Costmap2DROS transform timeout

[drishti_works]

Hi Matthieu,

We are currently trying to deploy the KinectV2 on our UGV.

Description of our stack:
Kinectv2 -> libfreenect2 -> kinect2_bridge -> RTAB-Map -> Move_base
Running everything on the Jetson TX2.

Upon running move_base we are getting the following error:
[ WARN] [1530340897.490120634]: Costmap2DROS transform timeout. Current time: 1530340897.4900, global_pose stamp: 1530340896.9615, tolerance: 0.3000

We have observed that the grid map (2d Occupancy Map ) that is created using the rtabmap is being published at a frequency of 1 Hz. I think this is whats causing move_base to give the error. we tried changing the tolerance limits in the Costmap2Dros and move_base config parameters, however for some reason move_base is not registering the change in parameters.

The same error does not arise in simulation or while using the zed camera (We had to stop using the ZED due to some hardware issues). It is only after switching to the kinectv2 we are facing an error. We are using the launch files for the kinectv2 and rtabmap as mentioned in the Hand Held Mapping Tutorial.

I hope you could help us with the same.

Thank you,
Ankit

[drishti_works]

Hi Matthieu,

Just to give you an update. We were able to increase to tolerance to 5seconds, and that allowed move_base to function.

However, we realised that Visual odom from RTAB Map was not being done very well, we would keep loosing Visual odom.

We tried the following tweaks:
1) Changed from F2M to F2F
2) Instead of GFTT we used FAST/BRIEF (tried all the others as well)

However, we are still loosing visual odom pretty easily.
There were a lot of feature points in our enviornment (whenever visual odom worked, we got a quality reading of 200+). But, once we lost visual odom, we needed to track back to the place that we were, even though the environment was known, and there were enough feature points.

Thus, request if you could guide us on:
1) Fixing the tolerance issue, without requiring the tolerance to be at 5 seconds (improve the publishing rate of RTAB Map)
2) How do we maximize the performance of the visual odom
3) How do we regain visual odom irrespective of where we lost it.

Thank you.

[matlabbe]

Hi,

Why odometry can get lost is described on this page (see lost odometry section): https://github.com/introlab/rtabmap/wiki/Kinect-mapping#lostodometry

What is the framerate of visual odometry? at which rate odom messages are published.

You can enable auto reset of odometry at the latest known position with Odom/ResetCountdown set to 1.

When using "Odom/Strategy" to 1 (F2F), you can also enable Optical flow (Vis/CorType=1), which can gives more matches to track. For all kind of odometry, increasing "Odom/KeyFrameThr" (default 0.3) may help to have more matches between consecutive frames. Beware that creating more keyframes would decrease odometry accuracy.

For the tolerance problem, not sure the frame rate would change anything, as for the static map, move_base should be able to handle updates that are not frequent (even 1 each 10 seconds or 1 each minute). Can you track down more specifically (with help of rqt_console) where in move_base code the warning is thrown?

cheers,
Mathieu