Orion: GPS-denied UAV navigation

Orion is Team Viklyk’s four-node prototype for UAV navigation when local GNSS is unavailable or jammed. A node estimates its position from radio ranges to three peers that still have GNSS, while its local altitude constrains the solve.

The team built Orion for the technical challenge at UAV Engineering Bootcamp 2026 at Kyiv Aviation Institute. The on-site program ran from June 29 through July 7, 2026 and covered navigation, communications, avionics, and system testing through engineering tasks.

Hardware assembly work on the ESP32 nodes.

Key project results

GPS-denied positioning worked in the field

On July 6, the team ran four nodes for about 8.4 minutes across a test area of roughly 300 by 130 metres in the Kyiv region. Navigation use of GPS was disabled on node 0. Nodes 1, 2, and 3 supplied GNSS positions and SX1280 time-of-flight ranges. Node 0 retained its own GNSS reading only as a reference for measuring the radio-position error.

The position-error figures compare the radio result with the GPS reference, rather than with the solver’s internal residual. The firmware reported the result as RADIO_3D, but this field build solved horizontal position with a fixed altitude constraint.

The supplied results graphic plots relative metre offsets only; it contains no geographic coordinates.

Three field iterations turned an unreliable link into a usable solve

Each field session produced an NDJSON capture. The next changes addressed the failure visible in that capture: missing diagnostics after July 4, solver and ranging faults after July 5, then radio contention between telemetry and ranging.

The main correction was a fixed TDMA radio schedule. Ad-hoc telemetry and ranging had competed for the same SX1280 radio. Node 0 became the timing authority, and the four nodes received separate telemetry and pairwise ranging slots. The July 6 capture contains 3,217 TDMA events. Ranging failures fell from 104 in the first session to 8 in the final session.

The design could be tested off the aircraft

The portable C11 core owns peer state, anchor selection, solution acceptance, and structured diagnostics. Thin adapters supply GNSS and radio events from NodeMCU-32S, ESP32-S3-DEVKITC-1, and SpeedyBee Nano 2.4G hardware. The same core also runs on a desktop for deterministic replay.

The team chose SX1280 hardware time-of-flight ranging instead of the task’s proposed SX1262 RSSI estimate. RSSI remained a link diagnostic; it was not treated as a distance measurement. This decision made metre-scale ranging possible without a new site calibration for every test.

At the analyzed revision, the repository has 291 tracked files and 12,952 lines of C/header and front-end source. A clean host build produced the core library, replay CLI, NMEA tool, POSIX demo, and 11 C test executables. All 11 executables passed. The deterministic reference replay reached RADIO_NAV_OK and recovered its known position with zero error.

Field evidence was visible and reusable

The control channel emits typed NDJSON records for snapshots, range results, node-quality reports, and logs. The browser interface reads live Web Serial data, records a session, and reopens saved captures for comparison. It displays peer state, ranges, GNSS status, solve outcome, residual, and geometry score in one view.

The final four-node bill of materials was about UAH 9,270. The software supports ESP-IDF and Arduino-based boards, so the team could combine the available ESP32 and SX1280 hardware rather than wait for one board type.

What remains unproven

The reported accuracy excludes four short outlier bursts, about 18 seconds in total, that reached roughly 120 m of error. Two had high residuals and could be rejected by a residual threshold. Two appeared internally consistent, so they need a measured uncertainty model instead of the current fixed one-metre sigma. About 3% of ranging attempts still timed out.

The field run validated links only up to 257 m. A 2.4 GHz radio also loses more range through obstacles than a sub-GHz link. Long UAV separation, a true height solve, and the planned scenario with three moving nodes and one stationary node still need field tests.

My participation

I contributed from June 29 through July 6, 2026. The local history at 4a31e3d matched the public GitHub main branch when I analyzed it.

The product-code count covers firmware, core code, ports, tools, tests, examples, and telemetry applications. It excludes documentation and agent configuration. Git churn includes code that a later commit revised.

My merged pull requests were #1, #3, #5, #7, and #9.

Work I delivered

• Set up the team process, sponsorship, and component purchases for the four-node prototype.
• Added ESP32 hardware-health firmware and moved the main build to ESP-IDF. The health and recovery path ran through the final field session without a watchdog reset.
• Added SpeedyBee Nano SX1280 support, time-of-flight ranging participation, timeout recovery, and a band scanner.
• Implemented typed control records, over-the-air debug telemetry, NDJSON capture recording, parser fixtures, and node-quality views.
• Built the React telemetry path for Web Serial data, saved-capture analysis, network state, ranges, and node health.
• Added GNSS/NMEA bring-up, status LED behaviour, hardware plans, acceptance notes, and architecture records.