[ros-users] Digital Camera 1394 in ROS?

[Patrick Beeson]

Scratch that.  I just looked at the code for the first time in a
while, and my ROS SR4K node does in fact build off of your ROS SR3k
code (not my Player sr4k extension).  The changes are: uses the new
Mesa API, works with ros 0.9 (no private nodes), and I changed the
coordinate system to by consistent with others we use internally (this
is easy to change back to typical image coordinates).  Again, when I
get some down time, I'm willing to work to get this using
image_transport, but right now is simply publishes sensor_msgs
PointCloud and Image types.

On Wed, Mar 10, 2010 at 10:56 AM, Patrick Beeson <beeson.p at gmail.com> wrote:
> It builds off of your Player SR3K driver.  There's a swissranger in Player
> now that supports the 4K and the new Mesa library API for 3k/4k devices.  My
> ROS one basically has the same guts as the Player one. This is a bit
> different from your ROS sr3k driver, but works quite well.  It could stand
> to be updated to use image_transport and needs a some tf info, but we could
> open source it (considering it's largely based off your Player code anyway).
>
> Radu Bogdan Rusu wrote:
>>
>> Patrick, is your SR4k driver different than the one that I wrote some time
>> ago ? (http://www.ros.org/browse/details.php?name=swissranger) If so, I
>> would like to merge/deprecate that, provided that you will release yours as
>> open source.
>>
>>
>> Patrick Beeson wrote:
>>>
>>> FYI,
>>>
>>> I have my own ROS node that combines cameradc1394 with the Player 1394
>>> driver.  It works very reliably and depends on nothing but sensor_msgs (I
>>> have to say that I do not like having to download the kitchen sink just to
>>> get a simple hardware driver working, which is why I have my own versions of
>>> Swissranger 4K driver, 1394 camera, etc.).
>>>
>>> Jack has been using it, along with a visualization tool I forked from
>>> somewhere.  I think I'll work with Jack to get this added to his ROS
>>> repository, or start my own (I'm assuming a reliable Swissranger 4000 driver
>>> would be of desire to someone out there).  But, I should go ahead and make
>>> it start using the image_transport package.  So, it'll probably be a few
>>> weeks before this shows up in the ROS package browse.
>>>
>>>
>>>
>>>
>>> Jack O'Quin wrote:
>>>>
>>>> On Wed, Mar 10, 2010 at 9:29 AM, Rosen Diankov <rosen.diankov at gmail.com>
>>>> wrote:
>>>>>
>>>>> I'm sorry you've been having so many problems with cameradc1394,
>>>>> perhaps we can come up with a solution that will work well for you.
>>>>
>>>> Thanks, Rosen.
>>>>
>>>> I do not mean to come across as harshly critical of cameradc1394. I
>>>> appreciate the work that has gone into it, and want to make it more
>>>> accessible to users. We are trying to get undergraduates working
>>>> productively with ROS vision components. Many of them are unfamiliar
>>>> with both ROS and Linux. They will have a lot more trouble getting
>>>> this working than I did.
>>>>
>>>>> - You say it seems to work but not easy to install? Typing 'rosmake
>>>>> cameradc1394'  should make and install everything for you, so are you
>>>>> having trouble compiling things?
>>>>
>>>> I did get it to work. It just took me a couple of hours. See below...
>>>>
>>>>> - i think the libdc1394v2 package is for systems that do not have
>>>>> libdc1394 version 2 installed, otherwise the library itself should be
>>>>> stable.
>>>>
>>>> On a recent boxturtle ROS install, the rosmake will fail because
>>>> cameradc1394 depends on libdc1394v2, which is no longer being
>>>> distributed. So, users either have to edit your manifest.xml to remove
>>>> that dependency (which is still needed on Ubuntu Hardy), or they have
>>>> to find and install the SVN repository for the
>>>> camera_drivers_experimental package (doable, but not trivial).
>>>>
>>>>> - cameradc1394 links the the ROS image libraries in order to
>>>>> serialize/convert the message correctly, display the image, and
>>>>> undistort it (radial distortion). You can disable the display
>>>>> dynamically, so the the only other place where opencv would be used is
>>>>> for undistortion and sending messages. Fortunately, both of these are
>>>>> not that heavy on computation, so your system should handle it.
>>>>
>>>> I am not particularly worried about computational overhead. It's more
>>>> a question of system design and consistency.
>>>>
>>>> The other ROS camera drivers do not depend on opencv2. There are
>>>> higher-level packages, such as image_view for that sort of function.
>>>> I'd prefer a simple DC1394 driver that behaves like the other ROS
>>>> camera packages. That way people can work consistently with all those
>>>> devices.
>>>>
>>>>> - i'm pretty sure the svn checkout command on sourceforge points to
>>>>> the correct code:
>>>>> svn co https://cmu-ros-pkg.svn.sourceforge.net/svnroot/cmu-ros-pkg
>>>>> cmu-ros-pkg
>>>>>
>>>>> The 'trunk' folder might be making things a little confusing for you,
>>>>> therefore i recommend:
>>>>>
>>>>> svn co
>>>>> https://cmu-ros-pkg.svn.sourceforge.net/svnroot/cmu-ros-pkg/trunk
>>>>> cmu-ros-pkg
>>>>
>>>> As you say, that is the correct URL for checkout. This error is
>>>> currently not important, because you have no other branches (so far).
>>>> But, you would not want users accidentally checking out *all* the
>>>> branches instead of just the mainline version. When there is a stable
>>>> version, they should check out branches/latest, instead, I suppose.
>>>>
>>>>> - There is a link on the ros.org camera_drivers webpage
>>>>> (http://www.ros.org/wiki/camera_drivers) into the correct wiki
>>>>> location where the cameradc1394 webpage is stored. I'm not sure why
>>>>> you feel it is hard to locate.....
>>>>
>>>> It would be easier to find under http://ros.org/wiki/cameradc1394
>>>> (which does not exist). It was hard to find because the SourceForge
>>>> page for cmu-ros-pkg does not point to it. I did eventually find a
>>>> pointer to it at the bottom of http://ros.org/wiki/libdc1394v2 (which
>>>> does exist).
>>>>
>>>>> - the README in the top source directory was old and contained nothing
>>>>> useful, i just deleted it
>>>>
>>>> Good idea, thanks.
>>>>
>>>>> - I think you are the first person that has expressed dissatisfaction
>>>>> with the way cameradc1394 is structured (no code reviews, etc), I've
>>>>> tried to stick with the camera API willowgarage publishes as much as
>>>>> possible. In the past year, it has been hard to keep up with it due to
>>>>> many changes, but we're actively maintaining cameradc1394. For
>>>>> example, I just noticed that the API requires a "set_camera_info" and
>>>>> "request_image" services, which we will add as soon as we have time.
>>>>
>>>> I fully understand the difficulty of tracking rapidly changing
>>>> interfaces in a complex system. That is why I favor better integration
>>>> into the ROS development process.  I believe a design review would
>>>> have identified the inconsistencies between cameradc1394 and the other
>>>> ROS camera drivers.
>>>>
>>>> A good review might have caught the set_camera_info change, as well. I
>>>> have so far been unable to display 1394 camera images with rviz. That
>>>> may be the reason.
>>>>
>>>>> If it makes a big difference for your team that the cameradc1394
>>>>> resided on WillowGarage's servers rather than sourceforge's, then I'm
>>>>> sure WillowGarage would be happy to host it.
>>>>
>>>> I expect they would. I don't see the repo location as a problem right
>>>> now (as long as the checkout URL is correct and up to date).
>>>>
>>>> I believe including good documentation into the ros.org wiki would
>>>> make the package much more accessible to beginning users. I am willing
>>>> to assist, if you feel that would be helpful. I don't know much about
>>>> digital cameras, but I do know how to edit the wiki. :-)
>>>>
>>>> Regards,
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>
>