# Why One Equation Matters Opening hook for the lesson. Three engineering domains -- GPS tracking, rocket guidance, and robot control -- are laid out side by side to set up the central claim of the whole lesson: a single prediction-correction recurrence powers all three. ## Key ideas on this slide - Every system carries a hidden **state** (position, velocity, orientation) that changes over time. - At each tick the system makes a **prediction** from a motion model. - A noisy **measurement** `z` then arrives and never quite agrees with that prediction. - The shared shape is: `x' = F x + K (z - H x)` -- a model-based prediction plus a correction proportional to the prediction-measurement mismatch. ## Why it matters The slide frames the mystery the rest of the lesson unpacks (see <ref slide="3">Prediction Plus Correction</ref>), and previews the concrete domains revisited in <ref slide="4">GPS as Estimation</ref> and <ref slide="5">Rockets and Robots</ref>. ## State Changes Over Time A **dynamic system** is anything that changes as time moves forward — a car rolling down a road, a population growing, a rocket burning fuel. The powerful idea on this slide is that we don't model the whole blur of motion at once. Instead we chop time into discrete **steps** and ask one question, over and over: *given the state right now, what is the state one step later?* The **state** is the smallest set of numbers that fully describes the system at an instant. For an object moving along a line, the state is just two numbers — position **x** and velocity **v** — written as a **state vector** `s = [x, v]`. The **state-transition rule** tells us how to turn the current state into the next one. For simple motion at constant velocity: - `x' = x + v · Δt` — new position = old position plus how far you travelled in one step - `v' = v` — velocity stays the same (no acceleration here) That is the whole engine. Apply the rule once → you get the next state. Apply it again → the state after that. A long simulation is nothing but this one rule, **repeated**. <viz id="1"></viz> ### What to try The track up top shows the object's **x** along a ruler (metres); the hollow gold ring marks where the *next* step will land, so you can **predict before you step**. - **Drag the Velocity slider** to set **v**. Notice the teal arrow on the object grow or flip direction — that is how far one step will carry it. - **Drag the Time step slider** to change **Δt**. A bigger step covers more distance per update; a smaller one creeps forward. Watch the numeric breakdown `x + v·dt = x'` update live. - **Press Step** to apply the transition rule once. The blue disc jumps to `x'`, a faded dot records where it came from, and both state boxes shift left→right: the "current" box's old values become history; the "next" box recomputes from the new state. - **Press Reset** to return to the start and clear the trail. ### The core takeaway The two boxes below the track are the heart of it: `s_k` on the left, an arrow labelled with the rule in the middle, `s_{k+1}` on the right. Step the system and the right box's values move into the left box — the rule is identical every time, only the inputs change. This is exactly the structure the next slide builds on: as we will see in <ref slide="3">Prediction Plus Correction</ref>, real estimators *predict* the next state with this rule and then *correct* it with a measurement. Here, with no measurement yet, the rule alone is the whole story — repeated application *is* the simulation. ## Prediction Plus Correction Every estimation system faces the same dilemma. You have a **model** of how something moves — a prediction of the next state — and you have a **sensor** that measures where it actually is. Neither is trustworthy on its own: the model drifts because reality never matches its assumptions, and the sensor is noisy. The engineering answer is to use *both*, and this slide shows why. ### The two pieces **Prediction** takes the current best estimate and rolls it forward using the model. Here the model is deliberately simple: it assumes the object keeps the velocity it started with. The true path curves, so a prediction-only estimate sails off in a straight line and drifts further from reality every step. Watch the red trace fly away from the faint true path — that is model error accumulating, exactly what dooms any "trust the model entirely" strategy. **Correction** takes a fresh sensor reading and snaps the estimate back toward the measurement. The noisy gold dots are the raw sensor — they cluster around the true path but jitter. In correction mode the teal estimate stays glued to truth *despite* that jitter, because every measurement update cancels the drift the prediction introduced moments earlier. <viz id="1"></viz> ### Try it - **Toggle "Correction on" off, press Reset, and watch.** The estimate rides the initial straight-line velocity and diverges while measurements sit there, ignored. This is the failure mode you avoid. - **Toggle correction back on mid-run.** Notice how the estimate immediately curves back toward the true path — the measurement update rescues a badly drifted estimate. - **Drag the sensor-noise slider up.** The gold cloud fattens; the corrected teal trace gets jittery but never runs away, while a prediction-only run is unaffected (it ignores measurements entirely). That contrast is the whole lesson: correction trades a little noise-immunity for freedom from drift. - Check the **error** and **max error** readouts in the panel. Prediction-only lets max error climb without bound; correction keeps it bounded and small. ### Why this matters Prediction alone is a model trusts nobody; correction alone is a sensor trusts nobody. Real systems — GPS, robot localization, rocket guidance (see <ref slide="4">GPS as Estimation</ref> and <ref slide="5">Rockets and Robots</ref>) — fuse them: the model carries the estimate through sensor gaps, and the measurement reins the model back when it drifts. The gain that decides how hard each measurement pulls is the single most important knob, which is exactly what <ref slide="7">Tune the Estimator</ref> explores. The equation behind all of this — one line that says *new estimate = prediction + gain × (measurement − prediction)* — is the subject of <ref slide="1">Why One Equation Matters</ref>. ## GPS as Estimation A GPS receiver never measures its position directly. Each satellite in view broadcasts a signal; the receiver reads the travel time and converts it to a **range** — an estimate of the distance to that satellite. Because clocks drift, signals bounce, and the ionosphere delays them, every range arrives carrying **noise**. The receiver's only safe move is to combine many noisy ranges into a single best guess, then do it again a moment later when new ranges arrive. That job is exactly the *predict + correct* loop from <ref slide="3">Prediction Plus Correction</ref> — just renamed. **Prediction** carries the receiver's last position forward using its velocity; **correction** folds in the fresh noisy ranges. What gets carried between steps is a **state vector** (position *and* velocity) **plus its uncertainty** — the covariance you see as the ellipse on the map. The same equation that tracks a moving cart in a physics lab tracks your phone. <viz id="1"></viz> The map shows four satellites at the corners beaming ranges (dashed circles) at a receiver traveling the faint circle in the middle. The bright teal dot is the **Kalman estimate**; the white dot beside it is the ground truth. Around the estimate sits the **2σ uncertainty ellipse** drawn straight from the filter's covariance matrix. Watch the ellipse **breathe**. Between corrections it swells — that is the *prediction* step, where uncertainty compounds because the future never matches the straight-line model perfectly. The instant fresh ranges arrive (a teal pulse rings out), the *correction* step shrinks it back down. Two phases, one equation, looping forever — that is GPS. Try these before reading on: - **Drag Satellite noise up.** Predict first: will the ellipse settle *larger* or *smaller*? Notice that high-noise ranges make the filter *distrust* the measurements, so the correction shrinks the ellipse less and the steady uncertainty grows. - **Drag Receiver speed up.** A faster receiver curves harder, so the constant-velocity prediction is wrong by more each frame — the ellipse now grows *faster between corrections* and the teal estimate *lags* the white truth, nudging the **Track error** readout up. - **Switch Active satellites from 4 to 2.** With only two ranges the geometry can no longer pin the receiver in every direction, and the ellipse stretches along the weak axis — the visible face of *dilution of precision*. GPS constellations are built to keep at least four satellites in view for exactly this reason. The panel's **Uncertainty σ** and **Track error** are the same two numbers an engineer reads off a real filter: how spread-out our belief is, and how far it has drifted from truth. Push **Reset track** to restart the estimate from scratch and watch the ellipse collapse down to the steady breathing rhythm. The takeaway is the point of this whole lesson: whether the state is a cart, a phone, or a spacecraft (<ref slide="5">Rockets and Robots</ref>), the machinery is identical — **predict the state, grow its uncertainty, correct with each new noisy measurement, repeat.** GPS is not a different algorithm; it is *the* estimator with antennas bolted on. ## Rockets and Robots A rocket fighting crosswind to touch down on its pad, and a wheeled robot drifting on a slick floor while it tries to follow a path, look like utterly different problems. They are not. Both keep a moving system on course by running the **same two-line state update** every step: - **Predict:** `x⁻ = x + u·dt` — push the last estimate forward with the control you commanded. - **Correct:** `x = x⁻ + K(z − x⁻)` — fold in the fresh measurement `z`, weighted by the gain `K`. That is the entire <ref slide="3">Prediction Plus Correction</ref> pattern, applied once to guidance and once to robotics. The only thing that changes between the two halves of this screen is *what* `x`, `u`, and `z` physically mean. On the left `x` is lateral position over the pad, `u` is thrust, `z` is a GPS fix. On the right `x` is cross-track error from the path, `u` is steering, `z` is a path-camera reading. The algebra is identical. <viz id="1"></viz> ### What to watch on the canvas Each side shows **two agents**. The solid one is the *true* system, pushed around by a perturbation you control. The outlined ghost is the **estimator's belief** of where that system is — the predict+correct loop's current estimate. A faint dashed link ties them; when the link stretches, the estimate has lost track of truth. **Drag the Wind slider** on the rocket side. With the **K** gain around `0.5`, the ghost stays glued to the true rocket and the commanded thrust nudges it back over the pad. Now **slide K down toward `0`** — the estimator goes *open-loop*, the ghost freezes where the model predicted, the thrust gets computed off a stale belief, and the true rocket blows downwind off the pad. **Drag the Wheel slip slider** on the robot side and do the same with K. The robot's ghost and true body diverge exactly the same way, for exactly the same reason: with `K ≈ 0` the predict step has nothing to pull it back to truth, so the control actuates on a lie. ### Read the state in the panel The panel lists, for each side, the **true and estimated state**, the **control input** the system commanded (thrust / steer), the **true−estimate error**, and the live **innovation** `z − x⁻` — the very quantity the correct step multiplies by `K`. Watch the innovation spike when you crank wind or slip, then shrink again as K fuses the measurement back in. A big innovation with a tiny K means nothing gets corrected; a big innovation with a healthy K means the estimator is doing its job. ### The takeaway The equation does not care whether it is flying or driving. Once you commit to a `predict → correct` loop with a gain `K`, the *domain* is just a choice of units and sensor; the machinery is reusable. That is why the same estimator block shows up in spacecraft descent, farm robots, drones, and <ref slide="6">The Equation in Practice</ref> in far larger systems. **Push K to the extremes on both sliders at once** to feel the single structure bending the same way across both halves of the screen. # The Equation in Practice This slide distills the **shared template** behind every state-space estimator, from GPS (slide 4) to rockets and robots (slide 5), and shows why real implementations care about the state dimension. ## The five-piece skeleton - **Predict step:** `x_k = F x_(k-1) + B u + w` - `x_k`, `x_(k-1)` — current / previous state - `F` — transition model (the physics) - `B u` — control input we command - `w` — process noise / uncertainty we can't predict - **Correct step:** `z = H x + v` - `z` — measurement - `H` — observation model (which state components we observe) - `v` — sensor noise Wired together, the two steps form the **predict -> correct loop** that runs forever, keeping the estimate locked to reality. ## Why size matters Correcting the covariance inverts an `n x n` matrix, so the per-step cost scales as `O(n^3)`. Doubling the state does **not** double the work: - `n = 2` -> a few flops, trivially real-time. - `n = 100` -> roughly a million times more work per step. That cubic penalty is why engineers fight to keep the state vector small — decomposing systems, dropping states, or using square-root / information-form variants that avoid full inverses. Slide 7 takes up how they tune the result. ## Tune the Estimator You have spent the lesson building up the **predict–correct** idea: take the best guess from the motion model, then fold in a noisy measurement (slide 3). Real systems—GPS units, robot localizers, rocket guidance—do this every single tick, and one choice makes or breaks the result: **how much to trust the prediction versus the measurement.** That ratio is not magic; it is a number you set, and here you set it. ### The scene A vehicle moves along a hidden **true path** (the gold curve). You never see it directly. A noisy **sensor** spits out a reading each step (the grey dots, scattered off the truth by ~14 units). Your **estimator** — a one-dimensional constant-velocity Kalman filter — runs the predict–correct loop on those readings and draws its best guess in teal. Two tuning knobs drive the filter, and both are genuine concept variables: - **Process noise Q** — how much the filter trusts its own motion model. Small Q says "my model is law," so the estimate over-commits to the predicted straight line and **lags** whenever the vehicle accelerates. Large Q says "my model is unreliable," so the estimate gets twitchy. - **Measurement noise R** — how noisy the filter *assumes* the sensor is. Small R says "believe the sensor," so the estimate rides the noisy dots. Large R says "ignore the sensor," so the estimate smooths the dots out — but drifts when the sensor was actually right. Inside the filter these two produce the **Kalman gain** *K = P / (P + R)*, the live blend weight between prediction and measurement. Watch the gain readout in the panel as you move the sliders: that number *is* the trust ratio, and it is exactly what <ref slide="6">The Equation in Practice</ref> was about. <viz id="1"></viz> ### The challenge The lower plot tracks **|estimate − truth|** every step. The teal dashed line at **7.0** is your target: keep the *run-average* error below it. The run auto-replays each time you change a knob, so feedback is immediate. **Move Q and R and watch the estimate line.** Some things to try: - **Pin Q very low** (0.01) and notice the teal line trailing the gold curve through every turn — pure prediction can't follow acceleration it never predicted. - **Pin R very low** (≈2) and watch the teal line jitter onto every grey dot — trusting a noisy sensor injects the noise straight into the state. - **Now balance them.** You want Q large enough to admit the model is wrong sometimes, and R close to the *actual* sensor scatter (the dots tell you what that is). The gain settles somewhere in the middle, and the error curve sinks under the threshold. **Hit Restart Run** to replay the same data with the current knobs — the measurements are fixed, so any change in the estimate is purely your tuning. Find the (Q, R) pair that pulls the run-average error below 7.0 and the status flips to **PASS**. There is a basin of good answers, not a single point — just like tuning a real filter.