Accelerometer Filtering

[kearnel]

I recently wired up an accelerometer/gyro board to our robot in hopes of using it to track the bot's position. The problem is that the accelerometer is giving me very noisy data and I don't know how to filter it. I've looked online and I can't find anything I can understand or use. If someone could explain a good filtering algorithm to me I'd appreciate it.

Please don't tell me it's impossible to track the bot's position using only an accelerometer and gyro because I don't plan on doing that.

Thanks

[plnyyanks]

It depends what language you're writing your code in.

I know that in LabVIEW (my forte), there are some functions in the signal processing palate that you should look at. There's a subpalate for filtering (Signal Processing->Filters) and it has a bunch of filtering VIs you could use. I haven't personally used them, but they're there. Note that these VIs will require the entire data set as an 1D array to filter them. Since this isn't too practical for real-time filters, look at Signal Processing->Point By Point->Filters for VIs that can filter one data point at a time.

[kearnel]

I'm using Java but I wouldn't mind porting code if you found some. I also wouldn't mind writing code but I don't understand how the algorithms work.

I suppose these VIs are black boxes with no viewable source code?

I don't mind a small delay either.

[plnyyanks]

I don't think porting LV code to Java is the best approach. Instead, I'd recommend reading up on some filtering algorithms and trying to find some appropriate Java libraries.

Start by reading some wikipedia articles about different types of filters and decide how you want to approach your filtering. Then, search for some packages that you might be able to use.

Maybe someone with some experience with Java programming might be able to help you out a little better

[kearnel]

I've been reading and trying to understand these algorithms but it appears that I need to understand calculus. I can't find anything that I can understand.

Edit: I'm wondering If there are any websites that explain filtering without using crazy-looking math to do it.

[Ether]

Originally Posted by kearnel

I've been reading and trying to understand these algorithms but it appears that I need to understand calculus. I can't find anything that I can understand.

Edit: I'm wondering If there are any websites that explain filtering without using crazy-looking math to do it.

Here's a very very simple "hello world" low-pass filter that will reduce noise (but also introduce delay):

new_filtered_value = f*previous_filtered_value + (1-f)*newly_read_value;

f is a tuning parameter between 0 and 1.

when f is zero, you get no filtering:

new_filtered_value = newly_read_value;

as you increase f from 0 towards 1, the filtering gets more aggressive.

[Joe Ross]

Originally Posted by kearnel

I've been reading and trying to understand these algorithms but it appears that I need to understand calculus. I can't find anything that I can understand.

Edit: I'm wondering If there are any websites that explain filtering without using crazy-looking math to do it.

You are correct that the types of filters that you will likely want to use do use calculus. They are typically introduced in upper division college classes, and covered in detail in graduate classes. Do you have any mentors with an electrical engineering or controls degree?

Filtering is very much dependent on the application. So far all you've told us is that you want to use the accelerometer for positioning, but you aren't using it for positioning. That makes it very hard to help. Filtering is a tradeoff between complexity (processing power), how well it keeps what you want, and how well it's able to reject what you don't want. Ether's filter is fairly simple filter that I've used before. It's very simple as far as processing, and is adjustable which is helpful. However it won't match the performance of a more complicated filter (which may or may not be necessary).

The advantage of using LabVIEW is the instant visualization of the data (besides the large number of built in filters). You can play around with the filters without understanding the math until you find a filter (and the coefficients) that work for your data. I would start with a Butterworth filter. Without the math background, all you'd be doing is copying code, so you'd be better off finding something already implemented. You can probably find a java implementation of a Butterworth filter.

For determining position with multiple sensors, a Kalman filter is probably what you really need, but that's several orders of magnitude harder then a Butterworth filter. I've seen several threads on chiefdelphi where people talked about them, but I'm not sure that anyone's successfully implemented one for a FIRST robot.

[EricVanWyk]

Originally Posted by kearnel

I've been reading and trying to understand these algorithms but it appears that I need to understand calculus. I can't find anything that I can understand.

Edit: I'm wondering If there are any websites that explain filtering without using crazy-looking math to do it.

Designing filters takes advanced math, but using and understanding them doesn't.

Your best bet will be to find a mentor who can explain it to you. One-on-one, this will take a good 30-45 minutes provided a 10th grade math background. One-to-many takes a lot longer.

You should also install LabVIEW and play with the filters. Looking at input to output visually while tweaking parameters is remarkably helpful. I usually give my students a half hour of playing with that palette, and it really helps solidify my droning at the white board.

[Sparks333]

Really, most filters designs don't require calculus. If you want to do something like a Kalman, it does require a bit of differential equations, but I wouldn't recommend using something like that anyway. All you need to know is a few basic pieces of information - passband frequency and stopband frequency. An accelerometer will have most of its interesting information at around DC, so you'll be wanting a lowpass filter. The easiest filter you can implement is called a finite-impulse response filter (FIR), which, in discrete terms, means all you do is a multi-tap filter like Ether recommended (his is a two-tap filter, but you can realistically have as many taps as you want - the more taps you have the more it will reject higher frequencies [sharper rolloff]). There are ways to set the coefficients of each tap to favor older values over newer (that is the function of Ether's f parameter) or vice-versa, but from experience you can make it work with a a simple boxcar averaging algorithm - every tap has the same coefficient, and they all add to 1.

Looking at the beginning post, though, I do worry slightly - what you propose is to record the robot's location based on gyro and accelerometer readings. I cannot stress enough that this is incredibly difficult, especially for any extended period of time. The best you can do is robot attitude. For anything along those lines, you will actually probably want to use a Kalman, but that's a huge amount of work.

I hope this is helpful.

Sparks

[Ether]

Originally Posted by Sparks333

The easiest filter you can implement is called a finite-impulse response filter (FIR), which, in discrete terms, means all you do is a multi-tap filter like Ether recommended

Actually, the one I posted is IIR (infinite impulse response)

[Sparks333]

Right you are - missed the previous_filtered_value, read it as previous_read_value.

Sparks

[StephenNutt]

Try using an Alpha-Beta filter, see http://en.wikipedia.org/wiki/Alpha_beta_filter

It is very simple to implement, so simple for my team I've created a simple Excel spreadsheet that takes a series a data points, the alpha and beta values, and plots the raw and filtered values in a graph. I can then adjust the alpha and beta values in Excel and view the changes in real time until I see the results I like and then plug those into the robot.

Steve

[ekapalka]

Have you considered a moving average? It accumulates the last x number of data samples in an array and finds the average of them in real time. We wrote one for our rangefinders, but it should apply to just about anything. It's only about sixteen lines of code (with five curly brackets, making it more like 11 lines of functional code). We're programming in C++, but syntactically it's almost the same.