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.

  • $\begingroup$ This is almost, but not quite (in my opinion) a duplicate of this question, which asks more about rotations (quaternions). $\endgroup$
    – Chuck
    Jun 2 '16 at 15:12
  • $\begingroup$ What is your platform? $\endgroup$
    – JSycamore
    Jun 5 '16 at 21:57
  • $\begingroup$ Its SensorTag board from TI(CC2650 sensortag). $\endgroup$
    – Vinay
    Jun 7 '16 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 \\ $$


$$ 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.

  • $\begingroup$ Thanks Chuck for your detailed analysis. This is useful. Can you also please let me know where these accelerometer alone can be used? $\endgroup$
    – Vinay
    Jun 7 '16 at 4:53
  • $\begingroup$ 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. $\endgroup$
    – Chuck
    Jun 7 '16 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.