Introduction — why we need estimation
Using GPS jitter as an example, build the sense of distinguishing three concepts — observations wobble, truth is invisible, estimates are our best guess.
The reason the blue dot on your smartphone map twitches even when you are standing still is that noise is baked into the observation itself. Instead of displaying the observation as is, the Kalman filter estimates the invisible true value.
Distinguishing truth, observation, and estimate
Throughout this course we always keep these three separate. On the simulator screen they appear as three different lines (truth line, observation points, estimate line).
First we get a numerical feel for "observations always drift a little each time."
Averaging cancels some noise
If the target is stationary, averaging multiple observations already reduces the visible jitter. This is because "noise happens to split into positive and negative and cancels out."
However, plain averaging still has a problem: it cannot follow motion well.
Check 1 — Observation errors and their mean
The truth is x = 100 m and three observations were 101, 98, 103. Compute the error e = z − x one by one, then take the average.
Q1. What is the error e of the observation z = 101?
101 − 100 = 1. Observations drift a little every time, so the starting point is simply seeing that drift as a number.
Q2. What is the error of the observation z = 98?
98 − 100 = −2. A negative error means the observation lies below the truth.
Q3. What is the error of the observation z = 103?
103 − 100 = 3. Errors are subtracted independently for each observation.
Q4. What is the simple average of the three observations 101, 98, 103?
(101 + 98 + 103) / 3 = 302 / 3 ≈ 100.67. A plain average already cancels some noise, but if the target is moving it introduces a lag.
What goes wrong when you use observations directly
- The UI looks jagged and untidy.
- Outliers feed straight into your control input.
- Values from multiple sensors disagree and cause confusion.
- Plain averaging is slow to catch up with motion.
Check 2 — The difficulty of using observations directly
Think about why displaying observations as is is a problem, then confirm the mean for a stationary target.
Q1. A stationary device returned observations of 10.0 → 10.2 → 9.9 → 15.0. Which reason best explains why displaying the raw observation is a problem?
The correct answer is the first choice. Observations contain noise and occasional outliers, so using them directly in UI or control means a value like 15.0 shows up on screen or feeds straight into the control input. The second choice is also a real concern, but the most direct UI/control problem is the outlier.
Q2. A stationary target was observed four times as 10.1, 9.9, 10.2, 9.8. What is the simple average?
(10.1 + 9.9 + 10.2 + 9.8) / 4 = 40.0 / 4 = 10.0. For a stationary target, averaging works very well; for a moving target, the lag becomes noticeable.
Takeaway of this chapter
Observations wobble. Truth is invisible. That is why it is worth having an "estimate" instead of raw "observations." In the next chapter we look at the predict step: using a model to advance the previous estimate forward to the next time index, before any new observation arrives — placing a "this is what the next moment should look like" using only the information we already have.