Use link/joint terminology consistently in MultibodyPlant

[sherm1]

Our most common input formats, .sdf and .urdf use the terms "link" and "joint" to describe the topology of a multibody system. That can include topological loops, rigid groupings of welded-together links, static links, free objects, etc. The input to Drake's MultibodyPlant is intended to represent that in a straightforward way. However, although MBP uses "joint" consistently with sdf it uses the term "body" (e.g. AddBody()) to mean "link". I'm not sure there was ever a good reason to do that but it is the term we started with and it didn't cause any trouble initially.

Internally, we need to create a model of the input system that includes a spanning tree plus constraints. Links can be split into multiple "bodies" and joints are implemented using "mobilizers" (generating differential equations) or constraints (generating algebraic equations). As we improve Drake's modeling capability, the distinctions between the input graph and modeled tree+constraints system will increase. In many cases that's invisible to API users who can just work with the original abstractions. However, internally and for many users we need to be able to communicate and think clearly about the distinction between the input topology and the generated model. This is coming up now because we are beginning to formalize input graph and tree introspection (e.g. see PRs #11257 and #10068).

We use the term "mobilizer" internally as a term of art to distinguish tree-model joints from input joints and that has been very helpful. I propose that we reserve "body" for the tree system and take advantage of Robotics' "link" term of art (and compatibility with sdf) to distinguish links as specified by users from the bodies we use to model them. That makes it easy to talk about the fact that there may be multiple bodies used to represent a single link (in the case of topological loops) or multiple links modeled as a single body (in the case of welded-together groupings).

In practical terms, this just means changing MBP::AddBody() to MBP::AddLink() and fixing some comments. The previous name can be left as a synonym with no harm, and eventually deprecated.

Thoughts?
cc @amcastro-tri @EricCousineau-TRI @RussTedrake @avalenzu @mitiguy

[sherm1]

BTW the CAD world uses "part" which is a nicer word than "link". Andy Ruina says we should use "object" (I don't think he knows about OOP :)

[EricCousineau-TRI]

I love this proposal in terms of consistency and delineating the physical modeling objects from the mathematical modeling objects.

However, I can't say that I love the current suggested solution:

In practical terms, this just means changing MBP::AddBody() to MBP::AddLink() ...

I think this would also mean renaming (Body, RigidBody) to (Link, Rigidlink)?

My issue with reflecting this in MultibodyPlant is that this assumes that we have successfully decoupled the plant from the tree incantation, which is not the case. I know that this was the desire initially, and this is a residual desire, but I'm not sure if I've seen this explicitly outlined as a goal?
As a developer, I'd prefer we not revert back to half-baked API delineations a la #9366 while the actual implementations are still highly coupled.

I'd feel much more at peace with initiating API transitions if:

• There is a high-level issue with an proposed roadmap to this decoupling (physical vs. math)
• It has some checkboxes on how to do the transition
  • e.g. do some stuff, MultibodyTreeTopology and all that disappears, do some more stuff, then BAM, MultibodyGraph queries become public. At some point, MultibodyTree becomes truly decoupled and has a non-awkward and non-redundant workflow (only talks Bodies and Mobilizers, never touches "Links" or Joints) and doesn't have a billion methods copied from MBP, and BAM, it's public again.
• It has a clear picture of how the user workflow benefits or is unaffected by this work
  • e.g. 5 lines of prototype of "before" and "after

Specifically on the delineation between Link and Body, I can't say I'm a fan of using terms that are generally synonymous, but I think that discussion is currently secondary to the overarching issue of decoupling and doing things holistically.

[amcastro-tri]

Per discussion with @sherm1, @mitiguy and @EricCousineau-TRI today:

• We'll keep Body as the user public API for physical queries (that is, no refactoring needed, yaiii!).
• We'll introduce (initially internally) a MobilizedBody in the ModelTree in [WIP] Imported MultibodyGraphMaker from Simbody #10068.

That is, per today's discussion we settled on Body (instead of Link) for the physical API and MobilizedBody (instead of Body) for the modeling API. MultibodyPlant's API will remain unchanged and we can still leverage on the entire Mobilizer technology we already have.

[sherm1]

BTW in case you need an abbreviation for MobilizedBody internally (and you very likely will), Simbody uses mobod as its approved abbr.

[jwnimmer-tri]

IIRC @sherm1 decided on a different solution path here -- using "mobod" internally but not renaming the MbP API.