Simulation is cheap: you can run ten thousand policy training iterations overnight without touching a robot. Hardware takes time, wears out, and cannot run in parallel across a server rack. Training in simulation is therefore useful, but its results can still fail on hardware.
The gap is the problem. A policy trained only in simulation can fail on hardware because friction, camera noise, joint compliance, and part surfaces differ from reality. It may exploit simulated traits that do not exist physically while missing hardware traits absent from the simulator. The mismatch is especially costly in contact rich tasks.
Sim to real transfer reduces the gap enough for deployment, though some gap always remains. The engineering question is which methods provide the most useful reduction for the least added cost. Transfer does not eliminate the gap. It makes deployment tractable.
Sources of the Gap
The sim to real gap has several sources. Categorizing them helps match each source with the right strategy.
The first source is dynamics mismatch. Simulators approximate rigid body dynamics, actuator behavior, and contact physics. Their default Coulomb friction model may not capture a polyurethane gripper contacting an ABS plastic housing, while a spring damper model may miss a backdrivable servo's compliance. Such errors compound across contact events, especially in contact rich manipulation.
The second source is visual mismatch. Synthetic simulator images differ from real camera images in texture, specular highlights, and sensor noise structure. A policy that detects part edges in rendered images may behave differently when those edges appear differently on real images.
The third source is what simulation omits. A production line can add conveyor vibration, temperature changes affecting joint compliance, lighting variation, and part batch variation. Clean simulation gives the policy no learned response to these real world disturbances.
Domain Randomization Baseline
Domain randomization is a common starting point. During training, friction, lighting, textures, and camera noise vary across ranges. The policy must handle many simulated conditions rather than fit one. The aim is for real conditions to fall within that randomized distribution.
This works up to a point. For coarse manipulation, domain randomization can yield acceptable transfer. Tight tolerances and subtle sensor cues are harder: the simulated distribution may not cover reality, so the policy can still fail.
We use domain randomization as one component, not the whole answer. It provides a useful foundation, then other strategies address specific gaps.
System Identification and Calibration
Instead of randomizing broadly, system identification measures deployment hardware and tunes the simulator to match it. Controlled robot experiments measure compliance, friction, and inertia, which then guide the dynamics configuration.
If a gripper's friction coefficient for a material is about 0.6 plus or minus 0.1, the range need not begin at 0 or span 0.1 to 1.5. A tighter distribution around the measured value usually improves policy quality in that regime.
For cameras, deployment calibration measures sensor characteristics and adjusts rendering accordingly. This costs more to set up than pure randomization but better matches fixed hardware. Customer owned sensors can justify it; products targeting arbitrary hardware generally favor randomization.
Real Data After Deployment
A reliable strategy starts with a sim trained policy good enough for shadow mode or human oversight. Real operation supplies data for fine tuning, closing the gap empirically rather than analytically.
The initial policy must be good enough to generate useful data. One failing on 60% of real attempts produces too few reliable input output pairs. Sim to real transfer matters because the simulated policy gets the system into real operation, where fine tuning data can be collected.
On a welding wire dispenser assembly task piloted with a small manufacturing firm in 2025, the sim trained policy reached about 78% success on the real line. That supported supervised operation, real demonstrations, and fine tuning. After two rounds using roughly 80 production examples, it reached unsupervised operation within its envelope. Over about three weeks, deployment moved from not deployable to supervised to autonomous.
What We Are Not Solving
Sim to real transfer is a bootstrapping tool. It puts an initial policy on hardware sooner than starting with physical demonstrations. It does not provide arbitrary generalization: performance remains bounded by the training task distribution. Other tasks need new demonstrations or another training run.
Some tasks gain little from simulation when their physics is too specialized or difficult to model. Fine insertion below a millimeter, deformable material handling, and wire harness routing are examples. We focus on tasks where simulation helps: pick and place with moderate variation, compliant insertion above sub millimeter tolerances, and cluttered manipulation with configural rather than geometric uncertainty.
The Honest Summary
Our workflow transfers sim trained policies to hardware at acceptable quality for our target tasks. We built a deployment pipeline combining domain randomization and system identification for manufacturing hardware, with on site calibration that needs no custom equipment. A new deployment can reach supervised operation on day one and autonomous operation within a few weeks of real fine tuning, without first collecting a long set of physical demonstrations.