rtab_map localization tuning & goal setting questions

edit

Hi,

1. RTAB-Map follows REP105 for map frame, thus will produce discrete jumps when a loop closure or relocalization happens. Thinking of localizations like a GPS, you may look at this example to filter the localization poses (using robot_localization package). Another solution is to set RGBD/OptimizeFromGraphEnd parameter to true: the robot won't jump anymore, but it is the map that will jump around. Also, the global pose will drift over time (as odom will be the global frame), so if you plan to use metric goals for autonomous navigation to plan in map frame, you would have to pass by rtabmap's goal interface so that the pose can follow the graph (like in this paper).

2. You can do "Download Map" in rtabmapviz. However, if the map is too big, the download time would be too high and may fail (ros services are limited). The local database copy is a way to update rtabmapviz without downloading the map from rtabmap node. If it is not convenient for your application (as it requires to copy offline the database between the computers), you may then transfer to RVIZ, and subscribe to topics like cloud_map. Note that if you want the high resolution point clouds using rtabmap_ros/MapCloud RVIZ plugin, there is a new way to incrementally republish the whole map, see this post. This approach is still yet to be implemented with rtabmapviz.

3. It depends if you are in 2D or 3D, weight, size, cost and computation power of the robotic platform. In this paper, we compared Stereo vs 3D LiDAR for the 3D case, then RGB-D vs Stereo vs 2D LiDAR (short-range and long-range) for 2D mapping. Note that dense maps / occupancy grids would be more accurate with LiDAR-based mapping, while trajectory accuracy may be similar between LiDAR-based or Vision-based approaches (but that depends always of the environment, if it has a lot of geometric constraints required by LiDAR or visual textures and enough lighting required by vision).

4. See 3.

5. This is explained in this paper. RTAB-Map's goal interface is an intermediary between the module sending the goal and move_base. The goal can be metric or a node in the graph (even a label "kitchen") which will be translated to a metric goal. The metric goal is attached to closest node in the graph, so if the graph is deformed because of a loop closure, the goal will be republished to move_base with the new location matching the optimized map. This is essential useful only in SLAM mode. For the localization mode (with default RGBD/OptimizeFromGraphEnd=false), you could send directly your metric pose to move_base, as the map is fixed and will never change.