FixTheRobot Explore Robotics / Systems Engineering / Design & Selection / Module 02

Design & Selection · Module 02

Sensor selection: warehouse robots

Which sensors belong on a warehouse robot, what each one costs you, and how the sensor set fails.

  • Intermediate
  • Module 02: Sensor Selection, Trade-offs & Integration
  • Written for ROS 2 Jazzy where ROS 2 is used
  • Sources checked 2026-11-05

Assumptions: Application roles are engineering judgement about common practice (core, common, niche), not a survey. The sensor characteristics are class-level tendencies; the datasheet and your tests decide.

1. Engineering problem

Warehouse 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 warehouse robot design.
  • Replacing or adding a sensor after a field failure.
  • Reviewing a sensor architecture before purchase.

3. Selection and design decisions

RoleSensor types
Core (nearly always present)2D LiDAR (scanning), Wheel / joint encoder
CommonMonocular camera, Stereo camera, 3D LiDAR (mechanical, spinning), IMU (accelerometer + gyroscope)
Niche or supportingRGB-D (active depth) camera, Non-spinning LiDAR (flash, MEMS, optical phased array, hybrid), Ultrasonic range sensor, UWB (ultra-wideband) ranging

Typical combinations

  • 2D LiDAR + wheel encoders + IMU: Proven for structured, mapped aisles.
  • Add cameras or 3D LiDAR: Pallet and overhang detection, people awareness.

Sensor types that do not fit this application

  • Event camera: Not typical for this application.
  • Thermal (long-wave infrared) camera: Not typical for this application.
  • FMCW LiDAR: Not typical for this application.
  • GNSS (multi-constellation): GNSS is not available indoors.
  • RTK GNSS: GNSS is not available indoors.
  • GNSS/INS (integrated unit): GNSS is not available indoors.
  • Barometer / pressure sensor: Not typical for this application.
  • Magnetometer: Not typical for this application.
  • Radar (mmWave and automotive-class): Not typical for this application.
  • Force/torque sensor: Not typical for this application.
  • Tactile sensor: Not typical for this application.
  • Sonar (underwater acoustic): Underwater acoustic sensor; not for operation in air.

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

  • 2D LiDAR (scanning): Accurate, direct range with very little compute; but sees only one plane: misses tables, overhangs and low obstacles.
  • Wheel / joint encoder: Precise, high-rate proprioception; basis of odometry and joint control; but odometry drifts from wheel slip and uncertain wheel radius/track.

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

2D LiDAR (scanning)  ·  Wheel / joint encoder
   │ time-synchronised, calibrated extrinsics
   ▼
state estimation / SLAM  ──▶  planning and control

7. Implementation

Integration complexity: Medium: standard 2D LiDAR navigation is mature; adding cameras or 3D LiDAR for pallets and people raises integration work.

  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: Two LiDARs for field-of-view coverage, map features or reflectors for disambiguation, and a separate safety-rated scanner for personnel protection (the navigation LiDAR is not a safety function).

8. Real examples

A goods-to-person shuttle: 2D LiDAR + encoders + IMU for navigation, cameras for pallet detection and a safety-rated scanner for people.

9. Failure scenarios

  • Reflective, shrink-wrapped or glossy surfaces
  • Repetitive aisle geometry causing localisation ambiguity
  • People and forklifts occluding the scan
  • Floor joints and ramps tilting a 2D scan plane
  • Dust

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

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