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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
