M6-T14: Software-in-the-Loop simulation

Learning objectives

After this lesson, you should be able to:

• Describe what is real and what is simulated in PX4 SITL.
• Explain lockstep simulation and why it matters for repeatability.
• Inject failures (sensor loss, wind, link loss) to exercise failsafes.
• State what SITL cannot verify and which tests must follow on hardware.

Conceptual explanation

Implementation-specific Simulator choices, make targets and world files change between PX4 releases. The principles hold across them; use the simulation page of the documentation for your release.

In software-in-the-loop simulation PX4 is built for the host computer (a POSIX target) and runs as an ordinary process. A simulator provides the world: vehicle dynamics, sensor models (IMU, GNSS, barometer, magnetometer, cameras, lidar) and sometimes wind and obstacles. Sensor data flows into PX4, actuator outputs flow back. The ground station and ROS 2 nodes connect over MAVLink and DDS exactly as on a real vehicle.

What is real: the PX4 flight stack code (estimator, controllers, commander, navigator), the communication interfaces, and your companion-computer software. What is simulated: rigid-body physics and motors, sensor noise and failure models, the environment, the radio link, and the clock if lockstep is used.

Engineering intuition

SITL answers “is the logic right?” and does not answer “is the world as I modelled it?”. A planner that works in SITL has shown it handles the modelled sensor and physics; it has not shown it handles real vibration, real latency jitter, real lighting or a real compass. It is an excellent filter for software bugs and logic errors, and a poor predictor of tuning and sensor performance unless the models have been validated against real data.

The simulator’s fidelity is a design choice with a cost. A simple point-mass sensor model runs fast and tests logic; a model with measured noise, latency and bias costs effort and tests more. Choose the fidelity to match the question.

Mathematical formulation

Lockstep couples simulator and PX4 time: the simulator advances its clock one step, sends sensor data, and waits for PX4 to run one control step before advancing again. Simulated time then no longer depends on how fast the computer is, which makes runs repeatable. With a physics step $\Delta t_{\text{sim}}$ and a real-time factor RTF:

Reproducibility needs a fixed seed for every random model (sensor noise, wind) and fixed initial conditions; then the same inputs give the same outputs, which allows regression tests: assert on tracking error, time-to-goal or number of failsafe triggers. The statistical power of a simulation campaign comes from many runs with different seeds: with $n$ independent runs the standard error of a success rate $\hat{p}$ is $\sqrt{\hat{p}(1-\hat{p})/n}$, so confirming a 98 % success rate to ±2 % needs about 50 runs, and distinguishing 99.9 % from 99 % needs several hundred.

RTF

real-time factor (simulated time per wall-clock time).

$n$

number of independent runs.

Architecture and data flow

Simulator (physics, sensor models) → sensor messages (for example via the MAVLink HIL interface or a Gazebo transport plugin) → PX4 SITL (flight stack) → actuator messages → simulator. PX4’s MAVLink and DDS endpoints on UDP ports → QGroundControl and the companion software. Simulated camera and lidar data go directly to the companion via the simulator’s own transport (for example Gazebo topics bridged into ROS 2), not through PX4.

Real-world UAV applications

• Developing and regression-testing autonomy software without hardware.
• Exercising failsafes by injecting sensor failures, link loss and wind.
• Training pilots and operators on mission procedures.
• Collecting statistics over many randomised runs.

Implementation example

The standard start-up, run on a development machine (see the lab for the full set-up; targets and simulator names depend on the PX4 version). Shown for reference and not run by the tests.

git clone --recursive https://github.com/PX4/PX4-Autopilot.git
cd PX4-Autopilot && bash ./Tools/setup/ubuntu.sh        # toolchain and simulator dependencies
make px4_sitl gz_x500                                   # build and start PX4 SITL with a Gazebo x500 quadrotor (target names vary by version)

This runs as shown. A small campaign driver for Monte Carlo SITL-style runs: seeded randomisation, a pass/fail criterion and a confidence statement. The “vehicle” is a stand-in function; replace it with a call to your simulation harness.

import numpy as np
from math import sqrt

def one_run(seed):
    rng = np.random.default_rng(seed)                       # every random model is seeded: the run is reproducible
    wind = rng.normal(0, 1.5); delay = rng.uniform(0.02, 0.12)
    miss = abs(0.15 * wind) + 3.0 * (delay - 0.02) + 0.05 * rng.standard_normal()       # stand-in for 'final position error' of a landing
    return miss < 0.6
assert one_run(7) == one_run(7)                             # same seed, same outcome
n = 400; passes = sum(one_run(s) for s in range(n)); p = passes / n
se = sqrt(p * (1 - p) / n); lo = p - 1.96 * se
print(f"success rate {p:.3f} +- {1.96 * se:.3f} (95 %), lower bound {lo:.3f}")
assert 0.9 < p < 1.0
need = lambda p0, half: int(np.ceil(1.96 ** 2 * p0 * (1 - p0) / half ** 2))
print("runs needed to confirm 98 % to +-2 %:", need(0.98, 0.02), "; 99.9 % to +-0.1 %:", need(0.999, 0.001))

Common engineering mistakes

Failure modes

Debugging approach

1. Fix seeds and rerun the failing case; step through with logs.
2. Check RTF and lockstep status.
3. Compare simulated sensor streams to real recorded ones for noise and latency.
4. Replay recorded real data into the companion to separate software from simulation issues.

Practical exercises

1. Start PX4 SITL, fly a mission, and download the log; compare its estimator noise to that of a real log.
2. Inject a GNSS failure mid-mission and record the failsafe.
3. Run the same scenario with ten seeds and report the spread of landing error.
4. List five effects your simulator does not model that matter for your vehicle.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• PX4: Simulation
• PX4: Gazebo simulation
• Gazebo documentation

What’s next