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 and its platform-specific TrackVehicleParams, 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 path is robustness through domain randomization. Instead of trying to identify one best parameter set, policies are trained across a range of plausible parameters and the real platform is expected to fall inside that distribution. For how this is represented inside LAV2's simulation stack, see Domain Randomization.

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, inspect FlightActionMapper or DifferentialDriveActionMapper. Replay behavior is configured through MuJoCoPlayConfig and executed by MuJoCoPlayRunner; task-side observation definitions remain backend-specific.

References

API Cross-References