Repository navigation
Rotate a rotated inertial origin's tensor and a rotated prismatic origin's translation; pinocchio oracle over every fixture - #7
Merged
Conversation
… a prismatic joint's translation through its origin; pinocchio oracle over every fixture
…s joints use the cos-sin configuration
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two rotation-direction bugs found through the UR5e, and a pinocchio oracle over every fixture so this class cannot recur silently.
Rotated inertial origin.
Link.build_spatial_inertiaapplied the parallel-axis term for an<inertial><origin>translation but never the origin's rotation, so a tensor written in a rotated inertial frame was taken as if it were in the link frame. The link-frame tensor isE^T I Ewith the parser's FeatherstoneE = R^T, equivalentlyR I R^Twith URDF'sR = Rz Ry Rx. On the UR5e, whose shoulder and wrists use rpy of plus or minus pi/2 about x, the generated dynamics were 7 to 10 percent off pinocchio on every inertia probe. None of GRiD's ten shipped robots rotates an inertial origin, so every shipped header regenerates byte-identical.Prismatic joint with a rotated origin. The single-DOF homogeneous transform rotated the joint's variable translation by
Einstead ofE^T, mirroring a prismatic joint's child whenever its<origin>carries a rotation. The 6x6 motion transforms, and so the dynamics, were right; only the homogeneous path used by the end-effector pose was wrong. GRiD's one shipped instance, fr3_finger_joint2, has a yaw of pi whose rotation is its own transpose, which is why no receipt could see it.Oracle.
tests/test_inertia_oracle.pychecks every fixture pinocchio's URDF reader can build: each body's mass, first moment and tensor about the joint origin againstmodel.inertias, with fixed-joint children folded on both sides and a decomposed planar joint mapped through its link's frame, and each joint frame's world placement at random configurations, with continuous joints fed as (cos, sin) and a decomposed planar joint as pinocchio's [x, y, cos, sin]. The oracle is built from the URDF with every rpy snapped to the quarter-turn grid the parser snaps joint origins to, the way RBDReference's pinocchio backend does, so both sides model the same robot. Fixtures with no URDF oracle are listed statically with the reason: helical, spherical and translation joints are parser extensions, and pinocchio's URDF reader ignores a planar joint's axis. A new fixture,rotated_inertial_arm.urdf, has rotated and offset inertial origins with full tensors, a prismatic joint with a rotated origin, a massive child behind a fixed joint and hyphenated joint names.Verification: 87 tests pass with pinocchio 3.9.0; GRiD's CPU lane passes against this branch with the same oracle over its ten shipped robots.
🤖 Generated with Claude Code