DeepRoboticsLab / DeepRoboticsLab/deep_robotics_model
Lite3 and X30 feet declare a singular inertia tensor on the links that take every ground contact
Nessuno ha ancora preso questa issue.
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 77
- Fork
- 14
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
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.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Inizia dai link dei piedi nelle posizioni indicate in Lite3/urdf/Lite3.urdf e X30/urdf/X30.urdf, quindi confronta la loro geometria di collisione e le dichiarazioni di inerzia con Lite3.xml e X30.xml. Controlla i giunti della caviglia con dont_collapse="true" e i link LIDAR_*; il lavoro è completato quando le descrizioni URDF e MJCF usano in modo coerente inerzie valide e superano il preflight URDF indicato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Ambito
- robotics
- Tipo di issue
- Bug
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Stato di attività
- Attiva
- Chiarezza
- Specificata chiaramente
- Idoneità per principianti
- 72/100