Trajectory jumps with visual odometry

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Trajectory jumps with visual odometry

osbjo
Hi!

I am using the part of the rawseeds dataset and RTAB-Map to investigate the robustness of different sensor configurations when doing SLAM, and localization in a known map. I Have posted earlier concerning weird map behavior which I experienced due to subpar stereo image rectification. It is still not perfect, and I cannot redo the camera calibration since I use a dataset, but now my maps look visually good.

The issue at hand now is what can be seen in the following image. When using stereo odometry, much of the estimated trajectory is shifted away from the GT in these discrete jumps. This does not happen when using external wheel encoder odometry (see the second figure). I wonder what might cause this, and what I can do to rectify the issue. I have tried running with both the default parameters Viz/MinInliers and Odom/MinInliers, and with modified values (larger and smaller values), but to no avail.

 
Reply | Threaded
Open this post in threaded view
|

Re: Trajectory jumps with visual odometry

matlabbe
Administrator
It feels like it is jumping between two TF published on same name. If the bag has already odometry TF in it and you want to try stereo odometry, two options:
* Remove the odom tf from the bag (with a script similar to this if you are on ros1), and make sure you are not also using the same odometry topic name than in the bag.
* set "guess_frame_id" parameter in stereo_odometry node and set it to your wheel odometry TF frame. stereo_odometry will then publish the correction between VO and wheel odom in the TF tree to avoid breaking the TF tree (final tf tree would look like this: map->vo->odom->base_link).

Can you link which sequence in rawseeds dataset you are testing with?
Reply | Threaded
Open this post in threaded view
|

Re: Trajectory jumps with visual odometry

osbjo
Thank you for directing me toward the issue of overwriting /tf. That was the issue. My bag published a the wheel odometry transform from /odom -> /base_link, and removing this when running in VO mode solved the issue.

I have produced the bag myself from the raw data found in Rawseeds dataset Dropbox, but I don't suppose this will be of interest any more.