Accelerometer + Tilt compensation
jdhar
based application... lots of google searches show how to calculate
tilt with an accelerometer ,but that is not quite what I am looking
for.
I need to measure 3-axis acceleration of a moving vessel with my
device.. the problem is the device may not be mounted truly flat. For
example, if it's tilted slightly on the X-axis, the X-axis will always
read a slight gravity component at DC, and the Z-axis will have a
little bit removed.
The problem is this: If the vessel moves perfectly along the "flat x-
axis", since my device is slightly tilted on the X-axis, this
acceleration will result in a change in the Z-axis.
So I am wondering if there is a way I can "rotate the device" to true
0 degrees using post-processing/math. If I could do this, then that
forward motion along the TRUE X-axis would result in a reading that
only changed the X-axis, not the Z-along with it. I can get samples at
DC, so I could easily calculate what the starting tilt is. So if at
DC, the X-axis reads -0.1g and the Z-axis 0.98g for example, I don't
think it's as simple as adding/subtracting those offsets all the time
since that doesn't take into account the component of one into the
other..
Thanks.
Frank Buss
> So I am wondering if there is a way I can "rotate the device" to true
> 0 degrees using post-processing/math. If I could do this, then that
> forward motion along the TRUE X-axis would result in a reading that
> only changed the X-axis, not the Z-along with it. I can get samples at
> DC, so I could easily calculate what the starting tilt is. So if at
> DC, the X-axis reads -0.1g and the Z-axis 0.98g for example, I don't
> think it's as simple as adding/subtracting those offsets all the time
> since that doesn't take into account the component of one into the
> other..
If you are using atan2 ( http://en.wikipedia.org/wiki/Atan2 ) to calculate
the angle between two axis, do this at calibration time and then subtract
this value from the angle you measure.
If you want to compensate all 3 axis, an nice solution might be using
quaternions ( http://en.wikipedia.org/wiki/Quaternion ). Quaternions are
especially useful, if you want to track movements. A quarternion can be
used to repesent orientation and rotations:
http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation
E.g. the scripting language of Second Live uses quarternions, for
controlling the orientation and movement of scripted objects in 3D.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Rich Webb
wrote:
>I am looking for a method of compensating for tilt in an accelerometer-
>based application... lots of google searches show how to calculate
>tilt with an accelerometer ,but that is not quite what I am looking
>for.
>
>I need to measure 3-axis acceleration of a moving vessel with my
>device.. the problem is the device may not be mounted truly flat. For
>example, if it's tilted slightly on the X-axis, the X-axis will always
>read a slight gravity component at DC, and the Z-axis will have a
>little bit removed.
You have six degrees of freedom that you need to be concerned with:
translation along each unit vector and also rotation around each.
Inertial measuring units typically do this with the second derivative of
translation and the first of rotation, i.e., accelerometers and rate
gyros. For an unconstrained system, you have to have all six.
In a constrained system (e.g., it's not moving), you can infer
orientation by measuring the three-axis acceleration, modulo a correct
estimate for the local gravity vector and the bias and scale factors of
your instruments. Well that and earth rate, non-aligned gravity and
earth's rotational frames of reference, the shape of the geoid, etc.
>The problem is this: If the vessel moves perfectly along the "flat x-
>axis", since my device is slightly tilted on the X-axis, this
>acceleration will result in a change in the Z-axis.
>
>So I am wondering if there is a way I can "rotate the device" to true
>0 degrees using post-processing/math.
Search on "strapdown inertial navigation" ...
>If I could do this, then that
>forward motion along the TRUE X-axis would result in a reading that
>only changed the X-axis, not the Z-along with it. I can get samples at
>DC, so I could easily calculate what the starting tilt is. So if at
>DC, the X-axis reads -0.1g and the Z-axis 0.98g for example, I don't
>think it's as simple as adding/subtracting those offsets all the time
>since that doesn't take into account the component of one into the
>other..
... but you still need gyros.
--
Rich Webb Norfolk, VA
jdhar
> If you are using atan2 (http://en.wikipedia.org/wiki/Atan2) to calculate
> the angle between two axis, do this at calibration time and then subtract
> this value from the angle you measure.
>
subtracting this from the angle I measure won't achieve what I need (I
don't think at least). Once in motion, all I have are 3 forces in the
X,Y,Z directions... I need a way to translate that initial angle to
modify those 3 vectors, right?
> If you want to compensate all 3 axis, an nice solution might be using
> quaternions (http://en.wikipedia.org/wiki/Quaternion). Quaternions are
> especially useful, if you want to track movements. A quarternion can be
> used to repesent orientation and rotations:
>
> http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation
>
These look like an interesting tool... I will have to study it more,
but thanks for the tip!
Scott Seidman
4b4c1e...@r15g2000prd.googlegroups.com:
Start with asking what you are trying to measure. If you don't need the
DC, then high pass filtering is your easiest solution.
Since gravity is just like any acceleration, once you start thinking
about your problem, you'll see there are some ill-posed aspects. If you
can find a situation where you can be assured that the platform has no
acceleration other than gravity, you should be able to correct, but if
you're talking about a ship, it will be rolling and heaving, so the
problem is difficult. Consider moving up to a 6-degree of freedom
system, that has three accelerometers and three gyros, if you can't just
high-pass filter to remove the low frequency.
--
Scott
Reverse name to reply
jdhar
> You have six degrees of freedom that you need to be concerned with:
> translation along each unit vector and also rotation around each.
> Inertial measuring units typically do this with the second derivative of
> translation and the first of rotation, i.e., accelerometers and rate
> gyros. For an unconstrained system, you have to have all six.
>
Got it. And for my own understanding, a "rate gyro" is simply
something that measures the rate of change on an angular basis,
correct?
> In a constrained system (e.g., it's not moving), you can infer
> orientation by measuring the three-axis acceleration, modulo a correct
> estimate for the local gravity vector and the bias and scale factors of
> your instruments. Well that and earth rate, non-aligned gravity and
> earth's rotational frames of reference, the shape of the geoid, etc.
>
Right, so this is what I could do when the system is at rest... I
don't think I need to worry about all of those other factors since
this doesn't have to be that precise.
> Search on "strapdown inertial navigation" ...
>
Did a quick search... I'm assuming you are referring to the concept as
opposed to the Book title. Basically, that is what I'm trying to build
(something fixed to the frame of the vessel)... I didn't think I would
need a gyro for this application however, and I'm still not quite
clear why I do. There is no way just knowing the acceleration vectors
to compensate for an initial tilt?
To maybe clarify my application, I don't need this INS (if you will)
to calculate where I am going exactly. What I need is to measure and
datalog the forces that are being applied in all 3 axis... that's it.
I just need to remove the cross-coupling from one axis into the other
due to mounting tilt. So if the vessel moves truly forward, it should
register acceleration on X only, not X and Z (for eg.). Other than
that, that's all I need.. I don't need to use that information to
calculate where I am in reference to a start point.
jdhar
> Start with asking what you are trying to measure. If you don't need the
> DC, then high pass filtering is your easiest solution.
>
acceleration over time. I'm not sure if highpass will do exactly what
I need however. If I simply just highpass filter all 3 axes, it won't
help the fact that moving in one TRUE axis (say movement in true X)
will couple into 2 axes on the accelerometer due to mounting tilt,
right?
> Since gravity is just like any acceleration, once you start thinking
> about your problem, you'll see there are some ill-posed aspects. If you
> can find a situation where you can be assured that the platform has no
> acceleration other than gravity, you should be able to correct, but if
> you're talking about a ship, it will be rolling and heaving, so the
> problem is difficult. Consider moving up to a 6-degree of freedom
> system, that has three accelerometers and three gyros, if you can't just
> high-pass filter to remove the low frequency.
>
It seems like 6-degree is where it's going, but I need to fully
understand why first. The vessel is a boat, but this is for a sports-
performance based application, so it's not a big ship that is in waves
or anything. So in short, I could find a situation where there is
"virtually" no acceleration other than gravity. The problem is I can't
guarantee the situation where the sensor will be mounted such that
gravity is only applied on the Z-axis.
Frank Buss
> So I get I can calculate the angle at calibration time... however,
> subtracting this from the angle I measure won't achieve what I need (I
> don't think at least). Once in motion, all I have are 3 forces in the
> X,Y,Z directions... I need a way to translate that initial angle to
> modify those 3 vectors, right?
If the sensor is moving in one direction, parallel to ground, you'll
measure the same like when it is not moving. For simplifying, now one axis
is in the direction of movement and one vertical. If it accelerates, it
should be possible to calculate the accleration, if you first calculate
atan2 of the vertical and the axis in the movement direction, then
substract the calibration angle and then calculate the movement strength
with sin or cos of the resulting angle, but I didn't proved it
mathematically and physically, maybe I'm wrong.
For 3 axis the same should be possible with quaternions when using
calibration quaternions. With this concept it should be possible to
calibrate roll, pitch and yaw, if you do two calibration measurements: one
not moving and one accelerating in a known direction.
Maybe some search with Google will get some papers, because I don't think
you are the first person with such a problem.
Rich Webb
wrote:
>To maybe clarify my application, I don't need this INS (if you will)
>to calculate where I am going exactly. What I need is to measure and
>datalog the forces that are being applied in all 3 axis... that's it.
>I just need to remove the cross-coupling from one axis into the other
>due to mounting tilt.
Okay, think I understand what you're aiming for. Conceptually, mount the
sensor block (the three accelerometers) in the center of a cube, find
the apparent acceleration for each sensor at each of the six
orientations, and work backwards from the local gravity vector to find
the misalignments that would be necessary to yield the observed results.
Could be done with three orthogonal faces but flipping it upside down
helps to identify other error sources.
jdhar
what needs to be done conceptually, in my head, the problem is with
how to actually do the math. I think I may have figured it out though,
and please correct me if I'm wrong.
If we stick with the 2-D case of having only X and Y, if I orient the
sensor incorrectly such that it's rotated by 10 degrees (since there
is no Z-axis, we'll assume it's perfectly flat), then what I should do
with any (X,Y) vector that I read out is effectively rotate the vector
back by 10 degrees. And I think I can use a rotation matrix (http://
mathworld.wolfram.com/RotationMatrix.html). It seems to scale to the 3-
D case too, but I haven't tried that yet. The Quaternions also seem to
do the same thing in the 3-D case, with just a more compact
representation and less calculations (which is a good thing!).
So in the 2-D case, I obviously can't use local gravity to figure out
the tilt angle since if it's perfectly flat, there will be no gravity
component in the X or the Y. But in the 3-D case, the magnitude of
(X,Y,Z) should yield close to 1g, and using these (and atan2), I
should be able to figure out the 3 rotation angles (I hope), and apply
the rotation matrix above.
Nothing like a trip back to fundamental-land...
Ken S. Tucker
> I think I understand what you are trying to say here.. I understand
> what needs to be done conceptually, in my head, the problem is with
> how to actually do the math. I think I may have figured it out though,
> and please correct me if I'm wrong.
>
> If we stick with the 2-D case of having only X and Y, if I orient the
> sensor incorrectly such that it's rotated by 10 degrees (since there
> is no Z-axis, we'll assume it's perfectly flat), then what I should do
> with any (X,Y) vector that I read out is effectively rotate the vector
> back by 10 degrees. And I think I can use a rotation matrix (http://
> mathworld.wolfram.com/RotationMatrix.html). It seems to scale to the 3-
> D case too, but I haven't tried that yet. The Quaternions also seem to
> do the same thing in the 3-D case, with just a more compact
> representation and less calculations (which is a good thing!).
>
> So in the 2-D case, I obviously can't use local gravity to figure out
> the tilt angle since if it's perfectly flat, there will be no gravity
> component in the X or the Y. But in the 3-D case, the magnitude of
> (X,Y,Z) should yield close to 1g, and using these (and atan2), I
> should be able to figure out the 3 rotation angles (I hope), and apply
> the rotation matrix above.
>
> Nothing like a trip back to fundamental-land...
You'll need to write a sim. The product/instrument
you are ambiguously specifying needs hardening up.
I write aerodynamic and astrodynamic sims so I
might be able to serve as a consultant.
Off hand, you'll need help with the initial specs,
physically, and the desired output, defining clearly
what your client wants, then see how to do the task,
electronically, based on the sim.
If your inexperienced with product developement
then I can do project/program management, it's
vital to divide the program into maesureable steps.
Best
Ken S. Tucker
Frank Buss
> If we stick with the 2-D case of having only X and Y, if I orient the
> sensor incorrectly such that it's rotated by 10 degrees (since there
> is no Z-axis, we'll assume it's perfectly flat), then what I should do
> with any (X,Y) vector that I read out is effectively rotate the vector
> back by 10 degrees.
Some math for the 2D case. First a sketch:
http://img107.imageshack.us/my.php?image=rotatebz1.png
Assume you have the angle "a" misalignment. Then the vector c is the
calibration vector (normalize this to length 1 and normalize all other
measurements with the same factor). You can calculate a=atan2(c_x, c_y). If
a force in the direction of the x-axis is applied, e.g. the vector v,
you'll measure m=c+v_rotated. v_rotated is v rotated by "a" and
m=(c_x+v_x*cos(a)-v_y*sin(a), c_y+v_x*sin(a)+v_y*cos(a)). You can solve
this for v_x and v_y:
v_x = (m_x-c_x)*cos(a)+(m_y-c_y)*sin(a)
v_y = (m_y-c_y)*cos(a)+(c_x-m_x)*sin(a)
This should work for arbitrary vectors v, not just parallel to the x-axis.
I hope there is no bug in my math, but looks like I have showed that you
have to substract the calibration vector first, and then rotate the result
back.
Doing the math for the 3D case with quaternions is left as an exercise to
the reader :-)
Jon Slaughter
"jdhar" <jai....@gmail.com> wrote in message
news:e5d24354-7c95-49a4...@r15g2000prd.googlegroups.com...
Why can't you just remove the offset as some calibration step? Once you do
this it shouldn't effec the accelleration at all... after all it is
independent of position.
Basically you have two coordinate systems. Think of two axes, one for the
sensor and one for the vessel. They should be fixed.
So any change in position or acceleration of one will have the same effect
on the other.
Therefor you only need to rotate one to the other. Assuming the axis is
orthogonal then there shouldn't be any problem as long as you get your
rotations right.
Basically rotate y axis to y, z to z, then x to x, or vice versa but don't
mix x to y and so forth.
Look up on the web for 3D rotating and probably euler angles, etc...
jdhar
being able to think this through :)
>
> Some math for the 2D case. First a sketch:
>
> http://img107.imageshack.us/my.php?image=rotatebz1.png
>
> Assume you have the angle "a" misalignment. Then the vector c is the
> calibration vector (normalize this to length 1 and normalize all other
> measurements with the same factor). You can calculate a=atan2(c_x, c_y). If
> a force in the direction of the x-axis is applied, e.g. the vector v,
> you'll measure m=c+v_rotated. v_rotated is v rotated by "a" and
> m=(c_x+v_x*cos(a)-v_y*sin(a), c_y+v_x*sin(a)+v_y*cos(a)). You can solve
> this for v_x and v_y:
> v_x = (m_x-c_x)*cos(a)+(m_y-c_y)*sin(a)
> v_y = (m_y-c_y)*cos(a)+(c_x-m_x)*sin(a)
What I was thinking is this... I take my readings, (X1, Y1), which are
uncorrected and are rotated by a certain angle. Can't I just multiply
it by the 2-D rotation matrix to get new values? IE:
[X2, Y2] = [cos -sin ; sin cos][X1 Y1] (where the sin/cos angles are
the rotation angle)
I tried this out in Matlab, and it seems to work. It looks almost
similar to your equations, it's just you subtract the calibration
components (c_x and c_y). Is just multiplying it by the rotation
matrix incorrect?? The rotation matrix is in essence defined by the
calibration since I need to figure out the angle from the X and Y
components.
...or they might both be equal to eachother :)
jdhar
> Why can't you just remove the offset as some calibration step? Once you do
> this it shouldn't effec the accelleration at all... after all it is
> independent of position.
>
It's not as simple as reading the (X,Y) values at steady-state, and
then subtracting them to obtain a zero-offset calibrated value. I
still have to deal with the fact that the sensor is rotated, and a
motion in one direction will affect the other (due to rotation).
> Basically you have two coordinate systems. Think of two axes, one for the
> sensor and one for the vessel. They should be fixed.
>
Correct.
> So any change in position or acceleration of one will have the same effect
> on the other.
>
Correct.
> Therefor you only need to rotate one to the other. Assuming the axis is
> orthogonal then there shouldn't be any problem as long as you get your
> rotations right.
>
> Basically rotate y axis to y, z to z, then x to x, or vice versa but don't
> mix x to y and so forth.
>
I personally don't think this would work.. again, think about it this
way... lets say the sensor is mountd perfectly. Then a movemente in
direction X will yield a non-zero X reading (call it X1), and Y will
yield zero. However, if the sensor is rotated even the slightest
amount, a movement in THAT SAME X-direction will now yield non-zero X
AND Y (call them X2 and Y2). Now I need some way to transform (X2,Y2)
to match (X1,Y1). The X2 component needs the Y2 component to determine
the proper translation to X1... so I can't just "rotate y axis to y
and x to x"... unless I am misunderstanding you. In short, I need to
treat the pair as a vector, and not individual axes.
Moreover, this isn't something I can calibrate it; it has to be
applied to each sample that I read.
Jon Slaughter
You must calibrate it out in some way. You must somehow measure the axis
then use that.
You don't realize that rotating the axis will fix it up properly.
Take 2D for example.
The transformation equations are
r = x*cos(t) - y*sin(t)
s = x*sin(t) + y*cos(t)
suppose they are depenent on time(t is angle of rotation between axis)
then
r' = x'*cos(t) - y'*sin(t)
s' = x'*sin(t) + y'*cos(t)
r'' = x''*cos(t) - y''*sin(t)
s'' = x''*sin(t) + y''*cos(t)
So your derivatives transform exactly the same way.
e.g., normally in vector notation it is
Y = R*X
Y' = R*X'
Y'' = R*X''
This means that if you have the inverse matrix R, call it S
then
S*Y = X
S*Y' = X'
S*Y'' = X''
e.g., you can "unrotate" to get back the original system.
It works and I think your making it more complicated than it is.
The only real issue is that in 3D it's a bit harder since you have 3 angles
of rotation that you have to deal with.
In fact, in 3D graphics they almost always use a 4D rotation matrix because
it's much easier to do. The problem is that to get an arbitrary rotation in
3D you have to rotate 3 orthogonal directions. This causes problems because
the order maters. (R = A*B*C != B*C*A)
Another option is quaternions which also handle the rotations in a
relatively simple way.
BUT!!! You have to somehow figure out how "off it is.
This shouldn't be too hard though. Measure the vehicle's position when it is
in the perfered axis along one axis only!! (that is important)
To get one of the angles: (example in 2D)
1. Measure the acceleration along the x axis of the vessel. You will get an
r and s value for the acceleration of the accelerometers.
2. Use the equations given above to solve for the angle
r'' = x''*cos(t) - y''*sin(t)
s'' = x''*sin(t) + y''*cos(t)
y'' = 0 since we only moved the vessel in the x direction.
so
r'' = x''*cos(t)
s'' = x''*sin(t)
or
tan(t) = s''/r''
So you have the angle t when then allows you to "undo" the rotation by the
accelerometer.(just rotate the opposite way)
Its very simple to do for 2D because there is only one angle of rotation. In
3D there are 3 so you have to solve a system of linear equations. It's no
big deal though but just make sure that the get the order of rotations
correct.
(normally one rotates about different axis. Y = A*B*C*X. So X = c*b*a*Y.)
Unless I'm totally misunderstanding your problem. Simple question: Suppose
you could orient your accelerometer perfectly and in any way you want, could
you then eliminate the problem?
jdhar
> you could orient your accelerometer perfectly and in any way you want, could
> you then eliminate the problem?
I need to read your post 10 times before I comment on it... but I'll
answer this quickly. If I could orient the accelerometer such that it
is perfectly flat (ie: perpendicular to gravity), meaning X and Y read
0 and Z reads 1 at steady-state... AND... if I could orient it such
that movement of the vessel in a perfectly straight line only results
in an acceleration on the X-axis, then yes, the problem that I am
describing would not be there.
I actually thought of another issue that I don't think I can solve
easily. I don't know if there is a way I can figure out the YAW angle.
IE: If the sensor is perfectly flat such that X=Y=0 and Z=1, the
sensor can still be rotated around the Z-axis (YAW) and there would be
no way of me knowing, correct? In that case, I wouldn't know the angle
to de-rotate the readings by....
So all of this discussion would not apply to a Yaw offset I think....
Frank Buss
> What I was thinking is this... I take my readings, (X1, Y1), which are
> uncorrected and are rotated by a certain angle. Can't I just multiply
> it by the 2-D rotation matrix to get new values?
No, I don't think this works. Your readings are the sum of the acceleration
in one direction and the earth gravitation, which gives a vector, which is
not in the direction of the accleration. But when subtracting the earth
gravitation, you can rotate it. If you rotate it before, I think you'll get
the wrong result.
As Ken wrote: A good idea would be to write a simulation program. You could
try it in Second Life, which has already a physical engine and a simple
scripting language, or you could use PyOpenGL or similiar systems for
prototyping. I don't like Python, but you can try a Google search with your
favorite language, in combination with OpenGL, and chances are good that
you'll get a result, e.g. http://www.jigglescript.com/ for JavaScript.
Frank Buss
> I actually thought of another issue that I don't think I can solve
> easily. I don't know if there is a way I can figure out the YAW angle.
> IE: If the sensor is perfectly flat such that X=Y=0 and Z=1, the
> sensor can still be rotated around the Z-axis (YAW) and there would be
> no way of me knowing, correct? In that case, I wouldn't know the angle
> to de-rotate the readings by....
The sensor needs not to be mounted perfectly flat. You can't detect
rotating about the z-axis, regardless of the orientation of the sensor.
This is the reason why I'm currently evaluating this sensor, in addition
with a 3-axis accelerometer:
http://www.global.yamaha.com/news/2006/20060726.html
This is much cheaper than currently available 3-axis gyros and has the
additional advantage to give absolute orientation measurements (if the
earth magnetic field can be measured and is not distorted too much by
external magnets) and you can move it as slowly as you want (some gyros
have lower limits on how slow you can rotate it for good detection).
Jon Slaughter
> Unless I'm totally misunderstanding your problem. Simple question: Suppose
> you could orient your accelerometer perfectly and in any way you want,
> could
> you then eliminate the problem?
I need to read your post 10 times before I comment on it... but I'll
answer this quickly. If I could orient the accelerometer such that it
is perfectly flat (ie: perpendicular to gravity), meaning X and Y read
0 and Z reads 1 at steady-state... AND... if I could orient it such
that movement of the vessel in a perfectly straight line only results
in an acceleration on the X-axis, then yes, the problem that I am
describing would not be there.
----
The its a "simple" calibration issue. i.e., you just have to "fixup" your
data from the accelerometer before using them in computation. This involves
multiplying them by Rotation matrices that undo the "errors". (think of it
as undoing the rotation that you physically added by not mounting the
accelerometer properly)
===
I actually thought of another issue that I don't think I can solve
easily. I don't know if there is a way I can figure out the YAW angle.
IE: If the sensor is perfectly flat such that X=Y=0 and Z=1, the
sensor can still be rotated around the Z-axis (YAW) and there would be
no way of me knowing, correct? In that case, I wouldn't know the angle
to de-rotate the readings by....
So all of this discussion would not apply to a Yaw offset I think....
----
I don't see any problems that you'll have except numerical ones(which can be
serious). You shouldn't have any problem computing Yaw, Roll, and Pitch.
They will need to be calibrated also. (if your plane starts off tilted, for
example, and you assume it is not then all your calculations will be off).
Essentially:
1. Yaw is angle between vector heading and vessel front.
2. Pitch is angle between vessel front and "ground" vector.
3. Roll is angle between special vector and "ground" vector
If you set up your accelerometer so that the x axis points from back to
front, y axis points from wing to win, and z axis is perpendicular to both
of those then then angles each axis makes with the "special" vectors will
give you your yaw roll and pitch.
The ground vectors would be found at calibration time. i.e., they are the
vectors from the axis in the state of equillibrium. i.e., the x axis, y
axis, and z axis point in the proper direction when the plane is sitting on
the ground not doing anything. (of course this can be problematic and better
to use a device to get those "special" vectors)
The main point being is that they are easily computed by knowing a few
things. Depending on what you really are trying to do it might not be a good
solution(can be inaccurate over long distances since the earth is curved,
for example.. but there are easy ways to fix it).
David L. Jones
I've done something like this with an ocean bottom tilt sensor.
Two accelerometers were used, one on the main PCB and another on a
small PCB mounted at right angles. The boards were then potted into a
sensor head so they couldn't move. We built a special "tilt
calibration" jig that had fluid spirit levels on it, the idea being
that you put the sensor head on the jig which could be locked into
place at the different axes. Once in place you would read the DC
offset value from the accelerometer on the desired axis and then
program an EEPOT (programmable EEPROM variable resistor) that nulled
out that DC offset directly on the front end circuit from the
accelerometer. Do that on all three axis and your sensor head is now
"calibrated" relative to a known level plane.
You wouldn't need to null it out in circuitry either, just need to
record the cal values so you can subtract it later in software.
Very simple and very effective.
I can't find the original schematics though, sorry.
Perhaps it's in a Patent we did for this device, I'll try and look it
up...
Regards
Dave.
Jon Slaughter
"Jon Slaughter" <Jon_Sl...@Hotmail.com> wrote in message
news:S8urk.17425$LG4....@nlpi065.nbdc.sbc.com...
Those vectors would probably be equal to the axis of the vessel so you
wouldn't have to find them. (but it would require that the vessel would be
the proper state at start up(i.e., your initial conditions))
Spehro Pefhany
Setting this state is called "leveling" (wrt gravity) and "alignment".
There is a great deal of information out there on these matters... try
googling on Quaternion and "Gravity Model".
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Scott Seidman
news:dleta4tsjv9gkhfll...@4ax.com:
> try
> googling on Quaternion and "Gravity Model".
"Quaternions came from Hamilton after his really good work had been done;
and, though beautifully ingenious, have been an unmixed evil to those who
have touched them in any way, including Clerk Maxwell." — Lord Kelvin,
1892.
I've had this hanging on my office wall since 1995.
Spehro Pefhany
Ken S. Tucker
wrote:
> On 22 Aug 2008 13:37:56 GMT, Scott Seidman
>
> >Spehro Pefhany <speffS...@interlogDOTyou.knowwhat> wrote in
> >news:dleta4tsjv9gkhfll...@4ax.com:
>
> >> try
> >> googling on Quaternion and "Gravity Model".
>
> >"Quaternions came from Hamilton after his really good work had been done;
> >and, though beautifully ingenious, have been an unmixed evil to those who
> >have touched them in any way, including Clerk Maxwell." — Lord Kelvin,
> >1892.
>
> >I've had this hanging on my office wall since 1995.
>
> Cute.. thanks.
> Best regards,
> Spehro Pefhany
Well I think good old fashioned trig is sufficient.
Perhaps an off-the-shelf aeronautical instrument
might work, but not as much fun ;-).
If the measurement is merely the planning angle
of a boat, ok, but then the sensor needs to be
*cushioned* from wave action, I'm a boater
myself. The spec's are too soft for me, so far, to
commit neurons.
Ken
jdhar
> in one direction and the earth gravitation, which gives a vector, which is
> not in the direction of the accleration. But when subtracting the earth
> gravitation, you can rotate it. If you rotate it before, I think you'll get
> the wrong result.
>
oh boy, where do I start... so many posts... ok, so if I had a 2-D
sensor and it was mounted perfectly flat, there would be no gravity
vector on the X and Y, correct? I was speaking in the perfectly 2-D
case where the sensor is flat. Then I should be able to de-rotate the
values as they come in.. but if gravity were involved, then
subtracting it first would make sense, I agree.
> As Ken wrote: A good idea would be to write a simulation program. You could
>
> try it in Second Life, which has already a physical engine and a simple
> scripting language, or you could use PyOpenGL or similiar systems for
> prototyping. I don't like Python, but you can try a Google search with your
> favorite language, in combination with OpenGL, and chances are good that
> you'll get a result, e.g.http://www.jigglescript.com/for JavaScript.
>
I'll look into this.. I would really be able to try all of this theory
out and see what happens before trying it physically.
jdhar
> The sensor needs not to be mounted perfectly flat. You can't detect
> rotating about the z-axis, regardless of the orientation of the sensor.
> This is the reason why I'm currently evaluating this sensor, in addition
> with a 3-axis accelerometer:
>
can compensate for by using the gravity vector to determine
rotation...
> http://www.global.yamaha.com/news/2006/20060726.html
>
> This is much cheaper than currently available 3-axis gyros and has the
> additional advantage to give absolute orientation measurements (if the
> earth magnetic field can be measured and is not distorted too much by
> external magnets) and you can move it as slowly as you want (some gyros
> have lower limits on how slow you can rotate it for good detection).
>
That looks like an interesting part. I also have GPS available, so I
was wondering if maybe I could use that to calibrate out rotation on
the Z-axis somehow..
jdhar
> The its a "simple" calibration issue. i.e., you just have to "fixup" your
> data from the accelerometer before using them in computation. This involves
> multiplying them by Rotation matrices that undo the "errors". (think of it
> as undoing the rotation that you physically added by not mounting the
> accelerometer properly)
>
Thanks Jon. I think this is just a miscommunication issue here...
that's exactly what I was talking about doing. Post-processing the raw
samples to undo these errors. By you saying "calibrate this out", I
thought you were referring to actually scaling the values out of the
accelerometer in hardware first so the samples come out corrected.
> I don't see any problems that you'll have except numerical ones(which can be
> serious). You shouldn't have any problem computing Yaw, Roll, and Pitch.
> They will need to be calibrated also. (if your plane starts off tilted, for
> example, and you assume it is not then all your calculations will be off).
>
Numerical problems are not of concern at this point as long as I know
the math... I have infinite processing power with no speed
constraints. I still don't see how to compute Yaw with a 3-axis
accelerometer when in steady-state.
> Essentially:
>
> 1. Yaw is angle between vector heading and vessel front.
> 2. Pitch is angle between vessel front and "ground" vector.
> 3. Roll is angle between special vector and "ground" vector
>
> If you set up your accelerometer so that the x axis points from back to
> front, y axis points from wing to win, and z axis is perpendicular to both
> of those then then angles each axis makes with the "special" vectors will
> give you your yaw roll and pitch.
>
Firstly, to clarify, this is part of the problem. The setup of the
accelerometer may not have the X-axis point perfectly back to front, Y-
axis point perfectly wing to wing and Z following gravity.
I'm not sure what the "special" vector is at this point...
> The ground vectors would be found at calibration time. i.e., they are the
> vectors from the axis in the state of equillibrium. i.e., the x axis, y
> axis, and z axis point in the proper direction when the plane is sitting on
> the ground not doing anything. (of course this can be problematic and better
> to use a device to get those "special" vectors)
>
> The main point being is that they are easily computed by knowing a few
> things. Depending on what you really are trying to do it might not be a good
> solution(can be inaccurate over long distances since the earth is curved,
> for example.. but there are easy ways to fix it).
So I'm failing to see how to calculate Yaw... Frank agreed that it's
impossible to measure rotation about the Z-axis.
My problem can essentially be broken into 2 parts:
1) Finding out how the sensor is rotated, on all 3-axis. It looks like
I can use the gravity vector to calculate X and Y rotation, but not Z.
2) how to apply the math to correct for those rotations.
I have started playing with Quaternions in Matlab, and they are
working out so far... #1 is posing the problem for me right now.
jdhar
On Aug 22, 6:21 am, Spehro Pefhany <speffS...@interlogDOTyou.knowwhat>
wrote:
> On Fri, 22 Aug 2008 05:56:27 -0500, "Jon Slaughter"
>
>
>
> <Jon_Slaugh...@Hotmail.com> wrote:
>
> >"Jon Slaughter" <Jon_Slaugh...@Hotmail.com> wrote in message
> >news:S8urk.17425$LG4....@nlpi065.nbdc.sbc.com...
>
> >> "jdhar" <jai.d...@gmail.com> wrote in message
jdhar
> Well I think good old fashioned trig is sufficient.
> Perhaps an off-the-shelf aeronautical instrument
> might work, but not as much fun ;-).
> If the measurement is merely the planning angle
> of a boat, ok, but then the sensor needs to be
> *cushioned* from wave action, I'm a boater
> myself. The spec's are too soft for me, so far, to
> commit neurons.
> Ken
Hi Ken. Off-the-sheld aeronautical instrument is no fun, as you
mentioned :) I want to understand all of this from the ground up.
I think I mentioned this in a previous post... waves and what not are
not an issue. The application is this: I want to be able to take this
sensor module that I am building, go on any canoe (this is a sports-
related application), suction cup it to a seat, and measure the
acceleration on all 3-axis. The problem is if I have the sensor
rotated in any way due to mounting errors (ie: my suction cupping is
no good), the vectors I read out on the accelerometer will involve
rotation components.
Scott Seidman
d469b4...@k30g2000hse.googlegroups.com:
Do a vector addition of your three axes. If the sum resolves to 1g, then
you know that any deviations you see on any axes must be due to a tilt of
your sensor. If they don't add to unity, the difference between 1g down
and your summed vector is the acceleration.
jdhar
> Do a vector addition of your three axes. If the sum resolves to 1g, then
> you know that any deviations you see on any axes must be due to a tilt of
> your sensor. If they don't add to unity, the difference between 1g down
> and your summed vector is the acceleration.
>
A perfectly flat sensor that is slightly rotated about the Z-axis (so
X and Y are out of line) will still yield a vector sum of 1g. This is
a case I need to account for and handle somehow.
Scott Seidman
5a827c...@m45g2000hsb.googlegroups.com:
> A perfectly flat sensor that is slightly rotated about the Z-axis (so
> X and Y are out of line) will still yield a vector sum of 1g.
>
This is true only if the sensor is not accelerating in space. This goes to
Einstein's Principle of Equivalence.
Ken S. Tucker
> > Well I think good old fashioned trig is sufficient.
> > Perhaps an off-the-shelf aeronautical instrument
> > might work, but not as much fun ;-).
> > If the measurement is merely the planning angle
> > of a boat, ok, but then the sensor needs to be
> > *cushioned* from wave action, I'm a boater
> > myself. The spec's are too soft for me, so far, to
> > commit neurons.
> > Ken
>
> Hi Ken. Off-the-sheld aeronautical instrument is no fun, as you
> mentioned :) I want to understand all of this from the ground up.
OK, I'm in for another neuron or two :-).
> I think I mentioned this in a previous post... waves and what not are
> not an issue. The application is this: I want to be able to take this
> sensor module that I am building, go on any canoe (this is a sports-
> related application), suction cup it to a seat, and measure the
> acceleration on all 3-axis.
Ok, there are 2 Coordinate Systems, a CS fixed to the
canoe, such as x from end to end (stern o bow), y (from
port to starboard) and z that is 90 degrees to x and y and
that CS is fixed to the boat.
Let's call that CS "k" and it belongs to the boat.
Next we have a Global CS, X,Y,Z, we'll denote "K",
that is simply aligned by longitude, latitude and altitude.
Now, if I understand correctly, the 3 axis accelerations
(using accelometers) will be measured in the "k" CS and
provide ax,ay,az?
Please confirm.
> The problem is if I have the sensor
> rotated in any way due to mounting errors (ie: my suction cupping is
> no good), the vectors I read out on the accelerometer will involve
> rotation components.
Yes that's correct, the vehicle rotates about a Center
of Gravity, so if the accelometers are set off from the
CoG an additional acceleration component will be
induced by the vehicles rotation. We're getting close
to Inertial Guidance system theory, if you want the
x,y,z relative to X,Y,Z, such as Pitch Yaw Roll, see,
http://en.wikipedia.org/wiki/Ring_laser_gyroscope
That get's complicated so we better all agree on term-
inology.
Regards
Ken
jdhar
> Ok, there are 2 Coordinate Systems, a CS fixed to the
> canoe, such as x from end to end (stern o bow), y (from
> port to starboard) and z that is 90 degrees to x and y and
> that CS is fixed to the boat.
> Let's call that CS "k" and it belongs to the boat.
>
Agreed
> Next we have a Global CS, X,Y,Z, we'll denote "K",
> that is simply aligned by longitude, latitude and altitude.
>
Sure
> Now, if I understand correctly, the 3 axis accelerations
> (using accelometers) will be measured in the "k" CS and
> provide ax,ay,az?
> Please confirm.
Not necessarily. First, we need to consider the CS of the
accelerometer itself - lets call k'.
If CS k' is mounted perfectly on the boat, CS k' will match k. If not
however, the 3 accelerations, (ax,ay,az) will be given relative to the
k' CS, not k. So if (k == k'), (ax,ay,az) will be given in the k CS. I
need to compensate for the case that (k != k').
What I am looking for is to solve for (bx,by,bz), where (bx,by,bz)
would be the value of (ax,ay,az) IF (k == k'). Solving for (bx,by,bz)
can be accomplished using 3-D rotation (quaternions for eg.) I
believe... IF I know the 3-rotation angles. That's the 2nd part of the
problem - how to determine the 3-rotation angles.
>
> Yes that's correct, the vehicle rotates about a Center
> of Gravity, so if the accelometers are set off from the
> CoG an additional acceleration component will be
> induced by the vehicles rotation. We're getting close
> to Inertial Guidance system theory, if you want the
> x,y,z relative to X,Y,Z, such as Pitch Yaw Roll, see,http://en.wikipedia.org/wiki/Ring_laser_gyroscope
Jon Slaughter
using various methods. I was wrong since I didn't know you were just going
to attach it arbitrarily. The accelerometer has no idea what a canoe is and
what front or back it. In fact it's impossible to do by the sensor alone.
So you have to come up with some method to figure out what is "front".
I was talking about computing the Yaw of the boat after the fact.... not the
yaw of the sensor w.r.t to the boat. But the boat's yaw w.r.t to its
heading.
e.g., for a canoe you are floating downstream, maybe your nose gets pointed
towards the shore on the side... but your still moving down stream... then
the yaw is +- 90 degree's. That is because your velocity vector is still
pointing downstream but your sensor orientation has changed. (Say your
velocity vector went from being along the x axis of the sensor(which would
be the front) to the y axis(which is the side))
In any case you are right. Theres no way to know the "yaw" of the sensor
w.r.t to the front of the canoe. Try to figure out how you can figure out
this then you have a solution. I think it will be impossible with your
sensor alone because it needs some idea of what front is. I do believe that
chances are any ordinary person can position it properly for decent enough
results. (it's not like we are talking about a missle here).
In any case I imagine that you plan on having some type of visualization
software and you can have the user rotate it where the position data makes
most sense.
e.g., suppose the route shows the canoe ending on the other side of the
shore.. the user knows he was on the other side and can rotate it. Further
suppose that it shows the canoe rising up in the air. He can rotate that out
too. It's not perfect but would be the easiest solution. That way you can
just have them attach the accelerometer anywhere at any orientation and let
them figure out what it should have been later on. (which is much easier and
cheaper)
Now there are a few potential ways to solve that problem but they require
more sensors. (essentially you are trying to do what that person is doing...
one simple way might be to use GPS and get the initial and final points but
it's not very accurate... but would give you some ability to find the
rotation matrix)
jdhar
> Ok, I assumed that you could determine the axis at installation time by
> using various methods. I was wrong since I didn't know you were just going
> to attach it arbitrarily. The accelerometer has no idea what a canoe is and
> what front or back it. In fact it's impossible to do by the sensor alone.
>
Agreed, but I do have some constraints. The user will know that the
sensor is to be mounted with a certain side facing forward etc... if
the user completely messes up the orientation, that's not my problem
for now. So I am assuming that the X-axis will be pointing forward/
backward, Y-axis left-right and Z-axis up/down.. what IS my problem is
that I can't expect the user to orient the sensor module 100%
correctly, so that X is exactly where it should be.
>
> In any case you are right. Theres no way to know the "yaw" of the sensor
> w.r.t to the front of the canoe. Try to figure out how you can figure out
> this then you have a solution. I think it will be impossible with your
> sensor alone because it needs some idea of what front is. I do believe that
> chances are any ordinary person can position it properly for decent enough
> results. (it's not like we are talking about a missle here).
>
I think the results will be decent no doubt, and it's not so much the
actual 'g' values that I am concerned with... it's more relative.
Since this is for a sports application, having repeatable results is
really what is important... not absolute values. So if a rotation of 5
degrees causes some bleed into the primary axis (the X-axis since that
is what moves forward/backward), that would no doubt affect any
relative comparisons.
> In any case I imagine that you plan on having some type of visualization
> software and you can have the user rotate it where the position data makes
> most sense.
>
Again, since there is no way for me to calculate Yaw on the sensor
w.r.t. boat, I can't even have an LCD or something that constantly
reads out an angle that the user tries to minimize. There are some
solutions that may work if the boat is moving, but I want all of the
setup to be when it is stationary.
>
> Now there are a few potential ways to solve that problem but they require
> more sensors. (essentially you are trying to do what that person is doing...
> one simple way might be to use GPS and get the initial and final points but
> it's not very accurate... but would give you some ability to find the
> rotation matrix)
The GPS idea is something I have considered, and maybe you can tlel me
if this would work in practice. I could try to have the unit "self-
cal" when in motion to figure out Yaw. With GPS, I can get my compass
heading easily. If I repeatedly sample the same compass heading for a
few samples, that means the boat is moving in a straight line. If this
is the case, then there should be very little Y-component on the
accelerometer. So theoretically, I would just have to keep adjusting
the rotation matrix to minimize the Y component, as long as the boat
is heading straight. AT that point, I could lock in the value and be
good for the rest of the usage period... ideally.
Jon Slaughter
>> In any case I imagine that you plan on having some type of visualization
>> software and you can have the user rotate it where the position data
>> makes
>> most sense.
>>
>
> Again, since there is no way for me to calculate Yaw on the sensor
> w.r.t. boat, I can't even have an LCD or something that constantly
> reads out an angle that the user tries to minimize. There are some
> solutions that may work if the boat is moving, but I want all of the
> setup to be when it is stationary.
>
Well, I'm not sure exactly what your trying to do. If it is meant as some
type of navigation then it's not the best method... or at least not by
itself.
>>
>> Now there are a few potential ways to solve that problem but they require
>> more sensors. (essentially you are trying to do what that person is
>> doing...
>> one simple way might be to use GPS and get the initial and final points
>> but
>> it's not very accurate... but would give you some ability to find the
>> rotation matrix)
>
> The GPS idea is something I have considered, and maybe you can tlel me
> if this would work in practice. I could try to have the unit "self-
> cal" when in motion to figure out Yaw. With GPS, I can get my compass
> heading easily. If I repeatedly sample the same compass heading for a
> few samples, that means the boat is moving in a straight line. If this
> is the case, then there should be very little Y-component on the
> accelerometer. So theoretically, I would just have to keep adjusting
> the rotation matrix to minimize the Y component, as long as the boat
> is heading straight. AT that point, I could lock in the value and be
> good for the rest of the usage period... ideally.
Yes, basically... but you don't have to do it very often. In fact, all you
are trying to do is "zero" in on the rotation matrix and gps can help you do
that. What you do is use your acceleration vector to find the position and
then use gps and compare it with it. By doing this over time you can get a
clearer idea of what is going on. (basically remove the "noise" by averaging
and then the "error" will be the rotation matrix)
I really have no idea how long it will take to "zero in" the system though.
It could be few seconds to a few minutes and I'm sure depends significantly
on the GPS system.
Basically you have two things to help you find position, one is the GPS and
the other is the accelerometer. By comparing the two you should be able to
figure something out. They both have pro's and con's.
The system definitely will be more robust with GPS but you'll have to weigh
the extra cost and complications with it. There is also some very
complicated mathematics associated with such things to get optimal
performance... you'll probably want to learn about kalman filtering for
that. (although maybe you can use some premade package that does it for you)
jdhar
> Well, I'm not sure exactly what your trying to do. If it is meant as some
> type of navigation then it's not the best method... or at least not by
> itself.
>
Nah, not really as a nav. tool. All I'm cncerned with are the G forces
on (X,Y,z), that's it. The only catch is I want to compensate for
mounting tilt so that a reading in the X direction corresponds with
the boat's X-axis, and not the mounted X-axis (similarly for other
axes)
>
> Yes, basically... but you don't have to do it very often. In fact, all you
> are trying to do is "zero" in on the rotation matrix and gps can help you do
> that. What you do is use your acceleration vector to find the position and
> then use gps and compare it with it. By doing this over time you can get a
> clearer idea of what is going on. (basically remove the "noise" by averaging
> and then the "error" will be the rotation matrix)
>
Right, this would be a cal time thing, not something done all the
time. Once it's mounted, it shouldn't change orientation.
> I really have no idea how long it will take to "zero in" the system though.
> It could be few seconds to a few minutes and I'm sure depends significantly
> on the GPS system.
>
> Basically you have two things to help you find position, one is the GPS and
> the other is the accelerometer. By comparing the two you should be able to
> figure something out. They both have pro's and con's.
>
> The system definitely will be more robust with GPS but you'll have to weigh
> the extra cost and complications with it. There is also some very
> complicated mathematics associated with such things to get optimal
> performance... you'll probably want to learn about kalman filtering for
> that. (although maybe you can use some premade package that does it for you)
The system already has GPS in it, so it's there for better or worse.
IT is a GPS module that outputs NMEA strings though, so I *think* they
are already filtered. I can directly pick off heading/speed/lat/long
etc..
JosephKK
wrote:
>>
>> Start with asking what you are trying to measure. If you don't need the
>> DC, then high pass filtering is your easiest solution.
>>
>Thanks Scott... I don't need DC, I'm concerned only with the delta in
>acceleration over time. I'm not sure if highpass will do exactly what
>I need however. If I simply just highpass filter all 3 axes, it won't
>help the fact that moving in one TRUE axis (say movement in true X)
>will couple into 2 axes on the accelerometer due to mounting tilt,
>right?
I may be smelling a conceptual error here. Accelerometers do not
measure displacement or velocity. It sounds like you want a
navigational instrument based on accelerometers only. It might work
but a magnetic compass and dead reckoning works better. A handheld
coupled to the magnet compass and a velocity sword will produce much
better results. Then again if your issue is making sure just which
way is "up" the 3d accelerometer is a good choice.
>
>> Since gravity is just like any acceleration, once you start thinking
>> about your problem, you'll see there are some ill-posed aspects. If you
>> can find a situation where you can be assured that the platform has no
>> acceleration other than gravity, you should be able to correct, but if
>> you're talking about a ship, it will be rolling and heaving, so the
>> problem is difficult. Consider moving up to a 6-degree of freedom
>> system, that has three accelerometers and three gyros, if you can't just
>> high-pass filter to remove the low frequency.
>>
>
>It seems like 6-degree is where it's going, but I need to fully
>understand why first. The vessel is a boat, but this is for a sports-
>performance based application, so it's not a big ship that is in waves
>or anything. So in short, I could find a situation where there is
>"virtually" no acceleration other than gravity. The problem is I can't
>guarantee the situation where the sensor will be mounted such that
>gravity is only applied on the Z-axis.
linnix
> On Thu, 21 Aug 2008 09:51:02 -0700 (PDT), jdhar <jai.d...@gmail.com>
> wrote:
>
>
>
> >> Start with asking what you are trying to measure. If you don't need the
> >> DC, then high pass filtering is your easiest solution.
>
> >Thanks Scott... I don't need DC, I'm concerned only with the delta in
> >acceleration over time. I'm not sure if highpass will do exactly what
> >I need however. If I simply just highpass filter all 3 axes, it won't
> >help the fact that moving in one TRUE axis (say movement in true X)
> >will couple into 2 axes on the accelerometer due to mounting tilt,
> >right?
>
> I may be smelling a conceptual error here. Accelerometers do not
> measure displacement or velocity. It sounds like you want a
> navigational instrument based on accelerometers only. It might work
> but a magnetic compass and dead reckoning works better. A handheld
> coupled to the magnet compass and a velocity sword will produce much
> better results. Then again if your issue is making sure just which
> way is "up" the 3d accelerometer is a good choice.
Furthermore, I question whether the g forces (other than gravity)
would be significant in a boat. Commercial grade GPS is slow and
inaccurate (meter accuracy). In real apps (ICBM), accelerometers are
utilized to correct good (cm accuracy) but slow GPS.
jdhar
> I may be smelling a conceptual error here. Accelerometers do not
> measure displacement or velocity. It sounds like you want a
> navigational instrument based on accelerometers only. It might work
> but a magnetic compass and dead reckoning works better. A handheld
> coupled to the magnet compass and a velocity sword will produce much
> better results. Then again if your issue is making sure just which
> way is "up" the 3d accelerometer is a good choice.
>
I don't need a nav. instrument based on accelerometers... all I need
is to measure the forces in X,Y,Z and datalog them. I just need to
compensate for mounting rotation/tilt. I will definitley make sure
it's mounted in the correct orientation, I just can't assure that it
won't be rotated by 10 degrees or so.
>
jdhar
> Furthermore, I question whether the g forces (other than gravity)
> would be significant in a boat. Commercial grade GPS is slow and
> inaccurate (meter accuracy). In real apps (ICBM), accelerometers are
> utilized to correct good (cm accuracy) but slow GPS.
I have already captured data from a few runs in the boat, and the g
forces are significant enough. I able to get down to a stddev. of
0.01gs at steady state, and then peak at about 0.2 or 0.3. Like I
mentioned before, it's more the relative measurements and the shape of
the graph that matters... not so much the absolute value.
The GPS I am using also samples at 5Hz, so I think its slightly better
than std. 1Hz commercial grade. I would love to get my hands on a more
accurate one though (and faster!). The more samples, the merrier!
linnix
Higher sample rate does not improve accuracy. You need to phase
correct the GPS signal with decoded gold code. First, you need to
have the key.
jdhar
world example.
I took some readings at steady-state, and found a mean vector of:
g =
-0.1427 -0.0681 0.9862
So most of the normal force is in the Z-axis, but there is a somewhat
significant component in the X-axis as well due to the tilt. The norm
of this vector is very close to 1.
I have included a link to a plot of the samples (in-motion) of all 3-
axes - these are uncompensated values:
http://via.fps-tech.org/pub/raw_samples.jpg
As you can see, most of the activity is in the X-axis, as expected
since I was moving straight.
Now, I have read lots of quaternions and how to do rotations on them.
If I have a rotation axis (x,y,z), and an angle theta, I can form a
quaternion and rotate a point about this axis/angle by multiplying v =
rot*sample*conj(rot), where rot is the rotation quaternion. The
problem I have is I don't know how to form the rotation quaternion
based on my steady-state vector 'g'. I don't know how to figure out
the angle and axis to rotate by...
I came across a paper (http://csdl2.computer.org/comp/proceedings/iswc/
2003/2034/00/20340252.pdf) that describes a problem similar to mine.
Their method is to:
- Find the mean vector at steady-state, similar to what I have for 'g'
- Take a motion sample (s), and subtract the 'g' vector, forming d = s
- g
- Then they claim the "vertical component", 'v', of 'd' can be found
by using dot products: v = dot(dynamic,gravity)/
(norm(gravity)^2)*gravity
- They claim the horizontal component of 'd' can be found by just
taking the difference of d and v, so h = d - v
I don't quite understand how the "vertical component" is still a 3-D
vector... and same for horizontal. But I applied this to all of my
samples, and the resultant graphs for the "vertical component (v)" and
"horizontal component (h)" are here:
Vertical: http://via.fps-tech.org/pub/vertical_proj.jpg
Horizontal: http://via.fps-tech.org/pub/horizontal_proj.jpg
Do these make sense? The horizontal graph, when compared to the raw
samples, looks like what I was hoping for... mostly motion in the X-
axis, very little in Z and Y. I do'nt quite understand what I am
looking at for the Vertical graph however...
Any ideas??
linnix
> ok, I am having some issues with the math here, so I will try a real-
> world example.
>
> I took some readings at steady-state, and found a mean vector of:
>
> g =
>
> -0.1427 -0.0681 0.9862
>
> So most of the normal force is in the Z-axis, but there is a somewhat
> significant component in the X-axis as well due to the tilt. The norm
> of this vector is very close to 1.
Have you sampled it without motion? Did you get any X and Y
components in that case?
> I have included a link to a plot of the samples (in-motion) of all 3-
> axes - these are uncompensated values:
>
> http://via.fps-tech.org/pub/raw_samples.jpg
>
> As you can see, most of the activity is in the X-axis, as expected
> since I was moving straight.
Or the sensor is tilted.
>
> Now, I have read lots of quaternions and how to do rotations on them.
> If I have a rotation axis (x,y,z), and an angle theta, I can form a
> quaternion and rotate a point about this axis/angle by multiplying v =
> rot*sample*conj(rot), where rot is the rotation quaternion. The
> problem I have is I don't know how to form the rotation quaternion
> based on my steady-state vector 'g'. I don't know how to figure out
> the angle and axis to rotate by...
>
> I came across a paper (http://csdl2.computer.org/comp/proceedings/iswc/
> 2003/2034/00/20340252.pdf) that describes a problem similar to mine.
> Their method is to:
>
> - Find the mean vector at steady-state, similar to what I have for 'g'
> - Take a motion sample (s), and subtract the 'g' vector, forming d = s
> - g
> - Then they claim the "vertical component", 'v', of 'd' can be found
> by using dot products: v = dot(dynamic,gravity)/
> (norm(gravity)^2)*gravity
You have to do the inner product on each component.
> - They claim the horizontal component of 'd' can be found by just
> taking the difference of d and v, so h = d - v
>
> I don't quite understand how the "vertical component" is still a 3-D
> vector... and same for horizontal.
All the components together is a vector. The components are scaler.
Kiran
> Have you sampled it without motion? Did you get any X and Y
> components in that case?
>
gravity on the sensor while the boat was still in flatwater.
>
> Or the sensor is tilted.
>
No, I oriented it with the X axis pointing in the forward motion
direction, so this makes sense. The non-zero Y and Z components are
due to the tilt, which is what I am trying to get rid of.
>
>
> You have to do the inner product on each component.
>
Really? Why do you say this?
>
> All the components together is a vector. The components are scaler.
>
I get that the components form a vector... but I was stating what they
said in the article. That 'v' is the verticle component.... this is
what I don't understand.
jdhar
linnix
Let me try to rephase it:
Let
O be the ocean wave
W be the user work vector
X be the measured vector
Y be the average sensor orientation vector
Z be the projection of X onto Y
Z is obtained by inner product of X and Y in the direction of Y
This will provide a set of equations as functions of the components.
For their project, they are measuring work done by the user
(walking, running and jumping),
so, Z = W and X = Y + W
But in your case, you have an external force O (ocean wave) .
So, Z = W + O and X = Y + W
You can't really separate the work done by the user and by the ocean.
JosephKK
wrote:
>>
If the desired information is not navigational, what is it?
JosephKK
wrote:
>>
If you can afford two sensors, you can get that as well. Even though
gyros do the rotation sensing thing best.
JosephKK
wrote:
>Thanks Jon, glad we are on some common ground...
That can simplify things much. Simply place the vessel in a reference
cradle that is aligned with a bubble level. Read the sensor output.
It gets real easy after that. Dual sensors will get yaw for you as
well. And a manual tip of the cradle will really help the calibration
/ offset calculation.
jdhar
> Let me try to rephase it:
>
> Let
> O be the ocean wave
> W be the user work vector
> X be the measured vector
> Y be the average sensor orientation vector
> Z be the projection of X onto Y
>
> Z is obtained by inner product of X and Y in the direction of Y
> This will provide a set of equations as functions of the components.
>
I assume inner product = dot product. From what I can tell by
searching, it looks like they are..
> For their project, they are measuring work done by the user
> (walking, running and jumping),
> so, Z = W and X = Y + W
>
> But in your case, you have an external force O (ocean wave) .
> So, Z = W + O and X = Y + W
>
> You can't really separate the work done by the user and by the ocean.
That's ok, I think this is getting over-complicated. All I am looking
for is the forces experienced onto the accelerometer, after being
compensated for the average vector (gravity). This first and foremost
includes roll/pitch, and maybe Yaw if I can get some other method to
work. If there are external forces that will influence this OTHER than
gravity, so be it... so for this application, we don't care about
external force 'O'.
jdhar
> If the desired information is not navigational, what is it?
I think I mentioned this somehwere before... I just need the vectors
out of the accelerometer to be compensated for gravity and mounting
tilt. It's more to see what is going on relatively in the boat as
opposed to tracking where it's going..
Scott Seidman
news:o9s3b49jobneq4bgp...@4ax.com:
>
> That can simplify things much. Simply place the vessel in a reference
> cradle that is aligned with a bubble level.
How about PLACING the whole assembly in a float? I think if you can center
the CG in three dimensions, you're all set.
Rich Webb
wrote:
>>
What you're asking to do is not possible in an unconstrained case (and a
canoe/kayak in whitewater is pretty unconstrained) unless you include
gyros and fully track all six degrees of freedom.
On the other hand, if you would accept knowing the total instantaneous
acceleration ("g force") at any given time, then all you need to do [*]
is a one-time calculation of the misalignments, bias, and scale factors
and accept that the gravitational acceleration is just another component
acting on the vehicle.
[*] neglecting bias drift
--
Rich Webb Norfolk, VA
jdhar
> How about PLACING the whole assembly in a float? I think if you can center
> the CG in three dimensions, you're all set.
>
hah, ya, if I could do something like that, then it would open up a
lot more avenues to explore.. unfortunately, I am restricted to a
simple PCB in a box.
jdhar
> What you're asking to do is not possible in an unconstrained case (and a
> canoe/kayak in whitewater is pretty unconstrained) unless you include
> gyros and fully track all six degrees of freedom.
>
what kind of "constraints" do I need. I have already constrained the
system to be in flatwater situations, with a maximum speed. This won't
be used for whitewater.. it would be useless for whitewater
applications anyway, heh.
I still don't quite understand how gyros will help anyway. Gyros will
measure angular acceleration.. in the steady-state situation (while
I'm calibrating), gyros won't tell me anything about the way the
sensor is oriented.
> On the other hand, if you would accept knowing the total instantaneous
> acceleration ("g force") at any given time, then all you need to do [*]
> is a one-time calculation of the misalignments, bias, and scale factors
> and accept that the gravitational acceleration is just another component
> acting on the vehicle.
>
I must be missing something fundamental. I don't understand (yet) why
knowing the "g force" at steady-state (when the boat is not moving)
won't allow me to calibrate it out in future measurements. The sensors
position (w.r.t. the boat) doesn't change after calibration... maybe
by illustrating a simple example, you could explain this??
Rich Webb
wrote:
>>
>> What you're asking to do is not possible in an unconstrained case (and a
>> canoe/kayak in whitewater is pretty unconstrained) unless you include
>> gyros and fully track all six degrees of freedom.
>>
>
>what kind of "constraints" do I need. I have already constrained the
>system to be in flatwater situations, with a maximum speed. This won't
>be used for whitewater.. it would be useless for whitewater
>applications anyway, heh.
I guess I'm the one that's confused, then. In calm conditions, at a
constant speed, there is no acceleration other than gravity. Are you
just trying to measure pitch and roll? If so, mount your instrument and
do some inclination tests, which should allow estimating the alignment
errors of the sensors.
jdhar
> I guess I'm the one that's confused, then. In calm conditions, at a
> constant speed, there is no acceleration other than gravity. Are you
> just trying to measure pitch and roll? If so, mount your instrument and
> do some inclination tests, which should allow estimating the alignment
> errors of the sensors.
>
No, we are just confusing each-other over time :) In calm conditions,
zero-speed, I am trying to measure pitch and roll. I am trying to do
this so I can know how to de-rotate all my future readings which will
be in calm conditions, but non-zero and non-constant velocity. Knowing
the (X,Y,Z) forces on the boat is of particular interest in my
application (when the boat is moving), so I just want to make sure
that my readings are compensated for errors in mounting the sensor as
much as possible. Things like waves and what not are out of my
control, and are not of concern to this application.
Scott Seidman
590e28...@59g2000hsb.googlegroups.com:
Still sounds to me like high-pass filtering is what you need to do.
Everything you seem to be saying seems to bring this home. This is how
accelerometers are dealt with, unless there's a reason to do otherwise,
but I still haven't seen an "I need low frequency content because...."
statement.