What are the pros/cons of the different visual odometry options?

  • Stereo Camera
  • Optical Flow
  • SLAM
  • other?


  • how well it performs vs other odometry options/sensors (lidar, radar)
  • sensor fidelity
  • computation
  • accuracy
  • precision
  • drift
  • native resilience and repeadability in sensor noise or vehicle speed
  • ease of integrating with IMU/GPS
  • etc

In general, of course, because there are a lot of different ways the trade-offs go when we get into specifics about applications and hardware. I'm asking out of curiosity, not for designing anything in particular.

  • $\begingroup$ This is more of a discussion than a question. You seem to have an idea of what techniques are available, but everything else here is subjective. Is there a specific aspect of visual odometry that you are looking for help with, or a specific comparison that you'd like to make? $\endgroup$ – Ian Nov 15 '12 at 18:46
  • $\begingroup$ Nowadays, questions can be archived as wiki entries. This, provided good solid answers, would be a great wiki entry. I think it should stay open and receive good attention. $\endgroup$ – Josh Vander Hook Mar 29 '13 at 15:28
  • $\begingroup$ Sorry Eruditass but on stack exchange, we prefer practical, answerable questions based on actual problems that you face. For hints on how to write better questions, check out the tour and How to Ask pages. $\endgroup$ – Mark Booth May 30 '13 at 22:39
  • $\begingroup$ @MarkBooth, due to the open ended nature of the question, as per Josh's request, I was simply asking for it to become a community wiki, as I am sure others who go through the initial engineering process of selecting how to localize a robot may find it useful. $\endgroup$ – Eruditass Jun 23 '13 at 0:26
  • $\begingroup$ Community wiki is now pretty much deprecated on stack exchange. The recommendation is that either a question is good, on-topic, constructive and a good fit, in which case it stays open, or it isn't and it is closed. Essentially the community wiki patch is no longer needed now that we have suggested edits. More often than not it was used to stop people gaming the system getting rep while keeping a non-constructive question open. If you want to discuss this further, feel free to come over to Robotics Meta and ask a question there. $\endgroup$ – Mark Booth Jun 23 '13 at 10:00

In general, visual odometry is a method that performs odometric measurements using visual means. This rules out the SLAM component, since visual odometry is only a relative means of navigation (see my answer on navigation). There are a number of methods to extract the relative motion of the camera. Since the transform from camera to robot is known this will also give you the relative transform of your robot.

  • If you only work with a single camera, you will always have a scale ambiguity, unless you have something to resolve that ambiguity in your image (e.g. object of known size) or combine it with another form of odometry like wheel odometry.

  • From a vision point of you, there are two ways you can follow: dense and sparse processing. Dense processing means, you use a regular sampling of your image points for your processing (could also be the full image). Sparse processing would mean, that you first extract feature points and only perform your operations on these features.

  • Using optical flow for visual odometry, I would consider a dense approach. Once you got the flow field, you need to extract the motion components. This is not so trivial, as it largely depends on how your environment looks. There was an interesting way of resolving this in the presence of outliers presented in "Monocular Heading Estimation in Non-Stationary Urban Environment"

  • Sparse approaches will use features, which are extracted using feature detectors. Then there are two different methods on handling the features. First approach will perform tracking of the feature and in this way estimate where the scene point was moving to. Second approach performs association of features through feature descriptors. First one is usually used with fast algorithms on high frequency, while the second one is more robust to larger scene changes and hence can be run at lower frequency. The visual odometry on the MER Rovers works this way e.g. Some form of geometric constraint is used to remove outliers, usually with a form of RANSAC. There is quite a nice library called libviso2 for performing visual odometry this way.

| improve this answer | |

I'm not familiar with all visual odometry options, but you might find the following two articles that recently appeared in the IEEE Robotics and Automation Magazine relevant:

Scaramuzza, D., Fraundorfer, F., Visual Odometry: Part I - The First 30 Years and Fundamentals, IEEE Robotics and Automation Magazine, Volume 18, issue 4, 2011.

Fraundorfer, F., Scaramuzza, D., Visual Odometry: Part II - Matching, Robustness, and Applications, IEEE Robotics and Automation Magazine, Volume 19, issue 2, 2012.

| improve this answer | |

Have a look at KITTI Visual Odometry Benchmark/Evaluation. Its a recent and nice evaluation of different stereo visual odometry algorithms on some large outdoor urban scenes. They compare it against ground truth (GPS).

I would say Visual Odometry are quite accurate and elegant perception systems. And its much better option than the IMU/GPS alone (even the high end ones).

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.