The validation ladder
No single test proves a flight controller. Teams build confidence step by step, moving from fast, cheap and safe tests to slow, expensive and risky ones:
| Stage | What it tests | What it misses |
|---|---|---|
| Unit and module tests | Individual functions, filters and state machines | Interactions, timing and hardware |
| Software-in-the-loop (SIL) | The full flight code against a simulated vehicle on a PC | Real processor timing, real sensors and I/O |
| Hardware-in-the-loop (HITL) | The real flight-controller board with a simulated vehicle | Real sensors and their mounting |
| Attitude test rig | Real sensors and attitude control under physical rotation | Translation, aerodynamics and outdoor conditions |
| Tethered and flight tests | Everything together | Nothing, but every test costs time and carries risk |
Software-in-the-loop: test every commit
ArduPilot and PX4 both ship software-in-the-loop simulators (SITL) that run the real flight code on a PC against a vehicle model, with Gazebo and other physics engines available. Because SIL needs no hardware, it can run automatically on every code change: missions, failsafes, parameter changes and edge cases that would be dangerous to try in the air.
Its blind spot is everything physical: processor load and timing, sensor noise, wiring, and the interaction between the airframe and the controller.
Hardware-in-the-loop: the real board in a simulated world
In HITL the flight code runs on the actual flight-controller board. The simulator replaces the sensors with simulated data and reads the motor outputs, so the real processor, scheduler and communication links are exercised. PX4 provides a HITL mode for this; custom HIL benches do the same with dedicated I/O.
HITL finds timing overruns, interface mistakes and configuration errors that SIL cannot. It still bypasses the physical sensors, which is where a motion platform comes in. The guide to HIL testing explains how such benches are built.
Attitude test rigs: real sensors, real motion
On a 3-axis rig the complete vehicle, or the flight controller in its real mounting, rotates in roll, pitch and yaw but cannot translate. Its own gyroscopes and accelerometers sense genuine motion, so sensor alignment, vibration, filtering and the attitude estimator are tested together, and axis encoders give an independent reference for the estimate.
A motor-driven platform can repeat the same profile on every run, which turns attitude testing into a regression test. With a vehicle model in the loop, the platform can follow the attitude the model computes from the controller’s outputs: physical HIL. INFINITE-HIL X1 is built for this stage, and the 3-DOF test rig guide covers rig types and selection criteria.
Test cases worth automating
- Steps and frequency sweeps on each axis, to compare the attitude response between firmware versions. The PID tuning guide explains what to look for.
- Disturbance rejection: gusts or disturbance torques injected through the model or the platform.
- Sensor faults: a frozen gyro, a biased accelerometer, lost GNSS or magnetometer interference, and the failsafe that should follow.
- Actuator faults: a weak or failed motor and the controller’s reaction.
- Estimator accuracy: the attitude estimate against the measured reference through long and combined-axis motion.
- Timing and load: loop rates and processor load with logging, telemetry and payload software running.
Turn it into a regression test
- Freeze the scenario. Store profiles, model versions and parameters with the firmware version they test.
- Define pass criteria. Overshoot, settling time, estimate error or failsafe timing, with limits agreed before testing.
- Run on every release. SIL on every commit; HITL and rig tests on every release candidate.
- Compare recordings. Keep commanded values, estimates and measured references on one time base so that runs can be overlaid.
- Close the loop with flight data. When a flight reveals a problem, add a test case that reproduces it on the ground.
What only flight tests can prove
Aerodynamics, translational dynamics, real wind, GNSS behaviour and the full operating environment can only be validated in the air. The earlier stages do not replace flight testing; they let you arrive at it with fewer unknowns, so that test campaigns are shorter, crashes rarer and flights confirm rather than discover.
For certified aviation software, standards such as DO-178C define the verification evidence required, and a staged approach like this one helps to produce it. To discuss a test setup for your flight controller, contact us.