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
<
ivan.dryanovski@gmail.com>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/<http://idav.ucdavis.edu/%7Eokreylos/ResDev/Kinect/>
>
>
>
> On Mon, Nov 15, 2010 at 12:21 PM, Ivan Dryanovski
> <ivan.dryanovski@gmail.com> 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 <stephane@magnenat.net>:
> >> 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
>
(text/plain)