Re: [Flightgear-devel] PID Controller Bug?
Hello Jeff,
I found the same bug some days ago and I reported it here on the lists.
Your solution was also my first approach, but it did not work for the
Integrator-part. The value ep_n is wrong for the next cycle.
But after a looot of testing I found this solution:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
// We have to add the maxium, which is posibble and then
// to reduce the input value for the next cylcle accordingly
ep_n = (ep_n * u_max )/(delta_u_n+ u_n_1 );
if ( Td 0.0 ) edf_n = (edf_n * u_max ) / ( delta_u_n +
u_n_1 );
delta_u_n =u_max - u_n_1 ;
// delta_u_n = u_max - u_n_1;
// ep_n = delta_u_n / Kp;
//ep_n =- u_max/Kp;
if ( debug ) cout Max saturationNew delta_u_n =
delta_u_n New ep_n = ep_n ew edf_n = edf_n endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
// We have to add the maxium, which is posibble and then
// to reduce the input value for the next cylcle accordingly
ep_n = (ep_n * u_min )/( delta_u_n + u_n_1 );
if ( Td 0.0 ) edf_n = (edf_n * u_min ) /(delta_u_n +
u_n_1 ) ;
delta_u_n =u_min - u_n_1 ;
// delta_u_n = u_min - u_n_1;
// ep_n = delta_u_n / Kp;
//ep_n =- u_min/Kp;
if ( debug ) cout Min saturationNew delta_u_n =
delta_u_n New ep_n = ep_n New edf_n = edf_n endl;
}
I tested it for a P and a PI-controller. I haven't tested yet the
D-part, but I hope, it will work too
It would be nice, if you also could test this solution.
Feed back is welcome
Kind regards
Hans-Georg
Jeff McBride wrote:
I have been playing around with the autopilot this evening, and
noticed something that seems to me to be broken.
I ran into a problem where I would see a really large change in output
(delta_u_n) but the output would not change (yes, this probably also
means my gains need some adjusting), e.g.:
- From debug output ---
Updating Yaw Stabilization
input = 119.876 ref = 0.000610361
ep_n = -119.875 ep_n_1 = -118.088 e_n = -119.875 ed_n = -119.876 delta_u_n =
-2.96522
P:-0.268029 I:-2.69719 D:0
min saturation
output = 0.982904
---
So I checked the code in xmlauto.cxx and found that yes, these lines
were responsible for zeroing delta_u_n:
- From xmlauto.cxx
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout min saturation endl;
}
-
Perhaps I am not understanding this correctly (this PID controller is
not like any I have seen before), but it seems to me that it should
read:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = u_max - u_n_1; // --- CHANGED
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = u_min - u_n_1 // -- CHANGED
if ( debug ) cout min saturation endl;
}
-Jeff
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
I seem to recall Erik commited a change to the autopilot code in the
last week or so. Does that fix something? Did that introduce a new
problem? This is pretty subtle, complex code so people shouldn't be
messing with it too much unless they are really sure they know what's
going on with it.
Curt.
Hans-Georg Wunder wrote:
Hello Jeff,
I found the same bug some days ago and I reported it here on the
lists. Your solution was also my first approach, but it did not work
for the Integrator-part. The value ep_n is wrong for the next cycle.
But after a looot of testing I found this solution:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
// We have to add the maxium, which is posibble and then
// to reduce the input value for the next cylcle accordingly
ep_n = (ep_n * u_max )/(delta_u_n+ u_n_1 );
if ( Td 0.0 ) edf_n = (edf_n * u_max ) / ( delta_u_n +
u_n_1 );
delta_u_n =u_max - u_n_1 ;
// delta_u_n = u_max - u_n_1;
// ep_n = delta_u_n / Kp;
//ep_n =- u_max/Kp;
if ( debug ) cout Max saturationNew delta_u_n
= delta_u_n New ep_n = ep_n ew edf_n = edf_n
endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
// We have to add the maxium, which is posibble and then
// to reduce the input value for the next cylcle accordingly
ep_n = (ep_n * u_min )/( delta_u_n + u_n_1 );
if ( Td 0.0 ) edf_n = (edf_n * u_min ) /(delta_u_n +
u_n_1 ) ;
delta_u_n =u_min - u_n_1 ;
// delta_u_n = u_min - u_n_1;
// ep_n = delta_u_n / Kp;
//ep_n =- u_min/Kp;
if ( debug ) cout Min saturationNew delta_u_n
= delta_u_n New ep_n = ep_n New edf_n = edf_n
endl;
}
I tested it for a P and a PI-controller. I haven't tested yet the
D-part, but I hope, it will work too
It would be nice, if you also could test this solution.
Feed back is welcome
Kind regards
Hans-Georg
Jeff McBride wrote:
I have been playing around with the autopilot this evening, and
noticed something that seems to me to be broken.
I ran into a problem where I would see a really large change in output
(delta_u_n) but the output would not change (yes, this probably also
means my gains need some adjusting), e.g.:
- From debug output ---
Updating Yaw Stabilization
input = 119.876 ref = 0.000610361
ep_n = -119.875 ep_n_1 = -118.088 e_n = -119.875 ed_n = -119.876
delta_u_n =
-2.96522
P:-0.268029 I:-2.69719 D:0
min saturation
output = 0.982904
---
So I checked the code in xmlauto.cxx and found that yes, these lines
were responsible for zeroing delta_u_n:
- From xmlauto.cxx
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout min saturation endl;
}
-
Perhaps I am not understanding this correctly (this PID controller is
not like any I have seen before), but it seems to me that it should
read:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = u_max - u_n_1; // --- CHANGED
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = u_min - u_n_1 // -- CHANGED
if ( debug ) cout min saturation endl;
}
-Jeff
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] A little emergency encountered inside FlightGear
I was practicing landing the unlandable today, and ran into a little emergency. It is a bit amusing and I thought I'd share it with you guys. http://www.students.yorku.ca/~ampere/fgfs-screen-001.jpg http://www.students.yorku.ca/~ampere/fgfs-screen-003.jpg As you can see, there is a problem with the main landing gears on the 747. The bug appears again after I restarted FlightGear. I have never seen this happening until I updated my CVS version of SimGear and FlightGear yesterday. I haven't touched anything in the data directory, so I think this might be FlightGear/SimGear related. In addition, each time I press F3, two screenshots are made: one ordinary screenshot, and another with a dialog box which looks similar to this (http://www.students.yorku.ca/~ampere/fgfs-screen-004.jpg). As a side note, I made it safely back to the airport, braked, and taxied to the tarmac. Those who have had trouble braking on large jets may want to hold Shift+B on touch down. Provided that Caps-Lock is off, holding Shift+B will toggle the brake between on and off states, thus preventing the nose wheel from sinking into the runway. Enabling Caps-Lock and hold B alone will also work. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
Ahh, yes. I see your point. Since the change in output is based on change in error (not current error), if the amount of output shift is altered but the last error (ep_n_1) is not the two will effectively become out of sync. In fact, the same thing must have been happening when delta_u_n was being set to 0 when saturation occurred. But, the integral component should correct for this after a little bit. I am not convinced that you need to adjust edf_n, or that you should. IMHO, there is no reason that the rate of change information cannot be used when the controller is in saturation, and there is no way for the derivative error to wind-up. But I agree with your scaling of ep_n to match the change in output. Good call. It looks like Erik did commit a patch, and it looks like it does not include your adjustment to ep_n. So, it is still broken (though, I think it may be an improvement). I don't currently have a linux box to compile FG on, and I have not tackled the problem of compiling on Visual Studio, so I am unable to test this code at the moment (though I will have a linux box for development soon!). I appreciate all the development everyone has done, as I have found FG to be a great tool for both work and play. Hopefully I can find some way to contribute myself in the near future. -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little emergency encountered inside FlightGear
On Wednesday 28 September 2005 04:48, Ampere K. Hardraade wrote: In addition, each time I press F3, two screenshots are made: one ordinary screenshot, and another with a dialog box which looks similar to this (http://www.students.yorku.ca/~ampere/fgfs-screen-004.jpg). well, I hacked the code not to show those dialogs any more... could supply a patch if someone wants it :-) Thorben ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
