Inconsistent semantics in "position" for reported collision

[SeanCurtis-TRI]

Problem statement

when calling fcl::collide(), configured to return penetration depth, normal, and "contact position", the semantics of contact position differ based on the combination of primitives.

Some quick rhetoric to use when discussing what is happening in the code. When two geometries collide, there is an overlapping region. Generally, we expect the following:

• We define a normal direction for the contact.
• The penetration depth is the greatest thickness of the overlapping region measured in the normal direction. If we slide a line that lies parallel with the contact normal over the intersecting region, we'll create a line segment. The length of the longest line segment is the penetration depth.
• The contact position would lie on the line segment used to determine penetration depth. It could be on either end (in which case it would lie on one colliding surface or the other), it could lie in the middle, or, more generally, anywhere on the segment. It is important that this be consistent so, given penetration depth, normal, and contact position, the corresponding points on the geometry surfaces can be reconstructed.

Survey of primitive-primitive semantics.

• Cases where contact position lies at the midpoint of the line segment:

  • box-box
  • halfspace-sphere
  • halfspace-ellipsoid
  • halfspace-box
  • halfspace-capsule
  • halfspace-cylinder and also here
  • halfspace-cone and also here
  • halfspace-convex
  • halfspace-triangle
  • plane-cone Not obvious, but it appears to be midpoint.
  • plane-triangle Seems to be midpoint.
  • sphere-cylinder
  • sphere-box
  • indep-based general convexity Strongly suggestive of being the midpoint, needs to be confirmed.
  • libccd-based general convexity the semantics is defined by libccd's ccdMPRPenetration() which is documented...vaguely. However, digging into the code, it seems to be the midpoint. This can/should be confirmed.

• Always lies on one surface (i.e., at end point of line segment)

  • halfspace-plane The contact point always lies on the plane's end of the line segment (90% sure on this statement).
  • halfspace-halfspace This looks like a plane, but, to be perfectly frank, it's hard to see meaning in this. When it comes to infinite regions of space, how does one define "penetration depth"?
  • plane-sphere On the plane.
  • plane-ellipsoid On the plane.
  • plane-box On the plane.
  • plane-capsule On the plane.
  • plane-cylinder On the plane.
  • plane-convex On the plane.
  • sphere-capsule. On the sphere.
  • sphere-triangle On triangle.

• Extraneous

  • sphere-sphere: The contact position is a weighted interpolation of the line segment endpoints weighted by the relative sphere radii. So, if the radii are equal, contact position lies in the middle. As one radius goes to infinity, the contact position goes to that sphere's surface.
  • plane-plane Doesn't return contact info.

Proposal

Everything should be pushed up into the mid-point formulation.

Side topic [Added in edit]

In some cases, the query doesn't mean anything. For example, the penetration depth of halfspaces is meaningless because the volumes are infinite; any intersection is, ultimately, an infinite intersection. Conversely, planes have no volume so plane-plane penetration is ill-defined; the depth must always be zero. We need to consider those weird cases and handle them appropriately.

[sherm1]

Sounds like the right plan to me! Would be nice for the returned values always to mean the same thing.

One thing you didn't mention is what happens with non-primitive contact. Are those currently returning the midpoint in all cases?

[SeanCurtis-TRI]

Excellent point; I've modified the text above to the best of my ability.

[ClementRolinat]

hello, it may be off-topic, but it seems that there are some inconsistencies in the returned normal direction as well, I reported the bug here : #422

[tonydangct]

What is the status on this for older versions of the fcl library? I'm still using fcl-0.5 in the MoveIt environment with ROS Kinetic.

[SeanCurtis-TRI]

@ClementRolinat I'm going to respond to #422 there.