GNSS-based localization — GPS, GLONASS, BeiDou — is remarkable technology for outdoor applications. In open sky, modern RTK-corrected GNSS reaches 2–5cm accuracy. For vehicles operating on highways between cities, this is genuinely sufficient for most localization needs. For the environments where most commercially relevant autonomous robots actually operate — multi-story parking garages, container port terminals, warehouse interiors, underground loading docks — GNSS is either unavailable or degrades to meter-level accuracy, which is not lane-level.
Lane-level accuracy is typically defined as lateral position error under 30cm relative to the lane centerline. For a delivery robot navigating a pedestrian corridor, it's approximately 10cm relative to a mapped path. For a warehouse AMR holding position in a pick aisle, it's approximately 5cm relative to a mapped rack face. None of these requirements are achievable with standard GNSS in enclosed environments.
This post explains how PathVynt's localization module achieves these accuracy requirements using LiDAR-based feature extraction and keyframe map matching, without relying on GNSS at any point.
Map-relative localization: the basic concept
Map-relative localization answers the question: given a sensor observation (a LiDAR scan) and a pre-built map, what is the most likely 6-DOF pose from which this observation was taken? The map is built in a one-time survey drive. During the survey, LiDAR scans are recorded, features are extracted, and a compact keyframe database is built that captures the geometric structure of the environment at a series of poses along the survey route.
During operation, the robot collects a LiDAR scan and matches features against the keyframe database. The matched keyframe gives a coarse pose estimate; refinement using iterative closest point (ICP) or its variants tightens this to the final pose estimate. A particle filter propagates the pose estimate forward between keyframe matches, using wheel odometry or IMU integration as the motion model.
PathVynt's map format (.pvmap) stores edge features and planar features extracted from the LOAM decomposition of each keyframe scan. Edge features (high-curvature points: rack uprights, column edges, doorframe corners) and planar features (low-curvature regions: walls, floors, large flat surfaces) are stored as separate point clouds in a compact binary format. A typical warehouse corridor map runs 2–6MB per 100m of corridor depending on feature density.
The occlusion problem
The most consistent failure mode in map-relative localization is feature occlusion: a dynamic obstacle (forklift, pedestrian, pallet stack) blocks the robot's line-of-sight to the features it normally uses for localization. If 60% of the wall features in a corridor are occluded by a stopped truck, the keyframe match becomes unreliable.
PathVynt handles this through angular sector masking during feature extraction. Before matching against the keyframe database, the feature extraction step identifies angular sectors of the LiDAR scan that are dominated by a tracked dynamic obstacle — specifically, sectors where the nearest return is clearly closer than the mapped environment and where the return intensity suggests a moving object. These sectors are masked out before feature extraction. The remaining sectors are matched against the keyframe, providing a pose estimate from the visible subset of features.
This masking approach maintains lane-level accuracy up to approximately 70% sector occlusion in structured environments. Beyond that threshold, the module enters a degraded mode: the particle filter continues propagating using odometry only, the pose estimate confidence is flagged as LOW, and your planner receives a wider uncertainty bound on the reported pose. The robot doesn't stop — it continues navigating with an inflated safety margin until enough features are visible to re-converge.
Keyframe map updates without re-survey
Warehouse environments are not static. Rack configurations change on seasonal cycles. A new conveyor belt installation blocks a previously mapped corridor. A permanent dividing wall is added to a previously open area. If your localization system requires a complete re-survey every time the environment changes, the operational cost of maintaining the map becomes prohibitive for warehouses with regular reconfiguration cycles.
PathVynt supports partial map updates: you drive the robot through only the changed zones, collect new keyframes, and the patcher updates only the affected portion of the .pvmap file. Unchanged keyframes are preserved. The update is propagated as a differential file that can be distributed to the fleet over the network without requiring each robot to reload the full map.
The patcher identifies affected keyframes using a spatial index of the existing map — any keyframe whose visibility frustum overlaps the changed zone is flagged for replacement. The patching process takes 2–5 minutes for typical zone changes in a 10,000m² warehouse. The updated map is validated against the survey data before distribution; a compatibility score is included in the map metadata that downstream robots can check before accepting the update.
Performance in GPS-denied mixed environments
Container port terminals are a particularly challenging environment: outdoor spaces with variable sky conditions, dense steel structures, and dynamic container stacks that fundamentally change the geometric structure of the environment day to day. GNSS is available in open yard areas but unreliable under crane booms and between dense container rows.
The PathVynt approach for this environment: use a hybrid localization mode. In open yard areas with good GNSS signal, the GNSS position is fused with the LiDAR-based pose estimate using a loose-coupling model — GNSS provides a global position anchor while LiDAR provides the fine-grained accuracy and handles GNSS dropout gracefully. When GNSS drops (under crane booms, between container rows), the LiDAR-only mode takes over transparently, and the particle filter maintains continuity using the last good GNSS-anchored pose as its prior.
In our measurements on a 400m container terminal access road with intermittent GNSS coverage (approximately 35% of the route had signal dropout), the hybrid mode maintained sub-20cm lateral accuracy throughout. The pure-GNSS baseline degraded to 1.8m lateral error during the dropout segments. The LiDAR-only baseline during the open segments had approximately 8cm lateral error — better than even the RTK-corrected GNSS, because the mapped environment provides reference features at meter-level density while satellite geometry is always finite.
For teams deploying in partially-covered outdoor environments: set LocalizationConfig.mode = HYBRID_GNSS_LIDAR and configure gnss_confidence_threshold = 0.85. Below this GNSS confidence score, the localization engine weights the LiDAR estimate exclusively. This threshold can be tuned per-deployment based on the local satellite environment.
What map-relative localization does not give you
Map-relative localization is not a substitute for SLAM in unmapped environments. If your robot encounters a corridor it has never surveyed, it cannot localize within it — the keyframe database has no entries for that area. PathVynt's localization module will flag a NO_MAP_COVERAGE status and the robot must either stop, request a survey drive, or operate in a pure-odometry fallback mode with explicit acknowledgment of degraded accuracy.
Building the initial map is a real cost. A thorough survey of a 5,000m² warehouse takes 1–2 hours of robot time and produces a map that needs validation before operational deployment. We've built tooling to make this faster, but it cannot be avoided entirely. If you're evaluating PathVynt for an environment where you cannot or will not do a survey drive, map-relative localization is not the right tool. For those cases, we recommend looking at SLAM approaches — though with the caveat that online SLAM at lane-level accuracy in dynamic environments remains an open research problem, and commercial implementations make significant compromises.
