Distance from accelerometer

Question

is it possible to calculate distance data based on the accelerometer readings? Let's say I hit the button and move the phone, is it possible to calculate how far the phone have been moved? My idea was to use the timer and the accelerometer and then somehow calculate the distance. Any hints?

Answer 1

In following response, reference is made to units of time (seconds) 's', and of distance (meters) 'm'.

Embedded device accelerometer data (acceleration - 'a' [units ms^-2]) are 2nd order time difference (differentials) of position.

Say if you have N position data points 'x' [zero order, unit m], displacement is difference x(i) minus x(j) [unit m] over time (t) period (t=j) minus (t=i); dividing that displacement by its time period gives velocity 'v' [1st order, units ms^-1]; the 'v' velocity data points derived in this manner will only be [N-1] in number by loss of one degree of freedom through the subtraction relation among the original N number of 'x' data points.

Now if you repeat what was done with 'x' but replacing it with derived 'v', then you get [2nd order] 'a' acceleration. By same reason you end with [N-2] number of 'a' data points by loss of another degree of freedom through the subtraction relation among the original N-1 number of 'v' data points.

Now yours is the converse problem: of beginning with 'a' acceleration data to derive 'x' by sequentially integrating 'a' to recover 'v' and repeat what was done with 'a' using the 'v' instead to recover an integrated 'x'. How do you do this?

By definite integration. When you push the 'start' button initially to begin (b) you have to establish initial condition for time (t) and velocity (v) for that initial acceleration reading (a) of the accelerometer, and you end the integration on another event (perhaps another button press) to indicate the end (e) of accumulation of changing velocities over their respective time periods. The integration (summation) tells you how velocity has evolved between (b) and (e). Of course you do this in finite (small) steps provided by the sensor events between your initial Begin button press and your final End button press.

Again in the same converse order you repeat the preceding but replace acceleration 'a' with integration result velocity 'v' to finish with dual integration result 'x'.

To get there you would have added initial (b) and end (e) seed data to your integration stream for velocity, and then for position.

So, the short answer is: for the derivation of position from acceleration you need to build configuration beginning and end-point data that your application shall adhere to. Often one uses 0=x=v=t assuming that corresponds to your initial button press. Thereafter, you're integrating "acceleration is proportional to force", and "velocity is proportional to momentum", and "momentum is proportional to displacement", with all three sharing coefficient of proportion mass (m) which in your kinematic exercise can be dropped out without further reference to 'm' and assumed to be unity (1).

Now for the practical part: I recently experimented with converting from Distance measurement -> Acceleration into the converse Acceleration -> Distance, using a smart phone platform accelerometer 3D array.

Prognosis thus far is not good: Using a Quad-core 1.2GHz CPU on a smartphone unit (mfg spec): OS Android OS, v4.4.4 (KitKat); Chipset Qualcomm MSM8916 Snapdragon 410; CPU Quad-core 1.2 GHz Cortex-A53; GPU Adreno 306,

I only obtained a 13.97 3D accelerometer reading cycles per second, including the minimal processor duty of shoving time and sensor data from Sensor event to UI resource .R display as text.

You shall need to discover (in a case such as this) how to perhaps dedicate one core to just the real-time processing. In contrast, I did much better with a humble dedicate 8-bit Motorlola 68HC11 a decade ago with 100x the number of duty program instructions.

Perhaps someone else knows how to dedicate one of android 1.2Ghz multi-cores for (near-) real-time duty cycle. The default of 14Hz event cycle cannot serve much use, and the clock timer has a scary standard deviation between sensor events, rendering the critical integration(s) questionable ...

MKhomo