Sim-to-Real Transfer for Robotics: The Ultimate Guide

A control policy that walks perfectly in simulation and falls over the instant it touches a real floor is the most common experience in robot learning. The simulator lied to the policy, in a hundred small ways: the friction under the feet was a single clean number instead of a patch of dusty concrete, the motors responded instantly instead of with 8 ms of delay, the mass was the CAD value instead of the CAD value plus a cable harness nobody modeled, and the IMU reported the truth instead of a drifting, noisy estimate. The policy learned to exploit every one of those conveniences. Reality withdraws them all at once.

Sim-to-real transfer is the discipline of building policies in simulation that survive that withdrawal. It sits underneath almost every modern robot-learning result: the ETH quadrupeds that walk over rubble they cannot see, the Shadow Hand that reorients a Rubik's Cube one-handed, the wave of humanoids from 2024 onward that climb stairs and recover from shoves. None of those systems learned on hardware in any meaningful quantity. They learned in a simulator running thousands of robot instances in parallel, and the engineering that made the transfer work is the actual product.

This guide is the long version for the people who build these systems: the reality gap and why it exists, domain randomization for dynamics and vision, system identification, domain adaptation, the teacher-student recipe that made legged transfer reliable, why simulation wins on cost and safety and parallelism, where physics-engine fidelity runs out, the canonical successes, how to measure whether transfer actually happened, and the pitfalls that will cost you a week each.

The take: The reality gap is the distance between the distribution of worlds your policy trained on and the single world it deploys into. You close it by widening the training distribution until reality falls inside it (domain randomization), by moving the simulator's parameters toward the truth (system identification), or by giving the policy a way to infer the parts of reality it cannot directly measure (teacher-student and online adaptation). The algorithm barely matters. Success is set by the actuator model, the randomization ranges, and the observation design. A policy that transfers is one that was never allowed to trust any single number the simulator told it.

Companion reading: robot simulation & digital twins, reinforcement learning for robotics, legged & quadruped robot hardware, real-time control systems, and foundation models & VLAs for robotics.

Table of contents

1. Key takeaways
2. The reality gap: what it is and why it exists
3. Why train in simulation at all
4. Domain randomization: dynamics and visual
5. System identification: measuring the real robot
6. Domain adaptation and online adaptation
7. Teacher-student and privileged learning
8. Physics-engine fidelity and where it runs out
9. Canonical successes
10. Measuring transfer
11. Pitfalls and failure modes
12. Where sim-to-real is heading
13. Frequently asked questions

The reality gap: what it is and why it exists

Frame the robot as a policy π(a | o) mapping observations to actions, trained to maximize return inside a simulator whose dynamics are P_sim(s' | s, a) and whose observations are o = g_sim(s). Deployment swaps both out for P_real and g_real. The reality gap is the gap between these two pairs, and it shows up in two distinct places that fail in different ways.

The dynamics gap is the difference between P_sim and P_real. Its usual sources:

• Actuator dynamics. Real motors have torque-speed curves, current limits, thermal derating, gear friction, backlash, and a response delay from the control command reaching the joint. A naive sim treats the actuator as an ideal torque or position source.
• Contact and friction. Real contact is compliant, history-dependent, and governed by micro-scale surface properties. Simulators use a stiff or soft contact model with a single Coulomb friction coefficient, and the two diverge exactly at foot strikes and grasps where it matters most.
• Mass and inertia. The real robot carries wiring, connectors, dirt, and manufacturing variance the CAD model omits. A 5 to 20 percent error in link mass or center-of-mass offset is normal.
• Latency. Sensor read, network transport, inference, and actuation each add delay. A real proprioceptive loop carries 1 to 20 ms of latency that an unmodeled sim ignores entirely.

The observation gap is the difference between g_sim and g_real. Simulated sensors are clean by default: an IMU with no bias drift, an encoder with no quantization, a camera with perfect textures and lighting. Real sensors are noisy, biased, delayed, and occasionally wrong. For vision policies this gap is enormous because rendered images and real images differ in texture, lighting, reflections, motion blur, and the thousand details a renderer does not reproduce.

The reason the gap is dangerous: RL and imitation both produce policies that are optimal for the training distribution, which means they actively exploit whatever the simulator makes free. If the sim lets a foot vibrate against the ground at no energy cost, a reward-maximizing policy will vibrate the foot. If the rendered floor has a distinctive texture, a vision policy will key off that texture. Every convenience becomes a dependency, and every dependency is a way to fail when reality takes the convenience away.

Rule of thumb: Assume the policy will exploit every difference between sim and real that you leave unrandomized and unmodeled. The gap is the single most exploitable error in your simulator, because that is the one the optimizer found. The average error across the whole model barely matters.

Why train in simulation at all

The case for simulation rests on three numbers that hardware cannot match.

Cost. A quadruped locomotion policy needs on the order of 1 to 5 billion environment steps. At a real control rate of 50 Hz on one robot, that is roughly 8 months to 3 years of wall-clock time on a single machine, and that assumes it never stops to reset or recharge. In simulation on one modern GPU it is a couple of hours. The economics are not close.

Safety. A half-trained policy flails. Early in training it commands nonsense, drives joints into limits, and falls constantly. On hardware every one of those events risks a harmonic drive, a snapped cable, or a person nearby. In simulation a fall costs nothing and the environment resets in microseconds.

Parallelism. The change that reshaped the field was moving the entire RL loop onto the GPU. Isaac Gym and its successor Isaac Lab, along with MuJoCo MJX and Brax, run physics, observation assembly, reward computation, and policy inference on the GPU with no CPU round-trip. One GPU steps thousands of randomized robot instances simultaneously at hundreds of thousands of steps per second. This is what collapsed legged-locomotion training from days on CPU clusters to under an hour on one card, and it is what makes domain randomization affordable, because a wide randomization distribution just means more instances, and instances are cheap.

The catch, and the reason this whole guide exists: everything above buys you a policy that is excellent in simulation. The value only materializes if that policy transfers. Simulation is the cheap, safe, parallel place to do the learning, and sim-to-real is the tax you pay to spend the result in the real world.

Domain randomization: dynamics and visual

Domain randomization is the reason a sim-trained policy survives reality, and the idea is one sentence: train the policy on a distribution of simulators. Perturb the simulator's parameters every episode so the policy has to work across a range of conditions. If the real robot's true parameters fall inside that range, the policy treats reality as another sample it has already handled. The lineage runs from Jakobi's "radical envelope-of-noise" work in evolutionary robotics (1997) through Tobin et al. (2017) for vision and Peng et al. (2018) for dynamics.

Formally, randomization changes the objective. Instead of maximizing return in one environment with parameters ξ, you maximize expected return over a distribution p(ξ) of environments:

J_DR(π) = E_{ξ ~ p(ξ)} [ E_{τ ~ π, ξ} [ Σ_t γ^t · r(s_t, a_t) ] ]

Reality is a single draw ξ_real. If ξ_real lies inside the support of p(ξ), the policy was already optimized against it in expectation. That is the entire mechanism. It also explains the cost: a policy trained over a distribution of dynamics is being asked to be robust rather than optimal. It hedges. Widen p(ξ) and you buy robustness at the price of peak performance, the same trade a worst-case H-infinity controller makes against an H2-optimal one.

Dynamics randomization perturbs physics. Visual randomization perturbs appearance for vision-based policies. Legged locomotion leans on the former, vision-based manipulation needs both.

Technique	What it randomizes	Why it bridges the gap	Typical range
Mass / inertia	Link masses, payload, CoM offset	Real mass is never the CAD value; payloads vary	plus or minus 10-30%
Friction	Ground and joint friction coefficients	Surfaces and joints differ; biggest foot-ground gap	0.4 to 1.25 (foot-ground mu)
Actuator / motor gain	PD gains, torque limits, motor strength	Real gains drift; gearboxes lose efficiency	plus or minus 10-25%
Latency / delay	Observation and action delay	Real loops carry 1-20 ms of latency	0-40 ms
Sensor noise	IMU bias/drift, encoder noise	Real sensors are noisy and biased	Gaussian, robot-specific sigma
Push / disturbance	Random external forces on the base	Teaches recovery and robust balance	impulses every few seconds
Terrain	Slopes, stairs, gaps, roughness	Generalizes beyond flat ground	curriculum, progressive
Visual	Textures, lighting, distractors, camera pose	Closes the appearance gap for vision	wide, task-dependent

The failure modes sit at both extremes. Too little randomization and the policy overfits the simulator's quirks, keying off a friction value or contact behavior that does not exist in reality, and it falls on the real floor. Too much randomization and no single behavior works across the whole insane range, so the policy learns a timid, conservative controller or fails to learn at all. Tuning the ranges is the real craft.

Two refinements matter in practice. Automatic domain randomization (ADR), introduced in OpenAI's Rubik's Cube work, expands each range only after the policy masters the current one, so the difficulty grows with competence instead of drowning a fresh policy. And the choice of what to randomize should follow your honest uncertainty: randomize each parameter in proportion to how poorly you know it.

For visual policies, randomization does something subtly different from dynamics randomization. The goal is to make the rendered appearance so varied that a real image looks like just another draw. You randomize textures on every surface, lighting direction and intensity, camera pose and field of view, and you scatter distractor objects. The policy is forced to solve the task from invariant structure (shape, relative position) rather than from any particular texture, and that invariant structure is what carries over to real images.

Rule of thumb: Randomize the parameters you are uncertain about, in proportion to your uncertainty. You know your link lengths to a millimeter, so barely randomize them. You barely know your foot-ground friction, so randomize it hard. Domain randomization is a way of injecting your honest model uncertainty into training.

System identification: measuring the real robot

Randomization handles the parameters you cannot measure. System identification handles the ones you can. The two are complementary, and the strongest pipelines do both: identify what you can measure to center the distribution on the truth, then randomize around that center to cover what you cannot.

System identification means running experiments on the real robot to estimate its parameters, then setting the simulator to match. The classic targets:

• Actuator response. Command a chirp or step to a joint, log the realized torque or position, and fit a model of the torque-speed curve, the PD tracking behavior, and the response delay. The ANYmal line famously fit a learned actuator model: a small neural network mapping commanded torque and joint state to realized torque, which captured the series-elastic drivetrain dynamics an analytic model missed.
• Mass and inertia. Weigh links, find centers of mass by balancing, or estimate the whole inertial parameter set by driving the robot through excitation trajectories and fitting the rigid-body dynamics equations, which are linear in the inertial parameters.
• Friction and damping. Estimate joint friction from constant-velocity moves and Coulomb-plus-viscous fits. Foot-ground friction is harder and usually stays randomized.
• Latency. Measure the end-to-end delay from command to observed effect with a timed step response.

The formal objective is to find simulator parameters ξ that minimize the discrepancy between real and simulated trajectories under the same commands:

ξ* = argmin_ξ  Σ_k  || x_real(k) − x_sim(k; ξ) ||²

where x is whatever state you can observe on both sides (joint positions, velocities, base motion). This is a nonlinear least-squares problem, solved with gradient descent through a differentiable simulator when you have one, or with black-box optimization (CMA-ES, Bayesian optimization) when you do not.

There is a closed-loop version worth knowing. SimOpt (Chebotar et al., 2019) alternates between training a policy in the current simulator and updating the simulator parameters to reduce the gap between real and simulated rollouts of that policy, iterating until the two match. This is real-to-sim correction done automatically, and it is the principled way to keep the simulator honest as you learn.

Rule of thumb: System identification narrows the randomization distribution around the truth; it does not replace randomization. Measure the actuator model and the masses precisely, then still randomize them a little, because your measurement has error and the real robot drifts over its lifetime.

Domain adaptation and online adaptation

Randomization and system ID both try to make the training distribution cover reality ahead of time. Adaptation methods instead let the policy adjust to reality at or after deployment.

Visual domain adaptation attacks the observation gap directly. Rather than randomizing appearance until real images look familiar, you learn a mapping that aligns the two domains. Approaches include training a feature extractor whose representation is invariant across sim and real (adversarial domain-confusion losses that prevent a discriminator from telling which domain a feature came from), or translating images from one domain to the other with a generative model so the policy always sees a consistent style. GraspGAN and RCAN were early demonstrations of sim-to-real grasping that leaned on image translation rather than pure randomization. In practice most 2026 vision stacks combine heavy randomization with a modest amount of real data for alignment, because pure randomization can leave performance on the table and pure adaptation needs real data that is expensive to collect.

Online dynamics adaptation attacks the dynamics gap at runtime. The idea: the policy cannot measure the hidden parameters ξ_real directly, but it can infer them from the recent history of what it can measure. Rapid Motor Adaptation (Kumar et al., 2021) makes this explicit. A teacher policy takes the true ξ as input and learns to act; an adaptation module then learns to regress a latent embedding of ξ from the recent stream of proprioceptive states and actions, and at deployment that module runs online, continuously updating its estimate of what the robot is walking on. The robot steps onto ice, the recent state-action history shifts, the adaptation module updates its latent, and the policy responds within a few control cycles.

The common structure across all of these: build a learned observer for the parameters the model never let you measure, and feed its output to the policy. Whether you call it a belief encoder, an RMA adaptation module, or a recurrent hidden state, you are estimating the unobservable from a history of the observable. That structure is exactly what the teacher-student recipe formalizes.

Teacher-student and privileged learning

This is the single most important practical recipe in legged sim-to-real, and it is worth stating precisely because it solves a problem the naive approach ignores.

The real robot does not live in a clean Markov decision process. It lives in a partially observable MDP (POMDP), where the optimal action depends on hidden state (friction under each foot, terrain shape, an external push) that the sensors never report. POMDP theory says the optimal policy is a function of the belief state, the posterior over hidden variables given the entire observation history, and a reactive single-frame policy cannot represent that belief.

The consequence for sim-to-real: in simulation you know everything, including the exact friction under each foot, the true contact forces, the terrain height around the robot, and the disturbance pushing the base. On the real robot you know almost none of that. A policy trained on privileged simulator state is brilliant in sim and useless on hardware because its inputs do not exist there.

The two-stage teacher-student pipeline (the ETH Zurich / Hutter lab privileged-learning recipe) resolves this:

Stage 1: train the teacher. Train a policy with RL that receives full privileged state: true friction, contact states, terrain map, external forces. Its inputs are clean and complete, so it learns an excellent policy fast. It could never run on the real robot, and that is fine, because it is not meant to.

Stage 2: distill the student. Train a student policy that uses only deployable observations, proprioception (joint angles and velocities, IMU) plus a short history of past observations and actions, to imitate the teacher's actions via supervised learning and DAgger. The history is the crux. It is an empirical approximation of the belief state. Feeding the last N frames lets the student infer the privileged information (am I on ice, did something just push me) from the recent time series of what it can actually measure. An encoder learns to map the observable history onto a latent that stands in for the hidden ξ. This is implicit online state estimation, learned end to end, and it is why the trick works.

# Teacher-student, schematically
teacher(s_privileged)            -> a_teacher        # RL, full state
student(o_history)               -> a_student        # supervised, deployable obs
loss = || a_student − a_teacher ||^2                 # distill, with DAgger rollouts
# deploy: student only, onboard sensors + history

The result is a student that matches teacher performance using only onboard sensors. ANYmal's robust blind locomotion over rough terrain (Lee et al., Science Robotics, 2020) was exactly this: a teacher with terrain knowledge distilled into a proprioception-only student that walked over rubble, mud, snow, and stairs it could not see, by feeling the terrain through its legs.

Rule of thumb: When the gap between sim-available and robot-available information is large, do not train one policy to do everything. Split it: a teacher that learns the skill with cheating inputs, and a student that learns to perceive well enough to execute it. Decoupling "learn the skill" from "learn to perceive" is the whole reason this works.

Physics-engine fidelity and where it runs out

Every sim-to-real decision eventually bottoms out on the physics engine, so it pays to know exactly what these engines are good and bad at.

Modern robotics simulators (MuJoCo, PhysX under Isaac Sim, Bullet, Drake, Brax) are excellent at rigid-body dynamics: the articulated equations of motion for a tree or closed loop of rigid links are well understood, and a good engine integrates them accurately and fast. If your task is dominated by inertial dynamics in free space, the simulator is close to the truth.

The fidelity runs out at contact. Contact is where rigid-body idealization breaks, and it is also where most interesting robotics happens. The hard parts:

• Friction. Engines use a Coulomb friction cone, often a pyramidal approximation, with a single coefficient. Real friction is anisotropic, load-dependent, history-dependent, and varies across a single contact patch. Foot slip, the biggest quadruped sim-to-real gap, lives here.
• Contact stiffness and restitution. Real contact is compliant and dissipative in ways that depend on materials and microgeometry. Engines pick a stiffness and damping that trade stability against realism. Too stiff and the simulation explodes or chatters; too soft and feet sink into the floor.
• Simultaneous and impulsive contacts. A foot strike or a multi-finger grasp involves multiple contacts resolved in the same step. The linear complementarity problem that governs this is expensive and the approximations engines use (relaxation, soft constraints) introduce errors precisely at the moments that matter.

Beyond contact, several regimes are simply outside what standard engines model well: deformable and soft materials (cloth, cables, soft grippers, tissue), fluids, granular media (sand, gravel, loose soil), and fine friction-limited manipulation (a screw threading, a card sliding). These are exactly the tasks where sim-to-real is hardest, and it is not a coincidence: the gap is largest where the physics model is weakest.

The practical implications:

• Match the engine to the task. MuJoCo's soft-constraint contact model is forgiving and stable for manipulation and locomotion research. PhysX under Isaac scales to huge parallel counts. Drake targets contact-rich manipulation with more careful contact modeling. There is no universally best engine.
• Tune contact parameters as part of system ID. Contact stiffness, damping, and friction are among the most impactful and least measurable parameters, so identify what you can and randomize the rest hard.
• Do not trust sim rewards near the fidelity boundary. If your reward depends on precise contact forces or slip, the simulator's version of that quantity may be fiction. Validate against real data before you trust it.

War story: A manipulation team trained a peg-insertion policy that hit 98 percent success in simulation and 20 percent on hardware. The simulator's contact solver let the peg slide into the hole with a tiny lateral force the real friction would never permit, so the policy learned an insertion strategy that only worked against a contact model that did not exist. The fix was stiffer, better-identified contact parameters plus friction randomization wide enough that the free-sliding strategy stopped paying off. A better algorithm would have changed nothing. The reward curve had looked perfect the entire time.

Canonical successes

Three lines of work define what sim-to-real can do, and every practitioner should know them.

ANYmal legged locomotion (ETH Zurich, Hutter lab). The 2019 Science Robotics result (Hwangbo et al.) trained control policies in sim with a learned actuator model and transferred them zero-shot to the real ANYmal, achieving faster and more robust locomotion plus a dynamic recovery-from-fall behavior classical methods struggled with. The learned actuator model was the key sim-to-real ingredient: it closed the largest single component of the dynamics gap. The 2020 follow-up (Lee et al.) added teacher-student distillation for blind rough-terrain locomotion, and the 2022 work on perceptive locomotion (Miki et al.) fused proprioception with exteroception so the robot could use terrain it could see while gracefully falling back to feel when perception failed. This line established the standard recipe: learned actuator model, domain randomization, teacher-student. See legged & quadruped robot hardware.

Dexterous manipulation (OpenAI, Dactyl and Rubik's Cube). OpenAI's Dactyl trained a Shadow Hand to reorient a block, and later to manipulate a Rubik's Cube one-handed, entirely in sim with PPO and massive domain randomization. The 2019 Rubik's Cube result introduced automatic domain randomization, expanding the ranges as the policy improved, and produced a policy robust enough to handle a real hand wearing a rubber glove, with fingers tied together, and with a plush giraffe pushing on it, perturbations it never saw in training. The cost was enormous: the equivalent of thousands of simulated years, because contact-rich finger-object interaction is far harder to simulate accurately than legged contact. The lesson is that extreme randomization plus ADR can bridge a very hard manipulation gap when you can afford the compute.

Humanoid locomotion (2024-2026 wave). The humanoid surge brought the quadruped recipe to bipeds. Unitree's H1 and G1, and a wave of humanoid programs, use PPO-trained locomotion policies, often with motion-capture references (adversarial motion priors and DeepMimic-style style rewards) for human-like gaits, plus the teacher-student and randomization machinery from the quadruped world. Bipedal balance is less forgiving than quadrupedal because the support polygon is smaller and the center of mass higher, so disturbance rejection matters more and the sim actuator and contact fidelity bar is higher. The 2024-2026 demos of humanoids walking, climbing stairs, and recovering from shoves are overwhelmingly sim-to-real RL stacks. See humanoid robot hardware and foundation models & VLAs for robotics.

The pattern across all three: the wins came from the actuator model, the randomization strategy, and the teacher-student structure. The RL algorithm (PPO in every case) is the least interesting part.

Measuring transfer

Transfer is a quantity you measure with hard numbers. The core metric is the sim-to-real gap in task performance:

gap = performance_sim − performance_real

evaluated on the same task and metric (success rate, tracking error, distance before failure, mean time between falls). A small gap on a hard, well-designed evaluation is the real signal. A policy that scores 99 percent in sim and 40 percent on hardware has a transfer problem no demo will reveal.

The evaluation practices that separate real results from lucky demos:

• Zero-shot deployment. Report performance on the real robot with the frozen sim-trained policy, no hardware fine-tuning. This is the honest measure of transfer, and it is what the ANYmal and Dactyl results reported.
• Held-out conditions. Evaluate on surfaces, payloads, and disturbances outside the training emphasis. A policy that only works on the one floor you tested on has not demonstrated robustness.
• Matched sim-versus-real trajectories. Run the same command sequence in sim and on the robot, log both trajectories, and align them. Where they diverge is where your simulator is wrong, and that divergence points directly at the parameter to fix or randomize. This real-to-sim comparison is the highest-value debugging tool in the whole pipeline.
• Perturbation sweeps. Systematically vary one condition (push force, added mass, friction) and plot performance against it. The curve shows you the edge of the robustness envelope, which a single pass-or-fail demo hides.
• Distribution coverage checks. Estimate where the real robot's parameters sit relative to your randomization distribution. If ξ_real is near the edge of p(ξ), transfer is fragile even when the average demo looks fine.

Metric	What it tells you	When it lies
Sim success rate	Upper bound on real performance	Always optimistic; ignores unmodeled effects
Zero-shot real success	Honest transfer measure	Depends heavily on the eval distribution
Sim-to-real gap	Size of the transfer problem	Small gap on an easy eval hides fragility
Perturbation sweep	Edge of robustness envelope	Only covers the perturbations you tested
Matched trajectory error	Where the simulator is wrong	Needs careful time alignment

Rule of thumb: The number that matters is zero-shot real-world performance on a hard, held-out evaluation, plus the matched sim-versus-real trajectory that shows you where the gap lives. A high sim score and a good demo video together prove almost nothing about transfer.

Pitfalls and failure modes

Most sim-to-real failures come from a short list of recurring mistakes.

Observation and action mismatch. The most common deployment bug is a mismatch between the observation the policy trained on and the one it receives on hardware: wrong field order, wrong scaling, wrong units, wrong history length, wrong action clipping. The network itself is rarely the culprit. The policy is a function fit to a precise input format, and any deviation is an out-of-distribution input. Write the observation-assembly and action-transform code once and share it byte-for-byte between sim and robot.

Unmodeled or wrong actuator dynamics. A simulator that treats the motor as an ideal source produces policies that oscillate, chatter, or fall when the real drivetrain adds delay and torque limits. The actuator model is the first thing to build and the first thing to suspect.

Randomization too narrow or too wide. Too narrow and the policy overfits sim and falls on the real floor. Too wide and it learns a timid, conservative controller or nothing at all. Both look like "sim-to-real does not work" and both are really a ranges problem.

Ignored latency. Real control loops carry delay that shifts phase and eats stability margin. A pure delay adds phase lag proportional to frequency with no amplitude warning, so a balancing policy that never trained against latency can go into a limit-cycle wobble on hardware. The delay you deploy with must fall inside the delay you randomized over.

Trusting sim near the fidelity boundary. Rewards and behaviors that depend on precise contact, slip, or deformation may be built on simulator fiction. Validate against real data before trusting anything near the physics model's weak points.

Reward hacking that only surfaces on hardware. A policy can exploit a simulator convenience (a foot vibrating for free, a contact-impulse glitch) that scores well in sim and collapses in reality. Watch the rendered rollouts, penalize the means as well as the ends, and treat the reward curve as a compliance report the optimizer wrote about itself.

Sim and real reset states differ. If the policy always starts from a clean upright pose in sim but the robot deploys from an arbitrary crouch, the initial-state distribution mismatches and the first second of deployment is out of distribution. Randomize initial states to cover deployment reality.

Rule of thumb: When a policy works in sim and fails on hardware, check in this order: (1) observation and action transforms, (2) the actuator model, (3) randomization ranges, (4) latency and jitter. The bug is almost always one of these, and it is almost never the RL algorithm.

Where sim-to-real is heading

Several threads are reshaping the field as of 2026.

Real-to-sim from perception. Instead of hand-building a digital twin, teams are reconstructing simulation-ready environments directly from real sensor data using neural radiance fields and Gaussian splatting, so the rendered appearance and geometry come from the actual deployment site. This shrinks the visual gap by construction and is especially promising for vision-based navigation and manipulation.

Differentiable simulation. Simulators that expose gradients through the physics step (Brax, Warp-based engines, differentiable MuJoCo variants) let system identification and even policy optimization use analytic gradients rather than black-box sampling. The promise is faster, more precise identification of the parameters that matter for transfer, though contact non-smoothness still makes the gradients tricky exactly where you most want them.

Foundation models and broad pretraining. Large vision-language-action models trained across many robots and tasks change the transfer question from "does this one policy cross the gap" to "does a broadly pretrained model adapt to a new embodiment with little data." Diverse pretraining data acts as its own form of randomization, and early results suggest broad priors transfer more gracefully than narrow single-task policies. See foundation models & VLAs for robotics.

Better contact and soft-body physics. The regimes where simulators are weakest (contact, friction, deformation) are the active research frontier, and every improvement there directly shrinks the hardest sim-to-real gaps.

The durable picture underneath all of this stays the same. You will train in simulation because it is cheap, safe, and parallel. You will face a reality gap because no simulator is the real world. And you will close that gap with the same three levers: widen the training distribution until reality falls inside it, move the simulator toward the measured truth, and give the policy a way to infer online what it cannot directly sense. The tools improve; the structure of the problem does not.

Frequently asked questions

What exactly is the reality gap? It is the difference between the distribution of simulated worlds a policy trained on and the single real world it deploys into. It has two parts: a dynamics gap (the simulator's physics differs from reality, especially in actuators, contact, mass, and latency) and an observation gap (simulated sensors are clean while real ones are noisy, biased, and, for cameras, visually different). The danger is that a trained policy actively exploits every difference the simulator leaves free.

Is domain randomization enough on its own? Often for dynamics, sometimes for vision, rarely for the hardest contact tasks. Randomization works when the real robot's true parameters fall inside the randomized range, which is realistic for masses, friction, and gains. It struggles when the simulator's model is structurally wrong (bad contact physics) because no amount of randomizing a wrong model produces the right behavior. The strongest pipelines combine randomization with system identification and, for vision, some domain adaptation.

Why does the actuator model matter so much? Because it is the largest and most exploitable single component of the dynamics gap for most robots. Real motors have delay, torque-speed limits, and gear friction that an ideal-source simulator ignores, and a policy trained against an ideal actuator learns behaviors that oscillate or fall when the real drivetrain adds those effects. A learned or carefully identified actuator model was the key ingredient in the ANYmal transfer results.

What is teacher-student learning and why is it standard for legged robots? You train a teacher policy with access to privileged simulator state (true friction, contact forces, terrain map) so it learns the skill quickly, then distill it into a student that uses only onboard sensors plus a short observation history. The history lets the student infer the privileged information online, effectively estimating the hidden state of a partially observable problem. It decouples learning the skill from learning to perceive, which is why it made blind rough-terrain locomotion reliable.

How do system identification and domain randomization work together? System identification measures the real robot to set the simulator's parameters near the truth, and randomization then perturbs those parameters to cover residual uncertainty and lifetime drift. Identify what you can measure well (masses, PD gains, latency, actuator response) and randomize hard what you cannot (foot-ground friction, contact stiffness, payload). Centering the distribution on the truth and then randomizing around it beats either technique alone.

Can I skip simulation and just learn on the real robot? Almost never at scale. A locomotion policy needs billions of environment steps, which is centuries of real time on one robot, and a half-trained policy is dangerous to run on hardware. Real-robot learning is reserved for small-budget fine-tuning with off-policy methods and heavy safety guards, and most production stacks in 2026 deploy a frozen sim-trained policy and improve it by improving the simulator.

Why do vision policies need different randomization than dynamics policies? The observation gap for cameras is about appearance: rendered images differ from real ones in texture, lighting, reflections, and blur. Visual randomization varies textures, lighting, camera pose, and distractors so the policy learns to rely on invariant structure (shape, relative position) rather than any specific appearance, which is what carries to real images. Dynamics randomization instead perturbs physical parameters and does nothing for the appearance gap.

How do I know whether transfer actually worked? Measure zero-shot real-world performance with the frozen policy on a hard, held-out evaluation, and compare it to sim performance to get the sim-to-real gap. Run perturbation sweeps to find the edge of the robustness envelope, and log matched sim-versus-real trajectories under the same commands to see exactly where the simulator is wrong. A high sim score and a good demo video together prove almost nothing.

Where are physics simulators least trustworthy? At contact and everything downstream of it: friction (foot slip, grasp slip), contact stiffness and restitution, simultaneous impulsive contacts, and any deformable, granular, or fluid material. These are exactly the regimes where sim-to-real is hardest, because the gap is largest where the physics model is weakest. Rigid-body dynamics in free space, by contrast, simulators handle well.

What is the first thing to check when a policy works in sim but fails on hardware? The observation and action transforms. The most common deployment bug is a mismatch between the observation format the policy trained on and the one it receives on the robot: field order, scaling, units, history length, or action clipping. Share the observation-assembly code byte-for-byte between sim and hardware, then check the actuator model, then the randomization ranges, then latency.