Sensor selection: underwater robots

1. Engineering problem

Underwater robot: the sensor set determines what the robot can perceive, how it localises and how it fails. Choosing it from the failure cases backwards is cheaper than discovering them in the field.

2. When is this needed?

• Starting a new underwater robot design.
• Replacing or adding a sensor after a field failure.
• Reviewing a sensor architecture before purchase.

3. Selection and design decisions

Typical combinations

• IMU + pressure (depth) sensor + magnetometer: Attitude and depth.
• Add sonar (and camera in clear water): Obstacle ranging and navigation where visibility is limited.

Sensor types that do not fit this application

• RGB-D (active depth) camera: Does not work (or is not used) underwater.
• Event camera: Does not work (or is not used) underwater.
• Thermal (long-wave infrared) camera: Does not work (or is not used) underwater.
• 2D LiDAR (scanning): Does not work (or is not used) underwater.
• 3D LiDAR (mechanical, spinning): Does not work (or is not used) underwater.
• Non-spinning LiDAR (flash, MEMS, optical phased array, hybrid): Does not work (or is not used) underwater.
• FMCW LiDAR: Does not work (or is not used) underwater.
• GNSS (multi-constellation): Does not work (or is not used) underwater.
• RTK GNSS: Does not work (or is not used) underwater.
• GNSS/INS (integrated unit): Does not work (or is not used) underwater.
• Radar (mmWave and automotive-class): Does not work (or is not used) underwater.
• Ultrasonic range sensor: Does not work (or is not used) underwater.
• Wheel / joint encoder: Does not work (or is not used) underwater.
• Force/torque sensor: Does not work (or is not used) underwater.
• Tactile sensor: Does not work (or is not used) underwater.
• UWB (ultra-wideband) ranging: Does not work (or is not used) underwater.

Try your own requirements in the Sensor Selection Calculator; read the per-sensor detail in the family guides for cameras, LiDAR, inertial and positioning and other sensors.

4. Advantages and disadvantages

• IMU (accelerometer + gyroscope): High rate, no external dependency, works anywhere; but integrates noise and bias into rapid drift.
• Sonar (underwater acoustic): Works where light does not: turbid and dark water; but low resolution; the image is hard to interpret.

5. Requirements and constraints

• Range, accuracy and rate requirements written as numbers before shortlisting.
• Mass, power and compute budgets (see the power and compute guides).
• Environment: lighting, weather, surfaces (glass, reflective, dark).
• Interfaces and ROS 2 driver availability for your distribution.
• Cost and supply for the quantities you need.

6. Architecture

IMU (accelerometer + gyroscope)  ·  Sonar (underwater acoustic)
   │ time-synchronised, calibrated extrinsics
   ▼
state estimation / SLAM  ──▶  planning and control

7. Implementation

Integration complexity: High: sealing, pressure rating and acoustic effects dominate, and few standard drivers exist.

1. Select the core sensors and write down what each cannot see.
2. Add the common sensors that cover those gaps.
3. Define time synchronisation and calibration for every sensor pair that is fused (Modules 6 and 7).
4. Define the redundancy and failure behaviour (below), then build and validate sensor by sensor.

Redundancy: Redundant depth sensors, a second heading source, defined behaviour (surface, hold) on loss of position, and acoustic navigation aids where the mission requires absolute position.

8. Real examples

An inspection vehicle: IMU + pressure (depth) sensor + magnetometer for attitude and depth, a forward sonar for obstacle ranging and a camera in clear water.

9. Failure scenarios

• Turbidity limiting cameras
• Acoustic multipath near the surface and seabed
• Thruster noise interfering with sonar
• Magnetometer interference from thrusters and ferrous hull parts
• Depth sensor drift or blocked port

10. Troubleshooting

1. Reproduce the failure and record all sensor streams (ROS bag).
2. Check which sensor lost data or went wrong first (rates, stamps, covariance).
3. Compare against the failure list above and the per-sensor failure scenarios in the family guides.
4. Add the missing modality or monitor, then repeat the test.

11. Validation

• Each listed failure condition is provoked deliberately (glass, sun, GNSS loss, slip) and the robot behaves as specified.
• Each sensor’s data rate, stamps and extrinsics are verified on the integrated robot.
• Redundancy is tested by unplugging each sensor in turn.
• Results are saved with the configuration.

12. Engineering checklist

• Failure cases listed before sensors chosen
• Core sensors cover the main task; common sensors cover their blind spots
• Datasheet specifications checked at operating conditions
• Interfaces, power and ROS 2 drivers checked
• Time sync and calibration planned for every fused pair
• Redundancy and failure behaviour defined and tested
• Safety-rated functions identified separately from navigation sensing

13. Further references

• Class-level guidance written from general engineering knowledge; it contains no product specifications. Product-specific numbers must come from the manufacturer’s datasheet for the exact model and operating mode.
• ROS 2 message types: sensor_msgs (jazzy branch).

Related on FixTheRobot

• Complementary Strengths and Weaknesses of Cameras and LiDAR Perception · Lesson