MultibodyTree features requests.

[amcastro-tri]

This issue is opened to track a number of issues, feature requests, ideas for RBT that need to be taken into consideration in the design of MultibodyTree. This issue will therefore help close those old RBT issues without loosing track of them.
The need for MultibodyTree was identified in #4633.

These items are listed in the order I think they will get resolved:

• Small lightweight spatial algebra library. Develop a lightweight spatial algebra library #2752
• Full templatization on <T> with transmogrification capabilities. Template RigidBodyTree on <T> #3987
• Design a class hierarchy that encompasses the concept of Frame's. Simplify RigidBodyFrame API #4407
• Simplify API for programmatic construction and queries. Provide simple API to RBT users #4328
• Provide a solid representation of unique identifiers when needed. RigidBody::body_index_ is not a good unique identifier in RBT #4291
• Compute Rigid Body Inertias with respect to Bo rather than Wo. Formulate CRB's in RBT as computed about Bo rather than Wo. #4621.
• Provide mechanism for state validation. Need to Add a Check To Verify Quaternion Floating Joint Configuration Is Valid #4838
• On MultibodyPlant<T>: Provide clean API access to cached computations. Output KinematicsCache from RBP #3325
• Provide a capability to represent several model instances. Need a Way To Extract From the Whole-World Model a Model-Instance Model #5190, relates also to Modify RigidBodyTree to Assign World Body a Model Instance ID of Zero #3088
• Provide documentation on spatial inertia methods and mass matrix computation. See old PR Document frames and spatial inertias transformations. #4591 for RBT.
• Move/adapt documentation provided in old PR Documentation for some RBT transform methods #4311.
• Transparent (and safe) API for joints internally implemented with Mobilizer's or Constraint's. SDF-based robots invisibly, unpredictably omit joint outputs #3673
• Remove drake::SpatialForce typdef in conflict with new class drake::multibody::SpatialForce. We have both drake::SpatialForce and drake::multibody::SpatialForce defined #6731
• Torsional springs and distance constraints between two points, per comment. Partially addressed by Added a RevoluteSpring ForceElement and associated unit tests. #10658.

For a full list of issues on RBT you can see #3908

[kunimatsu-tri]

I have a request for MultibodyTree, which is related to #3088.

I'm working on "label image" output feature of RGBD camera simulator.
The "label image" contains an unique id associated to an object in the each pixel .

From image rendering point of view, both the terrain and the sky should have unique ids, but the current RBT doesn't handle them. The temporal solution is assigning arbitrary ids to the sky and the terrain.
This is OK for now, but I feel the sky and the terrain are something special and they should always have the same ids if possible.

So, I want to request that we assign unique ids for the sky (or space or world if it's appropriate) and the terrain as follows:

sky: 0
terrain: 1

[sherm1]

#3088 is referring to physical bodies (in particular world), which are not geometry. RBTree currently knows about collision geometry, but not visual geometry. We are splitting out all geometry handling (both physical and collision) to GeometryWorld so your request might be for that? MultibodyTree will not have any geometry at all.

@SeanCurtis-TRI may have a useful comment since he is working on GeometryWorld.

[kunimatsu-tri]

Thanks. Resolved by discussion on Slack. I withdraw the request.

For the record, we've got a consensus that we should NOT define terrain to have an unique id since terrain could have more specific semantics than just terrain, and that it's OK for the sky (space, world, empty or whatever) to have ID zero in GeometryWorld.

[TristanThrush]

Would it be good to add support for the static tag (from the SDF format), so that the Drake SDF parser can handle an SDF for multiple objects and make some of them floating and some of them fixed?

[EricCousineau-TRI]

Related: Other feature requests are in #7025 as well

\cc @avalenzu

[sammy-tri]

Marking the model instance bits done based on #8986 and #9041

[sherm1]

cc @tri-ltyyu

[EricCousineau-TRI]

This done?

[sherm1]

I think this is far enough along that we could close it and have separate issues if there is anything left to be done. What do you think @amcastro-tri ?

[amcastro-tri]

agree.