All four feet on both quadrupeds declare a mass and a collision sphere, and an
inertia tensor that no rigid body can have.
Lite3 (Lite3/urdf/Lite3.urdf:121, and FR/HL/HR at 224/326/428):
<link name="FL_FOOT">
<collision><geometry><sphere radius="0.022"/></geometry></collision>
<inertial><mass value="0.02"/>
<inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0"/></inertial>
</link>A solid sphere of that radius at that mass is
I = (2/5) m r^2 = 0.4 * 0.02 * 0.022^2 = 3.872e-06 kg m^2
The declared tensor is all zeros -- eigenvalues (0, 0, 0), not positive
definite.
X30 (X30/urdf/X30.urdf:129, +237/346/454): mass 0.06, sphere radius 0.036,
diaginertia = 1e-12. The solid-sphere value is
0.4 * 0.06 * 0.036^2 = 3.1104e-05 kg m^2
so the declared value is 3.11e7 times too small. The four LIDAR_* links
carry mass 1e-05 with an all-zero tensor as well.
The correct values are computable from the links' own collision geometry --
the two numbers above -- so no CAD lookup is needed if the feet really are
approximately solid spheres.
One caveat worth stating, because it decides whether this matters. A
zero-inertia body on a fixed joint is harmless if the consumer merges it into
its parent. But the joint immediately below carries dont_collapse="true":
<joint name="FL_Ankle" type="fixed" dont_collapse="true">
which is an explicit instruction to importers not to merge it. So the model
asks for the foot to be kept as an independent body and gives it a singular
inertia. Whichever half is intended, the two disagree, and consumers differ on
what they do about it -- MuJoCo's compiler and Drake reject a non-PD tensor,
while some importers silently substitute a bounding-volume inertia and others
integrate it as-is.
Also worth noting the MJCF siblings repeat the same values (Lite3.xml
diaginertia="0.0 0.0 0.0", X30.xml 1e-12), so this is not a URDF-only
transcription slip and fixing one file would leave the other wrong. I checked
that specifically because I had expected the MJCF to be the recovery source.
Found while running a URDF preflight over published quadruped descriptions;
the checks are open source, so the arithmetic above is reproducible on your side
without adopting anything of ours.
All four feet on both quadrupeds declare a mass and a collision sphere, and an
inertia tensor that no rigid body can have.
Lite3 (
Lite3/urdf/Lite3.urdf:121, and FR/HL/HR at 224/326/428):A solid sphere of that radius at that mass is
The declared tensor is all zeros -- eigenvalues (0, 0, 0), not positive
definite.
X30 (
X30/urdf/X30.urdf:129, +237/346/454): mass 0.06, sphere radius 0.036,diaginertia = 1e-12. The solid-sphere value isso the declared value is 3.11e7 times too small. The four
LIDAR_*linkscarry mass 1e-05 with an all-zero tensor as well.
The correct values are computable from the links' own collision geometry --
the two numbers above -- so no CAD lookup is needed if the feet really are
approximately solid spheres.
One caveat worth stating, because it decides whether this matters. A
zero-inertia body on a
fixedjoint is harmless if the consumer merges it intoits parent. But the joint immediately below carries
dont_collapse="true":which is an explicit instruction to importers not to merge it. So the model
asks for the foot to be kept as an independent body and gives it a singular
inertia. Whichever half is intended, the two disagree, and consumers differ on
what they do about it -- MuJoCo's compiler and Drake reject a non-PD tensor,
while some importers silently substitute a bounding-volume inertia and others
integrate it as-is.
Also worth noting the MJCF siblings repeat the same values (
Lite3.xmldiaginertia="0.0 0.0 0.0",X30.xml1e-12), so this is not a URDF-onlytranscription slip and fixing one file would leave the other wrong. I checked
that specifically because I had expected the MJCF to be the recovery source.
Found while running a URDF preflight over published quadruped descriptions;
the checks are open source, so the arithmetic above is reproducible on your side
without adopting anything of ours.