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
You mentioned your eventual goal is to use your autopilot to fly aerobatics with a neutral plane, what is your take on mixing in rudder as the bank angle increases?
Knife edge circles are fun manuvers also. A little up elevator controls the circle or down elevator if your going the other direction.
Yes you are spot on, vey un-linear. I havn't acually done this yet but prolly will in the near future. I have just seen it done and the above equation is my take on how to do it. If you bank limit to like 30 deg then you can bet that this will work great. I'd say even out to like 45 deg but any more than that and you really start to wrap up the G's. IE 60 deg AOB is 2 G's
Thats a good point, up elevator can also increase the rate of turn in an aerobatic plane.
Its clear now that turn rate is highly dependant on the airframe. When flying an EasyStar the turn is controlled by the rudder (as apposed to ailerons) so “opposite rudder” probably would not have the desired effect.
I have seen aerobatic planes fly knife edge but that is an extreme condition not considered in the paper. I think for the assumptions to hold up a coordinated turn is needed. Most of the time, a knife edge is flown in a straight track, not a turn.
Ryan,
Thanks I will try that. Does the equation hold up well for a wide range of bank angles +/- 45 degrees. I would expect the true solution to be non linear.
In common practice what most people do is just feed forward a given ammount of elevator for a given bank angle. Keeps it real simple and tuneable. I have heard it called Loss of lift gain.... This is very AdHoc but simple and works great! Equations looks something like this
You mentioned adding up elevator in a turn to maintain altitude, eventually doing that without adding opposite rudder will tighten the turn into a death spiral towards the ground.
Have you watched a neutral aerobatic airplane fly a knife edge, as you roll the airplane onto its side the rudder gradually becomes the elevator and the elevator gradually becomes the rudder in order to maintain altitude.
I read the paper (a few times) and the ECF Explicit Complementary Filter seems to be a
promising approach. One thing I dont understand is the rate of change of the angle of attack (equation 11). The author assumes that in a turn, the rate of change of AoA is dependant on the pitch rate. That is, as the pitch rate increases, the rate of change of AoA will increase as well.
I dont agree with this conclusion. By assuming that the AoA continually increases during a turn will cause the AoA to diverge quickly.
I think the author is trying to determine how much the aircraft has to pitch up to maintain
level flight in a turn, which IS a function of pitch rate (or bank angle). Stated differently, the more bank in a turn, the more up elevator is need to maintain altitude.
Has anyone here correlated pitch rate in a turn to an increase in AoA to maintain level flight. It seems that if this is modeled correctly the centripetal acceleration can be better accounted for.
@ Bill
Thank you very much for your patience, now I get it.
It still puzzles me how's one to decide when to use ground speed and when airspeed, but that's beyond my scope and my goals.
Regarding yaw-to-roll effect, I used YawKp = 0.5, YawKi = 0.05. I suspect that the board feels sideways acceleration too, because accelerometers are apart from the rotation axis.
AFAIK Jordi's code uses ground speed, not airspeed, so is the code that I've written, based on Jordi's one.
Thank you again
Lorenzo
"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."
I am not sure why you saw an effect on the roll axis. You should not, because the speed was zero. How high did you set the DCM YawKp and YawKi? You really shouldn't change these parameters much, Jordi has tuned them for his hardware.
"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 ?"
This subject is fascinating. Notice I did not call the effect "centrifugal" acceleration, because it is not a centrifugal acceleration in the usual sense of the word. But it is a real acceleration in any case. I have done the math to assure myself that the real acceleration that you see is computed as the cross product of the airspeed vector with the rotation vector. But the math might not be convincing, so I like to use the special case of airspeed=windspeed as an example.
Lets suppose a plane is pointing straight into the wind with airspeed equal to wind speed. It will be stationary with respect to the ground. Now suppose that the plane turns a little bit to the left. It will no longer be pointing straight into the wind. As a result, it will begin to accelerate to left, without moving forward. The acceleration is real, and will affect any accelerometers on the plane. In both the aircraft and earth frame of reference, the foward velocity of the plane is zero, but the sideways velocity of the plane is not zero. The effect is quite noticeable if you fly your plane in strong wind: the plane will stop going forward, but it will move from side to side. In both the frame of reference of the plane and the ground frame, the plane accelerates sideways. In the frame of reference of the plane, if the turns are small, air will be going by at constant speed. The ground speed will be approximately zero, but not exactly zero, because the plane will be moving left and right with respect to the ground. There will be a sideways acceleration of the plane equal to the air velocity times the turning rate.
As a result, the theoretically correct equation for the sideways acceleration of an airplane that is pointing into an airstream is equal to the velocity of the plane with respect to the air, times the yaw rate.
In my case, since I do not have an airspeed sensor, I use the ground speed instead. It works just fine, for reasons that I explained in a previous post. In Jordi's case, I am not sure if he is using ground speed or air speed.
"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 ?"
Ryan answered this question for you. I do not think you should change any of the DCM algorithm gains that Jordi has selected without checking with him first.
The linear acceleration (ie car test) will have a direct affect on pitch like you are seeing (its perfectly normal) however the linear acceleration you are putting the imu in in the car is nothing like that in the air. You can however differentiate the GPS SOG and subtract it out but then you have even more latency. In the aircraft its not needed. The linear acceleration of the aircraft is in the noise level. Hence why I assume its zero and don't account for it.
As for the Yaw compensation a better way to test yaw compensation gain (granted I havn't gone through all of the DCM code) is to set the COG from the GPS to zero. That way you can see how quickly the gyro comes to zero heading every time. So you can twist it off 90 deg and it should always come back to zero. If you don't it will move all around to what ever the GPS is sending out and if you don't have your gps set up right it will be all over the place. Make sense? That's at least how I tested my gains (my approach is totally different than the DCM but still all the same stuff)
Comments
You mentioned your eventual goal is to use your autopilot to fly aerobatics with a neutral plane, what is your take on mixing in rudder as the bank angle increases?
Knife edge circles are fun manuvers also. A little up elevator controls the circle or down elevator if your going the other direction.
Greg
Thats a good point, up elevator can also increase the rate of turn in an aerobatic plane.
Its clear now that turn rate is highly dependant on the airframe. When flying an EasyStar the turn is controlled by the rudder (as apposed to ailerons) so “opposite rudder” probably would not have the desired effect.
I have seen aerobatic planes fly knife edge but that is an extreme condition not considered in the paper. I think for the assumptions to hold up a coordinated turn is needed. Most of the time, a knife edge is flown in a straight track, not a turn.
Ryan,
Thanks I will try that. Does the equation hold up well for a wide range of bank angles +/- 45 degrees. I would expect the true solution to be non linear.
elevator_cmd = elevator_cmd + loss_of_lift_gain * abs(roll angle);
I would start with something like 0.16 - 0.40 for the LoLgain
You mentioned adding up elevator in a turn to maintain altitude, eventually doing that without adding opposite rudder will tighten the turn into a death spiral towards the ground.
Have you watched a neutral aerobatic airplane fly a knife edge, as you roll the airplane onto its side the rudder gradually becomes the elevator and the elevator gradually becomes the rudder in order to maintain altitude.
Greg
I read the paper (a few times) and the ECF Explicit Complementary Filter seems to be a
promising approach. One thing I dont understand is the rate of change of the angle of attack (equation 11). The author assumes that in a turn, the rate of change of AoA is dependant on the pitch rate. That is, as the pitch rate increases, the rate of change of AoA will increase as well.
I dont agree with this conclusion. By assuming that the AoA continually increases during a turn will cause the AoA to diverge quickly.
I think the author is trying to determine how much the aircraft has to pitch up to maintain
level flight in a turn, which IS a function of pitch rate (or bank angle). Stated differently, the more bank in a turn, the more up elevator is need to maintain altitude.
Has anyone here correlated pitch rate in a turn to an increase in AoA to maintain level flight. It seems that if this is modeled correctly the centripetal acceleration can be better accounted for.
Thank you very much for your patience, now I get it.
It still puzzles me how's one to decide when to use ground speed and when airspeed, but that's beyond my scope and my goals.
Regarding yaw-to-roll effect, I used YawKp = 0.5, YawKi = 0.05. I suspect that the board feels sideways acceleration too, because accelerometers are apart from the rotation axis.
AFAIK Jordi's code uses ground speed, not airspeed, so is the code that I've written, based on Jordi's one.
Thank you again
Lorenzo
You said:
"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."
I am not sure why you saw an effect on the roll axis. You should not, because the speed was zero. How high did you set the DCM YawKp and YawKi? You really shouldn't change these parameters much, Jordi has tuned them for his hardware.
"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 ?"
This subject is fascinating. Notice I did not call the effect "centrifugal" acceleration, because it is not a centrifugal acceleration in the usual sense of the word. But it is a real acceleration in any case. I have done the math to assure myself that the real acceleration that you see is computed as the cross product of the airspeed vector with the rotation vector. But the math might not be convincing, so I like to use the special case of airspeed=windspeed as an example.
Lets suppose a plane is pointing straight into the wind with airspeed equal to wind speed. It will be stationary with respect to the ground. Now suppose that the plane turns a little bit to the left. It will no longer be pointing straight into the wind. As a result, it will begin to accelerate to left, without moving forward. The acceleration is real, and will affect any accelerometers on the plane. In both the aircraft and earth frame of reference, the foward velocity of the plane is zero, but the sideways velocity of the plane is not zero. The effect is quite noticeable if you fly your plane in strong wind: the plane will stop going forward, but it will move from side to side. In both the frame of reference of the plane and the ground frame, the plane accelerates sideways. In the frame of reference of the plane, if the turns are small, air will be going by at constant speed. The ground speed will be approximately zero, but not exactly zero, because the plane will be moving left and right with respect to the ground. There will be a sideways acceleration of the plane equal to the air velocity times the turning rate.
As a result, the theoretically correct equation for the sideways acceleration of an airplane that is pointing into an airstream is equal to the velocity of the plane with respect to the air, times the yaw rate.
In my case, since I do not have an airspeed sensor, I use the ground speed instead. It works just fine, for reasons that I explained in a previous post. In Jordi's case, I am not sure if he is using ground speed or air speed.
"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 ?"
Ryan answered this question for you. I do not think you should change any of the DCM algorithm gains that Jordi has selected without checking with him first.
Best regards,
Bill
As for the Yaw compensation a better way to test yaw compensation gain (granted I havn't gone through all of the DCM code) is to set the COG from the GPS to zero. That way you can see how quickly the gyro comes to zero heading every time. So you can twist it off 90 deg and it should always come back to zero. If you don't it will move all around to what ever the GPS is sending out and if you don't have your gps set up right it will be all over the place. Make sense? That's at least how I tested my gains (my approach is totally different than the DCM but still all the same stuff)
-
1
-
2
-
3
-
4
-
5
of 5 Next