Posted by Ryan Beall on October 14, 2009 at 3:30pm
In Bill's recent pod cast he talked about how the imudevboard experienced a random nose dive or extreme over estimation in the pitch (theta) axis. His theory was that the noise due to engine/aircraft vibration was causing the gyros to give inaccurate readings. He said that he put the imu in foam and the problem went away. I don't know how repeatable his experience was or how many test vehicles this "technique" was run on, but I find it no coincidence that I experienced the exact same effect on my imu.Here is my theory:I did some quick number crunching on some equations and found that it totally makes sense that pitch would "depart reality" more-so than roll and very rapidly as both him and I have both observed.(edit)For a 30deg AOB turn at about 1.5g's total the attitude solution if improperly estimated would be off in roll a couple of deg and about 30deg in pitch causing this nose dive affect.(correction)For a 60deg AOB turn at 2G's the estimation in pitch was off by 10 deg if centripetal was incorrectly calculated. The error would be in the positive direction causing the stabilty loop to push the nose over causing the "imu nose dive problem"I was extremely surprised at how quickly pitch departed at very shallow angles of bank. So this lead me to suspect one thing beings my math modeled exactly what I was seeing in the air....centripetal. Here are the pitfalls I evaluated:Gps latencyGps bandwidthPropper velocity mapping into componentsSo I will discuss in orderLatency. GPS has it...big surprise well how much is it and how much can it affect the solution. Depending on the module I have read 10seconds to about 0.5. Well for my Ublox it was about 0.75 to 1.5 depending upon the rep rate selected and positional accuracy (number of sats). I plotted it out and you can see how poorly the centripetal was accounted for in my "car test run". It's ok but in its worst case scenario could be off as much as 13 deg....which is better than 45deg with no centripetal at all for the runs I did. However 13 off and 1.5 seconds late quickly would cause things to go southGPS bandwidth. Its at best 4Hz....need I say more. You are going to miss changes in speed quite a bit and loose a lot of accuracy. Also note the graph where GPS clearly is reporting the wrong speed at the wrong timeVelocity mapping: This is how you map the velocity into the actual body velocities. Most people assume that the speed reported from the GPS is always out of nose of the airplane. This is mostly true except for in climbs. It is safe to assume that the v velocity (out the wing) is zero but not the w (out the belly of the aircraft). The total of u and w are the SOG from GPS and you must break them up. I'm pretty sure the imudevboard code does this but if it doesn't this is another large source for mis calculation----------------------------------------------------All of these things together are issues that can clearly throw off one thing....Centripetal estimation which was why we determined there was a 30deg offset in our crappy estimation. So with that solved (use airspeed instead) the problem goes away. I have hours of flight time on my IMU both with and without GPS and the nonGPS filter has yet to diverge from reality under self stabilized flight. GPS filter on the other hand....it depended on the airplane the autopilot....amongst a lot of other random variables that never made sense like calendar day. Some days it was fine and others it wasn't on the same aircraft which leads me to my next topic.
<Noise/Vibration:Gyro drift is due to temperature. When I tried to follow the drift using an integrator in software we had issues. Same idea and same effects and just as random. Some days fine and some days not. The filter DCM or what have you is a very dynamic thing and if you try to model a temperature drift with an integrator (in my humble opinion) it will only work assuming that your other estimations are perfect. Else the other errors will map into your temp compensation.....which does happen no denying it. Its ok if your gyros don't move that much with temperature and you keep an eye on the integrator however its way too unpredictable of a problem to assume your error state is a fixed target....It simply isn't.I run a temperature comp on my gyros and get repeatable results every time. With my comp equations the end result is a gyro that will hold itself +- 5 deg for 5 min or so. There are a lot of other tricks here like circuit noise reduction and oversampling that can be done but this is huge if you want to keep your solution converged.As far as vibration.....If a gyro gave crap results because of vibration then it wouldn't be any use in a 6dof filter. Your accelerometers produce noise with vibration and hence the reason we use gyros. I just don't see any room for allowance of gyros to be noisy in vibration. Pick good gyros and temp comp them and so many problems dwindle away very quickly-----------------------------------------------------------------------------------------------------------------update: addressing the airspeed questionMy acceleration model
Hi all.
@ Bill Premerlani
Sorry but I'm getting more and more confused. Doing some test with ArduIMU code I've noticed that rotation around yaw axis with high values of YawKp and YawKi (but speed = 0) had an effect on roll axis. The reason I supposed was: the algorithm is trying to compensate a centrifugal acceleration that actually doesn't exist because the speed is 0. Now after Bill explanation I'm doubting this. Nonetheless I simply don't understand where the acceleration comes from. If airspeed = windspeed then aircraft speed is zero in both the aircraft's and earth's frame of references. Thus also centrifugal acceleration (that is omega yaw x speed) should be zero.
Where am I mistaking ?
Another question: during a car test I've also found that pitch is greatly influenced by longitudinal acceleration (sudden starts and stops). To me it was no surprise, since - as explained in Bill's draft - it's the accelerometer data that are used to compensate gyro's drift, not the other way around. In other words, accelerometer's data have more "authority" than gyro's information in the long term. Is this correct or should I tune the gains in some way to reduce the effect of acceleration on pitch ?
Just a couple more observations about the use of airspeed or ground speed in the computation of the compensation for centrifugal acceleration, and then I promise to be quiet:
Airspeed is the theoretically correct speed to use, but ground speed works pretty well for the DCM algorithm, even in high winds, for several reasons:
1. The core algorithm based on an exact integration of the rotation group is accurage and low drift to begin with, so the PI feedback gains for drift compensation are very low. Therefore, it takes a sustained acceleration error for a long period of time.to generate a roll or pitch error.
2. While a plane is flying in a straight line, it does not matter what speed you use, the turn rate is zero, so the compensation is zero.
3. If a plane is turning fast enough for the acceleration to matter, it will spend time traveling both with and against the wind. Analysis shows that the errors arising from using ground speed instead of wind speed approximately cancel. The acceleration is underestimated going into the wind, and overestimated flying with the wind.
So, what happens with DCM in practice is that it works well in winds higher than you would expect it to, without an airspeed measurement, provided that you either fly in straight lines, or that you do not fly in straight lines.
By the way, I have done the analysis of the centrifugal acceleration of an airframe due to rotation, and Ryan is correct with regard to the question of whether to use ground (GPS) speed or air speed in the calculaton. The analysis can be done using geometry and vector calculus. Air speed is theoretically correct. The reason is, when a plane rotates in an airstream, it accelerates to accomodate the airstream.
There is an easy way to see it. Suppose that the plane is flying straight into the wind, with a speed equal to the wind. If it rotates ever so slightly, it will accelerate sideways. If you used ground speed (which is zero) you would compute that there is no acceleration. But in fact, if the plane rotates, it will accelerate.
There have been a few times that I have actually observed the effect, when I flew my GentleLady into a wind that matched its airspeed. I have even landed backwards a time or two.
When I match the airspeed to the wind speed, I can quickly move the GentleLady from side to side with just a little bit of rudder movement. Within frame of reference of the plane, the sideways movements are large accelerations, that are proportional to the windspeed=airspeed, times the rotation rate of the plane.
So, if you want to be able to fly in winds greater than about 1/2 of the airspeed of your plane, you need airspeed for the centrifugal acceleration compensation. For winds less than that, I have found that ground speed works well enough.
In my most recent flights I acutally had to command the airspeed higher to make any headway so I'd say it works quite well in wind. It held a continous orbit for 10 min in 20 gusting 28 knots. Which was about 90-110% of commanded airspeed.
Congratulations on the progress you've made. Very good stuff, and you have stimulated a number of interesting discussions. The DCM algorithm was mentioned a few times. So, at the risk of "stirring the pot", I will throw my two cents in...
The DCM algorithm, running on the UAV DevBoard works great, especially for pitch and roll control, without temperature compensation, and without an airspeed measurement. Several pilots have personally reported their results to me, a few with over 100 hours flight time each with the firmware, and another dozen with dozens of flights each. They all report being surprised at the accuracy of the pitch and roll control. For example, you might take a look at the work that Brian Cuervo has done with his tail-less airframe.
There is no need for temperature compensation with the DCM algorithm, because the integrator in the PI feedback controller automatically compensates for gyro drift. The reason you can do that with the DCM algorithm, is because the drift compensation is accomplished faster than the gyro offset can change because of a temperature change. The PI feedback controller "locks" onto the accelerometer information. A data point on that is that I fly the DevBoard in my EasyStar, mounted right next to the LiPo battery. The board starts out cold, is toasty warm at the end of the flight, with no shift in pitch.
The DCM algorithm compensates the accelerometer measurements for acceleration.
There is no need for an airspeed measurement with the DCM algorithm, because it provides very accurate pitch control. One data point on the accuracy of the pitch control is my entry in this month's T3 contest. I let the controls make the transitions in altitude as steps. It was interesting to watch. When the EasyStar reached a waypoint it would pitch up or down 15 degrees to quickly climb or descend to the altitude of the next waypoint. When it reached its target altitude, it would level off in a few meters.
Regarding the vibration issues for gyros in general, and the LISY gyros in particular: vibrations near the resonant frequency of some types of gyro's mechanical elements causes them to "rattle", resulting in a nonlinear response that cannot be filtered out: it quickly generates a large offset. We have plenty of testing to confirm that it is a real effect that can be mitigated. The ground testing is most convincing: in a ground test, acceleration effects do not enter the picture. John-Mac mounted a "redboard" (which has LISY gyros) on his helicopter (which was strapped down), and when he powered up the motor, the gyros "went berserk", basically generating large amplitude, random values. Interestingly, John also mounted a "greenboard" (which has Analog Devices gyros) on his helicopter, it performed perfectly, without any special mounting.
Interestingly enough, vibration is not an issue with the accelerometers that we are using. I would have thought there would be, since vibration IS an acceleration. But since the accelerometers have a high resonant frequency, they do not "rattle", and the vibrations can be filtered out with either the antialiasing filter or by a combination of oversampling and a digital filter.
Back to the gyros: I do not recommend using the LISY gyros in helicopters, the vibration is too great. However, the LISY gyros are well-suited for fixed wing aircraft, provided you are aware of the vibration issue. In the case of the UAV DevBoard, there is a simple test to find out if vibration is an issue: ground test the firmware in any of the stabilized modes to see if it works ok with the motor running. If it does, you are home free. If not, then you need to take some simple steps to isolate vibration.
In my EasyStar, there is so little vibration, the gyros are not affected, I do not use any special mounting. However, in my GentleLady, ground testing of MatrixNav showed that vibration interfered with the accuracy of pitch control. (Since the GentleLady does not use ailerons, there is no roll control.) The simple cure was to mount the board on a foam rubber strip.
Thanks for your assessment. I am looking at using DCM in an instrument for full scale sailplanes where two conditions are not at all unlikely to occur: 1 the wind speed at altitude is often 50+% of the airspeed and 2 sustained circling may occur for many minutes. For my application, getting the centripetal correction right seems important....
I take away from your comments that in your application you are getting better results with airspeed than gps speed. Can you give me any feedback on what wind conditions you have tested in or looked at as a percentage of airspeed. I have up till now not intended to have pitot/static inputs into this instrument, but perhaps that will be necessary as well as a wind estimate.
On the whole notion of not needing to measure the acceleration in the earth inertial field, I'd accept that up to a point, but if you are measuring it in the air/wind referenced inertial reference field shouldn't you have to do a rotation to either the airframe or earth coordinate system before using it as a correction?
... precisely my point, it is valid for fixed wing but for rotary-wing you'll want to replace the pitot tube with a primitive intertial navigation system.
Anyways that proves that Ryan had a valid point and a tested and true solution to the problem. I wonder if my IMU had worked out better if I had known about this a year ago...
This paper co-authored by the famous Dr. Mahoney of DCM fame will shed some light on the workings of an airspeed sensor, 6DOF gryos and accels using centripetal attitude estimation ( from angle of attack information) to create an accurate attitude estimator.
Entitled: A Complementary Filter for Attitude Estimation of a Fixed-Wing UAV
"The Explicit Complementary Filter (ECF) was extended
to incorporate a model of the longitudinal angle-of-attack
dynamics of a fixed-wing aircraft. With this model, the ECF-
^a, using only IMU and dynamics pressure measurements
achieved attitude filtering performance of the same quality
as a full extended Kalman filter that exploited full GPS/INS
data. The ECF shows significant potential as a simple and
robust attitude filter for small scale UAV vehicles."
Hmm.. Another thing that came into my mind while pondering this issue; with a pitot tube the centripetal correction wouldn't work with a helicopter or a quad since you aren't always going to the direction of the nose of your A/C; so in the case of such A/C having the IMU estimate the speed and it's direction with the help of GPS would be preferrable. I just wonder whether the speed estimate would hold true with a lower-end accelerometer for more than a couple of seconds which might not be enough after all.
Comments
I would write:
Va*q*sin(AoA)/g + sin(pitch)
Va*(r*cos(AoA)_p*sin(AoA))/g - cos(pitch)*sin(roll)
Va*q*cos(AoA)/g - cos(pitch)*cos(roll)
Michel
@ Bill Premerlani
Sorry but I'm getting more and more confused. Doing some test with ArduIMU code I've noticed that rotation around yaw axis with high values of YawKp and YawKi (but speed = 0) had an effect on roll axis. The reason I supposed was: the algorithm is trying to compensate a centrifugal acceleration that actually doesn't exist because the speed is 0. Now after Bill explanation I'm doubting this. Nonetheless I simply don't understand where the acceleration comes from. If airspeed = windspeed then aircraft speed is zero in both the aircraft's and earth's frame of references. Thus also centrifugal acceleration (that is omega yaw x speed) should be zero.
Where am I mistaking ?
Another question: during a car test I've also found that pitch is greatly influenced by longitudinal acceleration (sudden starts and stops). To me it was no surprise, since - as explained in Bill's draft - it's the accelerometer data that are used to compensate gyro's drift, not the other way around. In other words, accelerometer's data have more "authority" than gyro's information in the long term. Is this correct or should I tune the gains in some way to reduce the effect of acceleration on pitch ?
Thank you in advance and best regards
Just a couple more observations about the use of airspeed or ground speed in the computation of the compensation for centrifugal acceleration, and then I promise to be quiet:
Airspeed is the theoretically correct speed to use, but ground speed works pretty well for the DCM algorithm, even in high winds, for several reasons:
1. The core algorithm based on an exact integration of the rotation group is accurage and low drift to begin with, so the PI feedback gains for drift compensation are very low. Therefore, it takes a sustained acceleration error for a long period of time.to generate a roll or pitch error.
2. While a plane is flying in a straight line, it does not matter what speed you use, the turn rate is zero, so the compensation is zero.
3. If a plane is turning fast enough for the acceleration to matter, it will spend time traveling both with and against the wind. Analysis shows that the errors arising from using ground speed instead of wind speed approximately cancel. The acceleration is underestimated going into the wind, and overestimated flying with the wind.
So, what happens with DCM in practice is that it works well in winds higher than you would expect it to, without an airspeed measurement, provided that you either fly in straight lines, or that you do not fly in straight lines.
Best regards,
Bill
By the way, I have done the analysis of the centrifugal acceleration of an airframe due to rotation, and Ryan is correct with regard to the question of whether to use ground (GPS) speed or air speed in the calculaton. The analysis can be done using geometry and vector calculus. Air speed is theoretically correct. The reason is, when a plane rotates in an airstream, it accelerates to accomodate the airstream.
There is an easy way to see it. Suppose that the plane is flying straight into the wind, with a speed equal to the wind. If it rotates ever so slightly, it will accelerate sideways. If you used ground speed (which is zero) you would compute that there is no acceleration. But in fact, if the plane rotates, it will accelerate.
There have been a few times that I have actually observed the effect, when I flew my GentleLady into a wind that matched its airspeed. I have even landed backwards a time or two.
When I match the airspeed to the wind speed, I can quickly move the GentleLady from side to side with just a little bit of rudder movement. Within frame of reference of the plane, the sideways movements are large accelerations, that are proportional to the windspeed=airspeed, times the rotation rate of the plane.
So, if you want to be able to fly in winds greater than about 1/2 of the airspeed of your plane, you need airspeed for the centrifugal acceleration compensation. For winds less than that, I have found that ground speed works well enough.
Best regards,
Bill
Congratulations on the progress you've made. Very good stuff, and you have stimulated a number of interesting discussions. The DCM algorithm was mentioned a few times. So, at the risk of "stirring the pot", I will throw my two cents in...
The DCM algorithm, running on the UAV DevBoard works great, especially for pitch and roll control, without temperature compensation, and without an airspeed measurement. Several pilots have personally reported their results to me, a few with over 100 hours flight time each with the firmware, and another dozen with dozens of flights each. They all report being surprised at the accuracy of the pitch and roll control. For example, you might take a look at the work that Brian Cuervo has done with his tail-less airframe.
There is no need for temperature compensation with the DCM algorithm, because the integrator in the PI feedback controller automatically compensates for gyro drift. The reason you can do that with the DCM algorithm, is because the drift compensation is accomplished faster than the gyro offset can change because of a temperature change. The PI feedback controller "locks" onto the accelerometer information. A data point on that is that I fly the DevBoard in my EasyStar, mounted right next to the LiPo battery. The board starts out cold, is toasty warm at the end of the flight, with no shift in pitch.
The DCM algorithm compensates the accelerometer measurements for acceleration.
There is no need for an airspeed measurement with the DCM algorithm, because it provides very accurate pitch control. One data point on the accuracy of the pitch control is my entry in this month's T3 contest. I let the controls make the transitions in altitude as steps. It was interesting to watch. When the EasyStar reached a waypoint it would pitch up or down 15 degrees to quickly climb or descend to the altitude of the next waypoint. When it reached its target altitude, it would level off in a few meters.
Regarding the vibration issues for gyros in general, and the LISY gyros in particular: vibrations near the resonant frequency of some types of gyro's mechanical elements causes them to "rattle", resulting in a nonlinear response that cannot be filtered out: it quickly generates a large offset. We have plenty of testing to confirm that it is a real effect that can be mitigated. The ground testing is most convincing: in a ground test, acceleration effects do not enter the picture. John-Mac mounted a "redboard" (which has LISY gyros) on his helicopter (which was strapped down), and when he powered up the motor, the gyros "went berserk", basically generating large amplitude, random values. Interestingly, John also mounted a "greenboard" (which has Analog Devices gyros) on his helicopter, it performed perfectly, without any special mounting.
Interestingly enough, vibration is not an issue with the accelerometers that we are using. I would have thought there would be, since vibration IS an acceleration. But since the accelerometers have a high resonant frequency, they do not "rattle", and the vibrations can be filtered out with either the antialiasing filter or by a combination of oversampling and a digital filter.
Back to the gyros: I do not recommend using the LISY gyros in helicopters, the vibration is too great. However, the LISY gyros are well-suited for fixed wing aircraft, provided you are aware of the vibration issue. In the case of the UAV DevBoard, there is a simple test to find out if vibration is an issue: ground test the firmware in any of the stabilized modes to see if it works ok with the motor running. If it does, you are home free. If not, then you need to take some simple steps to isolate vibration.
In my EasyStar, there is so little vibration, the gyros are not affected, I do not use any special mounting. However, in my GentleLady, ground testing of MatrixNav showed that vibration interfered with the accuracy of pitch control. (Since the GentleLady does not use ailerons, there is no roll control.) The simple cure was to mount the board on a foam rubber strip.
Best regards,
Bill Premerlani
Thanks for your assessment. I am looking at using DCM in an instrument for full scale sailplanes where two conditions are not at all unlikely to occur: 1 the wind speed at altitude is often 50+% of the airspeed and 2 sustained circling may occur for many minutes. For my application, getting the centripetal correction right seems important....
I take away from your comments that in your application you are getting better results with airspeed than gps speed. Can you give me any feedback on what wind conditions you have tested in or looked at as a percentage of airspeed. I have up till now not intended to have pitot/static inputs into this instrument, but perhaps that will be necessary as well as a wind estimate.
On the whole notion of not needing to measure the acceleration in the earth inertial field, I'd accept that up to a point, but if you are measuring it in the air/wind referenced inertial reference field shouldn't you have to do a rotation to either the airframe or earth coordinate system before using it as a correction?
Thanks again for all your input and discussion!
Doug
Anyways that proves that Ryan had a valid point and a tested and true solution to the problem. I wonder if my IMU had worked out better if I had known about this a year ago...
Entitled: A Complementary Filter for Attitude Estimation of a Fixed-Wing UAV
http://engnet.anu.edu.au/DEpeople/Jonghyuk.Kim/pdf/2008_Euston_iros...
Quoting the papers conclusion:
"The Explicit Complementary Filter (ECF) was extended
to incorporate a model of the longitudinal angle-of-attack
dynamics of a fixed-wing aircraft. With this model, the ECF-
^a, using only IMU and dynamics pressure measurements
achieved attitude filtering performance of the same quality
as a full extended Kalman filter that exploited full GPS/INS
data. The ECF shows significant potential as a simple and
robust attitude filter for small scale UAV vehicles."
-
1
-
2
-
3
-
4
-
5
of 5 Next