parsing, sdformat: Bushing parsing should be done as custom Drake joint

[EricCousineau-TRI]

See discussion here: https://github.com/robotlocomotion/drake/pull/13824#pullrequestreview-463682376

@sherm1 Can you task this out? I won't have time to do this over the next month, but it seems like should something that should be done before then?

[sherm1]

I think we have to figure out whether it actually makes sense to do and if so how to specify it. @joemasterjohn, what do you think about us treating a bushing as a kind of joint in sdf and urdf? (@mitiguy and @amcastro-tri may want to weigh in also).

[SeanCurtis-TRI]

This slightly confuses me. I haven't looked into it deeply at all. But the one detail I have seen is the fact that the linear bushing is a force element and not a joint. Arguably, that is purely an implementation detail and at the model specification level, we want to preserve the idea that it is a joint. Is this the case?

[sherm1]

Yes, the idea is that a "joint" is something that joins two bodies. Whether it does so rigidly or with some compliance is a detail since all real joints have some compliance, and many real-world joints include rubber or spring-steel bushings on purpose. The bushing force element in particular is very "joint like" so we have a choice about whether to emphasize its "force-ness" or its "joint-ness". The bushing documentation here (scroll down to the table) actually explains how to use the bushing to create revolute, prismatic, ball, and weld joints incorporating some compliance. Joe's Strandbeest example uses a bunch of bushings to supply the missing joints in the closed-topology mechanisms.

[amcastro-tri]

I get your point @sherm1, no need to explain further. However IMO bushings are completely different from joints, I would parse them separately. Not sure why the "medium" priority.

[joemasterjohn]

I think folding the parsing of the bushing into a drake:joint might get confusing. Specifically that the user might expect there to be state associated with that "joint", or to be able to access/modify it through MBP's Joint based APIs. Maybe just adding sugar to the parsing of drake:linear_bushing_rpy to make it easier to create a bushing element that acts like a joint? Something like:

<drake:linear_bushing_rpy type="revolute">
  <parent>linkA</parent>
  <child>linkB</child>
  <pose>0 0 0</pose>
  <axis>
    <xyz>0 0 1</xyz>
  </axis>
</drake:linear_bushing_rpy>

The parser would then be responsible for setting up the correct frames and then estimating the stiffness/damping for the given joint type?

[sherm1]

Yeah, that's a good point @joemasterjohn. Not being able to use the joint API would be confusing. I think if we wanted to make bushing a kind of joint we would also have to support Joint API access. That's a lot more work than just fiddling with the sdf file.

I don't think we should add "joint like" support to the bushing. Anything where we have to estimate our own compliance and damping parameters is bound to cause trouble -- I favor leaving that to the user who has a lot more information and can tweak parameters until the human is satisified.

In view of Joe's comment and generally lukewarm-to-negative responses above, I propose we now close this issue and just leave the bushing the way it is until there is a good reason to undertake a project to make it a legitimate joint type. Are you OK with that Mr. OP (@EricCousineau-TRI)?

[mitiguy]

I agree with the current trend (Alejandro, Joe, Sherm) of this conversation.
If a bushing (a spring/damper on steroids) is a joint, then why not a simple translational spring ? It seems like all joints (other than a free joint) are associated with limiting a degree of freedom via a kinematic connection. One could argue a free joint is a misnomer -- it is really a lack of connection than a type of connection. But I think the terminology "free joint" is reasonably clear.

[EricCousineau-TRI]

Sorry for the delay, but yes, these discussion points sound reasonable; bushing parsing should remain as a "non-joint" for simplifying API expectations (don't mislead users). Closing.

Thanks!