Launching laser_scan_matcher and gmapping [closed]
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?
You can use robot_localization with laser_scan_matcher.
@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?
@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 - 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 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 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 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?
It will not override them. I recommend you read about Kalman Filter because it is a bit hard to explain here.