By Remi Bennett · Humanoid robot data · 24 September 2026 · 11 min read

Sim-to-real for humanoid robots: when should you calibrate the simulator?

A humanoid policy may walk reliably in simulation and still stumble on the physical robot. The cause can be actuator response, control latency, contact, payload, state estimation or a mismatch between the model and the robot's current configuration.

Calibrate when measurements show a mismatch that could change the decision you are using the simulator to make. Do not tune every parameter by default: first check interfaces and units, then identify which uncertainties the available data can actually constrain. For residual uncertainty, domain randomisation may be more useful than fitting a parameter the experiment cannot identify.

That distinction matters because calibration is not a certificate of safe hardware performance. It is a way to improve predictions within a defined model, dataset and operating regime. A recent humanoid payload-identification study, for example, calibrates a nominal robot model and then separately estimates the mass distribution of an unknown payload. Its results support that particular workflow, not a universal requirement to calibrate every robot before training.

MuJoCo Playground illustration showing simulated quadruped, humanoid and manipulation environments — MuJoCo Playground's project image illustrates the range of robot-learning environments in its paper. It is an illustration of that project, not evidence that a particular simulator matches a target robot. Source and image credit: MuJoCo Playground; see also the authors' paper.

What sim-to-real transfer means

Sim-to-real transfer means using a policy, controller or learned behaviour developed partly or wholly in simulation on a physical robot. In humanoid locomotion, the simulated policy observes a representation of robot state and issues joint targets or actuator commands; the real system has its own sensing, actuation, timing and contact behaviour.

Transfer is not a single algorithm. It is a chain of assumptions: the model, observation pipeline, controller interface, timing and task all need to be close enough for the policy to behave usefully. A mismatch can be tolerated, reduced during training, corrected through system identification, or caught through staged evaluation. Those approaches solve different parts of the problem.

Why a good-looking simulation can mislead

A simulator produces internally consistent results for the model and numerical settings it is given. That does not mean the model matches a particular robot. Two simulations can also disagree even when they use the same policy: different physics engines, solver settings, contact handling, actuator models or timestep choices can change the motion. MuJoCo's documentation, for example, describes the integration and constraint-solving choices involved in its forward dynamics rather than promising that a simulation is a hardware replica (MuJoCo simulation documentation).

For a humanoid, examine at least these mismatch sources:

Actuation: command scaling, torque limits, motor strength, friction, saturation and control mode.
Timing: policy frequency, actuator delay, state-estimation delay, communication jitter and action hold behaviour.
State: encoder offsets, filtering, IMU orientation and angular velocity, and coordinate-frame conventions.
Contact and mechanics: link masses, centre of mass, joint damping, foot geometry, ground compliance and collision parameters.
Configuration: battery, tools, protective equipment, shoes, payload and cable routing.

This list is a diagnostic checklist, not a claim that every factor matters equally for every robot or task.

Start with the transfer question, not a calibration campaign

Write down what the model will be used to decide. Is it screening gait ideas, comparing reward functions, training a policy for a fixed robot, evaluating a range of payloads, or preparing a cautious hardware trial? The required fidelity differs. A rough model may be useful for rejecting an obviously poor approach, while a decision about actuator limits or contact stability needs evidence tied to the target platform.

Then define the transfer boundary: robot serial/configuration, software and firmware versions, controller mode, observation fields, command units, nominal policy rate, task surface, payload, and reset conditions. If these are not fixed, “the sim-to-real gap” is not one stable quantity. It may be a change in the robot or its software rather than an error in the simulator parameters.

A staged calibration workflow

1. Check interfaces and units first

Before fitting physics, verify joint ordering, signs, offsets, units, frames, action scaling, limits and timestamps. Confirm whether the policy expects position, velocity, torque, or a normalised target, and how the robot converts it into actuator commands. Interface mistakes can look like model mismatch and are cheaper to test than a full calibration run.

Compare the policy's observation vector in simulation and on the robot: field order, filtering, frame, update rate, missing values and whether the values are measured, estimated or privileged simulator state. A policy trained with information that is unavailable on hardware cannot receive that same observation at deployment. The Isaac Lab transfer guide explicitly treats policy input/output mappings and actuator configuration as part of transferring a policy between physics backends (Isaac Lab policy-transfer guide).

2. Collect safe, informative measurements

Use controlled movements that are appropriate for the robot and approved by its safety process. Log timestamped commands and measured responses, along with the robot configuration and controller settings. Candidate signals include joint position and velocity, actuator command or estimated torque, IMU state, contact indicators and external motion capture when available.

A log is not informative merely because it is long. It should cover the operating range relevant to the task, separate input from response, and include enough timing information to reveal delay. Keep raw measurements, units, sensor calibration, software versions and exclusions with the dataset. If the policy will run at a particular frequency or under a specific controller mode, collect evidence in that regime rather than assuming a different mode is interchangeable.

Do not infer forces or physical parameters from signals the robot does not actually expose without documenting the estimator and its uncertainty. Some control stacks report commanded or estimated quantities, not direct measurements of motor torque or foot force.

3. Fit only parameters the data can identify

System identification uses observed inputs and outputs to estimate unknown model parameters. Depending on the robot and experiment, candidate parameters may include actuator gain or strength, delay, damping, friction, mass distribution or contact-related quantities. Not every parameter can be separated from every other one using a given dataset.

The MuJoCo System Identification Toolbox fits model parameters against recorded sensor data by minimizing the difference between measured and simulated outputs. Its examples also show how to package measured controls and sensor data for optimization. Treat each fitted value as conditional on the model and experiment, not as a universal property of the robot.

Fit against one portion of the recordings and evaluate against a separate portion or a different motion. Compare predicted and observed trajectories and timing, not only a single aggregate error. If several parameter combinations explain the calibration run, report the ambiguity rather than choosing a precise-looking value. A fit that cannot predict a withheld motion is not evidence that the model is ready for policy transfer.

4. Use domain randomization for residual uncertainty

Domain randomization trains across deliberately varied simulation parameters or conditions so that a policy is exposed to a broader range than one nominal model. It is useful when the plausible variation can be bounded and when robustness to that variation is relevant to the task. It does not tell you which parameter is wrong, and it does not guarantee robustness outside the ranges, contacts, hardware or observation assumptions used during training.

The MuJoCo Playground work is a concrete example of large-scale GPU training and sim-to-real experiments across tasks; its paper describes the training setup and the particular transfer results reported by its authors (MuJoCo Playground paper). Read those results as evidence about those experiments, not a guarantee for another robot or lab.

Choose randomization ranges from measured variation, documented tolerances, or clearly labelled hypotheses. Keep a record of which parameters were varied and how. Randomizing everything over arbitrarily wide ranges can make learning harder without making the eventual policy meaningfully safer.

5. Evaluate before expanding the claim

Use a staged evaluation appropriate to the platform: simulation regression tests, alternative-parameter or alternative-engine tests, hardware-in-the-loop where available, and supervised physical trials under the robot's established safety controls. Begin with constrained conditions and clear stop criteria. A successful transfer in one task, on one floor and one robot configuration does not demonstrate broad reliability.

Where possible, compare several versions under the same conditions and log failures as well as successes. Report the robot configuration, controller, policy interface, environment, number and type of trials, and the limits of the evaluation. Do not describe simulation success as hardware validation.

When to calibrate, randomize, or stop

Signal or situation	Useful next step	What it can establish	What it cannot establish alone
Joint response or delay differs from the model in a repeatable, measured test	Check interface and timing, then identify relevant actuator or delay parameters	Whether the model better predicts that measured response	Safe walking or general policy transfer
Several plausible parameter sets fit the same log	Collect a more informative, task-relevant excitation or report uncertainty	Whether additional data reduces ambiguity	That all unmeasured regimes are covered
Hardware variation is bounded but cannot be measured for every deployment	Randomize justified ranges during training and evaluate sensitivity	Robustness to the tested randomized conditions	Robustness beyond those ranges or conditions
Observation fields, units, frames or control modes do not match	Fix the software interface before physics tuning	Correctness of the tested input/output mapping	That the physical model is accurate
Transfer fails only after changing surface, payload or setup	Reproduce and document the changed condition; update the model or evaluation plan	Which changed condition correlates with failure	A single causal parameter without further testing
A mismatch is not understood, data are inadequate, or a stop criterion is reached	Pause hardware expansion and gather evidence safely	Recognition of a known limitation	Permission to continue a risky trial

Common mistakes

Tuning every parameter at once. This can obscure which measurements constrain which parameters. Start with interface, timing and parameters relevant to the task.
Treating a good calibration fit as validation. A model may fit its calibration data and still fail on another motion or contact condition. Hold out data and state what was tested.
Using randomization to hide a broken interface. Randomizing around incorrect units, frames or joint order does not fix those errors.
Assuming a simulator benchmark is a deployment recipe. Published results are bounded by their robots, controller stack, evaluation and reported conditions.
Ignoring the robot's current configuration. Payload or maintenance changes can invalidate assumptions made during earlier measurements.
Calling a policy “safe” because it survived simulation. Safety claims require platform-specific hazard analysis and controlled validation, not simulation alone.

What to document for a reproducible transfer

Keep a concise record with:

Robot model and physical configuration, including payload and relevant hardware changes.
Simulation, physics-engine, solver, model and controller versions.
Policy observation/action schemas, units, frames, control mode and update rates.
Measurement procedure, raw log locations, timestamp quality, sensor calibration and exclusions.
Parameters estimated, objective, data split, uncertainty or identifiability limitations.
Randomized parameters and ranges, including whether ranges are measured or assumed.
Evaluation conditions, trial counts, stop criteria, failures and permitted conclusions.

This record helps another team distinguish a result that is reproducible on the same setup from one that is merely plausible in a similar-looking simulation.

Frequently asked questions

Do I need a perfect simulator before training a humanoid policy?

No. Fidelity should match the decision and the risks. But before transferring to hardware, verify interfaces and the model assumptions that can materially affect the task, and use a controlled evaluation plan.

Does domain randomization replace system identification?

No. System identification estimates parameters from measurements under a model and experiment. Domain randomization trains across selected variation. They can complement one another: identify what the data support, then test or train for residual uncertainty.

Can I use the same policy across two simulators?

Not automatically. Compare observation and action mappings, actuator models, timing, solver and contact behaviour, then evaluate the policy in the target simulator. A guide showing a transfer workflow is not proof that arbitrary policies or models are equivalent.

Is sim-to-real transfer the same as sim-to-sim transfer?

No. Sim-to-sim compares simulation environments or physics backends. It can expose sensitivity to modelling choices, but it does not itself validate behaviour on the physical robot.

Search