Disable Loop Closure detection

[ricber]

Hi,
I've read here https://answers.ros.org/question/226606/rtabmap-ros-mapping-without-loop-closure-detection/ that is possible to disable loop closure detection by setting Kp/WordsPerImage parameter to -1.

However, I can't find this parameter anymore in the header file at https://github.com/introlab/rtabmap/blob/master/corelib/include/rtabmap/core/Parameters.h.

How can I do?

I also would like to know, in case the loop closure is disabled, if the rtabmap node performs the graph optimization that is usually done after Loop Closure. In this case, I am expecting that the graph optimization is performed when the TF transform map->odom is updated by an external source of odometry. Is this correct?

Thanks,
Riccardo.

[matlabbe]

Hi,

The parameter Kp/WordsPerImage is now called Kp/MaxFeatures.

rtabmap won't perform graph optimization if loop closure is disabled (and RGB/ProximityBySpace=false). map -> odom TF would be always Identity.

cheers,
Mathieu

[ricber]

Is there a way to force rtabmap to use the map->base_link TF odometry for building the map instead of odom->base_link?

[matlabbe]

Yes, change odom_frame_id parameter of rtabmap node to "map". However, if map->base_link has discrete jumps (like there is some relocalization/loop closure detection going on), the poses in the graph will just jump without graph optimization.

[ricber]

Probably I got it. I made rtabmap reading the odometry from the topic leaving empty the parameter "odom_frame_id". Then, in the rtabmap node, I remapped from "odom" to my global odometry topic.            

[ricber]

Ops, you answered while I was replying

Yep, I have discreet jumps because the map->odom correction is done by robot_localization as fusion of rgbd_odometry and GPS data.

[ricber]

Anyway, do you think this is a problem?

Although the map->odom TF is affected by discrete jumps, if I assume the global odometry map->base_link to be accurate, the map should be OK even if no graph optimizations are performed. Am I wrong?

[matlabbe]

You may try it. What happens is that if there is a jump 1 meter left while moving forward 1 meter because of relocalization, in the graph the next node will be 1 meter left of the previous node. In reality, if we look at the odometry (which should be continuous), the motion should be forward 1 meter.

Another approach is to feed GPS to rtabmap with "Optimizer/PriorsIgnored" parameter set to false (to use GPS constraints in graph optimization). For rtabmap node, there is an input topic called /gps/fix. See also this tutorial to see how GPS can be also used in rtabmap.

cheers,
Mathieu

[ricber]

Thank you very much for your helpful answers. I think this forum should be elected as the best forum of the year . I've never seen a place like this where authors of an algorithm reply to all who write and with such rapidity and completeness :)

Anyway, as far as I've understood, the problem of using non-continuous odometry as input for rtabmap is that the graph could result in discreet jumps, thus leading to a broken map with holes, brutally said. But couldn't potentially happen the same thing with loop closure? When a loop closure is detected, the graph is optimized, and I think that even the optimization could lead to "discreet jumps", thus breaking parts of the map.

Is this true? If yes, does rtabmap takes into account this problem? Is it equipped with some strategies to preserve the integrity of the map, meaning that there no unmatched surfaces?

[matlabbe]

Hi,

Yes, if rtabmap detects the loop closures, the gap will be filled by re-optimizing the map. The problem is that if loop closure detection / relocalization is done outside rtabmap, rtabmap cannot know how much movement is caused by odometry or relocalization, so no loop closure constraint can be added to graph to re-optimize it.

A workaround is to have odometry independent to global localization that we feed as usual to odometry input of rtabmap. On global localization with gps or VICON/Optitrack pose, we can connect them to /rtabmap/gps/fix or /rtabmap/global_pose inputs respectively. With Optimizer/PriorsIgnored=false, prior poses will be added to graph to optimize it.

cheers,
Mathieu

[ricber]

With this solution, and assuming loop closure disabled, when the graph will be optimized? Is there a ROS service to call or something similar?

[matlabbe]

Nothing to call, it should optimize automatically when a prior pose is received and Optimizer/PriorsIgnored=false. However, I fixed a bug to make optimization happen not only in localization mode, but also in SLAM mode. See this commit. I tested with priors (GPS) and gravity constraints (IMU). If you want to try with a GPS example, you can download the database from this tutorial: https://github.com/introlab/rtabmap/wiki/Robust-Graph-Optimization#multi-session. In GUI, the Optimizer/PriorsIgnored parameter is under Graph optimization panel in Preferences ("Ignore pose prior" checkbox). You would see that each time a new pose is added, the whole graph shifts a little.

cheers,
Mathieu