Behind the text, an animated field of sparse cyan and magenta squares stands for individual brightness-change events from an event camera. As they accumulate they resolve into a field of short arrows pointing away from a single focus of expansion — the optic flow of forward motion. The figure is illustrative and is not measured data.
haltere
A perception and guidance layer for autonomous flight that turns event-camera data into motion estimates and guidance commands — multirotor and fixed-wing — running alongside the autopilot rather than in place of it.
A haltere is the club-shaped organ behind a fly's wing. It beats in antiphase with the wing and reports body rotation the way a gyroscope does, and it is a large part of why flies fly the way they do. The name is a statement of where the engineering comes from.
Pre-release and in active development: the specification is complete, implementation is starting, and nothing has flown.
Flight where GPS isn't.
Low-altitude autonomy runs out of road exactly where it gets interesting: indoors, under canopy, in tunnels and urban canyons, close to structures — anywhere the satellite signal is absent, degraded, reflected or denied.
The usual answer is a camera, and the usual camera is the wrong instrument for the job. It samples the world on a fixed clock, so motion arrives late and smeared across an exposure. It reads every pixel whether or not anything changed, so power and computation scale with the sensor rather than with the scene.
Its dynamic range is the sharpest limit. An exposure set for shade is blind coming out of it; one set for open sky is blind under the canopy. The tunnel mouth and the sunlit gap between buildings are precisely the places a vehicle most needs to see, and they are where a frame gives up. Latency compounds the rest: by the time a frame has been processed, the aircraft has already moved.
Photons to guidance, in three stages.
Step 01
Event camera
Each pixel reports independently, and only when the brightness it sees changes: a timestamp, an address, and a polarity — brighter or darker. There is no frame and no exposure, so there is nothing to smear and nothing to wait for.
The properties that follow belong to the sensing modality rather than to any particular implementation: microsecond-scale temporal resolution, output proportional to change in the scene instead of to pixel count, correspondingly sparse computation, low power, and around 140 dB of dynamic range — enough to hold detail in shade and in direct sun in the same view.
Step 02
Elementary motion detectors
Signals from neighbouring points in the field of view are combined with a delay, so that motion in one direction arrives in step and reinforces, while motion in the opposite direction arrives out of step and is suppressed. That is the three-point arrangement — inhibitor, facilitator, trigger — modelled on the fly's motion pathway, and it is implemented here as a spiking detector.
Thousands of these local detectors tile the field of view. Their outputs are an optic-flow field, computed without ever assembling an image, and work happens only where brightness changed.
Step 03
Guidance
A flow field is not yet a decision. Its structure carries the vehicle's own motion: forward translation appears as expansion about a single point, rotation as a uniform sweep across the field, and an approaching surface as a local rate of expansion.
haltere is designed to reduce that structure to quantities an aircraft can act on — motion estimates, and guidance intended to hold a corridor by balancing flow between the two sides, to slow on looming, and to steer away from clutter. Those commands are handed to the autopilot. haltere does not close the attitude loop.
Fifty years of a solved problem.
The fly's motion-vision pathway is among the best-characterised circuits in neuroscience. Around 50 years of published work — behavioural experiments, recordings from motion-sensitive neurons, and computational models of the elementary motion detector — describe how it works. The primitives are published, not speculative.
What that circuit achieves is the interesting part. On the order of105 neurons, drawing milliwatts, in a volume smaller than a grain of rice, hold a course through cluttered natural environments at angular rates that trouble engineered systems.
The computation is local, parallel and asynchronous, and it is not a general vision pipeline followed by a planner. It is a small set of specialised circuits that map sensing onto action almost directly — a correlation over neighbouring inputs, not a learned model. That architecture is what haltere borrows, not the biology for its own sake: doing one thing where the data already is suits an event sensor and a power budget.
These figures describe the fly's visual system, not haltere.
A separate process, on the other side of a boundary.
Event camera
Actuators · airframe
haltere runs alongside PX4, not instead of it. It is a separate process that speaks MAVLink across a process boundary: guidance and setpoints out, vehicle state in. Everything to the right of that boundary stays where it is.
PX4 keeps rate and attitude control, state estimation and failsafes, and it keeps authority over the aircraft. haltere provides the seeing.
Not an autopilot · not an operating systemRust, because the failure modes matter.
The implementation language is a design decision here, not a preference.
Memory safety without a garbage collector means there is no collection pause inside a loop that has to answer on the sensor's timescale. Ownership and types make buffer handling and concurrency checkable before the code runs, rather than in the air.
A no_std-capable core lets the same perception code target a companion computer or bare metal alongside the flight controller, and a C ABI boundary keeps it callable from tooling that already exists.
Determinism is treated as a requirement rather than an optimisation: predictable memory use, predictable timing, and no hidden allocation on the path that has to keep up with the sensor.
- Memory safety
- enforced at compile time
- Runtime
- no garbage collector
- Core
- no_std-capable
- Timing
- deterministic, real-time
Where this actually is.
Specification complete, implementation starting.
- 01
Specification and architecture
CompleteThe perception pipeline, the detector model and the boundary with the autopilot are specified.
- 02
Core implementation in Rust
StartingEvent ingest, the elementary motion detector array, and the flow field.
- 03
Offline validation and simulation
PlannedRecorded event data first, then software-in-the-loop against PX4.
- 04
Bench, tether, then flight
PlannedHardware on a bench and on a tether before anything leaves the ground.
Nothing has flown yet.