# Instantaneous velocity calculation from accelerometer?

I am trying derive velocity from accelerometer (MPU9250 in sensor-tag board). I saw lot of blogs which talk about noise and exact estimation problems. I started seeing velocity derivation (integration of accelerometer data over time) yielding me towards ramp because of noise presence in MPU9250.

Is the velocity can be estimated only by accelerometer or we need assistance of another sensor such as GPS or gyroscope, etc..

Please let me know as I see my velocity calculations never converge at all. Also I have limitation in compute power, so Kalman filter kind of estimation techniques is difficult to implement. Can you please suggest whether I am in right direction or not.

• This is almost, but not quite (in my opinion) a duplicate of this question, which asks more about rotations (quaternions).
– Chuck
Jun 2, 2016 at 15:12
• What is your platform? Jun 5, 2016 at 21:57
• Its SensorTag board from TI(CC2650 sensortag). Jun 7, 2016 at 4:52

The only way to get a velocity from an accelerometer is to numerically integrate the output of the accelerometer. That is,

$$v = v_0 + a*dT \\$$

where $dT$ is the elapsed time between accelerometer readings. This means that you need to find the initial velocity $v_0$, and that an accelerometer cannot give an absolute velocity reading, only relative.

Further, all accelerometers have some sensor bias. If we call this term $a_{\mbox{bias}}$, then the accelerometer-based velocity "measurement" is actually:

$$v = v_0 + (a + a_{\mbox{bias}})dT \\$$

or

$$v = v_0 + (a_{\mbox{bias}}*dT) + a*dT \\$$

The bias term becomes a false speed reading. Further, the bias is prone to change over time, both with sensor age, orientation, temperature, etc. This means that it's not generally possible to (permanently) cancel that bias by simply measuring the accelerometer while it's known to be stationary, though this can be a technique you use to minimize the effect of the bias.

So, when you say the sensor is "noisy", that is technically true - there will always be some noise, but it is the fact that the noise is not zero-mean that introduces the trouble you're having. If the only issue were noise, then you could use filtering to remove it, but the fact that the bias exists means that no amount of filtering or averaging will ever give you the correct velocity.

The only way to get an absolute velocity is to incorporate an absolute velocity sensor. This could be done with GPS, a wheel speed sensor (assuming no tire slip), radar, etc. Generally you can combine (fuse) a sensor that is noisy in the short-term and accurate in the long-term (like GPS) with a sensor that is accurate short-term but drifts in the long-term, like an accelerometer, and get quality readings in both the short- and long-term.

• Thanks Chuck for your detailed analysis. This is useful. Can you also please let me know where these accelerometer alone can be used? Jun 7, 2016 at 4:53
• The accelerometer alone would generally be used when you only cared about short-term performance. The bias error (in velocity) is $v_{\mbox{err}} =\int a_{\mbox{bias}}dT$, which means, assuming a stable bias (it's not), the total drift is $v_{\mbox{err}} = a_{\mbox{bias}}(t_f - t_0)$. In the short term, the drift could be manageable, but the more time that elapses the less useful your measurements become.
– Chuck
Jun 7, 2016 at 12:53