laser_scan_matcher combined with wheel odometry
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!
Are you already using a localisation / sensor fusion node? If not, this sounds like something where robot_localization could be useful.
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.
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?
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.
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_lto ignore outliers. That, or you have to dig into the scan matcher code and play with covariances, as @gvdhoorn suggested.Did you solve you problem with laser scan matcher ?
Not sure if this is relevant, but please check this issue: https://github.com/ccny-ros-pkg/scan_... .