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)	In progress — C1 (VIO) candidate enumeration done (Sources #43–#52); per-mode context7 verification + Restrictions×AC sub-matrix per surviving candidate deferred to next session. C2–C10 not started.	See 02_fact_cards.md C1 cluster + preliminary applicability table.
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)

---

SQ3+SQ4 / C1 (Visual / Visual-Inertial Odometry) — Candidate enumeration

Source #43

• Title: VINS-Mono — A Robust and Versatile Monocular Visual-Inertial State Estimator (HKUST-Aerial-Robotics)
• Link: https://github.com/HKUST-Aerial-Robotics/VINS-Mono ; LICENCE: https://github.com/HKUST-Aerial-Robotics/VINS-Mono/blob/master/LICENCE
• Tier: L1 (canonical reference implementation; published in IEEE T-RO 2018 by Qin, Li, Shen)
• Publication Date: original 2018; repository last meaningful update 2024-02-25 (per GitHub commit log; 2024-05-23 simulation-data commit only)
• Timeliness Status: ⚠️ Borderline. ~24 months since the last meaningful master-branch commit at access time (2026-05-07). Established baseline that does NOT trigger Step 0.5's 18-month timeliness rejection because (a) IEEE T-RO publication is the canonical authority for the algorithm, (b) downstream forks (vins-mono-android, embedded variants) keep the algorithm class actively deployed.
• Version Info: No GitHub releases / tags (master-branch-only project). Stars 5,829.
• Target Audience: Mono+IMU VIO implementers; UAV state estimation researchers
• Research Boundary Match: Full match for the candidate's pinned mode — monocular camera + IMU producing 6-DoF metric pose. The VINS-Mono README explicitly names this configuration as primary.
• Summary: Optimization-based sliding-window monocular VIO. Features: efficient IMU pre-integration (Forster et al. 2017), automatic initialization, online camera-IMU extrinsic calibration, online camera-IMU temporal calibration, failure detection + recovery, loop detection (DBoW2-based), global pose graph optimization. Output is metric-scale 6-DoF pose at IMU rate (typically 100–200 Hz) with covariance from the optimization Hessian. License: GPL-3.0 (copyleft viral) — every binary distribution requires source disclosure for the entire linked binary; relevant for dual-use deployment if the companion image is sold or transferred to a customer.
• Related Sub-question: SQ3+SQ4 / C1 lead candidate

Source #44

• Title: VINS-Fusion — Optimization-based multi-sensor state estimator (HKUST-Aerial-Robotics)
• Link: https://github.com/HKUST-Aerial-Robotics/VINS-Fusion ; LICENCE: https://github.com/HKUST-Aerial-Robotics/VINS-Fusion/blob/master/LICENCE
• Tier: L1 (canonical reference; superset of VINS-Mono)
• Publication Date: original 2019 (Qin, Cao, Pan, Shen — ICRA workshop / IROS); repository last update 2024-05-23
• Timeliness Status: ⚠️ Borderline. ~24 months since the last update at access time. Same Step-0.5 reasoning as VINS-Mono — established class.
• Version Info: master-branch-only. Stars 4,476. Top-ranked open-source stereo-VIO on KITTI Odometry as of January 2019.
• Target Audience: Multi-sensor VIO implementers (mono+IMU, stereo, stereo+IMU, +GPS fusion)
• Research Boundary Match: Full match for monocular+IMU mode. VINS-Fusion README explicitly enumerates four sensor configurations (mono+IMU, stereo, stereo+IMU, +GPS toy example).
• Summary: Superset of VINS-Mono adding stereo and GPS-fusion modes. Same algorithmic core (sliding-window optimization with IMU pre-integration). Online spatial + temporal camera-IMU calibration; visual loop closure; ROS Kinetic/Melodic build dependency. License: GPL-3.0 — same dual-use distribution constraint as VINS-Mono. Independent KAIST benchmark (Source #46) found VINS-Fusion CPU mode + VINS-Fusion-imu fail to run on Jetson TX2 (insufficient memory and CPU); GPU-accelerated VINS-Fusion-gpu does run on TX2. Implication for project: VINS-Fusion-imu on Jetson Orin Nano Super is feasible but not certain; needs MVE.
• Related Sub-question: SQ3+SQ4 / C1 lead candidate

Source #45

• Title: OpenVINS — An open source platform for visual-inertial navigation research (Robot Perception and Navigation Group, U. of Delaware — rpng)
• Link: https://github.com/rpng/open_vins ; docs: https://docs.openvins.com/ ; LICENSE: https://github.com/rpng/open_vins/blob/master/LICENSE
• Tier: L1 (canonical research implementation; ICRA 2020 paper Geneva, Eckenhoff, Lee, Yang, Huang)
• Publication Date: original 2020; latest tagged release v2.7 = 2023-06; ongoing master-branch commits through 2024–2025 (latest issue threads through Feb 2025)
• Timeliness Status: ✅ Currently valid (master branch active; latest tagged release ~35 months but library is in stable/maintenance mode with continued issue triage).
• Version Info: Stars 2,828; 30 contributors; 12 releases. v2.7 is the current tagged stable.
• Target Audience: MSCKF/EKF VIO implementers; researchers needing a reference MSCKF
• Research Boundary Match: Full match for monocular+IMU mode. OpenVINS supports mono, stereo, multi-camera (1–N cameras) + IMU; mono is a documented first-class mode.
• Summary: Modular MSCKF (Multi-State Constraint Kalman Filter) implementation built around an Extended Kalman filter that fuses inertial state with sparse visual feature tracks via the sliding-window MSCKF formulation (Mourikis & Roumeliotis 2007). Supports SLAM features (in-state landmarks) plus pure MSCKF features (out-of-state). ROS1 + ROS2 (Humble) builds documented; Jetson Orin Nano Dev Kit + JetPack 6 + ROS 2 Humble compilation confirmed working by community contributors (rpng/open_vins issue #421, fdcl-gwu/openvins_jetson_realsense Nov 2025 setup guide). License: GPL-3.0 — same dual-use distribution constraint. Reported latency ~270 ms on Xavier NX (4-core, ARM, 40% CPU usage) per issue #164; needs Jetson-Orin-Nano-Super MVE for production budget verification.
• Related Sub-question: SQ3+SQ4 / C1 lead candidate

Source #46

• Title: Run Your Visual-Inertial Odometry on NVIDIA Jetson — Benchmark Tests on a Micro Aerial Vehicle (Jeon, Jung, Lee, Choi, Myung — KAIST)
• Link: https://arxiv.org/abs/2103.01655 ; KAIST VIO dataset: https://github.com/zinuok/kaistviodataset
• Tier: L1 (peer-reviewed conference, IROS-track preprint with public dataset)
• Publication Date: arXiv 2021-03-02
• Timeliness Status: ⚠️ Older than the 18-month Critical-novelty window, but uniquely authoritative for the specific question "do these VIO algorithms run on a Jetson?"; the included algorithms (VINS-Mono, VINS-Fusion, ROVIO, ALVIO, Stereo-MSCKF, Kimera, ORB-SLAM2-stereo) are all classical baselines whose runtime characteristics on ARM CPUs have not changed materially. Jetson hardware comparison (TX2 / Xavier NX / AGX Xavier) does NOT include Orin Nano — must extrapolate.
• Version Info: Conference paper.
• Target Audience: UAV state-estimation engineers picking a VIO for a Jetson companion
• Research Boundary Match: Strong match for the question, partial for the hardware (no Orin Nano). KAIST VIO dataset is indoor mocap, not UAV-aerial-nadir — the latency / CPU / memory numbers transfer; the accuracy numbers do not transfer to our domain.
• Summary: Comprehensive benchmark of 9 algorithms on TX2, Xavier NX, AGX Xavier: VINS-Mono, VINS-Fusion (CPU), VINS-Fusion-gpu, VINS-Fusion-imu, ROVIO, Stereo-MSCKF, ALVIO, Kimera, ORB-SLAM2-stereo. Hard findings: (a) on TX2, VINS-Fusion (CPU) and VINS-Fusion-imu fail to run due to insufficient memory and CPU performance — VINS-Fusion-gpu does run; (b) all algorithms except ROVIO show >100% CPU usage (multi-core utilisation, OK for our 6-core Orin Nano A78AE); (c) Kimera has the highest memory usage among VIO methods (numerous computations per keyframe), failure-prone on Xavier NX-class memory; (d) Stereo-MSCKF has the lowest memory among stereo VIOs; (e) ROVIO has the lowest CPU usage owing to its patch-tracking formulation. Implication for project: Jetson Orin Nano Super (8 GB shared, 6-core A78AE, Ampere GPU, 67 TOPS sparse INT8) is between Xavier NX and AGX Xavier in CPU performance and memory; algorithms passing on Xavier NX should pass on Orin Nano Super, but VINS-Fusion-imu's TX2 failure is a yellow-flag for memory pressure under co-resident C2/C3/C5 modules.
• Related Sub-question: SQ3+SQ4 / C1 (VINS-Mono / VINS-Fusion / OpenVINS / Kimera / Stereo-MSCKF / ROVIO Jetson runtime evidence), SQ5 (resource-budget failure modes)

Source #47

• Title: OKVIS2 — Realtime Scalable Visual-Inertial SLAM with Loop Closure (Leutenegger, ETH/Imperial/TUM Smart Robotics Lab)
• Link: https://github.com/ethz-mrl/okvis2 ; arXiv: https://arxiv.org/abs/2202.09199 ; LICENSE: https://github.com/ethz-mrl/okvis2/blob/main/LICENSE
• Tier: L1 (canonical implementation; arXiv 2022 by paper author)
• Publication Date: original arXiv 2022; OKVIS2-X T-RO 2025 successor (Boche, Jung, Laina, Leutenegger — IEEE T-RO 2025, vol 41 pp 6064–6083, DOI 10.1109/TRO.2025.3619051; arXiv 2510.04612, Oct 2025). Repository last push 2026-03-17 (ethz-mrl/OKVIS2-X).
• Timeliness Status: ✅ Current. Active development through 2026; OKVIS2-X is the most recent published VI-SLAM system in this class.
• Version Info: ethz-mrl/okvis2 (core) and ethz-mrl/OKVIS2-X (multi-sensor extension with optional GNSS / LiDAR / dense depth).
• Target Audience: Factor-graph VI-SLAM implementers; mid-large-scale loop-closure use cases
• Research Boundary Match: Full match for monocular+IMU mode. OKVIS2 README + paper explicitly support mono and multi-camera VI configurations. OKVIS2-X adds GNSS fusion (relevant: VINS-Fusion-style GPS-when-available drop-in IS the project's eventual posture in non-spoofed regions).
• Summary: Factor-graph VI-SLAM with bounded-size optimization. Innovation: pose-graph edges from marginalised observations can be "seamlessly turned back into observations" upon loop closure, reviving old landmarks and reprojection errors. Includes lightweight CNN segmentation for dynamic-region removal. OKVIS2-X (2025) generalises the core to fuse multi-camera + IMU + optional GNSS + LiDAR/depth — directly aligned with project's "VIO that may opportunistically fuse a non-spoofed GPS update" pattern and AC-NEW-2's spoof-promotion path. License: 3-clause BSD (permissive) — no copyleft / dual-use distribution friction. Note: GitHub UI shows "Other (NOASSERTION)" because of the standard BSD clause language pattern; the LICENSE file is canonical 3-clause BSD.
• Related Sub-question: SQ3+SQ4 / C1 lead candidate (factor-graph + permissive license + active maintenance)

Source #48

• Title: OKVIS2-X: Open Keyframe-based Visual-Inertial SLAM Configurable with Dense Depth or LiDAR, and GNSS (Boche, Jung, Laina, Leutenegger — TUM / ETH Zurich Smart Robotics Lab)
• Link: https://github.com/ethz-mrl/OKVIS2-X ; arXiv: https://arxiv.org/abs/2510.04612 ; IEEE T-RO 2025 vol 41 pp 6064–6083 DOI 10.1109/TRO.2025.3619051
• Tier: L1 (peer-reviewed IEEE Transactions on Robotics, Special Issue Visual SLAM 2025)
• Publication Date: arXiv 2025-10-04; T-RO 2025 vol 41
• Timeliness Status: ✅ Current (within 6-month Critical-novelty window)
• Version Info: 295 stars; 38 forks; 2 contributors; created 2025-09-23, last push 2026-03-17. License: NOASSERTION on GitHub UI; per-paper license follows ethz-mrl convention (BSD-3 derived).
• Target Audience: Multi-sensor SLAM researchers; large-scale VI-SLAM with optional GNSS/LiDAR
• Research Boundary Match: Strong match — extends OKVIS2 monocular+IMU mode with optional GNSS fusion (Visual-Inertial SLAM with Tightly-Coupled Dropout-Tolerant GPS Fusion lineage from IROS 2022). Project's MAV_CMD_SET_EKF_SOURCE_SET switch + companion-side spoof-detection conceptually mirrors OKVIS2-X's "GPS as drop-out-tolerant signal".
• Summary: Non-trivial extension of OKVIS2; submap-based volumetric occupancy mapping. Demonstrates that the OKVIS2 factor-graph backbone can absorb spoofing-aware GPS without re-architecting. Useful as architectural template for project's C5 estimator + C8 adapter integration. License: same as OKVIS2 (BSD-3-derived). Two named contributors (bochsim, SebsBarbas) actively pushing through Mar 2026.
• Related Sub-question: SQ3+SQ4 / C1 (OKVIS2 lineage; VI-SLAM with optional GPS/LiDAR), SQ8 (GPS-fusion dropout-tolerant lineage)

Source #49

• Title: Kimera-VIO — Visual Inertial Odometry with SLAM capabilities and 3D Mesh generation (MIT-SPARK)
• Link: https://github.com/MIT-SPARK/Kimera-VIO ; LICENSE.BSD: https://github.com/MIT-SPARK/Kimera-VIO/blob/master/LICENSE.BSD
• Tier: L1 (canonical implementation by MIT SPARK Lab)
• Publication Date: original 2020 (Rosinol, Abate, Chang, Carlone — ICRA 2020); ongoing development through 2024–2025 issue threads (Dec 2024 / Feb 2025 ROS2 / mono-inertial discussion).
• Timeliness Status: ✅ Active maintenance (recent issues / PRs through 2025).
• Version Info: master-branch-only; LICENSE.BSD = BSD 2-Clause "Simplified".
• Target Audience: VI-SLAM + mesh-mapping researchers
• Research Boundary Match: Partial. Stereo+IMU is the primary supported configuration; mono+IMU is optional but documented. Kimera also produces 3D mesh and high-level semantic labels (relevant to neither C1 nor the project's bandwidth budget — overhead).
• Summary: Frontend (image processing + IMU pre-integration) + Backend (factor-graph optimization in iSAM2 or GTSAM) + Mesher + Pose-Graph-Optimizer. License: BSD 2-Clause (permissive) — no dual-use distribution friction. Penalty for project: Source #46 KAIST benchmark found Kimera has highest memory usage among the VIOs tested (numerous computations per keyframe), and Kimera failed to fit on Xavier-NX-class memory under multi-process load. Mesh + semantic features are unused by the project — Kimera's overhead is unjustified vs OKVIS2 / OpenVINS for the project's narrow C1 mandate. Status: viable secondary fallback if OKVIS2 / VINS-Mono runtime issues arise; not a lead candidate due to overhead misfit.
• Related Sub-question: SQ3+SQ4 / C1 secondary candidate (BSD-permissive but resource-heavy)

Source #50

• Title: DROID-SLAM — Deep Visual SLAM for Monocular, Stereo, and RGB-D Cameras (princeton-vl, Teed & Deng)
• Link: https://github.com/princeton-vl/droid-slam ; arXiv: https://arxiv.org/abs/2108.10869 ; NeurIPS 2021
• Tier: L1 (canonical reference)
• Publication Date: NeurIPS 2021; repository latest tagged baseline.
• Timeliness Status: ✅ Foundational reference; DPV-SLAM (Source #51) is the lighter successor.
• Version Info: master-branch-only.
• Target Audience: Deep-learning-based VO/VSLAM researchers
• Research Boundary Match: Disqualified by hardware budget. Inference requires ≥11 GB GPU VRAM per official README; project budget is 8 GB shared CPU+GPU on Jetson Orin Nano Super, leaving <8 GB for VO + VPR + matcher + estimator + cache co-resident. DROID-SLAM is also monocular VO/SLAM, not VIO — no native IMU fusion; metric scale recovery requires external scale alignment.
• Summary: Recurrent dense bundle adjustment over a complete history of camera poses. State-of-the-art accuracy on TartanAir / EuRoC / TUM-RGBD at the cost of GPU memory. Disqualified outright for C1 lead by AC-4.2 (≤8 GB shared RAM) and the lack of IMU fusion that would require an additional ESKF/UKF wrapping. Kept as reference baseline to be cited as "what we cannot afford" in solution_draft01.
• Related Sub-question: SQ3+SQ4 / C1 disqualified candidate

Source #51

• Title: DPVO — Deep Patch Visual Odometry (princeton-vl, Teed, Lipson, Deng) + DPV-SLAM (Lipson, Teed, Deng — ECCV 2024)
• Link: https://github.com/princeton-vl/DPVO ; LICENSE: https://github.com/princeton-vl/DPVO/blob/main/LICENSE ; ECCV 2024 paper: https://www.ecva.net/papers/eccv_2024/papers_ECCV/papers/00272.pdf
• Tier: L1 (canonical implementation; NeurIPS 2023 + ECCV 2024)
• Publication Date: NeurIPS 2023 (DPVO); ECCV 2024 (DPV-SLAM); repository last update 2024-10-12.
• Timeliness Status: ⚠️ Borderline. ~19 months since last code update; ECCV-2024 publication of DPV-SLAM keeps the algorithm class within the 6-month claim window for the SLAM successor.
• Version Info: 989 stars; primary languages C++ / Python / CUDA. License: MIT (permissive) — no dual-use distribution friction.
• Target Audience: Deep-learning VO/SLAM with reduced memory footprint
• Research Boundary Match: Partial. DPVO is monocular VO only — no IMU fusion. Output pose is in arbitrary scale (no metric scale recovery). To be a viable C1 candidate the project must wrap DPVO with an external IMU+scale-fusion stage (loosely-coupled ESKF / VIO-fusion module). This makes DPVO not a drop-in C1 like VINS-Mono / OpenVINS / OKVIS2; it is a VO module that needs a separate VIO wrapper.
• Summary: Sparse patch tracking + differentiable bundle adjustment back end. Outperforms DROID-SLAM on TartanAir / EuRoC ATE while using ~1/3 of DROID-SLAM's GPU memory (DROID-SLAM: 8.7 GB VO mode vs DPVO: ~3 GB). DPV-SLAM (Lipson, Teed, Deng — ECCV 2024) adds full SLAM capability with 4–5 GB GPU usage. Jetson runtime evidence: indirect via DPVO-QAT++ (Source #52) — peak reserved memory 1.02 GB on RTX 4060 (8 GB) after INT8 fake-quant + custom CUDA kernel fusion; not directly tested on Jetson Orin Nano. Status for C1: pure-VO candidate (must be paired with separate IMU integration to deliver metric scale + attitude); would not satisfy "monocular VIO" gate alone, but viable as the VO half of a hybrid C1+C5 design.
• Related Sub-question: SQ3+SQ4 / C1 conditional candidate (VO not VIO; needs external IMU wrapper)

Source #52

• Title: DPVO-QAT++: Heterogeneous QAT and CUDA Kernel Fusion for High-Performance Deep Patch Visual Odometry (Cheng Liao)
• Link: https://arxiv.org/abs/2511.12653 ; project HTML: https://arxiv.org/html/2511.12653
• Tier: L2 (single-author preprint, code partially released; no peer-review yet)
• Publication Date: arXiv 2025-11-16 (within 6-month Critical-novelty window)
• Timeliness Status: ✅ Current
• Version Info: arXiv preprint; code & weights released for QAT-only and fused-CUDA variants.
• Target Audience: Embedded-platform DPVO deployers
• Research Boundary Match: Partial. Hardware tested = RTX 4060 (8 GB) + Intel Core Ultra 5-125H + 32 GB RAM — desktop GPU, NOT Jetson Orin Nano. Direct extrapolation requires Jetson MVE; Orin Nano Super's Ampere GPU is architecturally similar but smaller than RTX 4060.
• Summary: Quantization-Aware Training framework for DPVO with fused CUDA kernels. Reduces peak GPU memory from 1.94 GB → 1.02 GB (-47%) on a representative TartanAir sequence; +34.6% median FPS on TartanAir, +26.7% on EuRoC; -22.8 ms / -19.7 ms median P99 tail latency on TartanAir / EuRoC respectively. Heterogeneous precision: front-end pseudo-quantization (FP16/FP32 with INT8 simulation) + FP32 back-end geometric solver. Implication for project: shows DPVO has a documented Jetson-suitable footprint path but not a Jetson-Orin-Nano measurement. ATE accuracy comparable to baseline DPVO across 32 TartanAir + 11 EuRoC validation sequences. Notable: requires a teacher-student distillation training pipeline before deployment — adds operational complexity vs classical VINS-* / OpenVINS / OKVIS2.
• Related Sub-question: SQ3+SQ4 / C1 supporting evidence for DPVO embedded feasibility

Source #53

• Title: Pure VO baseline — KLT optical flow + 5-point essential matrix or homography RANSAC (OpenCV reference)
• Link: https://docs.opencv.org/4.x/d4/dee/tutorial_optical_flow.html ; representative public implementation: https://github.com/alishobeiri/Monocular-Video-Odometery (MIT, 2018) ; tutorial reference: https://zxh.me/posts/2022-12-19-monocular-visual-odometry/
• Tier: L1 (OpenCV official documentation) + L2 (representative public implementations)
• Publication Date: OpenCV docs continuously updated; tutorial 2022-12; reference implementation 2018 (algorithmic class is foundational, no time window per Step 0.5)
• Timeliness Status: ✅ Foundational baseline (no time window).
• Version Info: OpenCV cv::calcOpticalFlowPyrLK (KLT) + cv::findEssentialMat (5-point Nister) or cv::findHomography with RANSAC.
• Target Audience: Implementers needing a transparent low-complexity fallback
• Research Boundary Match: Full match for the simple-baseline candidate. Suits planar nadir-down UAV at altitude (Ukrainian steppe is ~planar at 1 km AGL — homography is geometrically appropriate; for non-planar relief the essential matrix path is more appropriate but adds scale-recovery work).
• Summary: Established classical pipeline: Shi-Tomasi or FAST corner detection → KLT pyramidal optical flow tracking → 5-point essential matrix or homography RANSAC → relative pose with arbitrary scale (must be metric-scale-aligned via IMU integration externally). Reference implementations widely available in OpenCV samples and pedagogical repos. Status: candidate as the project's Simple baseline / known-runnable / known-failure-mode C1 option per Component Option Breadth rule. Not a lead, but mandatory fallback presence per the research engine's "include at least one simple baseline" rule.
• Related Sub-question: SQ3+SQ4 / C1 simple-baseline candidate