Reading Time: 12 minutes

GPS-Denied Localization in Autonomous Vehicles: Solving the Urban Canyon Problem

About the Author

I am Dr. Dilip Kumar Limbu, Co-Founder of Moovita — Singapore’s first autonomous vehicle company — and former Principal Research Scientist at A*STAR’s Institute for Infocomm Research (I2R). Based on my 25 years of experience in building and scaling autonomous shuttle fleets across Singapore, Malaysia, and China, I have watched GPS positioning swing by 10+ metres in real time simply because our vehicle drove between two tall buildings in Singapore’s dense urban core — a problem that, left unsolved, makes Level 4 deployment in any real city impossible. In this post, based on my experience, I’ll share exactly why GPS fails where it matters most, and the layered localization architecture — HD maps, LiDAR SLAM, sensor fusion — that production autonomous vehicles actually use to know where they are.

TL;DR — Quick Insights

GPS alone is not viable for AV localization in any dense city. Multipath propagation errors from surrounding buildings and line-of-sight occlusion from tall structures and tunnels can severely impact GPS localization accuracy — exactly the environments where robotaxi demand is highest.
HD maps solve localization by turning it into a matching problem. Instead of trusting satellites, the vehicle compares live sensor data against a pre-built, centimetre-accurate map and computes its position from that match — correcting GPS drift rather than depending on it.
LiDAR-based SLAM is the dominant fallback when GPS is fully unavailable — tunnels, underground car parks, dense canyon streets — using loop closure detection to correct the drift that inevitably accumulates in any dead-reckoning system.
Factor Graph Optimization (FGO) is replacing the Extended Kalman Filter (EKF) as the production standard for fusing GNSS, IMU, and wheel odometry, because FGO demonstrates superior accuracy during GNSS outages in urban canyons.
The real-world answer is always layered, never singular — no production AV system relies on one localization method; they fuse GNSS, IMU, wheel odometry, LiDAR/visual SLAM, and HD map matching simultaneously, weighted by real-time confidence.

Table Of Contents

Introduction: The Problem Nobody Notices Until It Fails
Part 1: Why GPS Fails Exactly Where Autonomous Vehicles Need to Operate
Part 2: HD Maps — Turning Localization Into a Matching Problem
Part 3: SLAM — Localizing Without Any Pre-Built Map
Part 4: Sensor Fusion for Localization — IMU, Wheel Odometry, and the Shift to Factor Graphs
Part 5: The Layered Architecture — How It All Fits Together in Production
Engineering Insights — What to Build Today
Lessons Learned
GPS‑Denied AV Localization FAQs: Urban Canyon Solutions 2026

Introduction: The Problem Nobody Notices Until It Fails

When most people think about why autonomous vehicles are hard to build, they focus on perception — detecting pedestrians, reading traffic lights, or tracking other cars. But there’s a deeper challenge: knowing exactly where the vehicle is, in real time, with centimetre‑level precision.

At first glance, this sounds solved. Every smartphone has GPS. But phone GPS is only accurate to about 5–10 metres under good conditions. That’s fine for “turn left in 200 metres,” but useless for a vehicle that must know which lane it’s in or whether it has 30 cm or 3 m of clearance from a parked truck.

Autonomous vehicle navigating tall city buildings using LiDAR, cameras, IMU, and AI mapping to overcome GPS signal loss in urban canyons.

I saw this problem firsthand while deploying Moovita’s autonomous shuttles in Singapore. The city’s dense high‑rise “urban canyons” created some of the worst GPS conditions in the world. Signals bounced off buildings, producing errors so large that the shuttle sometimes thought it was on the wrong street.

That’s why production autonomous vehicles don’t rely on GPS alone. They use layered localization architectures:

HD maps + LiDAR to match real‑time scans against stored 3D maps.
Visual odometry to track movement through camera frames.
IMU sensors to measure acceleration and rotation when GPS drops out.
Sensor fusion to combine all of the above into a robust position estimate.

Bottom line: GPS fails in cities, and centimetre‑level localization requires multi‑layer fusion. Without it, autonomous vehicles cannot safely operate in dense urban environments.

Part 1: Why GPS Fails Exactly Where Autonomous Vehicles Need to Operate

Building autonomous vehicles isn’t just about teaching machines to see pedestrians, read traffic lights, or detect other cars. The harder question is: how does a vehicle know, with centimetre‑level precision, exactly where it is at any moment?

Most people assume GPS solves this. After all, every smartphone has it. But consumer GPS is only accurate to 5–10 metres under good conditions — fine for “turn left in 200 metres,” but useless when an autonomous car must decide which lane it’s in or whether it has 30 cm or 3 m of clearance from a parked truck.

Real‑world deployments prove the challenge. For example, while testing Moovita’s autonomous shuttles in Singapore, GPS signals bounced off tall buildings, creating errors so severe the shuttle sometimes thought it was on the wrong street. This is the urban canyon problem — exactly where autonomous vehicles need reliable localization the most.

This post explains why GPS fails in dense cities and how modern autonomous vehicles use layered localization architectures — combining HD maps, LiDAR, cameras, IMUs, and sensor fusion — to achieve the centimetre‑level accuracy that GPS alone cannot deliver.

The Physics of the Urban Canyon Problem

GPS (and the broader category of satellite positioning, GNSS) works by triangulating the vehicle’s position from timing signals received from multiple satellites simultaneously. This works extremely well with a clear, unobstructed view of the sky. It works very badly between tall buildings. This effect is well-documented in IEEE’s GNSS Multipath research, which identifies dense urban geometry as the primary driver of positioning error in commercial AV deployment.

Multipath propagation errors from surrounding infrastructure, as well as line-of-sight occlusion from tall buildings, tunnels, and bridges, can severely impact GPS localization accuracy. Without an effective global localization source, the location drifts quickly. Two distinct physical effects are responsible:

Signal occlusion happens when buildings physically block the line of sight to enough satellites that the receiver cannot get a reliable position fix — the same way you lose signal walking into a tunnel.

Multipath interference is more insidious: a GPS signal bounces off a glass office tower before reaching the receiver, arriving slightly delayed compared to the direct signal. The receiver, unable to distinguish the reflected signal from the direct one, computes a position based on a corrupted timing measurement — producing an error that looks like a confident, precise reading but is actually wrong by metres.

Why This Specifically Matters for Robotaxis

This is not an abstract engineering curiosity — it is precisely the operating environment where commercial robotaxi demand is concentrated. Dense downtown cores, financial districts, areas with tall buildings on both sides of the street: these are exactly the geographies with the worst GPS multipath and occlusion characteristics, and exactly where ride-hailing demand justifies commercial robotaxi deployment. The localization problem is not a corner case — it is the default operating condition for the highest-value AV use case. For the broader picture of why dense urban deployment remains the hardest unsolved problem in commercial AV rollout, see Why Self-Driving Cars Still Fail.

Part 2: HD Maps — Turning Localization Into a Matching Problem

The Core Insight

The most important conceptual shift in AV localization over the past decade has been this: instead of trying to make GPS more accurate, stop relying on GPS as the primary source of truth at all. Autonomous vehicles use HD maps as a reference framework, continuously comparing live sensor inputs against pre-mapped features to establish their precise location.

In practice, this means: before a vehicle ever operates autonomously on a given road, that road is mapped in advance — usually by a specially instrumented survey vehicle carrying high-grade LiDAR, cameras, and precision GNSS/IMU — producing a centimetre-accurate 3D representation including lane markings, curbs, traffic signs, and other fixed landmarks.

How Map-Matching Localization Works at Runtime

LiDAR scans, camera feeds, and radar signals are aligned with map data that includes lane markings, curbs, traffic signs, and other landmarks. This map-matching process corrects GPS drift and provides localization accuracy that GPS alone cannot deliver. By anchoring vehicle perception to known map features, the system maintains a stable and highly reliable position estimate.

The practical algorithm: as the vehicle drives, its live LiDAR point cloud is compared against the corresponding section of the pre-built HD map using point-cloud registration techniques (variants of Iterative Closest Point, or learned feature-matching approaches). The transformation required to align the live scan with the map directly gives you the vehicle’s precise position and orientation — independent of GPS entirely.

The Honest Limitation of HD Maps

I want to be direct about a real limitation here, because it’s one that cost real engineering hours at Moovita: HD maps as a reference framework require map generation, distribution, and — critically — continuous map update and maintenance, detecting real-world changes via crowdsourced or V2X-derived sensor streams. A construction barrier that appears the day after your map was surveyed is a map that’s now wrong in exactly the location where the vehicle most needs it to be right. This map staleness problem is the most underrated operational cost of any HD-map-dependent localization architecture, and any serious deployment plan must budget for continuous re-mapping, not a one-time survey.

Part 3: SLAM — Localizing Without Any Pre-Built Map

When You Don’t Have an HD Map (or GPS)

HD maps solve localization beautifully where they exist. But they don’t exist everywhere — a newly opened road, a temporary diversion, an underground car park, a tunnel. For these GPS-denied, map-denied situations, the fallback is SLAM: Simultaneous Localization and Mapping. For the full mathematical foundation of SLAM, including EKF-SLAM, Particle Filter SLAM, and Graph-Based SLAM with working Python code, see UDHY’s Autonomous Navigation and SLAM course.

To survive in a GPS-denied situation, additional active localization methods are required — by leveraging prior built maps such as 3D point clouds and distinctive visual features, LiDAR-based and visual-based SLAM methods can be used for localization, building the map and localizing within it at the same time, using only onboard sensors.

The Drift Problem and Loop Closure

SLAM has one fundamental, unavoidable weakness: drift. One of the critical issues of a SLAM algorithm is the accumulation of drift in the map and the estimate over time — every small error in matching consecutive sensor frames accumulates, so a SLAM system that’s been running for ten minutes without any external correction will have a position estimate that has wandered meaningfully from ground truth, even if it felt locally accurate the entire time.

The standard production fix is loop closure detection — most modern techniques rely on loop closure detection to correct this drift; when the vehicle revisits a location it has seen before, the system recognizes the match and uses it to retroactively correct the accumulated drift across the entire trajectory.

Particle Filter SLAM in Practice

Among various vehicle SLAM approaches, the Rao-Blackwellized particle filter (RBPF) stands out as one of the most widely adopted methods due to its efficient solution with logarithmic complexity relative to map size — RBPF approximates the posterior distribution of the vehicle’s pose using a set of Monte Carlo particles through sampling and importance weighting, essentially maintaining many simultaneous hypotheses of “where am I” and converging on the most consistent one as more sensor data arrives. This is the same FastSLAM approach compared against EKF-SLAM and Graph-Based SLAM in the algorithm comparison table in UDHY’s SLAM course. RBPF’s logarithmic complexity advantage was first formalized in the original FastSLAM paper, which remains the most-cited reference for this approach.

Part 4: Sensor Fusion for Localization — IMU, Wheel Odometry, and the Shift to Factor Graphs

Why IMU and Wheel Odometry Matter Even Though They Drift

A vehicle’s Inertial Measurement Unit (IMU) and wheel encoders provide continuous, high-frequency motion estimates — but they suffer from a different failure mode than GPS: drift. IMU propagation can compensate for GNSS signal outages, enabling continuous positioning and smoothing the trajectory during GNSS-denied periods, and wheel odometry provides high-frequency motion updates that enhance short-term accuracy and stability — but both accumulate error over time with no external correction, the inverse problem of GPS (which is noisy but doesn’t drift over time the same way).

The Architectural Shift: EKF to Factor Graph Optimization

For decades, the standard way to fuse GPS, IMU, and wheel odometry was the Extended Kalman Filter (EKF) — and using an EKF, engineers analyze velocity and position error resilience during GNSS interruptions, with well-documented drift behavior typical of MEMS-grade IMUs. The original Factor Graph formulation is described in Dellaert & Kaess’s foundational paper on factor graphs for robot perception, now the standard reference for this architectural shift.

The genuine architectural shift happening now is the move from EKF to Factor Graph Optimization (FGO) — FGO demonstrates superior accuracy during GNSS outages in urban canyons, because unlike an EKF (which only considers the current state and immediately preceding measurement), a factor graph can jointly optimize over a sliding window of past measurements simultaneously, allowing later information (like a loop closure) to retroactively correct earlier position estimates in a mathematically principled way.

Vision-Based Re-Localization Against Existing Maps

A newer technique worth understanding: rather than matching raw point clouds, MapLocNet leverages surround-view images and navigation maps, utilizing consecutive neural localization modules based on coarse-to-fine feature registration principles to achieve superior localization accuracy in challenging scenarios — essentially using a learned neural network to match what the cameras currently see against a lightweight navigation map (rather than a heavy point-cloud HD map), which is significantly cheaper to store and distribute at fleet scale. See the MapLocNet paper on arXiv for the full coarse-to-fine registration architecture.

Part 5: The Layered Architecture — How It All Fits Together in Production

No production autonomous vehicle relies on a single localization method. The real architecture is layered and runs continuously, fusing every available source weighted by real-time confidence:

Layer	Source	Update Rate	Strength	Weakness
Global	GNSS/GPS	1–10 Hz	Absolute position, no drift over time	Multipath, occlusion in urban canyons
Inertial	IMU	100–1000 Hz	High-frequency, works anywhere	Drifts without correction
Odometric	Wheel encoders	50–100 Hz	Reliable short-term motion estimate	Drifts, affected by wheel slip
Geometric	LiDAR SLAM / HD map matching	10–20 Hz	Centimetre precision, drift-corrected	Requires good map or loop closure
Visual	Camera-based re-localization	10–30 Hz	Lightweight map storage, semantic context	Lighting/weather sensitive
Fusion backbone	Factor Graph Optimization	Continuous	Combines all of the above optimally	Computationally heavier than EKF

This same layered confidence-weighting approach is what makes BEV sensor fusion and AV sensor fusion failure recovery possible — localization and perception both depend on knowing which sensor to trust right now. This is precisely the multi-layer redundancy philosophy I implemented at Moovita: when GPS confidence dropped (detected automatically via satellite count and dilution-of-precision metrics), the system automatically increased its reliance on LiDAR map-matching and IMU/odometry fusion — a graceful, continuous handoff rather than a binary “GPS works / GPS doesn’t work” switch.

Engineering Insights — What to Build Today

Build the confidence-weighting logic before you build the individual localization methods. Every localization source in this post has known, predictable failure conditions. A system that blindly trusts GPS until it catastrophically fails is far more dangerous than one that continuously estimates its own positional confidence and gracefully shifts weight toward more reliable sources as conditions change.

Don’t underestimate the operational cost of HD map freshness. Many teams treat HD mapping as a one-time engineering project. It is not. It is an ongoing operational commitment on the same order as fleet maintenance — budget accordingly, or your localization system will be confidently wrong the day after a road changes.

Factor Graph Optimization is worth the computational cost. If your team is still running EKF-based localization fusion in 2026, the superior accuracy of FGO during GNSS outages — precisely the conditions where localization failures cause real safety incidents — justifies the engineering investment to migrate. If you’re building toward a robotics engineering career, Controls & Localization is one of five tracks covered with real salary data in How to Become a Robotics Engineer.

Lessons Learned

GPS is a contributing sensor, never the sole source of truth. Every credible production localization architecture treats GPS as one weighted input among several, not a foundation.
The urban canyon problem is not an edge case — it’s the default operating environment for the highest-value robotaxi use case. Plan your localization architecture around dense urban geometry from day one, not as an afterthought.
Drift and noise are different problems requiring different fixes. GPS is noisy but doesn’t drift over time; IMU and wheel odometry drift but aren’t noisy in the same way. Understanding which failure mode you’re correcting for determines the right architecture.
Loop closure is what makes SLAM viable for sustained operation. Without it, drift accumulates without bound. With it, a vehicle that returns to a known location can correct its entire trajectory history.
Map freshness is an operational cost most teams underestimate. Budget for continuous HD map maintenance with the same seriousness you’d budget for fleet vehicle maintenance.

GPS‑Denied AV Localization FAQs: Urban Canyon Solutions 2026

1. Why doesn’t GPS work well for autonomous vehicles in cities?

GPS accuracy in dense urban environments is degraded by two physical effects: signal occlusion, where tall buildings block direct line-of-sight to enough satellites for a reliable fix, and multipath interference, where GPS signals reflect off buildings before reaching the receiver, creating confident-looking but inaccurate position readings. This is known as the “urban canyon problem,” and it occurs precisely in the dense downtown environments where robotaxi demand is highest, making GPS alone unsuitable as a primary localization source for autonomous vehicles.

2. What do autonomous vehicles use instead of GPS to know their location?

Production autonomous vehicles use a layered localization architecture combining HD map matching (comparing live LiDAR/camera data against a pre-surveyed centimetre-accurate map), LiDAR or visual SLAM (simultaneous localization and mapping using onboard sensors when no map is available), IMU and wheel odometry (for continuous short-term motion estimates), and GPS as one weighted input among several — fused together, typically via Factor Graph Optimization, rather than any single source being treated as ground truth.

3. What is SLAM and why is it needed if HD maps already exist?

SLAM (Simultaneous Localization and Mapping) allows a vehicle to determine its position using only onboard sensors, without depending on a pre-built map. It’s necessary because HD maps don’t cover every possible location a vehicle might need to operate — newly opened roads, temporary diversions, underground parking, and tunnels are all situations where SLAM serves as the fallback localization method.

4. What is Factor Graph Optimization and why is it replacing the Extended Kalman Filter in autonomous vehicles?

Factor Graph Optimization (FGO) is a sensor fusion technique that jointly optimizes a vehicle’s position estimate over a sliding window of past measurements simultaneously, rather than only considering the current state like an Extended Kalman Filter (EKF) does. This allows later information — such as a loop closure detection — to retroactively correct earlier position estimates. Research has demonstrated FGO’s superior accuracy during GNSS outages in urban canyons compared to traditional EKF approaches, making it the emerging production standard for 2026-era localization systems.

5. How accurate do autonomous vehicles need their localization to be?

Commercial autonomous vehicles typically require centimetre-level localization accuracy — sufficient to determine which lane the vehicle occupies and maintain safe clearance from nearby objects, parked vehicles, and curbs. Standard consumer GPS provides only 5–10 metre accuracy under good conditions, which is why HD map matching, LiDAR SLAM, and multi-sensor fusion are necessary to close the gap between consumer-grade satellite positioning and the precision Level 4 autonomy requires.

6. What happens when an autonomous vehicle loses GPS signal completely, such as in a tunnel?

When GPS becomes unavailable, the vehicle’s localization system shifts weight toward its other sources: IMU and wheel odometry provide continuous short-term motion estimates, while LiDAR or visual SLAM (if a map exists or can be built in real time) maintains a drift-corrected position estimate. This is a graceful, continuous handoff in well-engineered systems rather than a sudden loss of positioning capability — the system’s confidence in each source shifts automatically based on real-time signal quality metrics like satellite count and dilution of precision.

About the Author

Dr. Dilip Kumar Limbu Co-Founder, Moovita | Former Principal Scientist, A*STAR | PhD, Auckland University of Technology
Connect via LinkedIn Direct Inquiry.

Disclaimer
The views expressed here are personal and based on 25+ years in the industry, including my work at Moovita. They do not necessarily reflect the views of any organization.

Enjoying this post? Subscribe to get more AI insights.