Parsing ambiguous URDFs with efffort limits but no transmission

[jwnimmer-tri]

The joints in a typical URDF (e.g., panda arm) will have stanzas something like this:

  ...
  <joint name="panda_joint1" type="revolute">
    <origin rpy="0 0 0" xyz="0 0 0.333"/>
    <parent link="panda_link0"/>
    <child link="panda_link1"/>
    <axis xyz="0 0 1"/>
    <limit effort="87" lower="-2.8973" upper="2.8973" velocity="2.1750"/>
  </joint>
  <transmission name="panda_tran1">
    <type>transmission_interface/SimpleTransmission</type>
    <joint name="panda_joint1">
      <hardwareInterface>PositionJointInterface</hardwareInterface>
    </joint>
    <actuator name="panda_motor1">
      <hardwareInterface>PositionJointInterface</hardwareInterface>
      <mechanicalReduction>1</mechanicalReduction>
    </actuator>
  </transmission>
  ...

When drake's Parser loads this file, it create a multibody::Joint from the <joint> element and a multibody::JointActuator from the <actuator> element.

In case the joint is unactuated (e.g., acrobot shoulder), the URDF looks like this:

  ...
  <joint name="shoulder" type="continuous">
    <parent link="base_link"/>
    <child link="upper_link"/>
    <origin xyz="0 0.15 0"/>
    <axis xyz="0 1 0"/>
    <dynamics damping="0.1"/>
  </joint>
  <!-- N.B. There is no transmission element nor actuator element. -->
  ...

The file has no effort limit nor actuator.

The ambiguity arises when the URDF specifies a non-zero effort limit <limit effort="..."> but then does not define any transmission (nor actuator). For example, this joint from the spot model has no transmission elements defined at all:

    ...
    <joint name="front_left_hip_y" type="revolute">
        <origin xyz="0.0 0.110945 0.0" rpy="0 0 0" />
        <axis xyz="0 1 0" />
        <parent link="front_left_hip" />
        <child link="front_left_upper_leg" />
        <limit effort="1000" velocity="1000.00" lower="-0.89884456477707963539" upper="2.2951079663725435509" />
    </joint>
    ...

What should Drake do in this case?

At the moment, we neither warn nor add an actuator.

For reference, when parsing SDFormat the zero vs non-zero effort limit is the condition we use to govern whether or not to add actuation.

[jwnimmer-tri]

My proposal: the user has provided a file that is internally inconsistent. So no matter what, we need to warn somehow, since we can't obey the file as-is.

Then the question is which of the conflicting information do we obey on a best-effort basis? It seems like for URDFs in particular (typically robots, vs SDFormat which are objects + worlds), actuation is the common case so we should err on that side.

If the user wanted unactuated but happened to have a non-zero effort on paper, setting effort=0 or omitting //joint/limit/effort entirely is pretty easy. Adding XML for all of the transmissions and motors and such is a lot of work on the flip side.