ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Launching laser_scan_matcher and gmapping [closed]

asked 2019-07-28 08:26:52 -0500

tsdk00 gravatar image

updated 2019-07-28 08:46:32 -0500

Hi, So I have a simple question. When I'm building a map by launching gmapping node, so during the simulation (map building ongoing-process), is it possible to run laser_scan matcher node? What I want to do is correct the wheel odometry when the lidar sees a feature in the environment. For example, if running the robot in a narrow corridor, I want to use gmapping as a standalone package. So there will be error accumulated in the odometry due to the wheel slippage while running in the narrow corridor and once it has to turn at the end of the corridor, I want to correct the error in odometry by using laser_scan_matcher. Is it possible to do so?

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by tsdk00
close date 2019-08-28 06:09:14.454031


You can use robot_localization with laser_scan_matcher.

Humpelstilzchen gravatar image Humpelstilzchen  ( 2019-07-28 14:12:04 -0500 )edit

@billy Thanks for your reply. That's true since it is dead reckoning. But what I want to do is switching between wheel odometry and odometry from laser_scan_matcher. So, when I'm moving in a long narrow hallway, it would be advisable to use wheel odometry but once it sees a feature and it has to make a turn I wanted to use laser_scan_matcher odometry i.e switching the odometry from wheel encoder to odometry from laser_scan_matcher. Is that possible to do by writing a rosservice or by any other means?

tsdk00 gravatar image tsdk00  ( 2019-07-28 14:36:58 -0500 )edit

@Humpelstilzchen If I fuse the odometry data from laser_scan_matcher with wheel odometry or imu, it will give bad result when moving in a long narrow corridor. Since lidar will scan the same thing at every instant until it sees a feature. If it is possible to switch the fusion in between the simulation like for long narrow corridor use fusion between wheel odometry and imu and once it finds a feature use lidar+imu fusion. But I'm not sure whether it is possible or not.

tsdk00 gravatar image tsdk00  ( 2019-07-28 14:40:35 -0500 )edit

@tsdk00 - laser scan matcher has access to the exact same data as gmapping and won't be able to do anything more with that data than gmapping can. I don't understand why you think laser scan matcher will help, but I also do not claim to be an expert, so I don't know.

To your question: Can you switch between them? Aside from robot localization I can think of another way. Publish both ODOM from wheel and laser scan matcher on different topics and use a multiplexor to feed one of the other to gmapping...but that sounds like a bad idea as it will be complicated algo to know when to switch between the two and when you do switch, do you really have any idea which one is better? Laser scan matcher relies on features to advance the odom,

In a long narrow hallway, laser scan ...(more)

billy gravatar image billy  ( 2019-07-28 15:46:33 -0500 )edit

@billy Thanks alot. The thing is I was testing in a long straight pipe which is featureless just like moving in a narrow corridor. So there will be slippage if moving in a straight pipe but since I'm moving the robot at a slow speed, the slippage will be less. So once a junction arrives, say after 50m, I was thinking to use at that instant odometry from laser_scan_matcher since it would quite accurate at that instant since junction can be a feature. It might be certainly a bad idea but just wanted to test whether it can produce a better map or not.

tsdk00 gravatar image tsdk00  ( 2019-07-28 16:03:04 -0500 )edit

@tsdk00 You normally tune robot_localization with the covariance matrix. laser_scan_matcher should increase the covariances when it is less certain (I don't know if it does, the manual says no but iirc I have seen it somewhere).

@billy Despite the different algorithm between both nodes there is also another major difference: laser_scan_matcher will publish continuously its odometry information while gmapping will do it less often.

Humpelstilzchen gravatar image Humpelstilzchen  ( 2019-07-29 01:24:40 -0500 )edit

@Humpelstilzchen So if I'm using Gmapping node first, it will take as usual the odometry generated by wheels whenever scan matching fails and it will update the state. What, if after some time if I launch the laser_scan_matcher node, do you think it will override the odometry data from wheels and publish it from laser only?

tsdk00 gravatar image tsdk00  ( 2019-07-29 01:31:42 -0500 )edit

It will not override them. I recommend you read about Kalman Filter because it is a bit hard to explain here.

Humpelstilzchen gravatar image Humpelstilzchen  ( 2019-07-29 04:39:34 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-07-28 14:08:18 -0500

billy gravatar image

Gmapping isn't only mapping. It is also generating the map->odom transform(localizing). That means it is correcting for wheel slippage while it's mapping. SLAM = simultaneous localization and mapping

Laser scan matcher is used to generate ODOM when there are no encoders. It isn't intended to correct for slippage of wheel encoders. It replaces them.

To answer your direct question: No. Laser scan matcher will not correct error in odometry.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2019-07-28 08:26:52 -0500

Seen: 715 times

Last updated: Jul 28 '19