ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
So, this is more of a placeholder answer for the time being. I'm working on a more long-term fix with more official support.
Short story: Point Grey doesn't want to play nice with the ROS community (or modern Linux distros, in general), if this bothers you, please don't buy their products.
This has been kind of a problem for a while (just search "Bumblebee" on rosanswers or ros-users).
For the autonomous lawnmower, we wanted to be able to use the stereo camera to detect obstacles in an outdoor (read: no Kinect) environment. Here is an example of the data that we were able to achieve using the following method: Bumblebee2 Point Cloud
As it stands, the best way I have found is to start with the Electric camera1394 driver, and modify it for a stereo camera based on this ticket. The patch isn't going to apply cleanly, because it was based on a much older version of camera1394. To take out some of the headache, you can use my pre-modified camera_drivers, which is what was used for the lawnmower (in the previous video).
This modification will allow the stereo deinterlacing to take place, and each camera will be broadcast on it's own topic (along with corresponding CameraInfo). I currently use Format7 for my capture, then use the image_proc pipeline for the rest. Format7 is odd in that you set the frame rate by setting the packet size, which is a supported dynamic_reconfigure parameter, but you will have to do the math yourself using this.
From there, you can do the stereo camera calibration
You can then use image_proc and stereo_image_proc to debayer, bin (to decimate), rectify, disparity, and point clouds. Here's an example pipeline from the lawnmower
So, I hope this helps you for now, until I can get something more permanent in.