How To Get Velocity From Acceleration

Integration Basics

Velocity comes from acceleration by integrating over time. That's the theory, at least. In practice it means you take the acceleration value at any given instant, multiply it by how long that value held, and add it to whatever velocity you started with. Simple on paper. Messy in real sensors.

The discrete formula looks like this: v(t) = v + a(t) × t You start with an initial velocity, then for each sample you multiply acceleration by the time step and accumulate. You do this repeatedly across your entire dataset. After a thousand samples you have one velocity curve.

How To Get Velocity From Acceleration in Practice

I spent three weeks last year trying to reconstruct velocity from a cheap MPU-6050 mounted on a camera gimbal. The spec sheet says it outputs acceleration in mg per LSB. You read the raw value, convert to SI units, and integrate. That's what everyone tells you to do. Here's what nobody tells you: even a perfect sensor will give you garbage after about eight seconds. The problem is zero-point offset. The MPU-6050 I was using had an axis bias of roughly 0.02 m/s². Multiply that by gravity and the math breaks down fast. After sixty seconds of stationary integration my calculated velocity had drifted to nearly four meters per second. The gimbal hadn't moved. The sensor thought it was flying through low orbit. The workaround is calibration. Before you integrate anything, record the sensor output while the device is completely still for about thirty seconds. Average those readings. That average is your zero-offset. Subtract it from every subsequent sample. With that done, the same MPU-6050 stayed within ±0.15 m/s of true velocity over a ten-second static test. Ten seconds. Not a drill.

There are a few more things you need to get right or the whole thing falls apart. Sampling rate consistency matters more than people admit. If your integration step is jittering — say sometimes 0.01 seconds, sometimes 0.013 — your velocity calculation absorbs that variation as real acceleration. Use a hardware timer or a fixed interrupt rather than relying on software delays. On an Arduino, micros() gives you enough precision that you can compute actual elapsed time between samples instead of assuming a constant interval. It took me a while to realize my variable-timestep code was the primary source of drift, not the sensor itself. Gravity is always there. An accelerometer doesn't measure acceleration in the physics sense. It measures proper acceleration — the force pushing against the sensor. That means when the device sits still on a table, it reads 1g pointing upward. If you want kinematic acceleration for velocity integration, you need to subtract the gravity vector. This requires knowing your sensor's orientation relative to the Earth at all times, which usually means fusing with a gyroscope and doing something like a complementary filter or a Kalman filter. Without orientation data you can't separate gravity from actual motion, and your velocity will be wrong in any direction that isn't perfectly horizontal.

Initial velocity is not optional. You can't start from zero and expect correct results unless you actually know the object is stationary at t=0. I once integrated from a resting start position and got a velocity curve that looked plausible for the first five seconds, then diverged completely. The starting position felt still, but the sensor had a small bias that the brief calibration period didn't catch. A longer calibration window — two minutes instead of thirty — would have caught it.

When Integration Is the Wrong Tool

Double integration for position from acceleration is almost never reliable without external correction. Single integration for velocity is better but still limited. If you need velocity over extended periods, you should be fusing accelerometer data with something else — GPS for outdoor work, wheel encoders for vehicles, optical flow for drones. A standard Kalman filter running at the accelerometer sample rate with these external measurements as observations will give you velocity estimates that don't drift irrecoverably. The approach I settled on for the gimbal project used a complementary filter combining gyroscope-based angular velocity with accelerometer-derived linear velocity and a magnetometer for heading. It wasn't perfect. The velocity estimate still wandered about 0.5 m/s per minute of sustained motion, but that was good enough for gimbal stabilization where absolute velocity doesn't matter as much as relative change. If you're doing this for the first time, start with a known-movement test. Move the sensor a precisely measured distance at a roughly constant acceleration, record everything, then compare your integrated velocity against what you expect. You'll immediately see where your errors are coming from — offset, noise, timing, or gravity miscompensation. Then fix one thing at a time.