search

RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.35k stars 1.27k forks source link

Collision model algorithms assume convexity #4548

Closed SeanCurtis-TRI closed 7 years ago

SeanCurtis-TRI commented 7 years ago

We have a number of methods implemented in bullet_model.cc which inherently assume that the meshes involved are convex:

We want to support non-convex meshes. Initially, the intent is to support them as anchored meshes. However, until these algorithms are made smarter to account for convex/non-convex collisions we cannot introduce non-convex collision elements.

edrumwri commented 7 years ago

Is there indeed such a plan for nonconvex support? Would you share? Do these meshes represent solids, or are they non structured?

On Mon, Dec 19, 2016 at 4:47 PM Sean Curtis notifications@github.com wrote:

We have a number of methods implemented in bullet_model.cc which inherently assume that the meshes involved are convex:

  • BulletModel::collisionDetectFromPoints

  • BulletModel::findClosestPointsBetweenElements

We want to support non-convex meshes. Initially, the intent is to support them as anchored meshes. However, until these algorithms are made smarter to account for convex/non-convex collisions we cannot introduce non-convex collision elements.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/RobotLocomotion/drake/issues/4548, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHwz-QtJ517NwLsvQHRWZ_LKZ4oVbNLks5rJyW3gaJpZM4LRWHM .

SeanCurtis-TRI commented 7 years ago

There is indeed a current plan for limited non-convex support. Specifically, for anchored geometry (e.g., terrain.) We don't have a concrete plan for non-convex, dynamic collision geometry. Currently, we rely on convex decomposition in these cases.

edrumwri commented 7 years ago

Ok, sounds very reasonable!

On Tue, Dec 20, 2016 at 7:11 AM, Sean Curtis notifications@github.com wrote:

There is indeed a current plan for limited non-convex support. Specifically, for anchored geometry (e.g., terrain.) We don't have a concrete plan for non-convex, dynamic collision geometry. Currently, we rely on convex decomposition in these cases.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/RobotLocomotion/drake/issues/4548#issuecomment-268267450, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHwz61aD2aHQ9pVjclH1G2UWlXvTHcLks5rJ_AsgaJpZM4LRWHM .

amcastro-tri commented 7 years ago

Please take a look at related #2004. Also notice concave terrains were supported in #2697.

SeanCurtis-TRI commented 7 years ago

I would suggest that #2697 is inherently flawed. Exactly because of the two queries listed above.

If those queries had ever been run on a scene with static geometry, the bug would have already been revealed. But we were saved by the fact that static geometry wasn't being properly recognized. So, while it's true, #2697 offered support for concave terrains, that support is limited and has intrinsic landmines.

What must happen is that these two queries must be fixed to no longer blithely assume that all objects are convex.

SeanCurtis-TRI commented 7 years ago

When this is addressed, it is important to modify the tests in model_test.cc so that it more robustly tests the execution of static geometry code path.

Specifically, the geometry being made static should be explicitly non-convex so that it is clear that there is a different answer when properly convex vs. the convex hull.

SeanCurtis-TRI commented 7 years ago

4554 provides a tentative and incomplete solution. For the two queries, distance between point-object and object-object are, in some sense, "ignored" if the object is non-convex. This allows non-convex geometry to be introduced into the system where it behaves will in contact computation.

It became quickly apparent that there is no meaningful way to perform this query using Bullet. Bullet's underlying infrastructure determine collisions such that if two objects are not colliding, there is nothing interesting to say about them. These two methods are, essentially, evaluations of per-object distance fields; Bullet was not designed to do this. So, it will require bespoke functionality.

Furthermore, there is some complexity in solving this "properly". The distance function to a non-convex object has limited smoothness. Properly implemented it can guarantee c0 continuity, but can't guarantee anything higher. We'll want to make sure that this is sufficient.

One of the implications of the "solution" in #4554 is that we won't be able to query the distance between points and non-convex terrain objects (e.g., a mesh of uneven terrain). It will work for representations of the ground as boxes. It won't effect contact computation or ray casting.

SeanCurtis-TRI commented 7 years ago

Dynamics team status - what it will take to close this:

There is no quick fix on this. We'll close it until this presents a known problem.