The parent entity of a joint should be the child link

[azeey]

Environment

• OS Version: Ubuntu 18.04
• Source or binary build? source, ae1a048

Description

• Expected behavior: The pose component of a joint is relative to its child link, so the parent entity of joint should also be the child link
• Actual behavior: The parent entity of a joint is currently its model. This causes issues when computing poses of joints or any of it's child XML elements using worldPose.

[chapulina]

The parent entity of a joint should be the child link

I don't think it's that straight forward. The joint has technically 2 parents:

1. The entity that the joint belongs to, which is the model
2. The default frame of reference for the joint pose, which is the child link

components::ParentEntity currently holds the model entity, and I think that's correct. The question is how can we resolve its pose correctly. Some ideas:

• Have yet another component, i.e. components::PoseFrame (I think this can become too complicated to maintain, and will probably duplicate some frame semantics functionality already in SDF, so I think it's not a good idea)
• Handle joints as a special case within worldPose (not ideal, but not too bad)
• Recommend against using worldPose for joints, and instead handle this in the new Joint class that we need to create eventually (APIs that ease migration from classic #325 )

[scpeters]

• Expected behavior: The pose component of a joint is relative to its child link, so the parent entity of joint should also be the child link

Currently the JointPositionController GUI plugin lists the joints in a given model by checking for joints whose ParentEntity component matches a specified model entity. If we did decide to change the ParentEntity of a joint from its model to its child link, I think we'd still want to support this functionality in another way.

components::ParentEntity currently holds the model entity, and I think that's correct.

I also favor keeping a joint's ParentEntity as its containing model

The question is how can we resolve its pose correctly. Some ideas:

• Handle joints as a special case within worldPose (not ideal, but not too bad)

I think this would be the easiest thing to implement. We are already working around this in the ForceTorque system.