Generalize hydroelastic contact to arbitrary, externally createable, tetrahedral meshes

[arvismay]

Before you post:

• Have you reviewed the documentation on Getting Help?
• Have you reviewed existing GitHub issues and StackOverflow posts?
• Have you rerun install_prereqs.sh on your current commit of drake?

If you have encountered a bug (installation, segfaults, etc.), please try to post reproduction steps and as much relevant output as possible. Consider posting long snippets as a Gist.

[arvismay]

Generalize hydro-elastic collision mesh and pressure field to handle arbitrary tetmesh created in external tetrahedralizers like tetgen or tetwild. Possibly decouple the collision mesh from the pressure field so that the pressure field elements can be denser than the collision mesh elements.

[SeanCurtis-TRI]

To clarify, there are two good suggestions here. But they are largely independent and it's worth separating them.

• Externally generated compliant meshes: The ability to generate an arbitrary tetrhedral mesh with its accompanying pressure field, load it directly into drake.
  • This has certainly been discussed in the past and it would certainly provide a great deal of flexibility.
  • Tasks to implement:
    • Need to adopt some conventional file format (preferably not bespoke) that can represent the data appropriately.
    • Need code to parse said file format.
    • Need to validate the pressure field to make sure it is suitable for hydroelastic.
      • The definition of "suitable" needs to be given some thought. Possible requirements:
        • 0 on the surface
        • internal values in the range (0, 1]
      • It is not clear if we require a single detectable rigid core (a contiguous region where all values are 1), or whether a single geometry could have multiple rigid cores.
    • Increase URDF/SDF specification to allow file references.
• Multi-resolution pressure fields: The collision mesh and pressure mesh can be different resolutions
  • This hasn't been previously considered.
    • We have considered creating "layers" of tetrahedral volumes such that each "ring" of mesh has a different "slope" in the stress function. The function over the whole tetrahedral volume would be a continuous, piecewise function.
  • The apparent advantage of this alternate proposal is that we can still do contact with as sparse a mesh as possible, but in the domain of a single tet, model a more complex pressure field (still as a piecewise linear function).
  • This is, in fact, not true.
    • Because the hydroelastic contact surface is the equilibrium surface where two pressure fields overlap, we'd actually be subject to the resolution of the high resolution pressure field. The coarser collision mesh won't enter into it.
      • At best this could serve as a hierarchical, level-of-detail style optimization. To do so, the high resolution pressure field would have to be constrained to "match" the coarse pressure field. The high resolution pressure field would still have to be monotonically increasing over the common domain and should have the same Image (in the "function" sense) as the coarse domain.

Therefore, the primary recommendation of this issue: externally generated hydro meshes, is achievable. The second idea, not so much.

[arvismay]

I think I phrased the second idea incorrectly. It still might not be a great idea, but here's an attempt at rephrasing it.

It could be useful to decouple the definition of the pressure field from the collision mesh. The pressure field could be a higher or lower res embedded mesh, or even a signed distance function. The collision mesh still serves as the actual mesh on which the equilibrium pressure is calculated. Decoupling allows the user to update the collision mesh while leaving the pressure field the same.

[SeanCurtis-TRI]

We might be talking about two slightly different problem domains: hydroelastic algorithm evaluation and input parameter generation.

Hydroelastic algorithm evaluation

In this context, I interpret what you say as an attempt to decouple two things that cannot be decoupled. The algorithms for finding the contact surface are tightly coupled with how a pressure field is represented within each tetrahedron. Currently, the algorithms have some prerequisites:

• All values within the domain of the tetrahedron are a convex combination of the field values at the tetrahedron's vertices.
  • More particularly, the weights of the convex combination are the barycentric coordinates of the internal vertex w.r.t. the tet.
• Within a tet, the field is strictly linear.
  • By this, we can look at two tets and quickly determine the strictly planar portion of the contact surface attributable to the overlapping pressure fields in the corresponding pairs of tets.

This represents a degree of coupling that defies a higher order of abstraction between "mesh" and pressure field.

It is distinctly possible to decouple them, in principle. However, that would require novel implementations of what it means to find the equilibrium between two arbitrary pressure fields contained within two overlapping tetrahedral volumes. It will no longer be strictly planar, and the search for it becomes far more expensive.

Input parameter generation

It's certainly possible to have an abstract pressure field functor. And then, given some arbitrary mesh, the pressure field could be sampled at each vertex by evaluating the pressure field. The end result would still be a piecewise-linear approximation of the function within the domain of a tetrahedral mesh. And that is ultimately the input to the hydroelastic algorithms. So, if this approach were taken, it would most likely happen offline (outside of the Drake library) and be supported by Drake simply loading the resultant explicit hydroelastic mesh definition.

[SeanCurtis-TRI]

@DamrongGuoy Would you consider this is largely closed due to the PR train ending in #17837?

One of the concepts seems clearly resolved (externally generated tet mesh used as a compliant mesh). The other concept (some alternative modeling of the pressure field), isn't part of that. However, this issue doesn't do a good job of defining the requested feature.

It seems to me that we can close this. If rethinking the pressure field becomes relevant in the future, we can either re-open this issue or open a new issue with just that topic.

[DamrongGuoy]

I agree that we can close this issue now.

I add that now we have an example to use an externally created tetrahedral mesh at:

https://github.com/RobotLocomotion/drake/tree/master/examples/hydroelastic/python_nonconvex_mesh

The yellow bell pepper uses a tetrahedral mesh imported from VTK file generated externally by TetGen as shown here:

      <collision name="collision">
        <pose>0 0 0 0 0 0</pose>
        <geometry>
          <mesh>
            <uri>yellow_bell_pepper_no_stem_low.vtk</uri>
            <scale>1 1 1</scale>
          </mesh>
        </geometry>
        <drake:proximity_properties>
          <drake:compliant_hydroelastic/>
          <drake:hydroelastic_modulus>5.0e4</drake:hydroelastic_modulus>

https://github.com/RobotLocomotion/drake/blob/b277f59cb44649c12b1899c4d4917d53166d5ff0/examples/hydroelastic/python_nonconvex_mesh/pepper.sdf#L27-L47