Accelerometer Fundamentals (was Re: Neo1973 Update!)

openmoko at mauve.plus.com openmoko at mauve.plus.com
Wed Jun 6 03:58:15 CEST 2007


> I think the reason for using accelerometers not solid state gyros is cost.
> Sean quoted $3 for accels on the list a while back, while 3 axis gyros
> with
> SPI were closer to $20 last I looked, and that was for one that wasn't
> available yet. Production will ramp up, prices will fall and a future
> OpenMoko will probably use an accel and a gyro, but for now 2 accels gets
> you
> most of the way there for several $ less.
>
> Compass would be interesting, to me at least.

Below being posted on
http://wiki.openmoko.org/wiki/Accelerometer_Fundamentals
In many environments, 1 accel + 3 axes compass would be  good enough, and
significantly better performing than the 2 accel solution. (compass chips
are $10 or so for 3 axes)
I note that that's a single axes gyro, the gold standard would be 3 axes
accel, and 3 axes gyro, which will likely run $70 or so at 1K.

<snip>
Sigh - this wasn't the post I meant to comment on - but it'll do as it's
late - I wrote this and the webmail system timed out, and I can't find the
original post - anyway.

This discusses the possibilities of two 3-axis accelerometers.
Actual neo-based conclusions, and what you don't need two for are at the end.

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.


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.

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.

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.

What one accelerometer alone 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.
For example, in normal driving, the ground track of the car is some
function of the position of the steering wheel. Any lateral accellerations
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.
Any accellerations 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.

Of course - the errors build up, but it's not bad for short periods.
For example, 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)
I should add more figures to this, but it's late.
It's going up on http://wiki.openmoko.org/wiki/Accelerometer_Fundamentals
in an unedited form, and I'll add more to it later. If you have any
queries about how I've come to any particular conclusion, please put it on
the discussion page of that page, and I'll flesh it out.






More information about the community mailing list