[ros-users] Digital Camera 1394 in ROS?

[Jack O'Quin]

On Mon, Mar 15, 2010 at 11:44 PM, Patrick Mihelich
<mihelich at willowgarage.com> wrote:
> On Mon, Mar 15, 2010 at 10:03 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:
>>
>> Initial check-in for ROS port of Player camera1394 driver committed to
>> ros-pkg/trunk/stacks/camera_drivers_experimental/camera1394.
>
> Excellent, thanks for your work on this.

Thanks for responding, Patrick.

As you can see, I've got a lot of questions about this stuff. :-)

>>  * The code is GPL due to the Player driver license
>
> We strongly prefer the BSD license, especially for components like this one
> that are likely to see wide use. Even if there is an excellent GPLed dc1394
> ROS driver, some users will be compelled to write their own to avoid the
> licensing issues.

That's what I figured. But the existing WGE100 driver is GPL
(apparently because of one file). I just wanted to get a feel for what
priority various people assign to this issue.

Maybe the Player authors will agree to re-license our version. I feel
sure Patrick Beeson would agree.

>>   * It publishes CameraInfo and rviz can display images, but rviz
>> complains about a bad P value (projection matrix).
>>
>> This matrix is not being set in the driver. Should it be? Is there a
>> useful default value? Or, is that always handled later in the
>> image_pipeline?
>
> For monocular cameras you should set:
>  * R (rotation matrix) to the 3x3 identity matrix.
>  * P (projection matrix) to K (camera matrix) with a column of zeros
> appended.

Thanks. I'll give that a try.

>>   * There is Bayer decoding in the driver.
>>
>> Is that OK, or is this only supposed to be done later in the
>> image_pipeline?
>
> In the other drivers we've opted not to do any bayer decoding, leaving that
> to image_proc / stereo_image_proc. For consistency I'd say the image_raw
> topic should be the raw (bayer) data straight from the camera. If you want
> to do bayer decoding in the driver I would make that a separate topic.

Makes sense. We want it to function as a drop-in replacement for the
Ethernet camera drivers.

Personally, I'm OK with removing the Bayer code from the driver
altogether. Less to test and maintain.

But, there may be good reasons to include it as an option. This is
where I could use some technical advice from those with more computer
vision experience.

>>   * Should this package be supported on Mac OS X?
>
> I'm sure Mac users would appreciate it :). If you don't have a Mac to test
> with perhaps someone else can do that.

I think it *should* be supported on OS X, as long as that is feasible.

While I can get access to a Mac and might be able to get the code
working there, I am not a Mac guy and don't know the secrets of fink
and macports and the the Mach-o linker. Running an occasional test on
a platform I don't use regularly would not be adequate.

To be fully supported, we'd need (1) help writing and testing <rosdep>
stanzas; (2) people who run the code regularly on that platform; and
(3) at least one tester to try out new versions before releases of
both ROS and OS X.

If that's not feasible, we could provide partial support on an "if you
tell us it's broken we'll try to fix it" basis, I suppose.
-- 
 joq