Chapter 11

Estimate robot state, localize honestly, and measure uncertainty

Reopen the exact map, configuration, MCAP recording, transform snapshot, scenarios, and raw results preserved in Week 8, then explain what the first-flight black boxes were doing. Build the ideas in order—state and observations, probability and covariance, recursive Bayes filtering, practical EKF fusion, scan matching, pose graphs, and particle localization—before rerunning the frozen scenarios. The revised report must connect every frame, timestamp, uncertainty claim, parameter change, and measured improvement back to the unchanged Week 8 evidence.

Before you start

Run the Week 7 simulated differential-drive robot with wheel odometry and an IMU, and replay a short rosbag2 recording without connecting powered hardware.
Recognize the Week 8 `map→odom→base_link→sensor` frame chain, an occupancy grid, SLAM Toolbox mapping mode, AMCL localization mode, and simulation ground truth.
Use x-y coordinates, metres, seconds, radians, averages, squared values, fractions, and a small spreadsheet or Python script.
Treat an estimator output as a belief rather than ground truth, and preserve source timestamps, frames, units, raw measurements, configuration, and failed trials.

By the end

Separate hidden state, controls, observations, process and measurement models, estimator output, uncertainty, and independent ground truth.
Read mean, variance, standard deviation, covariance, correlation, and multimodal belief without confusing predicted uncertainty with measured error.
Execute a discrete Bayes predict/update cycle and explain why likelihood, prior, normalization, and model assumptions each change the posterior.
Calculate a scalar Kalman update and configure an inspectable `robot_localization` EKF that fuses non-duplicated wheel and IMU variables in valid frames and time.
Explain scan matching, occupancy updates, accumulated drift, pose-graph constraints, loop closure, AMCL particles, and `map→odom` correction as different parts of localization.
Evaluate nominal, outlier, and sensor-dropout trials with position and heading error, uncertainty coverage, recovery time, transform freshness, and an actionable failure taxonomy.
Ship a reproducible state-estimation and localization report whose claims can be recalculated from saved simulation data.

The field story

Guide the night courier through the blackout aisle

Courier-3 enters aisle C during a simulated night shift. Wheel odometry says it is moving straight, the IMU reports a slow turn, and the lidar loses a reflective wall just before a networked localization update disappears. Week 8 previewed the map-to-odom correction and warned that a transform can be available without being trustworthy. This week deepens that uncertainty preview: the robot must represent competing beliefs, update them with timed evidence, and expose how confident it is before the fleet assigns the next crossing.

You are not asked to produce a smooth blue line. You are asked to explain why the line moved, what observation changed it, which assumptions limited the update, and whether independent simulated ground truth supports the confidence claim. The courier will traverse a known loop, suffer an IMU outlier and lidar dropout, revisit a landmark, and recover. Every estimate carries frame, timestamp, covariance, configuration, and run identity, turning a mysterious localization jump into an inspectable chain of predictions and corrections.

Why this chapter now: Navigation and manipulation already depend on pose; the Week 8 transform preview now needs a quantitative belief model so downstream systems can distinguish a fresh estimate from a confident-looking failure.
Ignore for now: Do not derive measure theory, invent a new SLAM algorithm, or tune a real vehicle. Use small distributions, saved simulation data, and one declared estimator.
This unlocks: Inspectable state estimation supports localization gates, navigation recovery, mapping evidence, and later FleetOps freshness and fault tests.
Proof you will leave with: Provide input recordings, estimator configuration, frame tree, prediction/update calculations, covariance plots, ground-truth error, dropout and outlier runs, loop-closure evidence, recovery time, and the exact replay command.

Environment contractRepository-supported Node.js 22.13.0 or newer runs the scalar filter starter. The complete mission consumes the learner-created Week 8 bag and targets ROS 2 Jazzy with Gazebo Harmonic and tf2 in simulation; this repository does not bundle that bag or simulator workspace.

Compatibility boundary: Estimator parameters, message covariances, frame conventions, map formats, and SLAM/localization package behavior must match the actual Jazzy workspace. Do not copy a configuration from another ROS distribution without a replay test.
Smoke check: Run node week-11-courier-belief-update.mjs, replay one fixed bag twice, and confirm input counts, posterior values, transform timestamps, and ground-truth error summaries match.
Contract reviewed: 2026-07-25
Runtime evidence: The dependency-free starter is executed by repository tests on the supported Node.js baseline. Chapter-specific ROS 2, Gazebo, model, dataset, checkpoint, and hardware environments are learner-created unless the repository supplies an explicit asset; run the smoke check and preserve its versions and output before claiming runtime compatibility.
Drift risk: medium

Today in the field story

One problem, then the next

Courier-3 begins with a true pose hidden from its software. Wheel ticks, angular rate, lidar ranges, and commands are observations or inputs, not the state itself. Revisit Week 8’s map-to-odom preview and now name the uncertainty it left implicit. Draw the process and measurement models, attach frames and clocks, and separate estimator output from simulated ground truth before judging the first aisle segment.

Why now: Uncertainty must be modeled before sensor disagreement can be interpreted honestly.
Ignore today: Ignore matrix derivations and full SLAM internals; define the state and evidence contract first.
Unlocks next: A precise vocabulary for beliefs, predictions, observations, and independent error.

Understand

Build the physical picture first

A state estimator is a careful detective: it predicts the hidden situation from motion, checks noisy clues from sensors, and records how uncertain its current story remains.

State is the smallest set of quantities needed to answer the current engineering question and predict what happens next. For a flat-floor rover it might contain x position, y position, heading, forward velocity, and yaw rate. Motor temperature or battery charge can also be state in another estimator. A state is not automatically every field available in ROS, and it is not the same thing as the latest sensor message.

An observation is what a sensor reports about the state, often indirectly. A wheel encoder reports rotation; wheel geometry turns that into a motion estimate. A gyro reports angular rate; a lidar reports ranges to surfaces. The measurement model explains how a proposed state should create an observation. Each observation needs its original timestamp, unit, sensor frame, validity flags, and covariance before comparison with a prediction.

The process model predicts how state changes between measurements. A simple constant-velocity model says position advances by velocity times elapsed time, but real wheels slip, floors tilt, and commands arrive late. Process noise represents the model changes that were not explicitly predicted. A command is an input to the model, not proof that the robot physically achieved the requested motion.

Uncertainty is part of the estimate, not decoration added afterward. A useful output says both “x is about 10.5 m in odom at time t” and how broad the plausible range is. Independent simulation truth can measure estimator error, but truth must never be fed back as an ordinary sensor during the evaluation. Otherwise the test quietly gives the estimator the answer it is supposed to infer.

Words you need

Name each idea precisely

State: The hidden quantities the estimator must infer to support prediction or a robot decision.
Physical example:
A warehouse rover state contains map x-y pose, heading, forward speed, and yaw rate.
Observation: A timestamped sensor measurement that provides incomplete and noisy evidence about state.
Physical example:
A gyro sample reports 0.20 rad/s around its mounted z-axis rather than reporting the rover's complete pose.
Process model: A rule that predicts the next state from the previous state, elapsed time, controls, and modeled motion uncertainty.
Physical example:
A 1 m/s cart is predicted to advance 0.5 m during the next 0.5 s.
Measurement model: A rule that predicts what a sensor should observe if a proposed state were true.
Physical example:
A pose in a corridor predicts particular lidar distances to the left and right walls.
Ground truth: An independent reference used to measure estimation error, not an input secretly used to improve the estimate.
Physical example:
Gazebo's internal model pose evaluates wheel-and-IMU fusion after both trajectories are aligned in frame and time.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalProbability, variance, and Kalman weighting

State estimation combines predictions and measurements according to uncertainty.

μ: best current estimateUnit: state unit
σ²: variance, or squared uncertainty spreadUnit: state unit squared
K: Kalman gain, the measurement weightUnit: unitless

Prediction is 10 m. Measurement is 12 m. Let K = 0.25.
Innovation is 12 − 10 = 2 m.
Updated estimate = 10 + 0.25×2 = 10.5 m; the lower-trust measurement only shifts the estimate partway.

Programmer analogy

It is a weighted merge like resolving two data sources, but the weights come from modeled uncertainty.

Prediction 5 m, measurement 7 m, K = 0.5. What is the update?

5 + 0.5×(7−5) = 6 m.

The constant-velocity prediction is

x^-=x+v\Delta t=10+(1)(0.5)=10.5\,\mathrm{m}.

With $P=4$ , $R=1$ , and measurement $z=12\,\mathrm{m}$ , $K=P/(P+R)=0.8$ and $x=x^-+K(z-x^-)=11.7\,\mathrm{m}$ . Prediction and update use distinct assumptions.

Keep prediction, observation, and correction as separate claims

At 4.0 s, a one-dimensional cart state is x = 10.0 m with velocity v = 1.0 m/s. The process model assumes constant velocity for 0.5 s. A range-derived observation at 4.5 s reports z = 12.0 m.

Write the state and reference first: x = 10.0 m in the track frame at 4.0 s, with v = 1.0 m/s.
Compute elapsed time from timestamps: Δt = 4.5 - 4.0 = 0.5 s.
Apply only the process model: x⁻ = x + vΔt = 10.0 + 1.0 × 0.5 = 10.5 m.
Keep the observation separate: z = 12.0 m in the same track frame at 4.5 s.
Calculate the innovation, or measurement surprise: z - x⁻ = 12.0 - 10.5 = 1.5 m.
Stop before inventing a correction weight: without process and measurement uncertainty, the evidence supports a prediction and innovation but not a justified fused state.

Result

The prediction is 10.5 m and the observation is 12.0 m, producing a 1.5 m innovation; a later lesson will use modeled uncertainty to decide how much to correct.

What this proves

Writing each quantity's source, frame, time, and assumption prevents a measurement from silently replacing the state.

Physical examples

Where this appears in real life

Token moving behind a paper screen

A token starts at a measured mark, then a second person moves it behind a screen according to a noisy half-metre rule. The observer predicts its position and receives one imperfect peek every third move.

Look for:

The predicted position continues between peeks, the peek is evidence rather than truth, and the plausible interval widens when several moves are hidden.

Shopping trolley on two floor surfaces

The same forward push sends an unpowered trolley farther on smooth tile than on a rough mat, even though the requested push and elapsed time are identical.

Look for:

The command describes intention, while wheel or ruler measurements describe motion; the process model needs uncertainty for the unmodeled surface change.

Hands-on exercise

Make the idea observable

Use a spreadsheet or short script and a stationary paper track. Generate or record data only; do not command powered hardware.

Define a one-dimensional hidden trajectory with position and velocity at 0.5 s intervals, including one interval whose true velocity changes unexpectedly.
Generate a commanded-velocity column, a constant-velocity prediction column, and a separate noisy position-observation column with timestamps.
Hide the true-position column, calculate predictions and innovations, then label which values are state, control, observation, model output, and evaluation truth.
Reveal truth and calculate prediction error without using truth to alter any prediction.
Delay one observation by one time step and show why matching it to the newest prediction creates a false innovation.
Save the input table, formulas or script version, one nominal row, the delayed row, and a note naming the exact missing uncertainty needed before fusion.

Observe

The process prediction follows the assumed motion and misses the unexpected change; a delayed observation can look physically impossible even when its original measurement was reasonable.

Done when

Another person can identify every column's role, reproduce the 10.5 m prediction and 1.5 m innovation, and explain why no fused answer was claimed yet.

Build today

Use the frozen Week 8 artifacts to fuse odometry and IMU, explain scan matching, loop closure, and AMCL, then rerun the unchanged scenarios and compare error, uncertainty coverage, transform age, dropout recovery, and navigation success.

Evidence to save

DONE when the learning log explains “State, observation, process model, and uncertainty” in five precise points and a checked example produces the predicted output.

Common mistakes

Catch the wrong mental model

Wrong

Calling the latest sensor value the robot state.

Better

Treat the value as one timestamped observation and combine it with a declared process model, measurement model, and uncertainty.

Wrong

Using a commanded velocity as proof of actual motion.

Better

Keep control input and measured response separate; slip, saturation, delay, collision, or a disabled drive can break the command-to-motion assumption.

Wrong

Feeding simulation ground truth into the filter being evaluated.

Better

Reserve truth for independent error calculation and document every estimator input so the acceptance test cannot leak the answer.

Job connection

How this becomes employable evidence

Define the state, input, observation, frame, timing, and truth boundaries for an AMR localization component before integrating wheel encoders, IMU, lidar, and navigation consumers.

Relevant target roles

Robotics Software Engineer — ROS 2 / AMR
Robotics Application / ROS 2 Integration Engineer

Chapter 11 interview drill

Interview questions: State, observation, process model, and uncertainty

Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.

Primary interview scenario

A robot command says it moved one metre, wheel odometry says 0.92 m, and a lidar update suggests 1.08 m. Separate state, controls, observations, models, uncertainty, and ground truth before proposing a fix.

Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.

Technical follow-up questions

Q1Why is a wheel encoder observation not automatically robot position?

Model interview answer

It measures wheel rotation; geometry and a no-slip motion model convert rotations into an accumulating position estimate.

Q2What extra information belongs with a numeric observation?

Model interview answer

At minimum its timestamp, unit, frame, measured variable, validity state, and uncertainty or covariance.

Q3Why keep ground truth outside the estimator?

Model interview answer

Ground truth is the independent answer used to measure error; fusing it would invalidate the evaluation.

Chapter references

Introduction to Robotics and Perception — LocalizationPrimary open-text treatment of state beliefs, recursive Bayes prediction and measurement updates, Markov localization, Monte Carlo localization, and Kalman filtering.
robot_localization — State Estimation NodesMaintainer documentation for EKF and UKF behavior, timeouts, frame modes, per-sensor inputs, Mahalanobis rejection thresholds, and process and initial covariance.
robot_localization — Configuring sensor fusionMaintainer guidance for selecting non-duplicated state variables, planar constraints, absolute versus differential inputs, frames, and credible measurement covariance.
SLAM Toolbox — maintained ROS 2 repositoryMaintainer description of scan matching, pose graphs, loop closure, graph optimization, map serialization, and localization modes used in the mapping exercises.
Nav2 — AMCL configuration guideOfficial Adaptive Monte Carlo Localization contract for map, odometry and base frames, motion and laser models, particle bounds, resampling, initialization, and transform publication.