[Flightgear-devel] 2D-Panel for 707
Hi all, just for your information. I'm still working on a 2D-panel for the 707: http://wunderhg.homepage.t-online.de/fgfs-screen-016.jpg In the next weeks, I will release a first version. Kind regards Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug the next
Hans-Georg Wunder wrote: Jeff McBride wrote: The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=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 I see your point. In saturation the relation between P-Part, I-Part and D-part seems to be changed. I will verify that in the next days. Hans-Georg I have set the controller in debug mode and extracted the the values for P I and D. Every line is double, I don't know why. P:-0.1 I:-0.00058 D:-0 output = -0.100583 P:-0.1 I:-0.00058 D:-0 output = -0.100583 -- step to 0.1 P:-0 I:-0.00058 D:-0 output = -0.101167-- output is increasing due to I P:-0 I:-0.00058 D:-0 output = -0.101167 P:-0 I:-0.00058 D:-0 output = -0.10175 P:-0 I:-0.00058 D:-0 output = -0.10175 P:-0 I:-0.00067 D:-0 output = -0.102417 P:-0 I:-0.00067 D:-0 output = -0.102417 P:-0 I:-0.0005 D:-0 output = -0.102917 P:-0 I:-0.0005 D:-0 output = -0.102917 P:-0 I:-0.00058 D:-0 output = -0.1035 P:-0 I:-0.00058 D:-0 output = -0.1035 P:-0 I:-0.00058 D:-0 output = -0.104083 P:-0 I:-0.00058 D:-0 output = -0.104083 P:-0 I:-0.00058 D:-0 output = -0.104667 P:-0 I:-0.00058 D:-0 output = -0.104667 P:-0 I:-0.00067 D:-0 output = -0.105333 P:-0 I:-0.00067 D:-0 output = -0.105333 P:-0 I:-0.00058 D:-0 output = -0.105917 P:-0 I:-0.00058 D:-0 output = -0.105917 P:-0 I:-0.00058 D:-0 output = -0.1065 P:-0 I:-0.00058 D:-0 output = -0.49625 P:-0 I:-0.00058 D:-0 output = -0.49625 P:-0 I:-0.00058 D:-0 output = -0.496833 P:-0 I:-0.00058 D:-0 output = -0.496833 P:-0 I:-0.00058 D:-0 output = -0.497417 P:-0 I:-0.00058 D:-0 output = -0.497417 P:-0 I:-0.00058 D:-0 output = -0.498 P:-0 I:-0.00058 D:-0 output = -0.498 P:-0 I:-0.00058 D:-0 output = -0.498583 P:-0 I:-0.00058 D:-0 output = -0.498583 P:-0 I:-0.00067 D:-0 output = -0.49925 P:-0 I:-0.00067 D:-0 output = -0.49925 P:-0 I:-0.0005 D:-0 output = -0.49975 P:-0 I:-0.0005 D:-0 output = -0.49975 P:-0 I:-0.00067 D:-0 output = -0.5 -- Saturation, every thing is fine P:-0 I:-0.00067 D:-0 output = -0.5 P:-8.32639e-05 I:-0.0005D:-0 output = -0.5 P:-8.32639e-05 I:-0.0005 D:-0 output = -0.5 P:-0.000116517 I:-0.00058 D:-0 output = -0.5 I don't know where the P-part comes from P:-0.000116517 I:-0.00058 D:-0 output = -0.5 P:-0.000139774 I:-0.00058 D:-0 output = -0.5 P:-0.000139774 I:-0.00058 D:-0 output = -0.5 P:-0.000144413 I:-0.00058 D:-0 output = -0.5 P:-0.000144413 I:-0.00058 D:-0 output = -0.5 P:-0.000145338 I:-0.00058 D:-0 output = -0.5 P:-0.000145338 I:-0.00058 D:-0 output = -0.5 P:-0.000145522 I
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
Andy Ross wrote: Hans-Georg Wunder wrote: In the package there is a GPL-license. If this is enough, then everything is OK regarding the panel. Unfortunately, due to clear evidence of (minor, admittedly) copyright violation, this is not enough. The issue isn't license compatibility, it is copyright ownership. John Carty cannot legally grant a license to artwork he does not own. We need to be 100% sure that the people granting the license (GPL or otherwise) own the copyright. I wrote John a mail and told him, what Iam going to do, but I got no answer. At this point, I think a statement from Mr. Carty is really the only thing that will be acceptable. It's possible he didn't understand the rules, and generated some of the artwork via screenshots of other aircraft in MSFS. That's a showstopper for us. Now there three ways to go to get the panel GPL compliant: 1. To write a mail to Mr. carty an wait for an anwser (I got no anwser to my first mail, so I only have a small hope) 2. To repaint the parts I took from the package There I have one questions: When I go to the aircarft museum and take some cockpit photos. Can I use them for panel painting (like the 737 panel) ?? Is someone out there who has a 707 panel photo me ; ?? (There is no aircraft museum in Germany with a 707, AFAIK) - Do we have a place to store aircrafts with uncompliant aircrafts ??? Kind regards Hans-Georg Obviously Innis's model and FDM configuration are fine. But my strong suggestion is not to commit the panel until we can trace the history of every image in it. Andy ___ 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?
Roy Vegard Ovesen wrote: On Thursday 29 September 2005 13:51, Hans-Georg Wunder wrote: Time, reference,input,output 09:10:00,0,0,0 09:10:01,0.6,0,-0.4999 Jump into saturation. Thats OK. Only a P-Part, no I-Part 09:10:02,0.6,0,-0.4999 snip! 09:10:13,0.6,0,-0.4999 09:10:15,0,0,0.0999Here the output value should return to zero, because there is no I-Part Maybe it should?! In this example, the output flips from the min saturation to max-saturation. In a two phase controller (climb - altitude), it impossible to control the aircraft. Are you saying that it's not possible to make cascade configurations? We've had cascade configurations since day one! The problem is, that the change of input is store in ep_n. Only the changes are given to the output. But in saturation the change is not given to the output because of the windup logic The controller gets out of sync Same test with delta_u_n =u_max - u_n_1 and ep_n = (ep_n * u_max )/(delta_u_n+ u_n_1 ); (My solution. Meanwhile I think it is not necessary to change the edf_n-value, because the windup logic is for the integrator part, but I am not completly convinced. snip! This should work in any situation. Of course I can not deny the fact that your altering of ep_n does return the output closer to zero in one time step for the open loop case, but what about the closed loop case? Open loop PID controllers are really useless. Does this altering of ep_n improve the performance when used in closed loop controllers? A simple closed loop consists of a controller and a plant and a feedback. It is one common way to describe the controller with the answer of step a function in an open loop configuration. I think that some of the problems that your tests expose can be traced back to the fact that you use an open loop configuration. I suggest that you do some tests with closed loop controllers to see if there is any performance gain. I also suggest that you fiddle around with the beta value, try setting it to zero. PS! I'm a bit disappointed by the BESTune application. I seems that the demo version is able to recognize the original input data, and when you try to change them it barks that it don't want to use anything but the _original_ input data. It does display the custom input data, but it does not seem to calculate useable values for Kp, Ti and Td. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug
Jeff McBride wrote: The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=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 I see your point. In saturation the relation between P-Part, I-Part and D-part seems to be changed. I will verify that in the next days. Hans-Georg ___ 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 =?iso-8859-1?q?Bug??=
Roy Vegard Ovesen wrote: På 29.09.2005 00:47 CEST skrev Hans-Georg Wunder Behaviour with delta_u_n = 0 and an input jump function of 0.6 Saturation at the beginning o Time, reference,input,output 21:56:54,0,0,0 21:56:55,0,0,0 21:56:56,0,0,0 21:56:57,0,0,0 21:56:58,0,0,0 21:56:59,0,0.6,0.02549 Here the P-part is missing There has to be a jump to u_max You should not set the input to 0.6. You should set the reference to 0.6. The input is the process value, and the reference is the set point. You can not set the process value directly. If you could then you would not need a controller at all ;-). The test is done in an open loop configuration. The only difference between the input value and the reference value is the sign. Here the test results with the step response of the reference Same test with change of the reference value. Time, reference,input,output 08:51:03,0,0,0 08:51:04,0,0,0 08:51:05,0,0,0 08:51:06,0,0,0 08:51:07,0.6,0,-0.0195 Jump to 0.6 into saturation, output is negative due to Kp=-1 08:51:08,0.6,0,-0.08006P-Part ist missing 08:51:09,0.6,0,-0.14050001 08:51:10,0.6,0,-0.2011 08:51:11,0.6,0,-0.26150002 08:51:12,0.6,0,-0.32250002 08:51:13,0.6,0,-0.3833 08:51:14,0.6,0,-0.44350003 08:51:15,0.6,0,-0.4994 08:51:16,0.6,0,-0.4994 In your example here it does not matter, results would have been similar if you set the reference to 0.6. But you have to remember this when you use live values with your controllers. The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=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 is still 0.6: 0.6 (0.5 - 0.5) : true delta_u_n = 0.5 - 0.5 = 0.0 u_n = 0.5 + 0.0 = 0.5 u_n jumps to u_max and stays there as long as delta_u_n is positive. With this patch, the controller gets out of sync. Here the test results. But only, when the windup is used. Sorry, that it is so long. Behaviour with delta_u_n =u_max - u_n_1 (Patch fromj Erik) and an input jump function on the reference input of 0.2. Not Saturation at the beginning Time, reference,input,output 08:50:46,0,0,0 08:50:47,0,0,0 08:50:48,0,0,0 08:50:49,0,0,0 08:50:50,0,0,0 08:50:51,0.2,0,-0.2088 P-Part 08:50:52,0.2,0,-0.2291667 Integrator-Part 08:50:53,0.2,0,-0.24983339 08:50:54,0.2,0,-0.27016668 08:50:55,0.2,0,-0.2904 08:50:56,0.2,0,-0.31116659 08:50:57,0.2,0,-0.33133323 08:50:58,0.2,0,-0.35149986 08:50:59,0.2,0,-0.37216648 08:51:00,0.2,0,-0.39266644 Here the reference value changed from 0.2 to 0 08:51:01,0,0,-0.21149975 There the P-Part = 0 ond we only the the I-Part 08:51:02,0,0,-0.21149975 08:51:03,0,0,-0.21149975 08:51:04,0,0,-0.21149975 08:51:05,0,0,-0.21149975 08:51:06,0,0,-0.21149975 08:51:07,0,0,-0.21149975 08:51:08,0,0,-0.21149975 08:51:10,0,0,-0.21149975 08:51:11,0,0,-0.21149975 08:51:12,0,0,-0.21149975 08:51:13,0,0,-0.21149975 08:51:14,0,0,-0.21149975 08:51:15,0,0,-0.21149975 08:51:16,0,0,-0.21149975 08:51:17,0,0,-0.21149975 08:51:18,0,0,-0.21149975 08:51:19,0,0,-0.21149975 08:51:20,0,0,-0.21149975 08:51:21,-0.2,0,-0.0061664115 Here the reference value change from 0 to 0.2 08:51:22,-0.2,0,0.014166921The P-Part is added to the output value 08:51:23,-0.2,0,0.034500255The I-Part is added to the output value 08:51:24,-0.2,0,0.054833595 08:51:25,-0.2,0,0.075333593 08:51:26,-0.2,0,0.095666916 08:51:27,-0.2,0,0.11616691 08:51:28,-0.2,0,0.13683358 08:51:29,-0.2,0,0.15716694 08:51:30,-0.2,0,0.17766697 08:51:31,-0.2,0,0.19833365 08:51:32,-0.2,0,0.21866701 08:51:33,-0.2,0,0.23900037 08:51:34,-0.2,0,0.25966703 08:51:35,-0.2,0,0.2832 08:51:36,-0.2,0,0.30016693 08:51:37,-0.2,0,0.32083356 08:51:38,-0.2,0,0.34100019 08:51:39,-0.2,0,0.36150015 08:51:40,-0.2,0,0.38200011 08:51:41,-0.2,0,0.40266674 08:51:42,-0.2,0,0.4231667 08:51:43,0,0,0.2318Here the reference value change from -0.2 to 0 08:51:44,0,0,0.2318The P-Part is subtracted and we have only the I-Part 08:51:45,0,0,0.2318 08
[Flightgear-devel] Transfer function elevator/climb for root locus analyse for JSBSIM
Hello all, is it possible to derive the transfer function from jsbsim fdm coefficients. I know the way to calculate the parameters like Clalpha for a operation point. But for a root locus analyse I need the transfer function (Root locus is used to calculate the PID-Controller parameter) I would like to start with a function, which descripe the dependency of climb to elevator deflection climb = f(elevator-deflection) I want to use SCILAB (free matlab ;)) to analyse the close-loop behaviour. Any help will be appreciated Kind regards Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 2D-Panel for the 707
Hi all, I adapted the 2D-panel of a 707 from George Carty for FlightGear and merged it with the 3D-Model of Innis Cunningham. Here are the results: http://wunderhg.homepage.t-online.de/707-KSFO.jpg http://wunderhg.homepage.t-online.de/707_27092005.tar.gz Next days I will create some docs, how to use the INS, . Feedback is welcome. Kind regards Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
Roy Vegard Ovesen wrote: On Wednesday 28 September 2005 21:03, Hans-Georg Wunder wrote: The original problem is, when there is an input change from 0 to u_max/kp, the output value is zero. This is wrong. It has to be u_max. The fix from Erik was also my first approach. But it does not solve the problem. Under some circumstances the controller stays in saturation for ever. If you tune the PID controller to be a P only controller (Ti=inf, Td=0) then this can happen because of steady state error that can not be reduced by a P only controller. Maybe I did not stress this enough in my last post on this subject: The velocity form of the PID controller should _not_ be used as a P only controller! I do not talk about a P only controller and about the steady state error of a P only controller. The error happens, when the input value is a step function, which drives the controller directly into the windup logic. Then the output value is zero. All other cases are working fine. I found a site with a good explanation of the PID equation: http://bestune.50megs.com/typeABC.htm There is no windup logic in these equations. The equation that most of the controllers in FlightGear autopilots use is the type B. The equations here are of the independent type. We use the dependent type, but that does not matter. Our PID equation is actually able to act as type A, through type B to type C. This is done with the gamma and beta values. Gamma is the weighing of the reference for the derivative error: ed_n = gamma * r_n - y_n. beta is the weighing for the proportional error: ep_n = beta * r_n - y_n. So for a type A controller we would set gamma = 1 and beta = 1. For the type B, gamma = 0 and beta = 1, and finally for type C, gamma = 0 and beta = 0. Notice that we have complete power over how much we want to weigh the reference value for the derivative and proportional error term. I think, my solution solves the problem, but it would be great, if Jeff is also able to test it. The guys at BESTune claims that the type C controller is the best. I suggest that you try setting beta = 0 to make you controllers type C. I'm sorry but I'm very sceptical to your idea of altering ep_n and ed_n on saturation. Also on BESTune's site they have a demo of their BESTune application. It's Windows only, but I'm very exited about this app. I'm going to try and test it this weekend. I suggest that you check it out too. I really think that it can prove to be very helpfull in tuning our controllers. First of all I will do some tests to clarify my problem and my solution. Thank you for your detailed answer Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
I hope, this description is not to long, but I think it is very
important to have a working controller code
First the test results, at the end you will find the test decription for
the test controller and a little nasal script for logging.
o Behaviour with delta_u_n = 0 and an input jump function of 0.2 No
saturation at the beginning.
Time, reference,input,output
21:59:17,0,0,0
21:59:18,0,0,0
21:59:19,0,0.2,0.2008 Here I changed the input value
from 0 to 0.2 and we see the proportionel gain of -1 (P-part)
21:59:20,0,0.2,0.22116665 Here the integrator part is added.
21:59:21,0,0.2,0.24149997
21:59:22,0,0.2,0.26183332
21:59:23,0,0.2,0.2822
21:59:24,0,0.2,0.30250005
21:59:25,0,0.2,0.32283342
21:59:26,0,0.2,0.34283345
21:59:27,0,0.2,0.36316682
21:59:28,0,0.2,0.38350018
21:59:29,0,0.2,0.40383355
21:59:30,0,0.2,0.42433358
21:59:31,0,0.2,0.44466694
21:59:32,0,0.2,0.46500031
21:59:33,0,0.2,0.48533367
21:59:34,0,0.2,0.49950036 Here the windup logic limits the
output value to 0.5
21:59:35,0,0.2,0.49950036
21:59:36,0,0.2,0.49950036
21:59:37,0,0.2,0.49950036
21:59:38,0,0.2,0.49950036
21:59:39,0,0.2,0.49950036
21:59:40,0,0.2,0.49950036
21:59:41,0,0.2,0.49950036
21:59:42,0,0.2,0.49950036
21:59:43,0,0.2,0.49950036
21:59:44,0,0.2,0.49950036
21:59:45,0,0.2,0.49950036
Everything is fine !
Behaviour with delta_u_n = 0 and an input jump function of 0.6
Saturation at the beginning
o Time, reference,input,output
21:56:54,0,0,0
21:56:55,0,0,0
21:56:56,0,0,0
21:56:57,0,0,0
21:56:58,0,0,0
21:56:59,0,0.6,0.02549 Here the P-part is missing There
has to be a jump to u_max
21:57:00,0,0.6,0.08803
21:57:01,0,0.6,0.15050001
21:57:02,0,0.6,0.2131
21:57:03,0,0.6,0.2732
21:57:04,0,0.6,0.33350002
21:57:05,0,0.6,0.39350003
21:57:06,0,0.6,0.4533
21:57:07,0,0.6,0.49950004
Kind regards
Hans-Georg
P.S.: The test result for delta_u_n = u_max - U
Test controller:
pid-controller
nameTest controller/name
debugfalse/debug
enable
prop/autopilot/test/status/prop
valuego/value
/enable
input
prop/autopilot/test/input/prop
/input
reference
prop/autopilot/test/reference/prop
/reference
output
prop/autopilot/test/output/prop
/output
config
Kp-1/Kp !-- proportional gain --
beta1/beta !-- input value weighing factor --
alpha1/alpha !-- low pass filter weighing factor --
gamma0.0/gamma !-- input value weighing factor for --
!-- unfiltered
derivative error --
Ti1/Ti!-- integrator time --
Td0/Td !-- derivator time --
u_min-0.5/u_min !-- minimum output clamp --
u_max0.5/u_max !-- maximum output clamp --
/config
/pid-controller
For logging puposes I wrote a little nasal script:
#
# Function to log
#
print_test = func {
ref_log= getprop(/autopilot/test/reference);
input_log = getprop(/autopilot/test/input);
output_log = getprop(/autopilot/test/output);
time_log = getprop(/sim/time/gmt-string);
print(time_log,,,ref_log,,, input_log,,,output_log);
# Re-schedule the next call
if(getprop(/autopilot/test/status) != go) {
print(Log disabled);
} else {
#print(Set timer);
settimer(print_test,1);
}
}
Kind regards
Hans-Georg
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
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
[Flightgear-devel] Bug or feature in xmlauto.cxx ?
Hi all,
I try to configure a P-Controller, but I have problems with the
anti-windup logic:
My controller looks like this
pid-controller
nameTest controller/name
debugtrue/debug
enable
prop/autopilot/test/status/prop
valuego/value
/enable
input
prop/autopilot/test/input/prop
/input
reference
prop/autopilot/test/reference/prop
/reference
output
prop/autopilot/test/output/prop
/output
config
Kp-1/Kp!-- proportional gain --
beta1/beta !-- input value weighing factor --
alpha1/alpha !-- low pass filter weighing factor --
gamma0.0/gamma !-- input value weighing factor for --
!-- unfiltered derivative error --
Ti0/Ti !-- integrator time --
Td0/Td!-- derivator time --
u_min-100.0/u_min !-- minimum output clamp --
u_max100.0/u_max !-- maximum output clamp --
/config
/pid-controller
When I change the input value from 0 to to 150, the output value is 0
Updating Test controller
input = 0 ref = 0
ep_n = 0 ep_n_1 = 0 e_n = 0 ed_n = 0 delta_u_n = -0
P:-0 I:nan D:-0
output = 0
Updating Test controller
input = 0 ref = 0
ep_n = 0 ep_n_1 = 0 e_n = 0 ed_n = 0 delta_u_n = -0
P:-0 I:nan D:-0
output = 0
Updating Test controller
input = 150 ref = 0
ep_n = -150 ep_n_1 = 0 e_n = -150 ed_n = -150 delta_u_n = 150
P:150 I:inf D:0
max saturation
output = 0
Updating Test controller
input = 150 ref = 0
ep_n = -150 ep_n_1 = -150 e_n = -150 ed_n = -150 delta_u_n = -0
P:-0 I:inf D:-0
output = 0
Updating Test controller
input = 150 ref = 0
ep_n = -150 ep_n_1 = -150 e_n = -150 ed_n = -150 delta_u_n = -0
P:-0 I:inf D:-0
output = 0
Updating Test controller
input = 150 ref = 0
ep_n = -150 ep_n_1 = -150 e_n = -150 ed_n = -150 delta_u_n = -0
P:-0 I:inf D:-0
output = 0
Now u_n_1 = 0, so delta_u_n = 150 and greater as u_max,
and then u_n = 0 + 0 = 0. The controller does not work.
// 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;
}
// Calculates absolute output:
u_n = u_n_1 + delta_u_n;
if ( debug ) coutoutput = u_n endl;
I think, this is not okay. delta_u_n = 0; has to be replaced by
something like that
delta_u_n=u_max - u_n_1;
But that's not enough. The value of ep_n also has to be changed,
but I do not know how. Any ideas ?
Kind regards
Hans-Georg
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3 USB Joysticks CH
Hi, as far as I know, they are not supported by the standard kernel. I am using the 2.4.27 and I have had the same problem. You have to apply a patch. Look at this http://baron.flightgear.org/pipermail/flightgear-users/2003-January/003401.html and this http://www.qbik.ch/usb/devices/showdev.php?id=211 With the patch everything works great Kind regards Hans-Georg Luuk van Hal wrote: I'm still using Red Hat 8.0 on kernel 2.4.24 with 3 joysticks from CH products on a Sweex usb 2.0 hub. /usr/src/make xconfig support for usb (usbcore.o) -- Y Preliminary USB device filesystem -- Y EHCI HCD -- Y UHCI alternate driver (JE) -- Y USB full HID support -- Y HID Input layer support -- Y Input core support -- Y Joystick support -- Y lsmod: Module Size Used by rtnet 53768 0 rtai_rtdm 12900 0 [rtnet] rtai_shm 7368 0 (unused) rtai_fifos 17672 0 (unused) rtai_sched_up 48241 0 [rtnet rtai_rtdm] rtai 39616 2 [rtnet rtai_rtdm rtai_shm rtai_fifos rtai_sched_up] 3c59x 29552 1 mousedev 5492 1 dmesg | grep usb: usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb.c: new USB bus registered, assigned bus number 1 usb.c: new USB bus registered, assigned bus number 2 usb.c: new USB bus registered, assigned bus number 3 usb.c: new USB bus registered, assigned bus number 4 usb.c: new USB bus registered, assigned bus number 5 usb.c: registered new driver hid input: USB HID v1.00 Joystick [CH PRODUCTS CH PRO PEDALS USB ] on usb1:3.0 input: USB HID v1.00 Joystick [CH PRODUCTS CH THROTTLE QUADRANT] on usb1:4.0 input: USB HID v1.00 Joystick [CH PRODUCTS CH FLIGHT SIM YOKE USB ] on usb1:5.0 So far so good, I would say ...BUT ...this is the output of js_demo: Joystick test program. ~~ Joystick 0 not detected Joystick 1 not detected Joystick 2 not detected Joystick 3 not detected Joystick 4 not detected Joystick 5 not detected Joystick 6 not detected Joystick 7 not detected I've tried every possible combination of modules concerning usb and joysticks but I can't get any of the USB joysticks to work. Can someone tell me why these joysticks don't work while they are installed correctly. ___ 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] Re:update_helper() getting hairy (was:Nav0/Nav1 course tracking and ILS approach)
Now I am able to follow the ILS. Is this a bug in flightgear, or do I have the wrong understanding and do I use the wrong properties I think that adding more helpers to the autopilot like this will grow into a big hairy mess. I say we move the helpers into the instruments where they belong: the heading bug into the heading indicator, the nav stuff into the navradio, etc. From my side there is no preference, where those helpers are located. I found them under the autpilot-property-node and for me that's not wrong. If you want to locate them into the instruments, do it :) Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Atlas release candidate
Hello David, I just compiled the new Atlas-version on my Linux-Box (Debian 3.1) and it works great. I have had no compile-problems and the maps are looking very nice. With the new version I am able to visit foreign airports without additionnel enroute and approach charts. Great. One question I have: With the left key,I am able to move around on the map. But then I destroy the flight track. Is it a bug or just a missing feature ? The only thing I am missing is the multiplayer capability. Last week I flew with my daughter, each on a Linux box. But it was very difficult to fly together. Then I wanted to use atlas to have an overview, where we are. But that doesn't work. I would be great to have to ports where atlas is listening. Kind regards Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nav0/Nav1 course tracking and ILS approach
Hi all,
for the A320-200 2D-panel I tried to activate the course tracking with
nav1. But it doesn't work. Then I checked the source and I found the
following in src/Autopilot/xmlauto.cxx
874 // Calculate nav1 target heading error normalized to +/- 180.0
875 static SGPropertyNode *target_nav1
876 = fgGetNode(
/instrumentation/nav[0]/radials/target-auto-hdg-deg, true );
When I replaced it with
876 = fgGetNode(
/instrumentation/nav[1]/radials/target-auto-hdg-deg, true );
everything works:
Then I added the same sequence for nav0
874 // Calculate nav0 target heading error normalized to +/- 180.0
875 static SGPropertyNode *target_nav0
876 = fgGetNode(
/instrumentation/nav[0]/radials/target-auto-hdg-deg, true );
877 static SGPropertyNode *true_nav0
878 = fgGetNode( /autopilot/internal/nav0-heading-error-deg,
true );
879 static SGPropertyNode *true_track_nav0
880 = fgGetNode( /autopilot/internal/nav0-track-error-deg, true );
881 diff = target_nav0-getDoubleValue() - true_hdg-getDoubleValue();
882 if ( diff -180.0 ) { diff += 360.0; }
883 if ( diff 180.0 ) { diff -= 360.0; }
884 true_nav0-setDoubleValue( diff );
885
886
887 diff = target_nav0-getDoubleValue() - true_track-getDoubleValue();
888 if ( diff -180.0 ) { diff += 360.0; }
889 if ( diff 180.0 ) { diff -= 360.0; }
890 true_track_nav0-setDoubleValue( diff );
My Contoller looks like this:
pid-controller
nameNav0 Hold Stage 1/name
debugfalse/debug
enable
prop/autopilot/locks/heading/prop
valuenav0-hold/value
/enable
input
prop/autopilot/internal/nav0-track-error-deg/prop
/input
reference
value0.0/value
/reference
output
prop/autopilot/internal/target-roll-deg/prop
/output
config
Kp-1.0/Kp!-- proportional gain --
beta1.0/beta !-- input value weighing factor --
alpha0.1/alpha !-- low pass filter weighing factor --
gamma0.0/gamma !-- input value weighing factor for --
!-- unfiltered derivative error --
Ti200.0/Ti !-- integrator time --
Td0.1/Td !-- derivator time --
u_min-30.0/u_min !-- minimum output clamp --
u_max30.0/u_max !-- maximum output clamp --
/config
/pid-controller
Now I am able to follow the ILS. Is this a bug in flightgear, or do I
have the wrong understanding and do I use the wrong properties
If it is a bug, it would be great, if someone is able to add the
corrections to the cvs. I can send the differencies, but I do not know
the exact diff-command.
Kind regards
Hans-Georg
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2D-Panel for A320
David Culp wrote: I started to create a 2D-panel for the A320. ... But now i got stuck, because I have 3 questions: Nice work Hans-Georg! It seems to me that the FlightGear developers who have OpenGL experience have lost interest in the 2D panel code some time ago, and their answer to you will be to switch to 3D panels. I prefer the 2D panels, so I'm hoping you know C++ and OpenGL? Unfortunately I have no concept of OpenGl, but I will do some research on the net if it is a common OpenGl problem or if it is flightgear/simgear related But what's about some Nasal specialists :). I want to enter a waypoint in the MCDU (no problem) and then pass this waypoint to the route manager (like in Autopilot - Add Waypoint). Is there someone who knows how to invoke a C++ Thanks for help Hans-Georg Dave ___ 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
[Flightgear-devel] 2D-Panel for A320
Hi all, I started to create a 2D-panel for the A320. First I send this Email to the Users lists, but there I got the hint to send it to the devel-list. Here I am Here is the first shot: http://home.t-online.de/home/wunder.hans-georg/A320-200_31012005.jpg You can download it from : http://home.t-online.de/home/wunder.hans-georg/A320-200_31012005.tar.gz You also need to install the 747, because the A320-modell refers to it. But now i got stuck, because I have 3 questions: - How can I pass a waypoint to the route-manager with Nasal ? (I want to enter the waypoint in the MCDU and pass it via Nasal to the route manager) - How can I display only a part of the speed ribbon ? - How can I improve the fonts ? (I am using Linux. I saw in the afternoon, the the fonts are much better under windows) Thank you for help. PS: Some details of the panel: Open items: Generell: - Bad fonts !!! - No photo-realistic textures - Dokumentation Primary flight display: - speed ribbon - altitude ribbon - speed marker - Vertical speed indictor Navigation display: - Incomplete LS-Mode - No VOR-Mode - No NAV-Mode - ARC-Mode incomplete - No PLAN-Mode EFIS-Control Panel - FCU- Flight Control Unit: - No Speed- and Auto-Throttle - No Course-Mode - No approach control Engine/Warning-Display: - Redesign is necessary - No warnings yet System Display: Only Flight Controls exist, but needs redesign MCDU: Connection between Route-Manager and MCDU and . and and... --- Primary Flight Display: - Autopilot displays Heading, Altitude, Waypoint - Indicated Airspeed, Altitude, --- Navigation Display ILS-Mode: Switch on EFIS-Control-Panel GS = Ground Speed = Heading DME = DME from NAV1, HOLD, NAV-2 NAV1/2-Freq = Switchable between standy and selected adjust direct on the NAV-Display ADF = Switchable between standy and selected adjust direct on the NAV-Display NAV/ADF Switch on EFIS-Control-Panel ARC-Mode: Switch on EFIS-Control-Panel NAV1= Switchable between standy and selected adjust direct on the NAV-Display ADF = Switchable between standy and selected adjust direct on the NAV-Display WPT = Waypoint name and distance - MCDU: Type the value in the scratch pad then transfer the value per Line select key in the corresponding field ON/OF = Switch ON/OFF INIT CO-Route= Company route (can be set) FUEL-PRED FOB CENTER = Fuel on board center tank (can be set) FOB LEFT= Fuel on board left wing (can be set) FOB RIGHT = Fuel on board right wing (can be set) FOB SUM = Fuel on sum CONSUMED= Fuel consumed since fuel set F-PLN Shows the entries of the route manager --- Engine Starter: RUN Indicates, wether the engines runs or not SEL You have to select the engines before you can start or stop it START Starts the engines, the CUTOFF switch has to be set The engine speeds up to 7 % N1, the you have to unset the CUT OFF switch Power Switch: Switches of the power. Not all instruments have a depency on this switch Autopilot: AltitudeWorks more or less Heading Works more or less Kind regards Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
