SuperAPI AI Directory

isaaclab-transferring-policies-sim-to-sim

Agents & models

View repository

Updated 10-15 22:38

About this skill

Transfer Policies Between PhysX And Newton

When To Use

Read the sim-to-sim guide first. This skill follows that page in the same order. Before transfer, make the asset and task MJWarp-ready with isaaclab-preparing-assets-for-newton.

Workflow

  1. Task readiness and checkpoint compatibility. Keep one MDP for the same registered task. Resolve the explicit isaacsim_physx and newton_mjwarp backend alternatives from each PresetCfg, using them for intentional physics, asset, and control differences without silently changing policy-facing MDP terms. If an MDP-term preset differs, restore one checkpoint contract or treat it as a different task and retrain. Require successful training in both engines and exact action, observation, policy-state, timing, mechanism, and episode contracts.
  2. Mimic-joint action nuance. Newton MJWarp preserves both Franka finger coordinates but creates one active drive: the leader is driven and an equality moves the follower. PhysX preserves the mimic coupling while leaving the follower driveable. If one logical command targets both fingers and both have nonzero gains, PhysX applies two PD-drive contributions. Drive panda_finger_joint1 and set panda_finger_joint2 stiffness and damping to zero.
  3. Articulation joint and body ordering. A checkpoint stores column positions, not names, so a cross-backend replay with mismatched axis order feeds each joint's observation to a different joint's action. On every PN and NP command, set both env.scene.robot.joint_ordering and env.scene.robot.body_ordering to the source checkpoint's convention (physx for PN, mjwarp for NP); physics= still selects the target backend. The current Isaac-Lift-Franka asset resolves to the same joint and body order in both backends and needs no override; Isaac-Velocity-Rough-G1 and Isaac-Velocity-Rough-AnymalD do need it. Verify by comparing joint_names with backend_joint_names (and the body equivalents); a scrambled axis collapses the policy immediately rather than degrading gracefully.
  4. Transferring control behavior. Match nominal actuator response before tuning the policy. Distinguish rated and solver velocity limits, use per-joint effort, gains, friction, and armature, preserve dt * decimation, keep targets away from hard stops, and monitor saturation and action sign changes. Increase damping to prevent bang-bang control and retune it after increasing armature.
  5. Introducing domain randomization. Randomize plausible robot/object friction, object mass/inertia, joint gains/friction, joint armature, gravity, actuator response, reset pose/geometry, and observation noise. Keep inertia valid and coupled mechanisms coherent. If transfer needs extreme ranges, revisit the nominal model. Use curriculum when the final distribution blocks learning, promote to final deployment difficulty, and keep a separate deterministic nominal evaluation.
  6. Validate the full matrix. Evaluate PP, PN, NN, and NP. For each source policy, reproduce the same-backend baseline and deploy the exact checkpoint in the other backend.
  7. Run a validated transfer. The guide lists three fully validated tasks in a compact table — Isaac-Lift-Franka, Isaac-Velocity-Rough-G1, and Isaac-Velocity-Rough-AnymalD — with each task's experiment directory and task-specific notes. Substitute the task ID and directory into the generic PP/PN/NN/NP commands above. The play entry point applies play_mode overrides automatically. Isaac-Reorient-Cube-Allegro is shown as a PhysX-to-Newton demonstration only.

Validation

Require a task trainable in both backends, exact environment-contract equality, one active Franka finger drive in each backend, joint and body ordering resolved to the source checkpoint's convention on every cross-backend replay, matched nominal control behavior, plausible randomization, and all four training/deployment combinations.

Maintenance

Keep this skill synchronized section-for-section with the sim-to-sim guide, including the validated-task table (Franka, G1, ANYmal D).

References