Training Booster K1 to Walk in Isaac Lab Took 32 Minutes
One GPU ran 4,096 K1 robots at once and produced a gait that does not fall in 32 minutes. But it was a shuffle of 15.2 foot steps per second. Retrained with a gait shape score, v4 walked at 3.6 steps per second. We also record where the install got stuck and the limits we have not yet checked.
Physical AI, Hands On · Part 1
This article publishes only the practice process and results. Institutions that adopt the course receive the textbook text and the instructor's guide.
With one GPU, we trained 4,096 K1 robots at once for 1,000 iterations, and in about 32 minutes a policy that does not fall came out. In a 10-second walk test, it did not fall once.
But the gait shape did not pass. It was a shuffle of 15.2 foot steps per second, and on video it was far from a human gait. We changed the training to score gait shape and retrained, and v4 walked by lifting its knees and stepping alternately, at 3.6 steps per second.
The in-between v2 was trained with floor friction, pushes and torso mass randomized so that it would not fall in another simulator either (Part 3 of the series). v3 was a test that raised only the turn-tracking score on top of v2. It kept the sideways heading well in MuJoCo but reduced forward distance, so we did not use it as the reference. This article compares only v1 and v4, where the gait shape changed.
All results were confirmed on flat ground, inside simulation only. We have not yet taken the step of putting the policy on a real robot. What follows is a record of what we installed and trained ourselves.
What environment did we use?
One Windows PC, run entirely through remote terminal commands with no display.
| Item | Used this time |
|---|---|
| PC | Windows 11 Pro, RTX 4060 Ti 16GB, i7-13700F, 32GB RAM |
| Simulator | NVIDIA Isaac Sim 5.1.0 |
| Training tool | Isaac Lab 2.3.2 |
| Training algorithm | PPO (rsl-rl-lib 3.1.2) |
| Robot model | K1_22dof.urdf and meshes from Booster's official repository booster_assets |
Isaac Sim, Isaac Lab and the robot model are all publicly available files. Booster's model repository is under the BSD-3-Clause license.
Does the K1 model load correctly?
Yes. When we converted the URDF to USD, 22 joints came in matching the original in both names and count, and the robot stood upright on the floor in its initial pose at a height of about 0.955m.
However, with only gravity turned on, it falls within 2 to 3 seconds. The model is not wrong. There is simply no balance control yet. Filling that in through training is what this practice is about.
During conversion, warnings such as Unresolved reference ... head_realsense_rgb_link appear. It is a link for attaching a camera and has no shape, so it can be ignored.
How did we set up the training?
We adapted the humanoid flat-ground walking example task in Isaac Lab to the K1. That means four configuration files: task registration, robot configuration, environment and rewards, and PPO configuration.
- Walking commands: randomly drawn from 0 to 0.8 m/s forward, ±0.3 m/s sideways, and ±1 for turning
- Standing pose: starting height 0.56m, hip -0.2, knee 0.4, ankle -0.2 rad
- Termination condition: when the torso touches the floor, that robot's attempt (an episode) ends
- Neural network: 256-128-128, learning rate 1e-3
For the force that pulls joints toward target angles (PD gains), we referred to the T1 values in Booster's public training repository and lowered them to suit the K1's weight.
We gave the largest gains to the legs and smaller ones toward the ankles, arms and head. The full values are covered in the course materials.
These gains are our own estimate, not a manufacturer-official value.
How long did training take?
The first result (v1) took about 32 minutes for 1,000 iterations with 4,096 K1 robots running at once. That is about 1.9 seconds per iteration and about 98.3 million simulation steps in total.
During training, GPU utilization was about 56% and GPU memory was about 4.9GB. An intermediate result is saved every 50 iterations, so you can resume if you stop partway.
How did the reward change?
In the first training (v1), it started at -0.28 and rose to 32.0 (peak 32.5) at iteration 1,000.
| Iteration | Mean reward | Mean length of one attempt (max 1,000 steps = 20 s) |
|---|---|---|
| 0 | -0.28 | 13 (fell within 0.3 s) |
| about 85 | about -21 (lowest) | sharp rise begins |
| 131 | — | first reaches 1,000 |
| 999 | 32.0 | 992 |
Read the curve this way. Early on the reward dips briefly because the robot is learning not to fall first. After learning to stand, the score for walking at the commanded speed rises steadily, and after iteration 800 it flattens almost completely.
How different are before training and the first result (v1)?
We compared them under the same condition (a command of 0.5 m/s forward). A robot that used to fall now stands and moves forward.
| Before training | First result v1 (1,000 iterations) | |
|---|---|---|
| Falls | 2 to 3 in 5 seconds | 0 in 10 seconds |
| Lowest torso height | 0.08 to 0.10m (lying on the floor) | 0.53m (walking upright) |
| Distance moved | 0.7m (pushed along as it fell) | 4.26m (about 0.43 m/s) |
Why was the gait shape a failure even though the robot did not fall?
Because we gave no score for gait shape. We taught v1 only "do not fall, and match the commanded speed." The robot then found the easiest way to earn points: taking very fast, tiny steps in a shuffle. At 15.2 steps per second, compared with the 2 to 3 steps a human takes, it was effectively bouncing along.
An AI does only what it is told. So for v4 we taught gait shape through scores, referring to the gait scoring method in Booster's public training repository (booster_gym).
- Gait rhythm: tell the robot a fixed rhythm, and give points when it lifts the left and right foot alternately in time with it
- Foot spacing and torso height: penalize feet that are too close together or a torso that sinks
- Stronger penalty for abrupt motion: penalize more heavily than before when joint commands change suddenly
- Base: added on top of the training conditions that randomize friction and mass and push the robot
The full score values are covered in the course materials. On the same PC we trained 4,096 robots for 2,500 iterations, about 1 hour 40 minutes.
| 10 seconds, 0.5 m/s forward | First result v1 | v4 |
|---|---|---|
| Foot steps per second | 15.2 | 3.6 (humans take 2 to 3) |
| Motion abruptness | 0.199 | 0.062 (smaller is smoother) |
| Distance moved | 4.26m | 5.02m (target 5.0m) |
| Falls | 0 | 0 |
v4 is now the reference policy for our practice. On a turning command it also tracked the 458° target with 479°. The result of moving it to a different physics engine (MuJoCo) is covered in Part 4 of this series.
Where did the installation get stuck?
On Windows, using Isaac Sim 5.1.0 and Isaac Lab 2.3.2 together, some versions did not match. We list only what we actually ran into.
| Symptom | Cause | Fix |
|---|---|---|
Can't find extension ... isaacsim.asset.importer.urdf = 2.4.31 | The Windows build of Isaac Sim 5.1.0 ships URDF extension 2.4.30, while Isaac Lab 2.3.2 looks for 2.4.31 | Changed the version it looks for to 2.4.30 in our copy of Isaac Lab |
After the fix above, 'ImportConfig' object has no attribute 'set_merge_fixed_ignore_inertia' | A function that 2.4.30 does not have | Added a condition so it is called only when the function exists |
Warp error: Failed to open file ... | The Windows user folder name is in Korean, which breaks the temporary file path | Set the environment variable WARP_CACHE_PATH to an English-language path |
No module named 'h5py' | A component needed by the logging feature was missing | Installed h5py separately |
| Using the old K1 configuration as is fails to find joints | The old configuration used old names such as Left_Knee_Pitch; the current URDF uses left_knee_pitch_joint | Wrote a new joint naming rule to match the current URDF |
Some arm and head joints in the K1 URDF have aa at the start of the name (aahead_yaw_joint and so on). These are the original names, so please do not mistake them for typos.
Can we put it on a real robot right away?
Not yet. These results were confirmed only in flat-ground simulation.
v4 was trained with friction and mass changed and with pushes, but going to a real robot needs a further step that verifies the difference between simulation and the real world. The joint gains are also estimates, not manufacturer-official values. We have not taken that step yet.
If you carry this into a course, the practice can be used as one sequence: "install, check the model, train, read the curve, compare before and after, fix the score and retrain." The last step is where students see "an AI does only what it is told" for themselves.
Frequently asked questions
What GPU does training of this size need?
We used a single RTX 4060 Ti 16GB, and during v1 training GPU memory use was about 4.9GB. We did not test other GPUs.
Isn't it a success if the robot does not fall?
We saw it that way at first too. v1 did not fall, but it shuffled at 15.2 foot steps per second. With v4, trained with a score for gait shape, it became a human-like gait at 3.6 steps per second.
Does it have to be Linux?
We did this practice on Windows 11. We did have to fix, by hand, a difference in the URDF extension version between Isaac Lab 2.3.2 and the Windows build of Isaac Sim 5.1.0.
Can the trained policy be used on a real K1?
We have not confirmed this yet. These are flat-ground simulation results, and real-robot use needs additional verification of the difference between simulation and the real world.
Where did the joint gains come from?
They are estimates, based on the T1 values in Booster's public training repository and lowered to suit the K1's weight. They are not manufacturer-official values.
Next step
Next, picture what a course looks like with the same K1 in your lab. Look at the robot specifications, and we will work out with you in a consultation the setup that fits your student numbers and budget.
Versions used: Isaac Sim 5.1.0 · Isaac Lab 2.3.2 · rsl-rl-lib 3.1.2 · booster_assets commit 3c2dfa9
Source: The K1 conversion and walking training we ran ourselves (v1 and v4 gait comparison), BoosterRobotics/booster_assets (BSD-3-Clause), BoosterRobotics/booster_gym (gait scoring method referenced), isaac-sim/IsaacLab v2.3.2 (BSD-3-Clause)
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.