Revision history [back]

This could be normal. You are using two noisy measurements and a fusing algorithm that's likely prone to sudden changes as well as slightly misaligned sensors. While your wheel odometry is reporting one thing, your accelerometer might be saying something else. The fusion isn't perfect and you get an offset. This also explains why the laser scans are 'reset' when the robot decelerates. Try quickly accelerating and slowly decelerating. It should stay offset. You could also get a sense of the quality of your odometry sources by checking what the results are using each raw sensor. If one of the sensors exhibits similar behavior, you could try weighting the other sensor more.

Whatever you do, getting odometry to be perfect is impossible. When your robot drives over uneven terrain, one wheel hits carpet before the other, or your robot becomes decalibrated during runtime, you'll get all sorts of faulty values. That's why the complementary sensors like your lidar should compensate for this with AMCL which has plenty knobs to play with to tune it to your specific robot. A particle filter will do just fine with the odometry you show in your video. Other packages also exist if you have stricter requirements.

Another potential source could be publishing lag or even visualization lag. Check delays and publish rates on each of your sensors to make sure your filter gets values frequently enough to spit out updated values using rostopic hz and rostopic delay.

This could be normal. You are using two noisy measurements and a fusing algorithm that's likely prone to sudden changes as well as slightly misaligned sensors. While your wheel odometry is reporting one thing, your accelerometer might be saying something else. The fusion isn't perfect and you get an offset. This also explains why the laser scans are 'reset' when the robot decelerates. Try quickly accelerating and slowly decelerating. It should stay offset. You could also get a sense of the quality of your odometry sources by checking what the results are using each raw sensor. If one of the sensors exhibits similar behavior, you could try weighting the other sensor more.

The fact that it deviates more when rotating could point to bad extrinsic calibration, specifically the translation component. Try playing with the tf transformations you set between IMU and your base_link to be closer and farther away and see if that affects thing. Distance between wheels could also affect rotation.

Whatever you do, getting odometry to be perfect is impossible. When your robot drives over uneven terrain, one wheel hits carpet before the other, or your robot becomes decalibrated during runtime, you'll get all sorts of faulty values. That's why the complementary sensors like your lidar should compensate for this with AMCL which has plenty knobs to play with to tune it to your specific robot. A particle filter will do just fine with the odometry you show in your video. Other packages also exist if you have stricter requirements.

Another potential source could be publishing lag or even visualization lag. Check delays and publish rates on each of your sensors to make sure your filter gets values frequently enough to spit out updated values using rostopic hz and rostopic delay.