AI-generated editorial illustration. It explains the simulation-to-reality transfer problem and does not represent measured data.
1. The central question
Simulation offers an irresistible bargain: a robot can fall, collide, restart and repeat a task millions of times without damaging hardware or consuming human supervision. Yet a policy that walks perfectly in a physics engine may stumble on its first real step. What, then, actually transfers from a simulator to a robot?
The answer is not a complete behavior copied from a virtual world. What transfers is a policy shaped by the regularities the simulator represented well enough: broad relationships between observations and actions, useful coordination patterns, robustness across deliberately varied conditions, and sometimes an initial model of the robot’s dynamics. Everything else—friction, actuator delay, camera response, flexible contact, wear and environmental disorder—can invalidate that policy. Successful sim-to-real work is therefore a process of deciding which mismatch to model, which to randomize, which to adapt online and which to correct with real data.
2. Conceptual foundation
A simulator advances a mathematical state through time. It represents rigid bodies, joints, actuators, contacts and sensors using models and numerical solvers. MuJoCo, for example, combines generalized joint coordinates with optimization-based contact dynamics and exposes tools for control, state estimation, system identification and parallel sampling. Isaac Lab builds robot-learning workflows around accelerated physics, vectorized environments, rendering and randomization. These systems are powerful because they are controlled approximations, not because they duplicate every detail of matter.
The reality gap is the difference between the distribution of situations experienced in simulation and the distribution encountered by hardware. It includes a dynamics gap—mass, friction, motor behavior and contact—as well as a perception gap involving lighting, textures, camera noise and occlusion. Timing, communication delay, controller implementation and calibration add further gaps. A transfer method succeeds when the learned policy remains useful despite the mismatches relevant to its task.
3. How the system works
A typical pipeline begins with a digital robot model and a task environment. Engineers specify geometry, joints, actuator limits, sensors, objects, rewards or demonstrations. Thousands of environment instances can then run in parallel, generating experience for reinforcement learning or synthetic trajectories for imitation learning. The trained policy consumes the same kinds of observations expected on the robot and produces commands in a compatible action space.
Before deployment, teams may calibrate simulator parameters against recorded hardware trajectories, randomize parameters during training, or do both. The policy is exported into the real control stack, where observation normalization, control frequency, joint conventions and safety limits must match training. Hardware trials expose residual errors. Engineers then collect targeted data, adjust the simulator, adapt the policy or narrow the operating envelope. Sim-to-real is a loop between virtual and physical systems, not a one-way export button.
4. Major approaches
System identification attempts to make the simulator resemble a particular robot. Known commands are applied to hardware, and observed motion is compared with simulated predictions. Parameters such as mass, damping, friction, motor strength or latency are adjusted to reduce the discrepancy. This is efficient when a compact parameter set explains the behavior and the experiments excite those parameters clearly. It is harder when contact, compliance and hidden low-level controllers dominate.
Domain randomization takes the opposite stance: instead of finding one accurate simulator, train across many plausible simulators. Masses, friction, gains, delays, terrain, lighting or sensor noise vary from episode to episode. The policy is encouraged to rely on features that remain useful across the range. Randomization can improve robustness, but ranges chosen too narrowly miss reality; ranges chosen too broadly can force a conservative policy that sacrifices precision.
Adaptive identification uses new interactions to infer current dynamics. Dynamics as Prompts conditions on recent history and adjusts environment parameters without gradient updates. SPI-Active chooses exploration commands intended to reveal uncertain physical parameters. Such approaches can react to object or robot variation, but they require safe, informative hardware interaction and a model family capable of expressing the difference.
Hybrid simulation and real-data training uses simulation for broad coverage, then fine-tunes or calibrates with a smaller set of real trajectories. This avoids demanding perfect zero-shot transfer. It also changes the economic question: the aim becomes reducing costly hardware data, not eliminating it. Hybrid methods are often the most practical when contact-rich manipulation or changing environments leave systematic residual errors.
5. Evidence and examples
SPI-Active, published at CoRL 2025, studies contact-rich legged systems where conventional identification assumptions can fail. It combines massive parallel parameter sampling with active exploration designed around Fisher information. The authors report improvements of 42–63% over included baselines across their evaluated locomotion tasks. This supports targeted identification on those robots; it does not establish the same gains for manipulation or vision-heavy tasks.
Dynamics as Prompts tests in-context identification on object scooping and table air hockey. Its authors report stronger parameter estimation than their baselines in sim-to-sim tests and at least 70% success for sim-to-real object scooping across three objects. The case shows why fixed parameters may be insufficient when interaction dynamics change, while its two-task scope limits broader conclusions.
DROPO uses an offline set of trajectories to estimate a distribution over simulator parameters rather than a single best setting. Its likelihood-based approach represents uncertainty and was evaluated in two zero-shot transfer scenarios. The method is important because the fitting data can be collected before policy training, avoiding repeated online policy deployment. Its estimates still depend on the parameters and phenomena available inside the simulator.
Isaac Lab and MuJoCo illustrate the enabling infrastructure rather than a single transfer result. Both support large-scale sampling; Isaac Lab explicitly provides domain-randomization workflows, while MuJoCo exposes configurable contact, actuation and system-identification tools. These capabilities make experiments possible. They do not decide which parameters matter for a particular robot.
6. Trade-offs
The primary trade-off is fidelity versus scale. Detailed contact and actuator models can reduce mismatch but require measurements, engineering effort and computation. Simpler models run more environments faster and may be sufficient for broad locomotion patterns, yet fail on tight insertion, deformable material or force-sensitive tasks.
There is also accuracy versus robustness. System identification concentrates training near one estimated robot. It can support precision if the estimate is correct, but may become brittle as hardware warms, wears or carries a new payload. Domain randomization broadens coverage, but the resulting policy may avoid aggressive behavior that would be optimal on the actual machine.
Real-data efficiency versus safety creates another tension. Active exploration can reveal dynamics faster than passive trajectories, but deliberately informative commands may stress hardware. Offline identification is safer and reusable, though recorded data may not excite the parameters needed for a new task. Online adaptation responds to change but adds inference, monitoring and failure-handling requirements at deployment.
Finally, visual realism competes with physical realism for resources. Photorealistic images help vision models only if task-relevant appearance is represented. For a blind locomotion controller, actuator delay may matter far more. For object picking, camera calibration and asset geometry may dominate. “More realistic” is not a single direction.
7. Current limitations
Several physical effects remain difficult to model economically: cable stretch, gear backlash, stiction, soft materials, fluid movement, wear and intermittent contact. Engineers can compensate for an unmodeled phenomenon by changing other parameters, but that compensation may break in a different task. Sensor simulation has similar limits when real cameras apply undisclosed processing or when tactile sensors drift.
Evaluation is fragmented. Papers use different robots, tasks, baselines and definitions of zero-shot transfer. A successful demonstration may cover a narrow initial-state distribution and a newly calibrated machine. Few reports expose the complete engineering effort required to build assets, identify actuators, tune randomization and integrate the real controller. Simulation results alone cannot establish deployment reliability.
8. Open questions
How should a system decide whether a failure comes from the policy, the simulator, perception or low-level control? Automated diagnosis would make the sim-to-real loop less dependent on expert intuition. Researchers also need methods that identify which parameters are observable from available trajectories and which are effectively interchangeable.
Another question is whether learned world models can complement physics engines without replacing known mechanics. A learned residual could capture actuator or contact behavior that is difficult to specify, but it may extrapolate unpredictably. Transfer benchmarks also need transparent levels: zero-shot deployment, deployment after parameter calibration, and deployment after policy fine-tuning should not be reported as equivalent achievements.
9. Editorial synthesis
The most credible strategy is layered. Use known mechanics to build a simulator that is correct in the dimensions the task clearly depends on. Identify a small set of measurable robot-specific parameters. Randomize the uncertainty that remains, rather than every available setting. Then reserve real-world trials for calibration, failure discovery and targeted fine-tuning.
System identification is strongest when precision matters and the robot is stable enough to characterize. Domain randomization is strongest when variation is inevitable and exact calibration is not economical. Adaptive methods become valuable when payloads, surfaces or hardware condition change during operation. None removes the need to test the physical system. The purpose of simulation is to make those tests fewer, safer and more informative—not to turn virtual success into evidence of real deployment by itself.
10. Key takeaways
- Simulators transfer useful regularities, not perfect copies of physical behavior.
- System identification narrows the gap around a measured robot; domain randomization trains across uncertainty.
- Online adaptation and active exploration can track changing dynamics but introduce safety and complexity costs.
- Visual, dynamic and control-timing gaps are distinct and should be addressed according to the task.
- Real-hardware evaluation remains necessary even when a policy is described as zero-shot sim-to-real.
11. Further reading
- What Is Robot Simulation? — begin with physics engines, environments and virtual sensors.
- How Robots Learn Through Reinforcement Learning — understand why parallel simulated experience is valuable.
- Why Robots Generate Actions in Chunks — examine how a learned policy produces commands once transferred to a physical controller.
12. Sources & evidence
- Sobanbabu et al., Sampling-based System Identification with Active Exploration for Legged Sim2Real Learning, CoRL 2025.
- Zhang et al., Dynamics as Prompts: In-Context Learning for Sim-to-Real System Identifications, 2024; revised 2025.
- Tiboni, Arndt and Kyrki, DROPO: Sim-to-Real Transfer with Offline Domain Randomization, journal version 2023.
- NVIDIA, Isaac Lab Documentation.
- Google DeepMind, MuJoCo Documentation: Overview.
Sources
Accessed: 2026-09-02
-
Sampling-based System Identification with Active Exploration for Legged Sim2Real Learning
Nikhil Sobanbabu, Guanqi He, Tairan He, Yuxiang Yang and Guanya Shi. CoRL 2025, PMLR 305.
https://proceedings.mlr.press/v305/sobanbabu25a.html
Supports: targeted system identification, active exploration, domain-randomization limitations and locomotion experiments. -
Dynamics as Prompts: In-Context Learning for Sim-to-Real System Identifications
Xilun Zhang et al. Submitted 2024-10-27; revised 2025-02-28.
https://arxiv.org/abs/2410.20357
Supports: online parameter adaptation from interaction history and object-scooping evidence. -
DROPO: Sim-to-Real Transfer with Offline Domain Randomization
Gabriele Tiboni, Karol Arndt and Ville Kyrki. Robotics and Autonomous Systems, volume 166, 2023.
https://arxiv.org/abs/2201.08434
https://doi.org/10.1016/j.robot.2023.104432
Supports: likelihood-based offline estimation of dynamics distributions and zero-shot transfer cases. -
Isaac Lab Documentation
NVIDIA. Continuously updated official documentation.
https://isaac-sim.github.io/IsaacLab/v2.1.1/index.html
Supports: vectorized simulation, domain randomization, rendering and robot-learning workflow capabilities. -
MuJoCo Documentation: Overview
Google DeepMind. Continuously updated official documentation.
https://mujoco.readthedocs.io/en/stable/overview.html
Supports: articulated-body simulation, contact formulation, system identification and parallel sampling capabilities.

