Re: [Flightgear-devel] Autopilot tuning

2010-01-27 Thread Giuseppe Venanzoni
2010/1/26 syd adams adams@gmail.com:
 I wouldnt spend too much time on the b1900d , as Ive already redone most of
 it ,and added the CLM /DSC modes , and will probably commit tonight .

OK, I tuned only implemented modes on old aircraft :)
My patches are only suggestions

 The main problem i found on that is the yaw damper was fighting any turn in
 roll modes,so at the moment Ive disabled it.

I reduced the gain by 1/5. I think a low-pass filter could help

 I'm still tuning the pitch modes , i get the extreme elevator offset on mode
 initiaization now...

don't understand :( Have you tried to initialize internal variables
before mode switch?

Giuseppe


 Cheers

 --
 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


[Flightgear-devel] Autopilot tuning

2010-01-26 Thread Giuseppe Venanzoni
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=4t=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