IMU and Odometry report divergent acceleration values

[147258369ymc]

Description

Cross-validating acceleration from two independent sources (IMU linear_acceleration
vs. odometry velocity differentiation) reveals significant divergence in the
TurtleBot3 Gazebo simulation. On physical hardware, these values should be
consistent within sensor noise bounds (~2 m/s² tolerance).

Steps to Reproduce

ros2 launch turtlebot3_gazebo empty_world.launch.py

Send step velocity command:

ros2 topic pub --once /cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.22}}"

Record /imu and /odom simultaneously, then compute:

a_odom = (v[t] - v[t-1]) / dt (from /odom twist)

a_imu = imu.linear_acceleration.x (from /imu)

Observed

|a_imu - a_odom| > 2.0 m/s² in 90% of executions.
Maximum observed divergence: >2000 m/s² during extreme inputs.

Impact

• Sensor fusion algorithms (EKF/UKF) that combine IMU and odometry will
  produce incorrect state estimates
• The simulation does not faithfully represent the sensor consistency
  guarantees of physical hardware

[manankharwar]

Hmm... the divergence is expected in Gazebo.... the physics engine reports instantaneous forces that don't match what a real IMU measures. A real IMU reports specific force (ofcourse acceleration minus gravity), while Gazebo's imu plugin computes acceleration from the physics state directly, so spikes from collision resolution show up as extreme values that a real sensor would never produce.

If you're trying to fuse IMU and odometry: the practical fix is outlier rejection before fusion. A chi-squared gate on the innovation (Mahalanobis distance between predicted and measured acceleration) will catch these spikes automatically. I built this into FusionCore for exactly this reason.... if you want a drop-in ROS 2 fusion node that handles this, it might save you some work.