search

RobotLocomotion / drake

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

Should port `multibody_plant_subgraph` Python prototype to C++ #15026

Open EricCousineau-TRI opened 3 years ago

EricCousineau-TRI commented 3 years ago

Context:

See current publicly visible form of the code: https://github.com/EricCousineau-TRI/repro/tree/b130aced/drake_stuff/multibody_plant_prototypes

Suggested plan-of-attack:

Non-goal: function_system.py is just some minor sugar; ain't important for acute goal of this issue.

\cc @jennuine

EricCousineau-TRI commented 3 years ago

Should also ensure that we have a way of porting over / handling things like collision filtering. (\cc @SeanCurtis-TRI)

SeanCurtis-TRI commented 3 years ago

Can you elaborate on what "porting over/handling" collision filter means?

And what other "things" did you have in mind? It might be worth having a face to face so we can hash out these topics and enumerate them here for bookkeeping.

EricCousineau-TRI commented 3 years ago

Can you elaborate on what "porting over/handling" collision filter means?

Yup! The simplest invariant is if I have (plant, scene graph), and I copy in it's entirely to a new target set, everything (controllable by those two classes) should ideally be identical (e.g. the collision filtering semantics example in #15524).

By "controllable by those two classes", I'm attempting to separate this component's concerns away from anything relating to the System framework (e.g. any intermediate systems that re-translate objects, etc.), beyond the nominal connections that are done by AddMultibodyPlantSceneGraph().

And what other "things" did you have in mind?

Any and all elements that are tracked / added in via the (plant, scene graph) pairing to preserve the above invariant. At the moment, the only concrete list I have are things that are already supported in the Python prototype, with the addition of collision filtering.

SeanCurtis-TRI commented 3 years ago

The simplest invariant is if I have (plant, scene graph), and I copy in it's entirely to a new target set, everything (controllable by those two classes) should ideally be identical...

Seems to me you get that already. Is this known to be an issue or is this merely an indicator saying, "We don't know it's an issue, but we need to confirm (and correct as necessary)"?

EricCousineau-TRI commented 3 years ago

Sorry, it is now speculation -- it had been an issue for things like preserving JointIndex, etc.

So yeah: We should confirm this invariant (and correct behavior as necessary).

EricCousineau-TRI commented 3 years ago

Next step is PR GetGeometries(), and then to try an initial end-to-end prototype for just bodies and ~joints~ model instances. After that, do joints (b/c relationship is complex).