Inaccurate contact results from Bullet collision detector for falling objects

[mxgrey]

---

Bug Report

Please answer the following questions for yourself before submitting an issue.

• [x] I checked the documentation and found no answer.
• [x] I checked to make sure that this issue has not already been filed.

Environment

• Select DART version: 6.7
• Select OS name and version name(or number): Ubuntu 18.04
• Select compiler name and version number: GCC-8

Expected Behavior

When an object falls onto a surface (e.g. a sphere falls onto a plane) it should settle into place such that the object is just barely touching a surface (within some reasonable tolerance).

Current Behavior

When an object falls onto a surface, the Bullet collision detector reports contacts that are above the surface. As a result, objects that fell will settle into a position where they are hovering over the surface.

Note that if the object starts in contact with the surface but has no initial velocity, this phenomenon does not happen, even with gravity pushing the object down into the surface.

Steps to Reproduce

A regression test can be found in #1185

[mxgrey]

I'm noticing that in the sphere-plane tests, the collision detector is returning exactly one contact point every time step, and that one contact point remains the same from the very first time it gets computed. This makes me wonder if the issue could be related to #859 which seems to have something to do with making contact points persistent. Edit: Ignore this remark.

[mxgrey]

I've noticed that the penetration depth from the contacts report here will come out negative for bodies that are moving towards each other close enough together. When a point has a negative penetration depth, it will be located on an object that is not actually in penetration yet, but perhaps moving towards a penetration. If I filter out points that have a negative penetration depth value, then this issue disappears.

One brute force solution could be to throw away contact points that have negative penetration depth. However, I think that would be losing valuable information, since we could instead use these points to avoid problems like excessive penetration and phasing. I'll take a look at the collision handling code to see if I can identify a way to leverage negative penetration information, although I'd appreciate any and all guidance on that, since it's a part of the codebase that I'm not familiar with.

[mxgrey]

Also this may be related to what @karenliu has said about Bullet collision detector reporting collision points that are outside of the collision bodies.

[mxgrey]

I've chosen the simple option of ignoring contact points with negative penetration depth for now. We can always improve the constraint solving in the future if we want to leverage the proximity information somehow.

Some more questions to consider: Should we also filter out these phantom contact points when providing contact results to the user? And should we watch out for false negatives when the collision detector is being queried for a true/false response to whether there are collisions?

[jslee02]

Some more questions to consider: Should we also filter out these phantom contact points when providing contact results to the user? And should we watch out for false negatives when the collision detector is being queried for a true/false response to whether there are collisions?

Quick thoughts: We could have an option in CollisionOption for that (whether or not to include contacts with negative penetration if available).