laser_scan_matcher combined with wheel odometry

asked 2018-01-08 09:30:48 -0500

Chrizzl gravatar image

I have a differential drive robot which has a IMU, RPLidar A2 360 degrees laser scanner and encoders on the wheel axes. This way I have a lot of options to calculate my odometry and robot pose. I found out that the laser_scan_matcher package always gives the most accurate results, no matter how good I tune my wheel odometry. However, sometimes the laser_scan_matcher does not function good enough, for example in a hallway. The robot position will suddenly jump to a very different(wrong) point on the map.

I want to prevent this jumping and want the position to continue from the wheel odometry, untill laser_scan_matcher finds the correct position again. Is there any reasonably easy way to achieve this?

Thanks in advance!

edit retag flag offensive close merge delete



Are you already using a localisation / sensor fusion node? If not, this sounds like something where robot_localization could be useful.

gvdhoorn gravatar imagegvdhoorn ( 2018-01-08 09:52:29 -0500 )edit

As you suggested, I finally implemented robot_localization on my robot. (I had seen that package many times already, but thought it would be too hard to apply to my robot.) The odometry from the laser_scan_matcher serves via topic remapping also as an input for the robot_localization package.

Chrizzl gravatar imageChrizzl ( 2018-01-10 08:55:50 -0500 )edit

BUT: laser scan matcher always has the best odom in my experience, and I only want to prevent a big jump when laser_scan_matcher does not recognize it's scans anymore. (Combined with amcl/hector slam). How do I go and do this?

Chrizzl gravatar imageChrizzl ( 2018-01-10 08:57:45 -0500 )edit

I'm not an expert when it comes to robot_localization, but @Tom Moore is (he wrote it).

Something tells me this might perhaps be configurable using covariances.

gvdhoorn gravatar imagegvdhoorn ( 2018-01-10 10:04:30 -0500 )edit

Are you fusing the pose data from the scan matcher, or velocities? If it's pose data, you can use the Mahalanobis threshold parameters for that input in r_l to ignore outliers. That, or you have to dig into the scan matcher code and play with covariances, as @gvdhoorn suggested.

Tom Moore gravatar imageTom Moore ( 2018-01-10 10:09:25 -0500 )edit

Did you solve you problem with laser scan matcher ?

Lotfi_Z gravatar imageLotfi_Z ( 2019-04-25 12:32:52 -0500 )edit

Not sure if this is relevant, but please check this issue: .

EwingKang gravatar imageEwingKang ( 2019-05-13 02:49:10 -0500 )edit