Section 8.3: IMU, wheel odometry, joint encoders, proprioception

A Careful Control Loop

This section develops the technical contract for IMU, wheel odometry, joint encoders, proprioception into a usable mental model. First we define the object of study, then we connect it to the agent loop, then we test it with a compact implementation.

The key question in IMU, wheel odometry, joint encoders, proprioception is practical: what must the agent know, what can it observe, what action is available, and what evidence shows that the action worked under the stated conditions?

Theory

For IMU, wheel odometry, joint encoders, proprioception, the practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

Worked Example: Dead Reckoning and IMU Drift

An inertial measurement unit reports linear acceleration and angular rate, never position directly. To get position you integrate acceleration twice (velocity, then position), a process called dead reckoning. The trouble is that integration also accumulates error. A real accelerometer reading is $a_{\text{meas}} = a_{\text{true}} + b + n$, where $b$ is a slowly varying bias and $n$ is white noise. The bias is the killer: a constant bias $b$ double-integrates into a position error that grows like $\tfrac{1}{2} b t^2$, quadratically in time. Gyroscope bias behaves the same way for heading, and a wrong heading then steers the whole position estimate sideways. This is exactly why an IMU alone cannot localize for long, and why it must be fused with an absolute reference such as a camera, wheel odometry, or GPS.

# 1D dead reckoning: integrate a noisy, biased accelerometer to position.
# Truth: the body sits still, so true accel, velocity, position are all 0.
import numpy as np

dt = 0.01                       # 100 Hz IMU
steps = 2000                    # 20 seconds
rng = np.random.default_rng(1)

accel_bias = 0.05               # m/s^2 constant bias (uncalibrated)
accel_noise = 0.02              # m/s^2 white noise (1 sigma)
a_meas = accel_bias + rng.normal(0.0, accel_noise, size=steps)

vel = np.zeros(steps + 1)
pos = np.zeros(steps + 1)
for k in range(steps):
    vel[k+1] = vel[k] + a_meas[k] * dt   # integrate accel -> velocity
    pos[k+1] = pos[k] + vel[k+1] * dt    # integrate velocity -> position

t = steps * dt
print(f"after {t:.0f} s: velocity drift = {vel[-1]:.2f} m/s")
print(f"after {t:.0f} s: position drift = {pos[-1]:.2f} m")
print(f"closed-form bias term 0.5*b*t^2 = {0.5*accel_bias*t**2:.2f} m")

Practical Recipe

1. Write the observation, action, and success metric before choosing a model.
2. Build a baseline that is simple enough to debug by inspection.
3. Add the library implementation only after the baseline behavior is understood.
4. Record failures as structured cases: perception error, state error, planning error, control error, or evaluation error.
5. Run at least one perturbation test before trusting the result.

Production Pattern

IMU, wheel odometry, joint encoders, proprioception sits inside the Part II robotics contract: geometry defines where things are, kinematics defines what motion is possible, dynamics defines what motion costs, control defines how errors are corrected, and sensing defines what the agent can know on time.

Proprioceptive streams need bias, drift, quantization, and timestamp handling before fusion. This makes the section useful to students, builders, and researchers at the same time: the idea has an intuitive role, a formal interface, a runnable check, and a failure mode that can be reproduced.

Use this recipe when turning IMU, wheel odometry, joint encoders, proprioception into code, a simulator experiment, or a robot diagnostic. The point is not to use every library. The point is to keep the hand-built baseline and the maintained-tool path comparable.

1. Define each sensor message with units, frame, timestamp source, calibration file, and covariance meaning.
2. Run a static test, a slow-motion test, and a dropout test before fusing streams.
3. Compare the hand filter with FilterPy or ROS 2 robot_localization using identical measurements and noise settings.
4. Log innovation, covariance, delayed messages, rejected measurements, and downstream control effect.
5. Treat perception output as a belief with uncertainty, not as ground truth handed to the controller.

Proprioceptive failures often look like weak control. Check IMU bias, encoder quantization, wheel slip, joint zero offsets, sampling rate, and integration frame before tuning the policy.