[ros-users] Digital Camera 1394 in ROS?

[Rosen Diankov]

hi all,

Sorry for joining this heated discussion late.

The decision for including opencv into cameradc1394 was because we
wanted minimal latency for publishing an undistorted image with the
correct compression. In the past, ROS messages were being sent over
TCP/IP, and such a decision was necessary. However, with the recent
'nodelet' feature that allows image messages to be passed as pointers,
it makes much more sense to remove the opencv dependency from
cameradc1394 and make it consistent with the rest of the camera
drivers. Given that camera_drivers is released as a stack, this also
means that i would not be able to fix bugs in real-time if
cameradc1394 was offered as part of it.

If Willow Garage is willing to host an ieee1394 camera driver and
manage its lifetime in camera_drivers, I support the effort to create
a consistent 1394 driver package and would be glad to deprecate
cameradc1394 at the appropriate time.

rosen,

2010/3/11 Patrick Mihelich <mihelich at willowgarage.com>:
> I would also love to see a community-maintained dc1394 driver in ros-pkg.
> I'll echo that for inclusion in camera_drivers it would need to follow the
> same interface as the existing drivers, which we've put in some effort to
> standardize so that they work interchangeably with the image_pipeline. The
> docs are useful resources for these stacks:
>  * http://www.ros.org/wiki/camera_drivers
>  * http://www.ros.org/wiki/image_pipeline
>
> One design decision we made is that camera drivers need not do any
> processing of image data, not even debayering or undistortion. This keeps
> them low-dependency (no OpenCV needed). From a systems perspective it is
> nice to keep those concerns separate. The camera driver is only responsible
> for getting data off the camera and into ROS.
>
> The basic processing (debayering and undistortion) is handled by image_proc
> (or stereo_image_proc). It uses OpenCV functions. The OpenCV debayering
> functions are admittedly pretty basic; eventually we may make that
> plugin-based, so that people who are particular about their debayering
> methods can substitute in something more advanced like the libdc1394
> implementations.
>
> To work well with the image_pipeline packages the driver need only publish
> synchronized image_raw and camera_info topics. set_camera_info is used only
> by camera_calibration as a convenience, so that you don't have to store the
> calibration to the camera as a separate step.
>
> The request_image service is only for drivers implementing the polled camera
> interface. This is useful for high-def cameras like the 5Mp Prosilica we
> use, as sending those images at frame rate chews up a lot of bandwidth and
> you're unlikely to do any non-trivial processing on them in real time
> anyway. Polled camera support might be nice to have in a generic dc1394
> driver but is hardly a blocker.
>
> image_transport is designed to mimic the core roscpp classes as closely as
> possible, so I hope it is not difficult to integrate. In particular see the
> CameraPublisher convenience class.
>
> Cheers,
> Patrick
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>