viso2 stereo disparity

Question

I am trying to use viso2_ros . So I calibrated my stereo camera set.

Does the distance between the cameras matter much?Is this setup good enough?

The above are my calibration results.Is that fine? I didn't get any reprojection error as mention in this post. It just showed ? under epi . Is that okay.Around 180 samples were used in calibration.

Then I used stereo_image_proc package and then tried to optimize the parameters

A few more disparity maps

Are the disparity maps ok? Any suggestions on improving them? Is it okay to have grey background?

The following is the tf and rqt_graph

Is that correct? My knowledge on tf is basic and limited as I am a beginner. The following is the launch file used to generate the tf tree.

cambase is nothing but the left camera as suggested in this post.

I also checked the ~info topic messages of stereo odometer. the number of inlier's is very low i.e less than 10 and the number of matches is at max 25 . How do I improve upon it? I am always getting

Visual Odometer got lost!

even when the setup is at rest. How do I improve the inliers and get my system running? Are the things setup till now correct like the calibration and tf tree.

Configuration:

OS: Ubuntu 12.04

ROS distro: Hydro

Camera: PS3 eyecamera X 2 ---- 640x480 @ 60fps

P.S: If anything is not clear please let me know. This my first post. I have also read the following posts before asking and tried to improve from those suggestions

1. Post 1
2. Post 2
3. Post 3
4. Post 4

Update:

Point cloud generated by running viso2 . It is just some dots behind the camera.

point cloud generated by stereo_image_proc

This is the output of rostopic echo /stereo/left/camera_info and rostopic echo /stereo/right/camera_info . I hope it is correct to compare to seq with same id.

Also my stereo set is running at 640x480 @ 60fps

---

Originally posted by Sai Anirudh Kondaveeti on ROS Answers with karma: 3 on 2015-05-26

Post score: 0

Answer 1

Hi,

Does the distance between the cameras matter much?

Yes it does matte, as you increase the baselength B, your ability to reconstruct distant points increases, for indoor purposes baseline should be around ~12/13 cm. (this depends on the camera lenses(zoom level) and the focal length too). for out-door purposes use 25 to 30 cm.

Is this setup good enough?

the set up is good enough. make sure that cameras provide data of the same time, i mean there should not me more 30ms of delay between two camera(left-right) frames(again this depends on your speed of camera)

The above are my calibration results.Is that fine?

Your calibration looks fine! and disparity map too.

Are the disparity maps ok? Any suggestions on improving them? Is it okay to have grey background?

You are getting grey parts in back ground because algorithm is not able to find the disparity values for that region. if you want to improve it, you should use SGBM (again speed is the deciding factor here)

I didn't get any reprojection error as mention in this post. It just showed ? under epi . Is that okay.Around 180 samples were used in calibration.

After the calibration, when you bring your board in the frame the '?' will be replaced by the reprojection error. Try it again :) and 180 samples are more than enough. usually 20 samples will do the job :P

Now the actual question,

Viso2 is very good algorithm for pose estimation, it computes sparse features to get the changes in pose, the code is meant for high resolution and wide-baseline cameras and for out door purposes, though it should work on the low resolution cameras too. Your TF tree and other system level things are fine as far as i can see but the code is not able to find sufficient amount of feature matches thats the reason for "odom lost".

Try running this package outdoor and see how is the performance once. Number of matches will improve. Make sure that you experiment with this package in an environment where number of features are high. Try not to perform in-place rotation of camera, in that case Visual odometry algorithm might not work properly.

Hope I helped Sudeep

---

Originally posted by Sudeep with karma: 460 on 2015-06-01

This answer was ACCEPTED on the original site

Post score: 5

---

Original comments

Comment by Sai Anirudh Kondaveeti on 2015-06-02:
Thanks. I am working the on things you suggested.I kept approximate_sync:=true for the stereo_image_proc node.I used rostopic echo /stereo/left/camera_info and rostopic echo /stereo/right/camera_info and matched the seq to get time stamps. I hope that's correct way.Updated question

Comment by Sai Anirudh Kondaveeti on 2015-06-02:
Also I have kept my min_disparity:= -128 and disparity_range:=128 to have maximum range. Should I be optimizing on that ?[Computation cost is not a problem for me at the moment.]

Comment by Sudeep on 2015-06-03:
@^^ if you are not planning to mount the stereo camera on some fast moving robot like car then approximate_sync is fine. put min disparity as 0 and range as 128. To get better disparity use SGBM algorithm instead of BM(the one you are currently using) this will give you dense reconstruction.

Comment by Sudeep on 2015-06-03:
But it will not improve the performance of VISO2. Viso2 computes its own sparse feature based correspondence. :P

Comment by Sai Anirudh Kondaveeti on 2015-06-03:
Ok. I realised that the point cloud generated by viso2 is very sparse. Also I see that even-though my setup is at rest there is movement in rviz. Also observed that point cloud generated by viso2 is in -ve z- direction where as the pointcloud generated by stereo_image_proc is in +ve z-direction

Comment by Sai Anirudh Kondaveeti on 2015-06-03:
Is that normal? I am also adding the point-cloud generated by viso2 and stereo_image_proc