Case Study 2 — Computing Distance from Velocity Recordings

Field: Physics and transportation engineering Tools from this chapter: the integral as accumulated total (§13.9), displacement vs. distance (§13.10), signed area (§13.6), and the trapezoidal rule applied to data (§13.13).

A sensor that knows speed but not position

A modern phone, drone, or car does not directly measure where it is from moment to moment; it measures how fast it is going. An accelerometer integrated by the device's chip, a wheel-speed sensor, a GPS Doppler reading — all of them report velocity at a stream of closely spaced times. The position must then be reconstructed. The reconstruction is pure Chapter 13: velocity is the rate at which position changes, so by §13.9 the integral of velocity over a time interval accumulates the change in position.

The catch is that we never get a velocity formula. We get a table — velocity sampled at discrete instants. There is no $v(t)$ to find an antiderivative of, even if we wanted one. So we do what §13.13 prescribes: feed the data straight into a Riemann-type sum.

Consider a sprinter wearing a velocity tracker, recorded every two seconds over a 20-second effort:

She starts from rest, accelerates to a peak near 24 m/s around the 10-second mark, then tires and coasts back to a stop. How far did she run?

Distance is the area under the velocity curve

Because the sprinter never reverses direction — her velocity stays $\ge 0$ the whole time — distance and displacement coincide here (§13.10), and both equal the area under the velocity graph: $$\text{distance} = \int_0^{20} v(t)\,dt.$$ We cannot evaluate that integral exactly without a formula for $v$. But we can approximate it from the table, and with eleven data points spaced $\Delta t = 2$ apart, the natural tool is the trapezoidal rule of §13.13: $$T_n = \frac{\Delta t}{2}\Big[v_0 + 2v_1 + 2v_2 + \cdots + 2v_{n-1} + v_n\Big].$$ The interior readings are doubled because each is shared by two adjacent trapezoids; only the first and last readings appear once.

Sum the nine interior velocities first: $$8 + 15 + 20 + 23 + 24 + 22 + 18 + 12 + 5 = 147.$$ The endpoints $v_0 = 0$ and $v_{10} = 0$ contribute nothing. So $$T_{10} = \frac{2}{2}\Big[0 + 2(147) + 0\Big] = 1 \cdot 294 = 294 \text{ meters}.$$ The sprinter covered about 294 meters. We extracted a distance from a sensor that only ever knew speed — exactly the reconstruction every fitness watch and inertial navigation system performs thousands of times a second.

How much should we trust 294 meters?

A single estimate is only as good as its resolution. Why trust the trapezoidal rule over, say, a crude left-rectangle sum? Recall from §13.13 that the trapezoidal rule is the average of the left and right sums, $T_n = \tfrac12(L_n + R_n)$, and that averaging cancels much of their opposite-signed error. Let us see the spread.

The left sum uses the velocity at the start of each two-second block (the first ten readings, $v_0$ through $v_9$): $$L_{10} = 2(0 + 8 + 15 + 20 + 23 + 24 + 22 + 18 + 12 + 5) = 2(147) = 294.$$ The right sum uses the velocity at the end of each block ($v_1$ through $v_{10}$): $$R_{10} = 2(8 + 15 + 20 + 23 + 24 + 22 + 18 + 12 + 5 + 0) = 2(147) = 294.$$ Here $L_{10}$, $R_{10}$, and $T_{10}$ all land on $294$, because the first and last readings happen to be equal ($v_0 = v_{10} = 0$), so the only difference between $L$ and $R$ — the endpoint terms — washes out. That coincidence will not survive a finer sample, but it tells us the estimate is stable: the choice of sample point barely moved the answer, which is the signature of a well-resolved integral (§13.2). To tighten it further we would record velocity more often — every half-second instead of every two seconds — and watch the trapezoidal estimate settle, just as the rectangle sums settled in §13.5.

import numpy as np

t = np.array([0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20])
v = np.array([0, 8, 15, 20, 23, 24, 22, 18, 12, 5, 0])

# Trapezoidal rule on a data table (uniform spacing dt = 2):
dt = 2.0
trap = dt * (0.5 * v[0] + v[1:-1].sum() + 0.5 * v[-1])
print(round(trap, 1))   # 294.0 meters

When direction matters: signed area

The sprinter never turned around, so distance equaled displacement. But sensors routinely record motion that reverses, and then the two part ways — the central lesson of §13.10. Suppose a robotic shuttle on a track logs the following velocities, where negative means "moving backward":

The velocity is positive on roughly $[0, 2)$, negative on $(2, 5)$, and positive again afterward. The net displacement is the signed-area integral $\int_0^6 v\,dt$, in which the backward stretch (where $v < 0$) subtracts area, exactly as §13.6 demands. The trapezoidal sum, taken with signs intact: $$\int_0^6 v\,dt \approx 1\cdot\Big[\tfrac{3}{2} + 1 + (-1) + (-2) + (-1) + 1 + \tfrac{3}{2}\Big] = 1\cdot 0 = 0 \text{ meters net}.$$ The shuttle ends essentially where it started — net displacement near zero. But it certainly moved. The total distance integrates the speed $|v|$, splitting at every sign change (§13.10) and adding the unsigned pieces: $$\int_0^6 |v|\,dt \approx 1\cdot\Big[\tfrac{3}{2} + 1 + 1 + 2 + 1 + 1 + \tfrac{3}{2}\Big] = 9 \text{ meters of ground covered}.$$ Zero displacement, nine meters traveled. This is the canonical trap of §13.10: writing "distance $= \int v\,dt$" silently throws away every reversal. Distance is $\int |v|\,dt$; displacement is $\int v\,dt$; only when velocity keeps one sign — as with our sprinter — do they agree.

The bigger picture

What looks like a sports-science curiosity is the operating principle of inertial navigation. A submarine running silent, a spacecraft between planets, a phone in a tunnel with no GPS — each tracks position by integrating measured velocity (itself often the integral of measured acceleration). Every such system is running a Riemann sum on streaming sensor data, accumulating tiny $v\,\Delta t$ contributions into a position estimate, second by second. The same template — a rate times a small chunk of the variable, summed and refined — is what §13.9 promised would cover an astonishing range of applications. Here the rate is velocity and the accumulation is distance; in Case Study 1 the rate was a probability density and the accumulation was a probability. One idea, two fields.

Chapter 14 will let us recover exact distances whenever we do have a velocity formula, by finding an antiderivative and subtracting — the Fundamental Theorem turning these laborious sums into one-line evaluations. But when the velocity arrives as data, as it almost always does in the real world, there is no formula to antidifferentiate, and the numerical Riemann sum of this chapter is not a fallback — it is the only game in town.

Discussion Questions

1. The left, right, and trapezoidal sums all gave $294$ m for the sprinter because $v_0 = v_{10} = 0$. Invent a velocity table where $v_0 \ne v_n$ and show that $L_n$, $R_n$, and $T_n$ then differ. Which two does $T_n$ sit between, and why (§13.13)?

2. Explain in your own words why the sprinter's distance equals her displacement but the shuttle's does not. What feature of the velocity data is responsible (§13.10)?

3. The sensor sampled every 2 seconds. If the sprinter's true velocity curve is smooth, would halving the sampling interval to 1 second make the trapezoidal estimate noticeably better? Use the $O(h^2)$ error scaling of §13.13 to justify your answer.

4. A GPS unit reports only speed (always $\ge 0$), never signed velocity. For the reversing shuttle, what would integrating that speed signal give you — displacement or distance? What information has the unit already discarded (§13.6, §13.10)?

A Short Annotated Reading

• Stewart, Calculus: Early Transcendentals (9th ed.), §5.1 "Areas and Distances" — the textbook's own velocity-to-distance motivation for the integral; the direct parallel to this case study and to §13.9–13.10 of this chapter.
• Stewart, §7.7 "Approximate Integration" — the trapezoidal rule and its error bound, the engine behind the 294-meter estimate; matches §13.13.
• OpenStax, Calculus Volume 1, §5.1 "Approximating Areas" — a free, worked development of Riemann sums on data, including velocity tables, with abundant practice problems.