| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
I've been experimenting with fovis and viso2 in order to acquire visual odometry using the Kinect and Phidgets IMU. I noticed that the parameters are pretty much the same for both packages. Can anyone tell me which one they prefer and why?
One of the main differences is that fovis_ros supports mono+depth input as well as stereo and viso2_ros supports mono and stereo (but no mono+depth). If you use just a kinect, you will likely get better results using fovis_ros as with viso2_ros you can only use the mono_odometer which has several drawbacks (needs features on the floor and needs to know pitch and height of camera). If you use a stereo camera you can try both algorithms and look which works best for you.
fovis_ros offers a little more introspection which eases the tuning of parameters (compare FovisInfo to VisoInfo). It also has keyframe selection built in. For viso2_ros we hacked a solution to prevent drift on top of the library which is not very well tested.
Long story short: If you have a kinect, use fovis_ros. If you have a stereo camera, try both and look what works best for you. If you have a mono camera, use viso2_ros.
Hope that helps!
I actually started using ccny_rgbd and it has proved to be a nice complement to wheel encoder odometry. It is very lightweight which is desirable for my system and doesn't throw a lot of warnings and errors.
Asked: 2013-03-12 02:23:33 -0500
Seen: 2,079 times
Last updated: Mar 12 '13
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Which works better for you?
I'm getting better results from fovis_ros because it uses both depth and rgb. There are tf issues if you rely on the tf odom->base_link that fovis publishes. Errors arise if the messages are not perfectly in sync...
Please report any bugs regarding fovis_ros here.
I don't think the bug is in fovis_ros necessarily. The time stamp syncing between messages becomes delayed via a main launch file that launches every node for the robot. I believe this is the processor's fault. To compensate, I added a rate.sleep() in the odometer_base.hpp, increased the queue...
...to 10 and changed how fast the WallDuration was requesting synchronization.