URDF parser does not respect the "axis" element of a planar joint

[RussTedrake]

Someone tried

  <joint name="base_joint" type="planar">
    <parent link="world" />
    <child link="body" />
    <axis xyz = "0 1 0" />
  </joint>

and was surprised to see the planar joint still operating around the z axis. Looking at the URDF documentation, it seems that we are clearly in the wrong:

<axis> (optional: defaults to (1,0,0))

The joint axis specified in the joint frame. This is the axis of rotation for revolute joints, the axis of translation for prismatic joints, and the surface normal for planar joints. The axis is specified in the joint frame of reference. Fixed and floating joints do not use the axis field.

Reading the urdf parser code, we simply don't handle it (nor do we provide any warning).

One can work around it by rotating the origin:

  <joint name="floating_base" type="planar">
    <parent link="world" />
    <child link="ball" />
    <origin rpy="1.57 0 0" xyz="0 0 0" />
  </joint>

but we clearly need to fix the bug.

[xuchenhan-tri]

This suffers from the same issue as #17193 where the convention of Drake (joint frame doesn't necessarily coincide with the child frame) differs from convention of standard formats. We can let joint frame have the same translation as the child frame but use a rotation such that the joint frame's z is along the axis specified in URDF. This should have the same effect as Russ's temporary fix.

[xuchenhan-tri]

While working on this, I realized that axis info is not respected by universal joint either in URDF parser. However, unlike SDFormat, URDF doesn't support specifying the second axis of a joint (because it doesn't support joints where a second axis makes sense). I'm not sure what's the correct behavior should be in this case. Perhaps we need a new drake tag for axis2?

[rpoyner-tri]

A new tag for axis2 (or whatever) may be the only way. That may be distinct enough to warrant a new issue.

[xuchenhan-tri]

@rpoyner-tri see #19381.