search

RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.26k stars 1.26k forks source link

Provide MbP configuration option to use RpyFloatingJoints rather than QuaternionFloatingJoints #20943

Open sherm1 opened 7 months ago

sherm1 commented 7 months ago

PR #20912 provides a roll-pitch-yaw floating joint as an alternative to the existing quaternion floating joint. Currently MultibodyPlant implicitly adds QuaternionFloatingJoints to mobilize free bodies. MbP should have an option that would make it add RpyFloatingJoints instead.

Alejandro's branch behind abandoned PR #19065 has a possible implementation using MultibodyPlant::set_default_floating_joint_type() with the corresponding MultibodyPlantConfig option.

N.B. Most of the free body code in MbP assumes that the bodies' inboard joint type is QuaternionFloatingJoint and will break if another joint type is present. That code needs to be generalized to use any suitable floating joint.

cohnt commented 2 weeks ago

Just dropping by to say that this feature would be super useful for some of the stuff we're doing with IrisInConfigurationSpace when there are floating bodies. Do you have a sense of how time-consuming this would be to implement?

jwnimmer-tri commented 2 weeks ago

BTW I just noticed one thing in the overview:

N.B. Most of the free body code in MbP assumes that the bodies' inboard joint type is QuaternionFloatingJoint and will break if another joint type is present. That code needs to be generalized to use any suitable floating joint.

This is true, but also note that per https://github.com/RobotLocomotion/drake/issues/19269#issuecomment-1521098480 nearly all of those functions should just be deprecated for removal. I suppose we don't want to wait for that deprecation timeline to expire in order to start working on this issue, but it does raise the option that those methods could throw in case the plant setting is changed to "rpy" instead of "quat", to avoid investing the time in fixing up doomed code.

Existing users who stick with "quat" will be unharmed, and users who want "rpy" but don't need those functions (like cohnt) would still be able to make progress.

sherm1 commented 2 weeks ago

I'm working on a PR that will fix MbP internals so that floating bodies can have rpy joints. (The new topology code has global and per-model instance options to use rpys rather than quaternions for floating joints.) After the internals are working we can figure out how to convey that option in practical cases.