19

I'm working on an android application which can calculate device's movement in 6 direction. I think I can use acceleration as;

"x=a.t^2" but a is not a constant. And this is the problem. How can I calculate the total movement??

kubudi
  • 658
  • 1
  • 9
  • 20
  • You will need to poll the value of `a` and work out the average acceleration, and apply that average over the time period between the polls. –  Nov 25 '11 at 03:49
  • Very curious how you managed to resolve this, and if you got it so that it's precise to allow for precision navigation. – ina Feb 14 '12 at 21:36

2 Answers2

22

The accelerometer gives you three directions (x, y, z). They are acceleration measurements which is harder to know what the position of the device is. But, remember acceleration is related to position through integration:

a(t) = a[x]
v(t) = a[x]t + c
x(t) = a[x]t ^ 2 + ct + d

Problem is you can't know c or d because as you take the derivative the constants drop out. So there is some amount you can't get right with c and d missing. You can attempt to compensate by remembering the values you used last for those. So after grabbing 3 samples you can start to calculate position from that.

There is a significant amount of information about how to interpret the data from the sensors. Like figuring out where gravity is for orientation, and subtracting out gravity to get linear acceleration.

http://developer.android.com/reference/android/hardware/SensorEvent.html

Here is a way to come up with position using an accelerometer along with an algorithm for finding position in detail:

https://www.nxp.com/docs/en/application-note/AN3397.pdf

chubbsondubs
  • 37,646
  • 24
  • 106
  • 138
  • 3
    Especially second link is a golden mine for me. Thanks a lot. – kubudi Nov 27 '11 at 23:17
  • I used acceleration for calculate pixel count which I'll move. its queite simple and working properly. If u want I can send u my app but it have some dependencies. – kubudi Feb 17 '12 at 09:57
  • @chubbsoundubs, Could you please take a look [at this topic](http://stackoverflow.com/questions/42176603/getting-a-trajectory-from-accelerometer-and-gyroscope-imu) please . Thank you. – Veliko Feb 12 '17 at 10:32
7

It is true, you get position by integrating the linear acceleration twice. But the error is horrible. It is useless in practice.

Here is an explanation why (Google Tech Talk) at 23:20. I highly recommend this video.

It is not the accelerometer noise that causes the problem but the gyro white noise, see subsection 6.2.3 Propagation of Errors. (By the way, you will need the gyroscopes too.)

A similar question is Distance moved by Accelerometer.

Community
  • 1
  • 1
Ali
  • 56,466
  • 29
  • 168
  • 265
  • thanks but I think i don't need gyro. Can you explain why do you think it's neccesary to find distance moved? – kubudi Nov 27 '11 at 23:20
  • The SensorManager needs the gyros if you are using linear acceleration. As for the accepted answer, I hope you know the result you get will be very poor. Far worse than you expect. – Ali Nov 28 '11 at 07:20
  • Why? Gyro is returning you angular velocity. Wht do you need that for acceleration. I really don't get it. – kubudi Dec 09 '11 at 10:30
  • Please watch the video from the beginning to the end. It gives you a clear explanation. – Ali Dec 09 '11 at 14:18
  • 1
    Already watched. But I'm not trying to do with same way. There's not only one way to do this. In fact you can even use the camera. – kubudi Dec 10 '11 at 09:44
  • 1
    Ali, you have been posting the integrated results will be horrible, but I'm not sure if that's the case. In the google video, the rule of thumb was "integration of noise becomes drift". When you integrate something, you get area under the curve, which always grows the longer your line is above the positive y axis. It's not drift exactly, but just showing that the area is slowly increasing. – ina Feb 14 '12 at 21:35
  • @ina The gyro white noise quickly results in small orientation error. It is equivalent to having bias in the linear acceleration. **You are integrating this bias, not the noise**, and this is the source of the disaster. Read subsection 6.2.3 in the linked technical report, it gives you a numerical example. – Ali Feb 14 '12 at 22:02