I kept seeing people (including myself) blame imu_filter_madgwick for odometry drift. spent a while being confused about this, thought i should make a post about what was going on.
I think the filter is not the problem. it's actually doing its job.
The issue I found was that MEMS gyros have a very small constant offset. That bias gets integrated into heading every single timestep downstream of the filter. It doesn't matter how well you tune madgwick, the bias is still there in the raw gyro output. after a few turns it compounds into a heading that's genuinely wrong, and then every straight line drives you further from where you think you are. Someone added a note about this to the imu_tools README recently too: https://github.com/CCNYRoboticsLab/imu_tools
I simulated the same path twice. same noise, same everything, only difference is whether the bias is estimated and corrected in the state estimator:
Correct me if my philosophy is wrong but the fix isn't upstream in the IMU filter. Rather it's downstream in whatever state estimator (you are using) consumes the filtered output... it needs to put bias in its state vector rather than treating it as noise to be tuned around.
i went down this rabbit hole a few weeks ago and ended up switching to FusionCore (https://github.com/manankharwar/fusioncore) which tracks bias as a filter state... drift basically went away on longer runs.
Ofcourse this is only about the odom → base_link layer.... you still want slam_toolbox on top for long-range localization.
anyway if you're getting heading error after turns even with a filtered IMU, this is almost certainly what's happening. I want to hear what folks here have been doing other than laying up with AMCL.