SLAM and mapping

A robot vacuum starts in the middle of a living room it has never seen. It has no floor plan and no marker on a wall telling it where it stands. Within a few minutes it has both: a map of the rooms it can reach and a steady sense of where it sits on that map. It builds the map and finds itself on the map at the same time. That combined trick is SLAM.

What SLAM produces

SLAM stands for Simultaneous Localization And Mapping. The two halves name the two outputs:

  • A map. A machine-readable model of the space, commonly an occupancy grid (a top-down grid where each cell is marked free, occupied, or unknown) or a point cloud (a set of 3D points sampled from surfaces the sensors saw).
  • A live pose. The robot’s current position and orientation within that map, updated continuously as it moves.

The word simultaneous carries the whole idea. Mapping and localization each depend on the other, which looks like a chicken-and-egg problem: to place a new wall on the map, the robot needs to know where it was standing when it saw the wall; to know where it is standing, it needs a map to compare its view against. SLAM breaks the loop by solving both together. Each new sensor reading nudges the map and the pose estimate at the same time, and the two converge as the robot explores. This is what separates SLAM from plain localization: localization answers where am I against a map that already exists, while SLAM produces the map and the answer together.

What hardware SLAM requires

SLAM works by matching what the robot senses now against what it sensed a moment ago and against the map so far. That matching needs sensors that measure the shape of the surroundings, plus a rough guess of how the robot moved between readings:

  • A ranging sensor that reports distances to surrounding surfaces. A spinning LIDAR sweeps a plane and returns distance at each angle; a depth camera reports distance per pixel across its field of view. Either gives the geometry that becomes the map.
  • Odometry, a rough estimate of motion from wheel encoders or an inertial sensor. This seeds each match with a starting guess (“I probably moved forward about 20 cm”), which the ranging data then corrects.

A plain color camera with no depth, or a bare GPS receiver, does not supply the per-surface geometry SLAM relies on, so a supported ranging sensor is the core requirement.

Two modes: map live or localize against a prebuilt map

SLAM on a Viam machine runs as a SLAM service (a module paired with a supported ranging sensor). You configure it in one of two modes, and the right choice depends on whether the space is already mapped and how stable it is.

Map live. The robot builds a fresh map as it drives and localizes against that growing map in real time. Choose this when the space is unknown, when it changes often enough that a saved map would go stale, or when you are creating a map to save and reuse later. The cost is compute and time: the robot is doing the full simultaneous problem on every reading.

Localize against a prebuilt map. You supply a map captured earlier, and the service only estimates the pose against it, the mapping half is already done. Choose this when the environment is stable (a warehouse, a fixed building) and you want lower compute, faster startup, and repeatable behavior across runs. The trade-off is that the map is a snapshot: if the space is rearranged, the robot’s matches degrade until you remap.

A common pattern combines them: map the space live once, save that map, then run in localize-only mode for day-to-day operation and remap when the layout changes.

Because these are configuration choices on the SLAM service rather than separate components, you can switch modes by changing the service configuration. For the configuration shape and supported sensors of a specific implementation, see the SLAM modules in the Viam Registry and How a robot knows its position.

How the map feeds navigation

The map and pose are inputs, not the goal. Once SLAM reports where the robot is on a map, navigation can plan a route across that map to a destination and drive the base there, steering around the obstacles the map records. That handoff, from “where am I on the map” to “drive me to that spot”, is covered in Navigate a mobile base to a goal.

Next steps