This is the operational companion to our SLAM selection framework. That article covers which algorithm family to choose. This one covers what happens after you have chosen: how to map, how to run the route day after day, how to know when the robot's position estimate is lying to you, and what the platform should do about it.
Map once, localize forever
The single highest-leverage decision in a GPS-denied deployment is to stop treating SLAM as a runtime activity. Map the environment once, with a survey-grade rig and as much time as it takes; then run localization-only during operations. The reasons are practical, not academic:
- Comparability. Thermal readings and gauge inspections are only comparable run to run if the robot is at the same pose each time. Live SLAM gives you a slightly different trajectory every run; localization against a fixed prior map does not.
- Predictable failure. Localization against a prior map degrades in ways you can characterise in advance, because the map is known. Live SLAM degrades depending on what the corridor looks like today — wet floor, parked equipment, a contractor's scaffolding.
- Compute headroom. Localization-only frees the compute budget for the perception tasks that actually produce the deliverable: defect detection, thermal analysis, OCR on gauges.
The cost is the mapping exercise itself. In a large facility this is a real project — measured in days, not hours — and it should be scheduled as such rather than absorbed into a commissioning week.
Three environments, three mapping strategies
| Environment | Mapping approach | Localization during operations |
|---|---|---|
| Long straight tunnel / gallery (mine drifts, rail tunnels, cable tunnels) | Walk the corridor with a survey rig, closing loops only where cross-passages allow. Accept a longer mapping campaign; geometry is unhelpful. | Lidar-IMU localization against prior map, with a rail- or wall-following odometric term to suppress longitudinal drift. Consider fiducials at fixed intervals. |
| Cluttered indoor plant / substation interior | Room-by-room mapping with loop closures. Textured geometry makes this fast and accurate. | Lidar-IMU localization; visual features as a secondary check. This is the easiest GPS-denied case. |
| Open refinery or tank farm (physically open, but GNSS-unreliable due to multipath and shielding) | Map during a quiet period; record the skyline signature at the same time. | Lidar-IMU primary; GNSS used opportunistically as a soft constraint when the sky view is good, never as the sole source. |
Localization confidence is a number you must instrument
Every localization stack produces some internal confidence or covariance estimate. Most deployments ignore it and only look at the pose. That is the mistake. The confidence signal is what lets you distinguish three very different situations:
- Confident and correct. Normal operation.
- Unconfident and correct. Common in feature-poor stretches; the pose is fine but the system cannot prove it. Acceptable if it recovers once the corridor becomes informative.
- Confident and wrong. The dangerous case. This is what produces reports with plausible thermal readings recorded at the wrong asset. It typically arises from repetitive geometry — identical tunnel segments, identical pipe racks — where the localizer matches against the wrong instance.
Case 3 is the one to design against, and the only reliable defence is structural: make the route geometrically distinguishable, or add fiducials, or require a confirmed re-localization event at known checkpoints. Software alone will not save you here, because the system's own confidence metric is what is wrong.
The stop-and-flag rule
Our default behaviour when localization confidence drops below threshold is to stop, mark the position in the report, and wait for operator input. Not return-to-home, not continue on dead reckoning, not interpolate.
The reasoning: in an inspection deployment, a robot that stops is an inconvenience, but a robot that keeps walking while lost produces a report that a maintenance team will act on. In a hazardous-area or nuclear context that is a safety issue, and in any context it destroys trust in the system the first time someone checks a flagged defect against reality and finds the robot was 30 m away.
Return-to-home sounds friendlier, and is fine in a warehouse. In a tunnel it means the robot traverses the full length of the corridor while lost, which is exactly when it is most likely to collide with something or wander into a live area.
What degrades in the field, and what to monitor
- Wet floors. Lidar returns from standing water are inconsistent, and the ground plane becomes unreliable. Watch the vertical pose variance; if it drifts, the floor model is failing.
- Temporary obstructions. Scaffolding, parked equipment and contractor materials change the map. The localizer will handle some of this; a sustained increase in match residual means the prior map needs updating.
- Dust and condensate on the sensor window. A gradual, silent degradation in range returns. This is a maintenance item with a fixed interval, not something to leave to the operator's judgement.
- Thermal camera window contamination. The effect is a slow shift in apparent temperature, not a hard failure. Compare against a reference target where possible.
- Battery-endurance drift. Cold and dust reduce real endurance below the datasheet number. If your route planning assumes the datasheet, the robot will stop short of the last inspection point, which looks like a localization failure and is not.
Commissioning checklist
- Map the full operational envelope, including the routes you will only occasionally use.
- Establish a repeatability baseline: run the same 200 m three times and compare pose at fixed gauge points. Record the number.
- Deliberately test the failure path — obstruct a corridor, wet the floor, and confirm the platform stops and flags rather than continuing.
- Calibrate the thermal channel against a known reference and record the offset.
- Define the map-update procedure and who owns it. This is the single most commonly orphaned responsibility in a deployment.
If you are planning a deployment in a GPS-denied environment, our pages on mining and tunnel inspection and power-grid inspection cover the platform configurations we build for each case. Send us the environment description and we will give you an honest read on feasibility, including when the answer is that a legged platform is not the right tool.