Drake: suspicious behavior in python CalcGravityGeneralizedForces

[RussTedrake]

https://stackoverflow.com/questions/55373650/how-to-properly-use-multibodyplantcalcgravitygeneralizedforces-in-pydrake

[sherm1]

One thought that pops to mind @amcastro-tri is that the PyDrake result is consistent with gravity=0. That makes me wonder whether the fancy numpy binding for UniformGravity might be ignoring the given vector.

[gizatt]

Maybe this is the same as what you mean, but it looks like MBT has two methods for registering ForceElements -- one for generic force elements, and one for UniformGravityFieldElements. Maybe the Python call is not going into the specialized (latter) method and not getting registered to the MBT's gravity_field_, which is what gets checked in the CalcGravityGeneralizedForces method?

[amcastro-tri]

yes, that's what's happening. Let me see how to fix.

[amcastro-tri]

In C++ we also have UniformGravityFieldElement::CalcGravityGeneralizedForces(). We could add the python binding for that so you can call that computation directly on the element. Would that work @gizatt?

[jwnimmer-tri]

Adding Gravity should work the same in both C++ and Python. To the extent C++ uses a specialization to achieve this, pydrake must deal with that as well. Even if UniformGravityFieldElement::CalcGravityGeneralizedForces also gets bound, AddForceElement is still broken.

[EricCousineau-TRI]

Solving the API parity can be done by adding a overlay (before the first AddForceElement) that catches UniformGravityFieldElement and dispatches to that specialization.

I can submit this PR if you'd like.

TBH, though, it'd be way nicer if the public API didn't require internal compile-time specialization...
The better solution is to not constrain AddForceElement to only permit one addition of UniformGravityForceElement, and instead it should scan the list after-the-fact to get the gravity... Or perhaps remove CalcGravityGeneralizedForces and instead call it CalcConservativeGeneralizedForces, and have it loop over the conservative force elements?

EDIT: Er, dumb question now: Is it Conservative, or just PotentialEnergy stuff? ...

Also, the usages of gravity_field_ seem really weird. It's used for CalcGravityGeneralizedForces (find I guess...) and as a heuristic for set_penetration_allowance... with a default value???

[amcastro-tri]

as a heuristic for set_penetration_allowance... with a default value???

I agree, that'll get resolved with future better contact models.

[amcastro-tri]

@EricCousineau-TRI gave my a lil snippet of the solution for me to try. I'll try to PR soon. Thanks!

[amcastro-tri]

Fix in PR #11069.