# Detecting distance moved by accelerometer?

I have an accelerometer connected to an Arduino Uno board, is there a way I can detect the distance it this accelerometer moved on each of the 3 axis?

• No, not with any meaningful accuracy, as has been previously explained each of the many times this has been asked on the various stack exchange sites. – Chris Stratton Jun 21 '16 at 23:11
• Check out the way I calculated the distance traveled by an elevator using the ADXL345. It's not the most accurate or even easy, but I go through the whole process on my blog: engineersportal.com/blog/2017/9/25/accelerometer-on-an-elevator Let me know if you have any questions! – Joshua Hrisko Oct 19 '17 at 22:42

## 2 Answers

This is normally referred to as Dead Reckoning. The processes of determining position using known values, such as acceleration.

First we have to relate acceleration, velocity and position mathematically. Velocity is the integral of acceleration with respect to time: Similarly, position is the integral of velocity with respect to time: Here is an explanation that should tie this all together. However, it appears this explanation goes in the reverse order. That is using derivatives of position to find velocity. And derivatives of velocity to find acceleration. Simply put, finding a derivative is the opposite process of finding an integral.

A final note, this all works well on paper. In reality Dead Reckoning based only on acceleration does not work very well. For instance, I believe most vehicle GPS systems tend to use steering and speed if Dead Reckoning is to be used for guidance.

Added later...

Found this web site where someone talks specifically about Dead Reckoning using an Arduino. He is simply using the deltas of filtered acceleration readings:

``````velocity(i) = velocity(i-1) + acceleration (i)
position(i) = position (i-1) + velocity (i)
``````

But goes on to say accumulated errors causes drift and positioning errors.

• Comments are not for extended discussion; this conversation has been moved to chat. – Majenko Oct 20 '17 at 9:34

Think about it:

• Accelerometers measure acceleration.
• Acceleration is a change in speed.
• Distance travelled is speed multiplied by time.

If you know the starting speed (e.g., stationary) and you know how much you have accelerated between two points in time you can calculate the average speed for that time period - and since you know the time of that time period (one would hope) then you can get an approximation of the distance travelled in that axis.

I say approximation, because you are working with finite time points (quanta) and only looking at the acceleration at those points in time. It's far from perfect, but it can give you a rough ballpark figure. The smaller your quanta the better your accuracy - but it will never be anything more than a guestimation at best.

Now it's just, as they say, a SMOP.

• Distance is the double integration of acceleration. – perigalacticon Jun 22 '16 at 2:25
• I downvoted this because it suggests you can get "an approximation" or "rough ballpark figure" when in reality you're not going to get anything useful out of this approach. The most important issue is that any inaccuracy in your acceleration measurement is going to blow up massively when you integrate to get position. – Tom van der Zanden Jun 22 '16 at 6:31
• @TomvanderZanden I mentioned that it was a guestimation at best... A guestimation, by the way, is worse than an estimation. An estimation is based on good data - a guestimation is based on guesswork, so is quadruply inaccurate. The link to SMOP is of course supposed to discourage the OP from taking this route since the programming would be outside his ability sphere. – Majenko Jun 22 '16 at 9:36
• @TomvanderZanden you still get usable figures depending on what precision you expect. And you can increase the quality using other sensors and filtering data. The dead reckoning technique can get extremely complicated, but the accelometric input is the base of most – Lesto Jun 23 '16 at 21:49