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 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 >>>> 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@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >> >