TOPIC HUB · /topics/sim-to-real
Sim-to-real
Sim-to-real for humanoids: the reality gap, domain randomization, sim-to-sim checks, robot models, and the humanoids with official simulation support.
5 ROBOTS · 4 UPDATES
Introduction
Sim-to-real is the step from a controller that works in simulation to one that works on the robot. Almost every learned humanoid controller is trained in simulation first, so the differences between the simulator and the physical robot, the reality gap, decide whether it transfers [1].
The standard mitigation is domain randomization: vary the simulator's properties during training until the real world looks to the policy like one more variation [1]. Isaac Lab lists domain randomization among its core features [2]. Developer workflows add a check in between: Unitree's unitree_rl_gym runs a policy in a second simulator (Sim2Sim) before deploying it to the robot (Sim2Real) [3].
Transfer also depends on the robot model. Simulators load the maker's URDF or MJCF description [4], so a robot with an official, maintained model is a better sim-to-real platform than one without; the development tables of the robots below show which publish one.
CONCEPTS · 4
Key concepts
- Reality gap
- The differences between simulated and real robots that make a simulator-trained controller fail on hardware [1].
- Domain randomization
- Training across randomised simulator parameters so the policy treats reality as one more variation [1].
- Sim2Sim
- Testing a policy in a second simulator before hardware, to catch dependence on one simulator's quirks [3].
- Robot learning framework
- Software such as Isaac Lab that bundles simulation, tasks and training for reinforcement and imitation learning [5].
KNOWLEDGE GRAPH · 5 ROBOTS
Robots and Sim-to-real
| ROBOT | ISAAC | MUJOCO |
|---|---|---|
| AGIBOT X2AGIBOT | Not published | Official MJCF models (scene.xml, x2_ultra.xml / X2-Ultra.xml / X2-EDU.xml, plus omnihand/omnipicker variants) in the agibot_x2_urdf repository, and an official 'X2 MuJoCo Motion-Control Simulation' guide with local (ROS 2 Humble) or Docker deployment on Ubuntu 22.04. |
| Agility Digit 5Agility | Not published | Not published |
| Booster T1Booster | Booster Gym trains T1 locomotion policies in NVIDIA Isaac Gym (legacy Isaac Gym, not Isaac Sim/Lab) and cross-validates them in MuJoCo before deployment. Booster's newer Isaac-Lab-based framework, Booster Train, currently targets the K1 robot rather than T1. | Officially supported for sim-to-sim testing and deployment (booster_gym's play_mujoco.py, booster_deploy's --mujoco flag with a T1 mjcf_path). Also has a community-maintained Booster T1 model in Google DeepMind's MuJoCo Menagerie and a T1 joystick locomotion environment in MuJoCo Playground. |
| Unitree G1Unitree | unitree_rl_lab (Isaac Lab 2.3.0) · unitree_rl_gym (Isaac Gym) | unitree_mujoco · MuJoCo Menagerie model |
| Unitree H1Unitree | unitree_rl_lab (Isaac Lab 2.3.0 / Isaac Sim 5.1.0): dedicated h1 locomotion task folder, official support statement names Go2, H1 and G1-29dof. unitree_rl_gym (Isaac Gym): h1 and h1_2 tasks, with Sim2Sim/Sim2Real deployment. NVIDIA's own Isaac Lab (third-party) additionally ships public Isaac-Velocity-Flat/Rough-H1-v0 environments and an H1_CFG asset. | unitree_mujoco ships MJCF for both h1 and h1_2 (with DDS idl notes: H1 uses unitree_go, H1-2 uses unitree_hg); unitree_rl_gym documents Sim2Sim (MuJoCo) for h1 and h1_2. MuJoCo Menagerie (third-party, Google DeepMind) additionally provides a derived 19-joint H1 model under BSD-3-Clause. |
Values come from each robot's record, where every fact links to its source.
INTELLIGENCE
Latest updates
RESEARCH