Can an accelerometer measure position accurately?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a linear analog accelerometer that gives me a voltage up to 2g. Is there any hope at all in double integrating the sensor output in order to obtain a good position number (knowing exactly where your hand is in space if you were to wave the sensor around, to the nearest inch or half inch)?

Sorry about vague words like accurately and good... I just want to know if it is even possible at all to achieve a position reliable from an accelerometer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

in my experience (on android) errors accumulate very fast when integrating acceleration to speed and then to position.

start here perhaps : http://en.wikipedia.org/wiki/Dea...

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What you are describing is very similar to an inertial navigation system. They work "well enough" -- though thygate is correct in saying that errors accumulate quickly. Deficiencies in INS systems was one of the main motivational factors for a small U.S. military program that launched some satellites for navigational aids... more commonly known as the Global Positioning System.

I wish I was in A2. Hope they pound on NW this weekend.

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

=) You know they're gonna! Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there is a tut thread that might be of interest

https://www.avrfreaks.net/index.p...

cheers,

JoeSoap

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:
Sorry about vague words like accurately and good... I just want to know if it is even possible at all to achieve a position reliable from an accelerometer.

This was discussed recently. It's impossible to get metre-level let alone inch-level accuracy out of these accelerometers.

For justification of that statement, check out this thread where I show some numbers about how bias errors compound with time.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I've read everything you all have suggested I read. Since I'm only concerned with tracking motions of a few inches at a time, I'll simply tune the system as best I can and then re-zero every second or two. I wish I could make my boss read these threads =( he seems to think that position should be dead nuts accurate since it works in a high school physics book. So frustrating, but thanks for the links and writeups, I'll implement a double integral and just go with it I guess =( =( ow my head hurts

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:
So I've read everything you all have suggested I read. Since I'm only concerned with tracking motions of a few inches at a time, I'll simply tune the system as best I can and then re-zero every second or two. I wish I could make my boss read these threads =( he seems to think that position should be dead nuts accurate since it works in a high school physics book. So frustrating, but thanks for the links and writeups, I'll implement a double integral and just go with it I guess =( =( ow my head hurts

If you're serious, get your boss to buy this book. You can implement a complete system from the equations in that book, but don't expect any sort of performance out of these sensors (and you'll need a triad of gyros too!)

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dont you also need gyros for that, and perhaps even a compass to tell you what heading you are pointing at.
that would give you 9DOF and should make you able to position very accurately without resetting every second ( and thus also introducing errors)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:
dont you also need gyros for that, and perhaps even a compass to tell you what heading you are pointing at.
that would give you 9DOF and should make you able to position very accurately without resetting every second ( and thus also introducing errors)

With gyros and magnetometer, you can get a reasonable pitch, roll and yaw solution up to the accuracy of the sensors (generally about 1deg for a compass in yaw, about 1milliradian per mili-g of bias in the accelerometers).

Without an external reference (e.g. GPS), the position solution will still drift forever.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Everyone seems to use regular old Forward Euler integrators to 'add up' the little delta Vs. Wouldnt a trapezoidal or simpsons rule integrator have less error?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Everyone seems to use regular old Forward Euler integrators to 'add up' the little delta Vs. Wouldnt a trapezoidal or simpsons rule integrator have less error?

Actually, Runge-Kutta is reasonably popular :)

When designing an INS, part of the "error budget" will be for "algorithm error" as a result of integration approximation and other approximations that are made when the navigation computer has only limited capability (not as much of a problem as in the past). Generally, it will set about 5% of the total error budget (less, if you have a modern embedded processor available).

For MEMS devices, the double integration of white noise and bias (and lots of it!) makes the choice of integration method the least of its problems.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I came across this forum post on Arduino and thought it to be relevant. Should offer some more insight into what you're attempting. Alan

http://arduino.cc/forum/index.php/topic,58048.0.html

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the help so far, rather than making new posts, I got another question...

Any quick and dirty methods to get RMS from an 8 bit A2D sensor? I'm thinking sqare up all the numbers and root em....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I keep an array with the samples-squared values, and the running total, so each pass of the program: get new sample, square it, subtract off oldest sample-squared from the total. add new sample squared into total, advance array index, save new samplesquared in array, calc the mean, which is a shift if array size is a power of 2, do the sqrt, save it somewhere. So if you are getting 100 samples per sec, and want a 1 sec avg, just need a 100 sample array, but you dont re-add em all up every time. Clever huh?

Imagecraft compiler user