gps-denied-onboard/_docs/00_research/01_source_registry.md

Source Registry

Mode A Phase 2 — engine Step 2 (Source Tiering & Exhaustive Web Investigation). Critical-novelty sensitivity per Step 0.5 in 00_question_decomposition.md. Time windows applied:

• Lead-candidate / SOTA claims: prefer sources within last 6 months; up to 18 months if older is the official authority.
• Library/SDK API behaviour: must reflect the currently shipped version at search time (context7 mandatory per lead candidate).
• Established baselines (KLT, RANSAC, EKF, ORB, SIFT, GTSAM): no time window.

Investigation order saved in 00_question_decomposition.md → "Next Step": SQ6 → SQ1 → SQ2 → SQ3+SQ4 per component (C1→C10) → SQ5 interleaved → SQ7 → SQ8 → SQ9 synthesis at engine Step 8.

Investigation Status

Sub-question	Status	Notes
SQ6 — ArduPilot vs iNav external positioning	Saturated for protocol-level architectural decision (further detail deferred to SQ8 for spoofing-side fields and to design phase for SITL parameter tuning)	Major finding: iNav has no inbound external-positioning MAVLink handler; AC-4.3 wording must be revised. See 02_fact_cards.md "SQ6 Conclusions".
SQ1 — Existing GPS-denied UAV systems	Saturated. 13 sources logged across academic / open-source / commercial / defense-program / Ukraine-practitioner. Closest peer system: Twist Robotics OSCAR (deployed in Ukraine). Closest open-source pipeline-match: snktshrma/ngps_flight (NGPS, ArduPilot GSoC 2024 — LightGlue+SuperPoint+UKF+VISION_POSITION_ESTIMATE). Closest deployed commercial: Auterion Artemis (Skynode N + Visual Navigation, Ukraine-tested, 1000-mile range).	See 02_fact_cards.md SQ1 cluster + working summary.
SQ2 — Canonical pipeline decomposition	Saturated. 5 surveys/benchmarks logged (Skoltech aerial VPR, U.Maine cross-view, OrthoLoC 2.5D geodata, AnyVisLoc low-altitude multi-view, NUDT 2026 sciopen survey). All converge on retrieval → matching → pose-estimation hierarchical framework with VIO/IMU as auxiliary. Two new architectural facts added to C1–C10: (a) AdHoP-style perspective-refinement loop between matching and PnP (+63% translation accuracy, method-agnostic), (b) DSM 2.5D dependency for full 6-DoF on aerial-to-satellite (must be resolved with the Suite Sat Service or accepted as a 3-DoF degraded mode). Practitioner runtime evidence: AnyLoc on RTX 3090 = 0.63s/descriptor, SuperGlue re-rank = 17–25s; on Jetson Orin Nano these are non-viable for our 400 ms p95 budget — must restrict to lightweight VPR (e.g., MixVPR / SALAD class) + LightGlue/XFeat-class matchers. See 02_fact_cards.md "SQ2 Conclusions".
SQ3+SQ4 — Per-component candidates (C1–C10)	Not started
SQ5 — Failure modes / deployment lessons	Not started (interleaved with SQ3/SQ4)
SQ7 — Datasets, SITL, replay environments	Not started
SQ8 — Safety considerations (AC-NEW-4 / AC-NEW-7)	Not started	Carries the AP_GPS spoofing-signal probe deferred from SQ6.
SQ9 — End-to-end synthesis	Step 8 of engine (deferred)

---

Sources

Source #1

• Title: Non-GPS Navigation — Plane documentation
• Link: https://ardupilot.org/plane/docs/common-non-gps-navigation-landing-page.html
• Tier: L1
• Publication Date: live docs (current ArduPilot stable, accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: ArduPilot 4.7+ (persistent origin storage); applies to current Plane stable
• Target Audience: ArduPilot Plane operators / developers
• Research Boundary Match: Full match (fixed-wing, ArduPilot Plane is in scope)
• Summary: Lists supported non-GPS navigation systems for Plane. Notes that boards <1MB flash still support GPS_INPUT even when they cannot run other non-GPS messages. Notes that Plane (non-VTOL) is generally not applicable for low-altitude non-GPS — but GPS_INPUT as an external GPS replacement is not constrained by that note.
• Related Sub-question: SQ6

Source #2

• Title: GPS / Non-GPS Transitions — Plane documentation
• Link: https://ardupilot.org/plane/docs/common-non-gps-to-gps.html
• Tier: L1
• Publication Date: live docs (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: EKF3 (default since AP 4.0+)
• Target Audience: ArduPilot operators using mixed GPS / non-GPS sources
• Research Boundary Match: Full match
• Summary: Documents the EKF3 source-set mechanism (EK3_SRC1..3_POSXY/VELXY/POSZ/VELZ/YAW), three source sets, RC aux switch (option 90 "EKF Pos Source"), MAV_CMD_SET_EKF_SOURCE_SET, Lua-script driven switching. Explicitly named messages for non-GPS path: ExternalNav (option 6). GPS_INPUT is treated as a GPS source (set 1).
• Related Sub-question: SQ6

Source #3

• Title: EKF Source Selection and Switching — Plane documentation
• Link: https://ardupilot.org/plane/docs/common-ekf-sources.html
• Tier: L1
• Publication Date: live docs (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: EKF3 stable
• Target Audience: ArduPilot operators / developers
• Research Boundary Match: Full match
• Summary: Authoritative parameter reference for EK3_SRCx_* (POSXY/VELXY/POSZ/VELZ/YAW). Important caveat: "Ground stations or companion computers may set the source by sending a MAV_CMD_SET_EKF_SOURCE_SET mavlink command but no GCSs are currently known to implement this." Source-set switching from companion is supported by AP, not by stock GCS UI. Mentions ExternalNAV/OpticalFlow transition options via EK3_SRC_OPTIONS bit 1.
• Related Sub-question: SQ6

Source #4

• Title: ArduPilot AP_GPS_MAV.cpp (master)
• Link: https://raw.githubusercontent.com/ArduPilot/ardupilot/master/libraries/AP_GPS/AP_GPS_MAV.cpp
• Tier: L1 (source code)
• Publication Date: master HEAD (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: master branch
• Target Audience: ArduPilot developers, integrators of external GPS via MAVLink
• Research Boundary Match: Full match
• Summary: Authoritative implementation of MAVLINK_MSG_ID_GPS_INPUT ingestion into AP_GPS state. Decodes lat/lon/alt, hdop/vdop, velocity (vn/ve/vd), speed/horizontal/vertical accuracy, yaw. Honors gps_id (multi-GPS instance), ignore_flags bitmask (ALT, HDOP, VDOP, VEL_HORIZ, VEL_VERT, SPEED_ACCURACY, HORIZONTAL_ACCURACY, VERTICAL_ACCURACY). Requires fix_type ≥ 3 and time_week > 0 for jitter-corrected timestamping. Yaw uses 0 as "not provided" sentinel. Only GPS_INPUT is handled by this driver — VISION_POSITION_ESTIMATE / ODOMETRY go via the external-nav driver, not AP_GPS_MAV.
• Related Sub-question: SQ6

Source #5

• Title: ArduPilot PR #28750 — AP_NavEKF3: added two more EK3_OPTION bits (GPS-denied testing)
• Link: https://github.com/ArduPilot/ardupilot/pull/28750
• Tier: L2 (development PR, ArduPilot core team)
• Publication Date: 2024 (accessed via search 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: master / pending stable branch propagation
• Target Audience: ArduPilot developers
• Research Boundary Match: Full match
• Summary: Adds new EK3_OPTION bits to allow easier GPS-denied testing of EKF3, including an aux-switch / MAVLink command path to disable GPS use. Confirms ongoing 2024-2025 work on GPS-denied robustness.
• Related Sub-question: SQ6

Source #6

• Title: ArduPilot Issue #15859 — EKF3: improve source switching (GPS<->NonGPS)
• Link: https://github.com/ArduPilot/ardupilot/issues/15859
• Tier: L4 (issue tracker — open enhancement list)
• Publication Date: ongoing (long-running issue, accessed 2026-05-07)
• Timeliness Status: Currently valid (still open per dev docs reference)
• Target Audience: ArduPilot developers
• Research Boundary Match: Full match
• Summary: Authoritative list of planned improvements for source-switching. Linked from the L1 GPS-Non-GPS Transitions page. Indicates current source switching has known rough edges acknowledged by the core team.
• Related Sub-question: SQ6

Source #7

• Title: ArduPilot Issue #27193 — EK3 Source Switching wrong frame for GUIDED commands SOLVED
• Link: https://github.com/ArduPilot/ardupilot/issues/27193
• Tier: L4 (issue tracker, resolved)
• Publication Date: 2024 (accessed 2026-05-07)
• Timeliness Status: Reference only (resolved as user-config)
• Target Audience: ArduPilot operators using GPS↔Vision source switching
• Research Boundary Match: Partial overlap (Copter context but the bug was in shared SET_POSITION_TARGET_GLOBAL_INT path)
• Summary: Documented frame-interpretation issue when companion switches source set 1 (GPS) → set 3 (VISION_POSITION_ESTIMATES) and back. Resolved as configuration not code, but illustrates the kind of edge case to validate in SITL for AC-NEW-2 promotion.
• Related Sub-question: SQ6

Source #8

• Title: ArduPilot Issue #23485 — AP_NavEKF3: support fusing only External Nav Velocities (without position)
• Link: https://github.com/ArduPilot/ardupilot/issues/23485
• Tier: L4 (open enhancement)
• Publication Date: ongoing (open as of accessed 2026-05-07)
• Timeliness Status: Currently valid
• Target Audience: ArduPilot developers
• Research Boundary Match: Full match
• Summary: Confirms current limitation: ODOMETRY without position causes position-estimate timeout / failsafe. Implies the project's visual_propagated path (VO without satellite anchor) cannot be expressed as ODOMETRY-velocity-only on current AP — must be sent as full GPS_INPUT with widened covariance.
• Related Sub-question: SQ6

Source #9

• Title: iNavFlight/inav — telemetry/mavlink.c (master, processMAVLinkIncomingTelemetry)
• Link: https://github.com/iNavFlight/inav/blob/master/src/main/telemetry/mavlink.c
• Tier: L1 (source code, authoritative)
• Publication Date: master HEAD (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: iNav master (post-9.0)
• Target Audience: iNav developers
• Research Boundary Match: Full match
• Summary: Authoritative inbound MAVLink switch (lines ~1334–1390). Handles only: HEARTBEAT, PARAM_REQUEST_LIST (stub), MISSION_CLEAR_ALL, MISSION_COUNT, MISSION_ITEM, MISSION_REQUEST_LIST, MISSION_REQUEST, COMMAND_INT (only MAV_CMD_DO_REPOSITION), RC_CHANNELS_OVERRIDE, ADSB_VEHICLE, RADIO_STATUS. No GPS_INPUT, no VISION_POSITION_ESTIMATE, no ODOMETRY, no GLOBAL_POSITION_INT, no GPS_RAW_INT are accepted as inputs. Wiki page (Source #10) confirms.
• Related Sub-question: SQ6

Source #10

• Title: iNav Wiki — MAVLink (frogmane edited 2025-12-11)
• Link: https://github.com/iNavFlight/inav/wiki/Mavlink
• Tier: L1 (project wiki)
• Publication Date: 2025-12-11
• Timeliness Status: Currently valid
• Version Info: iNav 8.0 / 9.0 era
• Target Audience: iNav users / integrators
• Research Boundary Match: Full match
• Summary: Authoritative inbound/outbound MAVLink message lists. "Limited command support: Commands that are not implemented are ignored." Explicitly enumerates the supported incoming list (matches Source #9). Confirms iNav MAVLink is "intended primarily for simple telemetry and operation" and "not 100% compatible".
• Related Sub-question: SQ6

Source #11

• Title: iNav Wiki — GPS and Compass setup
• Link: https://github.com/iNavFlight/inav/wiki/GPS-and-Compass-setup
• Tier: L1
• Publication Date: live wiki (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: iNav 7.0+ (UBX-only); 9.0 requires UBX protocol ≥15.00
• Target Audience: iNav operators
• Research Boundary Match: Full match
• Summary: From iNav 7.0 NMEA was removed; only UBX is supported. Recommends u-blox M8/M9/M10 with protocol ≥15.00. Sets up the constraint for any UBX-emulation path the companion would take.
• Related Sub-question: SQ6

Source #12

• Title: iNavFlight/inav docs/development/msp/README.md (MSP message reference)
• Link: https://github.com/iNavFlight/inav/blob/master/docs/development/msp/README.md
• Tier: L1 (project docs)
• Publication Date: live (master, accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: iNav master
• Target Audience: iNav developers / integrators
• Research Boundary Match: Full match
• Summary: Authoritative spec for MSP_SET_RAW_GPS (201) and MSP2_SENSOR_GPS (7939). MSP_SET_RAW_GPS is 14-byte, lossy (no covariance, no per-axis velocity, altitude in meters with cm internal mismatch — bug fixed in 5.0.0 per issue #8336). MSP2_SENSOR_GPS is the newer plugin-style message with hPosAccuracy/vPosAccuracy/hVelAccuracy (mm and cm/s), hdop, NED velocity components, trueYaw, GPS week + time-of-week, fix type, satellite count. Requires USE_GPS_PROTO_MSP build flag and routes through mspGPSReceiveNewData() (the GPS_PROVIDER_MSP driver path).
• Related Sub-question: SQ6

Source #13

• Title: iNavFlight/inav src/main/io/gps.c + src/main/target/common.h (master)
• Link: https://github.com/iNavFlight/inav/blob/master/src/main/target/common.h
• Tier: L1 (source code)
• Publication Date: master (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: master
• Target Audience: iNav developers
• Research Boundary Match: Full match
• Summary: USE_GPS_PROTO_MSP is enabled by default in the common target configuration; on default builds the MSP GPS provider (GPS_PROVIDER_MSP) is registered with gpsRestartMSP / gpsHandleMSP. Confirms the MSP2_SENSOR_GPS path is reachable on stock iNav firmware without custom builds.
• Related Sub-question: SQ6

Source #14

• Title: iNav Issue #10141 — dual GPS support
• Link: https://github.com/iNavFlight/inav/issues/10141
• Tier: L4 (open feature request)
• Publication Date: ongoing (open as of accessed 2026-05-07)
• Timeliness Status: Currently valid
• Target Audience: iNav users
• Research Boundary Match: Full match
• Summary: Confirms iNav does not support dual-GPS / primary-secondary failover. Open enhancement; no implementation in 8.0 / 9.0. Architectural implication: companion must be the sole GPS source for iNav (not a backup to a real GPS connected directly to FC).
• Related Sub-question: SQ6

Source #15

• Title: iNav docs/GPS_fix_estimation.md (master)
• Link: https://github.com/iNavFlight/inav/blob/master/docs/GPS_fix_estimation.md
• Tier: L1
• Publication Date: live (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: iNav 8.0+
• Target Audience: iNav fixed-wing operators
• Research Boundary Match: Full match
• Summary: iNav's internal dead-reckoning ("GPS fix estimation") for fixed-wing. Uses gyro/accel/baro/(mag/pitot). RTH-only intent. Explicitly states: "Not a solution for GPS spoofing (GPS output is not validated in INAV)" — iNav has no internal anti-spoofing, so anti-spoofing is fully the companion's responsibility. Two settings: inav_allow_gps_fix_estimation (RTH-with-no-GPS) and inav_allow_dead_reckoning (short-outage tolerance) — both default OFF. failsafe_gps_fix_estimation_delay controls mission-vs-RTH tradeoff (default 7 s).
• Related Sub-question: SQ6 (dead-reckoning fallback) + SQ8 (anti-spoofing implication)

Source #16

• Title: iNav docs/Settings.md (master)
• Link: https://github.com/iNavFlight/inav/blob/master/docs/Settings.md
• Tier: L1
• Publication Date: master (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: iNav master
• Target Audience: iNav operators
• Research Boundary Match: Full match
• Summary: Authoritative parameter list. Confirms inav_allow_dead_reckoning (line 2081, default OFF) ≠ inav_allow_gps_fix_estimation (line 2091, default OFF). The two settings address different scenarios. failsafe_gps_fix_estimation_delay (line 1041, default 7 s) governs mission-abort timing.
• Related Sub-question: SQ6

Source #17

• Title: iNav Issue #10588 — Weird behaviour in DeadReckoning mode while GPS outage is not constant
• Link: https://github.com/iNavFlight/inav/issues/10588
• Tier: L4 (open issue, 2025)
• Publication Date: 2025
• Timeliness Status: Currently valid (open)
• Target Audience: iNav operators
• Research Boundary Match: Full match
• Summary: Documented stability bug: intermittent GPS outages cause porpoising and motor bursts in dead-reckoning. Cited recommendation: "GPS should be rejected if providing erroneous coordinates rather than no fix." Risk for AC-NEW-8 (visual blackout + spoofed GPS) on iNav: do NOT rely on iNav's dead-reckoning for the spoof-active failsafe path; companion must actively suppress its own MSP feed and accept that iNav may misbehave during the gap. Better: continue feeding companion-IMU-propagated position with growing covariance via MSP2_SENSOR_GPS so iNav never enters its dead-reckoning state.
• Related Sub-question: SQ6 + AC-NEW-8 design implication

Source #18

• Title: iNav Release 8.0.0 (highlights, Dec 2024)
• Link: https://github.com/iNavFlight/inav/releases/tag/8.0.0
• Tier: L1 (project release notes)
• Publication Date: late 2024 / early 2025
• Timeliness Status: Currently valid
• Version Info: iNav 8.0
• Target Audience: iNav users
• Research Boundary Match: Full match
• Summary: Introduces fixed-wing GPS fix estimation (dead reckoning RTH-only) — the milestone for #8347. No new external-positioning inbound MAVLink in 8.0. Confirms iNav's 2024–2025 trajectory has not added a GPS_INPUT-equivalent inbound interface.
• Related Sub-question: SQ6

Source #19

• Title: iNav Release 9.0.0 / 9.0.1 + 9.0.0 Release Notes wiki
• Link: https://github.com/iNavFlight/inav/wiki/9.0.0-Release-Notes
• Tier: L1
• Publication Date: 2025-2026
• Timeliness Status: Currently valid
• Version Info: iNav 9.0.x
• Target Audience: iNav users
• Research Boundary Match: Full match
• Summary: New in 9.0: pitot APA/TPA, position estimator improvements, MSP_REBOOT DFU, GCS NAV via COMMAND_INT MAV_CMD_DO_REPOSITION. No new external-positioning inbound MAVLink. UBX <15.00 dropped. Confirms iNav 9.x continues the same external-positioning architecture as 8.x.
• Related Sub-question: SQ6

Source #20

• Title: MAVLink common message set — GPS_RAW_INT (24)
• Link: https://mavlink.io/en/messages/common.html
• Tier: L1 (MAVLink spec, live)
• Publication Date: live (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: MAVLink common, current
• Target Audience: MAVLink integrators
• Research Boundary Match: Full match
• Summary: Current published GPS_RAW_INT extension fields: alt_ellipsoid, h_acc (mm), v_acc (mm), vel_acc (mm/s), hdg_acc (degE5), yaw (cdeg). No spoofing/jamming/integrity bitfield is present in GPS_RAW_INT at the time of access, despite PR #2110 having been merged for spoofing/integrity reporting. Spoofing/integrity may live in a separate message (GPS_INTEGRITY or similar — to be verified in SQ8). For now, spoof-detection signals available to companion from FC are limited at the message-shape level; FC-side textual signals (STATUSTEXT) and NAMED_VALUE_INT are the documented practical path.
• Related Sub-question: SQ6 + SQ8

Source #21

• Title: MAVLink PR #2110 — gps: add status and integrity information
• Link: https://github.com/mavlink/mavlink/pull/2110
• Tier: L2 (protocol PR with cross-project sign-off)
• Publication Date: merged (accessed via search 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: MAVLink common
• Target Audience: MAVLink integrators across PX4 / ArduPilot / QGC / Mission Planner
• Research Boundary Match: Full match
• Summary: Adds GNSS status / integrity reporting (jamming/spoofing/error) at the protocol level. Cross-project sign-off across PX4, ArduPilot, QGC, Mission Planner. Field-level breakdown to be cross-checked in SQ8 against the dialect XML — current common.html does not show those fields inside GPS_RAW_INT itself, suggesting they live in a sibling message (likely GPS_INTEGRITY or GPS_STATUS_EXT).
• Related Sub-question: SQ6 → defer to SQ8 for the precise message name and field set ArduPilot uses to expose spoofing.

Source #22

• Title: AirDroper — GNSS Spoofing Filter (companion device, MAVLink2 NAMED_VALUE_INT pattern)
• Link: https://gps.airdroper.org/
• Tier: L3 (vendor product page; design pattern reference, not protocol authority)
• Publication Date: live (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Target Audience: ArduPilot integrators considering anti-spoofing
• Research Boundary Match: Reference only (vendor's specific algorithm not relevant; the integration pattern is)
• Summary: Establishes a precedent that "companion-runs-spoofing-detection → publishes confidence to GCS as MAVLink2 NAMED_VALUE_INT, logged to dataflash" is a real-world integration pattern with ArduPilot, not novel to this project. Useful for SQ8.
• Related Sub-question: SQ8 (referenced from SQ6)

Source #23

• Title: ArduPilot PR #24135 — Add option to make EKF3 more robust to bad IMU and lagged GPS data
• Link: https://github.com/ArduPilot/ardupilot/pull/24135
• Tier: L2 (development PR)
• Publication Date: 2023-2024 (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: master / propagated to stable
• Target Audience: ArduPilot developers
• Research Boundary Match: Full match
• Summary: Introduces EK3_GLITCH_RADIUS parameter — soft outlier rejection: instead of dropping a GPS measurement that fails innovation gating, the EKF inflates innovation variance to the minimum that just passes, effectively de-weighting the measurement. Implication for AC-NEW-4 (false-position safety): the project's covariance honesty contract on GPS_INPUT.horiz_accuracy is the ONLY way for AP's EKF to detect and de-weight a bad estimate; under-reporting collapses this safety net.
• Related Sub-question: SQ6 + AC-NEW-4 design implication

Source #24

• Title: ArduPilot AP_NavEKF3 — VehicleStatus.cpp + AP_NavEKF3.cpp (master)
• Link: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3_VehicleStatus.cpp ; https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3.cpp
• Tier: L1 (source code)
• Publication Date: master HEAD (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: master
• Target Audience: ArduPilot EKF3 developers
• Research Boundary Match: Full match
• Summary: EKF3 quality control: (a) ground-stationary GPS drift check ≤ 3 m (gated by _gpsCheckScaler); (b) innovation gating per POS_I_GATE / VEL_I_GATE; (c) soft de-weighting via EK3_GLITCH_RADIUS (Source #23). Confirms AP's covariance-driven quality path actually exists; companion-supplied horiz_accuracy flows into this chain.
• Related Sub-question: SQ6 (full file analysis deferred to design phase)

---

SQ1 — Existing / competitor GPS-denied UAV navigation systems

Source #25

• Title: Twist Robotics develops OSCAR — a GPS-independent visual navigation system for drones resistant to electronic warfare equipment
• Link: https://www.pravda.com.ua/eng/news/2026/01/28/8018266/
• Tier: L2 (national newspaper of record reporting on a Technology Forces of Ukraine release; primary press is the Technology Forces of Ukraine FB post)
• Publication Date: 2026-01-28 (accessed 2026-05-07)
• Timeliness Status: Currently valid (within 6-month critical-novelty window)
• Target Audience: Ukraine-deployment practitioners; UAV companion-system designers
• Research Boundary Match: Full match — Ukrainian fixed-wing-class UAV, GPS-denied, vision-based, deployed in active conflict
• Summary: Twist Robotics (UA) deployed OSCAR ("Optical System of Coordinates with Automatic Relocalisation") — camera + landmark-matching + map → autopilot ingests as a "reliable GPS signal". Vendor claims: 20 m accuracy without cumulative error, day/night/fog operation, 500,000 km logged across 25,000 combat missions over 24 months development, AI-augmented + Obrii proprietary simulator for training. Note: hardware photo shows active cooling on the module — implies non-trivial compute (probably Jetson-class). No public independent benchmark. Closest deployed peer system to this project.
• Related Sub-question: SQ1 (closest peer); also informs SQ8 (anti-spoofing claims), SQ9 (synthesis)

Source #26

• Title: Ukraine Gives Drones Vision-Based Navigation to Push Past Heavy Jamming — The Defense Post
• Link: https://thedefensepost.com/2026/01/29/ukraine-drones-vision-navigation/
• Tier: L2 (defense-trade publication; corroborates Source #25 with a second-party byline)
• Publication Date: 2026-01-29 (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Target Audience: Defense-policy / procurement readership
• Research Boundary Match: Full match
• Summary: Confirms OSCAR is operational, terrain-imagery-against-mapped-landmarks pattern, autopilot-ingestion. Adds "live imagery" framing. No new technical detail beyond Source #25.
• Related Sub-question: SQ1

Source #27

• Title: Ukraine's Ruta Missile Drone Will Get an EW-Immune Navigation System — Defense Express
• Link: https://en.defence-ua.com/weapon_and_tech/ukraines_ruta_missile_drone_will_get_an_ew_immune_navigation_system-14541.html
• Tier: L2 (defense-trade publication, Ukraine-domestic)
• Publication Date: 2025-05-17 (accessed 2026-05-07)
• Timeliness Status: Currently valid (within 18-month authority window)
• Target Audience: Defense-procurement / industry analysts
• Research Boundary Match: Partial — operational profile (cruise-missile-class, terminal guidance) differs from our 8-h fixed-wing surveillance/strike profile; technique class is closely related (DSMAC pattern)
• Summary: Destinus Ruta (Ukrainian-Swiss origin; ~300 km strike range, miniature cruise missile) will integrate a navigation system from UAV Navigation (Spanish, Grupo Oesía). Defense Express infers DSMAC-style operating principle: "takes images of surface mid-flight, identifies location through comparison with reference". Vendor announcement notes validation in Ukrainian combat conditions including GNSS-denied / jamming / spoofing. Establishes that the cruise-missile-tier vision-nav pattern is now being miniaturised for ~300 km strike drones.
• Related Sub-question: SQ1 (commercial/military landscape)

Source #28

• Title: Kilometer-Scale GNSS-Denied UAV Navigation via Heightmap Gradients: A Winning System from the SPRIN-D Challenge
• Link: https://arxiv.org/abs/2510.01348
• Tier: L1 (peer-style preprint, full system description, real flight data, competition results)
• Publication Date: October 2025 (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: arXiv v1 (2510.01348v1)
• Target Audience: GNSS-denied UAV system designers (academic + practitioner)
• Research Boundary Match: Partial — different regime. Multirotor (≤25 kg), <25 m AGL, LiDAR-equipped, no satellite-tile basemap; 9 km waypoint mission. Our project is fixed-wing, ~1 km AGL, no LiDAR, monocular + sat-tile basemap. Architectural pattern transfers; specific algorithm does NOT (heightmap gradients require LiDAR).
• Summary: CTU Prague team won SPRIN-D Funke Fully Autonomous Flight Challenge with: VIO (OpenVINS) + LiDAR-derived local heightmap + gradient template matching against open-data DEM + clustered K-means particle filter, all on Intel NUC i7 16 GB CPU-only (no GPU). Achieved RMSE <11 m over kilometer-scale flights vs ≤53 m for raw odometry. Critical observations explicitly stated:
  • RTAB-Map and ORB-SLAM3 both fail beyond 1 km / above 2 m/s flight (compute/memory) and ORB-SLAM3 loses tracking in textureless areas — directly applicable to our 17 m/s cruise over agricultural steppe.
  • "Some teams used RGB satellite image-based matching, but this has proved to be highly unreliable at such low altitudes." This is a low-altitude (<25 m AGL) finding; our 1 km AGL operates in the high-altitude regime where the same paper notes RGB sat-matching "works reasonably well" (refs [5][6]).
  • Lesson: "ability to recover from periods of high uncertainty and re-localize is more critical than maintaining consistently low instantaneous RMSE." Direct architectural input for AC-NEW-2 / AC-NEW-8.
  • Lesson: IMU-from-airframe vibration isolation is mission-critical for VIO usability.
  • Lesson: magnetometer is unreliable near steel-reinforced structures; sensor-fusion is essential for heading robustness.
• Related Sub-question: SQ1 + SQ5 (failure modes for VIO/SLAM at speed) + SQ2 (canonical pipeline)

Source #29

• Title: Hierarchical Image Matching for UAV Absolute Visual Localization via Semantic and Structural Constraints
• Link: https://arxiv.org/abs/2506.09748 (PDF: https://arxiv.org/pdf/2506.09748)
• Tier: L1 (peer-submitted preprint, IEEE-bound, with public CS-UAV dataset)
• Publication Date: June 2025 (accessed 2026-05-07)
• Timeliness Status: Currently valid (within 6-month critical-novelty window for SOTA claims)
• Version Info: arXiv v1 (2506.09748v1)
• Target Audience: Academic SOTA researchers + UAV-localization implementers
• Research Boundary Match: Full match — exact same problem (UAV absolute visual localization in GNSS-denied conditions, downward-facing camera, satellite reference)
• Summary: 2025 SOTA pipeline: (1) image retrieval module (off-the-shelf, optimal-transport feature aggregation), (2) Semantic-Aware and Structure-Constrained Matching Module using DINOv2 features + 4D correlation tensor + SoftMNN + 4D conv, (3) lightweight fine-grained module for pixel-level. Constructs UAV absolute visual-loc pipeline without VIO/relative-loc dependence (retrieval-and-matching only). Evaluation on AerialVL + their own CS-UAV. Direct relevance: this is a candidate template for our C2 (VPR) + C3 (cross-domain registration) components, but DINOv2 is a heavyweight foundation model — must be benchmarked under our 25 W / 8 GB Jetson Orin Nano envelope before selection (handed off to SQ3/SQ4 + SQ5 for that component).
• Related Sub-question: SQ1 (academic SOTA), SQ3+SQ4 (C2/C3 candidates), SQ5 (Jetson-on-Foundation-Model failure mode)

Source #30

• Title: Raptor — GPS-Denied UAV Navigation & Coordinate Extraction (Vantor product page; Guide / Sync / Ace suite)
• Link: https://www.vantor.com/product/mission-solutions/raptor/
• Tier: L2 (vendor product spec; primary for the product itself, not for independent benchmark numbers)
• Publication Date: live (accessed 2026-05-07; references Mar 2026 + Dec 2025 + Sep 2025 partner blog posts indicating active product line)
• Timeliness Status: Currently valid
• Target Audience: Defense / commercial / industrial UAV integrators
• Research Boundary Match: Full match — vision-based aerial position software using existing camera + 3D terrain data, deployable on commodity hardware
• Summary: Vantor Raptor product family: Guide (on-drone vision-based positioning, demonstrated <7 m absolute accuracy in all dimensions, day/night/low-altitude, runs on commodity HW); Sync (georegisters live drone video against 3D terrain in real time, <3 m coordinate extraction); Ace (laptop-side coordinate extraction at <3 m). Backbone: Vantor's "100 million-plus sq km of highly accurate 3D terrain data, regularly updated" (Vivid Terrain, 3 m accuracy). Inertial Labs partnership (VINS-integrated Raptor Guide). Use cases include joint multi-domain ops, large-scale autonomous delivery, search-and-rescue. This is the closest production-grade commercial peer to the project's architecture (sat-basemap-as-service + on-drone vision).
• Related Sub-question: SQ1 (commercial), SQ3+SQ4 (commercial alternatives to building C2/C3 ourselves), SQ8 (basemap as a service vs offline cache)

Source #31

• Title: Auterion successfully completes Artemis program to deliver long-range deep strike drone (press release)
• Link: https://auterion.com/auterion-successfully-completes-artemis-program-to-deliver-long-range-deep-strike-drone/
• Tier: L1 (official vendor press release)
• Publication Date: 2025-10-15 (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Target Audience: Defense-procurement; UAV-integration architects
• Research Boundary Match: Full match — fixed-wing-class one-way attack drone with Ukraine-validated GPS-denied navigation; the system architecture is directly comparable
• Summary: Auterion Artemis (DIU project, completed Oct 2025) = Shahed-style design developed in Ukraine; up to 1,000-mile range; up to 40 kg warhead; runs on Auterion Skynode N mission computer + Auterion Visual Navigation system + built-in terminal guidance. Government evaluators signed off after operational flight tests in Ukraine including ground launch, GPS and GPS-denied navigation, long-range transit, and terminal engagement. Establishes that the integration pattern (companion-class autopilot + visual navigation + terminal guidance) is shipping at production scale to a US defense customer. Open architecture, manufacturing in US/UA/DE.
• Related Sub-question: SQ1

Source #32

• Title: Bring AI and computer vision to small autonomous systems — Auterion Skynode S product page
• Link: https://auterion.com/product/skynode-s
• Tier: L2 (vendor product spec)
• Publication Date: live (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Target Audience: Small-UAS integrators
• Research Boundary Match: Full match (companion-class autopilot with NPU)
• Summary: Auterion Skynode S = compact mission computer with dedicated Neural Processing Unit for AI / computer-vision applications on small UAS systems. Architecturally the same niche our Jetson Orin Nano Super sits in (companion compute + autopilot integration), but with Auterion's PX4 fork pre-integrated. Hardware/runtime envelope is comparable; the product establishes that this is a product category, not a one-off integration.
• Related Sub-question: SQ1, SQ7 (alternate companion HW for adjacent context)

Source #33

• Title: snktshrma/ngps_flight — Next-Generation Positioning System for ArduPilot (GSoC 2024)
• Link: https://github.com/snktshrma/ngps_flight (sibling: https://github.com/snktshrma/ap_nongps)
• Tier: L1 (open-source code repository, published GSoC project under ArduPilot organisation)
• Publication Date: GSoC 2024 timeframe (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Version Info: GSoC 2024 prototype (research-grade, not production firmware)
• Target Audience: ArduPilot integrators building visual-positioning companion stacks
• Research Boundary Match: Full match — closest open-source peer to our exact pipeline. ArduPilot, downward-facing camera, satellite-image reference, deep-learning matching, fused with VIO, fed back to autopilot.
• Summary: NGPS = ROS 2 + ArduPilot pipeline composed of three packages: ap_ngps_ros2 (visual geo-localization at 1–2 Hz by matching live camera frames to georeferenced satellite imagery using LightGlue + SuperPoint); ap_ukf (Unscented Kalman Filter fusing NGPS absolute positions with VIO estimates); ap_vips (VIO providing relative pose). Output is fused odometry to ArduPilot's EKF via VISION_POSITION_ESTIMATE (per the related issue #23471 framing). This is the architectural template the project should explicitly compare against — same component split as our C1+C2+C3+C5+C8 stack.
  • Caveats: (a) GSoC prototype, not production-hardened; (b) uses VISION_POSITION_ESTIMATE which on AP requires EKF source set 2/3 with EK3_SRC*_POSXY=Vision; our SQ6 conclusion picked GPS_INPUT as primary AP path because it carries horiz_accuracy directly and supports source-set switching via MAV_CMD_SET_EKF_SOURCE_SET — must compare the trade-off in design phase; (c) no documented spoofing-defence integration; (d) no documented covariance-honesty contract.
• Related Sub-question: SQ1 (closest open-source peer), SQ2 (canonical-pipeline confirmation), SQ3+SQ4 (architectural template for component selection), SQ6 (alternate AP transport: VISION_POSITION_ESTIMATE vs GPS_INPUT)

Source #34

• Title: AerialExtreMatch — A Benchmark for Extreme-View Image Matching and Localization (project page + GitHub + Hugging Face dataset)
• Link: https://xecades.github.io/AerialExtreMatch/ ; https://github.com/Xecades/AerialExtreMatch ; https://huggingface.co/datasets/Xecades/AerialExtreMatch-Localization
• Tier: L1 (peer-reviewed benchmark with public dataset, code, model checkpoints; OpenReview submission)
• Publication Date: 2025 (accessed 2026-05-07)
• Timeliness Status: Currently valid
• Target Audience: Academic + practitioner image-matching evaluators
• Research Boundary Match: Full match for cross-source UAV-satellite image matching evaluation
• Summary: 2025 benchmark with: 1.5 M synthetic train pairs (RGB+depth, diverse UAV/satellite viewpoints); ~30,000 evaluation pairs in 32 difficulty levels stratified by overlap (4 bins: <20/20-40/40-60/>60%), pitch difference (4 bins: 50–55, 55–60, 60–65, 65–70°), and scale (2 bins: 1-2×, >2×); a real-world UAV-localization split captured with DJI M300 RTK + H20T against UAV-derived orthomosaic/DSM AND lower-quality satellite maps. Evaluates 16 representative detector-based + detector-free image matching methods. This is the academic benchmark our C2+C3 candidate selection must publish numbers against.
• Related Sub-question: SQ1 (academic landscape), SQ7 (datasets)

Source #35

• Title: DARPA Fast Lightweight Autonomy (FLA) program page + Test-and-Evaluation review (arXiv 2504.08122)
• Link: https://www.darpa.mil/research/programs/fast-lightweight-autonomy ; https://arxiv.org/abs/2504.08122
• Tier: L1 (DARPA program page + 2025 academic review of program results)
• Publication Date: program 2015–2018 (concluded); review 2025-04 (accessed 2026-05-07)
• Timeliness Status: Foundational reference; review is current (within 18-month authority window)
• Target Audience: Defense-program historians + indoor-low-altitude GPS-denied autonomy researchers
• Research Boundary Match: Partial — different regime. FLA = small quadcopters at ≤20 m/s in cluttered indoor/outdoor with onboard sensing only, no satellite-tile basemap. Our project is fixed-wing, ~17 m/s, 1 km AGL, with sat-tile basemap.
• Summary: Foundational US-defense lineage for GPS-denied autonomy (2015–2018, complete). Set the template for "small UAV + onboard sensors + onboard compute → autonomous obstacle-avoidance + navigation without datalink/GPS". Phase 1 in Florida 2017; Phase 2 in Georgia 2018. The 2025 retrospective (arXiv 2504.08122) reviews FLA's testing methodology and Phase 1 results. Companion 2025 USAF SBIR Phase II solicitation (Sweetspot ID 7946c818-409f-5b31-8f06-554466071d83) is requesting visual-position-and-navigation capability for sUAS in GPS-denied environments — the regulatory tailwind is now active.
• Related Sub-question: SQ1 (defense-program lineage)

Source #36

• Title: DSMAC / TERCOM lineage — DTIC ADA315439 (Scene Matching Missile Guidance Technologies) + Wikipedia / SPIE references
• Link: https://apps.dtic.mil/sti/tr/pdf/ADA315439.pdf ; https://en.wikipedia.org/wiki/DSMAC ; https://www.spiedigitallibrary.org/conference-proceedings-of-spie/0238/1/Terrain-Contour-Matching-TERCOM-A-Cruise-Missile-Guidance-Aid/10.1117/12.959127.short
• Tier: L1 (DTIC unclassified technical report) + L2 (encyclopedia/SPIE proceedings)
• Publication Date: DTIC: 1996; SPIE: 1980; Wikipedia: live
• Timeliness Status: Foundational baseline (no time window per Step 0.5 — established classical algorithms)
• Target Audience: Cruise-missile-class designers; analogues for downward-vision navigation
• Research Boundary Match: Partial — different regime (cruise missile, terminal guidance). Architectural pattern (pre-cached scene reference + downward camera + correlation matching) is the direct ancestor of our C3 pipeline.
• Summary: DSMAC = electro-optical camera correlated against pre-stored reference scenes (often from satellite reconnaissance), achieving 3–10 m terminal accuracy. Tomahawk: TERCOM (radar altimeter + DEM) for mid-flight; DSMAC for terminal. CEP without DSMAC: ~30 m; with DSMAC: "only meters". Gulf War 1991: >80% of 280 launched Tomahawks hit target. Establishes that downward-vision-against-pre-stored-imagery is a 40+ year-old well-characterised technique class with documented accuracy bounds; our project's claim of <500 m / 99.9% reliability is achievable in the same technique class.
• Related Sub-question: SQ1 (lineage), SQ8 (baseline accuracy expectations)

Source #37

• Title: Electronic Warfare in Ukraine: The Invisible Battle — Ukraine War Analytics
• Link: https://ukraine-war-analytics.com/analysis/electronic-warfare-ukraine.html
• Tier: L3 (analytical aggregator; primary-source numbers cite vendor / OSINT reports)
• Publication Date: live (accessed 2026-05-07)
• Timeliness Status: Currently valid (operational-context reference)
• Target Audience: Ukraine-deployment practitioners
• Research Boundary Match: Full match (operational geography, threat environment)
• Summary: Operational-context anchor: Russian EW systems including Pole-21 GPS jammers (25+ km range) plus spoofing capabilities have driven ~70% of small-tactical-UAV losses to EW across the conflict. Twist Robotics' OSCAR cites the same approximate number (~75% of small tactical UAV losses to EW at the front per Source #25). Confirms the demand-side number is consistent across two independent reporting chains.
• Related Sub-question: SQ1 (Ukraine practitioner perspective)

---

SQ2 — Canonical pipeline decomposition

Source #38

• Title: Visual Place Recognition for Aerial Imagery: A Survey (Moskalenko, Kornilova, Ferrer — Skoltech)
• Link: https://arxiv.org/abs/2406.00885 (v2)
• Tier: L1 (peer-reviewed survey, accepted in Robotics and Autonomous Systems; companion benchmark code: https://github.com/prime-slam/aero-vloc)
• Publication Date: arXiv 2024-06; v2 update through 2024
• Timeliness Status: Currently valid (within 18-month authority window for established surveys; specific candidate latency numbers will need cross-validation against newer Jetson-class hardware reports)
• Target Audience: Aerial-VPR practitioners + UAV navigation system architects
• Research Boundary Match: Full match for the offline-cache visual geo-localization decomposition (aerial-nadir UAV vs. satellite tile basemap)
• Summary: Authoritative two-stage pipeline definition (verbatim): "Visual geolocalization can be implemented through various methods, typically relying on a pre-built database of images with known locations. This approach generally involves two stages: global localization (or Visual Place Recognition, VPR) and local alignment. Global localization involves identifying the nearest frame from the database (Image Retrieval), while local alignment determines the precise position using the selected frame." Re-ranking is treated as an integral sub-stage of VPR for aerial data because of agricultural/urban grid repetition. Local alignment = SuperPoint/keypoint detector → LightGlue/SuperGlue/SelaVPR matcher → cv2.findHomography → cv2.perspectiveTransform → Web-Mercator coordinate conversion. Practitioner-critical runtime numbers (RTX 3090, NOT Jetson): AnyLoc descriptor calculation = 0.37–0.84 s/frame (huge ViT-G DINOv2); MixVPR / SALAD = 0.05–0.20 s; SelaVPR = 0.04 s; SuperGlue re-rank = 15–25 s on top-100 candidates; LightGlue re-rank = ~1 s; SelaVPR re-rank = <0.1 s. Memory: AnyLoc descriptors = 2.3–13.9 GB for 4–7k tiles; SelaVPR = <0.2 GB. Final commentary: "While our methodology alone may not provide comprehensive robustness, it can be effectively augmented with additional sensors, such as inertial measurement units (IMUs). This integration enhances its utility for Visual Inertial Odometry (VIO) and Simultaneous Localization and Mapping (SLAM) systems, particularly for periodic location refinement and loop closure tasks. Additionally, our methodology could serve as a dependable emergency localization fallback in the event of an unexpected GNSS signal loss." → Validates the project's IMU/VIO + sat-anchor architecture as the canonical extension of the survey's two-stage core.
• Related Sub-question: SQ2 (canonical decomposition), SQ3+SQ4 (C2/C3 candidate latency budgets), SQ5 (foundation-model-on-Jetson failure mode)

Source #39

• Title: Cross-View Geo-Localization: A Survey (Durgam, Paheding, Dhiman, Devabhaktuni — U. Maine / Fairfield / ISU)
• Link: https://arxiv.org/abs/2406.09722 (v1)
• Tier: L1 (peer-style preprint, journal-bound — Expert Systems with Applications)
• Publication Date: arXiv 2024-06
• Timeliness Status: Currently valid (≤18 months for survey-of-deep-learning architectures)
• Target Audience: Cross-view (ground↔aerial) geo-localization researchers; partial overlap with our aerial↔satellite pipeline
• Research Boundary Match: Partial — different cross-view setup (the survey focuses on ground panorama → aerial overhead; ours is aerial nadir → satellite ortho). The pipeline-shape lessons transfer; the polar-transform / Siamese-network / GAN-based view-synthesis lessons do NOT directly apply because our two views are both top-down.
• Summary: Confirms the canonical pipeline decomposition (feature extraction → cross-view matching → similarity-driven retrieval) is the dominant pattern across 2015–2024 SOTA. Establishes the historical lineage: pixel-wise (Sheikh 2003) → feature-based (Lin 2013) → CNN/triplet-loss (Tian 2017) → Siamese+GAN (Hu 2018) → polar-transform (Shi 2019) → CosPlace/EigenPlaces (2022–2023) → DINOv2-class (AnyLoc 2023) → Transformer-only (TransGeo 2022, MGTL 2022) → multi-method fusion (2023+). Backbone comparison table establishes that ViT/DINOv2 is the current SOTA backbone; ResNet-class is the established production baseline; SIFT/SURF/PHOW remain the handcrafted baseline. Confirms our component-area split (C2 VPR + C3 cross-domain matching) is canonical and matches the survey's two-axis organization (backbone × matching strategy).
• Related Sub-question: SQ2 (decomposition lineage), SQ3+SQ4 (C2 candidate landscape)

Source #40

• Title: OrthoLoC: UAV 6-DoF Localization and Calibration Using Orthographic Geodata (Dhaouadi, Marin, Meier, Kaiser, Cremers — DeepScenario / TU Munich / MCML)
• Link: https://arxiv.org/abs/2509.18350 ; project page https://deepscenario.github.io/OrthoLoC
• Tier: L1 (peer-style preprint with public dataset, code, model checkpoints; 16,425 UAV images Germany+US, full 6-DoF ground truth)
• Publication Date: arXiv 2025-09 (within 6-month critical-novelty window)
• Timeliness Status: Currently valid (within 6-month critical-novelty window for SOTA aerial-localization claims)
• Target Audience: UAV-localization implementers + system architects building on Digital Orthophotos (DOP) + Digital Surface Models (DSM)
• Research Boundary Match: Full match — direct paradigm match to our project: "lightweight orthographic representations" instead of 3D meshes; "increasingly accessible through free releases by governmental authorities"; "no internet connection or GNSS/GPS support" — exactly the project's constraint envelope.
• Summary: Most directly applicable SQ2 source. Defines the 6-DoF localization pipeline using 2.5D geodata: (1) match query UAV image against DOP (orthophoto raster) using state-of-the-art matchers; (2) lift each 2D match in the DOP to 3D using the corresponding DSM elevation; (3) PnP+RANSAC (RANSAC-EPnP, 5-pixel inlier threshold) → initial pose; (4) Levenberg-Marquardt joint refinement of intrinsics + extrinsics; (5) AdHoP refinement: estimate homography from initial 2D-2D correspondences via DLT+RANSAC, warp the DOP to better match the query's perspective, re-match, map back via H⁻¹, lift to 3D, refine pose; accept refinement only if reprojection error decreases. Quantitative results on 16.4k images, 47 locations: best matcher = GIM+DKM achieves 75.4% recall at 1m-1° threshold (sparse SP+SG = 64.4%, sparse SP+LG = 64.2%, MASt3R = 63.5%, RoMa+AdHoP = 54.6%, XFeat*+AdHoP = 59.8%; LoFTR / eLoFTR / XoFTR all <23% recall). AdHoP yields ~30% average matching improvement, ~20% translation/rotation error reduction; for previously-underperforming methods (XFeat* → 95% matching improvement; DKM → 63% translation reduction; RoMa → 1m-1° recall +23%). Performance factors explicitly characterized: (a) cross-domain DOPs (visual gap only) cause ~3× translation error increase even on best method; (b) cross-domain DOPs+DSMs (visual + structural gap) cause ~7× translation error increase (0.16 m → 1.12 m for GIM+DKM+AdHoP) — this is exactly the war-zone scene-change scenario AC-3.x covers; (c) 20% covisibility floor between query and reference; below it localization fails; (d) Calibration is fundamentally ambiguous between focal length and translation → camera intrinsics MUST be calibrated upstream, not jointly optimized in flight. (e) Resolution: scaling images to 30% of original (~300 px) still works; geodata at 13 m/pixel is the floor, with degradation below.
• Related Sub-question: SQ2 (canonical pipeline + AdHoP refinement loop), SQ3+SQ4 (C3 matcher candidate ranks), SQ5 (war-zone scene-change failure mode), SQ8 (covisibility safety gate)

Source #41

• Title: Exploring the best way for UAV visual localization under Low-altitude Multi-view Observation Condition: a Benchmark — AnyVisLoc (Ye, Teng, Chen, Li, Liu, Yu, Tan — NUDT / Macao Polytechnic)
• Link: https://arxiv.org/abs/2503.10692 ; benchmark code https://github.com/UAV-AVL/Benchmark
• Tier: L1 (peer-style preprint with public 18,000-image dataset across 15 Chinese cities, multi-pitch / multi-altitude / multi-scene, with both aerial-photogrammetry AND satellite reference maps)
• Publication Date: arXiv 2025-03 (within 6-month critical-novelty window)
• Timeliness Status: Currently valid
• Target Audience: Aerial AVL practitioners; UAV-system designers facing pitch/altitude/yaw uncertainty
• Research Boundary Match: Partial — different altitude regime (the benchmark covers 30–300 m AGL, ours is ~1 km AGL); pitch range is 20–90° (ours is mostly nadir, ~80–90°). Lessons on the pipeline structure, retrieval-vs-matching trade-offs, sensor-prior noise tolerance, and aerial-vs-satellite reference-map gap transfer directly.
• Summary: Independently confirms the SAME pipeline as Source #40: image retrieval (rough position) → image matching (2D-2D) → DSM-lift to 3D → PnP+RANSAC. Best baseline = CAMP (retrieval) + RoMa (dense matcher) + Top-N re-rank → 74.1% A@5m on aerial photogrammetry map, 18.5% A@5m on satellite map (ALOS 30m DSM). Critical AC-quantitative findings: (a) Aerial map vs satellite map: 4× accuracy gap at A@5m (74.1% vs 18.5%) — driven by satellite-DSM coarseness (ALOS 30m vs aerial 0.94m) and modality difference. Direct relevance: project's offline cache is satellite tiles ≥0.5 m/px without DSM; this places us between the two data points (better than ALOS 30m, worse than aerial photogrammetry) — exact accuracy must be re-established once tile resolution is pinned. (b) Yaw prior noise: σ ≤ 5° → no impact; σ = 10° → 1.9% A@5m drop; σ = 30° → 4.1% drop; σ = 50° → 13.7% drop; σ = 60° → 25.7% drop. Implication for project's C1+C5+IMU: companion-side yaw estimate must hold σ < 10°. (c) Pitch prior noise: σ < 5° → no impact; σ ≥ 7° causes ~1–5% drops. (d) Pitch angle: smaller pitch (more oblique) → lower accuracy; nadir is best. Project's nadir-fixed camera at 1 km AGL is consistent with the benchmark's most-favourable regime. (e) Sparse vs dense matchers: SP+LightGlue+GIM+k2s = 75.4% A@10m at 105 ms/frame; RoMa = 81.3% A@10m at 659 ms/frame. Implication for project's C7 Jetson runtime: dense matchers ~6× more accurate but ~6× slower → SP+LightGlue-class is the production sweet spot under our 400 ms budget. (f) Re-ranking strategy: Top-N re-rank by inlier count = best accuracy/cost trade-off (62.2% A@5m at 0.8 s/frame on RTX 3090). Match-without-retrieval = catastrophic (34.3% A@5m, search-space too large).
• Related Sub-question: SQ2 (pipeline + sensor-prior tolerance), SQ3+SQ4 (C2 retrieval-vs-matcher trade-offs, C5 IMU prior contract), SQ5 (war-zone reference-map staleness failure mode), SQ7 (aerial-vs-satellite reference benchmarks)

Source #42

• Title: Survey on absolute visual localization techniques for low-altitude unmanned aerial vehicles (Ye, Chen, Teng, Li, Yang, Song, Yu — NUDT, College of Aerospace Science)
• Link: https://www.sciopen.com/article/10.11887/j.issn.1001-2486.25120033 ; DOI 10.11887/j.issn.1001-2486.25120033
• Tier: L1 (peer-reviewed Chinese journal — Journal of National University of Defense Technology, vol 48 issue 2, 2026; same lab as Source #41 with overlapping authorship — confirmed cross-validation, not duplicative)
• Publication Date: 2026-04-01 (within 6-month critical-novelty window)
• Timeliness Status: Currently valid
• Target Audience: UAV-system architects + Chinese-defense-research community
• Research Boundary Match: Full match (low-altitude UAV AVL is the survey's exact subject)
• Summary: Survey-level confirmation of the canonical "retrieval-matching-pose estimation" hierarchical framework. Verbatim claim: "the hierarchical framework balances search efficiency, positioning accuracy, and scene generalization, becoming a robust technical path for low-altitude long-endurance absolute localization." Compares the framework against alternatives that are explicitly rejected: (a) relative visual localization (cumulative errors — VIO/SLAM only); (b) end-to-end direct localization (poor generalization); (c) map-free localization (scene-dependent). Sub-component evolution per stage: (a) retrieval = template-matching (SAD/SSD/NCC) → BoW/VLAD → deep-learning (annular/dense feature segmentation, contrastive InfoNCE, self-supervised); (b) matching = SIFT/SURF/ORB → SuperPoint+LightGlue/RoMa (sparse / semi-dense / dense); (c) pose estimation = PnP variants + RANSAC + IMU prior fusion. Identifies four open challenges that align with project risks: (i) cross-domain generalization (war-zone scene change); (ii) real-time inference on edge platforms (Jetson); (iii) robustness to complex environments (cropland, snow, low texture); (iv) high-quality datasets (the same gap our project's AC-NEW-7 / cache provisioning works around). Lightweight-model-design-for-edge-deployment is named as a primary future-research direction — directly validates project's Jetson Orin Nano constraint as a recognized field-level challenge, not a project-specific oddity.
• Related Sub-question: SQ2 (framework canonicalness), SQ3+SQ4 (per-component evolution), SQ5 (named open challenges align with project risks)