From sensor drivers to the partner SDK. Eight layers define the OS, with time, security and logging across every layer. TrackFusion, RECONN.EARTH and OspreyVMS are the product modules. The collective layer is planned.
L1 sensor fusion and L3 collective coordination are the core areas of development. The diagram shows the full architecture, including the planned collective layer.
Select a layer to inspect its responsibilities, or choose a flow to follow its path.
APIs and an integration kit for payload installation and communication with the stack. Together with L0, this defines the integration work required for each partner.
Fleet registry, health and telemetry, firmware and over-the-air updates, key management, audit and evidence, and the operator UI. The operator hosts the control plane on their own infrastructure.
Live video, recording, stitching, detection and tracking, mapping, and mission-specific applications. This layer consumes the video and mission data that comes back up from the vehicles.
View OspreyVMS →Imagery retrieval, SAR-to-optical and optical-to-thermal conversion, tiling and caching, and the mission data store. Runs centrally and pushes reference imagery down to the L2 onboard cache before flight.
View RECONN.EARTH →Planned responsibilities: neighbour discovery, ranging, shared position, a registry of vehicle capabilities, and task allocation across the group.
Next development stage: implement and integrate L3.
View collective layer →Waypoint execution, the onboard reference-image cache, drift monitoring and fallback policy. Match confidence and reference age inform degraded-mode behaviour. The host autopilot retains flight control.
L1 / L2 boundary decision ↓Time synchronisation across sensors, the fusion pipeline, the match engine against reference imagery, and fix validation. Deterministic latency at frame rate is the reason this runs in hardware.
The kernel supplies validated fixes within a deterministic frame cycle.
View TrackFusion →Drivers and interfaces for radar, thermal, IMU and camera, with sonar as a later extension. Autopilot interfaces cover PX4, ArduPilot and MAVLink, alongside gimbals and radio links.
OEM integration at this layer connects each vehicle’s sensors, actuators and communications hardware.
Central reference services prepare, tile and cache imagery, then push it to the vehicle.
Sensor inputs become validated fixes. Navigation services manage execution and fallback behaviour.
Mission data feeds the applications; health, telemetry and audit records feed the control plane.
The kernel owns deterministic fusion, matching and fix validation. Navigation services own fallback policy. The precise boundary determines what is fixed in the FPGA implementation and what can be updated in field software.
To resolve: which responsibilities and interfaces are fixed at the kernel boundary?
Hardware drivers and the partner SDK determine the integration scope for each OEM. Reusable interfaces and vehicle-specific adapters set the work required.
To resolve: what is reusable across partners, and what remains specific to each vehicle?
Plan the route, prepare reference imagery, match live sensor data and validate the position. Reference preparation runs centrally before flight; matching runs on the aircraft.
The operator sets a route. Shoal-OS breaks it into waypoints — Nav Drone handles mission planning.
RECONN.EARTH prepares and tiles reference imagery for each waypoint, using the required sensor modality.
TrackFusion compares live radar and thermal data against that imagery, fused with inertial sensing.
A validated position goes to the autopilot — which keeps flight control throughout.
See how sensor fusion, reference matching and fix validation connect to navigation services.