IMU and LiDAR frequencies do not match

1. Symptoms

• The LiDAR-inertial estimator warns about missing IMU data for a scan.
• Odometry jumps at scan boundaries.
• The IMU runs at a different rate than configured.

2. Possible causes

• The IMU is configured at a rate that the driver or the link cannot sustain.
• A queue or buffer too small, dropping samples.
• IMU and LiDAR stamped from different clocks.
• The first or last IMU sample of a sweep is missing because of delay.
• The estimator assumes a nominal rate that does not match.

3. Measurements to collect

• Measured rate of each topic and the largest gap.
• Number of IMU samples between consecutive LiDAR stamps.
• Time offset between the two streams.

4. Diagnostic commands

Commands are not executed by the site’s automated tests (they need a ROS 2 Jazzy installation or the robot).

ros2 topic hz /imu/data
ros2 topic hz /points
ros2 bag record /imu/data /points
# count IMU samples per LiDAR sweep offline

5. Step-by-step investigation

1. Measure both rates and the largest gap.
2. Count IMU samples per sweep: it should be about IMU rate ÷ LiDAR rate with no empty sweep.
3. Check queue sizes and QoS of both subscriptions.
4. Check clocks and the time offset.
5. Check estimator parameters for the expected IMU rate.

6. Corrective actions

• Set the IMU rate to what the link sustains and update the estimator.
• Increase queue sizes; use sensor-data QoS for streams.
• Synchronise clocks and calibrate the offset.
• Interpolate or extrapolate IMU data at the sweep edges if the estimator supports it.

7. Validation after the fix

• Every sweep has the expected number of IMU samples in a long recording.
• No missing-data warnings over a full mission.

References

• See the guides on different rates and delays and LiDAR deskewing.
• ROS 2 message_filters documentation (Jazzy): doc/index.rst, read 2026-11-06.