Reference

[Durant35]

• http://wiki.ros.org/laser_scan_matcher
• “An ICP variant using a point-to-line metric" Proceedings of the IEEE International Conference on Robotics and Automation (ICRA), 2008

https://censi.science/pub/research/2008-icra-plicp.pdf

[Durant35]

Whether pose values returned by laser_scan_matcher package relative or cumulative

• In that sense, they are cumulative

Obtaining nav_msgs/Odometry from a laser_scan (eg. with laser_scan_matcher)

• It looks like the scan matcher isn't measuring velocity directly, but it is computing the delta in the laser position, which you could combine with the time between laser scans to produce a rough estimate of velocity, subject to jitter in your laser frequency and any errors in the scan matching.
• Since laser_scan_matcher doesn't publish stamped poses, you'll have to modify laser_scan_matcher directly to compute this output.
• LaserScan has a timestamp in the message header that you can use to compute the time between scans.

Combining laser_scan_matcher with gmapping

• gmapping needs odometry as /odom -> /base_link. Setting the ~fixed_frame parameter from world to odom in the laser_scan_matcher should provide that. In this way the laser_scan_matcher should provide fake odometry by scanmatching. Alternately you can set the ~odom_frame parameter in gmapping to world (only do one of these).
• The base_link -> laser transform gives the position of the laser relative to your robot. As you are passing 0 0 0, your are saying its in the center of the robot. You should adjust that to the real position of the laser.

[Durant35]

Algorithm Analysis

• Using laser_scan_matcher output