Re: which part of the code odom frame concept is written?
In ORB_SLAM2 original package, I think it publishes the pose directly in /map frame (/map -> /base_link), there is no /odom frame. In rtabmap, we follow the convention of REP105. /odom -> /base_link represents the pose computed by a frame-to-frame visual odometry for example. /map -> /odom represents the correction of odometry pose when a loop closure is detected and closed. To get the actual pose in the map frame, we should get /map -> /odom -> /base_link from TF.
For the code, /odom -> /base_link TF is published here. /map -> /odom is published here.
ORB-SLAM2 is a full SLAM approach, thus to integrate in RTABMap,
loop closure detection inside ORB-SLAM2 is disabled. Local bundle adjustment of ORB-SLAM2 is
still working, which makes the modified module similar to F2M. The big difference is the kind of features
extracted (ORB [Rublee et al., 2011]) and how they are matched together (direct descriptor comparison
instead of NNDR). Similarly to F2M, the size of the feature map is limited so that constant time visual
odometry can be achieved (without limiting the feature map size, ORB-SLAM2 computation time increases
over time). As ORB-SLAM2 has not been designed (at least in the code available at the time of writing
this paper) to remove or forget features in its map, memory is not freed when features are removed, which
results in an increasing RAM usage over time (a.k.a. memory leak).