E1 · Bench ready
10 minRun the setup block. If course 0 already built ~/fth, it only adds what's missing.
Done when: the block ends with unitree_rl_lab 4960b84 (2025-11-19) and mujoco 3.16.0 · onnxruntime 1.31.0.
Lesson 1 · 16 min
Where the simulator lies about a humanoid
A policy that walks in the simulator and falls on the robot: that is the problem of this course. In this lesson you set up the bench, run the ready-made Unitree G1 gait policy in the "sim" and in a "simulated real" with hidden parameters, and find out that no single difference knocks it down; the sum of them does.
Start the lesson
In this lesson you will
- 1The five sources of the gap in a humanoid: actuator, latency, friction, mass, and contact
- 2The ready-made G1 gait policy (unitree_rl_lab) running in MuJoCo
- 3Sim × "simulated real": 4.7 m walked versus a fall in 2.3 s
- 4Change one parameter at a time to find the culprit
Goal: measure the gap by running the same policy in "sim" and "simulated real", and find that no single parameter brings it down.
01What the simulator simplifies
Click each block. These are the five sources of gap this course measures.
Click each block in the diagram to see what it does.
None of these differences go away. Sim-to-real means making the policy robust to them, measuring the ones you can measure, and testing before the floor.
02The policy and the two worlds
What runs in this course's practice sessions. Click each step.
1. The policy
Unitree publishes in unitree_rl_lab a G1 29-DoF walking policy already trained in Isaac Lab and exported to ONNX, with the deployment file deploy.yaml (joint order, kp and kd, default pose, scales). Apache-2.0 license.
It takes 480 numbers (5 timesteps of angular velocity, projected gravity, command, joints, and last action) and returns 29 position targets at 50 Hz.
2. The sim
The MuJoCo Menagerie G1 (the same one from course 0) with the policy's PD inside MuJoCo: a position actuator with the kp and kd from deploy.yaml.
Running a policy trained in Isaac Lab inside MuJoCo already means crossing from one physics engine to another.
3. The "simulated real"
You don't have a G1. The course's "real robot" is the same MuJoCo with four hidden parameters in kit/mundos/real.json. Don't open the file before lesson 3: there you discover one of them through system identification.
It's a bench test, not the robot: what it teaches is the method, not the number.
4. One at a time
--so kp makes the "real" differ only in kp. Running each parameter alone, you see that none of them knocks the policy down, but kp alone already makes it walk 50% faster than commanded.
The gap is rarely a single cause: it's the sum of small differences.
03Set up the bench (reuses the one from course 0)
If you did course 0, the venv and the Menagerie are already in ~/fth: this block only adds onnxruntime, the G1 in the sparse-checkout, and the unitree_rl_lab policy folder, pinned to the tested commit.
Terminal · prepare ~/fth
F=${FTH:-$HOME/fth}; mkdir -p $F && cd $F
[ -d .venv ] || python3.12 -m venv .venv
. .venv/bin/activate && pip install -q mujoco==3.16.0 numpy onnxruntime==1.31.0 pyyaml
[ -d sim2real ] || git clone -q --depth 1 https://github.com/inematds/formacao-fth-sim2real-v72 sim2real
[ -d mujoco_menagerie ] || git clone -q --filter=blob:none --sparse https://github.com/google-deepmind/mujoco_menagerie
git -C mujoco_menagerie sparse-checkout add unitree_g1 && git -C mujoco_menagerie checkout -q 62ab00f
[ -d unitree_rl_lab ] || git clone -q --filter=blob:none --sparse https://github.com/unitreerobotics/unitree_rl_lab
git -C unitree_rl_lab sparse-checkout set deploy/robots/g1_29dof/config/policy/velocity
git -C unitree_rl_lab checkout -q 4960b84 && git -C unitree_rl_lab log -1 --format='unitree_rl_lab %h (%ad)' --date=short
python3 -c "import mujoco, onnxruntime; print('mujoco', mujoco.__version__, '· onnxruntime', onnxruntime.__version__)"Example from the repository
unitree_rl_lab 4960b84 (2025-11-19) mujoco 3.16.0 · onnxruntime 1.31.0
Two lines and no errors. The policy comes from commit 4960b84 of unitree_rl_lab: pin it, because a new policy.onnx may have a different input order.
ERRO: não achei /tmp/sem-bancada/unitree_rl_lab/deploy/robots/g1_29dof/config/policy/velocity/v0/exported/policy.onnx. Rode a preparação da aula 1 (unitree_rl_lab no sparse-checkout). saída: 1
The scripts look for everything in ~/fth (or in the folder set by the FTH variable). If the setup didn't run, the error tells you which path is missing.
04The same policy in both worlds
dois_mundos.py runs 10 s walking at 0.5 m/s in each world. Fall = pelvis below 0.5 m. Exits with 1 if any world fell.
Terminal · sim × simulated real
F=${FTH:-$HOME/fth}; cd $F/sim2real && . $F/.venv/bin/activate
python3 kit/dois_mundos.py; echo "saída: $?"Terminal · one parameter at a time
F=${FTH:-$HOME/fth}; cd $F/sim2real && . $F/.venv/bin/activate
for p in atrito massa kp atraso_ms; do python3 kit/dois_mundos.py --so $p | tail -1; doneExample from the repository
política: unitree_rl_lab G1 29 GDL velocity v0 (ONNX, 480 entradas) · comando 0.50 m/s · 10 s sim queda: não · andou 4.7 m em 10 s (vel. 0.47 m/s; pedida 0.50) real simulado queda: sim em t = 2.3 s (andou 1.9 m) saída: 1
In the sim, 4.7 m in 10 s (0.47 m/s for 0.50 commanded). In the "simulated real," a fall at 2.3 s.
real simulado (só atrito) queda: não · andou 4.7 m em 10 s (vel. 0.47 m/s; pedida 0.50) real simulado (só massa) queda: não · andou 4.6 m em 10 s (vel. 0.46 m/s; pedida 0.50) real simulado (só kp) queda: não · andou 7.5 m em 10 s (vel. 0.75 m/s; pedida 0.50) real simulado (só atraso_ms) queda: não · andou 4.6 m em 10 s (vel. 0.46 m/s; pedida 0.50)
None alone knocks it down. kp alone makes the robot walk at 0.75 m/s: the softer PD lets the legs lag behind, and the policy compensates by pushing harder.
05Practice
Measure the gap before you try to close it.
E2 · The measured gap
3 minRun the same policy in both worlds and note how far it walked in each.
Done when: python3 kit/dois_mundos.py; echo "saída: $?" → real simulado … queda: sim em t = 2.3 s and saída: 1.
E3 · Find the culprit
5 minRun the "one parameter at a time" loop and write down which parameter alone changes the behavior most, and what changes.
Done when: the 4 lines show queda: não and the kp line shows vel. 0.75 m/s; pedida 0.50; you wrote "none knocks it down alone; kp changes the speed".
06Lesson quiz
The explanation appears after your answer.
Question 1 of 3
Each parameter of the "simulated real" robot, on its own, does not knock the policy down; all four together do. What does this teach?skill
Correct
Each difference takes away a little margin. Together, they go past what the policy can handle. That's why you measure one at a time and then test the combination.Not this one
Each difference takes away a little margin. Together, they go past what the policy can handle. That's why you measure one at a time and then test the combination.Review: Set up the bench (reuses the one from course 0)Question 2 of 3
Running a policy trained in Isaac Lab on MuJoCo is already:
Correct
Different engines approximate contact and the actuator in different ways. Walking in both is a first sign of robustness; it's the gate of lesson 6.Not this one
Different engines approximate contact and the actuator in different ways. Walking in both is a first sign of robustness; it's the gate of lesson 6.Review: The policy and the two worldsQuestion 3 of 3
With only the lower kp, the robot walks at 0.75 m/s when the request is 0.50. Why?
Correct
The policy is a closed loop: if the joints don't reach the target, it asks for more. The result is walking wrong without falling, a gap that only shows up when you measure the speed.Not this one
The policy is a closed loop: if the joints don't reach the target, it asks for more. The result is walking wrong without falling, a gap that only shows up when you measure the speed.Review: Set up the bench (reuses the one from course 0)Quiz complete
You got {a} of {n} right. Get them all right and the lesson is marked as done.Pick one answer. The explanation appears after you try.
07In three sentences
SourcesActuator, latency (delay), friction, mass, and contact set the simulator apart from the robot.
MeasurementThe same policy walks 4.7 m in sim and falls at 2.3 s in the "simulated real" robot.
MethodOne parameter at a time finds the culprit; it's the sum that knocks it down.