Dead Reckoning Loop¶
State-estimation loop — instantiates Oriented Goal Wayfinding
Maintains a running position estimate by integrating heading and distance from a known fix, with no external reference — accurate in the short run, drifting in the long.
A Dead Reckoning Loop answers "where am I now?" by deduction from motion: start from a last known fix, and at every tick add the distance travelled in the current heading onto the previous estimate. Its one defining idea is that it uses no external reference — no landmark, no map match, no fresh fix from outside. Position is computed purely from the agent's own record of how it has moved. That self-containment is its whole virtue and its whole weakness: it works anywhere, always, at high update rate, needing nothing from the world — but every small error in heading or distance is folded permanently into the estimate, so accumulated drift grows without bound until something outside corrects it. The loop's real product is therefore a position estimate carrying an honest, expanding uncertainty, not a fixed truth.
Example¶
An autonomous mobile robot threads the aisles of a warehouse where satellite positioning is useless indoors. It runs a dead reckoning loop: wheel encoders count each revolution to give distance, a gyroscope tracks heading, and every few milliseconds the robot vector-sums that motion onto its previous pose. Rolling from the charging dock to bay 14, it stays confident and precise — for the first thirty meters the estimate is within a couple of centimeters. But the left wheel slips slightly on a patch of spilled shrink-wrap, and that unmeasured error is now baked in. By the far end of a long loop the robot's own belief about its position has drifted a good fifteen centimeters from reality, and — critically — it knows this, because the loop widens its uncertainty band with distance travelled since the last fix. It keeps moving on the estimate but flags that the band is approaching the point where it must be corrected against something external.
How it works¶
The loop is a tight integrate-and-accumulate cycle. It is seeded with a known fix. Each iteration reads two things — a heading (from a compass, gyro, or steering state) and an increment of distance (from an odometer, speed × time, or step count) — and composes them into a displacement, which is added to the running position estimate while the orientation state is updated to the new heading. In parallel it advances a drift term: because nothing corrects the estimate, error variance grows monotonically with distance since the last fix, and the loop carries that growth explicitly rather than pretending the estimate is exact. What the loop deliberately does not do is consult the outside world to reset itself; that correction is a separate act, performed by a different mechanism, that this loop is designed to hand off to.
Tuning parameters¶
- Integration interval — how often to sample motion and update. Faster sampling captures sharp maneuvers but amplifies sensor noise; slower sampling smooths noise but misses quick turns.
- Sensor quality / set — which motion sensors feed the loop and how good they are. Better inertial sensors slow the drift rate but cost more; the trade is dollars against how far you can go before a fix is mandatory.
- Drift model — how aggressively the uncertainty band widens per unit distance. Set it too tight and you overtrust a stale estimate; too loose and you demand corrections you do not yet need.
- Re-zero cadence — how far or how long the loop runs before it must be handed off for an external fix. This is the leash length on accumulated error.
- Heading source — magnetic, gyroscopic, or steering-derived, each with its own bias signature.
When it helps, and when it misleads¶
The loop's strength is availability: it produces a live position estimate in exactly the conditions where external references fail — tunnels, indoors, underwater, undersea, jammed or absent satellite signal — and it does so cheaply and continuously. For short spans it is remarkably accurate, and it degrades gracefully and knowably, widening its own error bars as it goes.
Its failure mode is unbounded error growth. A tiny, consistent heading bias compounds into a large positional error over distance; the estimate can be smooth, confident, and completely wrong, because the loop has no way to notice it has diverged from reality — it is, structurally, blind.[n1] The classic misuse is running dead reckoning too long between fixes and then trusting the number as if it were measured rather than deduced. The guarding discipline is to treat the loop as a bridge between fixes, not a source of truth: bound how far it runs before an external correction, and always carry the drift band forward so downstream decisions see the growing uncertainty rather than a falsely crisp coordinate.
How it implements the components¶
current_position_estimate— its primary output: the running, integrated estimate of where the agent is.orientation_state— it maintains heading/attitude each tick as part of the integration.progress_and_drift_metric— it tracks accumulated drift explicitly, widening the uncertainty band with distance since the last fix.
It does not implement recalibration_checkpoint or landmark_and_cue_set — correcting the drift against a reference map is map_matching_and_recalibration, and orienting from recognized features is landmark_based_wayfinding; dead reckoning takes no external fix at all.
Related¶
- Instantiates: Oriented Goal Wayfinding — it supplies the continuous position estimate the loop reasons from between fixes.
- Sibling mechanisms: breadcrumb_trail · guided_traversal_protocol · landmark_based_wayfinding · local_search_with_backtracking · map_matching_and_recalibration · orientation_overlay · route_replanning · turn_by_turn_route_guidance · waypoint_decomposition
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: The loop integrates heading and distance increments from a known fix into a running position estimate while explicitly advancing drift uncertainty, so its operative form is recursive state estimation.
Nearest alternative: Control, Automation & Runtime — It updates continuously during operation, but it only estimates state and does not actuate a target from the estimate.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Marine Science & Oceanography
Origin pattern: Historically ambiguous
Present-day reach: Multi-domain
Rationale: Navigation practice cohered dead reckoning as repeated integration of speed, heading, and elapsed time from a last known fix without an external reference.
Related originating lineages:
- Aviation & Aeronautics — Aviation formalized a later dead-reckoning lineage for position propagation between external fixes.
- Robotics & Automation — Robotics formalized odometric dead reckoning with propagated uncertainty and periodic external correction.
Review resolution: The named method is historically rooted in maritime navigation; aviation and robotics are later, genuine formalizing lineages rather than the first disciplinary home.
Attribution caveat: Dead reckoning predates modern disciplinary boundaries; maritime navigation is historically prior, while aviation and robotics formalized later lineages.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Dead reckoning and map_matching_and_recalibration are complementary halves of one estimator: this loop produces a drifting estimate; that mechanism consumes and corrects it at checkpoints. Neither is complete alone — dead reckoning without correction drifts away, correction without a continuous estimate has nothing to snap.
[n1] In inertial and odometric navigation, position is obtained by integrating motion, so measurement errors accumulate and the estimate "drifts" ever farther from truth the longer it runs without an external fix. Bounding this drift with periodic corrections is the standard practice precisely because the integrator itself cannot detect its own divergence. ↩