Jump to content

Edge compute, for mission perception

From Apollyon Wiki
Compute · mission and perception applications on a second compute domain · core subsystem

The flight-critical loop runs on the autopilot. Everything the aircraft needs to understand the world — terrain matching, target tracking, route generation — runs on a second computer alongside it. This subsystem is that computer and the software on it. It feeds the autopilot; it never replaces it.

Scope: mission and perception, not the flight-critical loop

The flight-critical guidance, navigation and control loop runs on the proprietary Veronte Autopilot 1x at its own fixed rate. This subsystem is the second compute domain: the mission and perception workloads that feed the core — scene matching, target tracking, route generation — and never replace it.

01 · Physical framing

Latency expressed as distance

At 100 to 270 metres per second, every millisecond a computer spends thinking moves the aircraft forward. A late answer is an old answer, and an old answer points at where the target used to be.

4.05 m
Distance covered during a 15 ms delay at Mach 0.8
4.5–13.5 m
Distance between perception updates at 60 to 20 Hz
20–60 Hz
Perception update rates across the fleet

The autopilot does not stop flying while perception works. It holds the aircraft on its own estimate and takes each fix, track or waypoint when it arrives. That is why this path is engineered for a worst case and not an average: a late update costs accuracy, and only accuracy.

Fig. 01 · Perception Update Ratesdistance, not milliseconds
DISTANCE TRAVELLED BETWEEN PERCEPTION UPDATESAT MACH 0.8 · 270 M/S0 m5 m10 m13.5 m20 HZ · TERRAIN MATCHING13.5 m30 HZ · EO/IR DETECTION9.0 m60 HZ · TERMINAL TRACKING4.5 mThe flight-critical loop runs on its own schedule and never waits for these updates.Perception feeds it; in between, the core keeps flying on its own estimate.
Fig. 01 Distance covered between perception updates at three rates, at Mach 0.8. The flight-critical loop runs on its own schedule and never waits for these updates; in between, it flies on its own estimate.
02 · Two compute domains

Flight-critical and payload compute

The split is deliberate. The autopilot baseline owns everything that keeps the aircraft in the air; the mission computer owns everything that tells it where to go and what is there.

What runs where
DomainOwnerWhat it carries
Flight-critical coreEmbention VeronteState estimation, guidance modes, control execution, actuation and a deterministic schedule.
Mission & perceptionApollyonTerrain and scene matching, target detection and tracking, route generation.
InterfaceNarrow by designNavigation fixes, track coordinates and waypoints. The core never waits on this path.

Keeping perception off the flight-critical core buys two things. A fault in perception cannot destabilise the aircraft, and a change to a perception model does not touch the flight-control loop.

03 · What the domain carries

Know where you are, know what you see, know where to go

The mission computer carries three families of workload.

Job 01

Terrain and scene matching

A camera frame is correlated against stored reference imagery to give an absolute position fix. No RF emission and no satellite signal. Midcourse and terminal fixes for Hemlock and the Piranha USV use this path.

DSMAC correlationRF silent
Job 02

Target detection and tracking

Optical and thermal frames are searched for targets. Detection, classification and track coordinates are handed to the autopilot's tracking mode, which flies the terminal phase.

EO/IRTrack handoff
Job 03

Route generation

Terrain-following routes and waypoints are computed from open terrain data before launch and updated in flight. The route reaches the autopilot as a mission plan, not as control commands.

Open terrain dataWaypoints
Thermal and power limits at the edge

The mission computer sits inside a sealed composite airframe with no liquid cooling. Power draw and heat are first-order constraints on what can run, so every workload is sized to the airframe's thermal budget before it is sized to its accuracy target.

04 · Engineering discipline

Design against the worst case, not the average

A pipeline that averages 2 milliseconds but spikes to 18 milliseconds once every five hundred cycles cannot be trusted to feed a terminal dive. Averages hide the cases that matter.

Every workload that feeds the core carries a timing budget measured against its worst case. Flight telemetry logs the latencies at microsecond resolution, and the budgets are re-derived from measured flights, not from bench averages. When a budget is exceeded, the autopilot simply continues on its own estimate.

05 · Fleet workloads

What runs on the mission computer

Onboard mission & perception workloads across the fleet
PlatformWorkload pipelinePerception rateCompute constraint
Ahuti Interceptor Adaptive world model, terminal optical target tracking, effector-guidance support. 60 Hz vision · high-rate tracking High-rate terminal tracking for fast interception.
Nightshade ADX-1 Multi-spectral EO/IR object detection, visual scene tracking, autonomous terminal dive homing. 30 Hz vision Conduction-cooled embedded compute module rated for sealed composite airframes.
Hemlock DSMAC terrain scene matching, optical horizon reference, terminal LWIR silhouette correlation. 20 Hz correlation Shock-resistant embedded compute module with terrain correlation for high-subsonic flight.
Piranha USV Shoreline DSMAC correlation, optical waterline tracking, hydrodynamic trim support, peer mesh. 30 Hz waterline tracking Salt-mist sealed enclosure, high shock-load dampening.
06 · Used by

Platforms carrying this subsystem

Supports: Robust flight control, GNSS-denied navigation.