[ros-users] accelerometer and tilt support + depth function

[Nicholas Butko]

Ivan, 

I just plugged a Kinect into my laptop for the first time five minutes ago, and it was beautiful. It's amazing how quickly tools are being developed, and we're thankful to everyone who has been developing them. 

To speak for my lab, a useful driver would have the following capabilities, roughly ordered by priority

1. Compatibility with OSX. 
2. Easy to get images RGB & Depth images into OpenCV for processing. 
3. BSD license. 
4. Stability.
5. Ability to control tilt.
6. Computational efficiency.
7. Accurate depth / image registration. 

Basically, from our point of view it is most important to have a solid foundation and low level access to the device. This foundation allows for the most flexibility. It is also important to be flexible with the code we write (which is why BSD license is a high-ish priority). Features like calibration and registration are wonderful, but secondary. 

I am quite busy right now, but in December I will have more time and freedom to work on other projects. If you need help developing or checking OSX compatibility, I will be happy to help. 

--Nick 

On Nov 15, 2010, at 10:37 AM, 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
> <ivan.dryanovski at 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 at 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 at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>> 
>> 
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users