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

Revision history [back]

The transformation between odom and base_link represents your robot's best estimate of odometry using wheel odometry (thought you may potentially fuse other sources using robot_pose_ekf or robot_localization), so the two frames should not overlap.

In the perfect-odometry case, odom and map would overlap. The transform represents gmapping's localization correction. It looks like your odometry drifts quite a bit based on the video. Have you tried tuning it based on the nav stack guide (http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide#Odometry)?

If you get a lot of natural drift in odometry, you could try increasing srr, srt, str, stt parameters to pass that information to gmapping.

Finally, increasing the particle count is always a good bet, although it makes gmapping more processor intensive.

The transformation between odom and base_link represents your robot's best estimate of odometry using wheel odometry (thought you may potentially fuse other sources using robot_pose_ekf or robot_localization), so the two frames should not overlap.

In the perfect-odometry case, odom and map would overlap. The transform represents gmapping's localization correction. It looks like your odometry drifts quite a bit based on the video. Have you tried tuning it based on the nav stack guide (http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide#Odometry)?

If you get a lot of natural drift in odometry, you could try increasing srr, srt, str, stt parameters to pass that information to gmapping.

Finally, increasing the particle count is always a good bet, although it makes gmapping more processor intensive.


EDIT That laserscan overlay DOES look fairly consistent. Maybe your issue is more with sensor noise then? I've never benchmarked an RPLidar, but I know they're on the cheap side. I'm not sure if there's anything you can tweak in gmapping to help account for that - maybe using a larger grid size, or the increasing minimumScore parameter?