From: Alan T. <ajt...@v-...> - 2013-07-26 19:11:53
|
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 |
From: James T. <zak...@ma...> - 2013-07-27 07:12:15
|
On 26 Jul 2013, at 20:11, Alan Teeder <ajt...@v-...> 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=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Torsten D. <To...@t3...> - 2013-07-27 07:41:35
|
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 > > |
From: Alan T. <ajt...@v-...> - 2013-07-27 08:27:42
|
From: Torsten Dreyer Sent: Saturday, July 27, 2013 8:47 AM To: fli...@li... 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 |
From: Torsten D. <To...@t3...> - 2013-07-28 11:26:09
|
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 <type>low-pass</type> or <type>high-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:To...@t3...> > *Sent:* Saturday, July 27, 2013 8:47 AM > *To:* fli...@li... > <mailto:fli...@li...> > *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 > |
From: Alan T. <ajt...@v-...> - 2013-07-28 13:21:50
|
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 <type>low-pass</type> or <type>high-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: fli...@li... 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=48808831&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: jean p. <jea...@wa...> - 2013-07-29 12:39:02
|
hi there, following this bug report: http://code.google.com/p/flightgear-bugs/issues/detail?id=901 it appears that orientation/side-slip-deg and side-slip-rad don't have the same sign, depending if it's a yasim or a jsbsim plane. is there a commonly adopted convention for this property? if not, shouldn't we document somewhere the meaning of the different fdm properties present in fg tree, to avoid such problems in the future ? jano |
From: Jon S. B. <jon...@co...> - 2013-07-29 12:57:01
|
As in this image: http://dodlithr.blogspot.com/2011/09/airplanes-stability-axis.html Beta is positive when the wind hits the right side of the vehicle. This is the only standard convention I have ever seen. I would recommend strongly against artificially changing the sign of this parameter as output from JSBSim. Jon > -----Original Message----- > From: jean pellotier [mailto:jea...@wa...] > Sent: Monday, July 29, 2013 6:27 AM > To: FlightGear developers discussions > Subject: [Flightgear-devel] making sign of side-slip consistent between > fdm (bug 901) > > hi there, > > following this bug report: > > http://code.google.com/p/flightgear-bugs/issues/detail?id=901 > > it appears that orientation/side-slip-deg and side-slip-rad don't have > the same sign, depending if it's a yasim or a jsbsim plane. > > is there a commonly adopted convention for this property? > > if not, shouldn't we document somewhere the meaning of the different > fdm properties present in fg tree, to avoid such problems in the future > ? > > jano > > ----------------------------------------------------------------------- > ------- > 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=48808831&iu=/4140/ostg.cl > ktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Alan T. <ajt...@v-...> - 2013-07-29 13:50:00
|
This confusion is common. It arises when people try to visualise the angle beta by simply yawing the aircraft, which they at the same time visualise as flying straight in the original direction. (you get the same condition if you yaw the aircraft in a wind tunnel) In this special case beta equals minus yaw angle - which is why they make this mistake. In turning flight there is of course no such simple relationship between sideslip and yaw. Side slip angle beta has the same sign as side slip velocity v. Alan -----Original Message----- From: Jon S. Berndt Sent: Monday, July 29, 2013 1:54 PM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] making sign of side-slip consistent betweenfdm (bug 901) As in this image: http://dodlithr.blogspot.com/2011/09/airplanes-stability-axis.html Beta is positive when the wind hits the right side of the vehicle. This is the only standard convention I have ever seen. I would recommend strongly against artificially changing the sign of this parameter as output from JSBSim. Jon > -----Original Message----- > From: jean pellotier [mailto:jea...@wa...] > Sent: Monday, July 29, 2013 6:27 AM > To: FlightGear developers discussions > Subject: [Flightgear-devel] making sign of side-slip consistent between > fdm (bug 901) > > hi there, > > following this bug report: > > http://code.google.com/p/flightgear-bugs/issues/detail?id=901 > > it appears that orientation/side-slip-deg and side-slip-rad don't have > the same sign, depending if it's a yasim or a jsbsim plane. > > is there a commonly adopted convention for this property? > > if not, shouldn't we document somewhere the meaning of the different > fdm properties present in fg tree, to avoid such problems in the future > ? > > jano > > ----------------------------------------------------------------------- > ------- > 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=48808831&iu=/4140/ostg.cl > ktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > 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=48808831&iu=/4140/ostg.clktrk _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: jean p. <jea...@wa...> - 2013-08-23 22:09:38
|
> > Beta is positive when the wind hits the right side of the vehicle. This is > the only standard convention I have ever seen. I would recommend strongly > against artificially changing the sign of this parameter as output from > JSBSim. > > Jon > I did a merge request considering jsbsim got right here, ie positive when the wind come from the right. you can find them here: http://code.google.com/p/flightgear-bugs/issues/detail?id=901#c12 the yasim planes using: orientation/side-slip-deg in autopilot or animation were tweaked with a sign inversion to have the same behaviour as before. three files are left inchanged as i don't know wich behaviour is correct, and as they were inversed between yasim and jsbsim planes: Nasal/dynamic_view.nas Huds/NTPS.xml /Huds/Instruments/turn-bank-indicator.xml the dynamic view got nearly no effect from the side-slip, so it's not a concern here, for the two hud files, i need to how they should behave, anyone got a clue? as a side note, i think the bocian's yawstring got a wrong sign in the animation, the string should be aligned whith the airflow, and it currently do the oposite (imho). jano |
From: Alan T. <ajt...@v-...> - 2013-09-09 21:54:37
|
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 <type>low-pass</type> or <type>high-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: fli...@li... 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=48808831&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... 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=48808831&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Alan T. <ajt...@v-...> - 2013-10-15 21:37:04
|
I now have further have 3 further additional filter changes that I would like to have added to the xml autopilot. These are a lead lag filter i.e. (1+as)/(1+bs), an asymmetric rate limit which allows different positive and negative rate limits to be specified, and an addition to my previous integrator which now includes anti-wind-up. Is there any interest in such work? - my last emails in this thread seem to have been forgotten about. Alan From: Alan Teeder Sent: Monday, September 09, 2013 10:54 PM To: FlightGear developers discussions Subject: 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 <type>low-pass</type> or <type>high-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: fli...@li... 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=48808831&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... 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=48808831&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... 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=58041391&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2013-10-15 21:44:41
|
On 15 Oct 2013, at 22:36, Alan Teeder <ajt...@v-...> wrote: > I now have further have 3 further additional filter changes that I would like to have added to the xml autopilot. > > These are a lead lag filter i.e. (1+as)/(1+bs), an asymmetric rate limit which allows different positive and negative rate limits to be specified, and an addition to my previous integrator which now includes anti-wind-up. > > Is there any interest in such work? - my last emails in this thread seem to have been forgotten about. These all seem plausible to me, I suspect Torsten was just been busy. Hopefully he will see this and follow up. Kind regards, James |
From: Alan T. <ajt...@v-...> - 2013-12-15 22:17:45
|
// digitalfilter.cxx - a selection of digital filters // // Written by Torsten Dreyer // Based heavily on work created by Curtis Olson, started January 2004. // // Copyright (C) 2004 Curtis L. Olson - http://www.flightgear.org/~curt // Copyright (C) 2010 Torsten Dreyer - Torsten (at) t3r (dot) de // // Washout/high-pass filter, lead-lag filter and integrator added. // low-pass and lag aliases added to Exponential filter, // rate-limit added. A J Teeder 2013 // // This program is free software; you can redistribute it and/or // modify it under the terms of the GNU General Public License as // published by the Free Software Foundation; either version 2 of the // License, or (at your option) any later version. // // This program is distributed in the hope that it will be useful, but // WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU // General Public License for more details. // // You should have received a copy of the GNU General Public License // along with this program; if not, write to the Free Software // Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. // #include "digitalfilter.hxx" #include "functor.hxx" #include <deque> using std::map; using std::string; using std::endl; using std::cout; namespace FGXMLAutopilot { /** * * */ class DigitalFilterImplementation : public SGReferenced { protected: virtual bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode) = 0; public: virtual ~DigitalFilterImplementation() {} DigitalFilterImplementation(); virtual void initialize( double initvalue ) {} virtual double compute( double dt, double input ) = 0; bool configure( SGPropertyNode_ptr configNode ); void setDigitalFilter( DigitalFilter * digitalFilter ) { _digitalFilter = digitalFilter; } protected: DigitalFilter * _digitalFilter; }; /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ class GainFilterImplementation : public DigitalFilterImplementation { protected: InputValueList _gainInput; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: GainFilterImplementation() : _gainInput(1.0) {} double compute( double dt, double input ); }; class ReciprocalFilterImplementation : public GainFilterImplementation { public: double compute( double dt, double input ); }; class DerivativeFilterImplementation : public GainFilterImplementation { InputValueList _TfInput; double _input_1; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: DerivativeFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; class ExponentialFilterImplementation : public GainFilterImplementation { protected: InputValueList _TfInput; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); bool _isSecondOrder; double _output_1, _output_2; public: ExponentialFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; class MovingAverageFilterImplementation : public DigitalFilterImplementation { protected: InputValueList _samplesInput; double _output_1; std::deque <double> _inputQueue; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: MovingAverageFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; class NoiseSpikeFilterImplementation : public DigitalFilterImplementation { protected: double _output_1; InputValueList _rateOfChangeInput; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: NoiseSpikeFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; class RateLimitFilterImplementation : public DigitalFilterImplementation { protected: double _output_1; InputValueList _rateOfChangeMax; InputValueList _rateOfChangeMin ; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: RateLimitFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; class IntegratorFilterImplementation : public GainFilterImplementation { protected: InputValueList _TfInput; InputValueList _minInput; InputValueList _maxInput; double _input_1; double _output_1; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: IntegratorFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; class HighPassFilterImplementation : public GainFilterImplementation { protected: InputValueList _TfInput; double _input_1; double _output_1; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: HighPassFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; class LeadLagFilterImplementation : public GainFilterImplementation { protected: InputValueList _TfaInput; InputValueList _TfbInput; double _input_1; double _output_1; bool configure( const std::string & nodeName, SGPropertyNode_ptr configNode ); public: LeadLagFilterImplementation(); double compute( double dt, double input ); virtual void initialize( double initvalue ); }; /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ } // namespace FGXMLAutopilot using namespace FGXMLAutopilot; /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ DigitalFilterImplementation::DigitalFilterImplementation() : _digitalFilter(NULL) { } bool DigitalFilterImplementation::configure( SGPropertyNode_ptr configNode ) { for (int i = 0; i < configNode->nChildren(); ++i ) { SGPropertyNode_ptr prop; SGPropertyNode_ptr child = configNode->getChild(i); string cname(child->getName()); if( configure( cname, child ) ) continue; } // for configNode->nChildren() return true; } /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ double GainFilterImplementation::compute( double dt, double input ) { return _gainInput.get_value() * input; } bool GainFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if (nodeName == "gain" ) { _gainInput.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ double ReciprocalFilterImplementation::compute( double dt, double input ) { if( input >= -SGLimitsd::min() && input <= SGLimitsd::min() ) return SGLimitsd::max(); return _gainInput.get_value() / input; } /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ DerivativeFilterImplementation::DerivativeFilterImplementation() : _input_1(0.0) { } void DerivativeFilterImplementation::initialize( double initvalue ) { _input_1 = initvalue; } bool DerivativeFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if( GainFilterImplementation::configure( nodeName, configNode ) ) return true; if (nodeName == "filter-time" ) { _TfInput.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } double DerivativeFilterImplementation::compute( double dt, double input ) { double output = (input - _input_1) * _TfInput.get_value() * _gainInput.get_value() / dt; _input_1 = input; return output; } /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ MovingAverageFilterImplementation::MovingAverageFilterImplementation() : _output_1(0.0) { } void MovingAverageFilterImplementation::initialize( double initvalue ) { _output_1 = initvalue; } double MovingAverageFilterImplementation::compute( double dt, double input ) { typedef std::deque<double>::size_type size_type; size_type samples = _samplesInput.get_value(); if (_inputQueue.size() != samples) { // For constant size filters, this code executed once. bool shrunk = _inputQueue.size() > samples; _inputQueue.resize(samples, _output_1); if (shrunk) { _output_1 = 0.0; for (size_type ii = 0; ii < samples; ii++) _output_1 += _inputQueue[ii]; _output_1 /= samples; } } double output_0 = _output_1 + (input - _inputQueue.back()) / samples; _output_1 = output_0; _inputQueue.pop_back(); _inputQueue.push_front(input); return output_0; } bool MovingAverageFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if (nodeName == "samples" ) { _samplesInput.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } /* --------------------------------------------------------------------------------- */ /* --------------------------------------------------------------------------------- */ NoiseSpikeFilterImplementation::NoiseSpikeFilterImplementation() : _output_1(0.0) { } void NoiseSpikeFilterImplementation::initialize( double initvalue ) { _output_1 = initvalue; } double NoiseSpikeFilterImplementation::compute( double dt, double input ) { double delta = input - _output_1; if( fabs(delta) <= SGLimitsd::min() ) return input; // trivial double maxChange = _rateOfChangeInput.get_value() * dt; const PeriodicalValue * periodical = _digitalFilter->getPeriodicalValue(); if( periodical ) delta = periodical->normalizeSymmetric( delta ); if( fabs(delta) <= maxChange ) return (_output_1 = input); else return (_output_1 = _output_1 + copysign( maxChange, delta )); } bool NoiseSpikeFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if (nodeName == "max-rate-of-change" ) { _rateOfChangeInput.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } /* --------------------------------------------------------------------------------- */ RateLimitFilterImplementation::RateLimitFilterImplementation() : _output_1(0.0) { } void RateLimitFilterImplementation::initialize( double initvalue ) { _output_1 = initvalue; } double RateLimitFilterImplementation::compute( double dt, double input ) { double delta = input - _output_1; double output; if( fabs(delta) <= SGLimitsd::min() ) return input; // trivial double maxChange = _rateOfChangeMax.get_value() * dt; double minChange = _rateOfChangeMin.get_value() * dt; // const PeriodicalValue * periodical = _digitalFilter->getPeriodicalValue(); // if( periodical ) delta = periodical->normalizeSymmetric( delta ); output = input; if(delta >= maxChange ) output = _output_1 + maxChange; if(delta <= minChange ) output = _output_1 + minChange; _output_1 = output; return (output); } bool RateLimitFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if (nodeName == "max-rate-of-change" ) { _rateOfChangeMax.push_back( new InputValue( configNode, 1 ) ); return true; } if (nodeName == "min-rate-of-change" ) { _rateOfChangeMin.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } /* --------------------------------------------------------------------------------- */ ExponentialFilterImplementation::ExponentialFilterImplementation() : _isSecondOrder(false), _output_1(0.0), _output_2(0.0) { } void ExponentialFilterImplementation::initialize( double initvalue ) { _output_1 = _output_2 = initvalue; } double ExponentialFilterImplementation::compute( double dt, double input ) { input = GainFilterImplementation::compute( dt, input ); double tf = _TfInput.get_value(); double output; // avoid negative filter times // and div by zero if -tf == dt double alpha = tf > 0.0 ? 1 / ((tf/dt) + 1) : 1.0; if(_isSecondOrder) { output = alpha * alpha * input + 2 * (1 - alpha) * _output_1 - (1 - alpha) * (1 - alpha) * _output_2; } else { output = alpha * input + (1 - alpha) * _output_1; } _output_2 = _output_1; return (_output_1 = output); } bool ExponentialFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if( GainFilterImplementation::configure( nodeName, configNode ) ) return true; if (nodeName == "filter-time" ) { _TfInput.push_back( new InputValue( configNode, 1 ) ); return true; } if (nodeName == "type" ) { string type(configNode->getStringValue()); _isSecondOrder = type == "double-exponential"; } return false; } /* --------------------------------------------------------------------------------- */ IntegratorFilterImplementation::IntegratorFilterImplementation() : _input_1(0.0), _output_1(0.0) { } void IntegratorFilterImplementation::initialize( double initvalue ) { _input_1 = _output_1 = initvalue; } bool IntegratorFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if( GainFilterImplementation::configure( nodeName, configNode ) ) return true; if (nodeName == "u_min" ) { _minInput.push_back( new InputValue( configNode, 1 ) ); return true; } if (nodeName == "u_max" ) { _maxInput.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } double IntegratorFilterImplementation::compute( double dt, double input ) { double output = _output_1 + input * _gainInput.get_value() * dt; double u_min = _minInput.get_value(); double u_max = _maxInput.get_value(); if (output >= u_max) output = u_max; // clamping inside "::compute" prevents integrator wind-up if (output <= u_min) output = u_min; _input_1 = input; _output_1 = output; return output; } /* --------------------------------------------------------------------------------- */ HighPassFilterImplementation::HighPassFilterImplementation() : _output_1(0.0), _input_1(0.0) { } void HighPassFilterImplementation::initialize( double initvalue ) { _input_1 = initvalue; _output_1 = initvalue; } double HighPassFilterImplementation::compute( double dt, double input ) { input = GainFilterImplementation::compute( dt, input ); double tf = _TfInput.get_value(); double output; // avoid negative filter times // and div by zero if -tf == dt double alpha = tf > 0.0 ? 1 / ((tf/dt) + 1) : 1.0; output = (1 - alpha) * (input - _input_1 + _output_1); _input_1 = input; _output_1 = output; return output; } bool HighPassFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if( GainFilterImplementation::configure( nodeName, configNode ) ) return true; if (nodeName == "filter-time" ) { _TfInput.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } /* --------------------------------------------------------------------------------- */ LeadLagFilterImplementation::LeadLagFilterImplementation() : _output_1(0.0), _input_1(0.0) { } void LeadLagFilterImplementation::initialize( double initvalue ) { _input_1 = initvalue; _output_1 = initvalue; } double LeadLagFilterImplementation::compute( double dt, double input ) { input = GainFilterImplementation::compute( dt, input ); double tfa = _TfaInput.get_value(); double tfb = _TfbInput.get_value(); double output; // avoid negative filter times // and div by zero if -tf == dt double alpha = tfa > 0.0 ? 1 / ((tfa/dt) + 1) : 1.0; double beta = tfb > 0.0 ? 1 / ((tfb/dt) + 1) : 1.0; output = (1 - beta) * (input / (1 - alpha) - _input_1 + _output_1); _input_1 = input; _output_1 = output; return output; } bool LeadLagFilterImplementation::configure( const std::string & nodeName, SGPropertyNode_ptr configNode ) { if( GainFilterImplementation::configure( nodeName, configNode ) ) return true; if (nodeName == "filter-time-a" ) { _TfaInput.push_back( new InputValue( configNode, 1 ) ); return true; } if (nodeName == "filter-time-b" ) { _TfbInput.push_back( new InputValue( configNode, 1 ) ); return true; } return false; } /* --------------------------------------------------------------------------------- */ /* Digital Filter Component Implementation */ /* --------------------------------------------------------------------------------- */ DigitalFilter::DigitalFilter() : AnalogComponent(), _initializeTo(INITIALIZE_INPUT) { } DigitalFilter::~DigitalFilter() { } static map<string,FunctorBase<DigitalFilterImplementation> *> componentForge; bool DigitalFilter::configure(const string& nodeName, SGPropertyNode_ptr configNode) { if( componentForge.empty() ) { componentForge["gain"] = new CreateAndConfigureFunctor<GainFilterImplementation,DigitalFilterImplementation>(); componentForge["exponential"] = new CreateAndConfigureFunctor<ExponentialFilterImplementation,DigitalFilterImplementation>(); componentForge["low-pass"] = new CreateAndConfigureFunctor<ExponentialFilterImplementation,DigitalFilterImplementation>(); componentForge["lag"] = new CreateAndConfigureFunctor<ExponentialFilterImplementation,DigitalFilterImplementation>(); componentForge["double-exponential"] = new CreateAndConfigureFunctor<ExponentialFilterImplementation,DigitalFilterImplementation>(); componentForge["moving-average"] = new CreateAndConfigureFunctor<MovingAverageFilterImplementation,DigitalFilterImplementation>(); componentForge["noise-spike"] = new CreateAndConfigureFunctor<NoiseSpikeFilterImplementation,DigitalFilterImplementation>(); componentForge["rate-limit"] = new CreateAndConfigureFunctor<RateLimitFilterImplementation,DigitalFilterImplementation>(); componentForge["reciprocal"] = new CreateAndConfigureFunctor<ReciprocalFilterImplementation,DigitalFilterImplementation>(); componentForge["derivative"] = new CreateAndConfigureFunctor<DerivativeFilterImplementation,DigitalFilterImplementation>(); componentForge["high-pass"] = new CreateAndConfigureFunctor<HighPassFilterImplementation,DigitalFilterImplementation>(); componentForge["washout"] = new CreateAndConfigureFunctor<HighPassFilterImplementation,DigitalFilterImplementation>(); componentForge["lead-lag"] = new CreateAndConfigureFunctor<LeadLagFilterImplementation,DigitalFilterImplementation>(); componentForge["integrator"] = new CreateAndConfigureFunctor<IntegratorFilterImplementation,DigitalFilterImplementation>(); } SG_LOG( SG_AUTOPILOT, SG_BULK, "DigitalFilter::configure(" << nodeName << ")" << endl ); if( AnalogComponent::configure( nodeName, configNode ) ) return true; if (nodeName == "type" ) { string type( configNode->getStringValue() ); if( componentForge.count(type) == 0 ) { SG_LOG( SG_AUTOPILOT, SG_BULK, "unhandled filter type <" << type << ">" << endl ); return true; } _implementation = (*componentForge[type])( configNode->getParent() ); _implementation->setDigitalFilter( this ); return true; } if( nodeName == "initialize-to" ) { string s( configNode->getStringValue() ); if( s == "input" ) { _initializeTo = INITIALIZE_INPUT; } else if( s == "output" ) { _initializeTo = INITIALIZE_OUTPUT; } else if( s == "none" ) { _initializeTo = INITIALIZE_NONE; } else { SG_LOG( SG_AUTOPILOT, SG_WARN, "unhandled initialize-to value '" << s << "' ignored" ); } return true; } SG_LOG( SG_AUTOPILOT, SG_BULK, "DigitalFilter::configure(" << nodeName << ") [unhandled]" << endl ); return false; // not handled by us, let the base class try } void DigitalFilter::update( bool firstTime, double dt) { if( _implementation == NULL ) return; if( firstTime ) { switch( _initializeTo ) { case INITIALIZE_INPUT: SG_LOG(SG_AUTOPILOT,SG_DEBUG, "First time initialization of " << get_name() << " to " << _valueInput.get_value() ); _implementation->initialize( _valueInput.get_value() ); break; case INITIALIZE_OUTPUT: SG_LOG(SG_AUTOPILOT,SG_DEBUG, "First time initialization of " << get_name() << " to " << get_output_value() ); _implementation->initialize( get_output_value() ); break; default: SG_LOG(SG_AUTOPILOT,SG_DEBUG, "First time initialization of " << get_name() << " to (uninitialized)" ); break; } } double input = _valueInput.get_value() - _referenceInput.get_value(); double output = _implementation->compute( dt, input ); set_output_value( output ); if(_debug) { cout << "input:" << input << "\toutput:" << output << endl; } } |
From: Torsten D. <To...@t3...> - 2013-12-16 20:04:09
|
Hi Alan, some thoughts from a short glimpse at the code: I don't like different names (aliases) for the same thing. The exponential filter is just that, a (double) exponential filter. This is just one kind of low-pass-filter and there are many others (butterworth, chebyshev I and II, bessel etc.). Same is true for high-pass filters - which are more or less just the inverse function of the lowpass. If the high-pass implementation is a (double)exponential, we should call it that way and not just high-pass. What's the difference between the new RateLimitFilter and the existing NoiseSpikeFilter? I like the lead-lag compensator! Sorry for not taking the time to actually test the code. I just read the diff to the current version. Torsten Am 15.12.2013 23:17, schrieb Alan Teeder: > Attached is my current version of digitalfilter.cxx. The changes are > minimal and it is fully backwards compatible with the version in git. > The intention is to add common building blocks that are were in use in > analogue autopilots, and also found their way into digital autopilots. > Could the developers please review it and let me know their thoughts. > Thank you > Alan > |
From: Alan T. <ajt...@v-...> - 2013-12-17 00:44:23
|
Torsten Thank you for your response. Here are the reasons for my proposed changes. The existing exponential filter, in its 1st order form, is in fact a lag or low-pass filter. However the name exponential filter could be applied to practically any s-transform type filter and the name is therefore not sufficiently precise. Hence I have added the lag and low-pass aliases to make the meaning clearer. Both of these names are in common usage for first order filters. Higher order filters would normally be called 2nd order lag or with names such as Butterwoth etc. The existing exponential name needs to be retained for backwards compatibility, but should be deprecated. I have added a new high-pass filter, which is also a first order exponential filter. The new rate-limit filter allows separate positive and negative rate limits, whereas the existing noise-spike is in fact just a rate limit with equal limits in both directions. The noise-spike name and functionality is retained for backwards compatibility. The new integrator and lead-lag filters are both commonly used building blocks. It is true that most of these functions can be achieved using the existing code, (including the PID filters), but writing control laws in XML is already rather long -winded. I am sure that there are more elegant ways of writing such additions to the code, but I have kept it simple, in line with my own C++ expertise. Alan From: Torsten Dreyer Sent: Monday, December 16, 2013 8:11 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot filters Hi Alan, some thoughts from a short glimpse at the code: I don't like different names (aliases) for the same thing. The exponential filter is just that, a (double) exponential filter. This is just one kind of low-pass-filter and there are many others (butterworth, chebyshev I and II, bessel etc.). Same is true for high-pass filters - which are more or less just the inverse function of the lowpass. If the high-pass implementation is a (double)exponential, we should call it that way and not just high-pass. What's the difference between the new RateLimitFilter and the existing NoiseSpikeFilter? I like the lead-lag compensator! Sorry for not taking the time to actually test the code. I just read the diff to the current version. Torsten Am 15.12.2013 23:17, schrieb Alan Teeder: Attached is my current version of digitalfilter.cxx. The changes are minimal and it is fully backwards compatible with the version in git. The intention is to add common building blocks that are were in use in analogue autopilots, and also found their way into digital autopilots. Could the developers please review it and let me know their thoughts. Thank you Alan -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Torsten D. <To...@t3...> - 2013-12-17 16:30:11
|
Hi Alan, I have just pushed your code with some tiny modifications. What I have not yet pushed are the new names for existing filters. You have good points for renaming or adding aliases. If we want to change the names, I'd be fine with that. But I'd prefer to deprecate the old ones than and have a clear idea about how to migrate to the new naming scheme. Adding your new names now would let them creep into various aircraft and introduce extra work in the future. I hope, you are OK with that. Would you mind documenting your new filters in the wiki at http://wiki.flightgear.org/Autopilot_Configuration_Reference And please report, if everything is working as expected. Torsten Am 16.12.2013 21:51, schrieb Alan Teeder: > Torsten > Thank you for your response. > Here are the reasons for my proposed changes. > The existing exponential filter, in its 1st order form, is in fact a > lag or low-pass filter. However the name exponential filter could be > applied to practically any s-transform type filter and the name is > therefore not sufficiently precise. Hence I have added the lag and > low-pass aliases to make the meaning clearer. Both of these names are > in common usage for first order filters. Higher order filters would > normally be called 2nd order lag or with names such as Butterwoth etc. > The existing exponential name needs to be retained for backwards > compatibility, but should be deprecated. > I have added a new high-pass filter, which is also a first order > exponential filter. > The new rate-limit filter allows separate positive and negative rate > limits, whereas the existing noise-spike is in fact just a rate limit > with equal limits in both directions. The noise-spike name and > functionality is retained for backwards compatibility. > The new integrator and lead-lag filters are both commonly used > building blocks. > It is true that most of these functions can be achieved using the > existing code, (including the PID filters), but writing control laws > in XML is already rather long -winded. > I am sure that there are more elegant ways of writing such additions > to the code, but I have kept it simple, in line with my own C++ > expertise. > Alan > *From:* Torsten Dreyer <mailto:To...@t3...> > *Sent:* Monday, December 16, 2013 8:11 PM > *To:* FlightGear developers discussions > <mailto:fli...@li...> > *Subject:* Re: [Flightgear-devel] Autopilot filters > Hi Alan, > > some thoughts from a short glimpse at the code: > I don't like different names (aliases) for the same thing. The > exponential filter is just that, a (double) exponential filter. This > is just one kind of low-pass-filter and there are many others > (butterworth, chebyshev I and II, bessel etc.). > Same is true for high-pass filters - which are more or less just the > inverse function of the lowpass. If the high-pass implementation is a > (double)exponential, we should call it that way and not just high-pass. > > What's the difference between the new RateLimitFilter and the existing > NoiseSpikeFilter? > > I like the lead-lag compensator! > > Sorry for not taking the time to actually test the code. I just read > the diff to the current version. > > Torsten > > > Am 15.12.2013 23:17, schrieb Alan Teeder: >> Attached is my current version of digitalfilter.cxx. The changes are >> minimal and it is fully backwards compatible with the version in git. >> The intention is to add common building blocks that are were in use >> in analogue autopilots, and also found their way into digital autopilots. >> Could the developers please review it and let me know their thoughts. >> Thank you >> Alan > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > > ------------------------------------------------------------------------ > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Alan T. <ajt...@v-...> - 2013-12-17 18:40:45
|
Torsten Thanks for adding these filters One line is however needed as it implements the new asymmetric rate limit (the old noise-spike is still the name for the existing symmetric rate limit) componentForge["rate-limit"] = new CreateAndConfigureFunctor<RateLimitFilterImplementation,DigitalFilterImplementation>(); I am not sure why you object to the idea of alias names, as they allow both backwards compatibility with existing autopilots and the use of more appropriate names in newer designs. I will start work on a change to the Wiki. Regards Alan From: Torsten Dreyer Sent: Tuesday, December 17, 2013 4:37 PM To: fli...@li... Subject: Re: [Flightgear-devel] Autopilot filters Hi Alan, I have just pushed your code with some tiny modifications. What I have not yet pushed are the new names for existing filters. You have good points for renaming or adding aliases. If we want to change the names, I'd be fine with that. But I'd prefer to deprecate the old ones than and have a clear idea about how to migrate to the new naming scheme. Adding your new names now would let them creep into various aircraft and introduce extra work in the future. I hope, you are OK with that. Would you mind documenting your new filters in the wiki at http://wiki.flightgear.org/Autopilot_Configuration_Reference And please report, if everything is working as expected. Torsten Am 16.12.2013 21:51, schrieb Alan Teeder: Torsten Thank you for your response. Here are the reasons for my proposed changes. The existing exponential filter, in its 1st order form, is in fact a lag or low-pass filter. However the name exponential filter could be applied to practically any s-transform type filter and the name is therefore not sufficiently precise. Hence I have added the lag and low-pass aliases to make the meaning clearer. Both of these names are in common usage for first order filters. Higher order filters would normally be called 2nd order lag or with names such as Butterwoth etc. The existing exponential name needs to be retained for backwards compatibility, but should be deprecated. I have added a new high-pass filter, which is also a first order exponential filter. The new rate-limit filter allows separate positive and negative rate limits, whereas the existing noise-spike is in fact just a rate limit with equal limits in both directions. The noise-spike name and functionality is retained for backwards compatibility. The new integrator and lead-lag filters are both commonly used building blocks. It is true that most of these functions can be achieved using the existing code, (including the PID filters), but writing control laws in XML is already rather long -winded. I am sure that there are more elegant ways of writing such additions to the code, but I have kept it simple, in line with my own C++ expertise. Alan From: Torsten Dreyer Sent: Monday, December 16, 2013 8:11 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot filters Hi Alan, some thoughts from a short glimpse at the code: I don't like different names (aliases) for the same thing. The exponential filter is just that, a (double) exponential filter. This is just one kind of low-pass-filter and there are many others (butterworth, chebyshev I and II, bessel etc.). Same is true for high-pass filters - which are more or less just the inverse function of the lowpass. If the high-pass implementation is a (double)exponential, we should call it that way and not just high-pass. What's the difference between the new RateLimitFilter and the existing NoiseSpikeFilter? I like the lead-lag compensator! Sorry for not taking the time to actually test the code. I just read the diff to the current version. Torsten Am 15.12.2013 23:17, schrieb Alan Teeder: Attached is my current version of digitalfilter.cxx. The changes are minimal and it is fully backwards compatible with the version in git. The intention is to add common building blocks that are were in use in analogue autopilots, and also found their way into digital autopilots. Could the developers please review it and let me know their thoughts. Thank you Alan ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Torsten D. <To...@t3...> - 2013-12-19 08:34:21
|
Oops - sorry. Fixed by now. Torsten Am 17.12.2013 19:40, schrieb Alan Teeder: > componentForge["rate-limit"] = new > CreateAndConfigureFunctor<RateLimitFilterImplementation,DigitalFilterImplementation>(); |
From: James T. <zak...@ma...> - 2013-07-29 13:26:33
|
On 29 Jul 2013, at 13:54, Jon S. Berndt <jon...@co...> wrote: > Beta is positive when the wind hits the right side of the vehicle. This is > the only standard convention I have ever seen. I would recommend strongly > against artificially changing the sign of this parameter as output from > JSBSim. Which raises the question, why does Yasim use the opposite sign? Does it use the opposite sign for Beta too? James |
From: James T. <zak...@ma...> - 2013-12-17 16:48:31
|
On 17 Dec 2013, at 16:37, Torsten Dreyer <To...@t3...> wrote: > I have just pushed your code with some tiny modifications. > What I have not yet pushed are the new names for existing filters. > You have good points for renaming or adding aliases. If we want to change the names, I'd be fine with that. But I'd prefer to deprecate the old ones than and have a clear idea about how to migrate to the new naming scheme. > Adding your new names now would let them creep into various aircraft and introduce extra work in the future. Given that we are (or at least, I am!) trying to keep aircraft compatibility, I think we need to keep the old names, although Alan makes good points about his new choices. Ideally we would make the old names print very loud warnings on the console, but this is not very good - non-aircraft-developer users get drowned in warnings they can’t do anything about. I would be happy with: - add the new names - make the old names print a warning - fix all instances in fgdata But I’m not sure that is practical for the 3.0 timeframe. > Would you mind documenting your new filters in the wiki at > http://wiki.flightgear.org/Autopilot_Configuration_Reference Yes, that’s absolutely vital, it’s the primary reference for using this code in my opinion. (We should perhaps remove the bundled README.autopilot file in favour of the wiki page) Regards, James |