Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Saturday 10 February 2007 01:08, gh.robin wrote: Hello Roy, I do not notice any differences regarding /autopilot/new-config dir between first load values (after FG loaded) and after reload autopilot. i get two pi-simple-controllers and sixteen pid-controllers. OK, you said that the heading hold in the dc3 was crazy. The dc3 uses the generic autopilot, then all aircraft using the generic autopilot should experience the same crazieness in heading hold mode. Could you try activating the debug option of the two pid-controllers that are used in heading hold mode? Open data/Aircraft/Generic/generic-autopilot.xml and set the debug flag to true for the controllers named Heading Bug Hold (DG based) Stage 1, and Heading Bug Hold (DG based) Stage 2. When you activate the heading hold mode you should get debug messages from those two controllers on the console. This is what I get when I'm in a left turn chasing the heading bug in the dc3 (# My comments): Updating Heading Bug Hold (DG based) Stage 1 Ts 0.0416667 input = -50.076 ref = 0 # We are -50.076 degrees from our desired heading. ep_n = 50.076 ep_n_1 = 50.1743 e_n = 50.076 ed_n = 50.076 Tf = 1e-06 edf_n = 50.076 delta_u_n = -0.110384 P:0.0982607 I:-0.20865 D:5.29441e-06 min saturation output = -20 # The controller has commanded a 20 degree left bank. Updating Heading Bug Hold (DG based) Stage 2 Ts 0.0416667 input = -16.6732 ref = -20 # We are currently at 16.6732 degrees left bank. ep_n = -3.32684 ep_n_1 = -3.34097 e_n = -3.32684 ed_n = 16.6732 Tf = 1e-06 edf_n = 16.6732 delta_u_n = 2.75638e-05 P:0.00141368 I:-0.00138618 D:6.68812e-08 output = -0.00296141 # This is the commanded aileron, a tiny bit of left aileron makes sense. # 0.03 seconds later: Updating Heading Bug Hold (DG based) Stage 1 Ts 0.033 input = -49.9996 ref = 0 ep_n = 49.9996 ep_n_1 = 50.076 e_n = 49.9996 ed_n = 49.9996 Tf = 1e-06 edf_n = 49.9996 delta_u_n = -0.09026 P:0.0764119 I:-0.15 D:-6.55459e-06 min saturation output = -20 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.033 input = -16.6844 ref = -20 ep_n = -3.31557 ep_n_1 = -3.32684 e_n = -3.31557 ed_n = 16.6844 Tf = 1e-06 edf_n = 16.6844 delta_u_n = 2.10212e-05 P:0.0011263 I:-0.00110519 D:-8.62141e-08 output = -0.00294038 As you can see the inputs and outputs to/from these controllers look reasonable. Are you getting crazy inputs and outputs when you try the same? And are you getting sane inputs and outputs after a autopilot reload? If you are getting crazy inputs and outputs, you should run fgfs in a debugger like ddd and step through the FGPIDController::update() method in source/src/Autopilot/xmlauto.cxx to see what is going on. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Sat, 2007-02-10 at 10:53 +0100, Roy Vegard Ovesen wrote: On Saturday 10 February 2007 01:08, gh.robin wrote: Hello Roy, I do not notice any differences regarding /autopilot/new-config dir between first load values (after FG loaded) and after reload autopilot. i get two pi-simple-controllers and sixteen pid-controllers. OK, you said that the heading hold in the dc3 was crazy. The dc3 uses the generic autopilot, then all aircraft using the generic autopilot should experience the same crazieness in heading hold mode. Just a random thought: the autopilot does not lock the controls out (and it shouldn't) so rudder inputs will make the heading hold wander. I fly with pedals, so I can really pull the nose off course when the autopilot is flying. Are the people experiencing problems with the autopilots using --auto-coordinate? Ron - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Sat 10 February 2007 10:53, Roy Vegard Ovesen wrote: On Saturday 10 February 2007 01:08, gh.robin wrote: Hello Roy, I do not notice any differences regarding /autopilot/new-config dir between first load values (after FG loaded) and after reload autopilot. i get two pi-simple-controllers and sixteen pid-controllers. OK, you said that the heading hold in the dc3 was crazy. The dc3 uses the generic autopilot, then all aircraft using the generic autopilot should experience the same crazieness in heading hold mode. Could you try activating the debug option of the two pid-controllers that are used in heading hold mode? Open data/Aircraft/Generic/generic-autopilot.xml and set the debug flag to true for the controllers named Heading Bug Hold (DG based) Stage 1, and Heading Bug Hold (DG based) Stage 2. When you activate the heading hold mode you should get debug messages from those two controllers on the console. This is what I get when I'm in a left turn chasing the heading bug in the dc3 (# My comments): Updating Heading Bug Hold (DG based) Stage 1 Ts 0.0416667 input = -50.076 ref = 0 # We are -50.076 degrees from our desired heading. ep_n = 50.076 ep_n_1 = 50.1743 e_n = 50.076 ed_n = 50.076 Tf = 1e-06 edf_n = 50.076 delta_u_n = -0.110384 P:0.0982607 I:-0.20865 D:5.29441e-06 min saturation output = -20 # The controller has commanded a 20 degree left bank. Updating Heading Bug Hold (DG based) Stage 2 Ts 0.0416667 input = -16.6732 ref = -20 # We are currently at 16.6732 degrees left bank. ep_n = -3.32684 ep_n_1 = -3.34097 e_n = -3.32684 ed_n = 16.6732 Tf = 1e-06 edf_n = 16.6732 delta_u_n = 2.75638e-05 P:0.00141368 I:-0.00138618 D:6.68812e-08 output = -0.00296141 # This is the commanded aileron, a tiny bit of left aileron makes sense. I have settled Heading Bug =180 autopilot does not work (crazy) I get messages here an extract .. Updating Heading Bug Hold (DG based) Stage 2 Ts 0.025 input = -0.129679 ref = 0 ep_n = 0.129679 ep_n_1 = 0.130254 e_n = 0.129679 ed_n = 0.129679 Tf = 1e-06 edf_n = 0.129679 delta_u_n = -2.51044e-05 P:-5.75163e-05 I:3.24197e-05 D:-7.7432e-09 output = 0.000684861 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -0.129309 ref = 0 ep_n = 0.129309 ep_n_1 = 0.129679 e_n = 0.129309 ed_n = 0.129309 Tf = 1e-06 edf_n = 0.129309 delta_u_n = -1.53979e-05 P:-3.69617e-05 I:2.15515e-05 D:1.23327e-08 output = 0.000669463 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -0.128936 ref = 0 ep_n = 0.128936 ep_n_1 = 0.129309 e_n = 0.128936 ed_n = 0.128936 Tf = 1e-06 edf_n = 0.128936 delta_u_n = -1.58609e-05 P:-3.73499e-05 I:2.14893e-05 D:-2.32856e-10 output = 0.000653603 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -0.12854 ref = 0 ep_n = 0.12854 ep_n_1 = 0.128936 e_n = 0.12854 ed_n = 0.12854 Tf = 1e-06 edf_n = 0.12854 delta_u_n = -1.81036e-05 P:-3.95257e-05 I:2.14234e-05 D:-1.30541e-09 output = 0.000635499 .. # 0.03 seconds later: Updating Heading Bug Hold (DG based) Stage 1 Ts 0.033 input = -49.9996 ref = 0 ep_n = 49.9996 ep_n_1 = 50.076 e_n = 49.9996 ed_n = 49.9996 Tf = 1e-06 edf_n = 49.9996 delta_u_n = -0.09026 P:0.0764119 I:-0.15 D:-6.55459e-06 min saturation output = -20 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.033 input = -16.6844 ref = -20 ep_n = -3.31557 ep_n_1 = -3.32684 e_n = -3.31557 ed_n = 16.6844 Tf = 1e-06 edf_n = 16.6844 delta_u_n = 2.10212e-05 P:0.0011263 I:-0.00110519 D:-8.62141e-08 output = -0.00294038 As you can see the inputs and outputs to/from these controllers look reasonable. Are you getting crazy inputs and outputs when you try the same? And are you getting sane inputs and outputs after a autopilot reload? And after reloading autopilot autopilot works I get messages Here an extract .. Updating Heading Bug Hold (DG based) Stage 1 Ts 0.017 input = -86.2699 ref = 0 ep_n = 86.2699 ep_n_1 = 86.3099 e_n = 86.2699 ed_n = 86.2699 Tf = 1e-06 edf_n = 86.2699 delta_u_n = -0.103803 P:0.0399801 I:-0.143783 D:1.29082e-08 min saturation output = -20 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -17.7823 ref = -20 ep_n = -2.21771 ep_n_1 = -2.22147 e_n = -2.21771 ed_n = 17.7823 Tf = 1e-06 edf_n = 17.7823 delta_u_n = 6.21317e-06 P:0.000375831 I:-0.000369619 D:9.22063e-10 output = -0.00492783 Updating Heading Bug Hold (DG based) Stage 1 Ts 0.017 input = -86.2299 ref = 0 ep_n = 86.2299 ep_n_1 = 86.2699 e_n = 86.2299 ed_n = 86.2299 Tf = 1e-06 edf_n = 86.2299 delta_u_n = -0.103755 P:0.039962 I:-0.143717 D:-1.08567e-08 min saturation output = -20 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -17.7861 ref = -20 ep_n = -2.21394 ep_n_1 = -2.21771 e_n = -2.21394 ed_n = 17.7861 Tf = 1e-06 edf_n = 17.7861 delta_u_n =
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Sunday 11 February 2007 00:29, gh.robin wrote: I have settled Heading Bug =180 autopilot does not work (crazy) I get messages here an extract .. Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -0.128936 ref = 0 ep_n = 0.128936 ep_n_1 = 0.129309 e_n = 0.128936 ed_n = 0.128936 Tf = 1e-06 edf_n = 0.128936 delta_u_n = -1.58609e-05 P:-3.73499e-05 I:2.14893e-05 D:-2.32856e-10 output = 0.000653603 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -0.12854 ref = 0 ep_n = 0.12854 ep_n_1 = 0.128936 e_n = 0.12854 ed_n = 0.12854 Tf = 1e-06 edf_n = 0.12854 delta_u_n = -1.81036e-05 P:-3.95257e-05 I:2.14234e-05 D:-1.30541e-09 output = 0.000635499 .. The autopilot is holding the wings level, right. I think characterizing this as crazy is very misleading. One might think that it was turning left and right. And after reloading autopilot autopilot works I get messages Here an extract .. Updating Heading Bug Hold (DG based) Stage 1 Ts 0.017 input = -86.2699 ref = 0 ep_n = 86.2699 ep_n_1 = 86.3099 e_n = 86.2699 ed_n = 86.2699 Tf = 1e-06 edf_n = 86.2699 delta_u_n = -0.103803 P:0.0399801 I:-0.143783 D:1.29082e-08 min saturation output = -20 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 input = -17.7823 ref = -20 ep_n = -2.21771 ep_n_1 = -2.22147 e_n = -2.21771 ed_n = 17.7823 Tf = 1e-06 edf_n = 17.7823 delta_u_n = 6.21317e-06 P:0.000375831 I:-0.000369619 D:9.22063e-10 output = -0.00492783 ... I can notice with the first example (before reload) only stage2 gives messages With second example (after reload) with autopilot working i do have both stage1 and stage2 It looks like the stage 1 controller fails to initialize at startup. Is this consistent, or are you, like Lee was, seeing some randomness in what controllers aren't working before autopilot reload? If you are getting crazy inputs and outputs, you should run fgfs in a debugger like ddd and step through the FGPIDController::update() method in source/src/Autopilot/xmlauto.cxx to see what is going on. Because i am not developer , i will not be able to do it Sure you can! ;-) -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Sun 11 February 2007 01:01, Roy Vegard Ovesen wrote: On Sunday 11 February 2007 00:29, gh.robin wrote: The autopilot is holding the wings level, right. I think characterizing this as crazy is very misleading. One might think that it was turning left and right. Yes , in that case crazy is not good, but randomly i can get some uncontrolled movements, like start to turn keeping that turn permanently or turn left then turn right, then lost stability and crash on the ground. It looks like the stage 1 controller fails to initialize at startup. Is this consistent, or are you, like Lee was, seeing some randomness in what controllers aren't working before autopilot reload? To me it is consistent, i get only stage 2 , i did not noticed some randomness. If you are getting crazy inputs and outputs, you should run fgfs in a debugger like ddd and step through the FGPIDController::update() method in source/src/Autopilot/xmlauto.cxx to see what is going on. Because i am not developer , i will not be able to do it Sure you can! ;-) I confirm i can't Regards -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
I couldn't see a parameter to enable dynamic view in the command line but it seemed ok if I enabled it via the menu. The view pitched a small amount when I enabled it and pitched back when I disabled it. LeeE On Friday 09 February 2007 20:51, Maik Justus wrote: Hi LeeE, can you start flightgear with the bo105 and dynamic-view enabled? If the view direction is ok during the first second or is it spinning around? Maybe this bug has a similar cause. Maik leee schrieb am 09.02.2007 20:22: On Friday 09 February 2007 19:04, Roy Vegard Ovesen wrote: I just tried the dc3. Heading hold is working perfectly. Could there be something on your and Lee's system that is causing this? I tried the first time you reported this issue, and was unable to reproduce what you saw then too. Are anyone else on this list seeing the problems that Lee and Gérard are seeing? It's difficult to imagine a system problem that might cause this behaviour, in view of the fact that resetting appears to fix the problem. However, I know that there are a few problems that I've seen here that no one else appears to have experienced on their systems, one long running example being problems with the wind and visibility settings not being honoured. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Saturday 10 February 2007 16:04, Ron Jensen wrote: On Sat, 2007-02-10 at 10:53 +0100, Roy Vegard Ovesen wrote: On Saturday 10 February 2007 01:08, gh.robin wrote: Hello Roy, I do not notice any differences regarding /autopilot/new-config dir between first load values (after FG loaded) and after reload autopilot. i get two pi-simple-controllers and sixteen pid-controllers. OK, you said that the heading hold in the dc3 was crazy. The dc3 uses the generic autopilot, then all aircraft using the generic autopilot should experience the same crazieness in heading hold mode. Just a random thought: the autopilot does not lock the controls out (and it shouldn't) so rudder inputs will make the heading hold wander. I fly with pedals, so I can really pull the nose off course when the autopilot is flying. Are the people experiencing problems with the autopilots using --auto-coordinate? Ron Not here. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Sun, 2007-02-11 at 00:16 +, leee wrote: I couldn't see a parameter to enable dynamic view in the command line but it seemed ok if I enabled it via the menu. The view pitched a small amount when I enabled it and pitched back when I disabled it. LeeE Dynamic view from the command line: --prop:/sim/view/dynamic/enabled=1 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 02:54, Dave Perry wrote: On Fri, 2007-02-09 at 00:25 +, leee wrote: Just checked again, with current cvs osg/simgear/flightgear, and I still got the same problems. As before, re-setting the A/P via the menu seems to kick everything into life. There also seems to be a random element to this problem - in half a dozeeen tests, most of the time it was the same controllers that seemed not to be working but in two tests there seemed to be a couple of additional ones that didn't want to play. The power check I added to kap140.nas moves the call to initialize the autopilot (apInit) to inside the apPower loop. apPower is called by a setlistener that monitors power=/systems/electrical/outputs/autopilot to makes sure there is power to the autopilot before starting the power monitor apPower to prevent a nil used in numeric context nasal error. I believe that the problem Gérard and Lee has seen is not specific to the KAP140 autopilot. apInit in kap140.nas _only_ initializes the properties that belong to the KAP140 autopilot. The initialization that Durk is talking about is certainly not the same as apInit. So far I have been unable to reproduce this. Lee and Gérard, could you please tell us what aircraft you are seeing this with. Is it aircraft that use the generic autopilot and/or aircraft that use a customized autopilot? -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 01:54, Dave Perry wrote: On Fri, 2007-02-09 at 00:25 +, leee wrote: Just checked again, with current cvs osg/simgear/flightgear, and I still got the same problems. As before, re-setting the A/P via the menu seems to kick everything into life. There also seems to be a random element to this problem - in half a dozeeen tests, most of the time it was the same controllers that seemed not to be working but in two tests there seemed to be a couple of additional ones that didn't want to play. The power check I added to kap140.nas moves the call to initialize the autopilot (apInit) to inside the apPower loop. apPower is called by a setlistener that monitors power=/systems/electrical/outputs/autopilot to makes sure there is power to the autopilot before starting the power monitor apPower to prevent a nil used in numeric context nasal error. So, those reporting this behavior, please look at the Log Window; after the description. There should be two lines: Initializing Nasal Electrical System power up If power up is not there, then apPower has not been called and apInit has not been called, and the state of the various locks is unknown. This would indicate a problem with the setlistener. If it is there, my changes are not causing this problem. Hmm... all I see here is Reading xml electrical system model from /usr/local/share/FlightGear/Aircraft/SU-37/Systems/SU-37-electrical.xml I don't know how this might relate to the Nasal power system but I was beginning to suspect some sort of timing problem. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 17:07, Roy Vegard Ovesen wrote: On Friday 09 February 2007 02:54, Dave Perry wrote: On Fri, 2007-02-09 at 00:25 +, leee wrote: Just checked again, with current cvs osg/simgear/flightgear, and I still got the same problems. As before, re-setting the A/P via the menu seems to kick everything into life. There also seems to be a random element to this problem - in half a dozeeen tests, most of the time it was the same controllers that seemed not to be working but in two tests there seemed to be a couple of additional ones that didn't want to play. The power check I added to kap140.nas moves the call to initialize the autopilot (apInit) to inside the apPower loop. apPower is called by a setlistener that monitors power=/systems/electrical/outputs/autopilot to makes sure there is power to the autopilot before starting the power monitor apPower to prevent a nil used in numeric context nasal error. I believe that the problem Gérard and Lee has seen is not specific to the KAP140 autopilot. apInit in kap140.nas _only_ initializes the properties that belong to the KAP140 autopilot. The initialization that Durk is talking about is certainly not the same as apInit. So far I have been unable to reproduce this. Lee and Gérard, could you please tell us what aircraft you are seeing this with. Is it aircraft that use the generic autopilot and/or aircraft that use a customized autopilot? Hi Roy, I am getting this with the SU-37 and I believe the version in cvs displays the problems. This is a pretty complex A/P setup with cascading up to three levels and it also includes filters to un-tie some tied nodes so that I could use listeners on the preperties. There are also still some redundant controllers in there as well, just to confuse matters further. At one point, while I was tidying up the redundant stuff, I found that when I removed a couple of unused controllers it seemed to cause a couple of used controllers to stop working. I monitor the cvs logs and hadn't noticed anything obvious come through that might have caused this and in the end I couldn't make much sense of it. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 18:24, leee wrote: Hi Roy, I am getting this with the SU-37 and I believe the version in cvs displays the problems. This is a pretty complex A/P setup with cascading up to three levels and it also includes filters to un-tie some tied nodes so that I could use listeners on the preperties. There are also still some redundant controllers in there as well, just to confuse matters further. Could you be more specific? Witch of the 21 pid controllers are not working in the SU-37 autopilot? Also could you tell me how to use the autopilot(s) in the SU-37? From the readme I gathered that it can be cotrolled from the mini-panel, but I'm unable to get the mini-panel to show, I tried c but that didn't seem to work. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Fri 9 February 2007 18:07, Roy Vegard Ovesen wrote: On Friday 09 February 2007 02:54, Dave Perry wrote: I believe that the problem Gérard and Lee has seen is not specific to the KAP140 autopilot. apInit in kap140.nas _only_ initializes the properties that belong to the KAP140 autopilot. The initialization that Durk is talking about is certainly not the same as apInit. So far I have been unable to reproduce this. Lee and Gérard, could you please tell us what aircraft you are seeing this with. Is it aircraft that use the generic autopilot and/or aircraft that use a customized autopilot? Hello Roy , Every Aircraft which basicaly use the Generic autopilot (no KAP140 or else). I tested it with a lot of the nice aircraft from Lee which do not work and among the others examples the dc3 Autopilot is right with Altitude but crazy with Heading. Like i noticed before, if during the flight if i try to get an autopilot with heading , i reload /menu/bug/autopilot and i get the autopilot working. Some others like a4f , f16, gives the same errors (heading bug) , in addition to the fact that the generic autopilot.xml does not suit to high speed aircraft (F18 autopilot.xml from Mathias is better to test it). I have noticed it with every aircraft of my hangar, but that is an other story :) Anyhow the remarks from Durk could be dug again (i have tried to find anything wrong without any success) , because, his own update dated 2007-12-27 12:00 was made only to cvs with OSG And remember = cvs pre osg with plib is perfectly working regarding autopilot. Regards -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 18:14, Roy Vegard Ovesen wrote: On Friday 09 February 2007 18:24, leee wrote: Hi Roy, I am getting this with the SU-37 and I believe the version in cvs displays the problems. This is a pretty complex A/P setup with cascading up to three levels and it also includes filters to un-tie some tied nodes so that I could use listeners on the preperties. There are also still some redundant controllers in there as well, just to confuse matters further. Could you be more specific? Witch of the 21 pid controllers are not working in the SU-37 autopilot? Also could you tell me how to use the autopilot(s) in the SU-37? From the readme I gathered that it can be cotrolled from the mini-panel, but I'm unable to get the mini-panel to show, I tried c but that didn't seem to work. I can't remember exactly which controllers were playing up but there did seem to be a random element to it. For the pitch modes the structure is Pitch-hold Climb-hold Altitude-hold AGL-hold. The Altitude AGL controllers set a target climb rate which is input to the Climb controller. The climb controller outputs a target pitch angle which is then used by the pitch controller to drive the elevon pitch component. At the start of an auto take-off, just the pitch-hold is used to handle the ground run and rotation. Once a set altitude is reached the climb-hold is engaged to achieve a set climb-rate and finally, the altitude hold is engaged. During this sequence I've seen occasions where each of the controllers has appeared to fail, e.g. sometimes the initial pitch hold just doesn't happen and there's no rotation, sometimes the climb rate isn't effective and sometimes the altitude hold is ignored. The locks all appear ok but the output from the controller isn't updated. If leave the aircraft to continue it's climb (on climb-hold) after the altitude hold hasn't worked and then reset the A/P via the menu all the controllers then seem to kick in and, if I can recover from the spin, the A/P seems to work ok. Sometimes, if the altitude hold hasn't worked, the agl hold does. Similarly, if I simply reset the A/P before starting then everything subsequently works ok. I found similar problems with the roll modes but there's only two stages of cascading there. The mini-panel 2d panel needs to be enabled by hitting 'shift-p' and then 's' to toggle into the mini-panel. I find here that I need to switch the old hud off (cycle by hitting 'h') to see the instruments - there seems to be some interaction between the hud display and the 2d instruments. There's a key to the A/P modes in the aircraft help menu but basically, if someting is coloured green you can click it to toggle it. This was all very experimental, from my point of view, hence everything's not very well organised atm. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 19:26, gh.robin wrote: Hello Roy , Every Aircraft which basicaly use the Generic autopilot (no KAP140 or else). I tested it with a lot of the nice aircraft from Lee which do not work and among the others examples the dc3 Autopilot is right with Altitude but crazy with Heading. I just tried the dc3. Heading hold is working perfectly. Could there be something on your and Lee's system that is causing this? I tried the first time you reported this issue, and was unable to reproduce what you saw then too. Are anyone else on this list seeing the problems that Lee and Gérard are seeing? Like i noticed before, if during the flight if i try to get an autopilot with heading , i reload /menu/bug/autopilot and i get the autopilot working. Could you check the property browser before and after you reload the autopilot? Look at the /autopilot/new-config dir. Are all the controllers there prior to reloading the autopilot? (In the cd3 I see two pi-simple-controllers and sixteen pid-controllers.) -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 19:04, Roy Vegard Ovesen wrote: On Friday 09 February 2007 19:26, gh.robin wrote: Hello Roy , Every Aircraft which basicaly use the Generic autopilot (no KAP140 or else). I tested it with a lot of the nice aircraft from Lee which do not work and among the others examples the dc3 Autopilot is right with Altitude but crazy with Heading. I just tried the dc3. Heading hold is working perfectly. Could there be something on your and Lee's system that is causing this? I tried the first time you reported this issue, and was unable to reproduce what you saw then too. Are anyone else on this list seeing the problems that Lee and Gérard are seeing? It's difficult to imagine a system problem that might cause this behaviour, in view of the fact that resetting appears to fix the problem. However, I know that there are a few problems that I've seen here that no one else appears to have experienced on their systems, one long running example being problems with the wind and visibility settings not being honoured. If it is a system problem, I simply don't know where to start looking. Could a compiler problem cause this? It's the only thing I can think of in view of the fact that I'm using Debian Stable and the gcc version is pretty old. I'm not sure that would explain the history of the problem either, that is, it was working ok then stopped working ok. I'm afraid I can't do a lot of testing for you on this. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 20:22, leee wrote: It's difficult to imagine a system problem that might cause this behaviour, in view of the fact that resetting appears to fix the problem. However, I know that there are a few problems that I've seen here that no one else appears to have experienced on their systems, one long running example being problems with the wind and visibility settings not being honoured. If it is a system problem, I simply don't know where to start looking. Could a compiler problem cause this? It's the only thing I can think of in view of the fact that I'm using Debian Stable and the gcc version is pretty old. I'm not sure that would explain the history of the problem either, that is, it was working ok then stopped working ok. I'm afraid I can't do a lot of testing for you on this. I just tried the SU-37, and the autopilot seemed to work OK. I have not been able to reproduce the problems that you and Gérard are having with the autopilot, so it looks like I can't do _any_ testing on this. :-( Could you try the tip I suggested to Gérard about looking at the controllers before and after autopilot reload? -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 19:45, Roy Vegard Ovesen wrote: On Friday 09 February 2007 20:22, leee wrote: It's difficult to imagine a system problem that might cause this behaviour, in view of the fact that resetting appears to fix the problem. However, I know that there are a few problems that I've seen here that no one else appears to have experienced on their systems, one long running example being problems with the wind and visibility settings not being honoured. If it is a system problem, I simply don't know where to start looking. Could a compiler problem cause this? It's the only thing I can think of in view of the fact that I'm using Debian Stable and the gcc version is pretty old. I'm not sure that would explain the history of the problem either, that is, it was working ok then stopped working ok. I'm afraid I can't do a lot of testing for you on this. I just tried the SU-37, and the autopilot seemed to work OK. I have not been able to reproduce the problems that you and Gérard are having with the autopilot, so it looks like I can't do _any_ testing on this. :-( Could you try the tip I suggested to Gérard about looking at the controllers before and after autopilot reload? Just tried another quick test. Opened five property browsers - autopilot/locks, autopilot/settings, autopilot/internal, autopilot/FCS/locks autopilot/FCS/controls - all seemed ok but then I pre-set most of the nodes during aircraft initialisation. On this test the altitude hold failed to work. The altitude hold controller reads the filtered target alt and outputs to autopilot/settings/target-climb-rate-fps. When the altitude hold controller was engaged it failed to update the target climb rate. Agl hold, which also outputs to the same target climb rate node in autopilot/settings, was ok and I could see the node being updated. I switched back to altitude hold and forced a climb by over-typing a +ve climb rate into the non-updating node. Once I got to around 10k ft I reset the A/P and the climb rate started updating. The roll modes were all ok on this test. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
Hi LeeE, can you start flightgear with the bo105 and dynamic-view enabled? If the view direction is ok during the first second or is it spinning around? Maybe this bug has a similar cause. Maik leee schrieb am 09.02.2007 20:22: On Friday 09 February 2007 19:04, Roy Vegard Ovesen wrote: I just tried the dc3. Heading hold is working perfectly. Could there be something on your and Lee's system that is causing this? I tried the first time you reported this issue, and was unable to reproduce what you saw then too. Are anyone else on this list seeing the problems that Lee and Gérard are seeing? It's difficult to imagine a system problem that might cause this behaviour, in view of the fact that resetting appears to fix the problem. However, I know that there are a few problems that I've seen here that no one else appears to have experienced on their systems, one long running example being problems with the wind and visibility settings not being honoured. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Fri 9 February 2007 20:04, Roy Vegard Ovesen wrote: Could you check the property browser before and after you reload the autopilot? Look at the /autopilot/new-config dir. Are all the controllers there prior to reloading the autopilot? (In the cd3 I see two pi-simple-controllers and sixteen pid-controllers.) Hello Roy, I do not notice any differences regarding /autopilot/new-config dir between first load values (after FG loaded) and after reload autopilot. i get two pi-simple-controllers and sixteen pid-controllers. -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Fri 9 February 2007 20:22, leee wrote: It's difficult to imagine a system problem that might cause this behaviour, in view of the fact that resetting appears to fix the problem. However, I know that there are a few problems that I've seen here that no one else appears to have experienced on their systems, one long running example being problems with the wind and visibility settings not being honoured. If it is a system problem, I simply don't know where to start looking. Could a compiler problem cause this? It's the only thing I can think of in view of the fact that I'm using Debian Stable and the gcc version is pretty old. I'm not sure that would explain the history of the problem either, that is, it was working ok then stopped working ok. I am using Fedora Core 5 daily updated. gcc (GCC) 4.1.1 Regards -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Sat 10 February 2007 01:15, gh.robin wrote: On Fri 9 February 2007 20:22, leee wrote: It's difficult to imagine a system problem that might cause this behaviour, in view of the fact that resetting appears to fix the problem. However, I know that there are a few problems that I've seen here that no one else appears to have experienced on their systems, one long running example being problems with the wind and visibility settings not being honoured. If it is a system problem, I simply don't know where to start looking. Could a compiler problem cause this? It's the only thing I can think of in view of the fact that I'm using Debian Stable and the gcc version is pretty old. I'm not sure that would explain the history of the problem either, that is, it was working ok then stopped working ok. I am using Fedora Core 5 daily updated. gcc (GCC) 4.1.1 And in addition to, when i said: was working with CVS FlightGear and Simgear dated 2007-12-27 built was nor working with CVS FlightGear and Simgear dated 2007-12-27 12:00 built These two release where rebuilt especially with the same system configuration, which remove any doubt regarding any system differences. Regards -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] C172p strange behaviour with --flight-plan
Hi, I hit on a strange problem when using the --flight-plan commandline option with the default c172. All controls are working except the ailerons, which makes flying around a bit challenging... ;-) command line: fgfs --airport=EDDT --runway=26L --flight-plan=EDDT-EDDC.plan EDDT-EDDC.plan: GERGA TUVAK GORIG BESKO LUROS EBASA KOBUS GARKI Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Thu 8 February 2007 11:13, Thomas Förster wrote: Hi, I hit on a strange problem when using the --flight-plan commandline option with the default c172. All controls are working except the ailerons, which makes flying around a bit challenging... ;-) command line: fgfs --airport=EDDT --runway=26L --flight-plan=EDDT-EDDC.plan EDDT-EDDC.plan: GERGA TUVAK GORIG BESKO LUROS EBASA KOBUS GARKI Thomas If it is FG cvs with OSG, it is not a surprise to me, i told before on several topics regarding autopilot, that it is not working. Nobody but Lee answered to confirm that it is not working. -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
Am Donnerstag 08 Februar 2007 18:35 schrieb gh.robin: On Thu 8 February 2007 11:13, Thomas Förster wrote: ... If it is FG cvs with OSG, it is not a surprise to me, i told before on several topics regarding autopilot, that it is not working. Nobody but Lee answered to confirm that it is not working. No, this was with the 0.9.10 release. The c172 starts with waypoint mode enabled if --flight-plan is given, but the autopilot (the one in the plane) switched off. Switching off waypoint mode with F6 gives back full controls. Looks like an interference of the generalized FG autopilot and the c172 one. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
gh.robin wrote: On Thu 8 February 2007 11:13, Thomas F?rster wrote: I hit on a strange problem when using the --flight-plan commandline option with the default c172. All controls are working except the ailerons, which makes flying around a bit challenging... ;-) If it is FG cvs with OSG, it is not a surprise to me, i told before on several topics regarding autopilot, that it is not working. If you would not notoriously combine such bug reports with senseless allegations then people probably would take your reports more seriously, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Thu 8 February 2007 23:09, Martin Spott wrote: gh.robin wrote: On Thu 8 February 2007 11:13, Thomas F?rster wrote: I hit on a strange problem when using the --flight-plan commandline option with the default c172. All controls are working except the ailerons, which makes flying around a bit challenging... ;-) If it is FG cvs with OSG, it is not a surprise to me, i told before on several topics regarding autopilot, that it is not working. If you would not notoriously combine such bug reports with senseless allegations then people probably would take your reports more seriously, Martin. Martin, Nice your answer , what would have more, to take that information seriously ? just, remember, from Lee == I experienced similar problems a few days ago - some of the AP controllers seemed to be working from start-up but others didn't. Re-setting the AP controllers via the debug menu appeared to kick them into life after start-up. I also had problems with some AP controllers seeming not to work after I removed other unrelated redundant controllers but didn't have enough time to look further into it or establish any consistency. from me == The CVS FlightGear and Simgear dated 2007-12-27 built, gives an Autopilot working The CVS FlightGear and Simgear dated 2007-12-27 12:00 built, gives an Autopilot destroyed. . if we reload the autopilot config with menu/debug We get the autopilot working heading and altitude== That information from me was only to help to improve FG cvs with OSG , if you do want it .i don't mind i have solved that bug with a specific trick on my side. Anyhow If you want more, i can give you the size and the color of my shirt. Regards -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Thursday 08 February 2007 23:22, gh.robin wrote: On Thu 8 February 2007 23:09, Martin Spott wrote: gh.robin wrote: On Thu 8 February 2007 11:13, Thomas F?rster wrote: I hit on a strange problem when using the --flight-plan commandline option with the default c172. All controls are working except the ailerons, which makes flying around a bit challenging... ;-) If it is FG cvs with OSG, it is not a surprise to me, i told before on several topics regarding autopilot, that it is not working. If you would not notoriously combine such bug reports with senseless allegations then people probably would take your reports more seriously, Martin. Martin, Nice your answer , what would have more, to take that information seriously ? just, remember, from Lee == I experienced similar problems a few days ago - some of the AP controllers seemed to be working from start-up but others didn't. Re-setting the AP controllers via the debug menu appeared to kick them into life after start-up. I also had problems with some AP controllers seeming not to work after I removed other unrelated redundant controllers but didn't have enough time to look further into it or establish any consistency. from me == The CVS FlightGear and Simgear dated 2007-12-27 built, gives an Autopilot working The CVS FlightGear and Simgear dated 2007-12-27 12:00 built, gives an Autopilot destroyed. . if we reload the autopilot config with menu/debug We get the autopilot working heading and altitude== That information from me was only to help to improve FG cvs with OSG , if you do want it .i don't mind i have solved that bug with a specific trick on my side. Anyhow If you want more, i can give you the size and the color of my shirt. Regards Just checked again, with current cvs osg/simgear/flightgear, and I still got the same problems. As before, re-setting the A/P via the menu seems to kick everything into life. There also seems to be a random element to this problem - in half a dozeeen tests, most of the time it was the same controllers that seemed not to be working but in two tests there seemed to be a couple of additional ones that didn't want to play. LeeE - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
leee wrote: On Thursday 08 February 2007 23:22, gh.robin wrote: Just checked again, with current cvs osg/simgear/flightgear, and I still got the same problems. As before, re-setting the A/P via the menu seems to kick everything into life. There also seems to be a random element to this problem - in half a dozeeen tests, most of the time it was the same controllers that seemed not to be working but in two tests there seemed to be a couple of additional ones that didn't want to play. I have read the original report, and remember that the moment the autopilot seemed to stop working was one where I had committed a bunch of AI related changes, which actually have nothing to do with the autopilot. The changes in this particular commit were affecting the core of FlightGear a bit more than usual, because I modified the initialization procedure of the TrafficManager system, which required code changes in Main/fg_init.cxx. There is a possibility that something has gone wrong here; either a) the new initialization procedure has a memory error that corrupts the initialization of the autopilot; or b) the new initialization procedure introduces a timing error, so that parts of the autopilot are never initialized. Normally, I would have run a few tests in order to falsify my hypotheses, but as I'm currently away from home, I can't do that. If anybody wants to look into this, please do so. Otherwise, it has to wait until after I get back home, I'm afraid. Cheers, Durk However, - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Fri, 2007-02-09 at 00:25 +, leee wrote: Just checked again, with current cvs osg/simgear/flightgear, and I still got the same problems. As before, re-setting the A/P via the menu seems to kick everything into life. There also seems to be a random element to this problem - in half a dozeeen tests, most of the time it was the same controllers that seemed not to be working but in two tests there seemed to be a couple of additional ones that didn't want to play. The power check I added to kap140.nas moves the call to initialize the autopilot (apInit) to inside the apPower loop. apPower is called by a setlistener that monitors power=/systems/electrical/outputs/autopilot to makes sure there is power to the autopilot before starting the power monitor apPower to prevent a nil used in numeric context nasal error. So, those reporting this behavior, please look at the Log Window; after the description. There should be two lines: Initializing Nasal Electrical System power up If power up is not there, then apPower has not been called and apInit has not been called, and the state of the various locks is unknown. This would indicate a problem with the setlistener. If it is there, my changes are not causing this problem. -- Dave Perry [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
