Re: ZED2 rtabmap loop closure and twisted map

Posted by matlabbe on
URL: http://official-rtab-map-forum.206.s1.nabble.com/ZED2-rtabmap-loop-closure-and-twisted-map-tp6986p7002.html

Hi,

One difference is the version of OpenCV libraries linked to. On 16.04, we have access to all OpenCV's features (even nonfree) because ROS provided its own OpenCV version. On 18.04, ROS relied on the system version of OpenCV, which has very limited features (not built with opencv_contrib or nonfree modules). With 16.04, GFTT/BRIEF is used by default, while on 18.04, GFTT/ORB is used.

In 0.20.4, a new parameter has been added to change the way quantization of binary features is done (to use less RAM and processing time). To use the older approach, set "Kp/ByteToFloat" to false. This may affect the matching.

To verify those hypotheses, I re-ran your database with different combinations with 0.20.4 (the 0.11 line is Rtabmap/LoopThr=0.11 by default):

1) GFTT/ORB

# left
$ rtabmap-reprocess --Kp/DetectorStrategy 8 --Kp/ByteToFloat true rtabmap.db output.db
#right
$ rtabmap-reprocess --Kp/DetectorStrategy 8 --Kp/ByteToFloat false rtabmap.db output.db

2) GFTT/BRIEF

# left
$ rtabmap-reprocess --Kp/DetectorStrategy 6 --Kp/ByteToFloat true rtabmap.db output.db
# right
$ rtabmap-reprocess --Kp/DetectorStrategy 6 --Kp/ByteToFloat false rtabmap.db output.db

3) SURF (baseline for loop closure detection)

$ rtabmap-reprocess --Kp/DetectorStrategy 0 rtabmap.db output.db

6) GFTT/ORB with some tuning

$ rtabmap-reprocess --Mem/STMSize 30  --Rtabmap/LoopThr 0.06 --Kp/DetectorStrategy 8 --Kp/ByteToFloat false rtabmap.db output.db

In conclusion, for this kind of environment, set Kp/ByteToFloat to false to get better loop closure hypotheses with binary descriptors. Rtabmap/LoopThr can be lowered to test more hypotheses. Mem/STMSize can be increased to avoid high loop closure hypotheses on just seen locations.

For your questions, you have set Optimizer/GravitySigma to 0.3, but there is no IMU added to map, so the map won't be optimized with gravity and won't be aligned with ground (unless input odometry is VIO, which seems not the case here). Verify that rtabmap node is received IMU data. To have less large gaps, as I said previusly, it is odometry drift. As you are using ZED's odometry, I cannot help more for that. Note also that your odometry covariance is set to Identity, this is quite bad if you want good map optimizations and to reject bad loop closures. If zed's odometry doesn't give good covariance, you can fix it on rtabmap node with odom_tf_angular_variance=0.001 and odom_tf_linear_variance=0.001.

cheers,
Mathieu