Remove Gravity from Accelerometer values

[trustnoone]

Hay guys, so I have an accelerometer which is obtaining values in either G or m/s/s depending on how I program it. Testing it everything seems fine and I get 1 G on one of the axis depending on how I hold it which is great.
The problem is I'm using an ADXL345 accelerometer which gives me values in X, Y and Z but I only want the acceleration values, unfortunately I am also getting acceleration values with gravity, so essentially I want to remove gravity.

Note that I don't care so much about orientation, but I do want to know its magnitude I guess. Also its going to be placed in a ball which a person can pick up in any sort of way and wave it around (not throw it) so I won't know what the orientation is at all.

So far the things I've heard in doing it is to derive the values then reintegrate it so that I remove the constant component (gravity) the other way i heard about it is through a filter pretty much stealing the same thing as they are doing in an android example except for arduino, but I don't know if that's really going to be that accurate, and I don't quite understand the example either.

Any help would be great!

 

[D H]

You need to add gravity (vectorially), not subtract it.

The reason an accelerometer at rest on your table measures 1g *upward* is because an accelerometer can't sense gravity. No local experiment can sense gravity, and your tiny little chip definitely qualifies as a "local experiment".

So if an accelerometer can't measure gravity, why does it register a 1g acceleration? The answer is simple. Draw a free body diagram of the forces acting on the accelerometer. There are only two. The table pushes the accelerometer upward and gravity pulls the accelerometer downward. The net force is almost zero. Since the accelerometer can't sense acceleration due to gravity, all it can sense is that 1g upward force by the table.

 

[trustnoone]

You need to add gravity (vectorially), not subtract it.

The reason an accelerometer at rest on your table measures 1g *upward* is because an accelerometer can't sense gravity. No local experiment can sense gravity, and your tiny little chip definitely qualifies as a "local experiment".

So if an accelerometer can't measure gravity, why does it register a 1g acceleration? The answer is simple. Draw a free body diagram of the forces acting on the accelerometer. There are only two. The table pushes the accelerometer upward and gravity pulls the accelerometer downward. The net force is almost zero. Since the accelerometer can't sense acceleration due to gravity, all it can sense is that 1g upward force by the table.

Woah okay that sort of blows my mind a bit, but it does make sense, thanks heaps for clearing that up for me, although I think my accelerometer is feeling inadequate now since you called it tiny :P. Unfortunately I'm still at a loss though, like it makes sense to add gravity vectorially now but will I still be able to do that without knowing the orientation of my accelerometer. Along with the fact that my accelerometer may be accelerating as it does this?

 

[D H]

You have a six degree of freedom problem. You can't solve this problem with a three dimensional measurement. This is why cell phone manufacturers are now making MEMS gyros and compasses a part of their smart phones and why Nintendo has added a Wii MotionPlus (which contains MEMS gyros) to its Wii Remote.

You have another problem on your hands, that of dead reckoning. Your accelerometer isn't perfect. No instrument is. Some of the errors in your accelerometer:

• Bias. An accelerometer in free fall should report zero acceleration in all axes. They never do. They instead report some non-zero value when the accelerometer is in free fall. This bias is always there. Integrating a bias yields a ramp, and integrating that yields a parabolic curve. Velocity errors due to bias grow linearly with time, position errors grow quadratically.
  
  Bias is nasty, but it is largely addressable. You need to calibrate the instrument. The accelerometer x and y axes should register zero acceleration if you keep the accelerometer perfectly still and align it so the accelerometer z axis is perfectly vertical. Now you know the x and y biases. Rotate by 90 degrees and now you'll have data for bias in z (and another measurement of bias in either x or y).
  
  
• Scale factor. When your accelerometer reports 0.1g, the actual acceleration might be 0.11g, and when it reports 1.0g, the actual acceleration might be 1.1g. This consistent 10% error is a result of a scale factor error. Like bias, this error source can be addressed to some extent with calibration.
  
  
• Noise. Your accelerometer is tiny. (I hope I didn't hurt it's itty bitty feelings.) It is subject to thermal and quantum variations. The output is a bit noisy. Sample the accelerometer faster (select a higher output data rate) and the output will be noisier. Sample even faster and it will be noisier yet. This noise generally grows with the square root of the sampling frequency. You would think this noise would average out. It doesn't. The integral of white noise is a random walk (aka drunkard's walk). Integrating a random walk eventually yields a mess.
  
  
• Misalignment. The accelerometer's x, y, and z axes should be orthogonal. They aren't, especially in a tiny little chip-based accelerometer such as your ADXL345. The spec sheet says the non-orthogonality might be as much as a degree. That's the internal misalignment. There's also misalignment added by you. The orientation in which you planned to attach the accelerometer to your system and the orientation in which you actually attached the accelerometer will never be exactly the same.
  
  
• Nonlinearity. Suppose the reported acceleration in one axis changes from 0.1g to 0.2g and later from 1.1g to 1.2g. You would think that those two changes are the same, but they aren't. Your accelerometer pretends to be linear, but it's not. (The spec sheet says you can ignore this problem. In critical applications, you can't.)

Many of the other errors can be addressed by calibration. Noise can't. It's the noise that leads to the dead reckoning problem.

 

[trustnoone]

Thats really helpful DH thanks heaps for that, its sounding like my derivative and integrating idea would be quite bad then as it would be quite inaccurate. I'm hoping some of these problems I will be able to neglect, I'm more just trying to get a value of little movement, lots of movement, heaps of movement etc, as opposed to an actual quantified value (such as the acceleration is this or velocity is that). So I'm hoping it would rely more on 0.1g is quite different to 1.3g so its likely obvious that they moved a lot here as opposed to they moved "this much". Using a difference value I hope might help reduce the effect of linearity and misalignment and scale factor. I'm also hoping Bias will be close enough, this has been heaps useful though, I really needed info like this which is easy to understand and use thanks heaps!
So does that mean there's no way I can do it as it is? I'm wondering whether its possible if I just measured for approximate 1G value, and if its near there I use that as the main orientation and just change it every time I measure close to 1G, could I do that by going sqrt(x^2+Y^2+z^2) to find if its close to gravity or 1G from all the axis and then try to work out pitch and roll and use those values to quaternion to the right frame of reference? I'm assuming it would be quite inaccurate but it seems to be the only way I can get something close to what I want.

 

[meBigGuy]

I think of an acceleraometer as a weight connected to 3 pairs of orthogonal springs. The forces on the springs produce a voltage. When sitting at rest gravity is forcing the weight down.

You are trying to determine in what direction that force is being applied at any instant and compensate for it.

What the android example does is assume there is a sudden movement in a single direction which is seen by a high pass filter. If there is rotational movement then you get weird results since the algorithm depends on gravity being a constant (slowly changing) to all the sensors (detectable by a low pass filter).

I think you also need a gyro to measure rotation. Then you know the direction of gravity. (gives you the 6 degrees you need)

 

[D H]

A gyro tells angular velocity, not orientation. They have to be integrated to give orientation, which means there's a dead reckoning problem. This is why some spacecraft have star trackers, others have magnetometers, and smart phones are starting to have compasses. To make matters worse, this is a non-trivial integration.

trustnoone, what is your education level in this area? Do you know what a Kalman filter is?

 

[meBigGuy]

hmmm. I was thinking a gyro would indicate orientation, but that's obviously not the case. It's happy at any orientation, and tells you when you change it.

It's a tough problem. http://www-scf.usc.edu/~peiyingc/WiiStick_PeiyingChinag.pdf talks about the wiiremote.

 

[trustnoone]

The wiiremote looks kool, seems like they just use the IR sensor to get around it, sort of feels like a very expensive way to go about it though? But I guess they felt it could be used for more then just finding out orientation.
Apologies about my slow message back, I just read up on the Kalman filter now, sort of makes sense but it doesn't seem very easy, or at least with my limited knowledge.

Currently I just get the magnitude of all the axis and test to see if its around the same as gravity and use that as calibration for any times that is not around the gravity value. So far it seems okay, I'm not using it for anything super accurate. I'm more just trying to obtain a yes he is moving as opposed to not moving, but this has cleared up sooooo much for me. I actually understand more about how the accelerometer works and why I am getting the values that I am getting. Cheers guys!

 

[CodeJingle]

Tracking orientation is not a dead reckoning problem. Calculate the direction of gravity and calculate the direction of magnetic north and you are golden. Isolating gravity is hard within a system under user acceleration, so integrate between the brief periods where you can directly calculate gravity. 3 axis accelerometer, 3 axis magnetometer, 3 axis gyroscope. 9-axis MEMS