RobotLocomotion / drake

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

Support fine grain (geometry level) contact force reporting #9125

Closed rcory closed 4 months ago

rcory commented 6 years ago

Description

We have an MBP with multiple bodies. One body has multiple collision geometries associated with it. For instance, say we have a body named "my_body" with two associated collision geometries named "my_body_collision_1" and "my_body_collision_2" and a second body named "other_body" with a single collision geometry named "other_body_collision". Now assume that both "my_body_collision_1" and "my_body_collision_2" are in contact with "other_body_collision". When visualizing contact results in drake_visualizer these contacts are reported using body names and not geometry names, i.e., for our example above, we would see a single contact result reported as (my_body(1),other_body(1)). It is useful to have lcm contact results be reported on a per-collision-geometry level such that collision geometry names are included in the contact results. For the example above, we would see two contact result reported as (my_body(1)_my_body_collision_1, other_body(1)_other_body_collision) and (my_body(1)_my_body_collision_2, other_body(1)_other_body_collision).

SeanCurtis-TRI commented 6 years ago

Further description

This happens because the lcm contacta results associates quantities with (body name1, body name 2) pairs. For bodies with multiple collision geometries, each geometry will still be registered with the same body-name-pair. The python script that handles the visualization performs aggregation -- so all contact forces associated with the same name pair are put into a single body-body-named object.

Proposal

In drake_visualizer, instead of having (body1, body2) display with all contact forces, we'll break them down per collision geometry pair. We'll do that by changing the names to (body1 - geometry name, body2 - geometry name).

Implementation

  1. :heavy_check_mark: Geometry names: I have a PR in flight that will introduce geometry names - for both collision and visual geometries. This will provide the fodder for distinguishing contacts. (Resolved in #9147)
  2. Getting the name to the LCM message: The ContactResults data structure will be extended to provide collision object names. The MBP will populate this additional data.
  3. Including the name: ContactResultsToLcmSystem will use the collision object name in the ContactResults data and encode it into the contact name.
SeanCurtis-TRI commented 4 years ago

@rcory Tagged as high priority from almost two years ago. We've got one of three options:

  1. Close
  2. Reduce priority
  3. Actually treat it like high priority

Thoughts?

rcory commented 4 years ago

It was higher priority at the time on a different project, but I'd be happy with bumping this to low priority given that it's currently a non-issue (it would still be nice to have this resolved at some point in the future).

DamrongGuoy commented 2 years ago

@rcory could we close this issue now? I see drake_visualizer can report per-collision-pair contact results now. This is what I saw in the scene browser. It reports contacts with chopper_1::bladehandle{top, vertical, horizontal, bottom_rear}_collision.

image

SeanCurtis-TRI commented 2 years ago

It's worth noting that it's only partially resolved. If I recall correctly, point contact isn't resolved so nicely.

jwnimmer-tri commented 8 months ago

The question to check here would be to see what Meshcat's contact tree does now. IIRC, it still uses geometry IDs instead of shape names, in its scene tree.

jwnimmer-tri commented 4 months ago

In any case, if someone has a problem with Meshcat UX, they can open a new issue. The old drake_visualizer UX is long gone.