# Source Registry — SQ6 — ArduPilot Plane vs iNav external positioning

> 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.
>
> This file replaces a section of the previous monolithic `01_source_registry.md`. See `00_summary.md` for the full category index. Investigation order is tracked in `../00_question_decomposition.md` and the cross-category Investigation Status table in `00_summary.md`.

---

### 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
