On Wednesday 10 Mar 2010, Curtis Olson wrote: > On Wed, Mar 10, 2010 at 7:50 AM, leee <l...@spatial.plus.com> wrote: > > As this would be a new feature, and one which might affect > > existing behaviours, I _really_ think it ought to be off by > > default. > > I really can't imagine any sane system that is designed to > leverage windup as a feature. It's like closing your eyes and > driving off the road. Anti-windup is a bit like adding guard > rails to the road. > > > Turning it on by default is almost guaranteed to break > > something, whereas because it is new nothing will be currently > > using it - this just seems a bit silly to me. > > windup == bad > antiwindup == good > > In a lot of ways this is like a bug fix. So if implemented > correctly, I really can't imagine any way it could break > anything. This only affects the simple PI controller (which is > brutally crude anyway.) The more advanced PID controller which > is used for most complex stage in most autopilots already has > anti-windup built into it's algorithm and we aren't touching > that. > > Best regards, > > Curt.
I agree that windup == bad and antiwindup == good, and that in a perfect world no one would have leveraged windup and that everyone would have implemented their PI simple controllers correctly. The trouble is that It's not a perfect world. Personally, I strongly doubt that any of the aircraft developers would have deliberately leveraged windup in their PI simple controllers but would have tuned them to work around what may have seemed to be an anomaly in their behaviour without realising that the anomalous behaviour was due to a windup issue. An extreme example of this sort of situation was the reversed wing incidence bug in YASim. Without even realising there was a problem, aircraft developers spent many hours, days and even weeks, tuning their FDMs to work around this unknown bug. Needless to say, any YASim aircraft that had non-zero wing incidence was comprehensively broken by the fix. An extreme example, like I said, but it highlights how aircraft developers work around 'bugs' which, when fixed, break the aircraft. The bottom line is that without a full audit of all the aircraft in FG there is simply no way to judge how many aircraft might be broken by changing the default behaviour. Furthermore, because it will be a new feature there is nothing that is currently in FG that is dependent upon it: changing the default will fix nothing. In the longer term, I would agree that it would be appropriate to change the default behaviour, but given the number of aircraft that a few of the developers have to maintain I think you need to give them a year or two to check for problems before forcing this change. This is, after all, how changes in the default behaviour of other software applications is handled: you give a warning that the default behaviour will be changed and a reasonable time scale for dependent works to be prepared for that change. You don't, unless you wish to antagonise all the developers who make stuff for your application, simply make the change and pass all the responsibility for fixing the resultant mess on to them. Especially, as I feel I must point out once again, when there is nothing in FG that currently depends upon a change in the default behaviour. Most importantly, note that leaving the default behaviour unchanged does not stop new work from using the new feature, and if implemented as Torsten suggested, it would not require any changes to new works that did use the new feature when the default behaviour is eventually changed. Going back a few years, there was a pretty long period (about a year) where I was spending more time fixing my aircraft, broken by bug fixes in the code, than I spent working on new stuff or improving the existing aircraft. I can tell you that It was a pretty depressing time. While I can understand the desire behind the coders to correct problems in their work, and to move it forwards as quickly as possible, that code depends upon the content developed for it, by the aircraft and scenery developers, and without their content FG is pointless. Sometimes, I think that the FG coders forget this important point. LeeE ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
