> The patch committed by Erik: > > http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19&r2=1.20&cvsroot=FlightGear-0.9 > > should fix this. This is what would happen when you set > delta_u_n = u_max - u_n_1 : > > delta_u_n > (u_max - u_n_1) > 0.6 > (0.5 - 0.0) : true > delta_u_n = u_max - u_n_1 = 0.5 - 0.0 = 0.5 > u_n = u_n_1 + delta_u_n = 0.0 + 0.5 = 0.5 > > and at the next time step let's assume that delta_u_n
But consider this scenario for next step: Assume Kp = 1. This means that the previous error e_n_1 = 0.6. Say the new error e_n = 0.5. delta_u_n = Kp(e_n - e_n_1) = -0.1 Now, this new delta when aplied to the saturated output will be: u_n = 0.5 - 0.1 = 0.4 ; The correct proportional component of the output should be 0.5 In the ideal scenario, the delta_u_n = -0.1 would be applied to u_n=0.6 to yield 0.5, but because of the saturation, the P component becomes offset. This offset will be compensated for by the I component after some time, but it shouldn't have to be. As I said before, I think the best solution is to track the "true" PID output (in this case 0.6) while outputing the saturated value and disable the integral component (with either a hard or soft limit) when the controller is saturated. Hans-Georg's suggested scaling of ep_n essentially fixes the problem. The one technical problem I have come to see with this approach is that it assumes that the entire output movement into saturation is due to the P part: ep_n = ep_n*u_max/(delta_u_n+u_n) This says that, for example, if the output only moved by half of the calculated increase because of saturation, we should change the current proportional position (saved in ep_n_1)to half its calculated value. This basically works because any large movements in one step are likely to be dominated by P, and in most (if not all) cases the error generated when the output moves back out of saturation is small and quickly compensated by the I part. I believe this is why the output of his latest test run using his fix returns to 0.0019 or 0.00175 after the reference is returned to 0, rather than returning to exactly u_n=0. Clearly this error is small and will not represent a proplem in this case. -Jeff _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
