Support missing joint types in MultibodyPlant

[sherm1]

Missing joint types:

• ball (spherical) joint (should use q=quaternion for unrestricted rotation, v=angular velocity)
• gimbal joint (should use q=rpy , v=q̇=ṙṗẏ) [actually called BallRpyJoint]
  (Probably space-fixed since that's what's common in robotics and matches sdf and our bushing. That's non-physical for a gimbal joint unless interpreted as a ypr body-fixed sequence.)
• universal (U-) joint (q=x (inboard), then new y (outboard), v=q̇)
• screw (1-d revolute/translational joint with ratio)
• gearbox/transmission (1-d revolute with input/output ratio)
• planar (requested in mbp: For quadrotor-modeling workflows, would be nice to have propeller and/or "thruster" actuators #12401 but apparently not supported by sdf)
• floating
  • URDF parsing, urdf: //joint[@type="floating"] - confusing? #13691
  • SDFormat Parsing for SDFormat floating joints #19165

These should be added as joints and mapped to corresponding mobilizers internally. We should be able to parse them in from sdf input, possibly with a Drake extension or two.

Here is the list of joint types officially supported by .sdf 1.6. Here is the list for URDF.

Sdf also has revolute2 which I think is like a U-joint but with non-perpendicular axes. Not clear if anyone needs that.

[EricCousineau-TRI]

I've spoken with @scpeters and @azeey about allowing SDFormat to pass through custom joint types. At present, I believe libsdformat will throw an error if we try do something like <joint type="drake:planar"/>. We should ensure custom joint types are supported through the spec for this. (I don't believe URDF will be an issue, but we should probably namespace it with drake: to start.)

[jwnimmer-tri]

What about <drake:joint type="planar"/>?

[EricCousineau-TRI]

That'd work! (and be simpler for adding the specific attributes)

[scpeters]

I'd like to hear what @azeey thinks as well, but I think <drake:joint /> will just be ignored, so it depends what you want the behavior to be when loaded by an unsupported parser

should we add a fallback_type attribute? this would let you say that a joint should be fixed if drake:planar is not available

I think we're too late into the release process to add this to our initial release of libsdformat9, but we could consider it along with the nesting / composition proposal

[azeey]

I think <drake:joint /> is fine if you are using libsdformat9. Of course, you'd have to access it's contents using the sdf::ElementPtr API instead of any of the DOM objects. In addition, sdf::Model won't contain a pointer to the joint so calls like sdf::Model::JointCount or sdf::Model::JointByIndex won't included that joint.

[sherm1]

That seems unfortunate. It would be nice if sdf could understand that this was a joint, but of an unfamiliar type. There are many useful joint types that sdf does not currently support.

[jwnimmer-tri]

@sherm1 Why do you say it is unfortunate? We don't care if JointCount sugar works. We just want the raw element tree to that we can do useful things with it.

Sure, ideally the sdf xml specification should grow to denote additional joint types in a first-party way, so that ecosystem tools can inter-operate. But for our needs in Drake, we just need the element tree. We don't need anything else.

[sherm1]

@jwnimmer-tri Why would it be reasonable for sdf's JointCount not to return the number of joints? I understand that we can hack around it but if there is a more reasonable solution it would be preferable.

[EricCousineau-TRI]

We don't need JointCount anywhere in Drake's libsdformat-using code, and our usage of libsdformat is heavily encapsulated, so I would say @azeey's suggestion is completely reasonable.

It would only really matter if we cared about traversing all defined joints in the order in which they were defined, which hopefully is never the case?
(Links may be another story with the whole canonical_link setup inherited from Gazebo, but I doubt we need a new link type that would affect that logic.)

[jwnimmer-tri]

... if there is a more reasonable solution it would be preferable.

I don't think it is reasonable to expect libsdformat to do anything special to support sdf dialects other than its own first-party, canonical definition -- other than provide a window into the raw XML, which it already does. If the file uses a first-party element name, the semantics had better be first-party semantics. If we want different semantics, we should use a different tag. Down any other path lies madness.

[sherm1]

.sdf is a format for physical description of robots. It understands links and joints. It is not a stretch for it to understand that there are other kinds of joints besides the small set it currently supports. I don't think that would be madness.

[jwnimmer-tri]

I am all for widening the spec to encompass additional, enumerated joint types. However, I don't want <joint type="dragons_breath"/> to pass libsdformat's validation phase. That is madness.

[sherm1]

Agreed. But something like
<joint type="user_defined"> standard joint stuff, drake::tag stuff </joint>
would still allow the sdf parser to understand that there are joints, which links they connect, etc. without having to understand all the details.

[scpeters]

I would support some extensions to how we define joints like user_defined, but we don't have time to include it in the current release. I think we should just be clear when we're discussing how it currently works vs how it could work

[sherm1]

@scpeters no worries -- would be nice to consider a more disciplined way to deal with non-sdf-standard joints in a future version. If we have to add more joints in the meanwhile we can get by with a drake::joint tag.

[EricCousineau-TRI]

A minor bit: With the pose frame semantics, we may get some more coupling to things like dragons_breath (e.g. a drake:joint tag may not have frame registered in the libsdformat pose graph). However, we can always address it later as there are multiple solutions (of varying complexity).

[RussTedrake]

Planar was added by #13824 and it's precursors. I've checked that box. Looks like the screw joint should be checked off as well, @sherm1?

[sherm1]

Thanks, yes -- done.

[jwnimmer-tri]

For the record, as of today the parsers don't support screw joint yet (even though MbP does). I added a TODO for that in #17054 on the SDFormat side. For the URDF side, it seems like we'll need to <drake:joint> since "screw" is not a URDF-standard joint type.

[RussTedrake]

FYI -- I found my first application need for the ball joint using quaternions instead of RPY. My rubik's cube example can sometimes run into singularities. For example, if you rotate the 2x2 cube about 'y', you'll hit it:
Rubik’s cube notebook

[RussTedrake]

We currently don't have parsing support for all of the joint types. In addition to the screw joint mentioned above, the sdf ball joint could be parsed into BallRpyJoint today, even if we want the quaternion version in the future? This came up in answering a stackoverflow question

@sherm1_ -- it seems reasonable to have that list coincide with this issue, and say that a joint isn't really supported if sdf defines it but our parsers don't support it. Or do you want a separate issue to track the parsing?

[sherm1]

I think it's sufficient to include parsing needs under "support missing joint types" as covered by this issue.

[jwnimmer-tri]

FYI I just updated the checkboxes at the top to add floating.