RNE/inertia() silently wrong (not crashing) for URDF robots with fixed/structural joints

[petercorke]

Background

Three independent bug reports (#236, #463, #489) hit essentially the same crash: rne()/inertia() raising AttributeError/TypeError on URDF-loaded robots (Panda, KinovaGen3) that have a structural (non-actuated, jindex=None) link in the chain -- typically the base-mount link before the first real joint.

Current status (verified 2026-08-25)

The literal crash no longer reproduces on current main -- confirmed directly:

>>> robot = rtb.models.URDF.Panda()
>>> robot.rne(q=[-1.649, -0.107, 0, 0, 0, 0, 0], qd=np.zeros(7), qdd=np.zeros(7), gravity=[9.81, 0, 0])
[0. 0. 0. 0. 0. 0. 0.]

No exception -- but that's the wrong answer. The equivalent DH Panda model, same pose, same gravity vector, returns real nonzero torques ([1.307, 3.65, -3.52, -1.23, -1.60, 0.038, 0.078]). Same symptom reproduces on KinovaGen3 (#463's exact repro): near-zero-but-not-exactly-zero torques (~1e-8 to ~1e-3) instead of the real gravity-load torques a bent 7-DOF arm should show.

So whatever change stopped the crash did not fix the underlying computation -- it just made the wrong answer silent instead of loud, which is arguably worse for anyone not specifically checking against a reference.

Root cause and proposed fix

#483 diagnosed this precisely and submitted a full working patch: when a fixed/structural link precedes an actuated joint, that link's center-of-mass and inertia tensor are never transformed into the parent actuated joint's frame before being folded into the dynamics recursion -- they're silently dropped/miscounted. #483's patch (verified against Pinocchio by the submitter) fixes this at the source. Not yet applied to main.

Next steps

• Apply (or re-derive, if Robot.rne()'s internals have since diverged further from Proposed fixes for RNE with fixed joints give incorrect results #483's patch) the fix from Proposed fixes for RNE with fixed joints give incorrect results #483.
• Add a regression test comparing URDF-loaded vs. DH-loaded RNE results for an equivalent robot (e.g. Panda), asserting they agree -- this exact class of bug would have been caught immediately by such a test.

Originally reported: #236, #463, #489. Fix proposed in #483 (kept open, not duplicated here).

[omnilink-tech]

On the regression test in "Next steps" — the awkward part of asserting
URDF-RNE against DH-RNE is that if they disagree, the test says they disagree
but not which one is wrong. #483 was verified against Pinocchio, which is one
independent implementation; a second would let the test assert against an
external reference rather than against the toolbox's other path.

I can offer that, and I have verified the instrument on precisely the shape this
issue is about before offering it.

The instrument, checked against closed form

A fixed structural link between world and the first actuated joint — no joint
attaches mount, so it is exactly the "structural link before the first real
joint" case. Gravity torque from MuJoCo's mj_rne with qacc = 0, against the
analytic -m g r cos(q) for a 1 kg point mass at r = 0.30 m hanging off a
3 kg fixed mount:

   q (rad)      mj_rne tau        analytic             abs err
   +0.0000       -2.943000000      -2.943000000        4.44e-16
   +0.5000       -2.582725480      -2.582725480        4.44e-16
   -1.2000       -1.066418871      -1.066418871        2.22e-16
   +1.5708       -0.000000079      -0.000000079        3.44e-16

mj_fullM -> M = [[0.090001]]
analytic   I_yy + m r^2 = 0.09000100

So on the failing topology the third implementation agrees with closed form to
machine precision, for both the gravity torque and the joint-space inertia.

What I could hand over

A table of gravity torques (N·m) and mass-matrix entries (kg·m²) for the URDF
Panda and KinovaGen3 at named configurations — including the exact one in your
report, q = [-1.649, -0.107, 0, 0, 0, 0, 0] with gravity = [9.81, 0, 0] —
computed from the compiled model, independent of both the toolbox and Pinocchio.
That gives the regression test a fixed external reference, so it can assert
correctness rather than agreement, and it would not silently pass if both
paths were wrong in the same way.

What I need for that, and could not find myself: the exact URDF the toolbox
loads. It is not in this repository, and I could not locate the data package
that ships it, so I have deliberately not guessed with a different Panda
description — the link inertias and the base-mount structure are exactly the
thing under test here, and a nearly-right model would produce numbers that look
authoritative and are not. If you point me at the file (or the package name), I
will run the table and post it.

Two smaller notes from reading the issue:

• The KinovaGen3 symptom you describe — ~1e-8 to ~1e-3 rather than exact
  zeros — is consistent with the structural link's contribution being dropped
  while numerical residue from the rest of the chain survives, which matches
  Proposed fixes for RNE with fixed joints give incorrect results #483's diagnosis rather than being a separate bug.
• Worth including a non-zero qdd case in the regression test as well as
  the gravity-only one. A dropped link's mass shows up in the gravity term, but
  a dropped inertia tensor only shows up under acceleration, and the two
  failure modes are separable.

Happy to be told this is not the reference you want — Pinocchio is a perfectly
good one and a third may be redundant. Offering it because the issue notes
#483's verification rests on a single external check.