Accuracy requirement of odometry input for rtabmap when mapping

[cactus]

Hello! I'm pretty new to rtabmap and I'm slightly confused by a few things. The first question should just be a clarification, while the second question is the "meat" of this post and requires the first question.

1. There's the distinction between mapping mode and localization mode. The mapping mode is still performs localization with mapping, but only on loop closure, correct? The localization mode, on the other hand, assumes a good map and performs localization all the time. This implies that when in mapping mode, rtabmap only publishes map -> odom on loop closure and at no other time?

2. If mapping mode is doing localization _only during loop closure_, that means if you drive the robot in a straight line for a long time, the quality of the map generated will depend heavily on the quality of the input odometry? In my particular example, I have wheel odometry and IMU (within a realsense D435i) on a differential drive robot (two wheels). I observed pretty heavy drift in wheel odometry and the IMU appears to suffer from a large amount of drift. As a result, I don't think the odometry can be accurate for more than 5 seconds or so. Using this number, does it imply that I need to structure my driving in a way that loop closure can be performed every 5 seconds when building the map initially?

Thanks!

[matlabbe]

Hi,

1. Yes, everything you said is correct. During mapping, localization can happen with loop closure detection but also proximity detection (which is similar to loop closure detection but using odometry to help the search with close nodes). When using a lidar and with RGBD/NeighborLinkRefining=true, the robot can correct the odometry using lidar at each map update. In localization mode, the robot can exit the map and come back and be relocalized, there is no assumption that the robot should be always in the map.

2. When driving straight, it is more an odometry issue, but yes after some time if you pass by near an already visited place, it is better to revisit it to find a loop closure to reduce odometry drift. To reduce odometry drift, a careful tuning of wheel odometry can be done, a fusion of wheel odometry with visual odometry and/or IMU (see robot_localization package), adding a 2D lidar with RGBD/NeighborLinkRefining=true as above or even doing lidar odometry could be done.

cheers,
Mathieu

[cactus]

Thank you very much for the answers! I didn't know about NeighborLinkRefining, and will definitely investigate, although I don't have a LIDAR yet.

I may have a follow up question in this thread.