How can I help AMCL deal with catastrophic wheel slips?

amcl

asked 2016-06-19 01:52:00 -0500

ChrisL8
241 ●13 ●19 ●28

My robot uses an ASUS Xtion for a fake laser scan and odometry from encoders on the wheels. It basically is a big version of a turtlebot.

For the most part it navigates fine, but sometimes a wheel will catch on something, like a lip on a rug or a threshold and spin badly. AMCL immediately thinks the robot has rotated and RVIZ shows that the map is in clear disagreement with the laser scan image of the surrounding walls.

Is there some setting in AMCL that will help it to "reset" when the visual input is very different from the model? In short, I'd like AMCL to assume the laser scan is right and the odometry is wrong when there is a huge disparity. As it is now, if it gets too bad I often just have to shut down AMCL and start over.

Note, this is for AMCL, where the map has been created and is not being updated.

edit retag flag offensive close merge delete

Comments

This picture might help explain what the issue is: https://ekpyroticfrood.net/shared/amcl_rotation_issue.png

You can clearly see how the corner of the room as seen by the 3D sensor is off from the corner of the map.

ChrisL8 ( 2016-06-22 21:51:52 -0500 )edit

add a comment

2

answered 2016-06-21 08:40:24 -0500

Icehawk101

955 ●27 ●35 ●55 http://ca.linkedin.com...

updated 2016-06-22 07:07:13 -0500

I used AMCL on a robot with Mecanum wheels, which have an enormous amount of slip. I used an IMU along with the laser_scan_matcher package in order to simulate the odom and then fed that to AMCL.

If you want to try with straight odometry, one thing you could try is increasing the covariance values in the odometry message. Covariance is a measure of uncertainty. If the uncertainty is high then AMCL should weigh the measurement less.

[EDIT] I did not know that AMCL doesn't use covariance, so I guess that's out.

In regards to laser_scan_matcher, yes and no. Yes, you are using the laser scans twice, but you are using them for different things. AMCL uses scan matching to compare the current laser scans against a map to try and determine the sensor's pose on that map. Laser_scan_matcher also uses scan matching, but between successive scans in order to determine the amount of translation and rotation there is between scans. This is then converted into a transform between a user specified fixed frame and base frame. TLDR: amcl uses scan matching to find pose on a map, laser_scan_matcher uses scan matching to find pose relative to its initial position.

edit flag offensive delete link

Comments

Based on this comment and the AMCL Wiki, I don't think that AMCL actually uses the covariance on the odometry topic. Am I wrong

ChrisL8 ( 2016-06-21 18:56:40 -0500 )edit

When you combine the IMU with the laser_scan_matcher and then feed it to AMCL, does that mean you are using the Laser Scan twice? This always confused me.

ChrisL8 ( 2016-06-21 18:57:15 -0500 )edit

Well, that I did not know. Oh well, there goes the covariance idea.

Icehawk101 ( 2016-06-22 06:57:07 -0500 )edit

My attempt to use the laser_scan_matcher resulted in a huge mess: https://ekpyroticfrood.net/shared/laser_scan_matcher_mess.png

I've never seen the green arrows spread so far and wide! I must be doing something very wrong.

ChrisL8 ( 2016-06-22 17:31:31 -0500 )edit

add a comment

1

answered 2016-06-19 20:11:11 -0500

spmaniato

1788 ●40 ●56 ●69 http://www.spmaniato.me/

A practical way of doing this in any state estimation filter (which is what AMCL is) is to increase the process noise (noise in motion) relative to measurement noise (sensor noise). That's not as straightforward in AMCL. The way I've been doing it is by increasing the value of the odometry parameters (odom_alpha_1, etc.) But that affects the behavior of the filter at all times, not just when there's wheel slippage.

Another way would be to fuse your raw odometry with another sensing modality, such as an IMU. If that's not an option, you can feed odometry into the laser_scan_matcher and have that broadcast the odom to base_link transform (see the wiki page). I haven't tried this, but I'm planning to.

Looking forward to other people's answers.

edit flag offensive delete link

Comments

Isn't feeding the odometry into the laser_scan_matcher and then using AMCL essentially using the laser scan twice? I guess if it works, there is nothing wrong with it.

ChrisL8 ( 2016-06-21 18:58:33 -0500 )edit

Yes, it's a bit weird. But they are using the LaserScans differently. One is doing laser scan matching and the other Particle Filtering using an inverse sensor model for the laser distance sensor.

spmaniato ( 2016-06-22 11:55:28 -0500 )edit

add a comment

How can I help AMCL deal with catastrophic wheel slips?

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

How can I help AMCL deal with catastrophic wheel slips? edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

How can I help AMCL deal with catastrophic wheel slips?