What is the role of rtabmap in a `move_base` planning pipeline?

[tsbertalan]

I see in various places in launch files and forum posts mention of a set_goal service of rtabmap. However, as far as I can tell, local and global plans are still created by `move_base`. If RTAB-map is only for mapping and localization, what role should it have in planning?

For context, I have a Kinect-v1 on an Ackermann-style rover platform, and I'm currently using move_base for a global plan with the TEB local planner plugin.

[tsbertalan]

Additionally, where should goals be published/how should they be declared? On move_base_simple/goal? Or directly to rtabmap via the service? Does this apply to both sending goals through rviz or programmatically?

[matlabbe]

Hi,

RTAB-Map implements a topological planning (in its graph) on top of the metrical move_base global planner.  When memory management is disabled, there is not really big advantage to use rtabmap's goal instead of move_base's goal. It is convenient though to plan to a node called "kitchen" for example, instead of pose "5.67, 10.4". On loop closure, the goal will also follow the graph when it is deformed and the new pose will be re-sent to move_base. To read more in details how RTAB-Map planning is used with move_base, see the paper "Long-Term Online Multi-Session Graph-Based SPLAM with Memory Management".

Rtabmap has two topics to set a goal: /rtabmap/goal and /rtabmap/goal_node. With the second one we can set a node id or a label. For the first one, we can use it like move_base_simple/goal, thus in RVIZ, we can remap the 2D Nav goal button to /rtabmap/goal instead of move_base_simple/goal.

cheers,
Mathieu

[tsbertalan]

Thanks for the specific reference; I've been meaning to look over all the papers on the home page for a few days now, and will read in more depth this weekend, I hope.

It sounds like the graph-based planning is most useful when the ground-truth map is expected to be dynamic, or perhaps when it is large enough that the metrical (global) planner will have difficulty planning typical movements. I do see some drastic loop closures from time to time in my tests in my apartment, but I think these will go away when I get around to implementing sensor fusion with my motor encoder and cheap IMU, so the odometry improves. And, of course, there are no ground-truth dynamic changes to my apartment; the graph map should be relatively fixed.

So, I'll put down graph-based high-level planning, per the right side of that Figure 2, on my list of stretch goals. I imagine that it would be the most useful goal-setting API to offer to a high-level abstract planner (either human or automated). For instance, at least some of the Neato vacuum cleaners are known to do super-global navigation based on a set (graph?) of waypoints (nodes?), on a roughly one-per-room basis.