"Give me a perfect accelerometer and one honest second, and I will tell you where you are. Give me a real one and a full minute, and I will tell you a beautiful, confident lie."
A Dead-Reckoning AI Agent
Why this section matters
An inertial measurement unit senses acceleration and angular rate, nothing else. It never measures position. To turn those rates into a trajectory you must integrate, and integration is where a tiny, boring measurement error stops being boring: it compounds. This section is about the mechanization that converts raw inertial samples into position, velocity, and attitude, and about the drift that mechanization inevitably grows. Understanding drift is not pessimism; it is the design principle behind every navigation system on Earth. Once you can predict how fast an unaided solution rots, you know exactly how good your aiding source (GNSS, a wheel encoder, a camera, a foot-contact detector) has to be, and how often it must speak up. Everything after this section, from zero-velocity updates to GNSS-inertial fusion, exists to fight the growth curve you are about to derive.
This section assumes you can already carry an attitude estimate forward in time. Section 24.1 gave us quaternions and rotation matrices; Sections 24.2 and 24.3 built filters that keep orientation honest against gravity and the magnetic field. We take that attitude solution as an input and ask the next question: given orientation, the specific-force reading of an accelerometer, and the raw physics of the sensors from Chapter 23, how do we get to a position, and how badly does that position degrade over time? We write the navigation state as position \(\mathbf{p}\), velocity \(\mathbf{v}\), and attitude \(\mathbf{q}\) (or its matrix \(\mathbf{R}\)), all expressed in a navigation frame, and the raw IMU outputs as specific force \(\mathbf{f}^b\) and angular rate \(\boldsymbol{\omega}^b\) in the body frame.
Strapdown mechanization: from raw samples to a trajectory
A strapdown inertial navigation system bolts the sensors rigidly to the vehicle (as opposed to the old gimballed platforms that physically held a stable table) and does the stabilization in software. The core loop, called mechanization, runs three integrations in cascade every timestep. First, angular rate updates attitude. Second, the accelerometer's specific force is rotated into the navigation frame, gravity is added back, and the result is integrated into velocity. Third, velocity is integrated into position. In continuous time:
$$\dot{\mathbf{q}} = \tfrac{1}{2}\,\mathbf{q}\otimes\begin{bmatrix}0\\ \boldsymbol{\omega}^b\end{bmatrix}, \qquad \dot{\mathbf{v}} = \mathbf{R}(\mathbf{q})\,\mathbf{f}^b + \mathbf{g}, \qquad \dot{\mathbf{p}} = \mathbf{v}.$$The key term is \(\mathbf{R}(\mathbf{q})\,\mathbf{f}^b + \mathbf{g}\). An accelerometer at rest on a table reads roughly \(+9.81\ \mathrm{m/s^2}\) upward, because it senses the normal force holding it up, not the gravitational field itself. Specific force is "acceleration minus gravity," so to recover kinematic acceleration you must add the gravity vector back after rotating the reading into the navigation frame. This single subtraction is the most error-sensitive step in the whole pipeline, and the next subsection explains why.
Attitude error leaks straight into position through gravity
Because gravity is about \(9.81\ \mathrm{m/s^2}\), a tilt error of just one degree misaligns the gravity cancellation by \(9.81 \sin(1^\circ) \approx 0.17\ \mathrm{m/s^2}\). That phantom horizontal acceleration is indistinguishable from real motion. Integrated twice over \(60\) seconds it becomes \(\tfrac{1}{2}(0.17)(60)^2 \approx 308\) meters of position error, from a one-degree tilt alone. This is why orientation estimation (the previous three sections) is not a separate hobby from navigation: in a strapdown system, every attitude error becomes a position error, amplified by \(g\) and by double integration.
The growth of drift: why unaided position error explodes
Drift is what we call the accumulation of error in an integrated quantity. To see its shape, take the simplest possible fault: a constant accelerometer bias \(b_a\), a small offset the sensor adds to every reading. Integrating a constant bias once gives a velocity error that grows linearly, \(\delta v(t) = b_a\, t\). Integrating again gives a position error that grows quadratically:
$$\delta p(t) = \tfrac{1}{2}\, b_a\, t^2.$$A gyroscope bias \(b_g\) is worse. It first corrupts attitude linearly, that tilt then couples into the gravity term, and the resulting acceleration error is integrated twice, so unaided position error from gyro bias grows cubically, proportional to \(g\, b_g\, t^3\). White noise on the sensors adds a random walk on top of these deterministic terms. The practical upshot is a hierarchy of time horizons: a good inertial solution is excellent for a fraction of a second, usable for a few seconds, and worthless after a minute unless something external corrects it. Table 24.4.1 makes the horizons concrete for representative bias levels.
| Elapsed time | From accel bias \(b_a = 10\ \mathrm{mg}\) (\(\tfrac{1}{2}b_a t^2\)) | From gyro bias \(b_g = 10\ ^\circ/\mathrm{h}\) (\(\tfrac{1}{6} g\, b_g\, t^3\)) |
|---|---|---|
| 1 s | 0.05 m | 0.00008 m |
| 10 s | 4.9 m | 0.08 m |
| 60 s | 177 m | 17 m |
| 600 s | 17.7 km | 17 km |
Table 24.4.1 carries the lesson of the whole section. At short horizons the accelerometer bias dominates (its \(t^2\) starts faster); at long horizons the gyro's \(t^3\) overtakes everything. Neither is survivable unaided beyond a minute at these consumer-grade bias levels. The code below reproduces the accelerometer column so you can watch the parabola open up.
import numpy as np
def dead_reckon_1d(accel, dt, bias=0.0):
"""Integrate a 1-D specific-force stream into velocity and position."""
a = accel + bias # sensor adds a constant offset
v = np.cumsum(a) * dt # first integration -> velocity
p = np.cumsum(v) * dt # second integration -> position
return p
fs, T = 100.0, 60.0 # 100 Hz for 60 s
dt = 1.0 / fs
truth = np.zeros(int(T * fs)) # the object is actually stationary
bias = 10e-3 * 9.81 # 10 mg expressed in m/s^2
p_est = dead_reckon_1d(truth, dt, bias=bias)
print(f"drift after {T:.0f}s from a 10 mg bias: {p_est[-1]:.1f} m")
# drift after 60s from a 10 mg bias: 176.6 m
cumsum turns a constant offset into the \(\tfrac{1}{2}b_a t^2\) parabola, reaching 177 m of phantom travel in one minute while the object never moved.Modeling the error: the error-state formulation
Rather than track the full nonlinear navigation state directly inside a filter, inertial engineers almost universally track a small linear error state: the deviation of the estimated position, velocity, and attitude from truth, together with the slowly varying sensor biases. The reason is practical. The true state spans hundreds of meters and many meters per second; the error state stays small, so its dynamics are well approximated by a linear model, which is exactly what a Kalman filter wants. The error propagates as \(\delta\dot{\mathbf{x}} = \mathbf{F}\,\delta\mathbf{x} + \mathbf{G}\,\mathbf{w}\), where \(\mathbf{F}\) encodes the couplings we just derived (velocity error feeds position, attitude error feeds velocity through gravity, gyro bias feeds attitude) and \(\mathbf{w}\) is the sensor noise driving the growth of covariance. This error-state Kalman filter is the backbone of GNSS-inertial navigation; we build the general machinery in Chapter 9 and specialize it to positioning in Chapter 25.
A crucial subtlety belongs to Chapter 23's territory but bites hardest here: the sensor error model must include not just bias but scale-factor error and axis misalignment, and the biases themselves are temperature-dependent and turn-on-to-turn-on random. A calibration that ignores temperature will leave a residual bias that no filter can distinguish from motion until an aiding measurement contradicts it. This is also where sampling discipline from Chapter 3 matters: an error in \(dt\), or unsynchronized accelerometer and gyroscope timestamps, injects its own drift that masquerades as bias.
Let a mechanization library do the strapdown loop
A correct strapdown mechanization is more than the three-line cascade above: it needs quaternion normalization, the specific-force-to-navigation-frame rotation, gravity and (for long baselines) Coriolis and transport-rate terms, and coning/sculling correction for high-rate motion. Hand-rolled, a production-grade loop with an error-state filter runs to several hundred lines. Libraries such as ahrs and the strapdown utilities in navpy or pyins collapse the propagation to a handful of calls:
from ahrs.filters import EKF # error-state INS/AHRS propagation
ekf = EKF(gyr=gyro, acc=accel, frequency=100.0)
attitude = ekf.Q # quaternion trajectory, coning-correctedReach for the library for the mechanization plumbing; keep writing your own error budget by hand, because the drift analysis is the part you actually have to understand to design the system.
The automotive tunnel: 30 seconds without GNSS
A production automotive navigation unit relies on GNSS for absolute position, but tunnels, urban canyons, and parking garages routinely black out the satellites for tens of seconds. During those gaps the system dead-reckons on its automotive-grade IMU plus wheel-speed and steering. Engineers size the IMU precisely against the worst expected outage: a 30-second tunnel with a curve. A gyro bias of \(10\ ^\circ/\mathrm{h}\) alone would build tens of meters of cross-track error over that span (Table 24.4.1), enough to place the car in the wrong lane at the exit. The fix is not a magic sensor; it is aiding. Wheel odometry pins the along-track velocity and the non-holonomic constraint (a car cannot slide sideways) pins the cross-track velocity, so the inertial solution only has to coast the short gaps between constraints. This is dead reckoning done right: inertial fills the milliseconds, cheaper sensors bound the drift, and GNSS re-anchors the moment it returns. The same tunnel with a raw phone IMU and no wheel aiding would drift into a neighboring building.
Research frontier: learning to bound inertial drift
The classical answer to drift is external aiding. A newer line replaces or augments the mechanization itself with learned models. TLIO (Liu et al., 2020, "TLIO: Tight Learned Inertial Odometry") trains a network to regress displacement and its uncertainty from raw IMU windows, then feeds those pseudo-measurements into a stochastic-cloning Kalman filter, cutting pedestrian drift by an order of magnitude over strapdown integration. RONIN (Herath et al., 2020) and the earlier IONet showed that a data-driven prior on human motion can constrain the double integral where physics alone cannot. The open frontier is generalization: a network trained on one carry pattern, device, or gait can inherit new biases on another, so uncertainty calibration (Chapter 18) is as important as the point estimate. We build these learned inertial-odometry models in Section 24.6.
Exercise: size the IMU for a 20-second dropout
You are designing a delivery robot that loses GNSS for up to 20 seconds under dense tree cover and must not drift more than 2 meters horizontally during a gap. (1) Using \(\delta p = \tfrac{1}{2} b_a t^2\), what is the maximum tolerable constant accelerometer bias, in mg? (2) Using \(\delta p \approx \tfrac{1}{6} g\, b_g\, t^3\), what maximum gyro bias, in degrees per hour, meets the same 2-meter budget? (3) Which sensor is the binding constraint at 20 seconds, and how does the answer change if the dropout is only 5 seconds? Comment on whether a MEMS-grade IMU can meet the budget unaided, or whether you must add odometry.
Self-check
- An accelerometer at rest reads about \(+9.81\ \mathrm{m/s^2}\), yet it is not accelerating. Explain why in terms of specific force, and describe what the mechanization must add back before the second integration.
- Rank the growth-with-time of position error from (a) a constant accelerometer bias, (b) a constant gyroscope bias, and (c) white accelerometer noise. Why does the gyro bias eventually dominate?
- Why do inertial navigation systems track a small error state in the Kalman filter rather than the full navigation state directly? Give the practical reason in one sentence.
What's Next
In Section 24.5, we exploit the one moment a strapdown system gets a free measurement: when a foot is planted flat on the ground, its velocity is momentarily zero. Zero-velocity updates and pedestrian dead reckoning turn that fleeting physical fact into a recurring correction that clamps the very drift we just watched explode, and they do it without any external radio, camera, or map.