# Calculating Speed: The Good, the Bad, and the Technically Difficult Submitted by DaveBakker on Fri, 05/26/2017 - 18:32

Clifton, PocketLab's inventor and CEO, posted a helpful explanation on PocketLab's Projectile Speed graph in our previous forum. The original post is below:

Calculating Speed

We’ve had many questions about the speed graph on the PocketLab iOS app. I want to provide some technical background on how to calculate speed in general, how the PocketLab calculates speed, the best use cases, and the technology limitations.

We are working to improve the functionality of many features, and we have lots of ongoing development. We’ll keep you updated as we upgrade functionality and add capabilities.

Technical Background
Calculating speed or velocity is a difficult problem in general. Researchers in the field of internal localization and mapping are actively investigating this problem.

The issue comes from the fact that we can’t directly measure velocity or speed with commercially available electronic sensors. We can directly measure parameters such as pressure, light, or acceleration. But for speed, in most applications we have to measure another parameter and then calculate speed.

For instance the speedometer on your car directly measures the rate of tire rotation and then from the circumference of your tire can calculate speed. If you have ever spun your tires on an icy road, you can see the speedometer increase while your car isn’t actually moving. The speed sensor on an airplane is a pitot tube that measures stagnation pressure of the fluid flow and then calculates air speed. Before the use of GPS, airplanes could only measure their speed relative to the air speed. So if a plane was flying with a 100 mph tailwind, the measured speed and the actual ground speed were off by 100 mph.

With the small-scale sensors used in PocketLab and virtually all other gadgets and devices, we can only directly measure acceleration and then have to calculate velocity.

Velocity Calculations
If we can measure acceleration, shouldn’t it be straightforward to calculate velocity? Every high school physics student learns that acceleration is the derivative of velocity. Can’t we just integrate the acceleration measurement to calculate velocity?

Unfortunately, no.

The first issue is that gravity affects the output of the accelerometer. An accelerometer cannot tell the difference between the constant acceleration due to gravity of 9.81m/s2 (1 g) versus an applied acceleration.

The second issue is acceleration due to angular rotation. If you place an accelerometer at the center of a turntable and spin it very quickly, the acceleration measurement in the radial direction of the turntable will increase, but the sensor will not actually be traveling off the turntable.

Because of these two issues, an accelerometer alone is not adequate to calculate velocity. You need the linear acceleration measurements from the accelerometer plus angular rotation measurements from a gyroscope or magnetometer. Then you need to process both sets of data using motion-processing algorithms. Entire companies are built around developing just these motion-processing algorithms.

So is that it?

Unfortunately, still no.

Since to calculate velocity from acceleration measurements involves integration, small errors in the acceleration lead to a large build up of error in the velocity measurement. So even more research is focused on how to correct this error. For outdoor applications, you can combine accelerometer motion data with GPS data using what’s called a Kalman Filter to more accurately calculate velocity. For indoor applications, you can combine acceleration and camera video also using a Kalman Filter to improve accuracy.

What does the PocketLab calculate?
The PocketLab calculates speed using just the accelerometer and the application is meant for projectile motion experiments. If you place the PocketLab sensor inside a ball and throw it up in the air, you can approximately measure the projectile speed. You can combine the calculated speed graph with the altitude and accelerometer graphs to compare altitude vs. time, speed vs. time, and acceleration vs. time.

Many of our beta tester teachers really wanted a way to illustrate the connection between position, speed, and acceleration. So we implemented a simple way to calculate speed for the specific use case of projectile motion.

Future Improvements
We have noticed from your feedback, that some of the speed graphs drift a lot. That is due to error in the accelerometer measurements. The error varies with each particular sensor. In a future version of the app, we will implement a better method to calibrate for the drift that some users have seen. For now, there’s a “Zero” button on the lower right side of the screen to reset the offset of the graph.

As for more advanced motion processing, we are working on it! We have the development marked on our engineering timeline. We’ll let you know as we make progress.

For a good introductions to motion-processing algorithms check out these links:
http://www.chrobotics.com/library/ac...ition-velocity
http://cache.freescale.com/files/sen...ote/AN3397.pdf