Localization fails due to timestamp offsets

1. Symptoms

• Localization is fine when still and degrades or jumps when moving or turning.
• Fused pose jitters with a consistent lag behind the real robot.
• Different sensors disagree by an amount that grows with speed.

2. Possible causes

• Arrival-time stamps instead of capture time.
• Different clock sources (host, device, GNSS) not synchronised.
• A constant offset not calibrated.
• A drifting device clock.
• A use_sim_time mismatch between nodes.
• Transform lookups at the wrong time (latest instead of the measurement time).

3. Measurements to collect

• Cross-correlation lag between angular rates of two sensors.
• Stamp difference between messages that observe the same event.
• Offset over time to see drift.
• Speed at which the error appears.

4. Diagnostic commands

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

ros2 bag record /imu/data /points /odom /tf /tf_static
ros2 param get /my_node use_sim_time

5. Step-by-step investigation

1. Check still versus moving: an error that appears only in motion points at time.
2. Estimate the offset by correlating rotation rates (see the LiDAR/camera–IMU guide).
3. Check the clock source of every sensor and the stamping point in each driver.
4. Check use_sim_time on all nodes.
5. Check transform lookups use the measurement stamp.
6. Apply the offset and re-test.

6. Corrective actions

• Stamp with the capture time or convert device time with a measured offset.
• Synchronise clocks (PPS or PTP) and monitor them.
• Calibrate and apply the constant offset; track drift.
• Make time settings consistent across nodes.

7. Validation after the fix

• Localization error in motion is within the requirement.
• Estimated offsets are stable over days.

References

• See the guides on hardware versus software synchronisation and LiDAR–IMU and camera–IMU calibration.