It sounds like our goals are fairly similar, so I would definitely be interested in combining efforts towards a common driver. I have only looked at Oliver Kreylos's driver briefly so far, but I agree that it looks very nice. Perhaps we should consider setting up another email list for working on this, so we don't spam ros-users too hard with Kinect related discussion? On Mon, Nov 15, 2010 at 1:37 PM, Ivan Dryanovski wrote: > Stéphane, > > We had a discussion at the lab about where we are headed with the ROS > driver. As you pointed out, having different versions of the driver is > not harmful, but not particularly practical either. Would you (as well > as Alex Trevor, Stefan Kohlbrecher, and anyone else) be interested in > moving towards a common ROS driver? > > We are mostly interested in developing the following features: > > * speed and stability - we'd like to see this run on less powerful > computers in the future > * clean, object-orient API > * geared towards easy, accurate calibration between the depth and RGB > data, so we can produce color-coded clouds > * accurate range calibration, preferably with variance values and/or a > confidence map > * PCL compatible > * documented, ideally follow the ROS style guide > > Anything else (accelerometers, motors, microphones) is less important > to us, but of course it would be nice if the driver handles it. > > If we move towards a common driver for ROS, what is the community's > opinion on the underlying hardware driver? There are three different > options available right now: Hector Martin's libfreenect and Oliver > Kreylos' driver [1]. There currently appears to be some speed and > stability issues with libfreenect. Oliver's driver seems to be more > object-oriented and better documented, but it has a lot of system > dependencies to deal with. The third option would be rewrite a driver > from scratch, under a BSD license. > > Ideally, we can host this as a separate repo on github, with major > contributors given write access,l so we don't have to deal with > patches. > > Let us know what you think > > Ivan Dryanovski > William Morris > > [1] http://idav.ucdavis.edu/~okreylos/ResDev/Kinect/ > > > > On Mon, Nov 15, 2010 at 12:21 PM, Ivan Dryanovski > wrote: > > Hi Stéphane, > > > > I will take a look at your depth function and see how it works for us. > > Thank you for sharing it! > > > > As for the naming conventions, we are currently using two different > > frames for the two cameras - kinect_rgb and kinect_depth. > > > > Ivan > > > > 2010/11/15 Stéphane Magnenat : > >> Hello, > >> > >> I have integrated the accelerometer and tilt support from adafruit [1] > >> into my kinect node. To do so, I have added them to libfreenect, for > >> which I now provide a git with my changes instead of patches in my > >> kinect node [3]. > >> > >> Here at ASL, Deon Sabatta and Davide Scaramuzza have found a more > >> precise depth function than 1/x. It is the following: > >> > >> depth = k3 * tan(pixVal/k2 + k1) > >> > >> where > >> > >> k1 = 1.1863 > >> k2 = 2842.5 > >> k3 = 0.1236 > >> > >> "The k2 value is very sensitive and may require more/better > >> measurements; however, this is a pretty good approximation for the > moment." > >> > >> I would like to raise two questions: > >> > >> 1. Having multiple implementations of Kinect ROS nodes is not harmful as > >> we happily share code. However, to ease the end-user's life I think that > >> we should agree on a naming convention for node and topic naming. Here > >> is a first suggestion: > >> node name: "kinect" > >> point cloud frame: "/kinect" > >> point could topic: "/kinect/cloud" (PointCloud + color in "rgb") > >> rgb image topic: "/kinect/image" (Image, rgb) > >> depth (raw in 8bpp) image topic: "/kinect/depth_image" (Image, mono8) > >> accelerometer topic: "/kinect/acc" (Vector3) > >> tilt input: "/kinect/tilt" (Int16) > >> Feel free to discuss it and propose more conventions, for instance for > >> the params/etc. > >> > >> 2. I have branched libfreenect to provide updates more easily to the ROS > >> community, but I do not want to fork it. Hector, your input is warmly > >> welcome on my changes. Currently, libfreenect is not reentrant and does > >> not have clean naming prefixes. The reentrance might require a bit of > >> thinking, but the naming is straightforward; do you agree if I put a > >> heading kinect_ before all public functions? > >> > >> I'm looking forward to hearing your comments, dear kinect hackers. > >> > >> Kind regards, > >> > >> Stéphane > >> > >> [1] https://github.com/adafruit/Kinect > >> [2] > https://github.com/ethz-asl/ros-drivers/tree/master/microsoft_kinect/ > >> [3] https://github.com/stephanemagnenat/libfreenect > >> > >> -- > >> Dr Stéphane Magnenat > >> http://stephane.magnenat.net > >> _______________________________________________ > >> ros-users mailing list > >> ros-users@code.ros.org > >> https://code.ros.org/mailman/listinfo/ros-users > >> > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >