FixTheRobot Explore Robotics / Systems Engineering / Engineering Guides / Module 02

Engineering Guides · Module 02

Sensor combination: LiDAR + IMU

The IMU deskews and bridges between scans; the LiDAR bounds the IMU’s drift with geometry. Together they are LiDAR-inertial odometry.

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

Assumptions: General fusion guidance. Named algorithms appear only where their READMEs were checked (see the SLAM Selection Guide). No performance figures are given.

1. Engineering problem

A moving LiDAR distorts its own scan, and scan matching alone fails in fast rotation or sparse geometry. The IMU supplies the motion within the sweep and between scans.

2. When is this needed?

  • Outdoor and indoor mapping without GNSS.
  • Fast or rough motion.
  • Any robot that needs a dense 3D map.

3. Selection and design decisions

What each sensor contributes

SensorContributionWeakness the other covers
LiDARDirect metric geometry, independent of lightDistorted by motion in a sweep; degenerate geometry; weather
IMUMotion within a sweep (deskew), prediction between scansDrifts alone

Fusion approaches

  • Tightly coupled LIO: FAST-LIO (iterated extended Kalman filter, per its README) and LIO-SAM (factor-graph smoothing and mapping, per its README); they have different IMU requirements, so check the SLAM Selection Guide.
  • Loosely coupled: a LiDAR odometry result fused with the IMU in an outer filter.

4. Advantages and disadvantages

  • Tight coupling needs correct LiDAR–IMU extrinsics and per-point timestamps.
  • More points cost compute.
  • Not every method uses a Kalman filter: filters and factor graphs both appear.

5. Requirements and constraints

  • Time synchronisation to within what the estimator tolerates (use the Sensor Time Synchronization Simulator).
  • Calibrated extrinsics between every fused pair, with the transform direction documented (see the frame-conventions guide).
  • Per-point (or per-packet) timestamps and a shared clock with the IMU.
  • LiDAR–IMU extrinsic calibrated, direction documented.
  • IMU of sufficient rate and quality for the chosen method.

6. Architecture

LiDAR (points + per-point time) ─┐
                                 ├─▶ LIO estimator ─▶ odometry, map
IMU (≥ 200 Hz) ──────────────────┘

7. Implementation

  1. Verify the LiDAR publishes per-point time and the IMU stamps are on the same clock.
  2. Calibrate the LiDAR–IMU extrinsic and check its direction with a test motion.
  3. Configure the estimator and its IMU parameters; start stationary to initialise.
  4. Validate against closed loops and a reference.

Compare structures in the Sensor Fusion Architecture Builder.

8. Real examples

  • A tracked inspection robot in a tunnel; a car-park mapping cart.

9. Failure scenarios

  • Wrong extrinsic: jumping at start-up.
  • Unsynchronised stamps: zig-zag during motion.
  • Degenerate corridors or open fields under-constrain registration.
  • Rain or dust creating false points.

10. Troubleshooting

  1. Check the IMU output and axis convention before running.
  2. Check LiDAR–IMU time offset with a rotation test.
  3. Plot the odometry in a degenerate area and compare with wheel odometry.

11. Validation

  • Closed-loop drift below your limit over repeated routes.
  • Stable start-up from rest in five trials.
  • Map thickness of a flat wall below your limit.

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