robot_localisation IMU centripetal force

asked 2019-09-30 10:39:20 -0500

Required Info:

Operating System: Ubuntu 16.04, ROS Kinetic
Installation type: from source
Version or commit hash:
-kinetic-devel branch 2.48: 4317f16

I am using the robot_localisation with a RTK GPS (2cm accuracy) and an IMU in an ackermann vehicle. The GPS has an update rate of 2Hz, the IMU has an update rate of 50Hz. To get a continuous pose output, I tried to fuse both sensors. This seems to work for slow velocities, but when driving a circle with higher velocities I get a "sawtooth" behaviour, where the output is drifting towards the center of the circle until the next GPS message is received and the output jumps back to the correct path.

I tried to analyse the behaviour and wrote a simulation node to output correct and error free data for testing and noticed that high lateral acceleration is triggering this behaviour. For testing, I set the lateral acceleration to zero in my simulation node and this behaviour is gone (output is fine).

My assumption is, that the robot_localisation does not take centripetal forces into account. Is this right? Is it possible to enable this feature? (I tried to set the lateral accelerations to "false" in the imu_config matrix, but the error still exists. Only after setting the lateral acceleration sensor output to zero, the drift behaviour is gone. This seems strange to me, because the data is still used, even if I put the config to false?)

edit retag flag offensive close merge delete


can you share your robot_localization yaml files. i am also using it with two sources of odometry but i am getting this error. Your help will be appreciated.

[ WARN] [1569846712.545910322]: Costmap2DROS transform timeout. Current time: 1569846712.5459, global_pose stamp: 0.0000, tolerance: 0.5000
[ WARN] [1569846712.651372358]: Could not get robot pose, cancelling reconfiguration
enthusiast.australia gravatar imageenthusiast.australia ( 2019-09-30 16:16:45 -0500 )edit

Setting any value to false in your config file means you don't want your filter to use that value, and usually not using acceleration is good idea because it can change abruptly. Though I guess this effect can be mitigated by covariance values, but that again would require a lot of work to get them right.

Choco93 gravatar imageChoco93 ( 2019-10-01 02:30:16 -0500 )edit