Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Tuesday 09 Mar 2010, Curtis Olson wrote: On Tue, Mar 9, 2010 at 12:15 PM, Torsten Dreyer wrote: Hi, I am about to commit a change that adds anti windup logic to the pi-simple- controller (FGPISimpleController) which currently lacks such functionality. The FGPIDController has some anti windup logic but that controller does not suit very well for some solutions and one might (I do) want to use the pi- simple-controller instead, if this just had some anti windup. My question is: should I add a switch to make the pi-simple-controller behave like it currently does, e.g. add something like anti-winduptrue/anti-windup and default that switch to 'false'? This should be a good idea if some autopilots relied on wound up PISimpleController. Or is it oversized backwards-compatibility? I can't imagine a single case where wind-up is a good idea - but who knows... Comments? Torsten BTW. the patch is really simple: double output = prop_comp + int_sum; -output = clamp( output ); -set_output_value( output ); +double clamped_output = clamp( output ); +if( output != clamped_output ) // anti-windup + int_sum = clamped_output - prop_comp; + +set_output_value( clamped_output ); Speaking as the author of the original PISimpleController code I think some anti-windup logic would be a good additive feature. I don't think we would need a switch to maintain the old behavior (unless we want to demonstrate to someone why anti-windup is a good idea ... but in that case, the switch should be to turn it off, not turn it on.) [snip...] Regards, Curt. As this would be a new feature, and one which might affect existing behaviours, I _really_ think it ought to be off by default. 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. LeeE -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
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. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
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#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Wed, Mar 10, 2010 at 9:27 AM, leee wrote: 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. Hi Lee, You make an excellent point, however I'm pretty sure it doesn't apply in this situation. Your example is apples to oranges from what we are talking about here. Can we find (or even just imagine) a case where this would break something? I can't myself. I don't want to argue just for the sake of arguing. This fix is not changing behavior like the example you cite. It just sets up guard rails to prevent us from going into an ill- or un-defined zone of control theory that everyone recognizes is bad and not useful. What is proposed is analogous to adding divide by zero or null pointer reference protection -- nothing more than guard rails to keep us out of bad areas we shouldn't be in anyway. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Wednesday 10 Mar 2010, Curtis Olson wrote: On Wed, Mar 10, 2010 at 9:27 AM, leee wrote: 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. Hi Lee, You make an excellent point, however I'm pretty sure it doesn't apply in this situation. Your example is apples to oranges from what we are talking about here. Can we find (or even just imagine) a case where this would break something? I can't myself. I don't want to argue just for the sake of arguing. This fix is not changing behavior like the example you cite. It just sets up guard rails to prevent us from going into an ill- or un-defined zone of control theory that everyone recognizes is bad and not useful. What is proposed is analogous to adding divide by zero or null pointer reference protection -- nothing more than guard rails to keep us out of bad areas we shouldn't be in anyway. Regards, Curt. There is always a risk associated with changing default behaviour and the bottom line is that there is no immediate need to do so, nor any overhead incurred by not doing so. This just seems like a commonsense policy to me, and was one of the factors that lead to me stopping work on FG. LeeE -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Wed, Mar 10, 2010 at 3:55 PM, leee wrote: There is always a risk associated with changing default behaviour and the bottom line is that there is no immediate need to do so, nor any overhead incurred by not doing so. This just seems like a commonsense policy to me, and was one of the factors that lead to me stopping work on FG. LeeE Would there be any value in searching the aircraft XML files in CVS to see how many are using the pi-simple-controller ? That might provide some idea of how much of an issue this is, though obviously doesn't address non-CVS aircraft. -Stuart -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Wednesday 10 Mar 2010, Stuart Buchanan wrote: On Wed, Mar 10, 2010 at 3:55 PM, leee wrote: There is always a risk associated with changing default behaviour and the bottom line is that there is no immediate need to do so, nor any overhead incurred by not doing so. This just seems like a commonsense policy to me, and was one of the factors that lead to me stopping work on FG. LeeE Would there be any value in searching the aircraft XML files in CVS to see how many are using the pi-simple-controller ? That might provide some idea of how much of an issue this is, though obviously doesn't address non-CVS aircraft. -Stuart This is exactly the sort of think I'd hope to see at the end of the transition/notification period and just before the default behaviour was changed, so that any outstanding occurrences could be looked into. Like I've already said though, while the new feature is desireable, there is no need to change the current default behaviour because nothing currently depends upon it, and should people wish to use the new feature they can do so without having to worry about changing the places where they have used it when the default behaviour actually is changed. LeeE -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
leee wrote: On Wednesday 10 Mar 2010, Stuart Buchanan wrote: That might provide some idea of how much of an issue this is, though obviously doesn't address non-CVS aircraft. This is exactly the sort of think I'd hope to see at the end of the transition/notification period and just before the default behaviour was changed, so that any outstanding occurrences could be looked into. In a continuous process of improving FlightGear there's no point in keeping an 'undesired' (or, in some cases even a buggy) feature as being the default just because some unknown 3rd party software _might_ depend on it. If people don't feel like moving on with the times then they're free to use old versions of software. If they'd like to stay current, then they're going to adjust their 3rd party stuff accordingly. It's as simple as that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Wednesday 10 Mar 2010, Martin Spott wrote: leee wrote: On Wednesday 10 Mar 2010, Stuart Buchanan wrote: That might provide some idea of how much of an issue this is, though obviously doesn't address non-CVS aircraft. This is exactly the sort of think I'd hope to see at the end of the transition/notification period and just before the default behaviour was changed, so that any outstanding occurrences could be looked into. In a continuous process of improving FlightGear there's no point in keeping an 'undesired' (or, in some cases even a buggy) feature as being the default just because some unknown 3rd party software _might_ depend on it. If people don't feel like moving on with the times then they're free to use old versions of software. If they'd like to stay current, then they're going to adjust their 3rd party stuff accordingly. It's as simple as that, Martin. Aha, so all the aircraft that have been developed for FG, and without which FG would be pretty pointless (unless you only ever want to fly the C-172) are just unknown 3rd party stuff now then? LeeE -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Wednesday 10 Mar 2010, Stuart Buchanan wrote: On Wed, Mar 10, 2010 at 3:55 PM, leee wrote: There is always a risk associated with changing default behaviour and the bottom line is that there is no immediate need to do so, nor any overhead incurred by not doing so. This just seems like a commonsense policy to me, and was one of the factors that lead to me stopping work on FG. LeeE Would there be any value in searching the aircraft XML files in CVS to see how many are using the pi-simple-controller ? That might provide some idea of how much of an issue this is, though obviously doesn't address non-CVS aircraft. -Stuart This is exactly the sort of think I'd hope to see at the end of the transition/notification period and just before the default behaviour was changed, so that any outstanding occurrences could be looked into. I just greped through the current CVS aircraft and found the following results: 51 Aircraft and the generic-autopilot uses the pi-simple-controller 49 of these aircraft and the generic-autopilot uses the pi-simple-controller with a Ki of zero aka P-only the remaining 2 Aircraft use a pi-simple-controller with Ki greater than zero and u_min/u_max set. These two are potential candidates for windup errors. These two aircraft and the respective controllers are * b1900d: Vertical speed hold, Descent FPM and IAS hold * Citation-Bravo: Altitude Hold Stage 1 Looking at the A/P configuration files, I assume that having antiwindup code enabled should do no harm but might stabilize these autopilots in case they run into a saturated condition. Torsten -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
leee wrote: On Wednesday 10 Mar 2010, Martin Spott wrote: In a continuous process of improving FlightGear there's no point in keeping an 'undesired' (or, in some cases even a buggy) feature as being the default just because some unknown 3rd party software _might_ depend on it. If people don't feel like moving on with the times then they're free to use old versions of software. If they'd like to stay current, then they're going to adjust their 3rd party stuff accordingly. Aha, so all the aircraft that have been developed for FG, and without which FG would be pretty pointless (unless you only ever want to fly the C-172) are just unknown 3rd party stuff now then? Aircraft in CVS are easily fixed during the development cycle, thus are likely to be working as expected until the next release (if they fail at all, which is expected to be very unlikely). The maintainers of 3rd party collections are having plenty of time until the next release to get their stuff adjusted accordingly. There's no point in trying to prevent people from improving FlightGear as long you don't identify a _real_ issue, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
On Wed, 10 Mar 2010, leee wrote: On Wednesday 10 Mar 2010, Martin Spott wrote: leee wrote: On Wednesday 10 Mar 2010, Stuart Buchanan wrote: That might provide some idea of how much of an issue this is, though obviously doesn't address non-CVS aircraft. This is exactly the sort of think I'd hope to see at the end of the transition/notification period and just before the default behaviour was changed, so that any outstanding occurrences could be looked into. In a continuous process of improving FlightGear there's no point in keeping an 'undesired' (or, in some cases even a buggy) feature as being the default just because some unknown 3rd party software _might_ depend on it. If people don't feel like moving on with the times then they're free to use old versions of software. If they'd like to stay current, then they're going to adjust their 3rd party stuff accordingly. It's as simple as that, Martin. Aha, so all the aircraft that have been developed for FG, and without which FG would be pretty pointless (unless you only ever want to fly the C-172) are just unknown 3rd party stuff now then? Do you deliberately twist what people say just so you have something to argue about? How many times does it need to be explained to you that the system involved is explicitly designed to prevent unwanted behavior? If there is something out there that is broken because of the limits imposed, then it's not FlightGear's problem. The designer did it wrong. They need to fix it. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Download Intel#174; 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
Re: [Flightgear-devel] anti windup for the pi-simple-controller
I just greped through the current CVS aircraft and found the following results: 51 Aircraft and the generic-autopilot uses the pi-simple-controller 49 of these aircraft and the generic-autopilot uses the pi-simple-controller with a Ki of zero aka P-only the remaining 2 Aircraft use a pi-simple-controller with Ki greater than zero and u_min/u_max set. These two are potential candidates for windup errors. These two aircraft and the respective controllers are * b1900d: Vertical speed hold, Descent FPM and IAS hold * Citation-Bravo: Altitude Hold Stage 1 Looking at the A/P configuration files, I assume that having antiwindup code enabled should do no harm but might stabilize these autopilots in case they run into a saturated condition. Torsten After some testing, I am confident the modification won't break any existing aircraft in CVS. So I have just commited the patch. I sent a private mail to syd adams as the author of the only two aircraft that use pi-simple-controllers as described above, giving him a heads up. Thanks for your comments Torsten -- Download Intel#174; 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
