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

[Stéphane Magnenat]

Hi,

> 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?

Yes.

> 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

I completely agree with you on these points. I would add:
* minimise dependencies, one does not want to install GL on an embedded 
platform. Optional dependencies that add features/helper programs are ok.
* complete support of Kinect's features.
* avoid over-engineering, as we want the driver to be straightforward to 
understand.

> Anything else (accelerometers, motors, microphones) is less important
> to us, but of course it would be nice if the driver handles it.

I think that completeness is important to avoid divergence of code base.

> 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.

Hector told me yesterday that he is currently rewriting libfreenect and 
that the new version should be out in a day or two. I would choose the 
driver with the least dependencies to ease deployment on embedded 
platforms. I would avoid rewriting a new driver if possible.

> 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.

Yes, having a lab-neutral repository will facilitate things. How to call 
it? Should we create an organisation such as 
"ros-collaborative-drivers", which would contain a stack of the same 
name and a kinect driver in it? Or is it too wide and should we restrain 
to kinect only? I think that the situation we face now will become more 
and more common, so having infrastructure to handle this will ease 
collaboration in the future.

About the naming of the driver, in mine I use the convention 
VENDOR_PRODUCT which results in microsoft_kinect. Is there a ROS 
convention for this?

I agree that once we have taken the strategic decisions, we should set 
up a mailing list to discuss the technical details.

Kind regards,

Stéphane

-- 
Dr Stéphane Magnenat
http://stephane.magnenat.net