Sim-to-real transfer

What it means

Sim-to-real transfer is the step from a simulated robot or environment to a physical one. A policy can perform well inside a simulator yet fail on hardware because the two systems differ. The reality gap can involve perception, contact physics, actuator behavior or timing. Transfer is therefore an empirical result to check, rather than a guarantee supplied by using a simulator. [1, 2]

Different methods address different gaps. Tobin and colleagues randomize rendered training images so real images can resemble another variation of the simulated data. Tan and colleagues improve a locomotion simulator through system identification, an actuator model and simulated latency, alongside training randomization. [1, 2]

How it applies to humanoids

Humanoid learning pipelines can use simulation before physical deployment. Unitree's official RL repository separates training, policy playback, testing in another simulator and deployment to a real robot. It supports several humanoid platforms, including G1 and H1. These are distinct workflow stages, and a successful simulation run alone completes only part of the pipeline. [4]

Agility describes an especially concrete contact-model problem: earlier Digit policies walked confidently in simulation but slipped on physical hardware. Its account traces the mismatch to simulated contact behavior and explains changes to the training setup. This illustrates why a visually plausible simulation may still teach the wrong response. [3]

Terminology and evaluation traps

Domain randomization broadens training conditions; it does not prove that the chosen variations cover every real situation. In the original visual study it varies rendering, while locomotion transfer also requires attention to the physical model. Identify which quantities were changed before treating randomization as a general solution. [1, 2]

Sim-to-sim testing transfers a controller between simulators, not onto hardware. Unitree lists that step separately from sim-to-real. Passing it is useful evidence about simulator dependence, but it cannot replace a physical test. [4]

Transfer claims should state the task, hardware and adaptation used. A policy tested on one gait or environment supports that result, rather than every motion the robot could theoretically make. The quadruped study evaluates specific trotting and galloping behaviors. [2]

How to read it on humanoidversus.com

Use a robot's cited learning material to distinguish training methods from demonstrated capabilities. ai_stack and compute describe disclosed systems; neither measures transfer quality. Related G1 and Digit records link to official learning material that helps interpret these claims. [3, 4]

This entry has no live ranking. Compare physical test conditions and outcomes in the sources, and preserve missing information about failures, adaptation or evaluation scope. A null hardware field is not evidence that simulation supplied a reliable replacement.

Further reading

Read the domain-randomization and agile-locomotion papers for contrasting transfer methods. Agility's Digit account and Unitree's repository show contact-model investigation and a staged deployment workflow. [1–4]