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

Design & Selection · Module 02

Sensor selection: humanoid robots

Which sensors belong on a humanoid 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

Humanoid 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 humanoid 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)IMU (accelerometer + gyroscope), Wheel / joint encoder, Force/torque sensor
CommonMonocular camera, Stereo camera, RGB-D (active depth) camera, Tactile sensor
Niche or supportingEvent camera, 3D LiDAR (mechanical, spinning), Non-spinning LiDAR (flash, MEMS, optical phased array, hybrid)

Typical combinations

  • IMU + joint encoders + foot force/torque: State estimation and balance: orientation, joint state and ground contact.
  • Add RGB-D or stereo camera: Terrain and object perception for footstep and manipulation planning.

Sensor types that do not fit this application

  • Thermal (long-wave infrared) camera: Not typical for this application.
  • 2D LiDAR (scanning): Not typical for this application.
  • FMCW LiDAR: Not typical for this application.
  • GNSS (multi-constellation): Not typical for this application.
  • RTK GNSS: Not typical for this application.
  • GNSS/INS (integrated unit): Not typical for this application.
  • Barometer / pressure sensor: Not typical for this application.
  • Magnetometer: Not typical for this application.
  • Radar (mmWave and automotive-class): Not typical for this application.
  • Ultrasonic range sensor: Not typical for this application.
  • UWB (ultra-wideband) ranging: 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

  • IMU (accelerometer + gyroscope): High rate, no external dependency, works anywhere; but integrates noise and bias into rapid drift.
  • Wheel / joint encoder: Precise, high-rate proprioception; basis of odometry and joint control; but odometry drifts from wheel slip and uncertain wheel radius/track.
  • Force/torque sensor: Direct contact-force measurement for compliant and safe interaction; but expensive and fragile against overload.

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)  ·  Wheel / joint encoder  ·  Force/torque sensor
   │ time-synchronised, calibrated extrinsics
   ▼
state estimation / SLAM  ──▶  planning and control

7. Implementation

Integration complexity: High: many joints, contact events and fast motion need tightly timed proprioception.

  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: Dual IMUs, encoders on both motor and output side, force/torque checks against model-based estimates, and defined safe-fall or safe-stop behaviour when state estimation is lost.

8. Real examples

A walking humanoid: pelvis IMU, joint encoders, foot force/torque sensors for contact, and a head-mounted depth camera for terrain.

9. Failure scenarios

  • Foot-contact misdetection from force/torque drift or noise
  • Impact shocks on the IMU at every step
  • Head-camera motion blur and vibration
  • Joint encoder backlash and compliance between motor and output
  • Cable fatigue at moving joints

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