Re: Realtime Map Merger Improvements

Posted by matlabbe on Sep 28, 2021; 9:59pm
URL: http://official-rtab-map-forum.206.s1.nabble.com/Realtime-Map-Merger-Improvements-tp8200p8612.html

Hi,

If map merger node subscribes to MapData of each robot, it can then have the graph and node data to reconstruct each map. One thing required is how loop closures are detected between maps. A naive way could be to compare a new received MapData (last node) with nodes from all the other maps. When a loop closure is detected, it keeps in cache inter map constraints. It creates an Optimizer and feed graphs of all maps with the inter constraints, thus optimizing the whole global map. It could then re-split the global graph in each individual map to send pose updates to corresponding MapCloud plugins in rviz.

To find loop closures between maps, you may also create multiple rtabmap objects inside the map merger and feed them the corresponding MapData. However, each local rtabmap will try to find loop closures and re-optimize the map, but this process has been already done on each robot (and MapData already contains this info). You may configure those rtabmap objects in appearance-based mode only and disable loop closure detection inside them, thus only the BOW vocabulary will be created. A new public function to Rtabmap object would have to be added to call the Bayes Filter and get an hypothesis with external data (descriptors that also need to be quantized to local rtabmap vocabulary).

Other way (without modifying rtabmap code) similar to what you have is to have single rtabmap object, but in appearance-based mode only (RGBD/Enabled=false) and feed it all images from all robots in any order. Rtabmap will still try to find loop closures between those images, even if it assumes that images are normally consecutive. In this appearance-based mode, rtabmap will only returns that ID A matches with ID B with high probability, but won't return a transform. The transform will have to be computed externally, using directly RegistrationVis or RegistrationIcp classes between node data of the loop closure. You would have to offset IDs of the nodes that you receive based on the robot, and use Mem/GenerateIds=false to make sure that rtabmap use same IDs that you know from the outside. Example: all nodes from robot 2 are offset by 1000, so that 1002 is the second node of map 2. For map 3, they are offset by 2000... This assumes you may never get more than 1000 nodes per map.

cheers,
Mathieu