Estimating Position with Noisy Acceleration Sensor

[mx tommy]

Ok, First of all I admit to being a complete and utter noob at Math... That said, I need some serious help :P

I'm working on a project that will need to estimate a position along a single axis based solely on the fact of 0 inital velocity, and a noisy acceleration value. As far as I can tell, I need a Kalman filter. However, I've only taken pre-calculus, and have no idea how to even READ those formulas... (I've spent the last 2 days trying, using generous amounts of google, and while I've made "some" progress, I'm still a LONG way from understanding it. I was hopping someone here could help me implement it, keeping in mind I only know basic algebra and functions.

Here's the info about the system I need to esimate...

At start time, velocity is 0.
I have a accelerometer sensor that reads acceleration along the axis of relevence.
I sample the accelerometer every X ms (prolly around 1, will need to see how many times I can in a second, depends on how long it takes the code to execute)
Acceleration will be rather high, and of short durration. (no longer then 10 seconds, I'm guessing this will help reduce the error over longer times)

unfortunately, I can't realistically use any other sensors for increased precision, for price reasons and practical reasons, and am prepared to accept a reasonably large error.

Ideally, I need a function (I'm programming in C. I don't need the C code, just something I could translate into C code) that I input the acceleration, and it returns an estimate of distance traveled, and estimated speed.

That would be ideal, though I'll take anything I can get, including just a simplified algerbraic version of the filter

Thanks, Thomas :)

 

[CRGreathouse]

If you're sampling every millisecond, I'd just assume that the acceleration varies linearly between samplings.

void updatePosition (double oldAcceleration, double newAcceleration) {
velocity += (oldAcceleration + newAcceleration) / 2;
position += velocity;
}

with suitable changes so the units are natural.

 

[mx tommy]

yes, but would that take into account the sensor noise?

 

[CRGreathouse]

yes, but would that take into account the sensor noise?

No, but I'm not sure much could be done without more information on what form the noise took.

This should be quite accurate, at least at the beginning. If it runs for a long time (where the definition of "long" depends on how much noise the sensor throws out) the position will become increasingly inaccurate (superlinear error).

 

[mx tommy]

ok, I'll give that a shot then, though in the case it proves to be too inaccurate, what information about noise is needed? and how would one obtain such information?

Also, since you'd have more of an idea on how such things work, would this be feasible for measuring 50 feet +-1.5 feet? (acceleration would probably average around 0.5g's, and I'm using a 1.5G sensor, so there should be plenty of sensitivity...)

thanks, Thomas :)

 

[CRGreathouse]

ok, I'll give that a shot then, though in the case it proves to be too inaccurate, what information about noise is needed? and how would one obtain such information?

Also, since you'd have more of an idea on how such things work, would this be feasible for measuring 50 feet +-1.5 feet? (acceleration would probably average around 0.5g's, and I'm using a 1.5G sensor, so there should be plenty of sensitivity...)

How fast is it moving? The real problem is that for each measurement, the speed stored internally gets further and further off. With uniformly distributed error a constant off the true acceleration, the position's error is almost quadratic in the time operated. Essentially, the longer it runs the worse the estimate becomes because it thinks it's still moving when it stops, or that it's stopped when it's still going. If there was some way to re-synch the speed every so often the system would be much more robust. Maybe there's a max speed it can get to, so under some assumptions you can have it reset itself to that speed when it runs "flat out" for some time without turning or hitting something, I don't know.

 

[mx tommy]

Well, it starts off at 0kph, and accelerates until 50 feet have been passed... At this point I'm done collecting data. I would assume that speed would be no more then 40-50kph, over maybe 5 seconds...

 

[CRGreathouse]

Well, it starts off at 0kph, and accelerates until 50 feet have been passed... At this point I'm done collecting data. I would assume that speed would be no more then 40-50kph, over maybe 5 seconds...

I imagine it will be fine. Post here when you have results (or problems, I suppose).

 

[SGT]

You would need a Kalman Filter if you were measuring position and wanted to estimate velocity and acceleration.
Since you are measuring acceleration, a simpler filter can do.
First, try a limited memory filter. If it suits your needs, fine! If it doesn´t, you can try an alpha-beta filter.
For the limited memory filter, let´s call a[k] the estimated acceleration at instant k and m[k] the measurement at the same instant. You have:
a[k] = \alpha \cdot a[k-1] + (1 - \alpha) \cdot m[k]
where 0 < \alpha < 1 and a[1] = m[1]
Explaining:
The estimated acceleration at any instant depends on every previous values of the acceleration and on the actual measurement.
Of course, the value at n time units in the past will contribute ,ultiplied by \alpha^n and since \alpha < 1 it will become small very fast. This is the reason we call it a limited memory filter.
If your acceleration is fairly constant, this will do well. If the acceleration is variable you will probably need an alpha-beta filter, that is a little more complicated. Let me know your results.