Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[multibody] Working PR for new Multibody graphing code #20225

Closed
wants to merge 1 commit into from

Conversation

sherm1
Copy link
Member

@sherm1 sherm1 commented Sep 20, 2023

[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

@svenevs
Copy link
Contributor

svenevs commented Oct 5, 2023

@drake-jenkins-bot retest this please.

1 similar comment
@svenevs
Copy link
Contributor

svenevs commented Oct 5, 2023

@drake-jenkins-bot retest this please.

@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch 7 times, most recently from 5360249 to 8f8e43f Compare October 12, 2023 19:11
@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch from 82846ef to ff16265 Compare October 17, 2023 01:04
@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch 5 times, most recently from b3bd789 to e3e2057 Compare October 24, 2023 21:25
@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch 4 times, most recently from ab0fca5 to 5e529c1 Compare October 26, 2023 21:54
@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch 11 times, most recently from 8916e6b to 5e4c4a7 Compare August 8, 2024 22:57
@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch 4 times, most recently from 9977d62 to 776b654 Compare August 14, 2024 20:50
@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch 5 times, most recently from 47955b9 to b52f076 Compare August 19, 2024 21:44
@sherm1 sherm1 force-pushed the mbp_topology_shuffle branch 2 times, most recently from 2ace167 to 7c9ea16 Compare August 19, 2024 22:53
Modified MultibodyTree to replace its internal topology with SpanningForest.

Harmonized BodyNode & Mobilizer with Mobilized Body numbering.
@sherm1
Copy link
Member Author

sherm1 commented Aug 22, 2024

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

@sherm1 sherm1 closed this Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants