Identify and then Thoroughly Document Transform of Joint's Mobile Frame To Its Child Body

[liangfok]

Simbody includes the following image that describes a joint, its frames, and their transforms.

https://github.com/simbody/simbody/blob/master/Simbody/doc/images/MobilizerTerminology.png

Using the variable names in the above-linked figure, I currently don't know what X_BM is in Drake. Is it identity? Or, is it inferred assuming bodies P and B are initially presented in a configure that makes frames F and M coincident?

For context, see: https://reviewable.io/reviews/robotlocomotion/drake/3137#-KPAy7Gzc5VtPqgiE6Kg

[amcastro-tri]

Is this an issue for Drake's code base or just a reminder for yourself @liangfok? I actually have the answer for this: there is no F like in SimBody, just a parent frame (P) a joint frame fixed with respect to the parent's frame (J for the lack of other notation) and a child body frame (C). Also, the return of jointTransform is the transform from the child's frame to the joint's frame, or T_JC in our notation. Is there anything that this issue would resolve in Drake?

[liangfok]

I believe the "defect" that this issue falls under is the fact that DrakeJoint is not adequately documented.

Thanks for the note. I believe you're saying X_BM (using SimBody's terminology) is identiy, which is what I was leaning towards: https://github.com/robotlocomotion/drake/pull/3137#issuecomment-250239262.

@sherm1, assuming the above is true, is it OK for Drake to force X_BM to be identity? Are there certain types of joints that cannot be modeled by this constraint? I believe the answer is yes, especially for "joints" in biological organisms that involve stretchy cartilage.

[sherm1]

is it OK for Drake to force X_BM to be identity?

It is not good practice because it prevents use of a natural body frame for the child body. Instead the child body frame B must be coincident with the inboard joint's "M" frame (in Simbody lingo). Since everything else on the body is expressed relative to B (visual & collision geometry, mass properties, locations of joints for which B is the parent), repositioning the inboard joint (for example during a design study or just due to a parameter change) means all of those other quantities have to be changed also. Awkward. Note that .sdf was modified by OSRF a few years ago to allow a separate joint frame on the child.

No need to address in RBTree other than to document it; if we change it we'll do that with other major API changes in a new multibody wrapper class.

[liangfok]

I agree with @sherm1's comment about how forcing X_BM to be identity is bad since it may prevent the child body from having a "natural" frame.

From a F2F discussion with @amcastro-tri, I also learned that revamping the RigidBodyTree to support non-identity X_BM may not be worthwhile given more fundamental changes the Dynamics team is planning that will result in a new software abstraction called MultiBodyWorld, which will replace RigidBodyTree. Because of this, I will close this issue without resolving it and trust that a non-identity X_BM will be supported in MultiBodyWorld once it exists.

[sherm1]

P.S. No capital "B" in "Simbody"

[amcastro-tri]

That was me, sorry. @liangfok was typing it right until I decided to pollute this thread :-)