Skip to content

feat(schemas): joint-drive schema-fragment API (additive)#8

Draft
vidurv-nvidia wants to merge 5 commits into
vidurv/schema-frag-frameworkfrom
vidurv/schema-frag-jointdrive
Draft

feat(schemas): joint-drive schema-fragment API (additive)#8
vidurv-nvidia wants to merge 5 commits into
vidurv/schema-frag-frameworkfrom
vidurv/schema-frag-jointdrive

Conversation

@vidurv-nvidia

@vidurv-nvidia vidurv-nvidia commented Jun 5, 2026

Copy link
Copy Markdown
Owner

Description

Additive joint-drive fragment family (custom func)

  • core: UsdPhysicsDriveCfg overriding funcapply_drive (multi-instance DriveAPI, rad→deg for angular, drive_typetype, tendon-child guard)
  • physx: PhysxJointCfg (physxJoint:maxJointVelocity); newton: MujocoJointCfg (mjc:actuatorgravcomp)
  • apply_joint_drive_properties(...): DriveAPI presence-gated; ensure_drives_exist is a spawner-level flag.

⚠️ Known divergence to resolve before ready: max_joint_velocity rad→deg conversion is NOT reproduced (it now lives on PhysxJointCfg written by the generic applier, which has no joint-type awareness). For angular-joint parity, PhysxJointCfg needs its own override func. Status: authored, ruff clean, sim verification pending.

Fixes # (N/A — part of the staged physics schema-fragment refactor; no tracked public issue)

Type of change

  • New feature (non-breaking change which adds functionality)

Screenshots

N/A — no user-facing visual changes.

Checklist

  • I have read and understood the contribution guidelines
  • I have run the pre-commit checks (ruff + ruff-format) on the changed files
  • I have made corresponding changes to the documentation (the public API reference is auto-generated via ./isaaclab.sh -d; not separately authored)
  • My changes generate no new warnings
  • I have added tests that prove my feature works
  • I have added a changelog fragment under source/<pkg>/changelog.d/ for every touched package
  • I have added my name to CONTRIBUTORS.md

Add the additive joint-drive schema-fragment framework, mirroring the
rigid-body pilot. This is the override-func family: UsdPhysicsDriveCfg
overrides func with apply_drive instead of the generic applier.

Core:
- JointDriveFragment marker and UsdPhysicsDriveCfg (typed multi-instance
  UsdPhysics.DriveAPI; max_effort -> max_force alias).
- apply_drive: per-joint writer reproducing modify_joint_drive_properties
  (angular/linear instance pick, tendon-child guard, rad->deg conversion
  for angular stiffness/damping, drive_type -> type carve-out).
- apply_joint_drive_properties: recursive family writer; DriveAPI is
  presence-gated (applied only when a UsdPhysicsDriveCfg is present).
  ensure_drives_exist is a writer kwarg, not a fragment field.

Backends:
- PhysxJointCfg (physxJoint:* / PhysxJointAPI, max_joint_velocity with
  max_velocity alias).
- MujocoJointCfg (mjc:* / MjcJointAPI, actuatorgravcomp).

Spawner:
- Widen joint_drive_props slot to accept a fragment list; add the
  spawner-level ensure_drives_exist flag. Bridge the from-files spawn site
  while keeping the gravcomp auto-enable logic working for fragments.

Add exports, test_joint_drive_fragments.py, and changelog fragments.
The tendon-child guard (PhysxTendonAxisAPI without PhysxTendonAxisRootAPI)
lived only inside apply_drive. The dispatch loop in
apply_joint_drive_properties runs every fragment's func per joint prim, so
PhysxJointCfg / MujocoJointCfg authored physxJoint:* / mjc:* attributes on
tendon-child joints that the legacy modify_joint_drive_properties skipped
wholesale (it returns False, so @apply_nested writes nothing and descends).

Hoist the guard into the dispatch loop so a tendon-child joint is skipped
for all fragments (and its children are descended into, matching the
legacy writer). apply_drive keeps its own guard defensively.

Add a regression test (verified to fail before the fix).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant