Re: [Flightgear-devel] Autopilot filters
Torsten Have you any more thoughts on this? Alan From: Alan Teeder Sent: Sunday, July 28, 2013 2:21 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot filters Torsten Thanks for looking at my code. Yes – there is already an integrator in the PI and PID filters. But the same can be said for derivative and gain. Min/max clamping via u-max and u-min appears to be working correctly in my integrator. Having a specific integrator filter makes the resultant XML file easier to read than hiding it inside a PI filter. It is also possible to make a washout filter from the existing gain and exponential filters. I see nothing wrong with extending the exponential filter, if that improves the code. High-pass and low pass-are just different flavours of the same thing. I coded the high-pass filter separately as it seemed the easiest way for me to implement such a filter. The aliases reflect the names that are in common usage. Lag and washout are used colloquially in control engineering, whilst high-pass and low-pass are rather more formal. The existing exponential filter name is too vague, and should be deprecated. It is true that a rate-limit can be used as a noise-spike filter, but there are other ways to remove spikes, so noise-spike should also be deprecated. My overall intention is to make available the same building blocks which were used in analogue and early digital autopilots, and to use the same terminology. For completeness, there may be a case for adding band-pass and band-stop filters, but these have very few applications in autopilots. Alan From: Torsten Dreyer Sent: Sunday, July 28, 2013 12:31 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot filters Hi Alan, thank you for your patch. I have a few, probably dumb questions: * Isn't the your new integrator filter the same as a pi-simple-controller with Kp=1 and no min/max clamping? * What would you think about extending the exponential filter to make it behave like a high-pass or low-pass like typelow-pass/type or typehigh-pass/type. That would not double existing code. * What is the purpose for adding alias names for existing filters? Cheers, Torsten Am 27.07.2013 10:27, schrieb Alan Teeder: From: Torsten Dreyer Sent: Saturday, July 27, 2013 8:47 AM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Autopilot filters Post a diff or the modified files or a link to a tarball here and I'll have a look. Probably a good start for me to get back into the loop after almost two years of absence... Torsten Thanks Torsten. The files are zipped at http://v-twin.dynip.sapo.pt/alan/FG/digitalfilter.zip. (10kb) At some time I will need to add a means of initialising the Integral filter to a property. Alan -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters
Hi Alan, thank you for your patch. I have a few, probably dumb questions: * Isn't the your new integrator filter the same as a pi-simple-controller with Kp=1 and no min/max clamping? * What would you think about extending the exponential filter to make it behave like a high-pass or low-pass like typelow-pass/type or typehigh-pass/type. That would not double existing code. * What is the purpose for adding alias names for existing filters? Cheers, Torsten Am 27.07.2013 10:27, schrieb Alan Teeder: *From:* Torsten Dreyer mailto:tors...@t3r.de *Sent:* Saturday, July 27, 2013 8:47 AM *To:* flightgear-devel@lists.sourceforge.net mailto:flightgear-devel@lists.sourceforge.net *Subject:* Re: [Flightgear-devel] Autopilot filters Post a diff or the modified files or a link to a tarball here and I'll have a look. Probably a good start for me to get back into the loop after almost two years of absence... Torsten Thanks Torsten. The files are zipped at http://v-twin.dynip.sapo.pt/alan/FG/digitalfilter.zip. (10kb) At some time I will need to add a means of initialising the Integral filter to a property. Alan -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters
Torsten Thanks for looking at my code. Yes – there is already an integrator in the PI and PID filters. But the same can be said for derivative and gain. Min/max clamping via u-max and u-min appears to be working correctly in my integrator. Having a specific integrator filter makes the resultant XML file easier to read than hiding it inside a PI filter. It is also possible to make a washout filter from the existing gain and exponential filters. I see nothing wrong with extending the exponential filter, if that improves the code. High-pass and low pass-are just different flavours of the same thing. I coded the high-pass filter separately as it seemed the easiest way for me to implement such a filter. The aliases reflect the names that are in common usage. Lag and washout are used colloquially in control engineering, whilst high-pass and low-pass are rather more formal. The existing exponential filter name is too vague, and should be deprecated. It is true that a rate-limit can be used as a noise-spike filter, but there are other ways to remove spikes, so noise-spike should also be deprecated. My overall intention is to make available the same building blocks which were used in analogue and early digital autopilots, and to use the same terminology. For completeness, there may be a case for adding band-pass and band-stop filters, but these have very few applications in autopilots. Alan From: Torsten Dreyer Sent: Sunday, July 28, 2013 12:31 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot filters Hi Alan, thank you for your patch. I have a few, probably dumb questions: * Isn't the your new integrator filter the same as a pi-simple-controller with Kp=1 and no min/max clamping? * What would you think about extending the exponential filter to make it behave like a high-pass or low-pass like typelow-pass/type or typehigh-pass/type. That would not double existing code. * What is the purpose for adding alias names for existing filters? Cheers, Torsten Am 27.07.2013 10:27, schrieb Alan Teeder: From: Torsten Dreyer Sent: Saturday, July 27, 2013 8:47 AM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Autopilot filters Post a diff or the modified files or a link to a tarball here and I'll have a look. Probably a good start for me to get back into the loop after almost two years of absence... Torsten Thanks Torsten. The files are zipped at http://v-twin.dynip.sapo.pt/alan/FG/digitalfilter.zip. (10kb) At some time I will need to add a means of initialising the Integral filter to a property. Alan -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters
On 26 Jul 2013, at 20:11, Alan Teeder ajtee...@v-twin.org.uk wrote: I have added a washout/high-pass filter and an integrator to the XML autopilot. Also I have added aliases to the exponential filter so that it may be also called low-pass or lag and an alias to the noise-spike filter so that it can also be called rate-limit. README.digitalfilters is updated to match, as well as incorporating the undocumented derivative filter and mentioning the use of expressions. How should I submit these for review? Please don´t ask me to use git, as I am very good at screwing my own repos up and would not like to do the same to fgdata. I would greatly prefer you to use Git, possibly after a discussion about workflow and suchlike. If that's utterly impossible you can post a diff or patch here and we can review it. Note that if you use Gitorious' merge-request system, and you can't screw up FGdata, but of course that doesn't help with making a glorious mess of your own... James Alan -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters
Post a diff or the modified files or a link to a tarball here and I'll have a look. Probably a good start for me to get back into the loop after almost two years of absence... Torsten Am 26.07.2013 21:11, schrieb Alan Teeder: I have added a washout/high-pass filter and an integrator to the XML autopilot. Also I have added aliases to the exponential filter so that it may be also called low-pass or lag and an alias to the noise-spike filter so that it can also be called rate-limit. README.digitalfilters is updated to match, as well as incorporating the undocumented derivative filter and mentioning the use of expressions. How should I submit these for review? Please don´t ask me to use git, as I am very good at screwing my own repos up and would not like to do the same to fgdata. Alan -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters
From: Torsten Dreyer Sent: Saturday, July 27, 2013 8:47 AM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Autopilot filters Post a diff or the modified files or a link to a tarball here and I'll have a look. Probably a good start for me to get back into the loop after almost two years of absence... Torsten Thanks Torsten. The files are zipped at http://v-twin.dynip.sapo.pt/alan/FG/digitalfilter.zip. (10kb) At some time I will need to add a means of initialising the Integral filter to a property. Alan-- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Wednesday 19 December 2007 16:38, Tiago Gusmão wrote: LeeE wrote: On Wednesday 19 December 2007 12:56, Tiago Gusmão wrote: LeeE wrote: On Tuesday 18 December 2007 22:52, Tiago Gusmão wrote: LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. LeeE Are you sure it's oscillating instead of just catching up with the current input? anyway, you can try to enable debug on that filter and show us some values. In the meantime i've had my own problem with the AP (now solved, don't use alpha=0 or you will get a NaN that will bring FG to a halt if tied to the controls) but i found some things that don't make much sense to me xmlauto.cxx, line 798, FGXMLAutopilot::reinit: -why is build() called there? it's already called inside init() -maybe my C++ is a little forgotten, but don't we need to delete the objects contained in components() ? Cheers, Tiago Hi Tiago, I'm not absolutely sure it's oscillating - it's changing too fast to actually see the numbers to be sure - but the visual pattern - that is, the apparent 'shape' that you can see suggests it is rapidly switching between two values, which change more slowly, over time, as the input changes. Like I said, I compared the un-filtered input with the filtered output and while the input could be stable to 2 decimal places the filtered output could be changing at the first decimal place i.e. the output was varying more than the input by a factor of up to 100, so it's not a case of the filter trying to catch up. The effect is that it is oscillating because it's vastly overshooting it's target in both directions. LeeE I wasn't able to reproduce, i tried with filter nametest filter/name debugtrue/debug typenoise-spike/type input/controls/flight/elevator/input output/controls/flight/filtered-elevator/output max-rate-of-change0.1/max-rate-of-change /filter Also my paper simulations seemed ok. Could you post your filter? Anyway, the current behavior of resetting the filtered output to zero doesn't seem very good, i think starting at the current input would be best. Cheers, Tiago Hi Tiago, have a look at the 'Target Pitch Filter' in the BAC-TSR2 autopilot - I saw the problem with that filter. The filename is: Aircraft/BAC-TSR2/Systems/BAC-TSR2-autopilot.xml LeeE I've tested it and it seems the input oscillates and can even change sign very briefly, you need to pause right after reloading the AP to be able to spot it. Because the filtered output will restart at zero, it will be able to quickly go negative and then will take quite some time to return to normal values. So while this is AP's fault, it's not because of the filter. Anyway, AP reloading isn't something we expect users to mess with, so i wouldn't bother much with it. And from what i've seen in the code, reloading is reliable in the sense that it really creates new instances of the objects, so there are no stale values. BTW, it was really nice to see the TSR2 fly KSFO - KSCK over those hills, good work :) Cheers, Tiago Hi Tiago, thanks for looking into it. On the TSR2 some of the controllers are very 'tightly' tuned and close to oscillating, and can become unstable at very high speeds. This is largely a nature-of-the-beast type problem - it's a relatively high mass aircraft with small wings and with the elevators(elevons) set close to the wing, giving a small moment arm. At the same time though, they need a lot of authority. The way to get around that would be to run the controllers at a higher rate, which would give them a higher resolution, but I decided to peg them all at 20Hz so that they would work on relatively modest h/w. The controllers are therefore very sensitive and can 'kick', hence the use of filters. Now that I know about the problem, and it really is only a problem while you're tuning the controllers, I know what to look out for. Heh - I first spotted it while I was tuning controllers, which means that you end up re-loading the autopilot a lot, and I spent a long time trying to tune the oscillations out before I noticed that the oscillations didn't start until I reloaded the autopilot - doh! I'll continue monitoring it and it'll be interesting to see if anyone else sees it. LeeE - SF.Net email is sponsored by: Check out the new
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Tuesday 18 December 2007, LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. I've seen something similar after I added an enabled option to the filters on my local branch. Whenever I enable a filter by setting some property to true (just like enabling PID controllers), I see the output from the filter, wich is connected to the control surface, makes the plane do some wild flying. I believe that I need to add some initialization code to the filters so that they behave nicely when they are enabled. I'm working on this. Also I'll remove the build() call in reinit() inless there is a good reason for calling build() twice. -- Roy Vegard Ovesen - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Thursday 20 December 2007 10:53, Roy Vegard Ovesen wrote: On Tuesday 18 December 2007, LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. I've seen something similar after I added an enabled option to the filters on my local branch. Whenever I enable a filter by setting some property to true (just like enabling PID controllers), I see the output from the filter, wich is connected to the control surface, makes the plane do some wild flying. I believe that I need to add some initialization code to the filters so that they behave nicely when they are enabled. I'm working on this. Also I'll remove the build() call in reinit() inless there is a good reason for calling build() twice. Doh! - It's only just occurred to me that we could use the logging facility to log the output from controllers and filters and analyse the results 'off-line' so to speak. Should be trivial to import the results into a spreadsheet and plot graphs - it'll only take a little bit of effort to set up the logging details - I'll try this when I get a chance. LeeE - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Thursday 20 December 2007 11:21, LeeE wrote: On Thursday 20 December 2007 10:53, Roy Vegard Ovesen wrote: On Tuesday 18 December 2007, LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. I've seen something similar after I added an enabled option to the filters on my local branch. Whenever I enable a filter by setting some property to true (just like enabling PID controllers), I see the output from the filter, wich is connected to the control surface, makes the plane do some wild flying. I believe that I need to add some initialization code to the filters so that they behave nicely when they are enabled. I'm working on this. Also I'll remove the build() call in reinit() inless there is a good reason for calling build() twice. Doh! - It's only just occurred to me that we could use the logging facility to log the output from controllers and filters and analyse the results 'off-line' so to speak. Should be trivial to import the results into a spreadsheet and plot graphs - it'll only take a little bit of effort to set up the logging details - I'll try this when I get a chance. LeeE got some data in a .csv - attached. TGT-PITCH-DEG is the input and TGT-PITCH-DEGF is the output from the filter. The sampling interval was set to 50 ms - in practice it's not as regular as that though. I imported it in to OO Calc to plot it and it seems to show that the filtered output isn't crossing the input but is sort of 'bouncing' off of it. The input _is_ varying in synch with the filtered output but I suspect that this is because the controller, which generates the target-pitch, is responding to the consequences of the 'bounces' in the filtered output, which was driving the elevator. In any case, it seems to show that the filtered output is varying much more than the input, which shouldn't be the case - the noise-spike filter should only limit the rate between the input variation levels, not exceed them. Interestingly, this is only happens when there is some variation in the input - if you switch off the controller that generates the input, or cause it to max out, the filter settles down and stabilises - the input needs to be varying a little bit for the problem to appear. LeeE Time,TGT-PITCH-DEG,TGT-PITCH-DEGF 915.942,1.33209,1.431093073 915.992,1.33209,1.332092643 916.033,1.33387,1.333867431 916.1,1.33419,1.500534097 916.133,1.33419,1.367200764 916.183,1.33655,1.433867431 916.408,1.3329,1.989651442 916.408,1.3329,1.989651442 916.408,1.3329,1.989651442 916.408,1.3329,1.989651442 916.442,1.3329,1.856318108 916.483,1.34099,1.889651442 916.542,1.33116,1.789651442 916.583,1.33116,1.622984775 916.65,1.31422,1.556318108 916.692,1.29495,1.589651442 916.733,1.28033,1.556318108 916.8,1.26023,1.489651442 916.842,1.26023,1.322984775 916.883,1.24673,1.356318108 916.95,1.24201,1.242008686 916.983,1.23672,1.308675353 917.033,1.23672,1.236724138 917.092,1.23537,1.235374451 917.133,1.24104,1.268707784 917.2,1.24955,1.249554515 917.233,1.25641,1.316221182 917.3,1.26561,1.356407261 917.342,1.26561,1.265610218 917.383,1.27426,1.298943551 917.45,1.27787,1.277867556 917.483,1.28017,1.344534222 917.55,1.28304,1.380168176 917.592,1.28304,1.283035755 917.633,1.2831,1.283098459 917.7,1.28233,1.283098459 917.742,1.28149,1.38274 917.783,1.28149,1.281490803 917.842,1.27937,1.279367566 917.883,1.27661,1.276611328 917.942,1.27424,1.509944661 917.983,1.27424,1.343277995 918.05,1.27818,1.278181434 918.092,1.27493,1.311514767 918.133,1.2723,1.341598574 918.183,1.2723,1.272304296 918.25,1.26944,1.269443274 918.292,1.27064,1.270636916 918.333,1.27033,1.337303583 918.383,1.27033,1.270326734 918.442,1.27173,1.271729112 918.483,1.27347,1.273471713 918.683,1.28299,1.939923286 918.683,1.28299,1.939923286 918.683,1.28299,1.939923286 918.683,1.28299,1.939923286 918.733,1.28299,1.739923286 918.783,1.29474,1.739923286 918.85,1.28841,1.606589953 918.892,1.27263,1.639923286 918.933,1.27263,1.47325662 918.992,1.25483,1.439923286 919.042,1.24046,1.439923286 919.083,1.22354,1.47325662 919.142,1.21445,1.439923286 919.183,1.21445,1.27325662 919.242,1.20351,1.239923286 919.292,1.20087,1.239923286 919.35,1.19963,1.199625731 919.392,1.19926,1.299625731 919.433,1.19926,1.199256182 919.483,1.20634,1.265922848 919.55,1.21445,1.214454889 919.592,1.22125,1.314454889 919.8,1.24697,1.904868126 919.8,1.24697,1.904868126 919.8,1.24697,1.904868126 919.8,1.24697,1.904868126 919.833,1.24697,1.771534793 919.892,1.2477,1.738201459 919.933,1.23738,1.704868126
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
LeeE wrote: On Tuesday 18 December 2007 22:52, Tiago Gusmão wrote: LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. LeeE Are you sure it's oscillating instead of just catching up with the current input? anyway, you can try to enable debug on that filter and show us some values. In the meantime i've had my own problem with the AP (now solved, don't use alpha=0 or you will get a NaN that will bring FG to a halt if tied to the controls) but i found some things that don't make much sense to me xmlauto.cxx, line 798, FGXMLAutopilot::reinit: -why is build() called there? it's already called inside init() -maybe my C++ is a little forgotten, but don't we need to delete the objects contained in components() ? Cheers, Tiago Hi Tiago, I'm not absolutely sure it's oscillating - it's changing too fast to actually see the numbers to be sure - but the visual pattern - that is, the apparent 'shape' that you can see suggests it is rapidly switching between two values, which change more slowly, over time, as the input changes. Like I said, I compared the un-filtered input with the filtered output and while the input could be stable to 2 decimal places the filtered output could be changing at the first decimal place i.e. the output was varying more than the input by a factor of up to 100, so it's not a case of the filter trying to catch up. The effect is that it is oscillating because it's vastly overshooting it's target in both directions. LeeE I wasn't able to reproduce, i tried with filter nametest filter/name debugtrue/debug typenoise-spike/type input/controls/flight/elevator/input output/controls/flight/filtered-elevator/output max-rate-of-change0.1/max-rate-of-change /filter Also my paper simulations seemed ok. Could you post your filter? Anyway, the current behavior of resetting the filtered output to zero doesn't seem very good, i think starting at the current input would be best. Cheers, Tiago - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after r eloading autopilot
On Wednesday 19 December 2007 12:56, Tiago Gusmão wrote: LeeE wrote: On Tuesday 18 December 2007 22:52, Tiago Gusmão wrote: LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. LeeE Are you sure it's oscillating instead of just catching up with the current input? anyway, you can try to enable debug on that filter and show us some values. In the meantime i've had my own problem with the AP (now solved, don't use alpha=0 or you will get a NaN that will bring FG to a halt if tied to the controls) but i found some things that don't make much sense to me xmlauto.cxx, line 798, FGXMLAutopilot::reinit: -why is build() called there? it's already called inside init() -maybe my C++ is a little forgotten, but don't we need to delete the objects contained in components() ? Cheers, Tiago Hi Tiago, I'm not absolutely sure it's oscillating - it's changing too fast to actually see the numbers to be sure - but the visual pattern - that is, the apparent 'shape' that you can see suggests it is rapidly switching between two values, which change more slowly, over time, as the input changes. Like I said, I compared the un-filtered input with the filtered output and while the input could be stable to 2 decimal places the filtered output could be changing at the first decimal place i.e. the output was varying more than the input by a factor of up to 100, so it's not a case of the filter trying to catch up. The effect is that it is oscillating because it's vastly overshooting it's target in both directions. LeeE I wasn't able to reproduce, i tried with filter nametest filter/name debugtrue/debug typenoise-spike/type input/controls/flight/elevator/input output/controls/flight/filtered-elevator/output max-rate-of-change0.1/max-rate-of-change /filter Also my paper simulations seemed ok. Could you post your filter? Anyway, the current behavior of resetting the filtered output to zero doesn't seem very good, i think starting at the current input would be best. Cheers, Tiago Hi Tiago, have a look at the 'Target Pitch Filter' in the BAC-TSR2 autopilot - I saw the problem with that filter. The filename is: Aircraft/BAC-TSR2/Systems/BAC-TSR2-autopilot.xml LeeE - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
LeeE wrote: On Wednesday 19 December 2007 12:56, Tiago Gusmão wrote: LeeE wrote: On Tuesday 18 December 2007 22:52, Tiago Gusmão wrote: LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. LeeE Are you sure it's oscillating instead of just catching up with the current input? anyway, you can try to enable debug on that filter and show us some values. In the meantime i've had my own problem with the AP (now solved, don't use alpha=0 or you will get a NaN that will bring FG to a halt if tied to the controls) but i found some things that don't make much sense to me xmlauto.cxx, line 798, FGXMLAutopilot::reinit: -why is build() called there? it's already called inside init() -maybe my C++ is a little forgotten, but don't we need to delete the objects contained in components() ? Cheers, Tiago Hi Tiago, I'm not absolutely sure it's oscillating - it's changing too fast to actually see the numbers to be sure - but the visual pattern - that is, the apparent 'shape' that you can see suggests it is rapidly switching between two values, which change more slowly, over time, as the input changes. Like I said, I compared the un-filtered input with the filtered output and while the input could be stable to 2 decimal places the filtered output could be changing at the first decimal place i.e. the output was varying more than the input by a factor of up to 100, so it's not a case of the filter trying to catch up. The effect is that it is oscillating because it's vastly overshooting it's target in both directions. LeeE I wasn't able to reproduce, i tried with filter nametest filter/name debugtrue/debug typenoise-spike/type input/controls/flight/elevator/input output/controls/flight/filtered-elevator/output max-rate-of-change0.1/max-rate-of-change /filter Also my paper simulations seemed ok. Could you post your filter? Anyway, the current behavior of resetting the filtered output to zero doesn't seem very good, i think starting at the current input would be best. Cheers, Tiago Hi Tiago, have a look at the 'Target Pitch Filter' in the BAC-TSR2 autopilot - I saw the problem with that filter. The filename is: Aircraft/BAC-TSR2/Systems/BAC-TSR2-autopilot.xml LeeE I've tested it and it seems the input oscillates and can even change sign very briefly, you need to pause right after reloading the AP to be able to spot it. Because the filtered output will restart at zero, it will be able to quickly go negative and then will take quite some time to return to normal values. So while this is AP's fault, it's not because of the filter. Anyway, AP reloading isn't something we expect users to mess with, so i wouldn't bother much with it. And from what i've seen in the code, reloading is reliable in the sense that it really creates new instances of the objects, so there are no stale values. BTW, it was really nice to see the TSR2 fly KSFO - KSCK over those hills, good work :) Cheers, Tiago - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. LeeE Are you sure it's oscillating instead of just catching up with the current input? anyway, you can try to enable debug on that filter and show us some values. In the meantime i've had my own problem with the AP (now solved, don't use alpha=0 or you will get a NaN that will bring FG to a halt if tied to the controls) but i found some things that don't make much sense to me xmlauto.cxx, line 798, FGXMLAutopilot::reinit: -why is build() called there? it's already called inside init() -maybe my C++ is a little forgotten, but don't we need to delete the objects contained in components() ? Cheers, Tiago - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Tuesday 18 December 2007 22:52, Tiago Gusmão wrote: LeeE wrote: Hi all, I've noticed recently that after re-loading an autopilot the filters that are being used seem to be getting a bit 'confused'. I spotted it when I was comparing the unfiltered input with the filtered output and saw that the input was stable to 2 decimal places but the filtered output seemed to be oscillating very quickly up to the first decimal place. I don't know if this happens with all filter types - all the ones I've been using are noise-spike types. LeeE Are you sure it's oscillating instead of just catching up with the current input? anyway, you can try to enable debug on that filter and show us some values. In the meantime i've had my own problem with the AP (now solved, don't use alpha=0 or you will get a NaN that will bring FG to a halt if tied to the controls) but i found some things that don't make much sense to me xmlauto.cxx, line 798, FGXMLAutopilot::reinit: -why is build() called there? it's already called inside init() -maybe my C++ is a little forgotten, but don't we need to delete the objects contained in components() ? Cheers, Tiago Hi Tiago, I'm not absolutely sure it's oscillating - it's changing too fast to actually see the numbers to be sure - but the visual pattern - that is, the apparent 'shape' that you can see suggests it is rapidly switching between two values, which change more slowly, over time, as the input changes. Like I said, I compared the un-filtered input with the filtered output and while the input could be stable to 2 decimal places the filtered output could be changing at the first decimal place i.e. the output was varying more than the input by a factor of up to 100, so it's not a case of the filter trying to catch up. The effect is that it is oscillating because it's vastly overshooting it's target in both directions. LeeE - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
