ACTUAL FLIGHT FIRMWARE · WSL2 · RECORDED EVIDENCE

From mission intent
to a verified landing.

PX4 flies an x500 in Gazebo. ROS 2 carries payload perception and offboard control. A C++ supervisor handles stale data; the flight controller survives a companion-process crash. The same stack also flies three drones from a moving carrier.

Gazebo physics + flight sensorsPX4 EKF2ROS 2 / XRCE-DDSONNX CPU + A*C++ mission supervisorPX4 control + failsafe
SINGLE-DRONE FLIGHTS PASSED—Every named check; the fleet and guardian flights have their own pages
MAX ESTIMATED ALTITUDE—Target: 3 m
ESTIMATED MIN CLEARANCE—Position estimate vs. known cylinders
RECORDED ROS IMAGES—Procedural payload at 10 Hz

Flight telemetry replay

—
0.0 s

Green: PX4 estimated trajectory · grey dashed: estimate PX4 flagged invalid · blue dashed: planned route, updated on replan · copper: known cylinders. This is a recorded replay, not a live console.

Independent observations

Flight and mission transitions

Real implementations: PX4 flight firmware and EKF2, Gazebo physics/flight sensors, ROS 2, DDS, local MAVLink heartbeat, C++ process IPC and ONNX Runtime. Procedural payload: camera and planar LiDAR. The ONNX graph segments a bright synthetic shape; it is not a trained drone classifier. Qualcomm hardware, NPU and hardware secure boot are not emulated. The simulator video comes from a Gazebo camera during the same recorded run; the 3D view redraws the recorded PX4 estimates.
Detailed reproduction guide →Measured results and versions →Architecture and failure policy →Eight fast fault-policy scenarios →