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

MultibodyPlant vs Pinocchio Performance #181

Open
mposa opened this issue Jul 18, 2020 · 7 comments
Open

MultibodyPlant vs Pinocchio Performance #181

mposa opened this issue Jul 18, 2020 · 7 comments

Comments

@mposa
Copy link
Contributor

mposa commented Jul 18, 2020

This is an issue to track Drake::MBP vs alternatives (currently Pinocchio). This example is on a Cassie URDF. Some comments on the plant:

  • Does not include loop closure
  • Does not include contact
  • Fixed base model (pelvis)

Test code is https://github.com/DAIRLab/dairlib/blob/pinocchio/examples/Cassie/test/benchmark_dynamics.cc

To replicate:

bazel run --define WITH_SNOPT=OFF examples/Cassie:benchmark_dynamics 

Status, July 18, 2020

As run on Michael's laptop

(multibody_plant) 100x inertia autodiff calculations took 182 miliseconds. 1820 microseconds per.
(multibody_plant) 10000x inverse dynamics calculations took 125 miliseconds. 12 microseconds per.
(multibody_plant) 100xautodiff inverse dynamics calculations took 240 miliseconds. 2400 microseconds per.
(multibody_plant) 10000x forward dynamics calculations took 304 miliseconds. 30 microseconds per.
(multibody_plant) 100xautodiff forward dynamics calculations took 348 miliseconds. 3480 microseconds per.
(pinocchio) 10000x rnea inverse dynamics calculations took 20 miliseconds. 2 microseconds per.
(pinocchio) 10000x rnea inverse dynamics derivatives calculations took 61 miliseconds. 6 microseconds per.
(pinocchio) 10000x aba forward dynamics calculations took 32 miliseconds. 3 microseconds per.
(pinocchio) 10000x aba forward dynamics derivative calculations took 120 miliseconds. 12 microseconds per.
vdot_mbp, vdot_pin, diff

Summary (Drake, Pinocchio)

For numerical derivatives, approximating by double x 42 (counting fixed-base coordinates nq=nv=16 and nu=10 )

  • Forward dynamics: (30, 3)
  • Inverse dynamics: (12, 2)
  • Forward dynamics derivatives , Drake-Autodiff: (3480, 12)
  • Forward dynamics derivatives , Drake-Numerical: (1260, 12)
  • Inverse dynamics derivatives , Drake-Autodiff: (2400, 6)
  • Inverse dynamics derivatives , Drake-Numerical: (504, 6)
@sherm1
Copy link

sherm1 commented Jul 29, 2020

I'm making some progress on this -- found some inadvertent inner-loop heap allocations in MBP. Not sure yet how much those affect performance but they can't be good. Will fix shortly.

@sherm1
Copy link

sherm1 commented Aug 1, 2020

FYI @mposa there appear to be some bugs in the test cases for autodiff of inverse & forward dynamics. Try setting the iteration counts to 1 in the test and run a Debug configuration (so that all the Eigen asserts are enabled). Looks like inconsistent use if drake::math::initializeAutoDiff() producing different numbers of derivatives for (e.g.) x and u in forward dynamics. Possible fixes mentioned here.

@mposa
Copy link
Contributor Author

mposa commented Aug 1, 2020

Yes, you're right. I caught that when I added the comparison between gradient matrices, but did not bother fixing the for loops. The bug probably makes AutoDiff actually look better than it really is.

@yminchen
Copy link
Contributor

yminchen commented Jan 23, 2022

A few benchmarks related to the center of mass evaluations:

All units below are [seconds per 100,000 calls].

Without resetting drake context every loop:

r_com time (Pinocchio):0.0406533
r_com time (Drake):0.0244223
v_com time (Pinocchio):0.0578227
v_com time (Drake):0.0902847
J_com time (Pinocchio):0.0692747
J_com time (Drake):0.602594

When resetting drake context in every loop:

r_com time (Pinocchio):0.0988584
r_com time (Drake):0.369517
v_com time (Pinocchio):0.137124
v_com time (Drake):0.711533
J_com time (Pinocchio):0.148367
J_com time (Drake):1.55255

@sherm1
Copy link

sherm1 commented Jan 24, 2022

Thanks @yminchen! I see that the Pinocchio times changed in the second set also -- is there an equivalent of resetting the Context in Pinocchio? Also, can you say what you did specifically to "reset" the Context in Drake?

@sherm1
Copy link

sherm1 commented Jan 24, 2022

cc @amcastro-tri

@yminchen
Copy link
Contributor

@sherm1 Thanks for the question! I should've mentioned this in the previous post. The benchmark was done not directly on Pinocchio but PinocchioPlant (we derived this class from Drake's MultibodyPlant by overriding center of mass related methods). This is why there is a difference between with and without resetting context for Pinocchio. The extra runtime is from calling plant.SetPositions(context.get(), q), for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants