Sim-to-Real Robotics: A Practical Guide for 2026

Sim-to-real robotics is the process of training a controller or policy in simulation and making it work on a physical robot. The transfer succeeds when the simulation captures the decisions the policy needs, the real system stays inside the modelled envelope, and deployment is gated by staged tests. Sim-to-real is not a single export button: it is a chain of modelling, randomization, evaluation and hardware tuning.

Microduck publishes that chain for a small biped: mjlab training environments, MuJoCo Warp simulation, PPO policy learning, ONNX export and a 50 Hz onboard runtime. Those details are useful as a worked example, but the principles below apply to arms, quadrupeds and other embodied-AI systems.

What is the sim-to-real gap?

The sim-to-real gap is the difference between the conditions represented by a simulator and the conditions a physical robot actually encounters. It comes from both visible differences, such as floor friction, and invisible ones, such as motor heating, communication delay and sensor calibration drift.

A policy can score well in simulation while failing outside it for a simple reason: the policy learned the simulator as much as the task. Sim-to-real work reduces that incidental learning and tests whether the behaviour survives conditions the training run did not explicitly reward.

Why does a trained robot policy fail on hardware?

A simulation policy usually fails on hardware through a combination of model error, distribution shift and integration error. The common causes below are useful diagnostic categories, not a checklist that can guarantee transfer.

How does a sim-to-real pipeline work?

A practical pipeline has seven stages. Each stage should produce evidence that can be reviewed before the next one runs.

1. Define the task and operating envelope. Name the behaviour, starting state, success condition and unsafe outcomes before training.
2. Model the robot. Include joint limits, actuator strength, mass, inertia, sensor layout and control rate. Where exact parameters are unknown, record ranges rather than false precision.
3. Train in simulation. Start from a task that already works, then change one major factor at a time.
4. Randomize the uncertainty that matters. Randomization should represent plausible hardware variation, not arbitrary noise that makes learning impossible.
5. Evaluate across scenarios. Test held-out terrains, initial conditions, disturbances and durations that were not sampled in training.
6. Export through the supported path. Keep normalizers, metadata and policy contracts aligned with the runtime.
7. Deploy through a test ladder. Validate shape, simulation replay, realistic simulation, bench behaviour and then supervised floor tests.

Pipeline advice becomes concrete only when connected to a deployed system. The Microduck training guide shows the robot-specific path, while the policy evaluation guide defines the evidence to collect before hardware testing.

What should you randomize in simulation?

Randomize the physical and computational differences your hardware can actually encounter. Start with a small list tied to observed or measured variation, then expand it as the evaluation suite reveals new failure modes.

• Actuation: motor strength, friction, backlash, voltage sag and maximum torque.
• Timing: observation latency, command latency and dropped control cycles.
• Contact: floor friction, restitution, slopes and small terrain discontinuities.
• Body dynamics: link mass, centre of mass and payload where the hardware allows variation.
• Sensing: bias, noise, quantization and temporary dropout.
• Initial state: joint offsets, body height and orientation at episode start.

Too much overlapping randomization makes failures hard to attribute. Change one category at a time, keep the same evaluation seeds and compare the new policy against a stable baseline.

How do you evaluate whether transfer worked?

Evaluate task success, safety and repeatability separately. A policy that finishes the task but falls during half the trials has not transferred successfully, and a policy that stays upright by refusing to move has not completed the task.

Use the same starting-state suite and measurement method across policies. Record more than an average score: preserve per-episode results, intervention counts, failure categories and the exact policy version. The robot policy evaluation framework provides a practical metric and test-gate structure.

How does Microduck apply sim-to-real?

Microduck trains in mjlab with MuJoCo Warp and PPO, exports policies to ONNX through the official exporter and runs the resulting controller on the robot at 50 Hz. The current policy contract maps 61 observations to 14 joint targets, and the normalizer is baked into the ONNX graph during export.

The public training code documents actuator modelling, domain randomization and export. The software architecture explains how the runtime protects the motor path, while the policy guide covers loading, testing and publishing behaviours.

Microduck is a compact finished robot, so its most relevant experiments are desk-scale locomotion, recovery and control-policy transfer. It is not a substitute for a high-payload industrial arm or a full-size humanoid platform.

When is sim-to-real a poor fit?

Sim-to-real is a poor fit when the missing physics dominates the task and cannot be modelled or safely explored. Examples include fine manipulation with unmodelled contact geometry, tasks that depend on human safety judgement or experiments requiring hardware the simulator cannot approximate.

It is also the wrong label for a policy that has never been run outside simulation. A successful training curve is an input to transfer testing, not proof that transfer happened.

Sim-to-real robotics FAQ

What does sim-to-real mean in robotics? It means transferring a controller or policy trained in simulation onto a physical robot and validating that it behaves safely and reliably.

Why do simulated robot policies fail in the real world? Simulation cannot capture every actuator, contact, timing and sensor effect. Policies can also overfit to one scene or learn the wrong reward.

Is domain randomization enough for sim-to-real? No. It helps expose the policy to variation, but actuator modelling, delay, systematic evaluation and safe hardware testing remain necessary.

How do I know a policy transferred successfully? Predefine task and safety metrics, run held-out scenarios and require the policy to pass staged simulation, bench and supervised hardware tests.

Can I learn sim-to-real without a robot? You can learn the modelling, training and evaluation workflow in simulation. Hardware transfer requires physical validation and supervision.

How does Microduck train and deploy policies? It uses mjlab, MuJoCo Warp, PPO and ONNX export, then runs the exported policy on its 50 Hz onboard control loop.

Key takeaways

• Sim-to-real is a validation pipeline, not just a simulation export.
• Model actuators, timing, contact and sensors before chasing reward changes.
• Domain randomization should reflect plausible hardware variation.
• Evaluate per-episode safety and repeatability, not only average reward.
• Deploy through shape checks, simulation replay, bench tests and supervised floor tests.
• Public training and deployment code makes Microduck a useful small-scale case study.

Where to go next

• Robot policy evaluation - define the evidence before hardware testing
• Biped robot reinforcement learning - the locomotion-specific workflow
• How to train Microduck - the concrete mjlab and ONNX path
• Microduck policies - export, test and publish controller files
• Microduck software architecture - onboard runtime and safety boundaries
• Microduck for AI research - assess whether the platform fits a lab study