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

"The world did not tell the robot it had moved. The encoders did."

A Wheel That Kept Its Own Counsel

Bolt a perfect robot to a workbench, power it down to zero motion, and its own inertial sensor will still swear it has wandered ten meters away within twenty seconds: that confident lie, born from a bias too small to see, is the central drama of proprioception. Figure 8.3A shows how the three proprioceptive sensors at the heart of that lie sit together on one mobile manipulator, each feeding a different part of the state estimate. This section defines the object of study, connects it to the agent loop, and tests it with a compact implementation.

The key question 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

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, a phenomenon engineers call quadratic drift from bias. 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. Pin every sensor to its physical coordinate frame before writing a single line of fusion code. For a TurtleBot 3 or Clearpath Husky, this means verifying the IMU's base_link-to-imu_link static transform in your URDF (Unified Robot Description Format, the XML file that defines a robot's links, joints, and sensor frames); a sign flip in any axis silently turns a forward acceleration into a reverse command.
2. Run a stationary bias test for at least 60 seconds at operating temperature. A Bosch BMI088 on a cold desk reads a different gravity vector than the same chip after five minutes of motor-on current; record both and compare before accepting a factory calibration.
3. Stress the odometry model with three primitives: drive 1 m straight on the real floor surface, turn 360 degrees in place, and execute a stop-start cycle. A TurtleBot 3 Burger on polished concrete shows roughly 2 percent slip on the straight run and 1.5 degree heading error per full rotation (typical laboratory measurements as of 2024; values vary with wheel wear and surface condition); on carpet those numbers double. Know your floor before trusting your map.
4. For a manipulator such as the Franka Emika Panda or a Universal Robots UR5e, check each joint's commanded-versus-measured angle during a slow joint-space sweep. A gap larger than 0.1 degrees at low velocity usually points to a stale zero calibration or a missed homing step, not a controller bug.
5. Log IMU innovation residuals, encoder tick-rate drop-outs, and timestamp jitter side by side with the controller output. On ROS 2, ros2 topic hz /imu/data and ros2 topic delay /imu/data expose rate and latency in real time; a jitter spike above 5 ms at 100 Hz produces a velocity estimate error that appears as a tremor in the end-effector trajectory.

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 in a Kalman or extended Kalman filter. The idea has an intuitive role, a formal interface, a runnable check, and a failure mode that can be reproduced, making it useful to practitioners, builders, and researchers alike.

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.