How to process the accelerometer data so that unnecessary noise is removed while retaining the interactiveness.

I started a new thread as the existing accelerometer thread was focused on fremantle API for it.

Lately I've been searching for commonly used ways to noise filter accelerometer data. The wiki page http://wiki.maemo.org/Accelerometers has only one processing example (Exponentially dampening system. Order 1 IIR filter for the signal processing guys). Some searching has revealed that similar exponential damping is used also by iphone developers, atleast it's commonly thrown around on forums and on tutorials.

While this is a ok way to remove the noise it tends to suffer from a rather bad latency issues, which is why wiki page recommended that fps must be over 25. Yet even when it is it still tends to lag quite a lot (takes almost a second to settle on the final value, tested with fps 36).

I've been playing with filtering the data with slightly higher order filters and the results seem good. The end result is quite smooth and the latency, especially when turning the phone quickly (e.g turn a vehicle on a game as an input example) is much better compared to exponential dampening.

I'd like to know what kind of ways various developers have used to filter the accelerometer data, what sort of problems you've encountered and how you've solved them? And do you consider that there would be need for making some documentation and examples of filtering techniques for programmers?

Moved to N900 forum. Lcuk's code works pretty nicely, and yes, expos are going to be your friend.

I tried to search what you mean by "Lcuk's code" but to no avail. Which specific application are you referring at? Also by expos you refer to the exponential dampening?

I'm going to post an example program eventually which compares various ways of processing the data, basically unfiltered vs damped like in the examples vs order 2 IIR filter made with Stetson-Harrison method + matlab.

You might get away with using a simple rolling average or a weighted rolling average (as you can't be symmetrical about the current reading, unless you can see into the future, so weight the most recent readings more heavily). This will suffer some lag, but depending on the sampling rate it will probably be too small to notice.

Should be more computationally efficient than trying to implement a true convolution/freq domain filter on the device.

Order 2 IIR filter requires 5 multiplications and 4 additions per input sample. So the processor usage is of the same order as it is with rolling average filter.

A rolling average is a convolution filter itself, and the order of that filter is the same as the amount of samples considered. So basically filters are used already.

I have an example program ready (I basically ripped off the simplegl example program and made a line which turns based on accelerometer readings). The FPS is fixed at 36fps currently. Even at this refresh rate the exponential dampening feels really slow. I'm going to upload it when I'll make a button which allows the filters to be changed on the fly. Currently I just compile a different version with a different filter.

I uploaded the filtertest program filtertest. Just copy it to the device and run. Spacebar changes the current filter. Touch the screen to quit.

There are 4 filters as of now. The first one is unfiltered, second one is the one provided by maemo wiki example and the third and fourth ones are different order 2 IIR filters. The actual code calculating the output is identical for all filters (only the relevant values are changed. e.g unfiltered has all other values 0 except the first input sample which has value 1).

The final filter ofcourse can be changed. I've played around with different values somewhat but the provided one is imho rather good example of the original point.

Tell me what you think.