We’re a university team developing a surface drone for marine applications, currently in the sensor selection phase for a complete onboard sensory architecture. We’re looking at your GNSS receivers, IMUs, and related sensing/communication products, and would really value input from someone with hands-on experience in marine or outdoor robotics deployments.
A few specifics about our use case :
· Surface vehicle operating in open water (sea testing so far);
· Need for synchronized data acquisition across multiple sensors (position, orientation, environmental);
· Long-range communication requirements given operating distances;
· Sensor placement and housing considerations for a marine environment (waterproofing, vibration, temperature range);
We’re trying to make well-informed choices early on rather than iterating through trial and error, so any guidance on compatible component combinations, synchronization approaches, or lessons learned from similar deployments would be extremely helpful.
Since our project involves some constraints around information sharing (we’re working with an industry partner), we’d prefer to continue this conversation over email if possible. If any of your engineers are open to that, please feel free to reach out directly, or let us know how best to get in touch — happy to share more technical details (prototype photos, dimensions, requirements) privately.
Thank you for the reference, we appreciate you taking the time to point us to OpenMetBuoy. It’s actually quite relevant to part of what we’re working on, since it combines GNSS and Iridium satellite communication in a marine deployment, which is close to what we’re considering for our own long-range communication setup. The reason we reached out is that our team doesn’t have much prior experience with sensor selection for marine applications, so we were hoping to get some direct input from someone with hands-on expertise, rather than working through it by trial and error. Unfortunately, since we’re collaborating with an industry partner on this project, we have some constraints on what we can share publicly on the forum. Because of that, we’d be really grateful if one of your engineers could help us over email instead, where we’d be able to go into more detail about our requirements. Would that be possible?
One of the “cheats” is to eliminate air space inside your electronics enclosure. The temperature swings will create pressure differentials that will pull-in outside air and it’s moisture (even with effective sealing at startup). Reducing the free-air volume helps significantly, but thermal management is still tricky.
If possible, design as much of your electronics package (inside the enclosure) to be completely waterproof (thick silicon conformal coatings, potting, etc) without the enclosure’s protection. Assume the enclosure will eventually be compromised to some degree by saltwater. Make sure it has nowhere to go - at both ends of your operational temperature range
We typically see very low duty cycles, so thermal design usually concentrates on Sun/Solar.
Hi Paul, we would share with you the sensor list that we made for every possible advice from you and your team, before we place an order from Sparkfun.
Our order includes:
Imu: ICM-20948;
GNSS: Receveir Breakout - MAX-M10S + magnetic mount antenna;
Sensor Breakout - BME280;
DS18B20 for each component (battery, esc, ecc..);
Load sensing: S-type TAS501, each with its own HX711 amplifier;
To give you a better idea of the usv, the hull’s drone dimensions are 83X85X18(cm), while the motor enclosure’s dimensions are 15X40X18(cm), and the hardware sensor platform that we are planning to use is Arduino R1 giga WiFi.
Unless you can give us some description of your requirements / specification, we can’t comment sensibly on your choice of sensors…
Put simply, what do you need to sense?
The global position of the drone?
The attitude of the drone (roll, pitch, yaw)?
Internal pressure, temperatures, humidity?
External pressure, temperature? Water temperature, air temperature, salinity?
Stress in the hull (which dictates needing the load sensing) - or something else?
You might want to consider a dual-antenna heading GNSS module, which will give you attitude information based on the relative antenna positions? The Septentrio mosaic-H is the gold standard here, but, sadly, we (SparkFun) don’t have a mosaic-H product available.
You haven’t mentioned comms. How much data do you want / need to transfer and how often? Will Iridium Short Burst Data (RockBLOCK) satellite comms meet your needs? Or will you be close enough to shore for standard mobile phone comms?
You haven’t mentioned power. Rechargeable batteries? What chemistry? Solar recharging? Larger batteries for the propulsion? Smaller back-up battery for the phone-home come-get-me comms…?
Will the drone be self-righting? Any possibility of it going turtle and not being able to self-right? Do you need a comms antenna on the bottom as well as the top?
Thank you very much for your detailed reply, to answer you our usv is a water rescue drone platform designed to support a person in the water (two handles for grabbing on, plus a semi-rigid stretcher with three attachment points to support the person’s legs.
The IMU needed us purely for the control of the drone (control of roll-pitch-yaw);
The sensor BME280 needed to monitor hull integrity, for example to help identify any water infiltration;
External environmental parameters are not needed for now, as we don’t have defined missions requiring that data yet;
The 5 load sensing sensors are for the 2 handles and the 3 stretcher attachment points (to monitor structural stress at those stressed points);
For the communications we really appreciate your advises: our current plan is to use the WiFi on the Arduino platform, since our initial tests will be conducted no more than 50-70 m from shore, furthermore communication needs to be bidirectional: we need to send control commands to the usv and receive telemetry data on shore; however, we’re inexperienced to estimating the actual data volume/frequency we’ll need, so any advice is gratefully accepted;
The power supply consist in rechargeable Li-on batteries, charged manually;
The self-righting is not a current priority but a future development, because now we are focused on evaluating the usv’s behavior in the sea water under normal orientation;
At last we searched for other prototypes but we didn’t find so much information about usv; we’ve developed a dynamic model in Matlab/Simulink, and the physical prototype has been built by the company in collaboration with our university.
Thanks again for the support and looking forward to your thoughts, especially in the data comms question,
Iridium Short Burst Data is perfect for applications where you need to transmit very small amounts of data - a few hundred bytes - from anywhere on the planet. There are Iridium solutions for higher amounts of data, but those can get expensive.
I think I would guide you to investigate two options: standard WiFi - perhaps a waterproof external antenna on the usv and a higher gain directional antenna on the shore which you can point towards the approximate location of the usv; or the standard radio control & video telemetry link used on flying uavs.
Will your initial usv be autonomous? Or will it always be guided / piloted by someone on the shore? That may guide you to chose LoRa (Long Range Radio) over standard WiFi or uav telemetry.
To sense water ingress, you would normally use some kind of conductive sensor similar to soil moisture measurement.
Wow… great project !
That’s much more exciting than what I assumed from your original post.
I have some ideas.
Would you consider autopilot implementation early on? Having the rescue vehicle remain “on station” throughout the day could be a huge value to the mission. It’s cheap and easy.
You might also want to consider LeFePO4 cells instead of Li-On.
Thank you both for the advice, really appreciated!
To give a bit more context: the vehicle is currently purely radio-controlled, piloted by a person on shore. Full autonomy isn’t reachable for us at this stage, so our priority right now is to validate basic RC control in the water first, stability, control response, and communication reliability. With the RC control priority in mind, we think a good next step is building out a proper sensor architecture (water ingress detection, IMU/orientation, battery monitoring, etc.) alongside the comms. This would give us a solid foundation to layer in station-keeping or autopilot later, once the base platform is proven in sea water.
