build 2026.06
stack · 8 components
published 2026-06-18

Pilotrs

A sensing → estimation → control stack in Rust. The autopilot only ever sees noisy sensor readings, never the true state.

source

01Sim core: 6DOF rigid body · RK4 @ 1 kHz
02Estimators: Complementary · 6-state MEKF · 15-state INS
03Control: Cascaded PID / LQR · waypoints · FBW
04Core: no_std · MSRV 1.91 (bare-metal compatible)

why it matters

Controllers and estimators only ever get the estimate, never the truth. The split is kept explicit in the code.
It's physically unstable and pitches out of control in under a second open-loop, but stays locked in with state feedback.
The no_std flight-control core has zero dependencies, making it easy to compile for embedded targets later without a rewrite.

visuals

Pilotrs viewer with the fly-by-wire fighter over the globe, route planner, and live telemetry plots — The viewer, flying the unstable fighter over the globe. Route planner top-right, live estimate-vs-truth plots bottom-right. Turn the flight computer off and it goes unstable in under a second.

Pilotrs architecture, simulation truth and sensors above a perception line, estimators and control below, closing the loop — The sensing → estimation → control loop. Nothing below the perception line reads the real state; it all goes through the estimate.

engineering notes

Pilotrs is a 6DOF flight sim and autopilot I wrote in Rust. It runs the rigid-body physics of a quadrotor and a fixed-wing plane, with a sensing → estimation → control loop on top, over a 1/1000-scale Earth.

Sensors only

The sim knows the aircraft’s true state. The autopilot doesn’t, and it’s not allowed to. Every controller and estimator only gets the estimate, which is built from noisy, biased sensor readings. I did the same thing on a school submarine project before this, fusing IMU data with a Kalman filter to get a usable heading.

What’s in it

One physics core runs both aircraft. Full 6DOF equations with the real, non-diagonal inertia tensor, shared between the quadrotor and a Beard & McLain fixed-wing model (lift, drag, moments, stall, control surfaces, propeller, a Newton trim solver). It integrates with RK4 at 1 kHz and renormalizes the quaternion every step.
Three estimators you can swap between: a complementary filter, a 6-state MEKF, and a 15-state INS. The INS treats the accelerometer as a strapdown input, so a long translating maneuver doesn’t wreck the attitude estimate the way a basic AHRS would.
PID and LQR controllers behind one trait, with waypoint missions and a fixed-wing autopilot on top. You can switch the controller or estimator while it’s running.
The core is no_std, sits at MSRV 1.91, and has zero dependencies, so it can easily compile for embedded microcontrollers later.

The fly-by-wire fighter

There’s also a relaxed-stability fighter. It has a negative static margin, so it’s unstable on its own and pitches away from level in about 0.34 s (an F-16 is around 0.3). A fly-by-wire system with angle-of-attack and rate feedback, command shaping, and gain scheduling keeps it flying. One key turns the flight computer off, and it goes unstable.

Without active stabilization from the flight computer, the aircraft pitches up and stalls almost instantly.

The world

The planet is a 1/1000-scale Earth, 6371 m radius. The fixed-wing flies in a planet-centered inertial frame with radial inverse-square gravity and great-circle navigation; the quadrotor uses a flat local frame near home, where the curvature doesn’t matter. The physics is frame-agnostic, so only gravity and the nav math change between them.

Tooling

The sim runs on its own thread, separate from rendering, and it’s deterministic. Telemetry is bit-exact record/replay, and there’s a parallel Monte-Carlo harness that runs faster than real time. The viewer lets you switch aircraft and estimators live, plan routes on a zoomable map, and plot estimate vs. truth vs. setpoint.