Technical:Accelerometer Fundamentals

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (reorg, tidy)
m (Category: -Hardware, (It's in sub 'Accelerometer'))
 
(23 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 
==What an Accelerometer is==
 
==What an Accelerometer is==
 
An accelerometer simply measures acceleration, either due to motion or due to gravity.
 
An accelerometer simply measures acceleration, either due to motion or due to gravity.
 +
 +
Acceleration is measured in m/s<sup>2</sup>.
 +
 +
The acceleration at near the surface of the earth is around 9.8m/s<sup>2</sup> (or 32ft/s<sup>2</sup>), which can be an unwieldy number, so 9.8m/s<sup>2</sup>  is often labeled 1G.
 +
 +
This means that if you drop an object from some height (assuming a vacuum), after 1 second it will be falling at 9.8m/s, a speed of 19.6m/s after 2 seconds, and so on.
 +
 +
===Formulae ===
 +
*Displacement after movement at an initial speed for a given time
 +
**s=u * t + 1/2 a * t<sup>2</sup>
 +
**initial speed * time + 1/2 * acceleration * time squared
 +
*Speed after Acceleration from rest
 +
**v=a * t
 +
**Speed = Acceleration * time
  
 
==What one three-axis accelerometer can do==
 
==What one three-axis accelerometer can do==
  
*If the orientation of the phone is held constant - for example, clamped into a car holder, then you can make pretty good guesses about the correlation of aceleration and position.
+
*If the orientation of the phone is held constant - for example, clamped into a car holder, then you can make pretty good guesses about the correlation of acceleration and position.
**In normal driving, the ground track of the car is some function of the position of the steering wheel. Any lateral accelerations against the current known course mean that the steering wheel has been applied, and the car is turning at a rate which can be computed by calculating it with the cars known speed.
+
**In normal driving, any lateral accelerations mean that the car is turning at a rate which can be computed if the speed of the car is known.
**Accelerations in line with the course mean that the car is slowing up or down, and any vertical accelerations mean that the car is going up or down a hill.
+
**Accelerations in line with the course mean that the car is slowing up or down, and any vertical accelerations mean that there is a bump, or a rise or fall in the road.
**Errors build up, but it's not bad for short periods.
+
**Errors build up, but it's not bad for short periods, 1cm/s^2 of error, with a car going in a straight line at 20m/s, takes a bit over a minute to move from a true direction of northeast - say, to a false direction of northnortheast. (the position is off after this period by a hundred metres or two)
**1cm/s^2 of error, with a car going in a straight line at 20m/s, takes a bit over a minute to move from a true direction of northeast - say, to a false direction of northnortheast. (the position is off after this period by a hundred metres or two)
+
  
 
*When hand-held, and stationary, the phone has quite accurate (better than a degree) knowledge of where 'down' is.  
 
*When hand-held, and stationary, the phone has quite accurate (better than a degree) knowledge of where 'down' is.  
Line 18: Line 31:
 
===What can be done with absolutely perfect devices?===
 
===What can be done with absolutely perfect devices?===
  
Imagine two three axis accellerometers rigidly placed on each end of an arrow.
+
Imagine two three axis accelerometers rigidly placed on each end of an arrow.
  
 
How much information do you get out of these?
 
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.
+
A few moments thought should reveal that the orientation of the sensors does not matter. You can resolve the three signals into one direction and size.
 
This does not change however the devices are oriented - there is no benefit in for example skewing one 45 degrees.
 
This does not change however the devices are oriented - there is no benefit in for example skewing one 45 degrees.
 
+
====Neglecting gravity====
 
Considering the case in deep-space - the maths are simpler.
 
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?
+
Holding the orientation steady, you can do perfect inertial navigation, and determine exactly where you are at all times.
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.
+
*What happens when we vary the orientation?
This reveals a problem.
+
**You can subtract any common acceleration 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.
+
*Spin the arrow on its axis, and none of the accelerometers 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)
+
**(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.
+
*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.
  
 +
====With Gravity====
 
Now, what if we add gravity in?
 
Now, what if we add gravity in?
  
 
With perfect accelerometers again, with Z axes pointing to the arrow tip.
 
With perfect accelerometers again, with Z axes pointing to the arrow tip.
As long as the Z axes does not point in the same direction as gravity + current acceleration, then you can determine roll, pitch, yaw, and XYZ acceleration.
 
If the Z axes does point to the acceleration vector, then you lose track of roll.
 
In theory - with perfect accelerometers, this does not matter.
 
Because you can never line it up perfectly.
 
In practice, with real ones, it gets more complex.
 
Roll signal/noise will drop as the acceleration vector closes on the Z axes, and be useless once it gets within the noise.
 
  
 +
*As long as the Z axes does not point in the same direction as gravity + current acceleration, then you can determine roll, pitch, yaw, and XYZ acceleration.
 +
*If the Z axes do point to the acceleration vector, then you lose track of roll.
 +
**In theory - with perfect accelerometers, this does not matter because you can never line it up perfectly.
 +
***In practice, with real ones, it gets more complex.
 +
***Roll signal/noise will drop as the acceleration vector closes on the Z axes, and be useless once it gets within the noise.
  
 
===Numbers===
 
===Numbers===
 
I'm assuming specs similar to the ADXL330 - simplified a little.
 
I'm assuming specs similar to the ADXL330 - simplified a little.
 +
(The accelerometer mentioned on the mailing list as being included in GTA02 is significantly worse than this - some 20 times more noise)
  
 
Assumptions:
 
Assumptions:
The Neo is a rigid object, and the accelerometers are rigidly fixed to it.
+
*The Neo is a rigid object, and the accelerometers are rigidly fixed to it.
The A/D has no noise.
+
*A/D has no noise and infinite bits.
The accellerometer is perfect, other than a noise of 300uG/sqrt(Hz), and a temperature sensitivity of +-.1mG/C.
+
*Accelerometer only has
I'm neglecting cross-axis sensitivity - which will need calibrated out, and non-linearity.
+
**A noise of 300uG/sqrt(Hz)
 +
**Temperature sensitivity of +-.1mG/C.
 +
***I'm neglecting cross-axis sensitivity - which will need calibrated out, and non-linearity.
  
 
For interactive use.
 
For interactive use.
High-pass filtering the accelerometer with a bandwidth of 10Hz - you can't filter it much more than that or you lose important 'wobbles', because you need to integrate them to come up with a position - leads to a noise floor of 300uG/sqrt(Hz) *sqrt(10Hz) = 1mG. (RMS (No, not that RMS))
+
High-pass filtering the accelerometer with a bandwidth of 10Hz - you can't filter it much more than that or you lose important 'wobbles', because you need to integrate them to come up with a position - leads to a noise floor of 300uG/sqrt(Hz) *sqrt(10Hz) = 1mG. (RMS)
  
 
Neglecting roll for the moment.
 
Neglecting roll for the moment.
  
1mG is an accelleration of 1cm/s^2.
+
1mG is an acceleration of 1cm/s^2.
  
 
If the accelerometers are spaced 10cm apart, then the radius between each and the center is 5cm, meaning the circumference of the circle is 30cm.
 
If the accelerometers are spaced 10cm apart, then the radius between each and the center is 5cm, meaning the circumference of the circle is 30cm.
 
Integrating over 1s, noise is around 3cm/s^2.
 
Integrating over 1s, noise is around 3cm/s^2.
  
After 1s, if you happen to hit an average noise peak in each accellerometer at the opposite point - something that'll happen once every 5-10 seconds or so, (absolute peaks are much worse) what happens to the pointing?
+
After 1s, if you happen to hit an average noise peak in each accelerometer at the opposite point - something that'll happen once every 5-10 seconds or so, (absolute peaks are much worse) what happens to the pointing?
  
 
Well - the velocity reads out as 6cm/s^2 wrong, which means that the position is now out by 3cm, or 10 degrees.
 
Well - the velocity reads out as 6cm/s^2 wrong, which means that the position is now out by 3cm, or 10 degrees.
===Results===
+
 
 +
==Results==
 
What does this mean though?
 
What does this mean though?
Well, if we are more or less stationary, we have 'down' very accurately.
 
But that's almost all we have.
 
  
Without roll, you cannot tell pointing.
+
For gentle twisting and turning, the differential accelerations are impossible to tell from noise.
However, in the best case - phone on its back, accelleration vector down, and turning in a vehicle, you may be able to tell sharp turns, not much more.
+
  
Because the differential accelerations are so small, and comparable to the noise floor for gentle turning and twisting, there are basically two ways that they can be useful.
+
There are broadly two regimens where they may be of use.
  
 
When more or less stationary:
 
When more or less stationary:
Picking up turning about the gravity axis - if you are looking at the phone with it in front of you at chest level, with accelerometers at top and bottom for example, this will let you pick up sharp rotations of the phone around the vertical axis - keeping the angle the screen keeps with the floor constant. But they have to be sharp. It will probably not be good enough for keeping a map aligned when you turn round in place, for example. It may be adequate for some games, but again, the movements have to be sharp, it will false signal as you decrease the wanted signal.
+
*Picking up turning about the gravity axis - if you are looking at the phone with it in front of you at chest level, with accelerometers at top and bottom for example, this will let you pick up sharp rotations of the phone around the vertical axis - keeping the angle the screen keeps with the floor constant.  
 +
*Roll signal-noise drops as the phone long axis approaches vertical, becoming useless well before it is vertical.
 +
*Movements have to be sharp and fairly large.
 +
*It will probably not be good enough for keeping a map aligned when you turn in place.
 +
**It may be adequate for some games, but again, the movements have to be sharp, it will false signal as you decrease the wanted signal.
 +
**The difference in acceleration when the device is swung like a baseball bat is fairly pronounced, and the speed of the swing can be accurately measured. Its exact path however cannot.
  
 
When in motion:
 
When in motion:
It may be adequate to improve positioning of the GPS, when sharply going round corners, or doing high-G aerobatics. It can fill in _short_ - 3-5s gaps in GPS coverage.  
+
*Improving the positioning of the GPS, it may give enough information to resolve sharp turns.
 +
*It can fill in _short_ - 3-5s gaps in GPS coverage, if the orientation of the phone is known.
 +
**In the best case - phone on its back, acceleration vector down, and turning in a vehicle, you may be able to tell sharp turns.
 +
***This is only useful if the phone is handheld, or not fixed in position to the vehicle, or if the vehicle does not go where it points.
 +
 
 +
In any condition:
 +
*Eliminating impossible points from the GPS data, if the maximum possible distance moved by the accelerometer over a time is under the difference between two GPS readings, then the GPS must be incorrect.
 +
*Recording taps on the device - the output will be broadly an intensity of tap, and the relative distance between the accelerometers and the tap.
  
 
And this is completely neglecting the temperature sensitivity.
 
And this is completely neglecting the temperature sensitivity.
  
What it can't do.
+
==What it can't do.==
Inertial navigation over more than several seconds.
+
Inertial navigation or rotation over more than several seconds. For big movements the GPS could be used, for smaller movements in the Z direction (> 25 cm) a pressure sensor could be added, see [[Wish List - Hardware - Atmospheric]], and for inertial rotation a magnetometer (digital compass) can be used, see [[Wishlist - Hardware: Digital compass]].
 
+
 
+
 
+
 
+
 
+
===Misc===
+
 
+
*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 [http://www.wiili.org/index.php/Motion_analysis this page] .
+
[http://www.analog.com/en/prod/0%2C2877%2CADXL330%2C00.html This page] gives the sensitivity of the accelerometer as around 300ug/sqrt(Hz).
+
 
+
'''References'''
+
  
 +
=References=
 
* [http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0112690EFA4082&tid=tshbMERC Freescale products]
 
* [http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0112690EFA4082&tid=tshbMERC Freescale products]
 
* [http://www.freescale.com/files/sensors/doc/app_note/AN3107.pdf Measuring Tilt with low-g accelerometers (Freescale doc)]*
 
* [http://www.freescale.com/files/sensors/doc/app_note/AN3107.pdf Measuring Tilt with low-g accelerometers (Freescale doc)]*
  
 
* [http://www.analog.com/en/cat/0,2878,764,00.html Analog Devices  MEMS and Sensors]
 
* [http://www.analog.com/en/cat/0,2878,764,00.html Analog Devices  MEMS and Sensors]
* [http://www.analog.com/en/prod/0,2877,ADXL330,00.html Analog Devices  ADXL330]
+
* [http://www.analog.com/en/prod/0,2877,ADXL330,00.html Analog Devices  ADXL330] ([http://www.wiili.org/index.php/Motion_analysis the sensor used in the Wiimote (only one sensor)])
  
 
* [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]*
 +
 +
* [http://www.memsic.com/ Memsic accelerometers]*
 +
 +
[[Category:Accelerometer]]

Latest revision as of 21:48, 15 September 2008

Contents

[edit] What an Accelerometer is

An accelerometer simply measures acceleration, either due to motion or due to gravity.

Acceleration is measured in m/s2.

The acceleration at near the surface of the earth is around 9.8m/s2 (or 32ft/s2), which can be an unwieldy number, so 9.8m/s2 is often labeled 1G.

This means that if you drop an object from some height (assuming a vacuum), after 1 second it will be falling at 9.8m/s, a speed of 19.6m/s after 2 seconds, and so on.

[edit] Formulae

  • Displacement after movement at an initial speed for a given time
    • s=u * t + 1/2 a * t2
    • initial speed * time + 1/2 * acceleration * time squared
  • Speed after Acceleration from rest
    • v=a * t
    • Speed = Acceleration * time

[edit] What one three-axis accelerometer can do

  • If the orientation of the phone is held constant - for example, clamped into a car holder, then you can make pretty good guesses about the correlation of acceleration and position.
    • In normal driving, any lateral accelerations mean that the car is turning at a rate which can be computed if the speed of the car is known.
    • Accelerations in line with the course mean that the car is slowing up or down, and any vertical accelerations mean that there is a bump, or a rise or fall in the road.
    • Errors build up, but it's not bad for short periods, 1cm/s^2 of error, with a car going in a straight line at 20m/s, takes a bit over a minute to move from a true direction of northeast - say, to a false direction of northnortheast. (the position is off after this period by a hundred metres or two)
  • When hand-held, and stationary, the phone has quite accurate (better than a degree) knowledge of where 'down' is.
    • Tilt in two directions can easily be calculated
    • Roll about the 'down' axis cannot.

[edit] What two three axis accelerometers can do

[edit] What can be done with absolutely perfect devices?

Imagine two three axis accelerometers 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 direction and size. This does not change however the devices are oriented - there is no benefit in for example skewing one 45 degrees.

[edit] Neglecting gravity

Considering the case in deep-space - the maths are simpler.

Holding the orientation steady, you can do perfect inertial navigation, and determine exactly where you are at all times.

  • What happens when we vary the orientation?
    • You can subtract any common acceleration 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 accelerometers 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.

[edit] With Gravity

Now, what if we add gravity in?

With perfect accelerometers again, with Z axes pointing to the arrow tip.

  • As long as the Z axes does not point in the same direction as gravity + current acceleration, then you can determine roll, pitch, yaw, and XYZ acceleration.
  • If the Z axes do point to the acceleration vector, then you lose track of roll.
    • In theory - with perfect accelerometers, this does not matter because you can never line it up perfectly.
      • In practice, with real ones, it gets more complex.
      • Roll signal/noise will drop as the acceleration vector closes on the Z axes, and be useless once it gets within the noise.

[edit] Numbers

I'm assuming specs similar to the ADXL330 - simplified a little. (The accelerometer mentioned on the mailing list as being included in GTA02 is significantly worse than this - some 20 times more noise)

Assumptions:

  • The Neo is a rigid object, and the accelerometers are rigidly fixed to it.
  • A/D has no noise and infinite bits.
  • Accelerometer only has
    • A noise of 300uG/sqrt(Hz)
    • Temperature sensitivity of +-.1mG/C.
      • I'm neglecting cross-axis sensitivity - which will need calibrated out, and non-linearity.

For interactive use. High-pass filtering the accelerometer with a bandwidth of 10Hz - you can't filter it much more than that or you lose important 'wobbles', because you need to integrate them to come up with a position - leads to a noise floor of 300uG/sqrt(Hz) *sqrt(10Hz) = 1mG. (RMS)

Neglecting roll for the moment.

1mG is an acceleration of 1cm/s^2.

If the accelerometers are spaced 10cm apart, then the radius between each and the center is 5cm, meaning the circumference of the circle is 30cm. Integrating over 1s, noise is around 3cm/s^2.

After 1s, if you happen to hit an average noise peak in each accelerometer at the opposite point - something that'll happen once every 5-10 seconds or so, (absolute peaks are much worse) what happens to the pointing?

Well - the velocity reads out as 6cm/s^2 wrong, which means that the position is now out by 3cm, or 10 degrees.

[edit] Results

What does this mean though?

For gentle twisting and turning, the differential accelerations are impossible to tell from noise.

There are broadly two regimens where they may be of use.

When more or less stationary:

  • Picking up turning about the gravity axis - if you are looking at the phone with it in front of you at chest level, with accelerometers at top and bottom for example, this will let you pick up sharp rotations of the phone around the vertical axis - keeping the angle the screen keeps with the floor constant.
  • Roll signal-noise drops as the phone long axis approaches vertical, becoming useless well before it is vertical.
  • Movements have to be sharp and fairly large.
  • It will probably not be good enough for keeping a map aligned when you turn in place.
    • It may be adequate for some games, but again, the movements have to be sharp, it will false signal as you decrease the wanted signal.
    • The difference in acceleration when the device is swung like a baseball bat is fairly pronounced, and the speed of the swing can be accurately measured. Its exact path however cannot.

When in motion:

  • Improving the positioning of the GPS, it may give enough information to resolve sharp turns.
  • It can fill in _short_ - 3-5s gaps in GPS coverage, if the orientation of the phone is known.
    • In the best case - phone on its back, acceleration vector down, and turning in a vehicle, you may be able to tell sharp turns.
      • This is only useful if the phone is handheld, or not fixed in position to the vehicle, or if the vehicle does not go where it points.

In any condition:

  • Eliminating impossible points from the GPS data, if the maximum possible distance moved by the accelerometer over a time is under the difference between two GPS readings, then the GPS must be incorrect.
  • Recording taps on the device - the output will be broadly an intensity of tap, and the relative distance between the accelerometers and the tap.

And this is completely neglecting the temperature sensitivity.

[edit] What it can't do.

Inertial navigation or rotation over more than several seconds. For big movements the GPS could be used, for smaller movements in the Z direction (> 25 cm) a pressure sensor could be added, see Wish List - Hardware - Atmospheric, and for inertial rotation a magnetometer (digital compass) can be used, see Wishlist - Hardware: Digital compass.

[edit] References

Personal tools

What an Accelerometer is

An accelerometer simply measures acceleration, either due to motion or due to gravity.

What one three-axis accelerometer can do

  • If the orientation of the phone is held constant - for example, clamped into a car holder, then you can make pretty good guesses about the correlation of aceleration and position.
    • In normal driving, the ground track of the car is some function of the position of the steering wheel. Any lateral accelerations against the current known course mean that the steering wheel has been applied, and the car is turning at a rate which can be computed by calculating it with the cars known speed.
    • Accelerations in line with the course mean that the car is slowing up or down, and any vertical accelerations mean that the car is going up or down a hill.
    • Errors build up, but it's not bad for short periods.
    • 1cm/s^2 of error, with a car going in a straight line at 20m/s, takes a bit over a minute to move from a true direction of northeast - say, to a false direction of northnortheast. (the position is off after this period by a hundred metres or two)
  • When hand-held, and stationary, the phone has quite accurate (better than a degree) knowledge of where 'down' is.
    • Tilt in two directions can easily be calculated
    • Roll about the 'down' axis cannot.

What two three axis accelerometers can do

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 Z axes does not point in the same direction as gravity + current acceleration, then you can determine roll, pitch, yaw, and XYZ acceleration. If the Z axes does point to the acceleration vector, then you lose track of roll. In theory - with perfect accelerometers, this does not matter. Because you can never line it up perfectly. In practice, with real ones, it gets more complex. Roll signal/noise will drop as the acceleration vector closes on the Z axes, and be useless once it gets within the noise.


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.

For interactive use. High-pass filtering the accelerometer with a bandwidth of 10Hz - you can't filter it much more than that or you lose important 'wobbles', because you need to integrate them to come up with a position - leads to a noise floor of 300uG/sqrt(Hz) *sqrt(10Hz) = 1mG. (RMS (No, not that RMS))

Neglecting roll for the moment.

1mG is an accelleration of 1cm/s^2.

If the accelerometers are spaced 10cm apart, then the radius between each and the center is 5cm, meaning the circumference of the circle is 30cm. Integrating over 1s, noise is around 3cm/s^2.

After 1s, if you happen to hit an average noise peak in each accellerometer at the opposite point - something that'll happen once every 5-10 seconds or so, (absolute peaks are much worse) what happens to the pointing?

Well - the velocity reads out as 6cm/s^2 wrong, which means that the position is now out by 3cm, or 10 degrees.

Results

What does this mean though? Well, if we are more or less stationary, we have 'down' very accurately. But that's almost all we have.

Without roll, you cannot tell pointing. However, in the best case - phone on its back, accelleration vector down, and turning in a vehicle, you may be able to tell sharp turns, not much more.

Because the differential accelerations are so small, and comparable to the noise floor for gentle turning and twisting, there are basically two ways that they can be useful.

When more or less stationary: Picking up turning about the gravity axis - if you are looking at the phone with it in front of you at chest level, with accelerometers at top and bottom for example, this will let you pick up sharp rotations of the phone around the vertical axis - keeping the angle the screen keeps with the floor constant. But they have to be sharp. It will probably not be good enough for keeping a map aligned when you turn round in place, for example. It may be adequate for some games, but again, the movements have to be sharp, it will false signal as you decrease the wanted signal.

When in motion: It may be adequate to improve positioning of the GPS, when sharply going round corners, or doing high-G aerobatics. It can fill in _short_ - 3-5s gaps in GPS coverage.

And this is completely neglecting the temperature sensitivity.

What it can't do. Inertial navigation over more than several seconds.



Misc

  • 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).

References