physics_driven_joints: DJ.001 crashes on mimic joints, DJ.007 rejects prismatic mimic axes, DJ.004 unsatisfiable for PhysX linear couplings

[johnnynunez]

Summary

Validating a robot with a coupled parallel gripper (one motor, two opposed racks, so the two finger joints are rigidly 1:1) surfaces three separate problems in physics_driven_joints. The first is a crash, the second makes the requirement unsatisfiable for linear joints, and the third asks for an asset configuration that PhysX does not currently honour.

All three are reproducible with small standalone scripts; none need the original robot.

Environment: simready-foundation @ main, simready-validate 2026.4.9, omniverse-asset-validator 1.18.0, Isaac Sim 6.1 (PhysX 110.1.13), Linux aarch64.

---

1. DJ.001 crashes on any joint carrying PhysxMimicJointAPI

nv_core/sr_specs/docs/capabilities/physics_bodies/physics_driven_joints/validation.py:

255  for drive, joint_state in zip(drives, joint_states):
256      stiffness = drive.GetStiffnessAttr().Get()      # -> float
257      damping = drive.GetDampingAttr().Get()          # -> float
258      if (stiffness and stiffness.Get() != 0.0) or (damping and damping.Get() != 0.0):
                                ^^^^^^^^^^^^^^^ float has no .Get()

Lines 256–257 already resolve the attributes to floats; line 258 calls .Get() on the float. Reported as:

Uncaught error: 'float' object has no attribute 'Get'
FET022_DRIVEN_JOINTS_NEUTRAL: failing requirements: ['DJ.001']

The branch is only reachable when a joint has PhysxMimicJointAPI and non-zero drive gains, which is presumably why it has gone unnoticed — it needs a coupled mechanism (parallel gripper, differential, belt drive) to trigger.

The same expression appears twice, at line 258 (neutral) and line 535 (PhysX variant). Line 621 uses stiffness.Get() correctly, because there stiffness is the attribute.

Suggested fix:

if (stiffness and stiffness != 0.0) or (damping and damping != 0.0):

With that one-line change applied locally, our asset goes from [FAILED] to [PASSED] on Robot-Body-Neutral.

Minimal reproducer (builds a 2-joint stage from scratch)

from pxr import PhysxSchema, Usd, UsdGeom, UsdPhysics

stage = Usd.Stage.CreateNew("/tmp/mimic.usda")
root = UsdGeom.Xform.Define(stage, "/Robot")
stage.SetDefaultPrim(root.GetPrim())
UsdPhysics.ArticulationRootAPI.Apply(root.GetPrim())

base = UsdGeom.Cube.Define(stage, "/Robot/base")
UsdPhysics.RigidBodyAPI.Apply(base.GetPrim())

for name in ("left", "right"):
    link = UsdGeom.Cube.Define(stage, f"/Robot/{name}")
    UsdPhysics.RigidBodyAPI.Apply(link.GetPrim())
    joint = UsdPhysics.PrismaticJoint.Define(stage, f"/Robot/joint_{name}")
    joint.CreateBody0Rel().SetTargets([base.GetPath()])
    joint.CreateBody1Rel().SetTargets([link.GetPath()])
    joint.CreateAxisAttr().Set("Z")
    drive = UsdPhysics.DriveAPI.Apply(joint.GetPrim(), "linear")
    drive.CreateStiffnessAttr().Set(5000.0)      # non-zero: reaches line 258
    drive.CreateDampingAttr().Set(41.28)
    drive.CreateMaxForceAttr().Set(1904.0)
    PhysxSchema.JointStateAPI.Apply(joint.GetPrim(), "linear")

follower = stage.GetPrimAtPath("/Robot/joint_right")
mimic = PhysxSchema.PhysxMimicJointAPI.Apply(follower, "Z")
mimic.CreateReferenceJointRel().SetTargets([stage.GetPrimAtPath("/Robot/joint_left").GetPath()])
mimic.CreateGearingAttr().Set(-1.0)
stage.GetRootLayer().Save()

# now: simready-validate /tmp/mimic.usda --profile Robot-Body-Neutral --version 1.0.0

Result: mimic absent -> rule passes, mimic present -> AttributeError: 'float' object has no attribute 'Get'.

---

2. DJ.007 cannot be satisfied by a prismatic mimic joint

Lines 664–676 match the mimic axis against rotational tokens only:

match axis:
    case "rotX": ...
    case "rotY": ...
    case "rotZ": ...
    case _:
        self._AddFailedCheck(
            requirement=DrivenJointsCapReq.DJ_007,
            message=f"Joint {prim.GetPath()} has unknown mimic axis: {axis}, aborting checks",

A linear coupled DOF — which is what a parallel gripper is — authors transX/transY/transZ (or the X/Y/Z short form). UsdPhysics.Tokens defines transX, transY, transZ, PhysxSchema.PhysxMimicJointAPI.Apply() accepts them, and PhysX's own Newton migration checker explicitly documents mimic support for PhysicsPrismaticJoint:

NewtonMimicAPI is single-apply per joint and supports single-DOF followers and leaders only (PhysicsRevoluteJoint / PhysicsPrismaticJoint).

So today no parallel-jaw gripper can pass FET022_DRIVEN_JOINTS_PHYSX/_ISAAC, regardless of how it is authored. Adding transX/transY/transZ (and the short X/Y/Z spelling) to the match would close it.

---

3. DJ.004 asks for zero gains, but PhysX does not enforce a prismatic mimic

DJ.004 fails a joint that has both a mimic API and non-zero drive gains:

Joint .../joint_right has both drive and mimic API

For a revolute follower that is the correct model — one motor, one drive, the constraint carries the other DOF. We applied it, then measured the result in Isaac Sim 6.1:

follower drive	finger deviation	left/right asymmetry
0 / 0 (DJ.004 compliant)	51.50 mm	51.50 mm
5000 / 41.28	0.006 mm	0.012 mm
500 / 4.13	0.092 mm	0.097 mm

A follow-up A/B shows why: on a prismatic joint, PhysX does not enforce PhysxMimicJointAPI at all. Removing the API entirely produces numbers identical to four decimal places:

case	mimic	slew deviation	asymmetry	leader → 40 mm	follower
mimic + follower drive	True	0.0064 mm	0.0123 mm	40.000	20.000
no mimic + follower drive	False	0.0064 mm	0.0123 mm	40.000	20.000
mimic + zero gains	True	51.5009 mm	51.4996 mm	40.000	0.941
no mimic + zero gains	False	51.5009 mm	51.4996 mm	40.000	0.941

The same probe on a revolute pair does show the constraint acting. So DJ.004 is right in general and wrong for linear DOFs on PhysX: complying makes the gripper physically worse than the bug it was authored to fix.

Newton (NewtonMimicAPI) and MuJoCo (<equality joint>) both honour the coupling, so an asset that must work across all three ends up keeping the constraint and the drive — which DJ.004 rejects.

Suggestion: scope DJ.004 to DOF types where the runtime actually enforces the constraint, or downgrade it to a warning when the follower is prismatic.

---

Why this came up

We are bringing Seeed-Projects/reBot-Isaacsim into SimReady conformance. The arm's gripper is a single RobStride motor driving two opposed racks through one pinion, so the two finger joints are rigidly coupled — modelling them as independent DOFs let the jaws drift 2.3 mm under arm motion and sag 7.4 mm under gravity.

With items 1–3 addressed, Robot-Body-Neutral passes. Happy to test any proposed fix against the asset and against the standalone reproducers.

---

Separately, and possibly worth its own issue: the validate venv installs usd-exchange, whose pxr build does not ship PhysxSchema. Every rule that touches PhysxSchema.JointStateAPI / PhysxMimicJointAPI then reports "PhysxSchema is not available in this environment" as a FAILURE rather than skipping or erroring loudly — on this asset that was 161 messages, and DJ.001/DJ.002/DJ.003 all reported as failing requirements when the asset satisfied two of them. Running the same validator against a pxr that does provide PhysxSchema cleared DJ.002 and DJ.003 immediately.

[johnnynunez]

Follow-up on item 3 (DJ.004) with a cleaner isolation, plus two more environment findings that affect how this validator's results should be read.

DJ.004: the constraint is not enforced, so zeroing the gains uncouples the mechanism

The earlier table showed identical numbers with and without PhysxMimicJointAPI. Here is the direct version, built from scratch: leader driven, follower with no drive gains, gearing = -1 (constraint is q_follower − q_leader = 0), gravity off so nothing but the mimic can move the follower.

joint type	mimic axis	leader	follower	limit	result
prismatic	(none)	0.0299	-0.0000	0.05	not enforced
prismatic	Z	0.0299	-0.0000	0.05	not enforced
prismatic	transZ	0.0299	-0.0000	0.05	not enforced
revolute	(none)	30.0000	0.0000	90.0	not enforced
revolute	rotZ	30.0000	30.0000	90.0	enforced ✔

The revolute row is the control. On PhysX, a prismatic mimic is a silent no-op, so DJ.004's "zero the follower's drive gains" leaves a linear coupled mechanism with nothing holding it together — measured on a real parallel gripper, 51.5 mm of finger deviation versus 0.006 mm with the drive kept.

Reported to Isaac Sim as isaac-sim/IsaacSim#731. That does not change the DJ.004 request itself, which is correct for revolute followers; it means the requirement cannot currently be satisfied and remain physically correct for prismatic ones.

Two more runtime gaps that turn into false requirement failures

Same class as the PhysxSchema problem noted at the end of the original report — a missing module is reported as a failing requirement rather than as a skip or an environment error:

missing module	rules affected	message
PhysxSchema	DJ.001, DJ.002, DJ.003	PhysxSchema is not available in this environment
usd.schema.isaac	RC.007, DJ.008, DJ.009, DJ.010	No module named 'usd.schema.isaac'
omni.client	RC.001, RC.004	module 'omni' has no attribute 'client'

usd.schema.isaac ships with the Isaac Sim build (exts/isaacsim.robot.schema) rather than with the validator, and omni.client likewise (extscache/omni.client-*). Neither has an aarch64 wheel on PyPI, same as usd-core.

On our asset this mattered a lot. Putting PhysxSchema and usd.schema.isaac on the path took seven requirements from FAILED to PASSED without touching the asset: DJ.002, DJ.003, RC.007, DJ.008, DJ.009, DJ.010 — plus DJ.001 once the .Get() crash from item 1 is patched. RC.001 and RC.004 remain unknown rather than failing: the asset root holds only the interface layer and the thumbnail exists at .thumbs/256x256/<asset>.png, but the rules cannot run to confirm it.

Suggestion: treat an import failure inside a rule as an environment error that aborts the run (or an explicit SKIP), never as a requirement failure. As it stands a validation report can state that an asset fails ten requirements it actually satisfies, which is hard to distinguish from a genuine failure without reading the verbose log.

For anyone hitting this on aarch64: installing omniverse-asset-validator, omniverse-usd-profiles and simready-validate --no-deps into a venv without usd-core, then running them on the Isaac Sim USD runtime (kit/python/bin/python3, with omni.usd.libs, omni.usd.schema.physx, isaacsim.robot.schema and omni.client on PYTHONPATH/LD_LIBRARY_PATH and every plugInfo.json directory in PXR_PLUGINPATH_NAME) provides all three. Dropping the Isaac PhysX schema into the usd-exchange venv does not work — its libraries are hash-suffixed (libusd_tf-310cf8b1.so) and the import fails on libusd_tf.so: cannot open shared object file.

Where the asset landed

With items 1–3 understood and the runtime gaps closed, Robot-Body-Neutral passes. ISA.001, RC.005, RC.007, BA.002, DJ.001, DJ.002, DJ.003, DJ.008, DJ.009 and DJ.010 all pass now and all failed before. What remains is DJ.004/DJ.006/DJ.007 (the prismatic mimic issue) and RC.001/RC.004 (blocked on omni.client).

Two authoring notes that may be worth documenting, since both took measurement to pin down:

• ISA.001 vs a neutral physics variant. ISA.001 reads prim_spec.payloadList on the default prim in the root layer, so a payload authored inside a variant does not satisfy it — but a root-prim payload composes under every variant selection, so Physics=none then carries the full physics stack. Both hold only if the neutral variant explicitly subtracts what the payload adds.
• RC.005 and the PhysicsScene. Three placements were measured, none satisfying every constraint: interface layer (composes, fails RC.005), physics-layer root (never composes — a payload arc maps only the defaultPrim subtree), physics layer under the robot prim (composes, passes RC.005, but leaks into any stage referencing the robot). We followed the reference SimReady robot (sample_content/.../Robotiq/2F-85) and author no scene at all, leaving gravity to the consuming stage.

[johnnynunez]

Confirmed against 2026.06.0 (0ed0dfb), as requested. All three findings reproduce; the release refactored physics_driven_joints/validation.py substantially (78 insertions, 150 deletions, moving from omni.asset_validator to usd_validation_nvidia + omni.capabilities) but did not touch these paths.

1. DJ.001 still crashes on any mimic joint

The .Get() call on an already-resolved float survived the refactor verbatim, now at lines 188 and 463:

stiffness = drive.GetStiffnessAttr().Get()      # already a float
damping = drive.GetDampingAttr().Get()
if (stiffness and stiffness.Get() != 0.0) or (damping and damping.Get() != 0.0):

Running the 6-DOF arm with a coupled parallel gripper against 2026.06.0:

[FAILED] Robot-Body-Neutral v1.0.0
         FET022_DRIVEN_JOINTS_NEUTRAL: failing requirements: ['DJ.001']
Message: Uncaught error: 'float' object has no attribute 'Get'

Comparing the floats directly (stiffness != 0.0) is enough for the asset to reach [PASSED] Robot-Body-Neutral v1.0.0 on this release.

2. DJ.007 still rejects prismatic mimic axes

Line 593 onward still matches only rotational tokens, so a linear coupled gripper cannot pass:

case "rotX":
    mimic_api = PhysxSchema.PhysxMimicJointAPI(prim, UsdPhysics.Tokens.rotX)
...
message=f"Joint {prim.GetPath()} has unknown mimic axis: {axis}, aborting checks"

UsdPhysics.Tokens defines transX/transY/transZ, and PhysxSchema.PhysxMimicJointAPI.Apply() accepts Z, transZ and linear without complaint.

3. DJ.004 remains unsatisfiable for PhysX linear couplings

Unchanged, and the underlying PhysX behaviour is now filed separately as isaac-sim/IsaacSim#731: PhysxMimicJointAPI is a silent no-op on prismatic joints. Verified with a from-scratch reproducer — leader driven, follower with no drive gains, gearing = -1, gravity off:

joint type	mimic axis	leader	follower	result
prismatic	Z	0.0299	-0.0000	not enforced
prismatic	transZ	0.0299	-0.0000	not enforced
revolute	rotZ	30.0000	30.0000	enforced ✔

The revolute row is the control. So zeroing a prismatic follower's gains to satisfy DJ.004 leaves the mechanism uncoupled — measured on a real parallel gripper, 51.5 mm of finger deviation versus 0.006 mm with the drive kept.

Status on 2026.06.0 after the one-line DJ.001 fix

Robot-Body-Neutral    PASSED
Robot-Body-Runnable   FAILED  DJ.004, DJ.006, DJ.007
Robot-Body-Isaac      FAILED  DJ.004, DJ.006, DJ.007, RC.001, RC.004

The remaining driven-joint failures are all items 2 and 3. RC.001/RC.004 are the omni.client environment gap noted below.

Packaging notes from validating against this release

Two practical points, in case they are useful for the release:

simready-validate on PyPI is still 2026.4.9, which expects --profiles-path to be a single profiles.toml. 2026.06.0 splits profiles into one TOML per profile (robot_body_neutral.toml, ...), so the published CLI fails with IsADirectoryError against the new layout unless an individual file is passed. Passing one profile TOML works fine.

Rule import failures are still reported as requirement failures. With usd_validation_nvidia now required by the capability modules, a missing dependency surfaces as a failing requirement rather than an environment error. Same class as the PhysxSchema case in the original report: on this host PhysxSchema, usd.schema.isaac and omni.client were each absent from the validator venv, and putting the first two on the path moved seven requirements from FAILED to PASSED without touching the asset (DJ.002, DJ.003, RC.007, DJ.008, DJ.009, DJ.010, plus DJ.001 with the fix above). RC.001/RC.004 remain blocked on omni.client, which has no aarch64 wheel — both are satisfied by the asset on inspection (root holds only the interface layer; thumbnail present at .thumbs/256x256/).

Treating an import failure inside a rule as an environment error or explicit SKIP would avoid reports stating an asset fails requirements it actually satisfies.

Environment

• SimReady Foundation 2026.06.0 (0ed0dfb), simready-validate 2026.4.9, usd-validation-nvidia 1.20.0, omniverse-usd-profiles 1.11.2
• Isaac Sim 6.1.0-alpha.26 (source build), omni.physx 110.1.13
• Linux aarch64, NVIDIA GB10 (sm_121), driver 13.0, CUDA 12.9

[johnnynunez]

Re-checked everything against the current tip of main, with a full (non-shallow) clone this time so nothing could be hidden behind --depth 1.

Verified three independent ways that 0ed0dfb really is the latest commit:

$ git ls-remote https://github.com/NVIDIA/simready-foundation.git refs/heads/main
0ed0dfbc539c9de99289771bd6848effe3ef5779   refs/heads/main

$ gh api repos/NVIDIA/simready-foundation/commits/main
0ed0dfbc539c9de99289771bd6848effe3ef5779   2026-08-03T18:26:47Z   SimReady Foundation Release 2026.06.0

and the file I analysed hashes identically to the one served by the GitHub API:

81e4d65c2fb4b2a1047f50003b419080f44b6b26652f6f16374a039b0516d8e5   local  git show origin/main:.../validation.py
81e4d65c2fb4b2a1047f50003b419080f44b6b26652f6f16374a039b0516d8e5   GitHub contents API

Correction to my previous comment: it is 4 call sites, not 2

Re-reading the file line by line rather than grepping for the one pattern I already knew, the same .Get()-on-a-float mistake appears four times, and it affects three requirements, not one:

line	requirement	code
188	DJ.001	if (stiffness and stiffness.Get() != 0.0) or (damping and damping.Get() != 0.0):
463	DJ.004	if (stiffness and stiffness.Get() != 0.0) or (damping and damping.Get() != 0.0):
542	DJ.006	if damping.Get() != 0.0:
549	DJ.006	if stiffness.Get() != 0.0:

In every case the value was already resolved two lines earlier:

stiffness = drive.GetStiffnessAttr().Get()   # float
damping = drive.GetDampingAttr().Get()       # float

Minimal reproducer

No robot asset needed — two bodies, a prismatic pair, a mimic on the follower:

from pxr import PhysxSchema, Usd, UsdGeom, UsdPhysics

stage = Usd.Stage.CreateInMemory()
root = UsdGeom.Xform.Define(stage, "/Robot")
stage.SetDefaultPrim(root.GetPrim())
UsdPhysics.ArticulationRootAPI.Apply(root.GetPrim())
base = UsdGeom.Cube.Define(stage, "/Robot/base")
UsdPhysics.RigidBodyAPI.Apply(base.GetPrim())

for name in ("left", "right"):
    link = UsdGeom.Cube.Define(stage, f"/Robot/{name}")
    UsdPhysics.RigidBodyAPI.Apply(link.GetPrim())
    joint = UsdPhysics.PrismaticJoint.Define(stage, f"/Robot/joint_{name}")
    joint.CreateBody0Rel().SetTargets([base.GetPath()])
    joint.CreateBody1Rel().SetTargets([link.GetPath()])
    joint.CreateAxisAttr().Set("Z")
    joint.CreateLowerLimitAttr().Set(0.0)
    joint.CreateUpperLimitAttr().Set(0.05)
    drive = UsdPhysics.DriveAPI.Apply(joint.GetPrim(), "linear")
    drive.CreateStiffnessAttr().Set(5000.0)      # non-zero reaches the bug
    drive.CreateDampingAttr().Set(41.28)
    PhysxSchema.JointStateAPI.Apply(joint.GetPrim(), "linear")

follower = stage.GetPrimAtPath("/Robot/joint_right")
mimic = PhysxSchema.PhysxMimicJointAPI.Apply(follower, "Z")
mimic.CreateReferenceJointRel().SetTargets([stage.GetPrimAtPath("/Robot/joint_left").GetPath()])
mimic.CreateGearingAttr().Set(-1.0)

drive = UsdPhysics.DriveAPI(follower, "linear")
stiffness = drive.GetStiffnessAttr().Get()
damping = drive.GetDampingAttr().Get()
print(f"stiffness = {stiffness!r} ({type(stiffness).__name__})")
if (stiffness and stiffness.Get() != 0.0) or (damping and damping.Get() != 0.0):
    pass

stiffness = 5000.0  (float)
damping   = 41.279998779296875  (float)
CRASH: 'float' object has no attribute 'Get'

Only reachable when a joint carries PhysxMimicJointAPI and non-zero drive gains, which is why an asset with a coupled gripper is needed to hit it in practice.

Patch

Applies cleanly to 0ed0dfb:

--- a/nv_core/sr_specs/docs/capabilities/physics_bodies/physics_driven_joints/validation.py
+++ b/nv_core/sr_specs/docs/capabilities/physics_bodies/physics_driven_joints/validation.py
@@ -185,7 +185,7 @@ class PhysicsDriveAndJointState(usd_validation_nvidia.BaseRuleChecker):
             for drive, joint_state in zip(drives, joint_states):
                 stiffness = drive.GetStiffnessAttr().Get()
                 damping = drive.GetDampingAttr().Get()
-                if (stiffness and stiffness.Get() != 0.0) or (damping and damping.Get() != 0.0):
+                if (stiffness and stiffness != 0.0) or (damping and damping != 0.0):
                     stop = False
                     break
@@ -460,7 +460,7 @@ class PhysicsJointHasDriveOrMimicAPI(usd_validation_nvidia.BaseRuleChecker):
                 stiffness = drive.GetStiffnessAttr().Get()
                 damping = drive.GetDampingAttr().Get()
-                if (stiffness and stiffness.Get() != 0.0) or (damping and damping.Get() != 0.0):
+                if (stiffness and stiffness != 0.0) or (damping and damping != 0.0):
                     self._AddFailedCheck(
                         requirement=cap.PhysicsDrivenJointsRequirements.DJ_004,
@@ -539,13 +539,13 @@ class PhysicsJointHasDriveOrMimicAPI(usd_validation_nvidia.BaseRuleChecker):
             elif is_mimic:
                 damping = drive.GetDampingAttr().Get()
                 if damping:
-                    if damping.Get() != 0.0:
+                    if damping != 0.0:
                         self._AddFailedCheck(
                             requirement=cap.PhysicsDrivenJointsRequirements.DJ_006,
                 if stiffness:
-                    if stiffness.Get() != 0.0:
+                    if stiffness != 0.0:
                         self._AddFailedCheck(
                             requirement=cap.PhysicsDrivenJointsRequirements.DJ_006,

Before / after on 2026.06.0

Same asset (6-DOF arm, coupled parallel gripper), same command, only the patch differs:

profile	0ed0dfb as-is	with the 4-line patch
Robot-Body-Neutral	FAILED — DJ.001	PASSED
Robot-Body-Runnable	FAILED — DJ.001, DJ.004, DJ.006, DJ.007	FAILED — DJ.004, DJ.006, DJ.007
Robot-Body-Isaac	FAILED — DJ.001, DJ.004, DJ.006, DJ.007, RC.001, RC.004	FAILED — DJ.004, DJ.006, DJ.007, RC.001, RC.004

DJ.001 clears everywhere. The remaining driven-joint failures are the prismatic-mimic items from the original report (DJ.004/DJ.006/DJ.007), and RC.001/RC.004 are the omni.client environment gap.

Happy to open a PR with this if that is easier than patching it your side.

[johnnynunez]

Re-verified everything against the asset as it now sits in Seeed-Projects/reBot-Isaacsim@main (b64fefb), rather than against my own branch — the earlier numbers in this thread were measured pre-merge.

$ git fetch upstream
   6f5061d..b64fefb  main -> upstream/main
$ git log -1 upstream/main
b64fefb  Merge pull request #21 from johnnynunez/fix/gripper-coupling

The validated asset is therefore the merged one, checked out into a clean worktree, not a local copy.

Where the reBot asset stands on 2026.06.0

Same asset, same commands, only the DJ.001 patch from my previous comment differs:

profile	0ed0dfb as-is	with the 4-line patch
Robot-Body-Neutral	FAILED — DJ.001	PASSED
Robot-Body-Runnable	FAILED — DJ.001, DJ.004, DJ.006, DJ.007	FAILED — DJ.004, DJ.006, DJ.007
Robot-Body-Isaac	FAILED — DJ.001, DJ.004, DJ.006, DJ.007, RC.001, RC.004	FAILED — DJ.004, DJ.006, DJ.007, RC.001, RC.004

Identical to what I reported from my branch, so the merge changed nothing about these results. DJ.001 clears on all three profiles with the patch; what remains is the prismatic-mimic family (DJ.004/DJ.006/DJ.007) and the omni.client environment gap (RC.001/RC.004).

Runtime behaviour of the merged asset

For completeness, since a validator pass says nothing about whether the mechanism actually works:

Isaac Sim 6.1 / PhysX     mimic composed: True
                          static  0.00006 mm
                          slewing 0.00629 mm      PASS

validate_physics_fidelity failures: []
                          MJCF compiled and stepped (MuJoCo 3.10.0)

Why DJ.004/DJ.006 cannot be satisfied here

Restating the constraint that makes these three interlock, now that DJ.006 is confirmed to be part of the same code path:

DJ.004 and DJ.006 both require a mimic follower to carry zero drive gains. On this asset the follower is a prismatic joint, and PhysxMimicJointAPI is not enforced by PhysX on prismatic joints (isaac-sim/IsaacSim#731 — verified with a from-scratch A/B where the constraint made no measurable difference, while the revolute control tracked exactly). Zeroing the gains therefore does not hand control to the coupling; it leaves the mechanism uncoupled.

Measured on the real gripper, that difference is 51.5 mm of finger deviation versus 0.006 mm with the drive kept — the asset would validate and the gripper would stop working. So the drive stays, and DJ.004/DJ.006 stay red until either the PhysX behaviour changes or the requirements gain a prismatic path.

DJ.007 is the third leg: it only accepts rotX/rotY/rotZ, so no linear coupled gripper can express its mimic axis at all.

Environment

• Asset: Seeed-Projects/reBot-Isaacsim@b64fefb
• SimReady Foundation 0ed0dfb (2026.06.0), full clone, verified against git ls-remote and the GitHub API
• simready-validate 2026.4.9, usd-validation-nvidia 1.20.0, omniverse-usd-profiles 1.11.2
• Isaac Sim 6.1.0-alpha.26, omni.physx 110.1.13, Linux aarch64 / GB10