Technical:Accelerometer Fundamentals

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Added accelerometer references from the mail list discussion)
m (add unfinished post to ML in case of crash)
Line 20: Line 20:
  
 
* [http://www.st.com/stonline/products/literature/ds/12094/lis3lv02dl.pdf ST Inertial Sensor]*
 
* [http://www.st.com/stonline/products/literature/ds/12094/lis3lv02dl.pdf ST Inertial Sensor]*
 +
 +
 +
Finish and edit in - in case of email client crash
 +
> If your tracking movement with 2 3D accelerometers... What would another
 +
> one provide.
 +
<snip>
 +
> I mean  if we know the rest orientation and then suddenly get pointed at
 +
> something it would seem like the 3d vectors will show a specific values
 +
> and directions for the 2 ends of the phone depending on the center of
 +
> the arc or movement that acted on the phone.
 +
>
 +
> I would say that we can get yaw, pitch and roll just fine.. But again, I
 +
> am no expert.
 +
>
 +
You can't get all of these. You certainly cannot do decent inertial navigation.
 +
 +
Actual neo-based conclusions at bottom.
 +
 +
What can be done with absolutely perfect devices?
 +
 +
Imagine two three axis accellerometers rigidly placed on each end of an arrow.
 +
 +
How much information do you get out of these?
 +
 +
A few moments thought should reveal that the orientation of the sensors does not matter. You can resolve the three signals into one vector and magnitude.
 +
This does not change however the devices are oriented - there is no benefit in for example skewing one 45 degrees.
 +
 +
Considering the case in deep-space - the maths are simpler.
 +
(not a common use-case, but simpler to analyse)
 +
Holding the orientation steady, you can do perfect inertial navigation, and determine exactly where you are at all times. (in a flat space-time, but meh)
 +
 +
What happens when we vary the orientation?
 +
Well - it's obvious that you can subtract any common accelleration that's measured by both sensors - this does not change the orientation.
 +
 +
Remembering that we can skew the sensors against each other, and this has no effect, let's specify that they are oriented with X and Y lined up, and Z pointing in the direction of the arrow.
 +
This reveals a problem.
 +
 +
Spin the arrow on its axis, and none of the accelererometers measure anything at all - they do not move, so they do not accelerate.
 +
(you can't get round this by moving them off-axis, as you can draw an imaginary arrow between the two accelerometers which has the same problem)
 +
 +
Spin the arrow around its centre (it must spin around its centre logically if you've subtracted the overall acceleration) you can pick up pitch and yaw.
 +
 +
Now, what if we add gravity in?
 +
 +
With perfect accelerometers again, with Z axes pointing to the arrow tip.
 +
As long as the between
 +
 +
I suppose I'd better back this up with numbers.
 +
I'm assuming specs similar to the ADXL330 - simplified a little.
 +
 +
Assumptions:
 +
The Neo is a rigid object, and the accelerometers are rigidly fixed to it.
 +
The A/D has no noise.
 +
The accellerometer is perfect, other than a noise of 300uG/sqrt(Hz), and a temperature sensitivity of +-.1mG/C.
 +
I'm neglecting cross-axis sensitivity - which will need calibrated out, and non-linearity.

Revision as of 00:07, 6 June 2007

  • AFAIK, you should be able to achieve the equivalent of a 3-axis accelerometer and a gyro by using three two-axis ones, and some software...
    • To tell which way the phone is spun, you need three gyros (to measure spin around the long axes and around the USB plug, and around an axes in and out of the screen). To tell which way the phone is accelerating, you need 3 accelerometers - this is a total of 6 independent variables.
    • You can't quite derive all 6 from 3 2-axis accelerometers, as apart from geometric problems (you tend to end up with axes that coincide) the sensitivity for rotation in some axes really quite sucks. (consider the size of the gravity vector, and consider the noise of the accelerometers).
    • Having said this, there is a big trade off between 'good enough' and cost. With smart software, it may be possible to get useful function without having to have the full optimal set of hardware that would make the function perfect.

An example of an accelerometer that might be used is the one in the Wiimote, as documented in this page . This page gives the sensitivity of the accelerometer as around 300ug/sqrt(Hz).

This is almost useless unfortunately. Though it implies - given adequate filtering - that you can get a position of a meter or better over 24 hours, the very high temperature sensitivity means that even stabilising the temperature to .1C, you get a bias of up to 1mm/s^2, or 100m/s after a day, or 8600Km. (1Km in around half an hour) In real use, in a phone, without a little oven to keep the temperature stable, 3cm/s^2 or so is probably achievable, or 1Km uncertainty in around 3 minutes.

References


Finish and edit in - in case of email client crash > If your tracking movement with 2 3D accelerometers... What would another > one provide. <snip> > I mean if we know the rest orientation and then suddenly get pointed at > something it would seem like the 3d vectors will show a specific values > and directions for the 2 ends of the phone depending on the center of > the arc or movement that acted on the phone. > > I would say that we can get yaw, pitch and roll just fine.. But again, I > am no expert. > You can't get all of these. You certainly cannot do decent inertial navigation.

Actual neo-based conclusions at bottom.

What can be done with absolutely perfect devices?

Imagine two three axis accellerometers rigidly placed on each end of an arrow.

How much information do you get out of these?

A few moments thought should reveal that the orientation of the sensors does not matter. You can resolve the three signals into one vector and magnitude. This does not change however the devices are oriented - there is no benefit in for example skewing one 45 degrees.

Considering the case in deep-space - the maths are simpler. (not a common use-case, but simpler to analyse) Holding the orientation steady, you can do perfect inertial navigation, and determine exactly where you are at all times. (in a flat space-time, but meh)

What happens when we vary the orientation? Well - it's obvious that you can subtract any common accelleration that's measured by both sensors - this does not change the orientation.

Remembering that we can skew the sensors against each other, and this has no effect, let's specify that they are oriented with X and Y lined up, and Z pointing in the direction of the arrow. This reveals a problem.

Spin the arrow on its axis, and none of the accelererometers measure anything at all - they do not move, so they do not accelerate. (you can't get round this by moving them off-axis, as you can draw an imaginary arrow between the two accelerometers which has the same problem)

Spin the arrow around its centre (it must spin around its centre logically if you've subtracted the overall acceleration) you can pick up pitch and yaw.

Now, what if we add gravity in?

With perfect accelerometers again, with Z axes pointing to the arrow tip. As long as the between

I suppose I'd better back this up with numbers. I'm assuming specs similar to the ADXL330 - simplified a little.

Assumptions: The Neo is a rigid object, and the accelerometers are rigidly fixed to it. The A/D has no noise. The accellerometer is perfect, other than a noise of 300uG/sqrt(Hz), and a temperature sensitivity of +-.1mG/C. I'm neglecting cross-axis sensitivity - which will need calibrated out, and non-linearity.

Personal tools
  • AFAIK, you should be able to achieve the equivalent of a 3-axis accelerometer and a gyro by using three two-axis ones, and some software...
    • To tell which way the phone is spun, you need three gyros (to measure spin around the long axes and around the USB plug, and around an axes in and out of the screen). To tell which way the phone is accelerating, you need 3 accelerometers - this is a total of 6 independent variables.
    • You can't quite derive all 6 from 3 2-axis accelerometers, as apart from geometric problems (you tend to end up with axes that coincide) the sensitivity for rotation in some axes really quite sucks. (consider the size of the gravity vector, and consider the noise of the accelerometers).
    • Having said this, there is a big trade off between 'good enough' and cost. With smart software, it may be possible to get useful function without having to have the full optimal set of hardware that would make the function perfect.

An example of an accelerometer that might be used is the one in the Wiimote, as documented in this page . This page gives the sensitivity of the accelerometer as around 300ug/sqrt(Hz).

This is almost useless unfortunately. Though it implies - given adequate filtering - that you can get a position of a meter or better over 24 hours, the very high temperature sensitivity means that even stabilising the temperature to .1C, you get a bias of up to 1mm/s^2, or 100m/s after a day, or 8600Km. (1Km in around half an hour) In real use, in a phone, without a little oven to keep the temperature stable, 3cm/s^2 or so is probably achievable, or 1Km uncertainty in around 3 minutes.

References