[ros-users] Collision detection

Madhani, Akhil J Akhil.J.Madhani at disney.com
Tue May 18 16:51:14 UTC 2010


Hi Gil,

We're investigating as well, so these are initial thoughts.  In terms of
features, our environments (at the moment) are simple and can be largely
modeled with meshes or primitives.  However, the systems are moving
somewhat quickly (~2 m/s).  If computational speed is an issue, I
imagine it will be because of arm speed, not model complexity.  For the
same reason, we are interested in proximity (and relative velocity)
queries as well.  Robustness will determine what role collision
detection can play within a hazard analysis/mitigation scheme.

Thank you,
Akhil.


Akhil J. Madhani 
(818) 553-6839 office 
(818) 641-4481 cell 
akhil.j.madhani at disney.com
------------------------------

Message: 4
Date: Mon, 17 May 2010 17:59:44 -0700
From: Gil Jones <gjones at willowgarage.com>
Subject: Re: [ros-users] Collision detection
To: ros-users at code.ros.org
Message-ID:
	<AANLkTim1IwP8vk2-hJGCu4xGQaFd2YQqAUgkSAgKJVDo at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Akhil,

This is actually something we've just started to seriously think about.
At
this point we don't do any continuous collision detection in our primary
collision checking implementations, though Bullet supposedly can do it.
We've mostly been using ODE.  But you are right that a lot of the work
in
collision checking doesn't really address the needs of the robotics
community.  We're currently starting some collaboration with a goal of
optimizing for several criteria that are important for our work here.
One,
we have large point clouds coming from our lasers and stereo pairs at
high
rates that we need to check collisions against; most of the existing
collision checkers are not necessarily optimized for this, as the
graphics
community generally have meshes.  We do have meshes for some things and
also
need that functionality.  Second, our robots currently don't have GPUs
but
they do have a number of CPU cores which can potentially be utilized, so
we
are interested in speedups through parallelism; we will likely explore
GPU
implementations at some point in the future.  Third, we want to be able
to
do proximity queries and not just binary collision/not collision
queries.
Finally, for some things we do need continuous collision detection, and
an
efficient implementation would be useful.  To our knowledge no existing
library fits our needs perfectly, and thus we are in the process of
figuring
out a short path to a library that will hopefully fill both our and the
community's needs.  And we will do a good deal of testing on the robots
to
show robustness.

If you or others have input on the kinds of features you want in a
collision
checking library we'd be very interested.  And as any new libraries
become
available we'll certainly make folks aware.

-Gil

E. Gil Jones (gjones at willowgarage.com)
Research Engineer
Willow Garage, Inc.
68 Willow Road
Menlo Park, CA 94025
650.475.9772


On Mon, May 17, 2010 at 5:26 PM, Madhani, Akhil J <
Akhil.J.Madhani at disney.com> wrote:

> I am wondering if there a consensus regarding continuous collision
> detection algorithms/libraries amongst the ROS community?  Bullet,
> ODE..?  What other libraries have been reviewed (e.g. Swift++)
>
> Since these has been developed for gaming/CG, robot folks have to ask
> about robustness: Are there any benchmarks for reliability?
>
> Thanks,
> Akhil
>



More information about the ros-users mailing list