Hi Paul, I'm opening this topic to the list as I know there are some other Bumblebee users out there. My comments are inline below. By the way, there is another community-contributed Bumblebee driver that may be useful to you, see the bumblebee2 package. On Mon, Sep 20, 2010 at 5:57 PM, Paul Furgale wrote: > I'm currently writing a ROS interface for my Point Grey Research Bumblebee > Xb3 camera. The cameras come pre-calibrated and in my experience the factory > calibration works well. Unfortunately, they don't use the 5 parameter > distortion model currently supported in the image_pipeline. I can use the > Point Grey libraries to read their calibration file and generate maps > suitable for the OpenCV function cv::remap(). Skimming the code of > image_pipeline suggests that you have something very similar implemented. > Out of curiosity, do you know what distortion model they use? I don't have experience with the Bumblebee cameras, but I've browsed Point Grey's software docs and it looks like their SDKs perform exactly the same operations as the image_pipeline. It would not surprise me at all if their distortion parameters could be encoded into CameraInfo as-is (or at least closely approximated), if only their APIs exposed them. Rather than go my own way and produce a parallel implementation of > PinholeCamera and the stereo processing already available in ROS, I would be > interested in helping shoehorn in support for custom rectification/dewarping > maps. The simplest solution I can think of is to add the ability to set the > undistort maps in the pinhole camera model, and add some fields to the > CameraInfo message. Granted, a custom map would be necessarily large, but > the CameraInfo message is meant to be transmitted once during initialization > (as far as I can tell). > Actually, every Image message is paired with a CameraInfo message having the same timestamp. So unfortunately putting custom maps in CameraInfo would be very expensive in bandwidth. image_geometry::PinholeCameraModel is optimized to only rebuild the undistort maps when the parameters change (e.g. in self-calibrating systems). Currently the easiest way to integrate is to just bite the bullet and use camera_calibration to get a camera model that the image_pipeline understands. Another way is to replicate the topics produced by stereo_image_proc in your driver node. You'd use PtGrey libs for the rectification (image_rect and image_rect_color topics). stereo_image_proc has some undocumented but fairly stable library methods(processDisparity, processPoints2) you can use to produce the stereo outputs (disparity image and point cloud). The community-contributed videre_stereo_cam package has a driver for Videre stereo cameras that I believe follows this model. For Diamondback I'm planning to refactor the image_pipeline into nodelets. That might be interesting to your use case, as nodelets will give you much more flexibility in mixing and matching the image_pipeline operations. You'd just write your own nodelet for rectification and swap it in for the default one using PinholeCameraModel. The last couple options have the drawback that CameraInfo and PinholeCameraModel still don't understand the distortion model. For many (admittedly not all) vision processing nodes this will be OK, as they operate on rectified images and ignore distortion. Do you have any interest in this? Is this the right venue to discuss this or > should I post these suggestions somewhere else? > Yes, and the mailing list is the best place for design discussions like this. Cheers, Patrick Thanks! > -- > Paul Furgale > PhD Candidate > University of Toronto > Institute for Aerospace Studies > Autonomous Space Robotics Lab > ph: 647-834-2849 > skype: paul.furgale > Videos of robots doing things: http://asrl.utias.utoronto.ca/~ptf/ >