GPS-Denied UAV Localization: NGPS System Achieves 2.94m RMSE in Real Flights (IROS 2026)

When a drone loses GNSS signals, it can still fly using visual-inertial odometry. But position errors accumulate with every meter traveled. Loop closure helps, but requires revisiting previously explored areas — not practical for continuous mapping, inspection, or search missions.

The paper NGPS (Neural Geo-Positioning System) takes a more engineering-feasible route: use a downward-looking camera to match real-time imagery against pre-loaded georeferenced satellite images, providing periodic absolute position fixes that correct VIO drift through asynchronous fusion. Accepted at IROS 2026, the system achieves 2.94 m position RMSE across five real flight sequences — a 72% reduction from monocular VIO’s 10.37 m baseline.

Addressing a Fundamental Problem in Autonomous Drone Flight

When GNSS is unavailable, how can a UAV maintain georeferenced absolute localization over extended periods — not just estimate relative displacement?

Visual-inertial odometry can estimate how far the drone has moved since the last frame, but heading, scale, and position errors accumulate without external absolute constraints. Loop closure detection mitigates drift but requires revisiting previously traversed areas — assumptions that don’t hold for continuous exploration missions like surveying, inspection, and search.

NGPS’s core approach: match the drone’s downward-facing camera view against georeferenced satellite base maps, recover absolute position from the map, and use this low-frequency result to continuously correct VIO drift.

Cross-Scale Image Registration, Not Scene Understanding

NGPS’s visual localization module uses SuperPoint for keypoint extraction and LightGlue for feature matching between drone images and satellite imagery. RANSAC estimates homography and the drone’s position relative to the satellite base map.

This is not visual-language navigation. The system doesn’t understand commands like “fly along the road” or “bypass the red building.” It solves the more fundamental problem of cross-view geolocalization: matching pixels from the drone’s camera to geographic coordinates on a satellite map.

Four main challenges exist:

• Scale differences — satellite imagery and drone camera have different ground resolutions
• Perspective changes — drones experience roll, pitch, and yaw; reference imagery is near-orthographic
• Temporal differences — satellite basemaps may be months or years old; buildings, roads, vegetation, and lighting change
• Onboard compute — large-scale satellite image matching cannot run unrestricted on embedded platforms

Key Design: Predict the Next Search Window Instead of Searching the Entire Map

Matching every frame against the full satellite map is computationally prohibitive and prone to false correspondences.

NGPS employs a velocity-predicted search window. Based on UKF velocity estimates, the system predicts where the drone will be at the next visual localization update and crops the satellite image around that prediction.

This mechanism is critical because absolute visual localization runs at only 1–2 Hz. The drone may have moved several meters between updates. Without velocity prediction, the search window stays at the last known position — at higher speeds, the drone flies right out of the search area.

At 4 m/s, the velocity-predicted window boosted matching success from 64.3% to 84.7% — a 32% relative improvement.

Three Data Frequencies: Not Simply “Mixed Together”

NGPS simultaneously handles three data streams at vastly different frequencies:

• Visual geolocalization: 1–2 Hz
• VIO position and velocity: 10–20 Hz
• IMU attitude and motion: 100–200 Hz

The fusion result is fed into ArduPilot EKF3 running at 100–400 Hz.

To handle timing, the paper designs an asynchronous time-priority queue. All measurements are first sorted by timestamp, then fed into the Unscented Kalman Filter strictly in capture order. This ensures temporal consistency across data streams with different frequencies and processing delays.

The system adapts measurement covariance based on: RANSAC inlier ratio, reprojection error, and LightGlue match confidence. Adaptive weighting achieved an additional 11% RMSE reduction compared to fixed noise models.

Real Flight Validation

Hardware: NVIDIA Jetson Orin NX (onboard compute), Cube Orange Plus (flight controller), Topotek stabilized gimbal camera (downward). Software: ROS 2 Humble, PyTorch, ArduPilot. Satellite reference at 0.3 m/pixel GSD. RTK-GPS trajectory at ~2 cm accuracy as ground truth.

Method	RMSE	Max Error
Monocular VIO	10.37 m	31.40 m
Visual Geo Only	4.46 m	9.84 m
Fixed-Noise Fusion	3.29 m	7.82 m
Adaptive NGPS	2.94 m	6.87 m

72% RMSE reduction vs monocular VIO (10.37 → 2.94 m).

2.94 m Is Not Achievable at All Altitudes

• 80–100 m in urban/suburban terrain: 1.82–2.06 m RMSE
• 60 m farmland: 2.73 m RMSE
• 150 m altitude: RMSE rises to 6.04 m, matching success drops to 78.3%

Performance on Jetson Orin NX

SuperPoint: ~47 ms. LightGlue: ~318 ms (~82% of GPU time). Total pipeline: ~386 ms (~2.6 Hz). CPU-only: 2052 ms (~0.5 Hz). GPU is mandatory for real-time operation.

Generating Georeferenced 2.5D Maps

NGPS produces georeferenced orthomosaics and digital surface models (DSM). Useful for emergency mapping, infrastructure inspection, search and rescue, and low-altitude path planning.

What This Research Actually Solves

NGPS advances drone localization from purely “relative motion estimation” to “relative odometry + map-based absolute correction.” A classic dual-layer structure: high-frequency VIO for continuity, low-frequency satellite matching for drift suppression.

It does not require redesigning the flight controller or deploying ground stations. The system integrates with existing flight platforms through ROS 2 and ArduPilot interfaces, running on Jetson-class hardware.

But it depends on three preconditions:

1. Clear georeferenced reference imagery of the mission area
2. Current ground appearance must not deviate excessively from satellite images
3. A reasonable initial search range

Industry Perspective: Multi-Source Redundancy

Future mature systems may combine GNSS+RTK, VIO, satellite image matching, LiDAR/radar terrain matching, and signals-of-opportunity navigation.

NGPS demonstrates a practically flyable system integration. Key areas for continued development: multi-scale relocalization, long-term mismatch recovery, satellite image domain adaptation, lower compute deployment, and cross-region validation.

Paper: https://arxiv.org/html/2607.18936

If you have any questions about GNSS-denied navigation or need FPV/data link solutions compatible with your UAV platform, feel free to contact us at [email protected].

Have questions about this article? Feel free to contact us at [email protected] — we’re happy to help!

Frequently Asked Questions

1. Does NGPS require internet access to fetch satellite images in real-time?

No. The satellite reference imagery is pre-loaded before the mission. NGPS performs matching entirely onboard.

2. Can NGPS run on lower-cost hardware like Jetson Nano?

On Jetson Orin NX: ~386 ms per match. Lower-end hardware would achieve <1 Hz localization. Contact Aomway for hardware recommendations.

3. How does NGPS handle seasonal changes in satellite imagery?

Large appearance changes reduce matching quality. Adaptive covariance helps prevent bad matches from corrupting the state estimate, but significant change remains challenging.

4. What happens over water or uniform terrain?

NGPS loses matching capability and falls back to pure VIO. The UKF continues propagating state until the next successful match.

5. Is NGPS code available?

Partial code is available on the authors’ GitHub repository. Aomway can assist with system integration for teams implementing similar GNSS-denied navigation capabilities.