Engineering Guides · Module 02
Mounting, interfaces, ROS 2 drivers and validation checklist
A sensor is not integrated until it is mounted rigidly, powered cleanly, driven with timestamps you trust, and validated on the robot.
Assumptions: Class-level guidance; check the datasheet and driver documentation of the exact model. ROS 2 message types are the standard sensor_msgs types where one exists.
1. Engineering problem
Most “sensor problems” are integration problems: a flexing mount, a noisy supply, a driver that stamps at arrival, or a missing transform. This guide collects the integration facts per sensor type and a bring-up checklist.
2. When is this needed?
- Bringing up a new sensor.
- Investigating a sensor that works on the bench and not on the robot.
- Writing an integration checklist.
3. Selection and design decisions
| Sensor type | Typical interface | ROS 2 message | Mounting notes | Calibration and sync |
|---|---|---|---|---|
| Monocular camera | USB 3.x, MIPI CSI, GigE Vision or GMSL | sensor_msgs/Image + CameraInfo | Rigid mount; vibration blurs images and breaks calibration; Avoid views through glass or windshield reflections; Protect the lens; plan cleaning | Intrinsics (and distortion); extrinsics to the base or IMU; time offset to the IMU if used for VIO. |
| Stereo camera | USB 3.x, GigE, MIPI or GMSL | sensor_msgs/Image + CameraInfo (left, right, often depth or disparity) | Stiff, vibration-isolated rig; both cameras on one rigid bar; Baseline chosen for the working distance | Intrinsics of both cameras and the stereo extrinsics; recheck after any mechanical stress. |
| RGB-D (active depth) camera | USB 3.x (most), Ethernet | sensor_msgs/Image (colour, depth) + CameraInfo, optionally PointCloud2 | Clear view, no glass in front; Avoid pointing at windows or into sun; Keep the minimum depth distance clear of the robot body | Depth and colour intrinsics and the depth-to-colour extrinsic (factory values usually available; verify). |
| Event camera | USB 3.x, MIPI | vendor-specific event messages (no standard sensor_msgs type) | Rigid; same considerations as a frame camera; Avoid scenes with strong flicker | Intrinsics via a blinking pattern or a co-located frame camera; temporal calibration to IMU. |
| Thermal (long-wave infrared) camera | USB, GigE, analog + capture, MIPI | sensor_msgs/Image + CameraInfo | Germanium or suitable window in the enclosure, not glass; Shield from direct sun on the lens | Intrinsics need a heated target; extrinsic to the visible camera for fusion. |
| 2D LiDAR (scanning) | Ethernet, USB/UART | sensor_msgs/LaserScan (ranges and optional intensities; no covariance field: uncertainty must be modelled separately) | Mount where the plane clears the robot body and sees the obstacles that matter; Level, with a clear 360° if needed; avoid being blocked by cables | Extrinsic to the base frame (height, tilt); time offset if fused with IMU. |
| 3D LiDAR (mechanical, spinning) | Gigabit Ethernet (UDP), sometimes with PTP and PPS | sensor_msgs/PointCloud2 (binary point blob described by PointField entries; no covariance field: uncertainty must be modelled separately) | Clear view with the body outside the field of view; mind the blind cone near the mounting axis; Higher placement sees farther but loses near ground | Extrinsic to base, IMU and cameras; per-point timestamps for deskewing. |
| Non-spinning LiDAR (flash, MEMS, optical phased array, hybrid) | Ethernet | sensor_msgs/PointCloud2 (no covariance field: uncertainty must be modelled separately) | Orient the field of view toward the critical area; use several units for coverage; Check overlap and blind regions | Multi-unit extrinsics need care; per-unit time offsets. |
| FMCW LiDAR | Ethernet | vendor-specific (often PointCloud2 with an extra velocity field; no covariance in the standard message) | As for 3D LiDAR | As for 3D LiDAR; verify how velocity is referenced (sensor frame). |
| IMU (accelerometer + gyroscope) | SPI, I2C, UART, CAN, USB | sensor_msgs/Imu | Rigid, near the centre of rotation if possible; isolate from vibration; Record the exact mounting orientation and lever arm | Bias, scale and axis alignment; noise parameters for fusion; extrinsic and time offset to camera/LiDAR. |
| GNSS (multi-constellation) | UART (NMEA/UBX), USB, CAN | sensor_msgs/NavSatFix | Antenna on top with a clear sky view and metal ground plane; Keep away from noisy electronics, cables and transmitters | Antenna lever arm to the base frame; fix the datum/frame convention (ENU vs NED). |
| RTK GNSS | UART, USB, CAN, Ethernet | sensor_msgs/NavSatFix (with fix status) | Same as GNSS, with better antenna quality; Plan the correction link and its antenna | Lever arm; correct base station coordinates. |
| GNSS/INS (integrated unit) | Serial, Ethernet, CAN | sensor_msgs/NavSatFix, Imu and vendor odometry messages | Rigid to the chassis; antenna(s) with sky view; measure lever arms precisely | Lever arms and mounting alignment; time sync via PPS. |
| Barometer / pressure sensor | I2C, SPI | sensor_msgs/FluidPressure | Vented, shielded from wind and propwash and sun; foam cover for light; Away from heat sources | Zero at start; temperature compensation; fuse with IMU/GNSS. |
| Magnetometer | I2C, SPI | sensor_msgs/MagneticField | Far from motors, ESCs and power cables; away from steel | Hard-iron and soft-iron calibration after final assembly; local declination. |
| Radar (mmWave and automotive-class) | CAN, CAN-FD, Ethernet, UART | vendor-specific (often PointCloud2 or object lists) | Behind radome material that is transparent to the band; Avoid metal in front; fix the mounting angle | Extrinsic and boresight alignment; time sync. |
| Ultrasonic range sensor | GPIO trigger/echo, UART, I2C, CAN | sensor_msgs/Range | Pointed slightly up from the floor; arrange firing order to avoid crosstalk; Keep the body out of the cone | Mounting position; temperature compensation. |
| Wheel / joint encoder | Quadrature, SPI/SSI, CAN, EtherCAT | sensor_msgs/JointState (through ros2_control); derived nav_msgs/Odometry | Mount on the output side if backlash matters; Shield cables; keep quadrature lines away from motor power | Wheel radius and separation; encoder zero offsets. |
| Force/torque sensor | Ethernet, EtherCAT, CAN, analog | geometry_msgs/WrenchStamped | Between wrist and tool, with cable strain relief; Rigid, with no mechanical interference | Bias (zeroing), tool mass and centre of mass; frame to the tool. |
| Tactile sensor | I2C, SPI, USB, vendor bus | vendor-specific | Integrated into fingertips; route cables to avoid flexing damage | Per-sensor calibration against known loads. |
| UWB (ultra-wideband) ranging | SPI, UART, USB | vendor-specific (no standard sensor_msgs type) | Anchors at known surveyed positions and varied heights; Keep antennas free of metal | Anchor survey and antenna delays. |
| Sonar (underwater acoustic) | Ethernet, serial, RS-485 | sensor_msgs/Range or vendor-specific | Clear acoustic path, away from thrusters; angle to the seabed or target | Speed of sound; mounting angle. |
4. Advantages and disadvantages
- Rigid mounts keep calibration valid but transmit vibration: isolate IMUs, not cameras or LiDAR extrinsics.
- Single shared power rail is simple but couples motor noise into sensors: separate rails or filtering.
- Vendor driver vs your own: a vendor driver is quick, a custom one gives control of timestamps; test whichever you use.
5. Requirements and constraints
- Cable strain relief and connector retention for vibration.
- Power and grounding (see the electrical integration checklist in Module 3).
- Bandwidth of the interface (see the throughput guide).
- Time sync hardware (PPS, PTP) available on the computer.
6. Architecture
sensor ─(cable, power)─▶ interface (USB/Ethernet/CAN/UART) ─▶ driver node (stamps, frame_id) ─▶ topic ─▶ consumers
└─▶ static transform to base_link (URDF)7. Implementation
- Mount: rigid bracket, measured position and orientation, photo and CAD recorded; protect the optics or antenna.
- Power and cable: supply within the rated range at peak, strain relief, shielding for noisy runs.
- Interface: connect and verify the link at the required rate (check for errors and drops).
- Driver: run it, then check the topic: type, rate,
frame_id, stamp meaning and covariance fields. - Transform: add the static transform from measured values; check its direction with a test point (frame-conventions guide).
- Time: measure stamp versus receive time and offsets to other sensors (bag-latency guide).
- Validate: run the sensor-specific validation from its entry; record the results.
Commands (not executed by the site’s tests): ros2 topic list -t, ros2 topic hz <topic>, ros2 topic bw <topic>, ros2 topic echo <topic> --once, ros2 run tf2_ros tf2_echo <parent> <child>.
8. Real examples
- A 3D LiDAR on a mast that flexes: the extrinsic is valid only when the mast is still; stiffen it.
- A GNSS antenna next to a motor driver: position noise rises when driving; move or shield it.
- A camera driver stamping at arrival: stamp offset shows as alignment error while turning.
9. Failure scenarios
- Connector loosening under vibration.
- Ground loops or motor noise in sensor supplies.
- Driver publishing with the wrong
frame_idor time base. - Calibration done before the final mounting.
10. Troubleshooting
- Bench-test the sensor alone; if it works, the problem is integration.
- Check supply voltage at the sensor under motor load.
- Check rate, drops and stamps of the topic.
- Check the transform direction and values.
- Repeat the validation after any mechanical change.
11. Validation
- Every sensor’s rate, stamp meaning and frame are documented and measured.
- Calibration done after final mounting and validated.
- Sensor data stays within spec during a full-load drive (motors, wireless, compute running).
- Each sensor’s validation record is stored.
12. Engineering checklist
13. Further references
- sensor_msgs definitions: ros2/common_interfaces (jazzy).
- Vendor documentation for the specific sensor and driver (not fetched here).
Related on FixTheRobot
- TF Frames and Coordinate Consistency SLAM · Lesson