Ask Your Question
0

stereo_image_proc pointcloud extremely low frequency

asked 2016-02-03 02:14:33 -0500

Ariel gravatar image

Hello,

I have a stereo vision system. Therefore, I'm using stereo_image_proc to get the rectified images as well as the pointcloud. As far as the rectified images, I get them at the same frequency as I get the raw images from the cameras (30 Hz), but the pointcloud is only 2 Hz, which makes it hard to do something with that. I only have the node to obtain the images from the cameras and stereo_image_proc. Is there anything else that I should be doing? Could stereo_Image_proc take that long to process the point cloud?

ariel@ariel-GT70:~$ rostopic hz /stereo/left/image_raw
subscribed to [/stereo/left/image_raw]
average rate: 30.038
    min: 0.019s max: 0.042s std dev: 0.00508s window: 25
average rate: 30.111
    min: 0.019s max: 0.042s std dev: 0.00496s window: 55
average rate: 29.964
    min: 0.019s max: 0.042s std dev: 0.00490s window: 85
average rate: 30.007
    min: 0.019s max: 0.042s std dev: 0.00502s window: 115
average rate: 30.039
    min: 0.019s max: 0.043s std dev: 0.00500s window: 145

ariel@ariel-GT70:~$ rostopic hz /stereo/left/image_rect_color 
subscribed to [/stereo/left/image_rect_color]
average rate: 31.532
    min: 0.017s max: 0.042s std dev: 0.00653s window: 19
average rate: 30.272
    min: 0.017s max: 0.049s std dev: 0.00610s window: 49
average rate: 30.328
    min: 0.017s max: 0.049s std dev: 0.00607s window: 79
average rate: 30.168
    min: 0.017s max: 0.049s std dev: 0.00615s window: 109
^Caverage rate: 30.208
    min: 0.017s max: 0.049s std dev: 0.00615s window: 123

ariel@ariel-GT70:~$ rostopic hz /stereo/points2 
subscribed to [/stereo/points2]
average rate: 1.827
    min: 0.547s max: 0.547s std dev: 0.00000s window: 2
average rate: 2.222
    min: 0.296s max: 0.547s std dev: 0.11000s window: 4
average rate: 2.050
    min: 0.296s max: 0.635s std dev: 0.11259s window: 6
average rate: 2.053
    min: 0.296s max: 0.635s std dev: 0.10111s window: 8
average rate: 2.099
    min: 0.245s max: 0.635s std dev: 0.11812s window: 11

Thanks for the help.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2016-02-03 03:10:00 -0500

Dense stereo is a pretty CPU-intensive operation, so depending on resolution, number of disparities and importantly, the CPU and load of the machine used, it can be (much) slower than the rate at which images come in. If you are interested in only a certain range band, you can adjust/reduce min_disparity and disparity_range as described here. This reduces the amount of block matching comparisons performed and should reduce CPU consumption.

edit flag offensive delete link more

Comments

I have followed the tutorial and when I increase the disparity_range I see that my camera node (ueye_cam) starts dropping frames. Could is be that stereo_image_proc requests 'too much' from the cameras and they cannot keep up?

Ariel gravatar image Ariel  ( 2016-02-04 07:05:43 -0500 )edit

I think this could only be the case if you run everything in a single nodelet manager and use low number of threads for it. If you run cameras and stereo image proc in separate processes, the only explanation I see is high CPU consumption leading to the driver starving for CPU (?).

Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2016-02-05 05:39:56 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2016-02-03 02:14:33 -0500

Seen: 323 times

Last updated: Feb 03 '16