# Calculating Velocity from Acceleration (Accelerometer)

I am using the Accelerometer in an Android Device to track and detect certain motions, using only one axis as the motions are linear along that axis.

I am using a simple filter to remove the noise from the accelerometer data:

ouput = ouput + alpha * (input - output)


The result looks like I would expect and seems usable for my purposes:

I want to calculate velocity from the accelerometer data I'm getting, but this is where I run into problems, as can be seen here:

As with the acceleration, the velocity curve looks plausible, but it doesn't return to zero after each repetition and falls off into negative values.

For now, I'm just writing the raw accelerometer data to a file and later modify and analyze it using spreadsheets, so these calculations are all done by hand.

• It is raw data, and thus includes the effect of gravity, which I just subtract (I'm using the average of the values of the short period at the beginning in which there is no movement, in this case it was 9.55)
• I have the timestamp of each data point, so I know the interval between readings
• I'm using the simple formula V = V0 + A * dt to calculate velocity.
• V0 is initially zero, then it's set to the previous value
• A is the adjusted acceleration (i.e. accel - grav)
• dt is the interval, the difference between the current and previous timestamp

I thought that the issue maybe is that the acceleration does not return to zero either and instead stays slightly below zero (as can bee seen in the first image above), which adds too many negative values that propagate in the calculation. So I set grav to be a smaller number, and there seems to be a sweet spot. In this example, large values for grav lead to the velocity dropping into negative, small values reverse the effect, with the velocity curve rising toward higher positive values. Right around grav = 9.3 (9.32 in this image), the graph seems to be most plausible. This interval is very small, 9.28 and 9.35 already show significant tendency to go up or down, respectively.

What could be the reason for this? Where does the ~9.32 come from? Why is it not the ~9.55 that I observe during the initial motionless period? Is there some way I could modify the calculations to get more consistent values? For example between each repetition there should be a short period of V = 0.

• It's pretty tricky to debug stuff like this... you should just try to play around by testing your accelerometer in some simple conditions where you'd expect a very simple waveform. Off the top of my head, there are several things which are possibly sources of the error: maybe your sample rate ($dt$) is too big and the errors perpetuate and magnify. Maybe you're forgetting to reset some variables in your code before calculating future values. Maybe there're some forces which your neglecting. It may not be physics: it could just be the code or a faulty accelerometer. – user191954 Jul 2 '18 at 10:06
• I'm pretty sure it's not an issue with my code, I'm really just taking the value that the Android API gives me and write them into a file. It's probably just the sensor that is not very accurate. That's actually the purpose of this, to find out, what usable data I can gather from a "cheap" smartwatch accelerometer. I'm not looking to get precise values, I'm more interested in relative change. I was unsure about whether this is the right SE, but as there is not really much in my code that could affect this, I didn't think it fit well on Stackoverflow. Thanks for the insight. – user199112 Jul 2 '18 at 16:51

Calibrate and validate. These are two words you need whenever you are doing calculations of physical parameters from measurement. You need to know how the device responds to known accelerations in order to determine whether the numbers you are getting are meaningful at the level you want to use them. The easiest would be if the manufacturer provided you with such details. Sadly, these days, devices of this type often come with no documentation whatever.

The fact you are getting 9.3 to 9.5 for gravity is suggestive. It suggests you have either an offset or a scale issue. One way to check this would be to read the values with the device sitting on a table, then turn it upside down and read again. An offset will show as a difference up-to-down. A scale issue will show low values both ways.

If you have a way to put the device in a situation with a known acceleration that would help also. Maybe a turn-table or some such? Though some such devices might be fooled by spinning in too tight a circle.

The steady drift suggests you could have a response issue. It may not be linear with acceleration. A narrow-but-high spike may be clipped, for example. Testing for such gets pretty complicated. You would need known acceleration profiles and then see how the device responds. Correcting for it adds more complication still.

• Thanks. I'll try your suggestions to see if I can determine whether it's a scale or offset issue. – user199112 Jul 2 '18 at 16:46
• I just did a quick test, and there seems to be an offset. In one direction it's 9.685, in the other 9.949. Put together, it's actually quite close to two times 9.81 (9.817). – user199112 Jul 3 '18 at 11:18

This should be a comment but I wanted to include a graph.

It would help to have details of the motion that you are observing.

Have you checked that the accelerations along the two other orthogonal axes are zero?

The area under an acceleration against time graph gives you the change in velocity.

So the blue area represents the positive change in velocity and, just by inspection, it looks smaller than the red area which is the negative change in velocity.
So the overall change in velocity is negative.

If you suspect the overall change in velocity is zero then is the zero of acceleration in the wrong place ie the acceleration axis is offset?

• I guess I'm trying to simplify too much. The motion is a simple up-down movement, in line with the axis, but not under ideal conditions, i.e. it's not perfectly straight, and there can be some left-right and front-back movement. So the other two axes are not zero, but I've been ignoring them as they would be zero under ideal conditions. I don't need precise measurements, I'm more interested in relative change, that's why I'm trying to simplify. – user199112 Jul 2 '18 at 16:41