It would be great, if you also test the code. Hans-Georg
Jeff McBride wrote:
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 [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
