Accelerometer + Tilt compensation

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

Spehro Pefhany wrote in news: snipped-for-privacy@4ax.com:

"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,

I've had this hanging on my office wall since 1995.

Cute.. thanks. Best regards, Spehro Pefhany

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.

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.

snipped-for-privacy@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de

Ok, so it's pretty much only rotation around the X or Y axis that I can compensate for by using the gravity vector to determine rotation...

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

snipped-for-privacy@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de

es

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.

be

h.

or

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.

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

on

ter

ood

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:

I have started playing with Quaternions in Matlab, and they are working out so far... #1 is posing the problem for me right now.

..

our

can

ns

both

ill

the

ng

nd

be

"The Journey is the reward"

eff.com

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.

jdhar wrote in news:829e8af4-8aa7-45d9-9a51- snipped-for-privacy@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.

en

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.

jdhar wrote in news:1cc7638c-a1bf-47af-b4ee- snipped-for-privacy@m45g2000hsb.googlegroups.com:

This is true only if the sensor is not accelerating in space. This goes to Einstein's Principle of Equivalence.

Agreed

Sure

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.

see,

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.

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)

Thanks Jon, glad we are on some common ground...

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.

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.

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.

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.

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.

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)

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)

Right, this would be a cal time thing, not something done all the time. Once it's mounted, it shouldn't change orientation.

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

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.

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.