Counting motion is not enough to know position
A mobile robot carries components along an industrial aisle. Encoders count wheel rotation without missing pulses, yet software places the vehicle off its expected path. Before adding a neural network, understand how turns become distances, distances rotate the chassis and rotations accumulate on the map. We distinguish two problems requiring different remedies: poorly approximating correct motion and perfectly integrating motion inferred with wrong parameters.
Abstract. Derive planar two-wheel odometry without slip, with constant wheel velocities per interval. Track width.5 m, left travel 1 m and right 1.02 m yield heading.04 rad and position approximately(1.009731,.020197)m. Compare exact-arc integration with Euler and measure numerical convergence. In a separate case both wheels really travel 10 m, but software uses a 2% larger right radius: exact integration ends about two metres from true position. This deterministic simulation is neither hardware benchmark nor safety evidence.
The model: wheels, chassis and assumptions
Let b be the full distance between wheel rolling points, not half the track. Chassis coordinates originate midway: x forward, y left, angle positive counterclockwise. Δl,Δr are positive for forward travel. Global pose(x, y,φ) uses metres and radians. Acceleration, tire deformation, slopes and payloads are absent. No-slip rolling is the assumption making chassis motion inferable from wheel rotation alone.
Modern Robotics section 13.4 by Kevin Lynch and Frank Park explains wheel increments, chassis motion and matrix-exponential integration; we read its technical explanation. Our scalar differential-drive example uses independent data and explicit full-width b. Mixing half-track and full-track conventions introduces a factor-two error. We run neither their software nor an EL-AI robot estimate.
From wheel to arc
Wheel radius r and encoder increment Δθ imply distance rΔθ. Perfect pulse counting does not certify effective radius. Mean wheel travel gives centre arc length; travel difference divided by b gives rotation. More right-wheel travel turns left, matching our positive sign. This is geometry, requiring no learned function.
Integrate the curve, not its tangent
Convert arc length and rotation into Cartesian displacement. With constant wheel velocities the centre follows a circular arc, radius R=Δs/Δφ for nonzero Δφ. In the initial chassis frame, forward displacement is RsinΔφ and lateral R(1−cosΔφ). The formula asks where the centre ends after turning while moving, not moving fully before turning.
u, v are metres in the initial chassis frame. cosφ, sinφ rotate the increment into map coordinates before adding x, y. A metre forward while facing north is not a metre along map x. Heading instead adds angles. Our φ is unwrapped; trigonometry accepts multiple revolutions. Applications may normalize angles with a consistent convention.
As Δφ approaches zero, sinΔφ/Δφ→1 and(1−cosΔφ)/Δφ→0, recovering u=Δs, v=0. Code uses this limit below 10⁻¹²rad rather than dividing by zero, adequate for tested values. Robust small-angle code may use sinc or series because 1−cosΔφ subtracts near-equal values. No library or hardware comparison was run: exact derivation differs from floating-point evaluation.
From origin φ=0, the example yields x=1.009730688 m, y=.020197307 m,φ=.04 rad. Putting all Δs along initial heading gives(1.01,0)m, then updates angle: explicit Euler, the initial tangent approximating an arc. It is a legitimate numerical approximation with step-dependent error. Confusing results hides roughly two lateral centimetres in this constructed interval.
A numerical error we can reduce
Fix total Δl=10 m,Δr=10.2 m and split into N equal intervals. This subdivides known constant-velocity synthetic data, not a physical encoder frequency. Exact final pose is(9.832813143,1.993209901)m, heading.4 rad, invariant to subdivision within numerical tolerance. Euler approaches it with increasing N. Error is Euclidean final-position distance in metres, not lateral error alone or collision probability.
| N | Euler error (m) |
|---|---|
| 1 | 2.011038172 |
| 10 | 0.200660483 |
| 100 | 0.020065607 |
| 1000 | 0.002006560 |
Tenfold more intervals reduce error about tenfold, consistent with first-order global Euler convergence here, not proof for every drive. If wheel velocities change within an interval, constant-velocity arcs can also approximate: total increments may omit temporal order. We have isolated method error under declared motion. Next keep exact integration but change input information quality.
A calibration error integration cannot fix
In scenario 2 true motion is straight: both actual radii.1 m, each encoder totals 100 rad, giving 10 m per wheel. Software uses.1 m left but.102 m right, a 2% parameter error, converting turns into 10 and 10.2 m. These match the earlier curved inputs, but that curve is now an estimate, not truth. Two explicitly different scenarios share the integrator’s numerical input.
Exact integration with 100 subdivisions estimates(9.832813143,1.993209901)m versus true(10,0)m and true heading 0: distance 2.000209278 m. More subdivisions cannot remove it: integration correctly follows a wheel difference absent in reality. Apparent heading.4 rad continuously rotates estimated forward travel, accumulating lateral displacement, rather than merely adding 2% to path length.
What encoders do not observe
A wheel slipping in place can produce the same pulses as real forward rolling. Encoders alone cannot distinguish them without assumptions. Effective radius and track can depend on contact and mechanics. These effects were not simulated, so two metres is not a universal robot-error prediction. Counter precision, parameter correctness and localization quality differ; an accurate encoder does not alone establish accurate localization.
Cameras or environmental references can add actual-motion evidence, but fusion introduces calibration, timing, noise and shared errors. No Kalman filter, visual localization or SLAM—simultaneous localization and mapping—is run here, and no performance is invented. Odometry remains a useful model-dependent input to compare with external evidence, not absolute pose truth.
Reproducibility and an industrial system
Each pose update uses constant work and memory unless trajectories are retained; plotted paths use O(N) memory. No randomness or seed; Python 3.14.0, Matplotlib 3.11.2 are recorded. Assertions check straight travel, arc subdivision equivalence and numerical comparisons. Displayed code recalculates 1,10,100 intervals, showing exact invariance and Euler convergence directly rather than treating screenshots as data.
A real test should separate parameter calibration from evaluation on unused paths, recording ground, payload, speed, radii, track, encoders and external-reference uncertainties. This protocol is proposed, not executed. Simulation proves no safety, compliance or suitability near people. Industrial/collaborative robotics is EL-AI’s stated exploration direction, not evidence here of a developed mobile product, customer or installation.
Correct turn counts can still give wrong position because counting is only the first link. Exact arcs solve integration under assumptions, not wrong parameters or unobserved motion. The same numerical inputs illustrated distinct declared physical truths. Before asking AI to compensate drift, ask what error comes from approximation and what from missing information.
from experiment import integrate
for n in [1,10,100]:
print(n,integrate(n,exact=True)[0],integrate(n,exact=False)[0])Code, data, and instructions · JSON. Educational calculations executed with Python 3.14.0; figures with Matplotlib 3.11.2. AI-assisted analysis, without claiming peer review or human review. Original illustrative ImageGen cover: it does not document EL-AI people, premises, or installations. Sources accessed 17 October 2026.