Visualize hydroelastic meshes

[SeanCurtis-TRI]

Problem

In the hydroelastic contact model, declared primitives types (e.g., spheres, cyliders, etc) are represented with a tessellated mesh. The amount of tessellation can depend on a configuration parameter and the resulting meshes (particularly if coarse) can deviate significantly from the idealized primitive. This has been known to lead to surprised users unable to interpret the contacts they are (or aren't) seeing. Being able to see the actual mesh involved in the contact can help users reason about the behavior they observe.

Solution

Ultimately, we'll allow users to configure visualizers in a way that they can declare they'd like to visualize hydroelastic meshes, where available.

This branch contains the "full" solution (as full as can be at any given time). The branch will be rebased frequently and pulling a local copy should bear this in mind.

The plan

• [x] The python path
  • [x] #15707
    • [x] #15762
    • [x] #15773
• [ ] The C++ path
  • [x] #15739
  • [x] #15772
  • [ ] Enable MeshcatVisualizer (in meshcat_visualizer.h) to visualize hydro geometry. This is not defined in the branch linked above yet.

[jwnimmer-tri]

Transcribing some notes from f2f discussions... hopefully I understood it correctly

The most important visualization is the contact patch mesh. In the typical case, most users prefer to turn off pressure field visualization.

Thus, doing the patch mesh into MeshCat first would be the priority.

[jwnimmer-tri]

Some quick thoughts for @joemasterjohn about where I left this.

I was focusing on visualizing contact results, instead of the tessellated primitives. I think that's more important.

Also, I was focusing on meldis more than within-simulation of a drake::geometry::Meshcat object. Our standalone demos use meldis; only notebook tutorials use an in-process Meshcat object.

The class drake::multibody::meshcat::ContactVisualizer in drake/multibody/meshcat/contact_visualizer.h is what publishes the plant's contact results output port directly into a Meshcat. This class is only useful for in-process Meshcat (i.e., notebooks), but should still be adapted to add hydro.

As with the already-implemented point contacts, the ContactVisualizer for hydro should implement by delegating into a helper class that doesn't depend on struct ContactResults directly. That way, meldis can re-use the helper class without needing to populate a ContactResults object.

That hydrocontact-meshcat helper class can offer buttons and sliders to change what is being displayed, similar to the configuration dialog in the drake-visualizer hydro contact control panel.

It's totally valid to change (i.e., replace) the contact-results-related lcmtypes if that makes anything here easier.

[rpoyner-tri]

@joemasterjohn are you still working on this?

[jwnimmer-tri]

As best I can tell, the only remaining work here is to finish these TODOs:

https://github.com/RobotLocomotion/drake/blob/6a5fb5acc19f937e9b08175838c09a6b1abde45d/visualization/visualization_config_functions.cc#L51-L52

https://github.com/RobotLocomotion/drake/blob/6a5fb5acc19f937e9b08175838c09a6b1abde45d/bindings/pydrake/visualization/_meldis.py#L336-L346

[jwnimmer-tri]

My hypothesis is that #20179 has solved this. Could either @joemasterjohn and/or @SeanCurtis-TRI please check and confirm, and close if so?