Ask Your Question

robot_localisation IMU centripetal force

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

sts-hmm gravatar image

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 image enthusiast.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 image Choco93  ( 2019-10-01 02:30:16 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-01-02 04:02:53 -0500

Tom Moore gravatar image

I'm sure the math could be derived to handle that better, but if you're going to use a generic filter package like this one, you're probably better off "modeling" kinematic constraints in the sensor data, as you did. If your robot can't move laterally, zero out the variables in question and feed them to the filter. In any case, I definitely don't have the cycles to add that feature, but if you want to take a crack at it and can do it in a way that doesn't break or fundamentally alter the filter's behaviour, I'd be willing to accept a PR.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


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

Seen: 135 times

Last updated: Jan 02 '20