drake icon indicating copy to clipboard operation
drake copied to clipboard

[multibody] Working PR for new Multibody graphing code

Open sherm1 opened this issue 2 years ago • 2 comments

[Draft] This is the complete set of changes introducing new topology-building code for MultibodyPlant. This is too big for review so serves as a reference for the chain of smaller PRs needed to get this in.

Issues addressed

#9566 #9939 #11266 #11307 #12789 #17429 #18200 #18442 #18803 #19034

Discussion

Users specify models (e.g. in sdf or urdf) with links and joints, forming a general directed graph. To work in internal coordinates, we have to model that graph with a spanning forest comprised of bodies, mobilizers, and constraints. This can (and should) be viewed as a graph transformation, independent of the multibody computations to be performed later. Currently in MultibodyPlant graph operations are sprinkled around the code and completed in various phases of the computation. The main idea here is to consolidate that into one place and time so that everything we need to build an optimal computational model is present already at finalize. By making the graph->forest construction explicit, we are also able to upgrade its functionality significantly:

  • build composites of welded-together links so they can be modeled with a single body in the forest
  • relax the current requirement that the user must orient joint parent/child directions to form a directed tree
  • accept topological loops in the input, modeling with a tree plus constraints
  • take advantage of free pre-calculations to make necessary graph queries extremely fast
  • respect modeling options that influence the resulting forest, e.g. use rpy or welds rather than quaternion floating joints for particular model instances.

The separation of concerns here makes it easy to add more graphing capabilities, such as editing the graph and quickly recomputing the resulting forest.

This change is a precursor to reworking the computational internals into a high-performance "multibody kernel" which can be constructed directly from the spanning forest. This PR only goes as far as re-expressing the existing functionality using the new graph and forest. The most significant internal change is that BodyNode and Mobilizer can now be viewed as a single mobilized body (BodyNode, Mobilizer) with the same index as the spanning forest's mobilized bodies.

Some details

  • Terminology: Link/Joint/Parent/Child for the input graph, and Body/Mobilizer/Mobod/Inboard/Outboard for the resulting forest are used strictly here to keep them untangled; that's not identical to terminology in MultibodyTree but it doesn't matter as much there.
  • The existing MultibodyGraph (in multibody/topology) is replaced with LinkJointGraph, representing the user's input.
  • All substantive functionality in MultibodyTopology (multibody/tree/multibody_topology.h) is removed and replaced with equivalent (but faster) functionality in the graph or forest.
  • LinkJointGraph owns a SpanningForest, comprised of mobilized bodies (Mobods) and loop-closing constraints.
  • Modeling is done when BuildForest() is called; the model is invalidated if changes are made to the graph.
  • The objects are copyable, movable, and assignable to facilitate transmogrification of MultibodyPlant.
  • To support mapping back from the built model to the user, LinkJointGraph is temporarily augmented with "ephemeral" elements to reflect additions required during modeling (e.g. the addition of floating joints).
  • The generated forest is used as a template to directly construct (BodyNode, Mobilizer) pairs.

Note to reviewers

During the PR train leading up to this I'm using Doxygen comments /** despite the fact that this is currently just internal so Doxygen will not process them. The intention is to make the API public once it stabilizes and proves its utility, and developing with the Doxygen comments on helps with proper wording and syntax. When the final PR in the train goes in the comments will be changed to /* and then changed back only if we do decide to make the API public.


This change is Reviewable

sherm1 avatar Sep 20 '23 22:09 sherm1

@drake-jenkins-bot retest this please.

svenevs avatar Oct 05 '23 01:10 svenevs

@drake-jenkins-bot retest this please.

svenevs avatar Oct 05 '23 02:10 svenevs

This is complete as of PR #21820. Box checked in epic #18442; on to the next phase.

sherm1 avatar Aug 22 '24 16:08 sherm1