Drone simulation and SITL test environments

SITL and HITL catch different problems

In SITL the flight code is compiled for the host computer and a physics simulator stands in for the vehicle and its sensors. It is fast, needs no hardware, and runs in continuous integration. It does not exercise the real flight controller's timing, drivers or sensors.

In hardware-in-the-loop (HITL) testing the firmware runs on the actual flight controller, while the simulator supplies sensor data and receives actuator outputs over a cable. It catches board-level problems that SITL cannot, at the cost of needing the hardware on the bench and running in real time. (TODO: confirm which simulators currently support HITL for your autopilot and firmware version.)

Simulator options

PX4's SITL is most commonly paired with Gazebo, with lighter options for quick checks. ArduPilot ships its own SITL with built-in vehicle physics, launched through its sim_vehicle tooling, and can also connect to Gazebo and other external simulators. When the code under test depends on camera imagery, such as detection or visual navigation, a game-engine environment built in Unity or Unreal can provide more realistic images than a robotics simulator. (TODO: check the current status and maintenance of any third-party simulator before standardising on it.)

What makes a test rig useful

• Scripted scenarios: take off, fly a mission, return, with explicit pass and fail conditions rather than someone watching the screen.
• Failure injection: GNSS loss or degradation, datalink loss, sensor faults, low battery, wind. Both autopilots provide simulation parameters or commands for some of these. (TODO: confirm the exact parameter and command names for your firmware version.)
• Repeatability: fixed random seeds and lockstep simulation so a test gives the same result on a fast workstation and a slow CI runner.
• Headless runs in containers, so the suite runs on every change instead of only before a field trip.
• Checks that read the flight logs, so a test can assert on what the autopilot actually did.

Beyond the autopilot

Some failures only appear when the environment is modelled properly: satellite geometry degrading near terrain, a radio link shadowed by a ridge, navigation drifting once GNSS is lost. My UAS navigation and communications test environment models those effects explicitly; the case study linked alongside describes how.

What I hand over

A rig is only useful if your team can run and extend it. I deliver it as a repository with container definitions, the scenarios, a continuous-integration configuration, and written instructions for adding a scenario. The fixed-scope version of this work is described in the offers on the home page.