Advanced autopilot tuning tips
| This article is a stub. You can help the wiki by expanding it. |
 This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.
|
In response to this question, see [1] for original response:
Note: For the time being, this is taken verbatim from the FG-Devel mailing list archives.
The large initial deflections you can get when switching between different controller cascades seems to occur because on the first iteration the controller sees an error but has no 'trend history' to know how effective its correction is, and so may command the max correction. As the aircraft responds to the initial correction though, the controller gets feedback upon which it then gauges the correction for the next iteration.
There are a number of ways around this, from limiting the flight control surface rate, either in the FDM config, or by inserting a filter between the output from the controller and the control axis input of the FDM, to filtering the target inputs, to using common pid controllers in the control hierarchy.
I ended up using a three controller hierarchy in some aircraft, with the same lower-level controllers being used by all modes and which were always engaged; only the top level controllers were switched.
For example, for altitude-hold I might have the following hierarchy:
Altitude-hold: generates a target climb-rate in FPS from the
difference between the current altitude and the target altitude.
Climb-rate-hold: generates a target pitch angle from the
difference between the current climb-rate and the target
climb rate generated by the Altitude-hold controller.
Pitch-hold: generates an elevator deflection from the
difference betwen the current pitch and the target
pitch generated by the Climb-rate-hold controller.
but then I'd use the same Climb-rate-hold and Pitch-hold controllers for the glideslope-hold hierarchy and just switch the Top level Altitude hold controller off instead of duplicating the entire hierarchy again.
Because the lower-level controllers are running continuously and are not switched on and off they've got some trend history data to be working with and this seems to ameliorate the problem by effectively buffering the top-level input change.
This type of hierarchy isn't without its own problems though; at low airspeeds you might need the Pitch-hold controller to be pretty brutal and almost driving into oscillation but at high speeds you need it to be much more delicate. However, judicious use of filters and variable gains can usually get you around most problems.
There is one type of autopilot problem that's more difficult fix though: the autopilot controllers and filters should run at a constant rate and although a <rate> parameter was added and initially worked, I think it may have become broken at some point and the rate at which the controllers and filters operate depends more upon the frame rate than anything else. Because the rate at which the controllers work is critical, depending upon the gains used, a controller that might be stable on one system might become unstable on a slower, or even sometimes a faster system (I've seen this sort of problems happen both ways).