Inquiries Regarding Multi-Session Functionality in RTAB-Map

[csvicbot-7]

Dear @matlabbe,

As part of a deeper exploration of the multi-session mode in RTAB-Map, I have encountered a few technical questions that I hope you might be able to clarify:

1. From my understanding, in multi-session mode, the poses of nodes within each session are calculated relative to the session’s own reference frame. When a loop closure occurs between two sessions, the node poses are optimized accordingly. In such cases, with respect to which reference frame are the optimized poses calculated? Which frame becomes the prevailing reference?
2. How should one properly close a session and initiate a new one? Is it necessary to stop RTAB-Map in order to switch sessions? Additionally, is it possible to automate the transition between sessions during continuous navigation?
3. Suppose there are two sessions: session 2 is currently active, while session 1 is no longer running. If the robot operating in session 2 revisits an area previously mapped in session 1, should a loop closure occur between the two sessions? If so, how does RTAB-Map handle the comparison between nodes of different sessions? Are the nodes from session 1 still available in the long-term memory (LTM)?
4. The procedure outlined in the multi-session example appears to describe an offline post-processing approach for merging sessions into a single global session. Is there a way to achieve this integration in real-time?
5. In the multi-session example, I noticed that some loop closures detected within individual sessions differ from those observed in the merged global session. When constructing the global session, should different parameters be used compared to those used for each session independently? For instance, should parameters such as Kp/DetectorStrategy have distinct values for individual sessions and a different value for the global one?

Thanks in advance for your time and any insight you could provide.

[matlabbe]

1. The reference frame depends on RGBD/OptimizeFromGraphEnd. If false, the reference of the combined map will be the one from the oldest map. If true, the reference is the latest node added, which is odometry frame.
2. You can call service /rtabmap/trigger_new_map to initiate a new session. Restarting the node will also restart a new session (make sure you don't use -d or --delete_db_on_start argument), like if the robot is turned off and on again.
3. Yes, a loop closure can happen with an older unconnected map. RTAB-Map keeps in WM (Working Memory) nodes from all sessions. If memory management is enabled, then it could eventually forget an old map and loop closures won't be possible with that map anymore.
4. Well, if you play back to back all databases with their original publishing rate, that would be simulating a real-time run. But live, if you call /rtabmap/trigger_new_map, that would trigger the new sessions like in that example.
5. It depends on how you run the experiment. With memory management enabled, because we keep in WM the nodes of previous maps, we could start the transfer to LTM nodes from the current session first, so we may miss loop closures for the same session. Without memory management, I would expect relatively the same number of loop closures detected than processing each map individually. Note that some visual features work slightly worst with bigger maps, so loop closure hypotheses may not be high enough when after combining multiple maps and some loop closures may be missed. In our large-scale loop closure experiments, we were using SURF features, though SIFT could also work well on large-scale environments.

cheers, Mathieu