Robots Under Uncertainty: Estimating Position from Noisy Sensors

The robot cannot directly see the truth#

A warehouse rover drives down a straight aisle toward a shelf. Its job is to stop at the right place, and to do that it has to answer one question: where am I along the aisle?

One number answers it, because the aisle is a line. Robotics calls that number the state — the smallest set of numbers that says everything the robot needs to know about its own situation. For a rover on a rail, one number is enough. For the two-joint arm in the previous lesson it was two joint angles; for a drone it would be a position, a velocity and an orientation. The rest of this lesson works with the single number, because everything important survives the simplification.

Now the awkward part. The rover has a distance sensor pointing at a marker at the end of the aisle, and it reports

“

3.21 m

The rover is really at 3.00 m. The sensor is not broken and not lying: it has measured something real, and its answer is 21 cm off. It reports 3.21 m because a sensor measures its own signal, not the world. The signal was produced by the world, then travelled, reflected, arrived, was timed, and was converted into a number — and every one of those steps adds a little error. A laser rangefinder has a resolution limit. A wheel encoder's wheel has a slightly wrong diameter. A GPS receiver's timing signal is noisy. Wherever the number comes from, it arrives as the truth plus an error.

Two different kinds of error are worth naming, because the filter in this lesson can handle one of them and not the other.

• Jitter is random and changes from reading to reading: 3.21 m now, 2.98 m a moment later, for a rover that has not moved. Averaging many readings from a parked rover shrinks jitter — ten times as many readings cut it by a little more than a factor of three.
• Bias is systematic and keeps the same sign: a sensor whose scale was calibrated badly always reads 0.1 m too large. It looks beautifully steady, and it is wrong. Averaging never removes bias, because every reading carries it.

This second kind of error is the one that catches people out. A filter fed a biased sensor will confidently report a position that is shifted by the bias. So the honest formulation of the claim that opens this lesson is: a sensor reading is a measurement of the truth, contaminated by error — and you can check for the error, but you cannot wish it away.

With that in mind, here are the four quantities, and they are the vocabulary for the rest of the lesson:

The word estimate is doing a lot of work in that table. A measurement is something the rover received; an estimate is something the rover concluded. A robot that drives on raw readings is gambling on a single noisy number; a robot that drives on an estimate has blended that number with what it already knew.

Prediction: what the robot expects after moving#

A robot does not sit still waiting for readings. It moves, and it knows what it commanded: drive forward at 0.5 meters per second for one second. So it can say where it should be without asking any sensor at all.

That is the whole idea. If the rover's last estimate was 3.00 m and it commands a 0.5 m step forward, the prediction is 3.50 m. Notice what the prediction is built from: the estimate, not the truth. The robot has no access to the truth, so its own best guess is the only starting point it has. This is also why estimates and predictions are two names for the same knowledge at different times — the prediction is the estimate carried forward.

The prediction is genuinely informative, and it is worth being clear about why. It is not a rumor and not a placeholder. Actuators really do move the robot, and the number of meters moved is real information about the world that no sensor needed to supply. It also covers the gaps: sensors report a few times per second at best, and the robot has to keep track in between. A robot with no prediction can only ask "where was I when I last measured?" — and the answer is always stale.

The trouble is that the prediction is only as good as the robot's knowledge of its own motion, and that knowledge is never exact:

• Wheel slip. The wheel turns 0.5 m of tread but the floor is smooth and the rover advances 0.47 m. The error is invisible to the encoder, because the encoder watches the wheel.
• Unmodelled geometry. A worn tyre has a smaller diameter than the one in the model, so every rotation carries the rover slightly less far than the code thinks.
• Timing and starting conditions. Commands are not executed instantly, and the estimate the prediction starts from was itself imperfect.

Because every prediction starts from the previous estimate, these small errors accumulate. This is the classic failure mode called dead reckoning: after 100 m of driving with a 1% distance error, the rover's own idea of its position is about 1 m off, and it will never find out on its own — the error does not decay, and nothing about it is random enough to cancel. A rover that only predicts drifts away from reality with complete confidence.

There is one more thing the prediction does, and it is subtle: moving makes the robot less sure. Not because anything went wrong, but because it just acted on a model of a world it cannot see directly. The prediction is the part of the estimate that carries information forward in time. It is not the part that ties the estimate back to reality.

Measurement: what the sensor reports and why raw readings jitter#

The reading is the opposite trade. It is about the world right now, which is exactly the information the prediction cannot supply, but it arrives blurred.

Write it as one line, which is how every estimation lesson starts:

The ten parked-rover readings from the exercise are that line made visible: 3.02, 2.97, 3.10, 2.95, … — a cluster around the truth with a spread of a few centimeters. What sets the spread? The sensor's resolution, the timing of its pulse, the surface it reflected off, its temperature, and the noise in its own electronics. What sets the centre of the cluster is the bias, if there is any. Averaging helps with the first and does nothing about the second.

Three consequences follow, and each one reappears in the lab.

One reading is not the answer. If the noise has a spread of 5 cm, then a single reading is typically within 5 cm of the truth and can easily be 10 cm off. Treating it as the truth means building decisions on that error.

Averaging works, but it needs a stationary rover. Averaging $n$ independent readings cuts the spread by $\sqrt{n}$: ten readings, a factor of about 3; a hundred readings, a factor of 10. That is a real win — and it is available only when the robot is not moving, because a moving rover takes each of those readings at a different place, and the average then answers a question about somewhere in the middle of that journey. If you want a precise position every second while driving, you cannot get it from averaging, and this is exactly the gap the prediction fills.

Only the measurement notices the uncommanded. Slip makes the rover go less far than commanded, but a shove from a person, a bump against a shelf, or a wheel spinning on ice makes it go somewhere the motion model never expected. The prediction cannot see any of that. The measurement is the only channel through which reality can disagree with the robot's internal story — which is why discarding the measurement to get a smooth answer is a bad trade, not just an imprecise one.

Estimate: combining the two with a plain-language weight#

So the robot holds two numbers that disagree, and both are partly right. The fix is not to pick a winner; it is to blend them:

Read it in words. The bracket is the correction the reading proposes: how far the reading is from the prediction. The gain is between 0 and 1, and it says what share of that proposal to accept.

• gain = 0: accept nothing. The estimate is the prediction, and the sensor is ignored — smooth, and deaf to the world.
• gain = 1: accept everything. The estimate jumps to the reading — responsive, and as jittery as the sensor.
• gain = 0.5: meet the correction halfway. Half the gap disappears each step.

What should the gain be? It should depend on which number deserves more trust, and there is a clean way to say how much. Give each source a say in proportion to how certain it is — measured as the square of its spread. Concretely: if one source's typical error is half the other's, it is four times as certain, and it gets four times the say.

With that rule, the gain has a closed form. Write $p$ for the prediction's uncertainty (its spread squared) and $r$ for the sensor's:

Worked example. Suppose the rover's prediction is $3.50 \pm 0.4$ m and the sensor reports $3.21 \pm 0.2$ m. The prediction's uncertainty is $p = 0.4^2 = 0.16$, the sensor's is $r = 0.2^2 = 0.04$, so

and the estimate is the prediction plus 80% of the gap:

The sensor's spread of 0.2 m is half the prediction's 0.4 m, so the sensor gets four times the say: 80% against 20%. Nothing was tuned by hand; the weighting fell out of how much each source should be trusted.

The payoff is not only a better number, it is a number that is better than either input. The prediction was uncertain by 0.4 m and the reading by 0.2 m, and after combining, the estimate's uncertainty is about 0.18 m:

That is the answer to "why bother combining?" — two imperfect sources of information about the same thing, combined in proportion to their reliability, beat both of them. Neither the prediction nor the measurement was good enough on its own; together they are.

Browser lab: track a robot on a line#

The cell below is the whole filter, in one self-contained cell of ordinary Python. It simulates the aisle from the first section — the true position advances, a sensor reports the truth plus random error — and it prints what the robot knows at each step, then draws the result.

Four things to look at before you change anything:

• truth is the hidden line. Only the simulation sees it. It is what all the errors are measured against.
• readings are the dots. Each is the truth plus one draw of random error.
• predictions are the dotted line: the estimate carried forward at the commanded speed, before the reading is applied.
• estimates are the solid blue line: the prediction plus gain times the correction.

The rover reverses at step 20 (a commanded change, which the prediction knows about), and at step 25 it is shoved 1 m by a person (an uncommanded change, which the prediction cannot know about). Both events are there to separate what each input contributes.

Work through it in this order.

1. Run it unchanged. Read the printed table around the shove. Predict how much of the 1 m shove the estimate accepts on the step it happens, before you look at the number.
2. Raise the sensor noise. Set sensor_noise = 0.80 and run again. The gain falls, the raw readings get much worse, and the estimate stays comparatively smooth — but look at the 8-step number after the shove: it gets worse, not better.
3. Change the motion uncertainty. Set motion_uncertainty = 0.50 and run. The gain rises, the estimate follows the readings more closely, and it recovers from the shove faster — at the cost of jumping around more.
4. Make the prediction overconfident. Set motion_uncertainty = 0.01 and run. The filter trusts its motion model almost completely, and it takes much longer to believe the shove.

import numpy as np
import matplotlib.pyplot as plt

# ---------------------------------------------------------------- the world
# The robot never sees these numbers. We keep them only to score the estimate.
dt = 1.0                 # one step = one second
speed_out = 0.5          # meters per second for the first 20 steps
speed_back = -0.4        # then the rover reverses
turn_step = 20           # the commanded turnaround
nudge_step = 25          # somebody shoves the rover here - no wheel ever turned
nudge_size = 1.0         # meters
n_steps = 45

# ------------------------------------------------------------ the two knobs
# Change either one, then press Run again. Nothing else needs editing.
sensor_noise = 0.35         # how jumpy the readings are (meters, 1 standard deviation)
motion_uncertainty = 0.05   # how unsure each move makes us (meters squared)

rng = np.random.default_rng(7)   # fixed seed, so everyone sees the same run

# --------------------------------------------- the robot's belief and memory
estimate = 0.0                 # its best guess of where it is
estimate_uncertainty = 0.25    # how unsure it is about that guess (m^2)

truth, readings, predictions, estimates, gains = [], [], [], [], []

for step in range(n_steps):
    # 1. The world moves the rover. Only we can see this.
    speed = speed_out if step < turn_step else speed_back
    true_position = (truth[-1] if truth else 0.0) + speed * dt
    if step == nudge_step:
        true_position = true_position + nudge_size

    # 2. The sensor reports the truth plus a random error.
    measurement = true_position + rng.normal(0.0, sensor_noise)

    # 3. PREDICT: carry the previous estimate forward by the commanded motion.
    prediction = estimate + speed * dt
    # Moving always makes us less sure, so uncertainty grows here.
    estimate_uncertainty = estimate_uncertainty + motion_uncertainty

    # 4. UPDATE: accept a share of the correction the reading suggests.
    gain = estimate_uncertainty / (estimate_uncertainty + sensor_noise ** 2)
    estimate = prediction + gain * (measurement - prediction)
    estimate_uncertainty = (1.0 - gain) * estimate_uncertainty

    truth.append(true_position)
    readings.append(measurement)
    predictions.append(prediction)
    estimates.append(estimate)
    gains.append(gain)

truth, readings = np.array(truth), np.array(readings)
predictions, estimates = np.array(predictions), np.array(estimates)


def mean_error(values, reference):
    """Average distance from the truth, in meters."""
    return float(np.mean(np.abs(values - reference)))


print(f"sensor_noise {sensor_noise:.2f} m    motion_uncertainty {motion_uncertainty:.2f} m^2")
print(f"mean |reading  - true position| {mean_error(readings, truth):.3f} m   (raw, jumpy)")
print(f"mean |estimate - true position| {mean_error(estimates, truth):.3f} m   (after combining)")
print(f"gain on the last step {gains[-1]:.2f}   (share of each correction accepted)")

print("\nthree steps around the shove:")
print("step | true (hidden) | prediction | reading | estimate | gain")
for step in (nudge_step - 1, nudge_step, nudge_step + 1):
    print(f"{step:4d} | {truth[step]:13.2f} | {predictions[step]:10.2f} | "
          f"{readings[step]:7.2f} | {estimates[step]:8.2f} | {gains[step]:.2f}")

after = slice(nudge_step, nudge_step + 8)
print(f"mean |estimate - true position| in the 8 steps after the shove: "
      f"{mean_error(estimates[after], truth[after]):.3f} m")
print("Notice: the estimate jumps around less than the raw readings, and it only partly "
      "corrects on the step of the shove - a prediction cannot see what was never commanded.")

# ----------------------------------------------------------------- the plot
fig, ax = plt.subplots(figsize=(7, 3.2))
xs = np.arange(n_steps)
ax.plot(xs, truth, "-", color="tab:gray", lw=2.2, label="true position (only we see it)")
ax.plot(xs, readings, "o", color="tab:orange", ms=3.5, alpha=0.75, label="raw readings")
ax.plot(xs, predictions, ":", color="tab:blue", lw=1.3, alpha=0.75, label="prediction")
ax.plot(xs, estimates, "-", color="tab:blue", lw=2, label="estimate")
ax.axvline(turn_step, color="tab:red", ls="--", lw=1.1, label="trajectory changes")
ax.axvline(nudge_step, color="tab:green", ls="--", lw=1.1, label="uncommanded shove")
ax.set_xlabel("step (seconds)")
ax.set_ylabel("position (m)")
ax.set_title("Tracking a rover on a line from noisy readings")
ax.grid(alpha=0.3)
ax.legend(fontsize=7, loc="upper left", ncol=2)
plt.tight_layout()
# The page captures the figure and shows it under this cell - no plt.show() needed.

What the printout means. gain is the share of the correction the filter accepted on the last step. The two mean |… - true position| lines compare the raw readings and the final estimates against the truth: the second should be the smaller of the two, which is the whole point of predicting and measuring together. The table is the shove seen step by step — at the shove the prediction has no idea anything happened, the reading carries the news, and the estimate moves only gain of the way toward it. The 8 steps after the shove number is the responsiveness of the filter: it is the price you pay for smoothness.

Reading the picture. The gray line is the truth, which the robot never sees. The orange dots scatter around it with a spread set by sensor_noise. The dotted blue line is the prediction: it is smooth, it takes the commanded turnaround at step 20 in stride, and it sails straight past the shove. The solid blue line is the estimate, which sits between the two. Notice that the estimate is not the truth either — it is the best blend the robot could make of what it had. The figure is drawn when the cell runs and appears under the output, so there is no plt.show() to add.

One honest caveat. The simulation is built so the truth is exactly "commanded motion plus a shove". Real motion models are wrong in small, persistent ways (slip, tyre wear), which is why the plan below asks you to check what happens when the model itself is trusted too much.

AI and robotics connection: estimation before action#

Look back at the sense → decide → act loop from the previous lesson. The decide box does not receive the truth. Nothing does. It receives the estimate.

That single fact has consequences that reach all the way into modern robot learning. A policy — a hand-written rule, a PID controller, or a neural network — is a function from state to action. Estimation is the function that supplies its input, and an error in the estimate becomes an error in the action: a rover that believes it is 30 cm further along than it is brakes 30 cm late; a manipulator that believes its hand is somewhere it is not collides with the table. The sensor's jitter and the motion model's drift do not stay in the estimation module. They propagate into behavior.

This is why the recipe in this lesson is one of the load-bearing ideas in robotics. The weighted predict/update cycle has a name — the Kalman filter — and in the case this lesson used (one number, linear motion, errors that look like a bell curve) it is not merely a sensible rule of thumb: it is the best possible estimate in the mean-squared-error sense, and the gain you computed by hand is the optimal one. rb-w2 derives the same cycle with matrices and covariances, which is what lets a robot estimate many states at once, handle nonlinear motion, and fuse several sensors.

The same pattern shows up far outside rovers:

• A phone blends GPS, accelerometers and Wi-Fi to place a dot on a map. GPS jitters; the accelerometers supply the prediction between fixes.
• A Mars rover dead-reckons between sun and star sightings, because a wrong estimate on another planet is not recoverable by asking directions.
• A robot vacuum keeps a belief about where it is while bumping into furniture — every bumper hit is a measurement that contradicts the prediction.
• A learned policy that consumes a history of observations and actions is doing estimation implicitly, whether or not it has a filter inside.

And one design lesson follows from the uncertainty numbers rather than from the estimate itself. Because the filter tracks how uncertain it is, a robot can act on that: drive slowly while the estimate is poor, take an extra measurement before committing to a grasp, or look where the uncertainty is largest. Estimation before action, with the confidence attached — that is the shape of every serious robotics stack.

Knowledge Check#

Checks on the cycle and the vocabulary before you take on the practical task.

Practical task#

Do this in the lab cell above, and record the numbers it prints. You are looking for settings that buy smoothness and responsiveness — a smaller mean error than the raw readings, without going deaf to a shove.

1. Baseline. Run the cell unchanged. Record three numbers: mean error of the raw readings, mean error of the estimate, and the gain. With the defaults the estimate's error is about 0.18 m against the readings' 0.24 m, and the gain is 0.47.
2. Make it smoother. Set sensor_noise = 0.80 and run. Describe what happens to the raw readings versus the estimate, and say which number in the printout shows that the estimate has become sluggish.
3. Make it faster. Set motion_uncertainty = 0.50 and run. The estimate now reacts quickly to the shove, and the gain rises — but compare the estimate's mean error and the smoothness of the blue line with step 1.
4. Hit the target. Find a setting where both hold: the estimate's mean error is below the readings' mean error, and the mean error over the 8 steps after the shove is under 0.45 m. The defaults already pass (0.18 m and 0.38 m); a very smooth setting such as motion_uncertainty = 0.01 fails the second test. Write down the two knob values you chose and both numbers.
5. Say why. In one sentence: why is the prediction useful, and why is the measurement useful?

You are done when step 4 passes with numbers you can quote, and your sentence from step 5 says something equivalent to: the prediction carries the estimate forward through motion and fills the gaps between readings, the measurement ties it back to the world and notices changes nobody commanded, and blending them by how much each can be trusted is better than trusting either one alone.

Key takeaways#

• A sensor reading is the truth plus an error. Jitter changes from reading to reading and averages away; bias does not, and it survives every blend.
• Four numbers, and only three of them are available to the robot: true position (never), prediction (motion model applied to the last estimate), measurement (noisy, current), estimate (the blend — and the input to every later decision).
• The prediction carries information forward in time and covers the gaps between readings, but its errors accumulate, so prediction alone drifts without ever noticing.
• The measurement is the only channel that ties the estimate back to the world and the only one that notices an uncommanded change.
• Combine them with $\text{estimate} = \text{prediction} + \text{gain} \times (\text{measurement} - \text{prediction})$, where $\text{gain} = p/(p+r)$ gives each source a say in proportion to its reliability. The combined estimate is more certain than either input alone.
• The gain is a trade-off you can feel in the lab: a small gain is smooth but slow to notice a shove; a large gain is responsive but inherits the sensor's jitter.

Where this leads#

You have reached the end of the beginner on-ramp: this is the last of the sixteen Guided Foundations Path steps, and it built on every one before it — probability for the noise, averages for the blending, and the sense → decide → act loop for the setting.

The natural next rung is the full treatment of the filter you just wrote by hand: Week 2: Dynamics and State Estimation derives the predict/update cycle with matrices and covariances, handles nonlinear motion with the extended Kalman filter, and fuses several sensors. The probability behind the weighting is developed in Probability & Statistics Week 6: Multivariate Gaussians, and Week 5: Bayes' Rule is the belief-over-states view of everything in this lesson.

If you would rather build than derive, Robot Learning Week 1: Robot Modeling and Kinematics is the advanced counterpart of the previous lesson, and the control loop there consumes exactly the estimate this lesson produces.

Further reading#

• Sebastian Thrun, Wolfram Burgard and Dieter Fox, Probabilistic Robotics (MIT Press, 2005). Chapter 2 derives recursive state estimation from Bayes' rule and introduces the predict/update cycle in general form; Chapter 3 is the Kalman filter. The standard reference for the belief view.
• Greg Welch and Gary Bishop, An Introduction to the Kalman Filter (University of North Carolina, TR 95-041, free PDF). The classic short tutorial — the same gain formula as this lesson, with the covariance algebra worked out step by step.
• Rudolph E. Kálmán, "A New Approach to Linear Filtering and Prediction Problems", Journal of Basic Engineering 82(1), 1960. The original paper; readable for the shape of the argument even if the algebra is beyond this lesson.
• Stuart Russell and Peter Norvig, Artificial Intelligence: A Modern Approach (4th ed., Pearson, 2020). Chapter 14 covers filtering and the recursive estimate under uncertainty, with robot examples throughout.