[ros-users] accelerometer and tilt support + depth function
stephane.magnenat at mavt.ethz.ch
Tue Nov 16 09:04:42 UTC 2010
> 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
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
> 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 . 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
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.
Dr Stéphane Magnenat
More information about the ros-users