A Walk Learned in Isaac Lab: Does It Also Walk in MuJoCo?
We moved a Booster K1 walking policy trained in Isaac Lab to MuJoCo. Walking forward and turning carried over, but sideways walking fell. Randomized training (v2) removed the fall but the body turned 195°, and v4, with a gait shape score, cut the heading drift to -11.6°. This gives the method and the results as they came out.
Physical AI, Hands On · Part 4 · Previous article: Five Isaac Lab Install Errors on Windows and How to Fix Them
This article publishes only the practice process and results. Institutions that adopt the course receive the textbook text and the instructor's guide.
It walks, but we trained three times. When we moved the Booster K1 walking policy trained in Isaac Lab to MuJoCo, the sideways walk of the first training (v1) fell in 1.7 seconds. After we retrained with floor friction, pushes and torso mass randomized (v2), it no longer fell, but the body turned 195°. With v4, which adds a gait shape score, none of the three commands fell, and the heading drift in the sideways walk shrank to -11.6°.
Checking in several simulators is exactly about finding differences like these before going to a real robot. This is a record of the moving and measuring we did ourselves.
Why move it to another simulator?
To tell apart a policy that walks only in one simulator. A motion obtained through reinforcement learning is easily tuned to the physics calculation of the simulator it was trained in. If it also walks under a different physics engine, it is less likely to be a motion that depends only on that simulator.
We chose MuJoCo for two reasons.
- Booster officially provides a MuJoCo K1 model. It has 22 joints, including motor force limits and materials, and we used it without conversion
- It is fast. For one robot, a 5-second simulation finished in 0.1 to 0.2 seconds
How did we move it?
We pulled out only the trained network's weights and ran them in MuJoCo with the same inputs and the same control.
- Install MuJoCo:
pip install mujoco==3.13.0in a virtual environment dedicated to the working folder - Prepare Booster's official K1 model (
K1_22dof.xml); the mesh folder is shared with the one used for the URDF earlier - Extract only the action network weights from the Isaac Lab training result into a numpy file, so the MuJoCo side does not need PyTorch
- Run each command for 10 seconds: standing still, 0.5m/s forward, 0.3m/s forward + 0.8rad/s turn, 0.3m/s sideways
If even one of these is off, the robot falls right away. These are the things we had to match.
| What had to match | Value matched this time |
|---|---|
| Control rate | 50Hz (MuJoCo 0.001 s × 20 steps) |
| Observation input | 78 values, in the same order as during training (a bundle of torso velocity, gravity direction, command, joint state and previous action) |
| Joint order | The Isaac Lab joint order, as is |
| Target joint angles | Default pose + 0.5 × action |
| Joint gains | The same PD gains as in training (values are covered in the course materials) |
Be especially careful that the two simulators number the joint order differently.
How did the first training (v1) turn out?
Forward walking and turning passed; only the sideways walk fell in MuJoCo.
| Command (10 s) | Isaac Lab | MuJoCo |
|---|---|---|
| Standing still | Pass | Pass |
| Forward 0.5m/s | 0 falls, 4.26m | 0 falls, 4.84m |
| Forward 0.3m/s + turn 0.8rad/s | 0 falls, accumulated 452.5° | 0 falls, accumulated 468.2° |
| Sideways 0.3m/s | 0 falls, 2.66m | Fell at 1.7 s |
Same policy, same command, but only the sideways walk came out differently. We raised the MuJoCo floor friction from 0.4 to 1.0 and changed the joint rotational inertia (armature) to 0.01, and the sideways walk still fell. That means there was no single cause.
What changed after retraining (v2)?
The robot no longer fell, but its body turned when told to go sideways.
For v2 we retrained at the same scale (4,096 K1 robots, 1,000 iterations) with these changes.
- Reflect the joint rotational inertia (armature) values from Booster's official MJCF
- Randomize floor friction
- Push the robot's body at regular intervals
- Vary the torso mass
| Command (10 s) | v2 Isaac Lab | v2 MuJoCo |
|---|---|---|
| Standing still | — | Pass (0.05m) |
| Forward 0.5m/s | 0 falls, 4.62m | 0 falls, 3.68m, heading off by 35° |
| Forward 0.3m/s + turn 0.8rad/s | 0 falls, accumulated 483.6° | 0 falls, accumulated 544.1° (turned more than commanded) |
| Sideways 0.3m/s | 0 falls, 2.31m, heading 24° | 0 falls, 1.31m, heading turned 195° |
The final mean reward of v2 is 28.95, lower than v1 (32.0). The randomization made the task harder, so we do not compare it with v1 by score alone.
In short, v2 removed the fall in the MuJoCo sideways walk, but the robot could not go sideways as commanded. Even forward walking drifted 35° in heading in MuJoCo.
How did v4, with the gait shape score, do?
None of the three commands fell, and the heading drift dropped sharply.
v4 is a policy originally made to fix gait shape. v1 was a shuffle of 15.2 foot steps per second; on top of the v2 randomization we added a score for lifting the feet alternately in time with the gait rhythm, and it became 3.6 steps per second (Part 1 of the series). We moved this v4 to MuJoCo the same way.
| Command (10 s) → MuJoCo | v2 | v4 |
|---|---|---|
| Forward 0.5m/s | 0 falls, 3.68m, heading 35° | 0 falls, 4.16m, heading 9.9° |
| Forward 0.3m/s + turn 0.8rad/s (target 458°) | 0 falls, 544.1° | 0 falls, 470.4° |
| Sideways 0.3m/s | 0 falls, 1.31m, heading 195° | 0 falls, 2.00m, heading -11.6° |
It is natural to read this as a gait that steps alternately on a beat being less shaky when the physics engine changes, but we did not run a test that separates the causes. So we do not conclude that "the gait shape score fixed the sideways walk." The reference policy for cross-checking is now v4.
How can the remaining error be reduced?
There are three candidates for reducing the remaining sideways heading error in v4 (-11.6°). None has been tested yet.
- Matching the foot collision shape: the official MuJoCo model computes the foot as a simple shape, while the Isaac Lab side uses a convex hull wrapped around the mesh
- Randomizing control delay: put into training the situation where commands arrive late
- Training longer: increase the number of iterations
We will post the results as a continuation of this series.
Did we get stuck anywhere in MuJoCo?
In two places.
Could not find module ... mujoco.dll: the PC's Visual C++ runtime was old andmsvcp140_atomic_wait.dllwas missing. Installing the latest Microsoft Visual C++ Redistributable (2015-2022) fixes itImage width 1280 > framebuffer width 640: an error when capturing without a display. Setmodel.vis.global_.offwidthandoffheightof the model to at least the capture size
Frequently asked questions
If a policy walks well in one simulator, will it walk on a real robot?
It is not guaranteed. In our own practice, the same policy walked sideways in Isaac Lab but fell in MuJoCo. Even after checking in several simulators, real-robot use needs additional verification.
Does randomized training solve the problem?
In our practice, randomization (v2) alone removed the fall in the sideways walk, but the body turned 195°. With v4, which adds the gait shape score, it dropped to -11.6°. Results change depending on what you change, so we check while varying the conditions.
Is PyTorch needed on the MuJoCo side?
We extracted only the trained network weights into numpy files and computed with them, so we did not install PyTorch on the MuJoCo side.
Can this be used as a student practice?
Because there are points where results split, such as the sideways walk, it makes a good discussion topic. If the observation input order or the joint order is wrong even in one place, the robot falls right away, so brief students on those first.
Next step
Changing simulators to check is good material for students to learn "why we check." When you carry this process into a course, we set the scope in a consultation, deciding how far to go.
Versions used: Isaac Sim 5.1.0 · Isaac Lab 2.3.2 · MuJoCo 3.13.0 · booster_assets commit 3c2dfa9 (K1_22dof.xml)
Source: The Isaac Lab to MuJoCo transfer tests we ran ourselves (v1, v2 and v4, 2026-09-17 to 2026-09-18). All results are flat-ground simulation, before any real-robot deployment.
The copyright of this article and its figures belongs to SV Robotics. Quotations that credit a link to the original are welcome; reproducing or redistributing the full text, or reposting it as teaching material, requires permission.