On Friday 30 April 2004 13:59, Jon Berndt wrote:
between where you are and where you want to be. This error term is limited
to 100, filtered with a slight lag, and then multiplied by 0.1 in order to
get a commanded HDOT (time derivative of altitude, or rate of climb) of 600 ft/min.
This is a slightly unusual way of doing it, normally the commanded HDOT would be limited to 600 ft/min instead of the altitude error. But this approach works great too.
We don't [_currently_] have a climb rate property in ft/min, although we could add this easily, and I could also "manufacture" it in the AP using a gain. I finished this up at 3 a.m. this morning, so keep that in mind! I think your observation is a good suggestion for a modification, though.
From the plot it looks like the altitude hold performs very well. But if you try another test where you control the throttle in such a way
that the aircraft is unable to hold a 600 ft/min vertical speed. I think
you will see that the integrator will wind-up as the "HDot Error" value
never reaches zero.
This integrator will start winding whenever the elevator is saturating and still unable to achieve the commanded climb rate.
Yep. I've got a wind-up protection feature in the integrator, but I haven't used it, yet - that's another area where I want to add some "protection".
Jon
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
