Robotics StackExchange | Archived questions

robot_localisation IMU centripetal force

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 robotlocalisation 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 imuconfig 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?)

Asked by sts-hmm on 2019-09-30 10:39:20 UTC

Comments

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

Asked by enthusiast.australia on 2019-09-30 16:16:45 UTC

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.

Asked by Choco93 on 2019-10-01 02:30:16 UTC

Answers

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.

Asked by Tom Moore on 2020-01-02 05:02:53 UTC

Comments