Using antiderivative to find velocity from acceleration

I have a quick question.

Last week my calculus class started teaching antiderivatives. If there is a function A(t) which gives acceleration as a function of time, then it’s antiderivative is a function V(t) which gives velocity as a function of time (the antiderivative of that would be position), plus a constant C of course.

Now suppose we have an accelerometer sensor on a robot. If I can take the numerical antiderivative (if I can even do that), would that give me the velocity of the robot at that time (assuming the robot started off not moving)?

Yes, you can easily calculate the velocity from the acceleration. You do the exact same thing when you use a “gyro” on the robot to calculate your heading (the “gyro” actually is an angular velocity sensor, and you calculate the angle via the antiderivative (more accurately called an “integral”).

To calculate an integral (i.e. anti-derivative) in software you do the following:

velocity = velocity + acceleration*sample_time;

You perform the above calculation over and over at a fast rate. “sample_time” is the time since the last time you took an acceleration reading.

Great question… here’s the 1 minute answer, but note that this is meant to get you started - there is MUCH MUCH more detail regarding these (numerical) methods that I won’t get to touch on.

If you are given an accelerometer, and let’s say it gives you values in m/s^2, you certainly can easily calculate the definite anti-derivative (integral) of acceleration to give you velocity.


Read the accelerometer periodically, and keep adding your readings to a “counter.” For example, start your counter at 0 (this is actually your C value), and start reading your accelerometer every 1s.

Let’s say the first reading you get is 10m/s^2. Add the value 10 to your counter, and it turns out this counter will represent your velocity.

1 second later, let’s say your next reading is again 10m/s^2. Add the value 10 to your counter which should now be 20. That makes sense, because if you’ve been accelerating at 10m/s^2 for 2 seconds, you’ll be moving at 20m/s.

1 second later, let’s say your next reading is -5m/s^2. Add the value to your counter, which should now be 15. You’re moving at about 15m/s.

It turns out, velocity is simply the sum of all your acceleration readings. You also have to adjust the values a bit depending on how often you are reading your accelerometer, but I’ll leave that for you to figure out - it’s not too difficult. This method is adding up values into a counter is called “accumulation” and it shows up all over the place, and is one of the most basic forms of numerical integration.

Now if you were wondering, if you created ANOTHER counter, and used that counter to add up the values from you first counter described above, you would be performing a DOUBLE integral, and would actually get your robot’s POSITION.

Before other posters jump on me, it turns out the method I mentioned above is very inaccurate. You will get a lot of “drift” and over time your velocity will no longer match up. There are a number of ways to improve on it, but chances are another poster will jump in and expand on that.

(waiting for someone to deliver an amazing 3rd year numerical methods lecture below) :smiley:

Thanks for the answers. I figured it was a little more involved in practice. I was just excited that something I was learning in calculus could be applied to something I’ve been meaning to try in robotics!

Thanks again, I’ll have to look into some of the methods you guys described, looking forward to it!

See an old 2005 white paper titled:
An Introduction to C Programming for FIRST Robotics Applications

An Introduction to C Programming for FIRST Robotics Applicatyions [SP]

It describes a second on integration of a gyro, using second order
accuracy and careful subtraction of the average at rest in order to
obtain a low drift angular position. You could go further by adding
temperature compensation. The code is for the old control system.
You could do the same with an accelerometer to get velocity, but
the pulse rate of wheel counters would provide much better results.
Integrating a second time, using the relatively poor acceleration
measurements, would not produce very useful results, but I’ll
resist going into that.

An issue with doing this on the cRIO is getting an accurate time
interval between measurements. There may be a suitable system
call to provide the time to sufficient accuracy.


For me, not being shown practical applications for all that math was the most frustrating part of learning it.

Distance is measured in meters
Speed is measured in meters per second
Acceleration is measure din meters per second, per second (m/s2)

The relationship between these three physical values can be found through calculus. A derivative is dX/dt, right? what do you think that “t” is for? Yes, it is TIME.

The slope of the ‘distance versus time’ curve is speed.
The slope of the ‘speed versus time’ curve is acceleration.

>>The derivative of the curve gives us the slope.

The area under the ‘acceleration versus time’ curve gives us the speed
The area under the ‘speed versus time’ curve gives us the distance

>>The integral of the curve gives us the area under the curve.

Ain’t calculus fun?
Now think of how darned smart the guys who figured all this out must have been…

Practical applications note:

Your standard 3-axis accelerometer is going to be reading something like 9.8 m/s^2 in some direction while apparently at rest. This is usually a good thing. A reading of less than this generally means your robot is rapidly approaching the ground, or we’re all in a heap of trouble, as gravity has taken a holiday.

Nevertheless, your robot isn’t actually accelerating at this speed towards the ground, so you need to subtract the acceleration of gravity from the reading of your accelerometer. Which is all fine and easy, until your robot starts pointing in a different direction and gravity is suddenly -9.8 m/s^2 in the x direction.

This means you need to keep track of your robot’s orientation in space, just so you can accurately account for the effect of gravity. Which means you slap a 3 axis gyro on your robot and start integrating rates of rotation to determine your orientation, to determine where gravity is, to subtract gravity from your overall acceleration, which you finally integrate to determine your velocity.

And then you wrap it in shiny white plastic, call it a Wii MotionPlus, and make millions of dollars.

Heaven help you if the accelerometer is off-center of the axis of rotation, though. Then you get all sorts of fun extra motion.

Some useful vocabulary and definitions:

  • an antiderivative of a function f(x) is any function whose derivative equals f(x)

  • “indefinite integral” and “antiderivative” are, in most contexts, synonyms

  • the definite integral of f(x) evaluated over the range x=a to x=b can be calculated analytically if an antiderivative for f(x) can be found. If F(x) is an antiderivative of f(x), then the afore-mentioned definite integral is equal to F(b)-F(a). Loosely speaking, this amazing fact is known as the Fundamental Theorem of Calculus.

  • not all functions f(x) have an antiderivative expressable with elementary functions

  • definite integrals can be approximated using numerical methods. A very simple method, often called Euler’s method, is to simply sum up the values of f(x) at equal intervals in the range and multiply the sum by the interval. Other more accurate methods are available, such as Runge-Kutta. These methods are often available in numerical computation libraries.

  • in the real world, integrating a sensor signal to obtain a new signal is fraught with difficulties. jitter and rounding errors can create signals which are not accurate. proceed with caution.