iiwa14_polytope_collision specifies model-relative joint axes

[ggould-tri]

(h/t to @aykut-tri for bringing this to my attention) iiwa14_polytope_collision.sdf https://github.com/RobotLocomotion/drake/blob/master/manipulation/models/iiwa_description/sdf/iiwa14_polytope_collision.sdf#L121 specifies that all of the iiwa joints have their axes defined relative to the model (expressed_in="__model__"). This cannot be correct -- the joint axes at least after joint 2 move relative to the model; the axes must be relative to the inboard link's frame. Either this model is wrong (less likely) or we are incorrectly handling expressed_in="__model__" (more likely)

[xuchenhan-tri]

According to http://sdformat.org/tutorials?tut=pose_frame_semantics_proposal section 7, expressed_in="__model__" is a replacement for the tag <use_parent_model_frame> which is used to indicate the vector is expressed "in the parent link's model frame" (http://sdformat.org/tutorials?tut=spec_model_kinematics).

However, the vector is resolved to be expressed in the joint frame (https://github.com/gazebosim/sdformat/blob/sdf12/include/sdf/JointAxis.hh#L207-L216) when Drake parses it. https://github.com/RobotLocomotion/drake/blob/35e6290f1b126a7bd19f406a2ac674745e12360c/multibody/parsing/detail_sdf_parser.cc#L694

Either way, assigning a seemingly more appropriate label.

[xuchenhan-tri]

On closer reading, I'm not sure this is a real issue. Could you clarify how the current behavior deviates from expectation? If I'm reading the issue correctly, the expected behavior is that the axes should be in the "inboard link's frame", and that's what drake's parser ostensibly does.

[ggould-tri]

I agree that the current behaviour is what the user (who did not write "model" -- that was emitted by a tool) wanted. I'm much less clear that it's what the spec indicates.

http://sdformat.org/spec?ver=1.9&elem=model#pose_relative_to says that the semantics are specified in http://sdformat.org/tutorials?tut=pose_frame_semantics (that is, your URL but without the "_proposal" suffix) which says:

Depending on the context, a model frame can be referenced with __model__ or //model/@name. The model frame is the default frame to which explicit model frames defined by //model/frame are attached

I think that implies that the pose is, as the name would suggest, model-relative rather than parent-link-relative? Or does SDF use the world "model" differently than we do?

[xuchenhan-tri]

My previous post was misleading, sorry! The text you quoted clearly indicate that in SDFormat, __model__ refers to the frame of the model (not link). In my previous post, I mixed up the concept of "parent model" and "parent(inboard) link"

I think that implies that the pose is, as the name would suggest, model-relative rather than parent-link-relative?

Agreed!

Or does SDF use the world "model" differently than we do?

No I don't think so.

However, I still don't understand this quote in the OP

the axes must be relative to the inboard link's frame.

Why is that? The axis can be represented in whatever frame that the author of the SDFormat file desires without making a difference in the simulation.

[xuchenhan-tri]

"The joint axes at least after joint 2 move relative to the model" is not contradictory to the fact that the axis is expressed in the model frame. The joint axis specified in SDFormat only dictates the the joint's initial orientation.

[ggould-tri]

Why is that? The axis can be represented in whatever frame that the author of the SDFormat file desires without making a difference in the simulation.

Because if the inboard link moves the axis should move, not remain fixed relative to the rest of the model? If the iiwa wrist axis, e.g., were always relative to the iiwa base then it would be wrong after any shoulder rotation.

[ggould-tri]

Ah, that is what was not clear to me. It seemed to me as though the axis was being made to relative to the model in simulation. It was not clear that this is only an initial condition.

[xuchenhan-tri]

Here the quote in the URL you posted above

The //joint/axis/use_parent_model_frame tag are removed in SDFormat 1.7, and //joint/axis/xyz/@expressed_in are added to modify the orientation of this vector. An empty string or default value implies the joint's initial orientation. Any valid frame can be referred to from here. This also applies to //joint/axis2. An example of SDFormat 1.7 is shown below.

[xuchenhan-tri]

Forgot to ask, can we close this issue @ggould-tri ?

[ggould-tri]

I guess so.

[jwnimmer-tri]

Perhaps it should be filed as a defect upstream that the SDFormat documentation was insufficient?

[xuchenhan-tri]

Meh, I think the level of documentation here is on par with the level of insufficiency throughout SDFormat so it doesn't really stand out to me...