IMU & Inertial Navigation

Chapter 1: What an IMU Actually Measures — Specific Force, Not Acceleration

We waved at "the IMU measures change." Now we get specific — literally, because the accelerometer measures something called specific force, and the gap between specific force and acceleration is the number-one confusion in inertial navigation. Get this chapter right and the rest of the lesson is downhill. Get it wrong and every position estimate you ever compute will ramp off to infinity in seconds, for a reason that looks like a bug but is actually physics.

The gyroscope — the easy half

Start with the part that behaves the way you'd expect. A gyroscope measures angular rate — how fast the sensor is rotating about each of its three axes, in radians per second (or degrees per second). Call it ω (omega), a three-element vector: rotation rate about the body's x, y, and z axes. A MEMS gyro is a tiny vibrating structure; when you rotate it, the Coriolis effect deflects the vibration, and the deflection is proportional to rotation rate. The key facts:

• It reports rate, not angle. Stationary → ω ≈ 0. Spinning at a steady 90°/s → it reports 90°/s the whole time, not an ever-growing number.
• It is measured in the body frame — the rotating frame glued to the sensor itself (more on frames in Chapter 2).
• To get orientation (which way you point) you must integrate ω over time. That single integration is where heading drift is born.

The accelerometer — the trap

Now the surprise. Ask anyone "what does an accelerometer measure?" and they'll say "acceleration." That is wrong in the one way that matters. An accelerometer measures specific force — the non-gravitational force per unit mass acting on the sensor — which is not the same as your acceleration through space. Here is the cleanest way to see it.

Inside an accelerometer is, conceptually, a tiny proof mass on a spring. The chip reports how far the spring is stretched. The spring stretches in response to whatever contact force is pushing on the mass — the electrostatic restoring force in a MEMS device, a real spring in the textbook cartoon. Crucially, gravity does not stretch the spring, because gravity pulls equally on the proof mass and on the case around it — they fall together. The spring only registers forces that act differently on the mass than on free-fall would.

Run the two thought experiments that nail it:

Read those two rows until they sting. At rest the accelerometer reads +g upward; in free fall it reads zero. The reading is the opposite of what naive intuition says. It is not measuring how you move; it is measuring the contact force that prevents you from free-falling. That force, per unit mass, is specific force, written f. The exact relationship is:

where f is the specific force the accelerometer reports, a is your true acceleration through space (what you actually want), and g is the gravity vector (about 9.81 m/s² pointing down, toward Earth's center). Read it as: the sensor gives you true acceleration minus gravity. Rearrange to get what you actually want:

This little rearrangement is the entire job of an inertial navigator's middle stage. To turn what the accelerometer reports (f) into the acceleration you can integrate for velocity and position (a), you must add the gravity vector back in. Check the table against the formula: at rest, a = 0 and g points down at 9.81, so f = a − g = 0 − (down 9.81) = up 9.81. Exactly what the table says. The signs work.

Let us make "at rest it reads up, tilt it and the components change" something you can feel. Below, an accelerometer sits in a gravity field. Tilt it and watch how the single fixed gravity vector splits into different x and y readings in the sensor's own frame — this is exactly the signal a phone uses to know which way is up when it auto-rotates your screen.

This is also the trick behind a phone's tilt sensing and a quadcopter knowing it is level: when stationary, the accelerometer's reading points straight along the support force (opposite gravity), so its direction tells you which way is up. The catch — and it is the central catch of the whole field — is that this only works while you are not accelerating. The instant the drone accelerates forward, its accelerometer can no longer tell "I tilted" from "I accelerated," because both stretch the same spring in the same way. Resolving that ambiguity is precisely what fusing the accelerometer with the gyro (Lesson 6, complementary filters / AHRS) is for.

Chapter 2: Frames — Body, Navigation, and Earth

The IMU measures everything in the body frame — the frame bolted to the chip, which rolls and pitches and yaws as the vehicle moves. But "where am I and how fast am I going" only makes sense in a frame fixed to the world: north, east, down. The entire strapdown algorithm of Chapter 3 is, at its heart, a machine for hauling measurements from the spinning body frame into a steady world frame, and a sign error in a frame definition is one of the most common and most baffling bugs in inertial navigation. So we pin the frames down first.

The three frames you must keep straight

The body frame is the rotating frame glued to the sensor. The chip's "x-axis" is wherever the manufacturer painted an arrow. Everything the IMU reports is in this frame, and the frame is tumbling around with the vehicle, which is exactly why raw IMU numbers are nearly meaningless until you rotate them out.

The navigation frame (also "local-level" frame) is a frame whose axes point along intuitive world directions at your current location. The two everyday conventions are NED (x = North, y = East, z = Down) and ENU (x = East, y = North, z = Up). They are both correct; they are both common; mixing them flips signs and is a perennial bug. In NED, the gravity vector is beautifully simple: g = (0, 0, +9.81) — straight down the positive z-axis. In ENU it is g = (0, 0, −9.81) — down the negative (Up) axis. That sign is the source of half the "my altitude estimate explodes upward" bugs in the field.

The Earth-Centered, Earth-Fixed (ECEF) frame is the global one: origin at Earth's center, rotating with the Earth. GPS gives you ECEF coordinates (or latitude/longitude/altitude, which is the same information). For a drone flying for thirty seconds over a field, you can pretend the navigation frame is fixed and ignore the Earth's rotation entirely. For a missile or an airliner flying for an hour, you cannot — the Earth spins underneath you at 15°/hour, and a navigation-grade INS must account for that Earth-rate term and for the navigation frame slowly rotating as you travel over the curved Earth (the transport rate). This lesson stays in the short-flight regime where those terms are negligible, but it is worth knowing they are the reason real INS mechanization equations are longer than ours.

How we represent the rotation between frames

To move a vector from the body frame to the navigation frame you apply a rotation. There are two standard ways to store that rotation, and an inertial navigator uses one of them as its running estimate of attitude:

We will write the strapdown update using a rotation matrix because it reads most clearly, and note where a quaternion would slot in. The deep mechanics of rotations — how a quaternion multiplies, why Euler angles gimbal-lock, how a matrix exponential turns a rotation rate into a rotation — are exactly the subject of the attitude-estimation lessons in this series; we keep this self-contained and cross-link the Complementary Filters & AHRS lesson (Lesson 6), which lives and breathes attitude representation.

Chapter 3: Strapdown Mechanization — Turning Six Numbers into a Pose

Here is the recipe that converts the IMU's six raw numbers — body-frame angular rate ω and body-frame specific force f — into the thing you wanted all along: orientation, velocity, and position in the navigation frame. It is called strapdown mechanization, and the word "strapdown" is historical: early inertial systems mounted the sensors on a physically gimballed platform that mechanically held them level, so the computer never had to track attitude. Modern systems strap the sensors down rigidly to the vehicle and do all the leveling in software. Cheaper, smaller, no spinning gimbals — but now you own the math.

The three stages, in the order that matters

Strapdown mechanization is three integration stages chained together. The order is not arbitrary — it is forced by a dependency, and understanding the dependency is understanding the lesson's whole drift story:

Why attitude must come first. Stage 2 needs to subtract gravity, and to subtract gravity correctly it must know which way "down" points in the current body frame — which is exactly what the attitude C_bⁿ tells you. If Stage 1's attitude is wrong, Stage 2 rotates the specific force into the wrong direction and adds gravity along a slightly-off axis. A sliver of the 9.81 m/s² gravity vector then leaks into the horizontal channels as phantom acceleration, and Stage 3 faithfully double-integrates that phantom into a runaway position error. Attitude error corrupts the gravity subtraction, and the gravity subtraction is the most error-sensitive step in the entire pipeline. This single dependency is why gyro errors (which spoil attitude) hurt position even more than accelerometer errors do — the formal proof is Chapter 4.

The discrete update equations

Computers work in discrete time-steps of length Δt (one over the IMU rate — for a 200 Hz IMU, Δt = 0.005 s). Here are the three stages as the update you run every tick. We write attitude as a rotation matrix C and use simple first-order integration to keep the ideas naked; real code uses higher-order and quaternion forms (and the coning/sculling corrections of Chapter 8), but the skeleton is exactly this:

Stage 1 — attitude update. A body-frame rotation rate ω over a small time Δt produces a small rotation. We update the orientation by composing the old attitude with that small rotation:

where I is the identity matrix and Ω (capital omega) is the skew-symmetric matrix built from the gyro vector ω = (ω_x, ω_y, ω_z). "Skew-symmetric" just means the matrix that turns "cross product with ω" into a multiplication; (I + ΩΔt) is the first-order approximation of the small rotation by angle ωΔt. Read it plainly: nudge the current orientation by the little rotation the gyro reported this tick. Any error in ω (a bias!) nudges it slightly wrong, every single tick, forever.

Stage 2 — specific force to nav-frame acceleration. Rotate the body-frame specific force into the nav frame, then add gravity back:

where f^b is the accelerometer reading in body frame, C_bⁿ is the attitude from Stage 1, and gⁿ is the gravity vector in nav frame — in NED, simply (0, 0, +9.81). This is the gravity-restoration step from Chapter 1 (a = f + g), now with the rotation that gets f into the right frame first. This is the line that breaks if attitude is wrong.

Stage 3 — integrate to velocity, then position. Two simple Euler integrations:

where v is velocity and p is position. The first line turns acceleration into velocity (add up the speed changes); the second turns velocity into position (add up the distances). This is the double integral that makes accel error grow as t² — and, through the corrupted gravity term, makes attitude error grow as t³.

The strapdown integrator in code — verbose, then compact

Here is the full loop as commented Python (2-D to keep it readable, but the structure is identical in 3-D — just bigger matrices). Notice the three stages map line-for-line onto the equations above:

python — verbose strapdown integrator (2-D)
import numpy as np

def strapdown_step(state, gyro_z, accel_body, dt, g=9.81):
    # state = dict with heading theta (rad), vel v (2,), pos p (2,)
    # gyro_z      : angular rate about vertical axis (rad/s), body frame
    # accel_body  : specific force (2,) in body frame  -- f = a - g

    # --- STAGE 1: attitude. integrate the gyro to update heading. ---
    theta = state['theta'] + gyro_z * dt        # a tiny gyro bias biases theta every tick

    # --- STAGE 2: rotate specific force into the nav frame, add gravity. ---
    c, s = np.cos(theta), np.sin(theta)
    C = np.array([[c, -s],                          # body -> nav rotation (C_b^n)
                  [s,  c]])
    f_nav = C @ accel_body                          # specific force, now in nav frame
    g_nav = np.array([0.0, g])                   # gravity in nav frame (here: +g on 'down' axis)
    a_nav = f_nav + g_nav                           # a = f + g  -- restore true acceleration
    # NOTE: if theta is wrong, C is wrong, so the giant g leaks into a_nav sideways.

    # --- STAGE 3: integrate acceleration -> velocity -> position. ---
    v = state['v'] + a_nav * dt                  # first integral
    p = state['p'] + state['v'] * dt           # second integral (use OLD v: simple Euler)

    return {'theta': theta, 'v': v, 'p': p}

And the same three stages, compressed — useful once you trust the structure. (Real production code adds quaternion attitude, midpoint integration, and coning/sculling, but this is the honest core):

python — compact
def step(th, v, p, wz, fb, dt, g=9.81):
    th += wz*dt                                              # 1. attitude
    c, s = np.cos(th), np.sin(th)
    a = np.array([c*fb[0]-s*fb[1], s*fb[0]+c*fb[1]+g])  # 2. C·f + g
    p = p + v*dt;  v = v + a*dt                              # 3. ∫∫ (old v for p)
    return th, v, p

Watch how the bug propagates in the verbose version: a constant gyro bias makes theta wrong by a little more each tick; that wrong theta builds a wrong rotation matrix C; C rotates the specific force into a slightly wrong direction; the +9.81 gravity term g_nav then fails to cancel cleanly, so a_nav carries a phantom horizontal acceleration; and Stage 3 double-integrates that phantom straight into a galloping position error. One bad number at the top, amplified through three integrations. That is the machine; Chapter 4 is the bill.

Chapter 4: Drift Growth — t², t³, and the Death of Dead-Reckoning

This is the emotional core of the lesson. We now compute, with real numbers, exactly how fast an unaided IMU goes wrong. There are two famous scaling laws, and once you have felt them in your gut you will never again be tempted to "just integrate the IMU." A constant accelerometer bias makes position error grow as t². A constant gyro bias makes it grow as t³ — faster, and the dominant killer in practice. We derive both from the mechanization of Chapter 3.

Accelerometer bias → t² position error

Suppose the accelerometer has a constant bias b_a — it reports an acceleration that is too large by b_a in some direction, every tick, even when nothing is happening. Walk it through Stage 3 of the mechanization (the double integral). A constant extra acceleration b_a integrates once into a velocity error that grows linearly:

and integrates again into a position error that grows as the square of time:

That ½ t² is the same shape as "distance under constant acceleration" from first-year physics — because that is exactly what it is. The bias acts like a tiny constant thruster the navigator does not know about.

Gyro bias → t³ position error (the dominant killer)

Now the worse one. Suppose the gyro has a constant bias b_g — it reports a rotation rate that is off by b_g (radians per second). Walk it through all three stages. Stage 1 integrates the gyro bias into an attitude error that grows linearly:

Now Stage 2 bites. An attitude error δθ means we think "down" is tilted by δθ from where it really is, so when we add gravity back we mis-aim it. A fraction sin(δθ) ≈ δθ (for small angles) of the gravity vector g leaks into the horizontal acceleration as a phantom:

This phantom acceleration itself grows linearly in time (because the attitude error does). Now double-integrate it (Stage 3). Integrating a term that grows like t gives t²; integrating again gives t³:

(The ¹⁄₆ is what you get integrating t twice: ∫∫ t = t³/6.) The gravity vector is the amplifier. The gyro bias is small, but it gets multiplied by the enormous g = 9.81 before it ever touches position, and then it rides a cubic instead of a quadratic. This is why, in real systems, gyro quality dominates accelerometer quality for position accuracy — and why a navigation-grade IMU spends most of its cost on the gyros.

Putting the two side by side

Here is the whole drift story in one table — the scalings that govern every unaided IMU on Earth:

The pattern is mechanical: each integration adds a power of t, and the gyro path has one extra integration than the accel path (it must pass through the attitude-to-gravity-leak stage first), which is exactly why gyro bias lands on t³ while accel bias lands on t². The random-noise rows (Chapter 5) grow more slowly than the bias rows but never stop — even a perfectly unbiased IMU random-walks away.

Now make the curves diverge in front of you. Below, dial in a gyro bias and an accel bias and watch the resulting position-error curves race apart — the accel-bias parabola and the gyro-bias cubic. This is the lesson's flagship: it is the single picture that explains why we fuse.

Drag the gyro bias up even a little and watch its purple cubic claw past the orange accel parabola — at long times the cubic always wins. That single behavior is the whole reason a navigation-grade IMU spends its money on ring-laser gyros: tame the gyro, and you tame the t³ term that dominates long-run position error.

Chapter 5: The IMU Error Model — Bias, Scale, Noise, and Allan Variance

So far we have leaned on one villain — a single constant "bias." Real IMUs misbehave in a small zoo of distinct ways, and you cannot calibrate, choose, or fuse an IMU sensibly without knowing the species. This chapter catalogs the errors and then introduces the one tool — the Allan variance — that engineers use to read them all off a single log-log plot from a datasheet.

The full error model of one axis

For a single accelerometer or gyro axis, the measured value relates to the true value roughly like this:

Each term is a different defect:

ARW and VRW — the √t laws of noise

Bias gave us t² and t³. Now the random part. The white noise on each sample has zero mean, so it does not bias you systematically — but integrating zero-mean noise does not cancel to zero; it performs a random walk, whose spread grows as the square root of time. Two named quantities capture this:

• Angle Random Walk (ARW) — the gyro's white noise, integrated once into a random walk in angle. Datasheet units: deg/√hr (degrees per square-root-hour). After time t, the heading uncertainty from noise alone is ARW × √t.
• Velocity Random Walk (VRW) — the accelerometer's white noise, integrated once into a random walk in velocity. Datasheet units: m/s/√hr (or m/s/√s). After time t, the velocity uncertainty from noise alone is VRW × √t.

The √ in the units is the tell: it encodes the random-walk √t growth directly. A gyro spec of "0.3 deg/√hr" means: leave it alone for one hour and noise alone gives ≈0.3° of heading uncertainty; for four hours, 0.3 × √4 = 0.6° (four times the time, only double the error — that is the √t mercy of random walk versus the cruelty of constant bias).

The Allan variance — reading every error off one plot

How do you measure all these from a real sensor? You log the IMU at rest for hours and compute the Allan variance (more usefully, its square root, the Allan deviation). The recipe: take your long log, chop it into bins of length τ (tau, the "averaging time"), average within each bin, and measure how much neighboring bin-averages differ. Repeat for many τ values, and plot Allan deviation against τ on a log-log graph. The shape of that curve is a fingerprint, and you read the error terms off its slopes:

The intuition for the bowl: at very short averaging times you are dominated by fast white noise (averaging longer helps, so the curve falls with slope −½); at very long averaging times the slow bias wander takes over (averaging longer now hurts, so the curve rises with slope +½); and at the bottom, the two trade off — that flat minimum is the famous bias instability number quoted on datasheets. One plot, every error.

When you read a datasheet (Chapter 8), the Allan plot — or the three numbers distilled from it (ARW, bias instability, bias random walk) — is what you are actually buying. A sensor whose bowl sits low and flat will dead-reckon far longer before its drift swallows you; a sensor with a high, narrow bowl is a phone-grade part that needs constant aiding.

Chapter 6: Grades of IMU — and the First Taste of Aiding (ZUPT)

Now the practical question: how long can a given IMU dead-reckon before its drift makes it useless? The answer spans six orders of magnitude depending on the sensor's grade, and knowing the grades lets you read the t²/t³ laws of Chapter 4 backward — from "how good is my gyro" to "how many seconds do I have before I need a fix." Then we meet the simplest possible piece of aiding, the zero-velocity update (ZUPT), as a teaser for everything the rest of the series adds.

The grade ladder

IMUs are sorted by their gyro and accel bias performance into rough tiers. The numbers below are order-of-magnitude (each tier spans a range) but the ratios between tiers are the point — and the rightmost column, "free-inertial time," is what you actually care about: how long it dead-reckons before drift dominates:

Feel the span: a phone-grade gyro can be ten thousand times worse than a navigation-grade one. That is why your phone's "inertial" heading needs the magnetometer and GPS constantly nudging it, while a submarine can stay submerged for hours with no outside fix and still know where it is to within a mile. The physics (the t³ law) is identical; only the bias b_g differs, and it differs enormously.

ZUPT — the simplest aiding there is

Here is the first crack of light. Recall the drift villain: the accelerometer bias makes the navigator believe a stationary vehicle is creeping along at a phantom velocity (Chapter 4: at 60 s, 0.6 m/s of phantom speed). Now suppose you know, from some outside fact, that the vehicle is momentarily standing still — a walking person's foot is flat on the ground mid-stride; a car is stopped at a light; a robot has paused. At that instant the true velocity is exactly zero. So you can tell the filter: "velocity = 0, and I'm sure of it."

That single assertion is a zero-velocity update (ZUPT), and it is shockingly powerful. By pinning velocity to zero whenever you detect a stationary moment, you kill the accumulated velocity error (which would otherwise integrate into ever-worse position error) and you give the filter the information it needs to estimate and subtract the accelerometer bias itself. Pedestrian dead-reckoning systems with a foot-mounted IMU use a ZUPT on every footstep (the stance phase), and that alone turns a hopeless MEMS drift into meter-level tracking over hundreds of meters — with no GPS at all.

Showcase — dead-reckon a path and watch it peel away (then ZUPT)

Time to put it all together. Below, a vehicle drives a known rectangular loop (dashed truth). We integrate a biased, noisy IMU to dead-reckon its trajectory — pure strapdown, no aiding — and watch the estimate spiral away from truth as time grows, exactly per the t³ law. Then flip on ZUPT (the vehicle pauses at each corner, and we pin velocity to zero) and watch the estimate snap back toward the truth. This is the whole lesson in one picture: drift, and the first cure.

With ZUPT off and any real bias, the estimate spirals further from the truth every lap — that is dead-reckoning dying in front of you. Toggle ZUPT on and the corner pauses pull the velocity error back to zero, dramatically tightening the spiral. It is not perfect — ZUPT only fixes velocity at the stationary instants, and heading still drifts between them — but it shows the core move of all aided navigation: inject absolute truth to bound the IMU's runaway.

Chapter 7: Use Cases & Real Products — The IMU Is Everywhere

The IMU is the most ubiquitous motion sensor on Earth — in your pocket, in every drone, in every airliner, in every VR headset, in spacecraft. Its role is almost always the same: the high-rate backbone that fills in motion between slower, absolute fixes. Let us tour where it lives and what grade each application demands, because seeing the same physics deployed from a $1 phone chip to a $1M submarine unit cements the lesson.

Phones, drones, AR/VR — the MEMS world

The IMU in your phone (a MEMS part costing under a dollar) does screen rotation, step counting, image stabilization, and feeds the AR pose estimator. It drifts hopelessly in seconds alone, so it is always fused — with the magnetometer for heading, with GPS for position, and most importantly with the camera in AR. When you place a virtual object on your table and walk around it, the IMU supplies the fast head motion (hundreds of Hz, zero latency) while the camera supplies the slow, drift-free anchor (tens of Hz). Drop the camera (cover the lens) and the AR object swims away within a second — you have just watched unaided MEMS drift. Drones use the same MEMS IMU as the inner-loop stabilizer: the flight controller reads the gyro at ~1–8 kHz to keep the craft level, far faster than GPS could ever react. AR/VR headsets fuse IMU with cameras (inside-out tracking) for exactly the reason a phone does — low-latency head motion from the IMU, drift correction from vision.

Cars and robots — tactical and automotive grade

Automotive IMUs (a notch above phone-grade) feed the vehicle's dead-reckoning during GPS dropouts — tunnels, parking garages, urban canyons — exactly the eleven-second-tunnel problem from the start of this series. They also drive stability control (ESC) and airbag deployment (the accelerometer detects the crash deceleration). Autonomous vehicles run a tactical-grade IMU as the heart of their localization stack, fused with GPS, wheel odometry, LiDAR, and cameras. Legged and wheeled robots use the IMU for balance (the gyro is the inner loop of a self-balancing robot, just like your inner ear) and as the motion prior in their SLAM.

Aircraft, missiles, submarines — the navigation-grade INS

A full Inertial Navigation System (INS) is a navigation- or strategic-grade IMU plus the strapdown computer of Chapter 3. An airliner's INS can fly for hours and stay within a nautical mile, and it is what keeps the aircraft navigating when GPS is jammed or unavailable — a safety-critical fallback. A submarine cannot receive GPS underwater at all, so its INS is its navigation: a navigation-grade unit dead-reckons the entire dive, occasionally surfacing or using other aids to reset. A missile's INS must work the instant it launches into a GPS-denied or jammed environment; the t³ drift law is precisely why guided munitions historically demanded such expensive gyros (and why GPS-aiding, when available, is such a force multiplier).

Pedestrian dead reckoning & the universal VIO/INS-GNSS backbone

First responders and soldiers in GPS-denied buildings use foot-mounted IMUs with the ZUPT trick (Chapter 6) to track position indoors. And across all of modern robotics and AR, the dominant pattern is visual-inertial odometry (VIO) and INS-GNSS fusion: the IMU is the high-rate predictor, run at hundreds of Hz, and a camera or GPS supplies the low-rate correction. The IMU's job is identical in every one of these systems — predict fast, get corrected slowly.

Chapter 8: Practical Application — Datasheets, Grades, Calibration

You have an application and a budget; you need to pick an IMU, read its datasheet, and calibrate it. This chapter is the field guide. The recurring theme: every datasheet number maps directly onto a drift law from Chapter 4, so reading a datasheet is reading your future drift.

Reading a datasheet — the numbers that matter

Ignore the marketing; find these lines:

Worked unit-conversion you will do constantly. A datasheet says "ARW = 0.3 deg/√hr." How much heading noise after 10 minutes? 10 min = 1/6 hr, so noise = 0.3 × √(1/6) = 0.3 × 0.408 = 0.12°. And "gyro bias instability = 5°/hr": that is the floor your heading wanders at — over a 1-minute aiding gap, roughly 5°/hr × (1/60) hr = 0.083° of irreducible drift, before noise. Convert everything to consistent units (often deg/s and m/s²) before plugging into the Chapter-4 laws.

Choosing the grade for the job

The decision is driven by one question: how long must I dead-reckon between absolute fixes, and to what accuracy? Then solve the drift law backward:

• Continuous aiding available (GPS or camera every fraction of a second, as in a phone or drone)? A MEMS part is fine — you never let it drift long enough to matter. Don't overpay.
• Tens of seconds of dropout (a car through a tunnel, a UAV losing GPS lock)? Tactical grade — enough endurance to coast the gap within lane-level error.
• Minutes to hours unaided (a submarine, a jammed missile, a transoceanic flight)? Navigation/strategic grade — pay for the gyros, because the t³ term is unforgiving over long t.

Calibration — estimating the turn-on bias

The single most valuable, free calibration: estimate the bias at rest. Before you move, hold the IMU perfectly still for a few seconds and average the readings. The gyro should read zero, so its average is the turn-on gyro bias — subtract it from every subsequent sample. The accelerometer should read exactly g pointing up, so the average minus the known gravity vector gives the accel bias (and the direction tells you the initial level/tilt). This one trick removes the turn-on bias, the biggest single contributor to early drift:

python — estimate & remove turn-on bias at rest
import numpy as np

def calibrate_at_rest(gyro_samples, accel_samples, g=9.81):
    # average a few seconds of STATIONARY data
    gyro_bias  = np.mean(gyro_samples, axis=0)        # gyro should read 0 -> mean IS the bias
    accel_mean = np.mean(accel_samples, axis=0)
    # accel should read +g 'up'; whatever's left over is bias (assumes level)
    accel_bias = accel_mean - np.array([0, 0, g])
    return gyro_bias, accel_bias

# then, every live sample: corrected = raw - bias
# gyro_c  = gyro_raw  - gyro_bias
# accel_c = accel_raw - accel_bias

The catch from Chapter 5: this only removes the turn-on bias. The in-run bias keeps wandering, which is why a good fuser keeps estimating bias online (as a filter state) rather than trusting a one-time calibration forever.

Coning, sculling, and sample rate — why high rate matters

Two subtle dynamic errors lurk when the simple first-order integration of Chapter 3 meets real, fast motion. Coning is attitude error that appears when an axis traces a cone (combined oscillation in two axes) faster than your update rate can resolve — the naive integration systematically under-rotates. Sculling is the velocity analog: a correlated oscillation between angular rate and specific force that a naive integrator mis-integrates into a spurious velocity. Production strapdown code applies dedicated coning and sculling compensation terms and integrates at very high rate precisely so these high-frequency effects are captured rather than aliased. The practical takeaway: sample the IMU much faster than the highest vibration/dynamics frequency — a drone's prop vibration is hundreds of Hz, so its IMU runs at kHz. Under-sample and coning/sculling/aliasing inject errors no calibration can remove.

Chapter 9: Debugging & Failure Modes — Reading the Symptom

When an inertial navigator misbehaves, the shape of the error tells you the cause. A linear ramp, a parabola, a sign flip, a temperature-correlated wander — each points at a specific bug. This chapter is the symptom-to-cause lookup table that turns hours of confusion into a five-minute diagnosis. The unifying skill: look at the error's growth shape and its correlation with conditions.

The diagnosis table

The two signature shapes, derived

The two most common bugs have unmistakable signatures, and knowing the math lets you read the bias off the plot. A velocity ramp at rest is an accelerometer bias. If the navigator thinks a stationary vehicle's speed is climbing in a straight line, that line's slope is the accel bias: δv = b_a·t, so slope = b_a. Read the slope, you have the bias, subtract it — bug fixed. A position parabola at rest is also accel bias (the integral of the velocity ramp), and a slowly curving heading is gyro bias (the path bends because the heading is winding off at b_g·t). The shapes are not coincidences — they are the Chapter-4 laws made visible in your log.

Detecting clipping and time-sync issues

Saturation/clipping shows up as a flat ceiling on the acceleration trace during the hardest part of a maneuver — the signal hits the full-scale rail and stops following reality. The fix is to set a wider full-scale range (at the cost of resolution) or pick a part rated for your dynamics; a drone hitting prop-wash spikes or a car in a hard crash can easily exceed a default ±2 g range. Time-sync errors are subtle and brutal in fusion: because the IMU runs so fast, a small timestamp skew between the IMU and the camera/GPS means you correct the IMU prediction with a fix that belongs to a different instant, and the filter fights itself — jittery, lagging, or diverging pose. Detect it by checking whether the fusion error correlates with vehicle speed (a fixed time offset × velocity = a position error that scales with speed). The fix is hardware timestamping or estimating the time offset as a filter state.

Chapter 10: Connections — The Drift Problem Has an Answer (Next Lesson)

We have built the IMU from zero: what it measures (specific force and angular rate, in the body frame), how strapdown mechanization turns those six numbers into a pose, and — the heart of it — why that pose drifts as t² and t³ until an unaided IMU is hopeless within seconds to minutes. That last fact is not a dead end. It is a setup.

Where this connects in the series

Cheat-sheet

References

1. Groves, P.D. Principles of GNSS, Inertial, and Multisensor Integrated Navigation Systems, 2nd ed. Artech House, 2013. — the modern standard reference for INS mechanization, error models, and integration.
2. Titterton, D. & Weston, J. Strapdown Inertial Navigation Technology, 2nd ed. IET, 2004. — the definitive treatment of strapdown mechanization, coning/sculling, and gimballed vs. strapdown history.
3. Farrell, J.A. Aided Navigation: GPS with High Rate Sensors. McGraw-Hill, 2008. — the bridge from this lesson to the next: how aiding (GPS, ZUPT) bounds inertial drift.
4. El-Sheimy, N., Hou, H. & Niu, X. "Analysis and Modeling of Inertial Sensors Using Allan Variance." IEEE Trans. Instrumentation and Measurement, 2008. — the practical guide to reading IMU errors off an Allan-deviation plot.

"An inertial navigator is a memory with no eyes. It remembers, beautifully, where it was — and forgets, catastrophically, where it is. The art of navigation is teaching it to open its eyes, just often enough." — on the necessity of aiding.