Section 29.4: Mapping and occupancy grids

"A grid cell is a decision about where the robot may spend risk."

A Loop Closure That Came Back With Receipts
Educational illustration for Section 29.4, showing mapping and occupancy grids as a robot reasoning problem that connects measurements, state estimates, decisions, and replayable evidence.
Figure 29.4.1: Mapping and occupancy grids becomes useful when the visual idea is tied to a state variable, an uncertainty model, and the next robot action.
Big Picture

Mapping and occupancy grids is the state-estimation half of embodied autonomy. The robot has partial, noisy, time-stamped evidence; it must turn that evidence into a pose, a map, and an uncertainty statement that a planner can actually trust.

Problem First

A robot map is a probabilistic memory of what sensor rays have implied. Free space, occupied space, and unknown space must stay distinct because a planner should treat unseen cells differently from cells observed as empty.

Occupancy grids update each cell through inverse sensor models, often using log odds for numerical stability. A range ray decreases occupancy probability along free cells and increases it near the measured endpoint. The map is therefore a belief field, not a bitmap.

Action Contract

A map result is incomplete without resolution, frame, timestamp, update rule, decay policy, inflation radius, and the planner layer that reads it. A clean map image does not prove safe traversability.

Formal Model

For occupancy grids, the posterior is a cell-wise belief over free, occupied, and unknown space conditioned on sensor rays and robot pose. The planner consumes inflation, freshness, and uncertainty, not only a black-and-white bitmap.

$$ L_t(c)=L_{t-1}(c)+\log\frac{p(c\mid z_t,x_t)}{1-p(c\mid z_t,x_t)}-L_0(c) $$

The evidence terms are inverse sensor model, ray casting, pose uncertainty, update rate, decay policy, and map resolution. Each one changes whether a cell is safe to traverse or only looks safe in a stale grid.

Algorithm: Section 29.4 Evidence Loop
  1. Transform each sensor ray into the map frame.
  2. Mark traversed cells as free evidence and endpoint cells as occupied evidence.
  3. Update log odds, then clamp values to avoid irreversible certainty.
  4. Publish costmap layers that keep unknown, lethal, inflated, and traversable cells separate.

Worked Diagnostic

Code Fragment 1 is the occupancy update smoke test: one ray should clear free cells, mark an endpoint, and leave unseen space unknown. If that invariant fails, larger maps will fail quietly.

# Apply log-odds updates for free and occupied evidence.
# The probabilities show how repeated rays change a grid cell belief.
import math

def sigmoid(x):
    return 1.0 / (1.0 + math.exp(-x))

log_odds = 0.0
for update in [-0.4, -0.4, 0.9]:
    log_odds += update
    print(f"log_odds={log_odds:.1f}, p_occ={sigmoid(log_odds):.2f}")
log_odds=-0.4, p_occ=0.40 log_odds=-0.8, p_occ=0.31 log_odds=0.1, p_occ=0.52

Expected output interpretation. The first two updates make the cell increasingly likely to be free, then the occupied endpoint evidence pushes it back toward uncertainty. The final value near 0.5 is exactly the interpretation to watch for: the map has conflicting evidence, so a cautious planner should not treat this cell as confidently traversable.

Code Fragment 1: The log-odds trace shows two free-space updates followed by one occupied endpoint update. The cell moves gradually because mapping should accumulate evidence rather than flip certainty after a single ray.

Tool Workflow

Library Shortcut

Nav2 costmaps, OctoMap, Voxblox-style volumetric maps, and Open3D point-cloud processing turn this update idea into maintained map layers and visualization workflows. The library path handles ray tracing, inflation, serialization, and map publication.

Use the hand grid update as a regression test, then use OctoMap, costmap_2d, Voxblox, or Nav2 layers for scale. The production tool is allowed to be complex; the occupancy invariant should remain simple.

Failure Mode To Test

Replay with moving people, reflective surfaces, stale cells, wrong sensor height, and delayed pose updates as separate cases. The label should separate map aging from sensor misclassification and localization-induced smear.

Practical Example

A warehouse mapping log should store raw scans, robot pose, occupancy probabilities, inflation layer, obstacle decay state, planner cost, and recovery action. That single replay explains whether a blocked route was a map problem or a planner choice.

Research Frontier

Mapping research is moving toward hybrid metric, semantic, and neural maps. The key embodied question is how those richer maps expose conservative, inspectable costs to planners rather than only attractive reconstructions.

Memory Hook

A grid cell is a decision about where the robot may spend risk.

Self Check

Can you state the state variables, observation residual, uncertainty representation, replay artifact, and most likely field failure for mapping and occupancy grids? If one field is vague, the estimator is not ready for embodied use.

Key Takeaway

Mapping and occupancy grids is production-ready only when geometry, uncertainty, timing, and action consequences are tested together.

Exercise 29.4.1

Run one map update with static obstacles and one with a moved obstacle or stale shelf. Report cell probability, inflation status, planner clearance, and whether recovery behavior invalidates the old route.

What's Next?

Continue to Section 29.5: Graph-based and visual SLAM, where this state-estimation contract becomes the input to the next embodied capability.

Section References

Durrant-Whyte, H. and Bailey, T. "Simultaneous Localization and Mapping." IEEE Robotics and Automation Magazine, 2006. https://ieeexplore.ieee.org/document/1638022

Classic SLAM tutorial that frames the estimation problem and the role of uncertainty.

GTSAM Project. "Factor Graphs and GTSAM." Official documentation. https://gtsam.org/

Primary tool reference for factor graphs, smoothing, pose graphs, and robotics estimation examples.

ROS 2 Navigation Project. "Nav2 documentation." Official documentation. https://navigation.ros.org/

Primary documentation for integrating localization, maps, planners, controllers, behavior trees, and recoveries.