SLAM and robot localization

Three problems that get conflated

Three distinct questions hide under one acronym, and treating them as one is the source of a great deal of confused procurement.

• Mapping. You know where the robot is and you want a map. Comparatively easy, and it is what a survey run does.
• Localization. You have a map and you want to know where the robot is in it. This is the problem most deployed robots actually solve, most of the time.
• SLAM. You have neither, and must build the map while locating yourself in the map you are building. Circular by construction, which is what makes it interesting.

Most commercial systems do SLAM once, during commissioning, to produce a map — and then run localization against that map every day afterwards. The daily problem is localization. Understanding that the hard operational question is "does the map still match the building" rather than "can it do SLAM" changes what you ask a vendor.

Sensor families

Lidar. Direct range measurement, largely indifferent to lighting, geometrically precise. Two-dimensional scanning lidar remains the workhorse of indoor mobile robots; three-dimensional lidar is standard outdoors and increasingly common inside. Expensive relative to cameras, and it sees geometry rather than appearance, which is exactly its strength and exactly its weakness.

Cameras. Cheap, rich, and dependent on light and texture. Visual SLAM extracts features or tracks pixels across frames. It fails on blank walls and in the dark, and it cannot recover absolute scale from a single camera.

Visual-inertial. A camera plus an inertial measurement unit. The IMU supplies high-rate motion and resolves the scale ambiguity; the camera corrects the drift the IMU accumulates within seconds. The combination is far stronger than either alone and underpins most modern tracking, including what is inside a headset.

RGB-D. A camera that also returns per-pixel depth. Convenient indoors at short range, and defeated by sunlight, by glass, by dark and shiny surfaces, and by anything beyond a few metres.

Wheel odometry. Integrating wheel rotation. Free, available at high rate, and drifting without bound — and badly wrong the moment a wheel slips. Always a supporting input, never a primary one.

Satellite positioning. Outdoors only, and much better with corrections. Useless indoors and unreliable in urban canyons and under cover.

Nearly every real system fuses several of these, because each one's failure mode is covered by another's strength.

How a SLAM system is built

Most implementations separate into two halves. The front end turns raw sensor data into relative motion estimates and into constraints — matching one scan to the next, tracking features between frames, recognising a place seen before. The back end takes those constraints and solves for a globally consistent set of poses and landmarks, typically by minimising error over a factor graph.

The part that makes the whole thing work is loop closure. Any incremental estimate drifts. When the robot recognises that it has returned to somewhere it has been, that recognition becomes a constraint which lets the back end redistribute accumulated error across the whole trajectory, snapping the map into consistency. Without it a map of a large building slowly shears.

Loop closure is also the most dangerous component, because a false loop closure — deciding that two different places are the same place — corrupts the entire map, and does so irreversibly. Identical corridors, repeated shelving bays and symmetric layouts are exactly the environments where this happens, and exactly the environments robots are deployed in.

Systems worth knowing by name

Cartographer, from Google, for two- and three-dimensional lidar SLAM. ORB-SLAM3 as the long-standing reference for feature-based visual and visual-inertial SLAM. RTAB-Map for appearance-based mapping with strong ROS integration and practical loop closure. LIO-SAM and FAST-LIO2 for tightly coupled lidar-inertial odometry, which is where most of the recent practical gains have come from. VINS-Fusion in the visual-inertial line.

More recent work builds maps out of neural radiance fields or Gaussian splats rather than points and landmarks, producing reconstructions of striking visual quality. Whether that becomes the basis of production localization or stays a reconstruction technique is not yet settled, and anyone telling you confidently either way is guessing.

Where it breaks

These are the failures that decide deployments, and none of them show up in a demonstration.

• Featureless geometry. A long blank corridor gives a lidar nothing to fix position along its length. The robot knows precisely where it is across the corridor and drifts along it.
• Repetition. Identical aisles are the classic trigger for false loop closure, and warehouses are built out of identical aisles.
• Dynamic environments. The map records a building; the building contains people, pallets, parked trolleys and a different stack of boxes every morning. A system that treats everything it sees as structure will fight the map all day.
• Glass and mirrors. Lidar passes through glass and reflects off mirrors. Both produce confident, wrong measurements, which is worse than no measurement.
• The kidnapped robot. Someone picks the robot up and puts it somewhere else, or it boots in an unknown place. Recovering global position from nothing is a different and harder problem than tracking, and many systems that track beautifully recover badly.
• Map decay. The building changes. Shelving moves, a wall goes up, a seasonal display appears. The map silently stops matching, performance degrades over weeks, and the cause is invisible unless someone is monitoring for it.

The operational questions

Map maintenance is the cost nobody quotes. Who re-surveys, how often, what triggers it, how long the robot is out of service while it happens, and whether that is included in the price. For a fleet, add: are maps shared between robots, what happens when one robot's updated map disagrees with another's, and who adjudicates.

Then reliability arithmetic. A localization system that recovers correctly ninety-nine per cent of the time sounds excellent and is not. Ten robots running two hundred missions a day produce twenty failures daily — each one a stopped robot, a blocked aisle and somebody walking over. The guide on fleet management covers what that arithmetic does to an operation.

The right question for a vendor is not whether localization works. It is what happens when it does not: does the robot stop safely and ask for help, or does it proceed confidently in the wrong place.

What commissioning actually involves

The survey run is the part everybody underestimates. Somebody drives or walks the robot through the whole operating area while the SLAM system builds the map, and the quality of that half-day determines the quality of every mission for the next two years.

It goes wrong in predictable ways. Driving too fast degrades scan matching. Missing a loop means the drift never gets corrected. Surveying while the space is unusually empty produces a map of a building that does not exist during working hours. Surveying while it is unusually full bakes transient obstacles into the structure. And the map almost always needs manual editing afterwards — removing people who were captured as walls, marking keep-out zones, annotating doorways and charging positions.

Budget a proper window for it, do it when the space looks like it normally looks, and treat the map as a reviewed artefact rather than an automatic output.

What to put in a specification

If you are writing requirements rather than reading marketing, these are the clauses that separate systems.

• Localization accuracy, stated with a confidence and a condition. "Within a stated tolerance, ninety-nine point nine per cent of the time, in the environment as surveyed" is a requirement. A single centimetre figure is a number.
• Recovery behaviour. What the robot does when confidence drops below threshold, how long it attempts recovery, and who it tells.
• Relocalization time from cold start, including from an unknown position.
• Map update procedure: who performs it, how long the area is out of service, and whether a partial update is possible or the whole area must be re-surveyed.
• Degradation disclosure. Which environmental changes invalidate the map, stated by the vendor in advance rather than discovered by you.
• Logging. Whether a localization failure is recorded with enough context to diagnose it afterwards, or whether you get a stopped robot and no explanation.

That last one decides whether month three is a debugging exercise or a guessing exercise.