Simultaneous Localization and Mapping

Chapter 7 explained how LiDAR works and what the scanner captures. Chapters 8 through 10 covered the practical pipeline: planning a survey, capturing the site, controlling the ground, and processing the scans. This chapter explains the computational engine that turns those raw scans into a point cloud: SLAM.

A raw scan is not a map. It is a pile of points in the scanner’s frame, tilted and offset by the vehicle’s motion. To turn it into a map, the sensor’s motion must be estimated. That is SLAM.

SLAM: the map and the pose, simultaneously

SLAM, Simultaneous Localization and Mapping, is the computational problem of building a map of an unknown environment while simultaneously tracking the sensor’s location within that map. It is the chicken-and-egg problem of mobile robotics, solved well enough in 2026 that most map builders do not need to think about it. But you do need to know what it guarantees and what it does not.

A SLAM system takes in sensor data, usually LiDAR scans with inertial measurements from an IMU, and produces two outputs: a point cloud registered into a single consistent frame, and a trajectory, the estimated path the sensor took through the environment.

The trajectory has drift. Over long distances, small errors in the pose estimate accumulate. A SLAM trajectory covering a kilometer might drift by 10 to 50 cm by the end. At Harbor Yard, 50 cm is the difference between a dock face that lines up and one that does not.

The standard fix is loop closure: when the sensor returns to a place it has already seen, the SLAM system recognizes the match and corrects the accumulated drift. A capture plan that includes deliberate loop closures, driving the vehicle back through the start point at the end of the route, produces a more accurate point cloud than a single linear pass.

Loop closure corrects drift after it accumulates. RTK prevents much of it from accumulating in the first place, and using it during capture is highly recommended. When the trajectory carries centimeter-grade position fixes along its whole length, the SLAM solve is constrained at every step, and the point cloud comes out more self-consistent: distances between far-apart features hold instead of sagging. The two work together. RTK loses fix under canopies, overhangs, and dense container stacks, and loop closure is what catches the drift those outages leave behind.

flowchart TD
    A["Sensor Data
    LiDAR · IMU · GNSS"] --> B["SLAM
    scan matching +
    pose estimation"]
    B --> C["Registered
    Point Cloud
    internally consistent"]
    C --> D["Georeferencing
    tie to ground
    control points"]
    D --> E["Usable Point Cloud
    ready for vectorization"]

    B -.->|"loop closure:
    recognize revisited
    places, correct drift"| B

From SLAM to a usable point cloud

Chapter 10 covered filtering, registration, and georeferencing in detail. The short version: SLAM produces an internally consistent point cloud. Registration aligns it with other scans. Filtering removes noise and artifacts. Georeferencing anchors it to known coordinates via ground control points. The result is a point cloud ready for vectorization.

Harbor Yard’s solve had both guards on it: the RTK-corrected trajectory that Chapter 9’s survey nail put on known coordinates, and the deliberate loop closures built into Chapter 8’s capture plan. The result: every lane centerline, every stop line, and every dock face in the Harbor Yard Lanelet2 map is accurate to within 5 cm of its true position. Whether that is good enough depends on what the vehicles on the site require. The required accuracy drives the capture method, not the other way around.

What comes next

The next chapter covers localization: how a robot uses the map you just built to determine its position, ten times per second, by matching what it sees against known landmarks.

Part IV then begins the next stage of the pipeline: Representation. How do we turn geometry into meaning?