Motion perception, before navigation.

Haltere is developing an event-based motion-perception component for PX4 inspection drones. The first scope is an offline evaluation on recorded event data, not a complete GPS-denied navigation system or a production SDK.

Current status: specification complete; core implementation starting. No Haltere performance measurements or flight demonstrations have been published. The architecture below is a design, not an implemented integration.

The first use case

We are investigating motion perception across high-contrast lighting transitions in GPS-denied industrial inspection. The intended evaluation compares the approach against a customer's existing baseline within an agreed operating envelope. It may establish an advantage, or show that an existing solution is the better choice.

Proposed pipeline

• Input: recorded events containing pixel coordinates, a timestamp, and brightness-change polarity, together with sensor and recording metadata.
• Validation: explicit handling of malformed records, discontinuous timestamps, known data loss, and overload.
• Motion core: local spiking motion detectors that correlate neighbouring events over time, drawing on models of insect motion vision.
• Output: motion/flow features, timestamps, coordinate and unit conventions, and explicit quality and validity indicators.
• Evaluation: replayable comparisons, reference-data alignment, resource measurements, operating limits, and a reproducible report.

Quality scores are not automatically calibrated probabilities. Optical flow does not by itself supply metric position, scale, or drift-free navigation. Those distinctions matter before connecting a perception result to an estimator or control system.

Hardware and software boundary

The first live reference configuration is intended to use one event-camera family and one companion computer. The sensor, compute board, operating system, driver rights, availability, and calibration requirements must be selected and confirmed as part of scoping. There is no published supported-hardware list yet.

Haltere is intended to run as a separate Rust process alongside PX4. The appropriate interface depends on what the implementation can validly produce. MAVLink compatibility alone does not establish a correct integration: units, coordinate frames, timing, estimator expectations, and any required IMU or range inputs must agree.

PX4 retains state estimation, rate and attitude control, and aircraft authority. That boundary is not a safety guarantee for bad external estimates or setpoints. Initial live integration is intended to be non-commanding. Guidance is a later scope with separate evidence and safety requirements.

Why event sensing

Event sensors report brightness changes asynchronously. Depending on the sensor and conditions, this can offer fine temporal resolution and a wide dynamic range without producing complete frames at a fixed rate.

Sensor timestamp resolution is not end-to-end perception latency. Low event activity can reduce work, but lighting flicker, noise, and rapid scene changes can generate substantial load. Finite sensor bandwidth, low texture, poor illumination, and calibration also constrain what can be inferred.

The research bet is that computation native to the event stream can be useful within a practical hardware budget. It is not a claim that frame-based vision is universally unsuitable.

Why Rust and insect-inspired detectors

The proposed detector computation is local and stateful rather than a general vision model followed by a planner. Rust is the intended implementation language for memory safety, explicit ownership, and controlled resource use.

A separable, no_std-capable core is an architectural goal. Bare-metal ports and multiple platform bindings are not prerequisites for the first evaluation. Real-time timing and power consumption must be measured on the selected implementation, not inferred from the language or the biology.

The name comes from the fly's haltere, a small organ involved in sensing body rotation. It is an engineering inspiration, not a claim that the product replicates the capabilities of a fly.

What an evaluation should establish

We agree the baseline and numeric acceptance thresholds before evaluating final results. Relevant measures include motion-estimation error, invalid-output and failure rates, processing latency, CPU and memory use, and total sensor-plus-host power and cost.

Comparisons should use customer-relevant cases, disclosed hardware budgets, and reference measurements where required. Held-out cases and negative results belong in the report. Offline replay measurements will be labelled as such; they do not establish live flight-loop performance.

An evaluation produces an engineering decision, not permission for autonomous deployment. Any progression through bench, simulation, tethered testing, and flight depends on appropriate safety work, facilities, operators, and permissions.

Selected references

• Gallego et al., Event-based Vision: A Survey: sensing principles, practical limitations, optical flow, and pose estimation as distinct problems.
• Prophesee evaluation hardware: examples of available event-sensor development ecosystems.
• iniVation DVXplorer documentation: sensor characteristics, software interfaces, and stated operating context.
• PX4 optical-flow documentation: an example of the interface and sensor requirements that must be resolved for an actual integration.

These references describe third-party research and products, not Haltere results. No endorsement, partnership, or production compatibility is implied.