Skip to content

Real2Sim

This guide covers the inverse direction of transfer: bringing the simulator closer to the real platform before policy replay or deployment. In practice, this is mostly a parameter-alignment problem.

Core Idea

The main methodology is to use system identification on real-world data, then update the simulation parameters so the simulated platform better matches the measured dynamics of the real one.

In LAV2, that means revisiting the parameters and assumptions that feed the simulation stack, especially VehicleParams, rotor dynamics, mixer behavior, and any task-side normalization or rate assumptions built on top of them.

Two Practical Paths

There are two common ways to approach real-to-sim alignment.

The first is explicit parameter identification. You collect real-world flight or drive data, estimate the platform parameters from that data, and then update the simulator so those parameters are reflected in the model.

The second is robustness through domain randomization. Instead of trying to identify one best parameter set, you train policies across a range of plausible parameters and rely on the real platform falling inside that distribution.

The first path improves fidelity directly. The second path improves tolerance to model mismatch. In practice, they are often combined rather than treated as exclusive choices.

What Usually Needs Alignment

For LAV2, the most important alignment targets are:

  • mass and inertia
  • rotor thrust and torque coefficients
  • motor lag, rate limits, and initial RPM assumptions
  • mixer-related scaling and normalized command interpretation
  • control frequency and decimation assumptions
  • observation scaling and frame conventions used during training

These are the parameters most likely to create a visible gap between real behavior and simulation behavior if they are inaccurate.

System Identification Workflow

A practical workflow is:

  1. record real-world or bench-test data under representative operating conditions
  2. identify the parameters that explain the measured response
  3. update the corresponding simulation-side parameters
  4. re-run transfer tests in Sim2Sim
  5. repeat until the replay stack behaves closely enough to be useful

This is why Real2Sim belongs before Sim2Sim in the transfer sequence. A policy tested in MuJoCo is only meaningful if the MuJoCo-side model is already close enough to the real platform.

Where The Changes Land In LAV2

Most of the resulting adjustments eventually land in:

If the mismatch is not purely physical but instead comes from command or observation interpretation, then the relevant changes may also involve lav2.controller.mapping, lav2.runner.common.mujoco, or task-side observation definitions in the RL backend.

References

API Cross-References