Problem maintaining pitch when accelerating / decelerating.

I just finished up some initial flight tests using the ArduIMU+ V2 in my Skywalker airframe.
This was my first flight tests using IMU stabilization insteed of thermopile sensors. After some PID adjustment I have nice and stable stabilization of the airplane. But... Whenever I accelerate quickly the plane goes into a dive. Or if I decelerate it pulls up. The plane is trimmed and motor mounting angle is good, so it is not that. It does not seem to be a problem with vibrations. I have mounted the IMU using vibration pads, and if I slowly accelerate the IMU maintain the correct pitch at any throttle setting. Same with deceleration. But punch the throttle and the plane goes into a steep dive. Or sharply pulls up if I let go of the throttle quickly.

My setup is the ArduIMU+ V2 with unmodified v1.7 firmware and the ublox gps.
I am currently focusing on stabilization so the only autopilot logic in use, are PID loops for elevator and ailerons using roll and pitch from the IMU as input.

Views: 944

Reply to This

Replies to This Discussion

Hi John,

I have encountered the same thing, my personal fix was to turn down the roll comp (i know that sounds nuts and not sure that is the result)

and also the elevator commanded movement up to 8deg and down 8deg from 15..

now i see a little down attitude, but it rockets off and keeps alt...im wondering if some of it is perception..but mine did do exactly that to start with....

The pitching up as it slows was pronounced to start with, but now its pretty good..(also increase your lowest point throttle setting, it stops it trying to stall at wp`s)

of course this is just my results..mayeb others want to chirp in on this.

hope this helps.


Mike.
Most airframes will not experience this problem. If you are then the correct fix is to turn down the pitch/roll drift compensation gains in ArduIMU. They are not user parameters - you will have to look in the code for them. Decreasing those gains will allow a bit more pitch and roll error due to gyro drift but will reduce the effects of linear acceleration on the pitch.
Mike:
I appreciate your input, but it sounds like you solution is a fix for the symptoms and does not address the source of the problem. Limiting the elevator movement dampens the effect so that the IMU is not able to send the plane into a dive before it stabilize after an acceleration. But the problem is still there, and is most likely related to the DCM. I would like the autopilot to be able to use large elevator movements for flying in windy conditions, stall recovery , automated low speed landings, etc. And what about automated takeoffs? As it looks now, I suspect the IMU will steer the plane into the ground if I hand launch or catapult the airplane with stabilization active.
Doug:
Thanks for the info. I will try adjusting the gains and post my findings. But I am still worried about hand launch and catapult takeoffs. Can the accelerometer gains be lowered enough to allow for that kind of acceleration and still remove gyro drift? Also there would be situations when flying in windy conditions where gusts of wind will quickly decelerate the plane. If the IMU pulls up the nose at that moment it leads to even more deceleration and could cause a stall.
John,

I have flown the ArduPilot/ArduIMU quite a bit. Hand launch is a tricky business, but other than that I have not had any problems with linear acceleration. You are right about what could happen if you are flying close to stall speed. The general problem is that you are dealing with a first generation very inexpensive IMU, and the gyros are just not that good. They drift, quite a bit, so the gains have to be fairly high.

For most airframes and conditions hand launch is probably the only area you have to be real careful with. I have a take-off pitch parameter in the code that I always pick to be at least as large as I expect the pitch down from the hand launch to be.

Catapult lauch - well you will need to use another approach for that I think. Here is one approach I tested out a bit that will probably work for most airframes doing a catapult launch. Figure out a pitch servo value that you can hold constant during the launch phase that will produce a good climbout, neither too steep or shallow. Change the code so that during launch the IMU controls the bank angle and you just use a fixed pitch servo value. Pick the altitude criteria so that the airframe will reach it at least a second after the large linear acclerations have passed.
Doug,

Thanks for the heads up...didnt knwo about this..

John, without knowing about the IMU coding im only dealing with the symptoms..but...i have irradicated 99% of it.

I live and fly in the flattest and windiest part of the UK..never much less that 15knot winds..

I a can attest that auto take off`s do not stuff it in hard, if yours is doing that then, maybe you need to look further into the gains,(and into what doug has suggested)

I do have allot of movement, on all surfaces...but without touching the IMU i have got good flights and auto take offs...niot quite grown the doobreys to auto land yet..mainly due to the cost the UAV airframe i am using..

For the record...its taking off the ground with a gyro on the rudder by itself....

so the code is pretty much dead on!

regards,

Mike,
I have done quite a bit of testing with the IMU as well and what you experience is to be expected due to the code. There are several issues with the IMU code as it is. Firstly, the accelerometer needs to be properly calibrated. The default code assumes certain values for the limits and zero value from the accelerometer. As a result the computed composite vector doesn't always show 1G as you roll the plane around. In short, the accelerometer isn't accurate due to the lack of calibration in the current code.

This in turn messes up the de-weighting algorithm, which expects to see 1G when there is no lateral acceleration. Because of this corrections aren't as good as they can be. Furthermore, the de-weighting algorithm acts progressively, too progressively. Because of this, your roll and pitch readings will get progressively worse the longer you stay in a turn.

The DCM isn't really an estimator. As such, almost all the correct prediction of attitude in a dynamic situation (involving acclerations and decelerations) come from the de-weighting code working properly, and from the gyro drift management. The ArduIMU doesn't appear to handle the former very well in the current incarnation of the code - it's on the right track but I think the implementation is lacking. Also, I am not sure how well the gyro drift is being tracked, or whether it is set once during the initialization.

For these reasons, I am gravitating back to a KF type solution instead of the DCM. The DCM kinda works, and is easier to implement but has some shortcomings in real dynamic applications. One way to mitigate this is to use the GPS info for centripetal force compensation. It isn't ideal but it should be better than nothing and may work, depending on your particular application.

I suspect that the apparent "success" of the ArduIMU comes mainly from people who do not need critical output from the IMU and don't use the IMU for stabilization only (ie. usually GPS augmented). Once you put the IMU output on a visible GUI, you will see how poorly it performs in turns with the current code (1.6 and 1.7).

What would be nice would be to see a neat platform based on the ADXRS610 or better. These gyros show very little drift, highly repeatable performances, has a built in temperature sensor which allows for temperature compensation (very linear coefficiency). Unfortunately, it's expensive and runs on 5V.

Daniel
Just a quick update:
I played with the Kp/Ki_ROLLPITCH gains yesterday with some interesting (and some a bit scary) results.

To simplify gain changes I made the following code modifications.
#define ROLLPITCH_GAIN 0.5
#define Kp_ROLLPITCH 0.015*ROLLPITCH_GAIN
#define Ki_ROLLPITCH 0.000010*ROLLPITCH_GAIN


Some controlled indoor tests showed ROLLPITCH_GAIN 0.1 is the minimum gain that will compensate for gyro drift with the IMU lying flat on a table. With this in mind I decided to go with ROLLPITCH_GAIN 0.25 for my first flight.
In flight everything seemed fine and pitch hold was much better when accelerating/decelerating. Just some minor dips when trying to provoke the problem. So the pitch problem seemed to be solved.

But now for the scary part. I live by the coast, so you get used to flying in windy conditions. Yesterday I was flying in approx 6m/s. I was doing a long slow turn into the wind and as the plane banked into the wind (ground speed approaching zero or maybe even negative) the plane went nuts and started oscillating up and down and sideways in a self feeding loop that just got worse and worse. I tried applying throttle but the oscillating continued. So after watching the plane doing Red Bull air racing for a while, I switched to manual and leveled the plane. I then flipped back to auto and everything was fine. I repeated the slow turns into the wind and was able to provoke the problem in about 1 of 5 tries. The problem seem to occur when the plane because of the wind, turns around it's own axis at one spot with little or no ground speed (hanging on the wind).
Now before I go and place the blame on the IMU this might be related to the PID control loops. The strong sideway winds when turning can result in large aileron and elevator movements for long periods of time to keep the plane level. This might make the PID generate high D values to "rein" in the airplane. And when the sideway force suddenly disappear as the plane turns into the wind, the D's are so off that the PID is no longer in 'sync' with IMU. I have not had time to test this by flying with D set to zero yet, but doing so should confirm if the problem is PID or IMU related.. I will come back with more data when I get the chance.
Are you using GPS ground speed as speed input, without the airspeed probe?
No speed control, manual throttle to keep the setup simple since I am focusing on testing the stabilization.
John,

Any improvements?
I believe that is inherant in the underlying human pilot control philosophy of this AP that airspeed is controlled PRIMARILY by pitch and altitude is controlled PRIMARILY by throttle. Unfortunately this doesn't apply completely when trying to maintain flight equilibrium. For example, a human pilot reverses this philosophy when trying to stay on the glideslope centerline when flying an ILS approach.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service