Wonderful, brilliant stuff Giuseppe, The way that the autopilot works with those patches is the way I expected.
Hope this stuff makes its way into CVS so at least there's a good reference implementation. pete Giuseppe Venanzoni wrote: > Hi! > > I would like to join the discussion about AP tuning. I recently posted > a message on the forum > (http://www.flightgear.org/forums/viewtopic.php?f=4&t=6853) for > b1900d. With enclosed files, action is quite smooth and autopilot > seems stable, at least on my conputer. > For vertical stabilization (selected altitude holding) I used an > approach very similar to the one proposed by LeeE, with a first stage > that controls vertical speed (I used a proportional only stage with > <pi-simple-controller>). I also managed the configuration in such a > way to share as much stages as possible for different modes, using a > flag which activates these stages. > I also used several noise-spike filters in order to avoid abrupt changes. > For the problem of bouncing during transition between modes, I > modified the script flightdirector.nas in such a way that when pilot > switches on AP or changes mode all internal variables of the autopilot > are reinitialized with the current attitude of the plane. In fact, for > velocity mode PIDs the memory of the past is only contained in these > variables, since there isn't an integrator. > > I hope that it can be useful. > > Giuseppe > > > leee wrote: > >> 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). >> >> LeeE >> > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
