Drake: RigidBodyTree to MultibodyTree Feature Migration

[avalenzu]

The purpose of this issue is to try to make sure that no existing functionality of RigidBodyTree/RigidBodyPlant is unintentionally lost in the transition to MultibodyTree/GeometryWorld. Each comment on this issue should name a feature of RigidBodyTree/RigidBodyPlant. If a feature you use has already been listed, please +1 the corresponding comment.

[avalenzu]

URDF/SDF parsing

[avalenzu]

Simulating multi-body systems without contact

[avalenzu]

Simulating multi-body systems with contact

[avalenzu]

Collision checking

[avalenzu]

Ray-casting

[avalenzu]

Computing separation/penetration distance

[sherm1]

Obtaining Jacobians (which ones?)

• Relative position
• Transformed points (RigidBodyTree::transformPointsJacobian())
• Relative quaternion
• Relative roll-pitch-yaw
• Geometric Jacobian

[EricCousineau-TRI]

For collision checking: signed distance functions

[manuelli]

Rigid body dynamics, H,C,B matrices.

[avalenzu]

Centroidal momentum matrix

[siyuanfeng-tri]

I'd like to have a first order system.

[sammy-tri]

Model-Instance-Centric Port Accessors (RigidBodyPlant)

[EricCousineau-TRI]

In conjunction with Sammy's comment, if we're going to use MultibodyTree as a world-representation, it'd be nice to have instance-centric properties directly available (not just ports, but getting variables / indices / whatever for a subset of an instance's joints within the tree, bodies for a given instance, etc.).

[manuelli]

Following up on Eric and Sammy's comments. I will mostly be using MultiBodyTree with a single robot, so just having the same easy to use functionality from RBT would be appreciated.

[EricCousineau-TRI]

As a nice-to-have, being able to copy portions of an already-constructed tree into a construction-in-progress tree.
(Example: From the monolithic pick-and-place, instantiating a KUKA arm within the world, adding a WSG gripper, and, when building the controller model, have the option to use the same model, but fixing / welding the gripper joints.)

[EricCousineau-TRI]

Per comment in #7185:

• Python bindings
• Support a dynamically changing scene (objects being added or removed), with support in Python, for collision-free IK trajectory planning. Either:
  
  
  
  • Interacting with GeometryWorld to add / remove entities
  
  
  • Adding / removing tree components (bodies, collisions) and being able to recompile the tree efficiently
  
  

[amcastro-tri]

Thank you @EricCousineau-TRI.

1. Python bindings do not happen to fall on my lap, I wonder if this should be cited on a more "python bindings" issue? so it doesn't get lost here.
2. Support a dynamically changing scene. The policy with MBT was decided; if you want to add more bodies (for dynamics at least), you need to create a new tree. That makes sense if you think that everything MBT needs to solve for is fully coupled. Of course, additional sugar around it can mimic this functionality you describe, but it'd be code living outside of MBT.
3. Dynamically adding/removing collision geometries is another issue, but as far as I understand @SeanCurtis-TRI took this into account in GeometrySystem.

[mpetersen94]

Torsional springs and distance constraints between two points.

[sherm1]

cc @tri-ltyyu

[EricCousineau-TRI]

Uh, is this still alive?

[amcastro-tri]

I believe many of the features mentioned here are actually in Drake master today.
Some might be missing but were not given high enough priority yet. I vote that we close for this issue and if there is some feature we currently don't have and you want it added, please open a specific issue for it. Thanks @EricCousineau-TRI

[EricCousineau-TRI]

Seconded! Closing for now, we can re-open later.