Re: Realtime Map Merger Improvements
Posted by derektan1995 on Sep 24, 2021; 3:37pm
URL: http://official-rtab-map-forum.206.s1.nabble.com/Realtime-Map-Merger-Improvements-tp8200p8605.html
Hi Mathieu,
Thanks for your reply and your elegant solution. Everything will look great on Rviz on a multi-robot map setup, even in the event of a loss-comms scenario.
I am still pondering more about my original question on how we can further improve the realtime map_merger capabilities of rtabmap. You mentioned in this post that we have to reprocess all map data from all robot's map nodes accumulated each time we want to combine them. However, this approach is simply too slow especially as the map on each robot grows large with time. From my testing, it takes about 10s per map merge after 2 robots have accumulated map nodes over 1 minute of operation. Are there any way to incrementally build the merged map similar to how the mapCloud plugin does it, as opposed to having to reprocess all nodes? (I recently noticed ETH Zurich coming up with something similar for pointcloud merging)
Perhaps one way is to grow each robot's map in a sequential order. In our current implementation, we are processing all of robot 1's nodes first (e.g. node 1 to node 30), then robot 2's nodes (e.g. node 31 to node 60). Whenever there are new nodes coming from robot 1, we can insert them between node 30 and 31. Similar for robot 2, new nodes can be inserted beyond node 60. That way, rtabmap will not detect odometry jumps and hence cause the disappearing map issue. I wonder if this approach is feasible? If so, how do we go about adding nodes to specific positions on the pose graph?
Looking forward to discussing more with you, as always.
P.s. A very simple implementation of map_merger node for your reference.
Regards,
Derek
URL: http://official-rtab-map-forum.206.s1.nabble.com/Realtime-Map-Merger-Improvements-tp8200p8605.html
Hi Mathieu,
Thanks for your reply and your elegant solution. Everything will look great on Rviz on a multi-robot map setup, even in the event of a loss-comms scenario.
I am still pondering more about my original question on how we can further improve the realtime map_merger capabilities of rtabmap. You mentioned in this post that we have to reprocess all map data from all robot's map nodes accumulated each time we want to combine them. However, this approach is simply too slow especially as the map on each robot grows large with time. From my testing, it takes about 10s per map merge after 2 robots have accumulated map nodes over 1 minute of operation. Are there any way to incrementally build the merged map similar to how the mapCloud plugin does it, as opposed to having to reprocess all nodes? (I recently noticed ETH Zurich coming up with something similar for pointcloud merging)
Perhaps one way is to grow each robot's map in a sequential order. In our current implementation, we are processing all of robot 1's nodes first (e.g. node 1 to node 30), then robot 2's nodes (e.g. node 31 to node 60). Whenever there are new nodes coming from robot 1, we can insert them between node 30 and 31. Similar for robot 2, new nodes can be inserted beyond node 60. That way, rtabmap will not detect odometry jumps and hence cause the disappearing map issue. I wonder if this approach is feasible? If so, how do we go about adding nodes to specific positions on the pose graph?
Looking forward to discussing more with you, as always.
P.s. A very simple implementation of map_merger node for your reference.
Regards,
Derek
| Free forum by Nabble | Edit this page |