GPS-Denied LiDAR SLAM: How Robots Navigate in Tunnels, Mines, and Indoor Spaces

GPS works—until it doesn't. Underground mines, long highway tunnels, the deep interior of distribution warehouses, urban canyons between high-rises: these are the environments where satellite signals disappear and robots must figure out where they are using only what they carry onboard. LiDAR SLAM (Simultaneous Localization and Mapping) has become the go-to solution for this problem. A 2025 IET survey on GPS-denied LiDAR-based SLAM identified it as the dominant approach for subsurface exploration, tunnel maintenance, and mining surveys, where neither standalone cameras nor inertial systems can sustain reliable navigation on their own.

This article breaks down which SLAM algorithms actually work in these environments, how different sensor fusion strategies change the accuracy ceiling, and what hardware characteristics matter when you're building a robot that needs to map a 2-kilometer mine tunnel without ever seeing a satellite.

Where GPS-Denied SLAM Actually Matters

The term "GPS-denied" covers more ground than most people assume. Here are the environments where LiDAR SLAM isn't optional—it's the only viable option.

Underground mining tunnels are the classic case. Hundreds of meters below the surface, ore transport vehicles and inspection robots navigate branching tunnel networks that stretch for kilometers. A 2025 case study on trackless transport vehicles in underground mines showed that LiDAR-based relative positioning achieved an 84% minimum success rate in autonomous driving within tunnels—but only when the SLAM system could maintain feature tracking along smooth, repetitive walls.

Highway and rail tunnels present a different challenge: long, straight corridors with consistent cross-sections. A LiDAR system that depends on geometric diversity for scan matching will struggle here because one section of tunnel looks nearly identical to the next 50 meters. Loop closure becomes the critical differentiator.

Large warehouses and logistics centers may have GPS coverage near loading docks, but once an AGV moves into the interior—between tall shelving racks that block signals—positioning shifts to SLAM. The challenge is less about drift (distances are shorter) and more about operating 24/7 with minimal computational overhead per unit.

Urban canyons in dense city centers can degrade GPS accuracy from meters to tens of meters due to multipath. LiDAR SLAM fills the gap, especially for low-speed delivery robots operating at street level between tall buildings.

6 GPS-Denied SLAM Algorithms Compared

Not all SLAM systems handle GPS-denied environments equally. The table below covers six widely deployed open-source options, evaluated on the metrics that matter when you can't fall back on GPS: loop closure, computational demand, and behavior in degenerate (geometrically poor) environments.

LIO-SAM: The Benchmark for Feature-Rich Environments

LIO-SAM (LiDAR Inertial Odometry via Smoothing and Mapping), released by Shan et al. in 2020, uses a factor graph with IMU preintegration and feature-based LiDAR scan matching. It includes a built-in loop closure module based on scan context descriptors and ICP refinement.

In environments with enough geometric diversity—junctions, equipment, uneven walls—LIO-SAM delivers consistent sub-decimeter accuracy over distances of 1–2 km. The factor graph structure means that when loop closure does detect a revisited location, the entire trajectory gets corrected backward, not just the local neighborhood.

The weakness shows up in long, feature-poor corridors. LIO-SAM's feature extraction relies on surface curvature to identify edge and planar points. In a smooth-bored mine tunnel with consistent cross-section, the feature set becomes sparse and repetitive. The system flags this via elevated covariance in the optimization, but it can't fix the underlying data scarcity. Computational demand sits in the moderate range: a 4-core CPU handles 10 Hz operation with a typical 16- or 32-channel LiDAR.

FAST-LIO2: Speed and Simplicity

FAST-LIO2 dropped the feature extraction step entirely. Instead of extracting edge and planar points, it registers raw point clouds directly against an incrementally built map using an Iterated Extended Kalman Filter (IESKF). An incremental k-d tree (ikd-tree) keeps map lookup fast even as the point cloud grows.

This direct approach puts FAST-LIO2 among the fastest LIO systems in widespread use—consistently real-time on a single CPU core with margin to spare. Published benchmarks show translational RMSE improvements over LIO-SAM, LILI-OM, and LINS at map sizes of 1,000–2,000 m on standard datasets.

The trade-off: no built-in loop closure. For GPS-denied environments where the robot covers long distances (multi-km tunnels), drift accumulates without correction. The IESKF does a good job propagating state through short LiDAR degradation windows using IMU alone, but it can't recover from systematic drift. A 2024 study on stacked cage farming environments found FAST-LIO2 achieving 12.8 cm APE at 0.2 m/s in single-aisle scenarios—good, but the error grew significantly in longer, more repetitive aisles.

Point-LIO: Per-Point Precision

Point-LIO, from the same HKU-MARS lab as FAST-LIO2, takes a different approach to the same problem. Instead of processing one scan at a time, it propagates and updates the state at each individual point's timestamp. This gives it an odometry update rate that matches the LiDAR's point sampling frequency, not just the scan rate.

The per-point approach helps in moderately degenerate environments because each point provides an independent observation. If part of a scan is in a geometrically useful area (a junction, a support pillar), those points get fully utilized rather than being diluted in a full-scan average.

However, Point-LIO shares FAST-LIO2's lack of loop closure, and in completely open, featureless environments (large empty chambers in mines), the per-point approach doesn't help because there are simply no useful geometric constraints. GitHub issues from users report that FAST-LIO2 sometimes outperforms Point-LIO in these specific degeneracy cases.

Cartographer: Grid-Based Reliability

Google's Cartographer takes a fundamentally different approach: it builds 2D or 3D occupancy grid submaps and uses branch-and-bound scan matching for both local and global (loop closure) optimization. Originally released in 2016, it remains widely used in industrial robotics.

Cartographer's strength in GPS-denied environments is its tolerance for moderate feature scarcity. The grid representation doesn't depend on extracting specific geometric features—it just needs enough point density to register submaps against each other. This makes it more forgiving in environments where feature extraction methods struggle.

The cost is computational. 3D Cartographer with 16-channel LiDAR data can consume significant CPU resources, and real-time performance depends heavily on submap size and resolution settings. A 2024 evaluation noted that Cartographer "fails to fully utilize the potential performance of each sensor" due to its loosely-coupled design—it doesn't tightly integrate IMU data into the optimization, which means motion degradation when environmental geometry is simple.

F-LOAM: Lightweight but Fragile

F-LOAM (Fast LiDAR Odometry and Mapping) optimizes the original LOAM pipeline for speed. It keeps the edge/plane feature extraction and point-to-edge/plane matching but removes the IMU dependency entirely.

On a capable CPU, F-LOAM runs faster than both LIO-SAM and FAST-LIO2 for pure odometry estimation. In environments with rich geometric features, it's competitive in accuracy.

Without an IMU, though, there's no fallback when LiDAR scan matching fails. In the long corridors and smooth tunnels common in GPS-denied applications, F-LOAM's performance degrades sharply. For these specific use cases, F-LOAM is generally not recommended unless paired with external loop closure.

KISS-ICP: The Minimalist Option

KISS-ICP (Keep It Simple, Straightforward) strips SLAM down to point-to-plane ICP with voxelized map representation. No feature extraction, no IMU integration, no complex parameters to tune. A single CPU core handles everything.

For quick prototyping and environments with decent geometric structure, KISS-ICP works well out of the box. Its minimal parameter set means less time spent tuning and more time deploying. It adapts well to different LiDAR sensors and scan patterns.

The limitation is the same as F-LOAM's: no IMU means no dead-reckoning bridge during scan matching failures, and no built-in loop closure means no drift correction. For short-range indoor environments (warehouses, shopping malls), this might be acceptable. For multi-km mine tunnels, it's insufficient on its own.

Sensor Fusion: Why LiDAR Alone Isn't Enough

The choice of SLAM algorithm matters, but sensor fusion strategy has an equal or greater impact on real-world GPS-denied performance. Here's how the three common fusion configurations compare.

Pure LiDAR (No IMU, No Wheel Odometry)

Algorithms like F-LOAM and KISS-ICP operate on LiDAR data alone. In feature-rich environments, this works. In GPS-denied applications, it's fragile.

Without IMU preintegration, the system has no way to estimate motion between scans when geometric features are temporarily absent. A robot passing through a featureless tunnel section for 3–5 seconds will experience uncorrected drift proportional to its speed. At 1 m/s, that's 3–5 meters of positioning uncertainty from a single gap.

LiDAR + IMU (Tightly Coupled)

This is the configuration used by LIO-SAM, FAST-LIO2, and Point-LIO, and it represents the current practical standard for GPS-denied navigation.

The IMU provides high-frequency (200–1000 Hz) orientation estimates that bridge LiDAR scan matching gaps. In a tightly-coupled system, IMU measurements contribute residuals to the same optimization as LiDAR correspondences—both are estimated jointly rather than separately.

Accuracy in GPS-denied environments typically falls in the 0.1–0.5% of distance traveled for LiDAR+IMU systems in moderate environments. A 2025 study on LiDAR-inertial-wheel odometry found that adding IMU to LiDAR-only SLAM improved rotation estimation by approximately 26% in indoor environments.

The boundary condition: IMU bias drift. Consumer-grade MEMS IMUs (common in robotics) accumulate orientation error at roughly 0.1–1°/minute. Over a 30-minute mine inspection run, that's 3–30° of accumulated error. The LiDAR needs to provide correction updates frequently enough to keep IMU bias in check—typically every few seconds in geometrically rich areas, or every few meters of travel.

LiDAR + IMU + Wheel Odometry

Adding wheel encoders creates a three-sensor fusion chain that works especially well for ground robots. The 2025 Nature paper on multimodal SLAM for underground coal mines demonstrated this exact configuration: a tightly-coupled LiDAR-inertial-wheel odometry frontend with multi-factor graph optimization backend.

Wheel odometry provides a direct measurement of ground truth motion (assuming no wheel slip), which gives the system an independent constraint that doesn't depend on environmental geometry at all. For slow-moving indoor robots with frequent stops and starts, wheel odometry actually outperforms IMU because it doesn't accumulate error during stationary periods.

The accuracy ceiling for LiDAR+IMU+wheel fusion in GPS-denied environments reaches 0.05–0.2% of distance traveled—roughly 2× better than LiDAR+IMU alone, and 5–10× better than pure LiDAR.

The limitation: wheel slip on uneven or loose surfaces (gravel in mines, wet warehouse floors) can introduce sudden large errors. Systems that include wheel odometry need slip detection logic to de-weight encoder measurements when they disagree with the IMU/LiDAR estimate.

Non-Repetitive Scanning in Feature-Sparse GPS-Denied Environments

Most multi-beam LiDARs use a repetitive scanning pattern—each rotation of the motor produces the same angular pattern. If the environment lacks features at those specific angles, the sensor simply doesn't see them, no matter how long it scans.

Non-repetitive scanning LiDARs like the Livox M360 change this equation. The M360 uses a prism-based optical design where each rotation produces a different angular pattern. Over time (typically 0.5–1 second), the accumulated point cloud fills in the 70° vertical × 360° horizontal FOV much more evenly than a repetitive scanner would.

In GPS-denied environments, this matters because the geometric features available are often sparse and directionally specific. A mine tunnel might have support ribs every 2 meters on one side and a smooth wall on the other. A repetitive scanner that happens to undersample the rib side in a given rotation gets poor feature coverage for that scan. The M360's non-repetitive pattern accumulates rib geometry across multiple rotation patterns, building better feature coverage in the same time window.

The 200 kHz point rate compounds this advantage. More points per second means denser coverage in less time, which translates to finer geometric detail in the accumulated cloud. For SLAM algorithms that depend on point density for scan matching (FAST-LIO2, KISS-ICP), higher point rates directly improve matching accuracy. The M360's ≤2 cm ranging precision at 10m means those additional points carry reliable distance information, not just noise.

The IP67 rating and <4.5W power consumption make the M360 practical for the harsh conditions common in GPS-denied applications: dust-laden mine tunnels, humid underground infrastructure, outdoor tunnels with water ingress. At 408 g, it's light enough for small inspection robots and UAVs where payload is limited.

Real-World Deployments

Mining: Autonomous Ore Transport

Underground mines in Australia, Canada, and China have been deploying LiDAR-based autonomous vehicles for ore transport since the early 2020s. The DARPA SubT Challenge (2019–2021) accelerated development of GPS-denied SLAM systems specifically for underground environments, and commercial deployments followed.

One MDPI case study from 2025 described LiDAR-based relative positioning within mine tunnels achieving 84% minimum success rate for autonomous driving. The failure cases clustered at tunnel junctions and turning points—exactly where geometric complexity increases but also where feature ambiguity can confuse the SLAM system.

The multimodal SLAM approach (LiDAR + IMU + wheel odometry) described in the 2025 Nature paper represents the current state of practice for mining. Their system was designed specifically for large-scale autonomous navigation in underground coal mines, with a tightly-coupled frontend and multi-factor optimization backend handling the long, branching tunnel networks typical of Chinese coal operations.

Tunnel Inspection: Wall Condition and Clearance Mapping

Railway and highway tunnel inspection has shifted from manual measurement to robotic LiDAR scanning. Robots equipped with LiDAR map the tunnel interior at walking or driving speed, producing 3D point clouds that engineers use to detect deformation, water ingress, and clearance violations.

In these applications, the challenge is less about navigation accuracy (the robot follows a known path) and more about mapping consistency. A tunnel inspection run might cover 5–10 km in a single session. Without loop closure, point cloud drift can make the far end of the tunnel appear shifted by meters relative to the start—unacceptable for deformation monitoring where millimeter-level changes need to be detected across months.

This is where LIO-SAM's built-in loop closure or FAST-LIO2 paired with an external loop closure module (like Scan Context) becomes critical. The loop closure detects when the robot has returned to a previously mapped section (e.g., after a U-turn at the tunnel end) and corrects the accumulated drift.

Warehouse AGV: High-Density Indoor Navigation

Large logistics warehouses (Amazon, JD.com, and their third-party logistics partners) operate fleets of hundreds to thousands of AGVs that navigate between tall shelving racks. GPS is unavailable inside, and RFID/reflector-based systems require physical infrastructure installation.

LiDAR SLAM provides infrastructure-free navigation. The 2D LiDAR + SLAM approach has been the industry standard for warehouse AGVs for nearly a decade, but 3D LiDAR is increasingly replacing 2D as costs drop and the need for multi-level navigation (mezzanines, loading ramps) grows.

For warehouse AGVs, the priority is computational efficiency over maximum accuracy. The robot needs to localize within 2–5 cm at speeds of 1–2 m/s, using minimal onboard compute so that the main processor can handle path planning and fleet coordination. FAST-LIO2's single-core efficiency makes it a strong candidate here, especially when the operating area is limited enough that drift without loop closure stays within acceptable bounds.

Choosing the Right Stack for GPS-Denied Navigation

There's no single "best" SLAM algorithm for GPS-denied environments. The right choice depends on your specific constraints.

For short-range indoor environments (warehouses, shopping malls, office buildings under 500m of travel): FAST-LIO2 or Cartographer. Fast, low compute, and drift stays manageable.

For long-range tunnel/corridor environments (mines, highways, rail tunnels over 1 km): LIO-SAM with its built-in loop closure, or FAST-LIO2 + external loop closure module. The ability to close loops at tunnel entrances or U-turns is non-negotiable.

For rapid prototyping or sensor evaluation: KISS-ICP. Minimal setup, works with any LiDAR, no parameters to tune.

For maximum accuracy with available sensors: LiDAR + IMU + wheel odometry fusion. The 2025 underground mining results show this triple-fusion approach reaching 0.05–0.2% distance accuracy—good enough for most commercial autonomous navigation applications.

For feature-sparse environments (smooth-bored tunnels, large open chambers): prioritize non-repetitive scanning LiDAR hardware (like the M360) to maximize geometric feature coverage, and pair it with a tightly-coupled LIO algorithm. The hardware contribution to SLAM quality in these environments is often larger than the algorithm contribution.

All M360 specifications referenced in this article are based on the M360(-D) User Manual Ver 1.4 (2026-02-27). For deployment-specific guidance, contact our engineering team or see the M360 vs MID-360 comparison.