The shared core, in hardware, software and method

Where the limit comes from

Commercial supply chains provide many standard drone parts, but true system performance comes down to how well subsystems work together. The limits of high-speed uncrewed aircraft—terminal speed, maneuver load, and electronic warfare resilience—are shaped by battery thermals, bus communication latency, and how accurately simulation models reflect real flight.

Buying an airframe and an autopilot off the shelf sets strict limits, especially since standard flight simulators rarely show how motion on one axis feeds into the others at the high dynamic pressures a fast aircraft works in. Apollyon focuses its engineering on the authored layer: the control laws and guidance packages tailored to each airframe's operating regime, on top of a proven flight-control baseline. It also owns the onboard mission and perception compute, works on battery discharge behaviour, and designs mission-matched composite structures. Passive components and standard raw materials are sourced across diversified supply lines, as detailed in the supply chain review.

Owning this authored software and configuration layer makes iteration straightforward. Because our engineering team owns the flight package and the baseline is fully configurable, telemetry from each flight directly feeds back into our aerodynamic models and the next software update.

Core vehicle architecture, functional view

Navigation, flight control, propulsion and actuation operate over a unified electrical and data bus. This functional architecture standardises avionics across the Nightshade effector family; Hemlock applies the same functional layout at a larger scale with its own guidance and navigation implementation.

Reading the diagram

Core vehicle architecture, software view

One proprietary autopilot baseline operates across the Nightshade family. Vehicle variations execute as versioned configuration packages rather than separate code branches, so a validated change propagates across the line without touching the flight-critical core. Hemlock takes the method and the qualification evidence onto its own implementation.

Three clear design choices shape this software stack:

First, the state estimator is the only component that handles raw sensor inputs. Guidance algorithms and flight controllers work from a single fused state estimate rather than dealing with separate, asynchronous sensor streams.

Second, the flight controller pairs that fused estimate with scheduled control laws. Gains, envelope boundaries, and actuator allocations are derived from real flight data rather than theoretical approximations, maintaining responsive handling across the flight envelope (§05).

Third, mission management is decoupled from low-level flight dynamics. Waypoints, terrain-following rules, optical tracking, and geofence abort triggers run as configurable mission profiles on a common runtime. This lets the same mission software run a target drone or the Mk II loitering munition, and carry over to later airframes.

The machine, its twin, and the loop

Flight testing provides the raw data, but the speed of development depends on the engineering workflow behind it: calibrating simulation models against instrumented flight logs, tuning control laws in software, and validating changes on hardware-in-the-loop benches before flying again.

The digital twin and system identification

Control tuning depends heavily on how closely a simulator reflects real physics. Standard flight simulators often rely on linear aerodynamic approximations that fall apart at high speeds and steep angles of attack. Apollyon maintains a parameterised simulation model for each airframe rather than maintaining disconnected simulation setups. After every test flight, telemetry is used to refine lift and drag polars, control-surface hinge moments, moments of inertia, and motor thermal limits.

Flight logging also helps identify external conditions and hardware wear—such as mountain wind shear, actuator heating, or battery voltage sag under heavy load. Incorporating these observations into the state estimator helps the flight controller respond reliably even in turbulent conditions outside ideal test corridors.

The iteration loop

Each test flight records telemetry across structural, electrical, and control channels. After recovery, our data pipeline processes this flight data to update aerodynamic model coefficients, verify timing on the real-time kernel, refine control gains near envelope boundaries, and review structural tolerances for subsequent builds.

This continuous process expands flight envelopes systematically. Because the data ingestion tools, hardware-in-the-loop test benches, and physical models are shared engineering assets, new airframes can be developed and validated faster and with fewer flight prototypes.

The subsystem register

The method above runs through seven subsystems. Each has its own page, and that page is the authority for it: product pages state their configuration of a subsystem and link to it rather than restating it.

What is shared, and what is not

The architecture claim is deliberately scoped. The three Nightshade configurations share the full core; Hemlock, the interceptor and the surface vessel are tailored architectures that inherit the estimation methods, guidance laws and hardware validation rather than the identical flight core.