:) Ok. So in any case, please let me know when the driver is complete and published so I can remove the other one. I hate clutter. :) Patrick Beeson wrote: > 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 -- | Radu Bogdan Rusu | http://rbrusu.com/