Re: Mysterious error regarding tf timeout

Posted by matlabbe on
URL: http://official-rtab-map-forum.206.s1.nabble.com/Mysterious-error-regarding-tf-timeout-tp8695p8792.html

Hi Derek,

Thanks for the details. So 75mx75m local grids at 10 cm cell size can have up to 562500 cells in 2D. If you have 100 nodes to update like this, it will require 100 x 562500 (56M) operations to update the global occupancy grid. Well, do you need to have access to full global occupancy grid at any time? You could use GridGlobal/MaxNodes parameter to limit the size of the assembled occupancy grid to nodes curently close to robot. To plan beyond that occupancy grid, you would have to use path planner embedded in rtabmap to plan to a node in the graph instead of a pose. While moving on the graph on previously visited areas, the occupancy grid will be incrementally updated. I tried this approach on a robot having to use an OctoMap while doing SLAM, as the OctoMap updates on loop closures are large, limiting the OctoMap to only nodes close to robot reduced that processing time, while keeping the robot able to do local planning in the OctoMap and using RTAB-Map graph global planning for longer paths.

Other option is to increase GridGlobal/UpdateError (default 0.01m) so that global occupancy grid update happens less often, but will still increase in computation time like you've seen, just less often.

A final option is to increase the cell size to 20 cm for example, thus it will cut by 4 the computation time when the global occuancy grid has to be updated.

Make sure you subscribe to only one output map topic of rtabmap, so that only that map is generated.

cheers,
Mathieu

PS: yes by graph optimzation, when yellow links are added there is an optimization. If the optimization correction goes over GridGlobal/UpdateError, the global map is re-assembled.