Visual odometry crash

[Bill]

I'm exploring various modules and configurations of RTABMap.

The visual odometry module is particular interesting because our iRobot create odom is not to great.  I've followed your visual odometry example and got it to output odom - but at some point it'd crash, probably when the camera is facing corner and rotating fast.

Another module I like is your obstacle detection module - It appear to be cleaner then raw depth field point cloud and it can be fed to local costmap as voxel for clearing/setting obstacles.  This module too crashes - maybe when floor isn't visible.

I don't know if this is known issue and if not I can produce logs.  Thanks!!

[matlabbe]

Thanks for the info, are you using the binaries? I've seen these problems before (when odometry has no features, when obstacle_detection doesn't see any ground or the input point cloud is empty) and some changes have been done in the source since then. Well, if you are using the RTAB-Map from github, I'll test again.

cheers,
Mathieu

[Bill]

Thanks man!  I built from git both rtabmap_ros and rtabmap and tested obstacles detection and rgbd odometry - both works! :)  obstacles detection runs through many situations where ground is not visible!

visual odometry works great, but still lose tracking when robot travel through a particularly narrow and featureless passage way - and it makes sense.  but after that particularly difficult area odom continue to stay 0, even when the area has many features.  I can see why that is - visual odometry has lost some continuity, but since many SLAM only look at short-term changes in odom, would there be a way to make it resume after area of featurelessness?

[matlabbe]

You can set parameter "Odom/ResetCountdown" to 1 (default 0) for the visual odometry node:

<param name="Odom/ResetCountdown" type="string" value="1"/>

This will make the odometry automatically resets on the last known position when it is lost. That means that it will introduce inconsistencies in the map created. For example, the robot moved in a featureless environment for about 3 meters, and when features can be tracked again, the odometry is reset 3 meters back.

Other solutions:
- use the wheel odometry instead of the visual odometry
- call service "/rtabmap/reset_odom" when odometry is lost (either detect null odometry coming from odometry node or use "lost" field of rtabmap/OdomInfo message), this will make odometry to reset on Identity transform, which when detected by rtabmap, create a new map. You will loose the previous map until a loop closure is found back between the new and previous maps, but you will have a consistent global map.