2026.04.10
Why I moved off Isaac Lab for sim-to-real.
A field note on simulator fidelity, iteration speed, and where tooling friction started to outweigh convenience.
Isaac Lab is impressive engineering. The GPU-parallelized physics, the built-in domain randomization, the tight integration with Isaac Sim — on paper, it should be the obvious choice for humanoid locomotion research. After six months on it, I moved to MuJoCo for the Unitree G1 work. Here's the honest accounting.
What Isaac Lab does well
- Massively parallel training — 4096+ environments on a single A100
- Isaac Sim assets are high-fidelity, especially for articulated robots
- Domain randomization API is well-designed and composable
- RSL-RL and skrl integration is first-class
Where the friction built up
- Isaac Sim startup takes 3–5 minutes on our lab machines — kills fast iteration
- URDF imports often break; MJCF is more reliable but Isaac Sim treats it as second-class
- Dependency footprint is enormous — Isaac Sim is 15 GB+, with NVIDIA driver version pinning
- Headless rendering is unstable on our cluster; debugging requires a physical GPU workstation
The shift happened during a deadline sprint. I needed to test a new reward shaping idea at 2am, and Isaac Sim wouldn't launch on the remote machine. I ran the same environment in MuJoCo in 40 seconds and had results in 20 minutes.
For agricultural terrain specifically, MuJoCo's contact model handles the deformable-floor-like behavior of poultry litter better than Isaac Sim's rigid-body defaults. The difference in sim-to-real gap was measurable once we got the G1 on actual floor material.
Current setup
- MuJoCo 3.x for training (unitree_rl_mjlab fork)
- Domain randomization: manual noise injection + terrain heightmap sampling
- Isaac Sim for final visual validation before hardware deployment
- Transfer: zero-shot on real G1 after curriculum training