Summary
The physics_driven_joints requirement DJ.007 (mimic-api-check) hard-fails any mimic joint whose naturalFrequency is 0. However, 0 is the PhysxMimicJointAPI schema default, and NVIDIA's own PhysX "Mimic Joint" demo relies on that default. As we understand it, naturalFrequency = 0 is the perfectly rigid (solver-enforced, zero-compliance) mimic mode, so DJ.007 appears to forbid rigid mimic couplings entirely. We'd like to understand whether that is intentional.
Where the rule is
nv_core/sr_specs/docs/capabilities/physics_bodies/physics_driven_joints/requirements/mimic-api-check.md (DJ.007):
gearing and naturalFrequency must be non-zero; dampingRatio may be zero (info)
and the validator .../physics_driven_joints/validation.py, class MimicAPICheck:
if natural_frequency == 0:
self._AddFailedCheck(
requirement=cap.PhysicsDrivenJointsRequirements.DJ_007,
message=f"Joint {prim.GetPath()} has natural frequency == 0",
at=prim,
)
Why this looks inconsistent
Schema default is 0. In PhysxSchema, physxMimicJoint::naturalFrequency defaults to 0, documented as "The natural frequency of mimic joint compliance." A default that always fails an essential check is surprising.
NVIDIA's own demo uses 0. The omni.physx.demos MimicJointDemo applies PhysxMimicJointAPI setting only gearing and offset, leaving naturalFrequency at its default 0 — and the joints couple correctly. That demonstrates 0 is a valid, functional configuration (specifically the rigid, non-compliant one), yet DJ.007 rejects it.
It removes the only perfectly-rigid option. Our understanding is that naturalFrequency = 0 gives a rigid, solver-enforced equality constraint, while any positive value introduces a compliant spring (stiffer as the value grows, but never perfectly rigid). If correct, DJ.007 makes it impossible to author a perfectly rigid mimic in a conformant asset — you can only approximate rigidity with a high naturalFrequency. The obvious physical alternative (a real closed kinematic loop) is separately blocked by DJ.011 (no-articulation-loops), so there appears to be no conformant way to express a truly rigid closed-chain coupling.
Questions
Is forbidding naturalFrequency == 0 intentional, and if so, what's the rationale — is the goal to disallow perfectly rigid mimics for cross-engine portability / articulation stability?
If a near-rigid coupling is the intended pattern, what naturalFrequency do you recommend? Is the 100 in the mimic-api-check.md example a recommendation or just illustrative? (The example comment says it "has to be a natural number" — is a specific type/range expected?)
Given the conflict, should the schema default change to a non-zero value, and/or should the MimicJointDemo be updated, so the default configuration is conformant?
Is there a supported way to author a rigid mimic (or rigid closed-chain coupling) that passes both DJ.007 and DJ.011?
Environment
Spec: NVIDIA/simready-foundation @ 0ed0dfb
Validator: simready-validate==2026.4.9
Runtime: Isaac Sim 6 / omni.usd.schema.physx 110.1.13
Summary
The physics_driven_joints requirement DJ.007 (mimic-api-check) hard-fails any mimic joint whose naturalFrequency is 0. However, 0 is the PhysxMimicJointAPI schema default, and NVIDIA's own PhysX "Mimic Joint" demo relies on that default. As we understand it, naturalFrequency = 0 is the perfectly rigid (solver-enforced, zero-compliance) mimic mode, so DJ.007 appears to forbid rigid mimic couplings entirely. We'd like to understand whether that is intentional.
Where the rule is
nv_core/sr_specs/docs/capabilities/physics_bodies/physics_driven_joints/requirements/mimic-api-check.md (DJ.007):
gearing and naturalFrequency must be non-zero; dampingRatio may be zero (info)
and the validator .../physics_driven_joints/validation.py, class MimicAPICheck:
Why this looks inconsistent
Schema default is 0. In PhysxSchema, physxMimicJoint::naturalFrequency defaults to 0, documented as "The natural frequency of mimic joint compliance." A default that always fails an essential check is surprising.
NVIDIA's own demo uses 0. The omni.physx.demos MimicJointDemo applies PhysxMimicJointAPI setting only gearing and offset, leaving naturalFrequency at its default 0 — and the joints couple correctly. That demonstrates 0 is a valid, functional configuration (specifically the rigid, non-compliant one), yet DJ.007 rejects it.
It removes the only perfectly-rigid option. Our understanding is that naturalFrequency = 0 gives a rigid, solver-enforced equality constraint, while any positive value introduces a compliant spring (stiffer as the value grows, but never perfectly rigid). If correct, DJ.007 makes it impossible to author a perfectly rigid mimic in a conformant asset — you can only approximate rigidity with a high naturalFrequency. The obvious physical alternative (a real closed kinematic loop) is separately blocked by DJ.011 (no-articulation-loops), so there appears to be no conformant way to express a truly rigid closed-chain coupling.
Questions
Is forbidding naturalFrequency == 0 intentional, and if so, what's the rationale — is the goal to disallow perfectly rigid mimics for cross-engine portability / articulation stability?
If a near-rigid coupling is the intended pattern, what naturalFrequency do you recommend? Is the 100 in the mimic-api-check.md example a recommendation or just illustrative? (The example comment says it "has to be a natural number" — is a specific type/range expected?)
Given the conflict, should the schema default change to a non-zero value, and/or should the MimicJointDemo be updated, so the default configuration is conformant?
Is there a supported way to author a rigid mimic (or rigid closed-chain coupling) that passes both DJ.007 and DJ.011?
Environment
Spec: NVIDIA/simready-foundation @ 0ed0dfb
Validator: simready-validate==2026.4.9
Runtime: Isaac Sim 6 / omni.usd.schema.physx 110.1.13