Noise Reduction on 2125 Accelerometer?

Private19872

I was experimenting today with my Memsic 2125 Accelerometer in an attempt to track it's position on my table. Since it outputs acceleration, I have to take the acceleration, compound it into velocity, and then compound that into a position. So far, it almost works as intended, but it suffers from what I presume to be noise in the sensor. Whenever I move it, the position will move to where I want it to, but because the accelerations don't exactly match from start to stop, the velocity will constantly increase making the position go crazy. Has anyone tried this before? Any idea as to how I could resolve this issue? Thanks.

Beau Schwabe

Use two of them mechanically locked to the same plane of orientation and look at them differentially so that any common mode noise cancels out ( well almost cancels out ). Remember though with two accelerometers locked to the same plane if you pivot one with relation to another you can get angular rate readings similar to a gyro.

I attempted to do what you are doing to measure actual ground displacement during an earthquake ... we get lots of them here in OKLAHOMA of all places.

train nut

Integrating an accelerometer to obtain displacement is inherently noisy and prone to drift. If the acceleration signal is passed thru a 0.4Hz hipass filter it removes the DC component of the acceleration and reduces the drift. I have worked with motion transducers all my work career and recently found the frequency that seems to be the ideal filter frequency.

Private19872

Do you have any recommendations as to what object I could use for the high pass filter? Also, my code so far is pretty basic (and probably wrong). Any other suggestions on how I might go about integrating my input?

lonesock

If you just want DC-blocking, there is a neat trick here: dspguru.com/book/export/html/76. Look for "Fixed-Point DC Blocking Filter with Noise-Shaping". I haven't used it on accelerometer data, but it works well on audio data for a zero-crossing detector.

Jonathan

Beau Schwabe

For accurate measurements, some of that, what appears to be "noise", is valid data.

Correct time integration of the sampled data is going to play a key part here. True random noise will have a 50% bias on the LSB of data, whereas your actual signal will persuade the bias to something other than a 50% duty cycle over time.

The most common mistake is to truncate and round the data, which can cause severe out of control drift errors.

Beau Schwabe

Here is something I put together awhile back using a Gyroscope. The concept is similar to how you need to integrate the Accelerometer data. When using this algorithm on a Gyro, I was able to repeatably do a full 360 Deg rotation and return to Zero ... Assuming my starting point was Zero. Depending on the angle of the axis of rotation I could see evidence of a predicted maximum 15 Deg per hour drift. Which is not really drift at all, it's the rotation of the earth .... 360 Deg / 24 hours = 15 Deg / Hour

http://forums.parallax.com/discussion/127868/gyro-lisy300

ajward

@Beau - Cool, thanks for posting this link! I was experimenting along the same lines, but couldn't come up with anything that worked... at least to my satisfaction.

Amanda

Private19872

Sorry for the delay, but I was unable to do much Propeller work recently. I tried the Gyro demo, replacing the long value it added in with the X value from the M2125. For the first few seconds, it works great! Not issues at all, and the tracking is smooth. However, after about a second, whether I'm moving the chip or I let it sit still, the output from your code (the first integral) will begin to drift, and the readings start flying away again. Maybe I'm just doing something wrong here? If anything, I'd imagine it's the fact I'm trying to throw the raw values into the code. Could they possibly need some sort of filtering?