Humanoid-Gym offers a practical intermediate test: export a locomotion policy trained in Isaac Gym and run that policy in MuJoCo before considering hardware. A second simulator can reveal a mismatched observation, action, joint map or physics assumption that the training simulator never exposed. It is a screen for faults and brittle policies, not a substitute for measured real-robot evidence or a safety clearance.
The Humanoid-Gym repository describes an Isaac Gym training workflow and an Isaac Gym-to-MuJoCo sim-to-sim route. Its maintainers report real-world checks on RobotEra XBot-S and XBot-L. Those examples show what the released framework is intended to support; they do not validate a different humanoid merely because it can load the same kind of policy file.
Export the same policy, then audit the interface
The repository’s usage sequence matters. Its play.py step exports a JIT policy from a training run, and sim2sim.py loads that exported artifact in MuJoCo. If you silently retrain, change observation normalization or substitute a later checkpoint between engines, the second-engine result no longer isolates a transfer problem. Keep the export hash and both environment configurations with every comparison.
Observation order can break transfer even when vector lengths match. The released sim-to-sim script assembles and clips observations, stacks their history, scales the policy action into joint targets, then applies PD control and torque limits. These transformations are part of what the exported policy actually experiences. Audit joint order, signs, units and control interval at both sides of that boundary. The README also flags MJCF/URDF joint mapping and initial pose when adding a robot. A wrong map can produce a failure before the dynamics comparison begins.
| Evidence from the second engine | Plausible interpretation | Check before blaming policy learning |
|---|---|---|
| Instability at the first control step | Interface or initial-state mismatch | Joint order, base frame, action scale and startup pose |
| Stable stance but wrong foot timing | Contact or control-cadence gap | Foot geometry, friction, solver settings and step timing |
| Failure only on disturbed terrain | Policy or physics robustness limit | Disturbance definition and whether training covered it |
| Similar simulated motion in both engines | Fewer obvious simulator-specific failures | Still requires hardware rollout and instrumentation |
This table is an editorial diagnostic. It is not a failure taxonomy measured by the Humanoid-Gym authors. A good second-engine trajectory supports continued evaluation; it cannot tell you that hidden hardware effects have disappeared.
A proposed mismatch-localization run
Consider a hypothetical humanoid that walks in Isaac Gym but pitches forward after two strides in MuJoCo. First replay a short stationary-control trace and compare observation fields at each policy call. Verify that both engines pass the same command and history in the expected units. Then compare the exported policy’s raw outputs before any controller conversion. If those outputs already diverge under matched observations, look at preprocessing or state construction. If outputs match but body motion diverges, inspect actuation and contact parameters. Finally run the full policy loop with fixed disturbance conditions and record the first step at which the traces separate.
That is a proposed debugging sequence, not a test performed for this article. It also cannot uniquely identify a physical cause from one trajectory. Several mismatches can interact, and forcing two engines to match one narrow gait may overfit their parameters. Use more than one start, speed and terrain condition before describing a policy as robust.
This is a different question from the SIMPLER sim-real ranking analysis, which asks whether simulated evaluations track relative real-policy performance. Humanoid-Gym’s second engine can catch incompatibilities before hardware. It does not, by itself, measure correlation with real outcomes. For training variation rather than second-engine replay, the domain-randomization guide explains another related decision. Keep those evidence types separate.
The released stack is historical
As checked on 2026-09-29 KST, the repository README still specifies Python 3.8, a PyTorch/CUDA combination and Isaac Gym Preview 4 for setup. That is the project’s documented dependency path, not a claim that current systems cannot run it or that an installation was attempted here. A team should check the repository and vendor availability for its own environment, pin the exact versions it uses, and budget for compatibility work. A newer simulator with a similar name is not automatically a drop-in replacement for the training and export sequence.
Before a robot trial, retain the exported checkpoint, input/output schema, physics parameters, model assets and second-engine trace. If the MuJoCo rollout fails, localize the first discrepancy before changing reward weights or collecting more demonstrations. If it succeeds, document precisely which motions and disturbances were tested and continue to hardware validation through the team’s normal controls. The authors’ reported XBot results remain their platform-specific evidence. No repository installation, simulator run or humanoid trial was performed for this article.