Embodied AI and the Sim-to-Real Gap

You train a manipulation policy in simulation. In sim it succeeds 98% of the time across ten thousand randomized environments. You load it onto the physical arm, hit run, and it grasps air, overshoots the part, or oscillates until the safety controller cuts power. Welcome to the reality gap — the single most reliable way embodied AI projects miss their timelines.

Simulation is not optional. No one is going to teleoperate the millions of trajectories a robust policy needs, and you cannot run reinforcement learning on hardware that breaks and takes wall-clock days per epoch. Sim is where scale comes from. But sim that you trust without discipline is how you ship a robot that works in the demo video and nowhere else. Here is the engineering picture in 2026.

Why the gap exists#

A simulator is a model of physics, and every model is wrong in specific, exploitable ways. The reality gap is the accumulated divergence between that model and the world. It shows up in three layers, and a policy will happily overfit to all of them.

Physics. Friction coefficients, contact dynamics, joint damping, actuator latency, link masses, motor backlash — the simulator uses nominal values, the real robot has manufacturing variance, wear, and temperature drift. Contact-rich tasks are the worst offenders, because the moment two rigid bodies touch, small errors in the contact model produce large differences in outcome.

Perception. A rendered camera frame is too clean. Real sensors have rolling shutter, motion blur, lens distortion, exposure shifts, and noise. A vision policy trained on pristine renders learns to depend on textures and lighting that the real camera never reproduces.

Latency and control. In sim, observation and action are instantaneous and perfectly synchronized. On hardware there is sensing delay, compute delay, and actuation delay, and a policy that assumed zero latency becomes unstable when the loop closes 30ms late.

The cruel part is that reinforcement learning is an optimizer, and optimizers find loopholes. If the simulator lets a policy exploit a quirk of the contact solver to get a higher reward, it will — and that strategy evaporates the instant it meets real friction. High sim reward is not evidence of a good policy. It is evidence the policy learned the simulator.

Domain randomization: don’t model reality, span it#

The dominant fix is counterintuitive. Instead of trying to make the simulator match reality exactly — a fool’s errand — you randomize the simulator so aggressively that reality becomes just one more sample from the training distribution. If the policy has seen friction from 0.4 to 1.2, masses perturbed by 20%, and a thousand lighting conditions, the real robot’s actual friction is nothing special. The policy learned to be invariant to the thing it can’t measure.

NVIDIA’s Isaac Sim bakes this in across every layer. Physics randomization perturbs masses, friction, PD gains, joint damping, and actuation limits. Rendering randomization varies lighting, textures, and backgrounds. Sensor models inject additive noise, miscalibration, and rolling-shutter effects. The GPU-accelerated Isaac Lab framework runs thousands of these randomized environments in parallel, which is what makes the approach tractable — you need volume for randomization to cover the space.

The same engine feeds NVIDIA’s GR00T humanoid foundation model. The GR00T-Gen workflow uses Isaac Sim plus the Cosmos platform to expand demonstration datasets through domain randomization and 3D augmentation, generating synthetic motion data at a scale teleoperation could never reach. NVIDIA has reported that simple pick-and-place transfers can hit 80-90% success with zero real-world fine-tuning when trained on tens of thousands of episodes with aggressive randomization. Note the qualifier: simple pick-and-place. The further you get from that — fine manipulation, deformable objects, long horizons — the more the gap reopens and the more real data you need.

Domain randomization has a cost worth stating plainly. Forcing invariance to a huge parameter range produces a more conservative, less optimal policy. You trade peak performance for robustness. That is almost always the right trade for deployment, but it is a trade, and a policy that looks sluggish in sim may simply be a policy that will survive contact with reality.

The discipline that actually closes the gap#

Randomization narrows the gap. Eval discipline is what tells you whether you’ve closed it enough to ship — and this is where most teams are sloppy.

Sim metrics are not real metrics#

A number from the simulator measures how well the policy games the simulator. It is a development signal, never an acceptance criterion. The only metric that counts is success rate on the physical robot, in the deployment environment, on held-out task instances. We treat the sim-to-real transfer like a train/test split where the test set is reality itself, and we refuse to report sim numbers as if they were results.

Evaluate on hardware, on a held-out distribution#

Real-robot evaluation is slow and expensive, which is exactly why teams skip it and exactly why they get burned. Build a fixed physical eval suite — a set of object poses, lighting conditions, and task variants the policy never trained on — and run it on the real hardware every time before you trust a checkpoint. The same instinct that makes a School ERP trustworthy applies here: you don’t grade a system on the data it studied. Run enough physical trials to get a real success rate with error bars, not a hero demo.

System identification meets randomization#

Pure randomization is conservative; pure system identification (measuring your specific robot’s parameters and matching the sim to them) is brittle. The pragmatic move is both — calibrate the simulator to your hardware’s measured friction and latency so the distribution is centered correctly, then randomize around that center to cover residual error. This narrows the range you have to span and recovers some of the performance that blind randomization throws away.

Watch the failure modes, not just the rate#

A 90% success rate hides everything that matters. The 10% of failures tell you whether the gap is in perception (fails under certain lighting), physics (fails on heavier parts), or latency (oscillates near contact). Logging and classifying failures turns an opaque number into an engineering to-do list. This is ordinary MLOps practice — observability on the model’s actual behavior — applied to a robot.

Close the loop with real-to-sim, not just sim-to-real#

The strongest teams in 2026 run the arrow both directions. Sim-to-real trains the policy; real-to-sim uses hardware data to correct the simulator. You record real trajectories, compare them against what the simulator predicts under the same commands, and use the residual to refine the physics parameters and sensor models. The simulator stops being a fixed asset and becomes a thing you tune against ground truth, which is what techniques like reconstructing real scenes into the simulator are reaching for. Each cycle tightens the distribution the policy trains on, and the gap you measure on the physical eval suite shrinks for a reason you can point to, not by luck.

This is also where ordinary Data Platforms discipline pays off. Real-robot trajectories are scarce and expensive, so they deserve the same versioning, schema, and lineage you would give any high-value dataset. A team that throws away its hardware logs after a debugging session is discarding the exact signal that calibrates the next simulator. Treat every physical run as a labeled sample of reality and store it like one.

What we tell teams#

A few hard-won positions.

Sim is a draft, hardware is the edit. Use simulation to get a policy that is plausibly good and to burn through the search space cheaply. Then budget real time and real episodes for the fine-tuning and evaluation that actually certify it. The teams that fail are the ones who treat sim as the finish line.

Contact-rich tasks need more real data — accept it. Free-space motion, navigation, and locomotion transfer reasonably well from heavily randomized sim. Insertion, deformable manipulation, and anything where forces matter will need on-hardware fine-tuning. Plan the budget around the hardest contact task, not the easiest reach.

Treat the gap as a measurable quantity, not a vibe. The difference between your sim success rate and your hardware success rate, tracked over time per task, is the single most useful number in an embodied AI program. When it shrinks, your randomization and calibration are working. When it doesn’t, no amount of more training in sim will save you — and that is a finding, not a failure.

The reality gap is not a bug that a better simulator will eventually eliminate. It is structural: a model of physics will always diverge from physics. The teams that ship in 2026 are not the ones with the most photorealistic renderer. They are the ones with the discipline to randomize hard, calibrate to their hardware, and evaluate on the only test set that matters — the real one.

---

Got a policy that aces sim and stalls on hardware? We build the randomization, calibration, and physical eval harnesses that close the gap before deployment. Talk to our engineers.