Rviz2: finger has unrealistic inertia, so the equivalent inertia box will not be shown

[ggorjup]

Describe the problem you got

I cloned the main branch (commit c5a1e33) on ROS 2 Jazzy.

I visualize the robot with:

ros2 launch openarm_description display_openarm.launch.py arm_type:=v10 bimanual:=true

Rviz throws errors for the finger inertias:

The link openarm_left_left_finger has unrealistic inertia, so the equivalent inertia box will not be shown.
The link openarm_left_right_finger has unrealistic inertia, so the equivalent inertia box will not be shown.
The link openarm_right_left_finger has unrealistic inertia, so the equivalent inertia box will not be shown.
The link openarm_right_right_finger has unrealistic inertia, so the equivalent inertia box will not be shown.

The error disappears if xy, xz, and yz are set to 0.0 here, but I'm not sure if that's an appropriate solution since the finger is asymmetric and probably has non-zero products of inertia.
A value of 1e-7 works as well, but that is again just a guessed number.

[abetomo]

I tried it as well, and indeed there was no error when xy, xz, and yz were set to 0.
The commented‑out configuration has the values set to 0.

openarm_description/config/hand/openarm_hand/inertials.yaml

Lines 52 to 68 in 73ca62f

	# left_finger: &finger
	# origin:
	# x: 00064528
	# y: 0.017020
	# z: 0.0219685
	# roll: 0
	# pitch: 0
	# yaw: 0
	# mass: 0.03602545343277134
	# inertia:
	# xx: 2.3749999999999997e-06
	# yy: 2.3749999999999997e-06
	# zz: 7.5e-07
	# xy: 0
	# xz: 0
	# yz: 0
	# right_finger: *finger

[omnilink-tech]

The blocker in this thread seems to be the sentence "that is again just a
guessed number", so here is the interval rather than another guess.

The admissible range

For the finger's declared diagonal (2.375e-06, 2.375e-06, 7.5e-07), the
largest equal-magnitude off-diagonal that still describes a physical rigid body
is

p_max = 2.90569e-07

Checked against that bound:

|off-diagonal|   verdict
1e-06            REJECTED   (as shipped -- exceeds the bound by 3.44x)
3e-07            REJECTED
2e-07            admissible
1e-07            admissible  (the value suggested above, with ~47% margin)

So 1e-7 is not merely "it works" -- it is comfortably inside the physical
range, and anything up to 2.9e-07 would be too. The asymmetry concern is
well-founded; it just does not extend as far as 1e-06.

Cross-checked with MuJoCo 3.11.0 on the same numbers, which agrees:

off-diag 1e-06     -> Error: inertia must satisfy A + B >= C; use 'balanceinertia' to fix
off-diag 2.9e-07   -> compiles
off-diag 0         -> compiles

Why this is a load failure, not a cosmetic one

Parsing assets/robot/openarm_v1.0/urdf/example/v1.urdf and taking eigenvalues
of the finger tensor as shipped:

openarm_left_left_finger   m=0.0360255
  principal moments = (1.3308137e-07, 1.375e-06, 3.9919186e-06)
  A + B = 1.5080814e-06  <  C = 3.9919186e-06     deficit 62.22%

Same for openarm_left_right_finger, openarm_right_left_finger and
openarm_right_right_finger. MuJoCo refuses the file outright, so this is not
an RViz nicety -- the description will not load in a MuJoCo-family consumer at
all.

The intended values appear to be in the file already

assets/end_effector/parallel_link/config/inertials.yaml declares the live
values at :45-47 (xy/xz/yz: 1e-06), and twenty lines below, at :66-82,
there is a commented-out &finger anchor carrying the same diagonal with

#     xy: 0
#     xz: 0
#     yz: 0

The 1e-06 reads as a rounding floor from whatever emitted the v1 configs
rather than a measurement -- and the sibling link at :28-30 in the same file
uses 0.0.

Two things worth noting so this reads as targeted rather than a blanket
complaint:

• v2.0 is clean. Its configs carry full CAD precision (e.g.
  ixy="-3.81487993180929e-07"), so only the v1 path is affected, and only the
  fingers are small enough for a 1e-06 floor to break the tensor.
• PR fix finger inertia #47 fixed exactly this (1e-06 -> 0) and was closed unmerged when
  the 2.0 release moved the file layout. Both paths named in that PR's closing
  comment still carry 1e-06 on main today, so the fix was correct and simply
  got lost in the move.

If a non-zero asymmetric value is preferred over 0 on principle, anything at
or below 2.9e-07 is safe; 1e-7 gives comfortable margin.

Happy to send a PR against the current layout if that is useful -- it is a
three-line change in one file, though I do not have the hardware to confirm the
fingers really are near-symmetric, which is your call rather than mine.

[omnilink-tech]

Following up with the patch, since the intended values turn out to be in the
file already.

What it changes

Six lines: xy/xz/yz on the two live finger blocks, 1e-06 -> 0.

That is exactly what the commented-out &finger anchor twenty lines below
declares, with the same mass and the same diagonal:

# left_finger: &finger
#   mass: 0.03602545343277134
#   inertia:
#     xx: 2.3749999999999997e-06
#     yy: 2.3749999999999997e-06
#     zz: 7.5e-07
#     xy: 0
#     xz: 0
#     yz: 0
# right_finger: *finger

so this is restoring the file's own stated intent rather than substituting a
value of mine. The commented block is left untouched.

Before and after

BEFORE  eig=[1.33081370e-07 1.37500000e-06 3.99191863e-06]   a+b=1.508081e-06 < c=3.991919e-06   VIOLATED by 62.22 percent
AFTER   eig=[7.500e-07        2.375e-06      2.375e-06     ]   a+b=3.125000e-06 > c=2.375000e-06   OK

MuJoCo refuses the current values (inertia must satisfy A + B >= C) and
compiles the patched ones.

Scope: this is the fingers only, and I checked

I ran the same triangle-inequality check over
assets/robot/openarm_v1.0/config/arm/inertials.yaml, which carries nine more
1e-06 entries from the same rounding floor. None of them violate — 0 of 8
links. The floor only breaks the tensor where the diagonal is small enough for
1e-06 to be comparable to it, which is true of the fingers and of nothing
else. So this is a targeted fix rather than a repo-wide sweep, and the arm
values can be left alone.

git apply openarm-finger-inertia.patch

openarm-finger-inertia.patch

diff --git a/assets/end_effector/parallel_link/config/inertials.yaml b/assets/end_effector/parallel_link/config/inertials.yaml
--- a/assets/end_effector/parallel_link/config/inertials.yaml
+++ b/assets/end_effector/parallel_link/config/inertials.yaml
@@ -42,9 +42,9 @@
     xx: 2.3749999999999997e-06
     yy: 2.3749999999999997e-06
     zz: 7.5e-07
-    xy: 1e-06
-    xz: 1e-06
-    yz: 1e-06
+    xy: 0
+    xz: 0
+    yz: 0
 
 right_finger:
   origin:
@@ -59,9 +59,9 @@
     xx: 2.3749999999999997e-06
     yy: 2.3749999999999997e-06
     zz: 7.5e-07
-    xy: 1e-06
-    xz: 1e-06
-    yz: 1e-06
+    xy: 0
+    xz: 0
+    yz: 0
 
 # left_finger: &finger
 #   origin:

If you would rather keep a small non-zero asymmetric value than exactly zero —
which was the concern raised earlier in this thread — anything up to
2.9e-07 is admissible for this diagonal, and I can redo the patch with
whichever value you prefer.