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
[Flightgear-devel] Autopilot filters
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, Way point, GPS definitively broken ?
Hello, James Back to the topic. Thanks for the fix , right now we can use again the Autopilot with the GPS. However the altitude is lost at each WP loading, set to Zero. We could, before, keep on the original defined AP altitude, all over the trip. I know it was not realistic. May be that cruise altitude given within the route manager could be used, to init the AP altitude, thus to keep on the right altitude along the trip. Any idea ? Thank Ahmad On 18 June 2013 01:40, grtuxhangar team hohora...@gmail.com wrote: Just tested with the Cub, working perfectly. Thank a lot Ahmad On 17 June 2013 16:42, James Turner zakal...@mac.com wrote: On 17 Jun 2013, at 15:41, grtuxhangar team hohora...@gmail.com wrote: If you refer to your last fix (yesterday) , it is not sufficient, since like said the /autopilot/settings/gps-driving-true-heading property is not set to true. No, I need to make further tweak this evening, don't worry :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Hello, Autopilot with Route manager is Longer broken, it is missing /autopilot/settings/gps-driving-true-heading triggered to true and the right /true-heading-deg which goes with it. Since the feature has not been removed from the GUI, i guess it had been broken elsewhere . Your update the GUI GPS box related is right. Thank Ahmad On 16 June 2013 23:23, James Turner zakal...@mac.com wrote: On 16 Jun 2013, at 15:46, grtuxhangar team hohora...@gmail.com wrote: Both same place , same computer.. I've just pushed a fix to FlightGear, which fixes part of this for the Cub. Please test and let me know if things are improved! Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
though not sure
gps.cxx line 774
if (!_config.driveAutopilot() || !_defaultGPSMode) {
_apDrivingFlag-setBoolValue(false);
isn't it that strange ?
_apDrivingFlag is ever set to false
On 17 June 2013 14:22, grtuxhangar team hohora...@gmail.com wrote:
Hello,
Autopilot with Route manager is Longer broken, it is missing
/autopilot/settings/gps-driving-true-heading triggered to true and the
right /true-heading-deg which goes with it.
Since the feature has not been removed from the GUI, i guess it had been
broken elsewhere .
Your update the GUI GPS box related is right.
Thank
Ahmad
On 16 June 2013 23:23, James Turner zakal...@mac.com wrote:
On 16 Jun 2013, at 15:46, grtuxhangar team hohora...@gmail.com wrote:
Both same place , same computer..
I've just pushed a fix to FlightGear, which fixes part of this for the
Cub. Please test and let me know if things are improved!
Regards,
James
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 17 Jun 2013, at 14:41, grtuxhangar team hohora...@gmail.com wrote:
though not sure
gps.cxx line 774
if (!_config.driveAutopilot() || !_defaultGPSMode) {
_apDrivingFlag-setBoolValue(false);
isn't it that strange ?
_apDrivingFlag is ever set to false
Yes, the problem is I assumed aircraft with an explicit GPS instrument are
using a fully configured setup, but in fact many (such as yours) are listing an
explicit GPS in instrumentation.xml, but relying on the default configuration.
These problems are because long ago it was decided it would be a good idea to
have the route-manager, GPS AP work in aircraft which never had such things
in real-life (Spitfires, Cubs…) , so we have to (in C++) decide if the user is
asking for a simulated GPS (which should obey electrical power, and often needs
manual synchronisation of the GPS course - CDI course, and maybe no AP at all
all), or if they are asking for the internal features to 'just work'
regardless.
Anyway, for now the fix is just to go back to the old situation, where we
assume the user wants the GPS to drive the AP all the time.
Longer term, I think I will contemplate a more radical renaming to fix the
issue, where explicit simulated GPSs such as the Garmins and so on use a
different instrument name. ('real-gps' or something) Then I could assume any
aircraft requesting a 'gps' instrument is legacy and wants the old behaviour,
but remove all the awkward defaults for people who really want full simulation.
Regards,
James--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Anyway, for now the fix is just to go back to the old situation, where we
assume the user wants the GPS to |drive the AP all the time
If you refer to your last fix (yesterday) , it is not sufficient,
since like said the /autopilot/settings/gps-driving-true-heading property
is not set to true.
Thank
Ahmad
On 17 June 2013 15:50, James Turner zakal...@mac.com wrote:
On 17 Jun 2013, at 14:41, grtuxhangar team hohora...@gmail.com wrote:
though not sure
gps.cxx line 774
if (!_config.driveAutopilot() || !_defaultGPSMode) {
_apDrivingFlag-setBoolValue(false);
isn't it that strange ?
_apDrivingFlag is ever set to false
Yes, the problem is I assumed aircraft with an explicit GPS instrument are
using a fully configured setup, but in fact many (such as yours) are
listing an explicit GPS in instrumentation.xml, but relying on the default
configuration.
These problems are because long ago it was decided it would be a good idea
to have the route-manager, GPS AP work in aircraft which never had such
things in real-life (Spitfires, Cubs…) , so we have to (in C++) decide if
the user is asking for a simulated GPS (which should obey electrical power,
and often needs manual synchronisation of the GPS course - CDI course, and
maybe no AP at all all), or if they are asking for the internal features to
'just work' regardless.
Anyway, for now the fix is just to go back to the old situation, where we
assume the user wants the GPS to drive the AP all the time.
Longer term, I think I will contemplate a more radical renaming to fix the
issue, where explicit simulated GPSs such as the Garmins and so on use a
different instrument name. ('real-gps' or something) Then I could assume
any aircraft requesting a 'gps' instrument is legacy and wants the old
behaviour, but remove all the awkward defaults for people who really want
full simulation.
Regards,
James
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 17 Jun 2013, at 15:41, grtuxhangar team hohora...@gmail.com wrote: If you refer to your last fix (yesterday) , it is not sufficient, since like said the /autopilot/settings/gps-driving-true-heading property is not set to true. No, I need to make further tweak this evening, don't worry :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Just tested with the Cub, working perfectly. Thank a lot Ahmad On 17 June 2013 16:42, James Turner zakal...@mac.com wrote: On 17 Jun 2013, at 15:41, grtuxhangar team hohora...@gmail.com wrote: If you refer to your last fix (yesterday) , it is not sufficient, since like said the /autopilot/settings/gps-driving-true-heading property is not set to true. No, I need to make further tweak this evening, don't worry :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Hello, For the record With FG Git : I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working Thank Ahmad -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
The autopilot and route manager are working for me in Boeing 777-200, but the airport/waypoint lookup box in the GPS window is missing. Saikrishna Arcot On Sun 16 Jun 2013 07:09:22 AM CDT, grtuxhangar team wrote: Hello, For the record With FG Git : I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working Thank Ahmad -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 16 Jun 2013, at 13:09, grtuxhangar team hohora...@gmail.com wrote: For the record With FG Git : I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working They're temporarily broken, not definitively broken :) I was travelling most of last week and then had to rebuild my laptop due to a failed hard-drive, later today / next week I'll be looking at a collection of related route-manager / flight-plan / GPS issues. It will help to have very precise test cases in the bug-tracker, since when I did some limited testing two weeks ago, I found searching by nearest or name did work. So really I would like to see very exact steps to reproduce, not simple 'is not working'. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Hello, It will help to have very precise test cases in the bug-tracker, since when I did some limited testing two weeks ago, I found searching by nearest or name did work. So really I would like to see very exact steps to reproduce, not simple 'is not working'. Which become an other topic :) The last time i notified a bug within bug-tracker ( was bug to me since was working with previous version ) i got an answer your request is a new feature Since to me, by using the devel list it can open a talk about the issue if it is an issue. Thank BTW: i did notice the problem with a simple aircraft without any embedded NAV AP ( Cub ) Ahmad On 16 June 2013 15:05, James Turner zakal...@mac.com wrote: On 16 Jun 2013, at 13:09, grtuxhangar team hohora...@gmail.com wrote: For the record With FG Git : I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working They're temporarily broken, not definitively broken :) I was travelling most of last week and then had to rebuild my laptop due to a failed hard-drive, later today / next week I'll be looking at a collection of related route-manager / flight-plan / GPS issues. It will help to have very precise test cases in the bug-tracker, since when I did some limited testing two weeks ago, I found searching by nearest or name did work. So really I would like to see very exact steps to reproduce, not simple 'is not working'. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 16 Jun 2013, at 13:09, grtuxhangar team hohora...@gmail.com wrote: I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. I need some help understanding this one, since you don't like to use the bug tracker please list the exact steps to reproduce the issue. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working I've just pushed a fix to the GPS box which should fix this issue, please test and let me know. (fix is in fgdata) Thanks, James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Yes, i can first, the screenshot done with my working FG version ( was an old GIT version ) with its own fgdata https://3291185c-a-62cb3a1a-s-sites.googlegroups.com/site/grtuxhangarctd/other-download/fgfs-screen-511.jpg you can notice within the autopilot box Heading setting the GPS/FMS heading is exposed after i had Activated within the Route Manager the airport way point (KSFO) and the screenshot done with the last FG Git version with the last fgdata you can notice within the autopilot box Heading setting the GPS/FMS is missing, in spite of i had Activated within the Route Manager the airport way point (KSFO) https://3291185c-a-62cb3a1a-s-sites.googlegroups.com/site/grtuxhangarctd/other-download/fgfs-screen-512.jpg Both same place , same computer.. Thank Ahmad On 16 June 2013 16:10, James Turner zakal...@mac.com wrote: On 16 Jun 2013, at 13:09, grtuxhangar team hohora...@gmail.com wrote: I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. I need some help understanding this one, since you don't like to use the bug tracker please list the exact steps to reproduce the issue. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working I've just pushed a fix to the GPS box which should fix this issue, please test and let me know. (fix is in fgdata) Thanks, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 16 Jun 2013, at 15:46, grtuxhangar team hohora...@gmail.com wrote: Both same place , same computer.. I've just pushed a fix to FlightGear, which fixes part of this for the Cub. Please test and let me know if things are improved! Regards, James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot frame rate
On Fri, 7 Oct 2011 14:48:50 +0100, Alan wrote in message 3978EF975F29409FA9418725F2E83743@AlanPC: -Original Message- From: Arnt Karlsen Sent: Friday, October 07, 2011 1:12 PM To: flightgear-devel@lists.sourceforge.net ..chk output of fgfs -v -h |less , should offer frame rate throttling on recent and git versions of FG. Arnt I assume you mean fgfs --model-hz=n This will run the whole FDM at n iterations per second, not just the autopilot system. ..nope, but I did play with --model-hz trying to debug Curt's QF-14B-uav and found it had next to zero effect on frame rates, I was trying to ease the wild ride speeding up the fdm. ;o) Alan -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot frame rate
On Thu, 13 Oct 2011 00:50:40 +0200, Arnt wrote in message 20111013005040.7edb5...@nb6.lan: On Fri, 7 Oct 2011 14:48:50 +0100, Alan wrote in message 3978EF975F29409FA9418725F2E83743@AlanPC: -Original Message- From: Arnt Karlsen Sent: Friday, October 07, 2011 1:12 PM To: flightgear-devel@lists.sourceforge.net ..chk output of fgfs -v -h |less , should offer frame rate throttling on recent and git versions of FG. Arnt I assume you mean fgfs --model-hz=n This will run the whole FDM at n iterations per second, not just the autopilot system. ..nope, ..er, yes, I misremembered the question I answered. ;o) but I did play with --model-hz trying to debug Curt's QF-14B-uav and found it had next to zero effect on frame rates, I was trying to ease the wild ride speeding up the fdm. ;o) Alan -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot frame rate
On Fri, 7 Oct 2011, Alan Teeder wrote: I am also having problems in this area. If you look at the time dependant filters they use a very simple code which easily explains the problem. It would be much better to use the Tustin substitution which is practically guaranteed to be stable, and is used in real life autopilots. However these run at fixed framerates. That should be no problem as the autopilot in FG should be running at a fixed framrate (/sim/model-hz) these days. That is, fixed in simulated time, which is all that should matter. (As an aside our time management is still pretty messy and lots of things that ought to use simulated time seems to be using real time instead - try increasing the simulation rate and see how many virtual things that do not speed up...) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot frame rate
On Fri, 7 Oct 2011 02:46:22 +0100, Peter wrote in message CADt7PXMjc9znKOo5XStyyUt7BHYRAuJ9=qt+85smq-YsP=y...@mail.gmail.com: Would it be possible to make the autopilot work at a reliable freq.. The autopilot atmo in my suspicion is bound to a frame rate.. this explains why it wobbles on my low frame rate machine.. ie laoder card.. IMHO the autopilot.. should be set at a freq eg 10hz or less and fised inc calculation .. ..chk output of fgfs -v -h |less , should offer frame rate throttling on recent and git versions of FG. Just a thought for comment.. and a new idea website.. https://sites.google.com/a/freeflightsim.org/flightgear-developers-guide/ Pete -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot frame rate
-Original Message- From: Arnt Karlsen Sent: Friday, October 07, 2011 1:12 PM To: flightgear-devel@lists.sourceforge.net ..chk output of fgfs -v -h |less , should offer frame rate throttling on recent and git versions of FG. Arnt I assume you mean fgfs --model-hz=n This will run the whole FDM at n iterations per second, not just the autopilot system. Alan -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot frame rate
There is also a frame rate throttling option, but it's pretty buried /sim/frame-rate-throttle-hz Also consider setting your sync to vblank option in your video hardware. That can help limit FlightGear to run at your display's refresh rate. Curt. On Fri, Oct 7, 2011 at 8:48 AM, Alan Teeder wrote: -Original Message- From: Arnt Karlsen Sent: Friday, October 07, 2011 1:12 PM To: flightgear-devel@lists.sourceforge.net ..chk output of fgfs -v -h |less , should offer frame rate throttling on recent and git versions of FG. Arnt I assume you mean fgfs --model-hz=n This will run the whole FDM at n iterations per second, not just the autopilot system. Alan -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilot frame rate
Would it be possible to make the autopilot work at a reliable freq.. The autopilot atmo in my suspicion is bound to a frame rate.. this explains why it wobbles on my low frame rate machine.. ie laoder card.. IMHO the autopilot.. should be set at a freq eg 10hz or less and fised inc calculation .. Just a thought for comment.. and a new idea website.. https://sites.google.com/a/freeflightsim.org/flightgear-developers-guide/ Pete -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot key bindings and the problem of backspace
Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot key bindings and the problem of backspace
On 27/09/10 21:29, Stuart Buchanan wrote: Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? My vote would be for option 1 with these further additions: a) change the behaviour of ':' so that help is shown automatically on entering the Command Mode Dialog (hide this with Tab for the experts) b) Publicise this extremely handy but little-known (to me at least) feature by adding these :-mode shortcuts to the menus - This is something I had planned anyway but was holding off on to see how the recent changes to the menu were received before embarking on fresh additions. These key sequences should also be added to the relevant documentation. A wiki page on them would be nice too. btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. A good idea but make it optional so the purists can look for the subtlety different position of the parking brake handle or the tiny hard-to-see annunciator on the panel. Certainly in real-life, I was always taught to physically feel for the parking brake position as part of my before-landing checks on a PA-28, its not something you want to get wrong, especially if its a one-wheel-at-a-time landing!: My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Best Regards Willie Fleming 0141 637 6443 07799 67 88 15 a href=http://www.uwdcvideos.co.uk/index.taf?exref=174007v=1; target=_blank img src=http://www.uwdcvideos.co.uk/images/b1.gif; border= 0 width=468 height=60/a -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot key bindings and the problem of backspace
Willie wrote: On 27/09/10 21:29, Stuart Buchanan wrote: Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? My vote would be for option 1 with these further additions: a) change the behaviour of ':' so that help is shown automatically on entering the Command Mode Dialog (hide this with Tab for the experts) b) Publicise this extremely handy but little-known (to me at least) feature by adding these :-mode shortcuts to the menus - This is something I had planned anyway but was holding off on to see how the recent changes to the menu were received before embarking on fresh additions. These key sequences should also be added to the relevant documentation. A wiki page on them would be nice too. btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. A good idea but make it optional so the purists can look for the subtlety different position of the parking brake handle or the tiny hard-to-see annunciator on the panel. Certainly in real-life, I was always taught to physically feel for the parking brake position as part of my before-landing checks on a PA-28, its not something you want to get wrong, especially if its a one-wheel-at-a-time landing!: My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart I use Ctrl W and Ctrl P a great deal without looking at the gui, and would hate to lose them. Ctrl H would be useful, but it doesn't work like the previous 2, in that it doesn't hold the current heading. ISTR that it did at one point, but would not swear to it. Similarly, Ctrl S. I think these key bindings are traditional, in that the older flight sims used them. I would expect that many of the older hands would expect them to be as they are: I wonder if a change is _really_ needed? That said I have no particular preference for either solution 2 or 3 above. Vivian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot key bindings and the problem of backspace
On 27/09/10 22:11, willie wrote: btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? It works OK - it just sends the help message to the console, which is not much use in full-screen mode. Willie -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot stage names
Sorry for replying late, I was out of town. I'm posting in haste so I apologize if I'm missing something, but was there a recent change to the autopilot system that now ignores stages if they have the same name tag as a previous stage? Previously this wasn't the case, but if it's a new addition, it could possible break some configurations that aren't expecting this. True - stages of duplicate names are ignored. Also, in the autopilot dialog box, something is now forcing the altitude to zero no matter what I change it to? Previously I could step the target altitude up and down in 100' increments using the up and down arrow keys and no matter what I do, the altitude is forced back to zero? Any ideas? This is with the Rascal110 model. I'll have a look, but not before tomorrow evening. Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilot stage names
I'm posting in haste so I apologize if I'm missing something, but was there a recent change to the autopilot system that now ignores stages if they have the same name tag as a previous stage? Previously this wasn't the case, but if it's a new addition, it could possible break some configurations that aren't expecting this. Also, in the autopilot dialog box, something is now forcing the altitude to zero no matter what I change it to? Previously I could step the target altitude up and down in 100' increments using the up and down arrow keys and no matter what I do, the altitude is forced back to zero? Any ideas? This is with the Rascal110 model. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilot properties not being updated?
Greetings, I did a GIT update and rebuild recently and have noticed that no properties under /autopilot/internal/ are being set or updated. Quite a few autopilot XML files use the lookahead speed and fdm-heading-bug-error amongst some others. Does anyone know where they went and if they are coming back. Cheers Scott. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot properties not being updated?
On 1 Jul 2010, at 19:53, Torsten Dreyer wrote: Please check if you have something like autopilot pathAircraft/Generic/generic-autopilot-helper.xml/path /autopilot near line 226 of preferences.xml If not: do a git pull on the fgdata. If yes: You found is is a bug. And if you're using the 777, it's a known bug, which has a short-term work-around; longer term, I have a rewrite of the AP pending, but it's a couple of weeks from being committed. James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot
Perhaps the PI anti-windup change could be re-visited. When the output is clamped and anti-windup is active, at xmlauto.cxx:625, the line: int_sum = clamped_output - prop_comp; seems to introduce the Kp, proportional gain factor, into the integral sum. With the proportional gain much bigger than Ki the integral part and proportional part effectively cancel after this, with the result: output close to zero. Replacing that with : if( output != clamped_output ) // anti-windup // int_sum = clamped_output - prop_comp; int_sum -= error * Ki.get_value() * dt; .. seems to restore altitude hold to at least the B777 although I don't know if that's the optimal correction to the integral term during output clamping. Thanks. I used a slightly different approach to fix this. The problem occoured when the proportional amplifier was driven into the nonlinear range and it's output was clamped. This resulted in a feedback into the integrator. Clamping the amplifier before adding the integral sum should solve this issue. Can you check, if this works for you? Thanks, Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot
Perhaps the PI anti-windup change could be re-visited. When the output is clamped and anti-windup is active, at xmlauto.cxx:625, the line: int_sum = clamped_output - prop_comp; seems to introduce the Kp, proportional gain factor, into the integral sum. With the proportional gain much bigger than Ki the integral part and proportional part effectively cancel after this, with the result: output close to zero. Replacing that with : if( output != clamped_output ) // anti-windup // int_sum = clamped_output - prop_comp; int_sum -= error * Ki.get_value() * dt; .. seems to restore altitude hold to at least the B777 although I don't know if that's the optimal correction to the integral term during output clamping. Thanks. -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot
Perhaps the PI anti-windup change could be re-visited. When the output is clamped and anti-windup is active, at xmlauto.cxx:625, the line: int_sum = clamped_output - prop_comp; seems to introduce the Kp, proportional gain factor, into the integral sum. With the proportional gain much bigger than Ki the integral part and proportional part effectively cancel after this, with the result: output close to zero. Replacing that with : if( output != clamped_output ) // anti-windup // int_sum = clamped_output - prop_comp; int_sum -= error * Ki.get_value() * dt; .. seems to restore altitude hold to at least the B777 although I don't know if that's the optimal correction to the integral term during output clamping. Thanks. I'll have a look into this later today, Thanks, Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilot
Hello ... After the recent autopilot update , altitude hold doesn't work anymore for me , (using pi-simple-controller) Im not sure what effect to expect with the anti-windup addition , but my guess is it's just exposing my poor configuration. Cheers -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot
Hello ... After the recent autopilot update , altitude hold doesn't work anymore for me , (using pi-simple-controller) Im not sure what effect to expect with the anti-windup addition , but my guess is it's just exposing my poor configuration. Syd, if you are referring to the b1900d or the Bravo, the only autopilot controllers that could be affected by the patch might be for the b1900d - Vertical Speed Hold - Descent FPM - IAS and the Bravo - Vnav Hold 1 Unless I didn't introduce a bug, pi-simple-controller with a Ki of zero (aka pure gain) should not show a behaviour other than before the change. Curt made a nice description of anti-windup at http://www.flightgear.org/Docs/XMLAutopilot/node3.html quote Integrator wind up can occur when the system simply can't get to the target value, even at full control input. For instance a large truck commanded to go 90km/hr might slow to 70km/hr on a steep hill even at full throttle. During this time while climbing the hill, the integrator term is accumulating a tremendous amount of error. This is called integrator windup. Once you hit the crest of the hill you have to overshoot the target speed for a while to ``unwind'' the integrator term (which at this point may have grown very large.) This can cause you to significantly over-speed for as long as you were undershooting the target. This can lead to many unsafe and unstable situations so ``integrator windup'' is generally considered an undesirable /quote Please let me know, if I can help fixing the problem. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot
Thanks for the explanation , that does help clear a few things .I'll probably redo these files again shortly . Cheers On Tue, Mar 16, 2010 at 2:34 AM, Torsten Dreyer tors...@t3r.de wrote: Hello ... After the recent autopilot update , altitude hold doesn't work anymore for me , (using pi-simple-controller) Im not sure what effect to expect with the anti-windup addition , but my guess is it's just exposing my poor configuration. Syd, if you are referring to the b1900d or the Bravo, the only autopilot controllers that could be affected by the patch might be for the b1900d - Vertical Speed Hold - Descent FPM - IAS and the Bravo - Vnav Hold 1 Unless I didn't introduce a bug, pi-simple-controller with a Ki of zero (aka pure gain) should not show a behaviour other than before the change. Curt made a nice description of anti-windup at http://www.flightgear.org/Docs/XMLAutopilot/node3.html quote Integrator wind up can occur when the system simply can't get to the target value, even at full control input. For instance a large truck commanded to go 90km/hr might slow to 70km/hr on a steep hill even at full throttle. During this time while climbing the hill, the integrator term is accumulating a tremendous amount of error. This is called integrator windup. Once you hit the crest of the hill you have to overshoot the target speed for a while to ``unwind'' the integrator term (which at this point may have grown very large.) This can cause you to significantly over-speed for as long as you were undershooting the target. This can lead to many unsafe and unstable situations so ``integrator windup'' is generally considered an undesirable /quote Please let me know, if I can help fixing the problem. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
Thanks James. It seems to work with my test buzzing london and associated VOR/ILS am now trying to refine autopilot in concert. pete James Turner wrote: On 28 Jan 2010, at 04:00, syd adams wrote: you can also check the instrumentation/nav/nav-loc , but it seems to stay stuck on true if you tune another frequency that's out of range or invalid... not sure when that broke. My fault, just checked the code and it's trivial to fix. WIl commit it ASAP. As ever, the sooner people report these things, the sooner I'll fix them :) James -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
Ok, and then the final step is the bits.test(bar,0). I spent a couple of minutes searching the web but could not find docs for the bits.test function. I assume bits.test(oddnumber,0) returns 1 and something else for even numbers, presumably 0? Jari - learning Nasal On 1/29/10 2:34 AM, Ron Jensen wrote: On Thu, 2010-01-28 at 21:59 +0100, Jari Häkkinen wrote: For me the Nasal function looks strange. I can't understand what the addition of 0.001 to freq does? For me it seems to be a waste of precious CPU time. Jari var bar=int((freq+0.001)*10)-int(freq)*10; The 0.001 ensures we get the proper number since 'int' truncates and doesn't round. For example, 111.70 is stored internally as 111.6... since base 2 and base 10 don't play well together below the decimal point. int((111.69...)*10) returns 1116 when what was expected and desired was 1117. 0.001 is large enough to correct the result but small enough not to push us to the next station, station spacing is assumed at 0.05. (The same problem exists in C++.) Ron -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
On Fri, 29 Jan 2010, Jari Häkkinen wrote: Ok, and then the final step is the bits.test(bar,0). I spent a couple of minutes searching the web but could not find docs for the bits.test function. I assume bits.test(oddnumber,0) returns 1 and something else for even numbers, presumably 0? You'll find bits.test() in Nasal/bits.nas (it is an FG local extension to the Nasal bits module). The return value is true (i.e. 0) or false (i.e. ==0), I would not dare to assume that 1 is always returned for true. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/-- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
On Fri, 2010-01-29 at 15:34 +0100, Anders Gidenstam wrote: On Fri, 29 Jan 2010, Jari Häkkinen wrote: Ok, and then the final step is the bits.test(bar,0). I spent a couple of minutes searching the web but could not find docs for the bits.test function. I assume bits.test(oddnumber,0) returns 1 and something else for even numbers, presumably 0? You'll find bits.test() in Nasal/bits.nas (it is an FG local extension to the Nasal bits module). The return value is true (i.e. 0) or false (i.e. ==0), I would not dare to assume that 1 is always returned for true. Cheers, Anders Right, bits.test(n,b) # checks whether bit b is set in number n So bits.test(oddnumber,0) is actually a test for oddness. the 0th bit being the only bit that is not a power of two. Ron --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
Thanks. Jari On 1/29/10 4:07 PM, Ron Jensen wrote: On Fri, 2010-01-29 at 15:34 +0100, Anders Gidenstam wrote: On Fri, 29 Jan 2010, Jari Häkkinen wrote: Ok, and then the final step is the bits.test(bar,0). I spent a couple of minutes searching the web but could not find docs for the bits.test function. I assume bits.test(oddnumber,0) returns 1 and something else for even numbers, presumably 0? You'll find bits.test() in Nasal/bits.nas (it is an FG local extension to the Nasal bits module). The return value is true (i.e.0) or false (i.e. ==0), I would not dare to assume that 1 is always returned for true. Cheers, Anders Right, bits.test(n,b) # checks whether bitb is set in numbern So bits.test(oddnumber,0) is actually a test for oddness. the 0th bit being the only bit that is not a power of two. Ron --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
On 28 Jan 2010, at 04:00, syd adams wrote: you can also check the instrumentation/nav/nav-loc , but it seems to stay stuck on true if you tune another frequency that's out of range or invalid... not sure when that broke. My fault, just checked the code and it's trivial to fix. WIl commit it ASAP. As ever, the sooner people report these things, the sooner I'll fix them :) James -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
On 28 Jan 2010, at 03:45, Ron Jensen wrote:
Here is a nasal function to determine if a frequency is a localizer. It
accepts a frequency in megahertz and returns 1 if the frequency is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
A general observation - it'd be much better to request C++ properties /
native-nasal functions that implement such logic, rather than coding it up in
Nasal (in each aircraft / instrument).
Individually each function is trivial but it does add up to a lot of Nasal
being run. I've seen other code manually computing if a VOR is in range, and
various other mathematical / trigonometric / geometric operations. In practice
the CPU hit is probably negligible, but semantically, the C++ code is already
computing all this stuff - if it's not being exposed (via properties), or being
exposed badly or unhelpfully, then I'd much prefer people complain loudly about
the fact, here.
As Syd already mentioned, this is a case in point with the nav/nav-loc property
... both that it exists, but also that it wasn't working right - but will be
(again), soon.
Regards,
James
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
On 28 Jan 2010, at 09:18, James Turner wrote: My fault, just checked the code and it's trivial to fix. WIl commit it ASAP. Committed now - also made the same fix for 'has-gs' which was similarly getting stuck on the old value when no valid station was tuned. James -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
I can't read Nasal so I can't say if the function below is correct. For
what it is worth: A frequency between 108.100 and 111.950 (including end
points) is a localizer frequency if the first decimal is an odd number.
Jari
On 2010-01-28 04.45, Ron Jensen wrote:
On Wed, 2010-01-27 at 09:06 +, Pete Morgan wrote:
I just noticed the info below about localiser on the Flight Simulation
Naviagtion site
http://www.navfltsm.addr.com/
Is there an easy way to determine is the NAV is a Lcoaliser, I cant see
that in Prop tree.
pete
Localizers are found on a few of the NAV frequencies:
http://en.wikipedia.org/wiki/Instrument_landing_system#Frequency_list
Here is a nasal function to determine if a frequency is a localizer. It
accepts a frequency in megahertz and returns 1 if the frequency is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
Nasal is like C, C++, perl, and php in many ways so if you can read any of
those, you should be pretty confident that what you think nasal is doing is
what it's actually doing. Writing nasal code from scratch is harder of
course because it requires knowledge of all the picky language syntax
details.
Curt.
On Thu, Jan 28, 2010 at 2:21 PM, Jari Häkkinen wrote:
I can't read Nasal so I can't say if the function below is correct. For
what it is worth: A frequency between 108.100 and 111.950 (including end
points) is a localizer frequency if the first decimal is an odd number.
Jari
On 2010-01-28 04.45, Ron Jensen wrote:
On Wed, 2010-01-27 at 09:06 +, Pete Morgan wrote:
I just noticed the info below about localiser on the Flight Simulation
Naviagtion site
http://www.navfltsm.addr.com/
Is there an easy way to determine is the NAV is a Lcoaliser, I cant see
that in Prop tree.
pete
Localizers are found on a few of the NAV frequencies:
http://en.wikipedia.org/wiki/Instrument_landing_system#Frequency_list
Here is a nasal function to determine if a frequency is a localizer. It
accepts a frequency in megahertz and returns 1 if the frequency is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call
away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
For me the Nasal function looks strange. I can't understand what the
addition of 0.001 to freq does? For me it seems to be a waste of
precious CPU time.
Jari
On 2010-01-28 21.39, Curtis Olson wrote:
Nasal is like C, C++, perl, and php in many ways so if you can read any
of those, you should be pretty confident that what you think nasal is
doing is what it's actually doing. Writing nasal code from scratch is
harder of course because it requires knowledge of all the picky language
syntax details.
Curt.
On Thu, Jan 28, 2010 at 2:21 PM, Jari Häkkinen wrote:
I can't read Nasal so I can't say if the function below is correct. For
what it is worth: A frequency between 108.100 and 111.950 (including end
points) is a localizer frequency if the first decimal is an odd number.
Jari
On 2010-01-28 04.45, Ron Jensen wrote:
On Wed, 2010-01-27 at 09:06 +, Pete Morgan wrote:
I just noticed the info below about localiser on the Flight
Simulation
Naviagtion site
http://www.navfltsm.addr.com/
Is there an easy way to determine is the NAV is a Lcoaliser, I
cant see
that in Prop tree.
pete
Localizers are found on a few of the NAV frequencies:
http://en.wikipedia.org/wiki/Instrument_landing_system#Frequency_list
Here is a nasal function to determine if a frequency is a
localizer. It
accepts a frequency in megahertz and returns 1 if the frequency
is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in
the business
Choose flexible plans and management services without long-term
contracts
Personal 24x7 support from experience hosting pros just a phone
call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
mailto:Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term
contracts
Personal 24x7 support from experience hosting pros just a phone call
away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
mailto:Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
On Thu, 2010-01-28 at 21:21 +0100, Jari Häkkinen wrote: I can't read Nasal so I can't say if the function below is correct. For what it is worth: A frequency between 108.100 and 111.950 (including end points) is a localizer frequency if the first decimal is an odd number. Jari Right, that's what the function checks for. As far as I can tell the property instrumentation/nav/nav-loc requires the station to be in-range. When as you say, localizer frequencies are _always_ localizer frequencies. Ron -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
On Thu, 2010-01-28 at 21:59 +0100, Jari Häkkinen wrote: For me the Nasal function looks strange. I can't understand what the addition of 0.001 to freq does? For me it seems to be a waste of precious CPU time. Jari var bar=int((freq+0.001)*10)-int(freq)*10; The 0.001 ensures we get the proper number since 'int' truncates and doesn't round. For example, 111.70 is stored internally as 111.6... since base 2 and base 10 don't play well together below the decimal point. int((111.69...)*10) returns 1116 when what was expected and desired was 1117. 0.001 is large enough to correct the result but small enough not to push us to the next station, station spacing is assumed at 0.05. (The same problem exists in C++.) Ron -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
2010/1/26 syd adams adams@gmail.com: I wouldnt spend too much time on the b1900d , as Ive already redone most of it ,and added the CLM /DSC modes , and will probably commit tonight . OK, I tuned only implemented modes on old aircraft :) My patches are only suggestions The main problem i found on that is the yaw damper was fighting any turn in roll modes,so at the moment Ive disabled it. I reduced the gain by 1/5. I think a low-pass filter could help I'm still tuning the pitch modes , i get the extreme elevator offset on mode initiaization now... don't understand :( Have you tried to initialize internal variables before mode switch? Giuseppe Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
Yes Ive sorted some of that out . What makes it a bit more difficult is that all pitch modes have to be output to target-pitch-deg to run the flight director bars . If you want to experiment with the version I just uploaded , I'm sure it could be greatly improved. But I'd prefer if you posted patches here in the development area rather than the forum. I'm not there much , so probably miss a lot. Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
you can also check the instrumentation/nav/nav-loc , but it seems to stay
stuck on true if you tune another frequency that's out of range or
invalid... not sure when that broke.
On Wed, Jan 27, 2010 at 7:45 PM, Ron Jensen w...@jentronics.com wrote:
On Wed, 2010-01-27 at 09:06 +, Pete Morgan wrote:
I just noticed the info below about localiser on the Flight Simulation
Naviagtion site
http://www.navfltsm.addr.com/
Is there an easy way to determine is the NAV is a Lcoaliser, I cant see
that in Prop tree.
pete
Localizers are found on a few of the NAV frequencies:
http://en.wikipedia.org/wiki/Instrument_landing_system#Frequency_list
Here is a nasal function to determine if a frequency is a localizer. It
accepts a frequency in megahertz and returns 1 if the frequency is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot: NAV/Localiser
It works, but the behaviour is unexpected, or I got it wrong about VOR navigation. Sounds like it could be a faulty config file ,,, but the proper way to do a VOR navigation is : Set your (VOR/LOC) frequency set your desired course / radial. Set your heading bug to intercept the course ... most autopilots ive been studying go into heading hold automatically if your outside the capture range ... then NAV engages when your in range of the course (not the station). The only way I can describe it is imagine the course as a road and your driving parallel , off the road . you turn on the autopilot and point the car towards the road ... when your close enough to the road the autopilot takes over and pulls you onto the road ... And now I'm off to design an autopilot for my car ;) Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot: NAV/Localiser
On Tue, Jan 26, 2010 at 2:36 AM, syd adams wrote: It works, but the behaviour is unexpected, or I got it wrong about VOR navigation. Sounds like it could be a faulty config file ,,, but the proper way to do a VOR navigation is : Set your (VOR/LOC) frequency set your desired course / radial. Set your heading bug to intercept the course ... most autopilots ive been studying go into heading hold automatically if your outside the capture range ... then NAV engages when your in range of the course (not the station). I would say be a little careful about what config file you use as an example. There is some slightly goofy stuff that has crept into some autopilots over the years. There are some stages that could easily be P only, but are written as PID which leads to more hunting and oscillations or long term errors than otherwise would be necessary. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot: NAV/Localiser
Curtis Olson wrote: On Tue, Jan 26, 2010 at 2:36 AM, syd adams wrote: It works, but the behaviour is unexpected, or I got it wrong about VOR navigation. Sounds like it could be a faulty config file ,,, but the proper way to do a VOR navigation is : Set your (VOR/LOC) frequency set your desired course / radial. Set your heading bug to intercept the course ... most autopilots ive been studying go into heading hold automatically if your outside the capture range ... then NAV engages when your in range of the course (not the station). I would say be a little careful about what config file you use as an example. There is some slightly goofy stuff that has crept into some autopilots over the years. There are some stages that could easily be P only, but are written as PID which leads to more hunting and oscillations or long term errors than otherwise would be necessary I fixed the ocillations on a couple of aircraft, however all the aircraft have this NAV1/VOR slow correcting error which is completely unrealistic imho, such as following a SID or STAR as the aircraft doesnt really get on course until near the VOR station. (red in the image below). http://imgur.com/LL6b9 What this implies is that say I am 100nm away from a VOR, and just within the 30 degree correction, then it would take 100nm to correct that final 30 degree. Is there a way to sort this with a PID. And as Syd pointed out with the car and road analogy, then the car would be in the ditch most of the time ! pete -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot tuning
Hi! I would like to join the discussion about AP tuning. I recently posted a message on the forum (http://www.flightgear.org/forums/viewtopic.php?f=4t=6853) for b1900d. With enclosed files, action is quite smooth and autopilot seems stable, at least on my conputer. For vertical stabilization (selected altitude holding) I used an approach very similar to the one proposed by LeeE, with a first stage that controls vertical speed (I used a proportional only stage with pi-simple-controller). I also managed the configuration in such a way to share as much stages as possible for different modes, using a flag which activates these stages. I also used several noise-spike filters in order to avoid abrupt changes. For the problem of bouncing during transition between modes, I modified the script flightdirector.nas in such a way that when pilot switches on AP or changes mode all internal variables of the autopilot are reinitialized with the current attitude of the plane. In fact, for velocity mode PIDs the memory of the past is only contained in these variables, since there isn't an integrator. I hope that it can be useful. Giuseppe leee wrote: The large initial deflections you can get when switching between different controller cascades seems to occur because on the first iteration the controller sees an error but has no 'trend history' to know how effective its correction is, and so may command the max correction. As the aircraft responds to the initial correction though, the controller gets feedback upon which it then gauges the correction for the next iteration. There are a number of ways around this, from limiting the flight control surface rate, either in the FDM config, or by inserting a filter between the output from the controller and the control axis input of the FDM, to filtering the target inputs, to using common pid controllers in the control hierarchy. I ended up using a three controller hierarchy in some aircraft, with the same lower-level controllers being used by all modes and which were always engaged; only the top level controllers were switched. For example, for altitude-hold I might have the following hierarchy: Altitude-hold: generates a target climb-rate in FPS from the difference between the current altitude and the target altitude. Climb-rate-hold: generates a target pitch angle from the difference between the current climb-rate and the target climb rate generated by the Altitude-hold controller. Pitch-hold: generates an elevator deflection from the difference betwen the current pitch and the target pitch generated by the Climb-rate-hold controller. but then I'd use the same Climb-rate-hold and Pitch-hold controllers for the glideslope-hold hierarchy and just switch the Top level Altitude hold controller off instead of duplicating the entire hierarchy again. Because the lower-level controllers are running continuously and are not switched on and off they've got some trend history data to be working with and this seems to ameliorate the problem by effectively buffering the top-level input change. This type of hierarchy isn't without its own problems though; at low airspeeds you might need the Pitch-hold controller to be pretty brutal and almost driving into oscillation but at high speeds you need it to be much more delicate. However, judicious use of filters and variable gains can usually get you around most problems. There is one type of autopilot problem that's more difficult fix though: the autopilot controllers and filters should run at a constant rate and although a rate parameter was added and initially worked, I think it may have become broken at some point and the rate at which the controllers and filters operate depends more upon the frame rate than anything else. Because the rate at which the controllers work is critical, depending upon the gains used, a controller that might be stable on one system might become unstable on a slower, or even sometimes a faster system (I've seen this sort of problems happen both ways). LeeE -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
I wouldnt spend too much time on the b1900d , as Ive already redone most of it ,and added the CLM /DSC modes , and will probably commit tonight . The main problem i found on that is the yaw damper was fighting any turn in roll modes,so at the moment Ive disabled it. I'm still tuning the pitch modes , i get the extreme elevator offset on mode initiaization now... Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
Wonderful, brilliant stuff Giuseppe, The way that the autopilot works with those patches is the way I expected. Hope this stuff makes its way into CVS so at least there's a good reference implementation. pete Giuseppe Venanzoni wrote: Hi! I would like to join the discussion about AP tuning. I recently posted a message on the forum (http://www.flightgear.org/forums/viewtopic.php?f=4t=6853) for b1900d. With enclosed files, action is quite smooth and autopilot seems stable, at least on my conputer. For vertical stabilization (selected altitude holding) I used an approach very similar to the one proposed by LeeE, with a first stage that controls vertical speed (I used a proportional only stage with pi-simple-controller). I also managed the configuration in such a way to share as much stages as possible for different modes, using a flag which activates these stages. I also used several noise-spike filters in order to avoid abrupt changes. For the problem of bouncing during transition between modes, I modified the script flightdirector.nas in such a way that when pilot switches on AP or changes mode all internal variables of the autopilot are reinitialized with the current attitude of the plane. In fact, for velocity mode PIDs the memory of the past is only contained in these variables, since there isn't an integrator. I hope that it can be useful. Giuseppe leee wrote: The large initial deflections you can get when switching between different controller cascades seems to occur because on the first iteration the controller sees an error but has no 'trend history' to know how effective its correction is, and so may command the max correction. As the aircraft responds to the initial correction though, the controller gets feedback upon which it then gauges the correction for the next iteration. There are a number of ways around this, from limiting the flight control surface rate, either in the FDM config, or by inserting a filter between the output from the controller and the control axis input of the FDM, to filtering the target inputs, to using common pid controllers in the control hierarchy. I ended up using a three controller hierarchy in some aircraft, with the same lower-level controllers being used by all modes and which were always engaged; only the top level controllers were switched. For example, for altitude-hold I might have the following hierarchy: Altitude-hold: generates a target climb-rate in FPS from the difference between the current altitude and the target altitude. Climb-rate-hold: generates a target pitch angle from the difference between the current climb-rate and the target climb rate generated by the Altitude-hold controller. Pitch-hold: generates an elevator deflection from the difference betwen the current pitch and the target pitch generated by the Climb-rate-hold controller. but then I'd use the same Climb-rate-hold and Pitch-hold controllers for the glideslope-hold hierarchy and just switch the Top level Altitude hold controller off instead of duplicating the entire hierarchy again. Because the lower-level controllers are running continuously and are not switched on and off they've got some trend history data to be working with and this seems to ameliorate the problem by effectively buffering the top-level input change. This type of hierarchy isn't without its own problems though; at low airspeeds you might need the Pitch-hold controller to be pretty brutal and almost driving into oscillation but at high speeds you need it to be much more delicate. However, judicious use of filters and variable gains can usually get you around most problems. There is one type of autopilot problem that's more difficult fix though: the autopilot controllers and filters should run at a constant rate and although a rate parameter was added and initially worked, I think it may have become broken at some point and the rate at which the controllers and filters operate depends more upon the frame rate than anything else. Because the rate at which the controllers work is critical, depending upon the gains used, a controller that might be stable on one system might become unstable on a slower, or even sometimes a faster system (I've seen this sort of problems happen both ways). LeeE -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Tuning
On Monday 25 Jan 2010, Pete Morgan wrote:
I'm having a successful time tuning my first autopilot on the
787.
I've managed to get rid of the jerks and wobbles, mainly by
using a noise-spike filter with max-rate-of-change. That
thanks to Syd Adams for that wonderful tip.
All flight level changes, and NAV, heading can be tuned very
well, at the current tuning speed of 250 knots.
However, at lower and higher speeds, the behaviour changes,
sometimes significantly.
So it it possible to have two different PID/configs's operating
at different airspeeds..
eg in psuedo code
config
{if getprop(airspeed) 150 }
Kp0.07/Kpbeta0.5/beta
{else}
Kp0.06/Kpbeta0.3/beta
{if}
/config
Hope it makes sense..
pete
You can vary the proportional gain of the pid controllers by
specifying a property and default value instead of just sticking a
fixed value between the Kp tags e.g.
Kp
prop/autopilot/FCS/settings/example-gain/prop
value-0.2/value
/Kp
...so that the actual value for Kp is read from the property tree
node /autopilot/FCS/settings/example-gain. A default vaue of -0.2
is written to this node but it can be changed in flight, either by
another pid-controller, an autopilot filter or by a Nasal script.
Having actually come across this same problem of a pid controller
becoming unstable at higher speeds, my choice was to use a
reciprocal filter to drive the gain, as the autopilot filters are
very efficient and incur very little overhead e.g.
filter
nameMach/ruddervator-pitch-trim gain reciprocal filter/name
debugfalse/debug
enable
prop/autopilot/FCS/locks/ruddervator-pitch-trim-gain/prop
valuetrue/value
/enable
typereciprocal/type
gain
prop/autopilot/settings/pitch-trim-reciprocal-gain/prop
value-0.004/value
/gain
input/velocities/mach/input
output/autopilot/FCS/settings/example-gain/output
u_min-0.02/u_min
u_max-0.005/u_max
/filter
...so that the gain value used by the altitude-hold pid-controller
is reduced as the Mach value increases. Note that you can also
vary the rate at which the pid-controller gain is backed off by
varying the filter gain, as that's also taken from a property tree
node.
Note also that you can vary the u_min and u_max clamp values for
filters and pid-controllers in flight too, by reading them from a
property tree node in the same way that you can read and change the
gains e.g.
u_min
prop/autopilot/FCS/settings/altitude-hold-umin/prop
value-200/value
/u_min
u_max
prop/autopilot/FCS/settings/altitude-hold-umax/prop
value200/value
/u_max
A word of advice though: you can end up with very complex autopilot
configurations (the last one I did was 1256 lines long), with lots
of new property tree nodes being referenced, so it pays to think it
all through first and get yourself organised so that you can keep
track of everything - don't just start adding new nodes etc.
willy-nilly. I suggest adding a new parent node beneath /autopilot
e.g. /autopilot/FCS and then add all your custom stuff beneath that
node instead of just adding lots of new nodes beneath /autopilot.
As your autopilot becomes more complex it pays to set up new
sub-parent nodes to group together each type of thing you're
working with e.g.
/autopilot/FCS/settings
/autopilot/FCS/targets
/autopilot/FCS/controls
LeeE
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Tuning
thanks lee for the reply, particular about the thinking it through part; and am already thinking about a problem I've encountered, although I'm still trying to get the hang of the autopilot. VNAV. - (don't know how to explain the problem well) I've managed to get the Altitude hold, Vertical Speed, glidescope and Pitch to work well individually, eg the Altitude Hold has a spike filter on the input which removes the lurches and violent movements. However switching between the VNAV modes causes the elevator which all the PID's are individually driving to Jump to a new position. eg switching from -1000 fps vertical speed descent to a climb to altitude hold above. This immediate elevator jump can be clearly seen on the yoke and the HUD elevator indicator and causes the aircraft to bounce around. I'm not sure how to tackle this problem, or indeed what the real problem is. One thought would be to make ALL the vnav PID's/calculations feed a single output such as target-climb-rate-fps, and then this would be filtlered to manipulate the elevator. That would mean making some convertion eg from the glideslope to target-climb-rate-fps. Another would to have some sort of crossfade as the PID's swap from one to another. Are there any existing solutions to this problem. Any advice greatly appreciated. regards pete A word of advice though: you can end up with very complex autopilot configurations (the last one I did was 1256 lines long), with lots of new property tree nodes being referenced, so it pays to think it all through first and get yourself organised so that you can keep track of everything - don't just start adding new nodes etc. willy-nilly. I suggest adding a new parent node beneath /autopilot e.g. /autopilot/FCS and then add all your custom stuff beneath that node instead of just adding lots of new nodes beneath /autopilot. As your autopilot becomes more complex it pays to set up new sub-parent nodes to group together each type of thing you're working with e.g. /autopilot/FCS/settings /autopilot/FCS/targets /autopilot/FCS/controls LeeE -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Tuning
On Monday 25 Jan 2010, Pete Morgan wrote: thanks lee for the reply, particular about the thinking it through part; and am already thinking about a problem I've encountered, although I'm still trying to get the hang of the autopilot. VNAV. - (don't know how to explain the problem well) I've managed to get the Altitude hold, Vertical Speed, glidescope and Pitch to work well individually, eg the Altitude Hold has a spike filter on the input which removes the lurches and violent movements. However switching between the VNAV modes causes the elevator which all the PID's are individually driving to Jump to a new position. eg switching from -1000 fps vertical speed descent to a climb to altitude hold above. This immediate elevator jump can be clearly seen on the yoke and the HUD elevator indicator and causes the aircraft to bounce around. I'm not sure how to tackle this problem, or indeed what the real problem is. One thought would be to make ALL the vnav PID's/calculations feed a single output such as target-climb-rate-fps, and then this would be filtlered to manipulate the elevator. That would mean making some convertion eg from the glideslope to target-climb-rate-fps. Another would to have some sort of crossfade as the PID's swap from one to another. Are there any existing solutions to this problem. Any advice greatly appreciated. regards pete The large initial deflections you can get when switching between different controller cascades seems to occur because on the first iteration the controller sees an error but has no 'trend history' to know how effective its correction is, and so may command the max correction. As the aircraft responds to the initial correction though, the controller gets feedback upon which it then gauges the correction for the next iteration. There are a number of ways around this, from limiting the flight control surface rate, either in the FDM config, or by inserting a filter between the output from the controller and the control axis input of the FDM, to filtering the target inputs, to using common pid controllers in the control hierarchy. I ended up using a three controller hierarchy in some aircraft, with the same lower-level controllers being used by all modes and which were always engaged; only the top level controllers were switched. For example, for altitude-hold I might have the following hierarchy: Altitude-hold: generates a target climb-rate in FPS from the difference between the current altitude and the target altitude. Climb-rate-hold: generates a target pitch angle from the difference between the current climb-rate and the target climb rate generated by the Altitude-hold controller. Pitch-hold: generates an elevator deflection from the difference betwen the current pitch and the target pitch generated by the Climb-rate-hold controller. but then I'd use the same Climb-rate-hold and Pitch-hold controllers for the glideslope-hold hierarchy and just switch the Top level Altitude hold controller off instead of duplicating the entire hierarchy again. Because the lower-level controllers are running continuously and are not switched on and off they've got some trend history data to be working with and this seems to ameliorate the problem by effectively buffering the top-level input change. This type of hierarchy isn't without its own problems though; at low airspeeds you might need the Pitch-hold controller to be pretty brutal and almost driving into oscillation but at high speeds you need it to be much more delicate. However, judicious use of filters and variable gains can usually get you around most problems. There is one type of autopilot problem that's more difficult fix though: the autopilot controllers and filters should run at a constant rate and although a rate parameter was added and initially worked, I think it may have become broken at some point and the rate at which the controllers and filters operate depends more upon the frame rate than anything else. Because the rate at which the controllers work is critical, depending upon the gains used, a controller that might be stable on one system might become unstable on a slower, or even sometimes a faster system (I've seen this sort of problems happen both ways). LeeE -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] Autopilot Tuning
Thanks leee.. for all the tips.. Is one of you aircraft in CVS so I cant study the autopilot. pete leee wrote: On Monday 25 Jan 2010, Pete Morgan wrote: thanks lee for the reply, particular about the thinking it through part; and am already thinking about a problem I've encountered, although I'm still trying to get the hang of the autopilot. VNAV. - (don't know how to explain the problem well) I've managed to get the Altitude hold, Vertical Speed, glidescope and Pitch to work well individually, eg the Altitude Hold has a spike filter on the input which removes the lurches and violent movements. However switching between the VNAV modes causes the elevator which all the PID's are individually driving to Jump to a new position. eg switching from -1000 fps vertical speed descent to a climb to altitude hold above. This immediate elevator jump can be clearly seen on the yoke and the HUD elevator indicator and causes the aircraft to bounce around. I'm not sure how to tackle this problem, or indeed what the real problem is. One thought would be to make ALL the vnav PID's/calculations feed a single output such as target-climb-rate-fps, and then this would be filtlered to manipulate the elevator. That would mean making some convertion eg from the glideslope to target-climb-rate-fps. Another would to have some sort of crossfade as the PID's swap from one to another. Are there any existing solutions to this problem. Any advice greatly appreciated. regards pete The large initial deflections you can get when switching between different controller cascades seems to occur because on the first iteration the controller sees an error but has no 'trend history' to know how effective its correction is, and so may command the max correction. As the aircraft responds to the initial correction though, the controller gets feedback upon which it then gauges the correction for the next iteration. There are a number of ways around this, from limiting the flight control surface rate, either in the FDM config, or by inserting a filter between the output from the controller and the control axis input of the FDM, to filtering the target inputs, to using common pid controllers in the control hierarchy. I ended up using a three controller hierarchy in some aircraft, with the same lower-level controllers being used by all modes and which were always engaged; only the top level controllers were switched. For example, for altitude-hold I might have the following hierarchy: Altitude-hold: generates a target climb-rate in FPS from the difference between the current altitude and the target altitude. Climb-rate-hold: generates a target pitch angle from the difference between the current climb-rate and the target climb rate generated by the Altitude-hold controller. Pitch-hold: generates an elevator deflection from the difference betwen the current pitch and the target pitch generated by the Climb-rate-hold controller. but then I'd use the same Climb-rate-hold and Pitch-hold controllers for the glideslope-hold hierarchy and just switch the Top level Altitude hold controller off instead of duplicating the entire hierarchy again. Because the lower-level controllers are running continuously and are not switched on and off they've got some trend history data to be working with and this seems to ameliorate the problem by effectively buffering the top-level input change. This type of hierarchy isn't without its own problems though; at low airspeeds you might need the Pitch-hold controller to be pretty brutal and almost driving into oscillation but at high speeds you need it to be much more delicate. However, judicious use of filters and variable gains can usually get you around most problems. There is one type of autopilot problem that's more difficult fix though: the autopilot controllers and filters should run at a constant rate and although a rate parameter was added and initially worked, I think it may have become broken at some point and the rate at which the controllers and filters operate depends more upon the frame rate than anything else. Because the rate at which the controllers work is critical, depending upon the gains used, a controller that might be stable on one system might become unstable on a slower, or even sometimes a faster system (I've seen this sort of problems happen both ways). LeeE -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established
Re: [Flightgear-devel] Autopilot Tuning
On Monday 25 Jan 2010, Pete Morgan wrote:
I'm having a successful time tuning my first autopilot on the
787.
I've managed to get rid of the jerks and wobbles, mainly by
using a noise-spike filter with max-rate-of-change. That
thanks to Syd Adams for that wonderful tip.
All flight level changes, and NAV, heading can be tuned very
well, at the current tuning speed of 250 knots.
However, at lower and higher speeds, the behaviour changes,
sometimes significantly.
So it it possible to have two different PID/configs's operating
at different airspeeds..
eg in psuedo code
config
{if getprop(airspeed) 150 }
Kp0.07/Kpbeta0.5/beta
{else}
Kp0.06/Kpbeta0.3/beta
{if}
/config
Hope it makes sense..
pete
You can vary the proportional gain of the pid controllers by
specifying a property and default value instead of just sticking a
fixed value between the Kp tags e.g.
Kp
prop/autopilot/FCS/settings/example-gain/prop
value-0.2/value
/Kp
If you run the CVS version (or wait a couple of days for the new release), you
can make use of even more flexible input parameters:
- specify a constant for a constant value
- specify a property name to read the value from a property
- add a scale and/or offset for linear modifications of the value
- add a condition to enable this value and choose from more than one input
Trivial example, constant
Kp0.2/Kp
Trivial example, property
Kp/some/property/Kp
More complex:
if( /foo == 123 )
Kp = /some/property * /some/other/property + 3
else
Kp = 4711
!-- case f00 == 123 --
Kp
condition
equals
property/foo/property
value123/value
/equals
/condition
property/some/property/property
scale/some/other/property/scale
offset3.0/offset
/Kp
!-- default, or else branch --
Kp4711/Kp
Recursion is supported, so something like this works:
Kp
property/some/property/property
offset
property/some/offset/property/property
scale
condition
some funky condition here
/condition
value23.0/value
condition
some other condition
/condition
I'm loosing my track here, but you might see the idea behind.
you can model polynoms like a0+a1*x+a2*x^2(+...) that way.
More examples is in Docs/README.digitalfilters or the HansaJet autopilot (work
in progress).
HTH
Torsten
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot: NAV/Localiser
Am trying to get the autopilot to follow a NAV1 course, correctly. It works, but the behaviour is unexpected, or I got it wrong about VOR navigation. Please have a look at the image link below as I am not good at explaining. http://imgur.com/LL6b9 Approaching a VOR, from say 50nm away, just off the track, then (see red on image) * the aircraft will turn toward the VOR at a maximum of 30 degree correction, * then at some point even 40 nm away it will start to slowly turn toward the VOR very very slowly and gradually correct until passing over the VOR at correct heading (where then aircraft them wobbles). * The aircraft also never seems to establish on the localiser runway center line where the error is even more critical, although I need to research more. The expected behaviour would be for the aircraft to continue at 30 and then turn directly into the radial at correct course (Blue on image) I've tried messing about with the pid, by adding gain, etc but getting nowhere. Can anyone offer some advice. TIA regards Pete -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Tuning
Would it be possible to wire up the VNav autopilot as follows, or is it a bad idea. http://i.imgur.com/UkGHG.png I'm trying to figure out a way that will allow smooth switching between the pids, which would mean taking into account the current elevator position. Also is it possible to make all the PID's active (with history as leee pointed out).. and have a switch between them pete leee wrote: On Monday 25 Jan 2010, Pete Morgan wrote: thanks lee for the reply, particular about the thinking it through part; and am already thinking about a problem I've encountered, although I'm still trying to get the hang of the autopilot. VNAV. - (don't know how to explain the problem well) I've managed to get the Altitude hold, Vertical Speed, glidescope and Pitch to work well individually, eg the Altitude Hold has a spike filter on the input which removes the lurches and violent movements. However switching between the VNAV modes causes the elevator which all the PID's are individually driving to Jump to a new position. eg switching from -1000 fps vertical speed descent to a climb to altitude hold above. This immediate elevator jump can be clearly seen on the yoke and the HUD elevator indicator and causes the aircraft to bounce around. I'm not sure how to tackle this problem, or indeed what the real problem is. One thought would be to make ALL the vnav PID's/calculations feed a single output such as target-climb-rate-fps, and then this would be filtlered to manipulate the elevator. That would mean making some convertion eg from the glideslope to target-climb-rate-fps. Another would to have some sort of crossfade as the PID's swap from one to another. Are there any existing solutions to this problem. Any advice greatly appreciated. regards pete The large initial deflections you can get when switching between different controller cascades seems to occur because on the first iteration the controller sees an error but has no 'trend history' to know how effective its correction is, and so may command the max correction. As the aircraft responds to the initial correction though, the controller gets feedback upon which it then gauges the correction for the next iteration. There are a number of ways around this, from limiting the flight control surface rate, either in the FDM config, or by inserting a filter between the output from the controller and the control axis input of the FDM, to filtering the target inputs, to using common pid controllers in the control hierarchy. I ended up using a three controller hierarchy in some aircraft, with the same lower-level controllers being used by all modes and which were always engaged; only the top level controllers were switched. For example, for altitude-hold I might have the following hierarchy: Altitude-hold: generates a target climb-rate in FPS from the difference between the current altitude and the target altitude. Climb-rate-hold: generates a target pitch angle from the difference between the current climb-rate and the target climb rate generated by the Altitude-hold controller. Pitch-hold: generates an elevator deflection from the difference betwen the current pitch and the target pitch generated by the Climb-rate-hold controller. but then I'd use the same Climb-rate-hold and Pitch-hold controllers for the glideslope-hold hierarchy and just switch the Top level Altitude hold controller off instead of duplicating the entire hierarchy again. Because the lower-level controllers are running continuously and are not switched on and off they've got some trend history data to be working with and this seems to ameliorate the problem by effectively buffering the top-level input change. This type of hierarchy isn't without its own problems though; at low airspeeds you might need the Pitch-hold controller to be pretty brutal and almost driving into oscillation but at high speeds you need it to be much more delicate. However, judicious use of filters and variable gains can usually get you around most problems. There is one type of autopilot problem that's more difficult fix though: the autopilot controllers and filters should run at a constant rate and although a rate parameter was added and initially worked, I think it may have become broken at some point and the rate at which the controllers and filters operate depends more upon the frame rate than anything else. Because the rate at which the controllers work is critical, depending upon the gains used, a controller that might be stable on one system might become unstable on a slower, or even sometimes a faster system (I've seen this sort of problems happen both ways). LeeE -- Throughout
[Flightgear-devel] Autopilot Tuning
I'm having a successful time tuning my first autopilot on the 787.
I've managed to get rid of the jerks and wobbles, mainly by using a
noise-spike filter with max-rate-of-change. That thanks to Syd
Adams for that wonderful tip.
All flight level changes, and NAV, heading can be tuned very well, at
the current tuning speed of 250 knots.
However, at lower and higher speeds, the behaviour changes, sometimes
significantly.
So it it possible to have two different PID/configs's operating at
different airspeeds..
eg in psuedo code
config
{if getprop(airspeed) 150 }
Kp0.07/Kpbeta0.5/beta
{else}
Kp0.06/Kpbeta0.3/beta
{if}
/config
Hope it makes sense..
pete
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Okay, that's a useful data point, I'll take a look at that in the next few days (in between eating too much...). I assume all interactions with the system are occurring through the radios and autopilot *dialogs* (F12 and F11), not the cockpit panel? The cockpitpanel isn't working fully right now, as not yet completed, but the dialogs and the autopilot.xml are untouched by me. Do other autopilot modes work? Do the VNAV modes work, aside from NAV1-GS hold? VNAV seems to work. Only ILS-Approaches aren't possible right now. Take a look at Syd's scripts? The core flightdirector.nas scripts are pretty clear, though as always I wish less copying of files into each aircraft went on. I already took a look into several times, but if I would able to use the Bravo-flightdirector as an example I wouldn't have said this. Syd's flightdirector seems to dependant on other things ( not always other simlated systems) so I wasn't able yet to use this. If you want help understanding what the scripts do, and how they are structured, I'm happy to (try to) help. (Actually I think the scripts could be simplified quite a bit, but Syd may disagree - he knows better than me!) That's another big point of it - still don't understand quite right waht's the script is doing, how it is structured. The flight-drector issue is complicated because the generic autopilot doesn't provide anything in this area. I have briefly wondered about writing a C++ generic flight director, but I don't think it's a good idea - people who want an accurate flight-drector for a real aircraft will find it much easier to write a specific one in Nasal (to go with a custom autopilot) than try to work with a generic C++ one, I think. But a generic flightdirector with comments written in nasal could help much more. Like the generic systems, autopilot.xml etc... I'd also be happy to start collecting an 'autopilot internals' wiki page, to collect information about this kind of thing in a proper place, and to go alongside my existing route-manager and GPS/FMS internals documents. That is a good idea! Merry Christmas HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
I already took a look into several times, but if I would able to use the Bravo-flightdirector as an example I wouldn't have said this. Syd's flightdirector seems to dependant on other things ( not always other simlated systems) so I wasn't able yet to use this. I guess a short explanation of the flight director nasal code is this: It is more or less an autopilot controller , to manage modes like armed , then capture points, and handle pilot button presses... The autopilot in passive mode IS acting as a flight director , since it goes through the motions , but doesn't output the results to the control surfaces .Those outputs can be used to animate V-bars. That nasal code probably could use a serious cleaning up , its been a learn as i go project ... Its also adapted from Curt's original flight director code , which I probably trashed trying to be helpful :) Cheers and Merry Christmas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Unfortunately they are only few ones Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Regards, James I can't use the latest data and sources, but just as compare and help: 737-300 (Using the autopilot.panel via F11)- in 19.1 the 737-300 was the airliner with the best autopilot behavior recommended for ILS-approaches done by ap. with my last built from 11/27/2009 the aircraft didn't responded anymore on NAV1-Hold and GS. Cheers HHS P.S.:I'm beware of that the actually 737-300 needs a own written flightdirector like the Citation Bravo and other aircrafts from Syd has to be real - but how to write one? __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 23 Dec 2009, at 11:42, Heiko Schulz wrote: 737-300 (Using the autopilot.panel via F11)- in 19.1 the 737-300 was the airliner with the best autopilot behavior recommended for ILS-approaches done by ap. with my last built from 11/27/2009 the aircraft didn't responded anymore on NAV1-Hold and GS. Okay, that's a useful data point, I'll take a look at that in the next few days (in between eating too much...). I assume all interactions with the system are occurring through the radios and autopilot *dialogs* (F12 and F11), not the cockpit panel? These are the kind of things that people don't mention, but make a big difference in testing. Do other autopilot modes work? Do the VNAV modes work, aside from NAV1-GS hold? P.S.:I'm beware of that the actually 737-300 needs a own written flightdirector like the Citation Bravo and other aircrafts from Syd has to be real - but how to write one? Take a look at Syd's scripts? The core flightdirector.nas scripts are pretty clear, though as always I wish less copying of files into each aircraft went on. If you want help understanding what the scripts do, and how they are structured, I'm happy to (try to) help. (Actually I think the scripts could be simplified quite a bit, but Syd may disagree - he knows better than me!) The flight-drector issue is complicated because the generic autopilot doesn't provide anything in this area. I have briefly wondered about writing a C++ generic flight director, but I don't think it's a good idea - people who want an accurate flight-drector for a real aircraft will find it much easier to write a specific one in Nasal (to go with a custom autopilot) than try to work with a generic C++ one, I think. I'd also be happy to start collecting an 'autopilot internals' wiki page, to collect information about this kind of thing in a proper place, and to go alongside my existing route-manager and GPS/FMS internals documents. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken
S Andreason wrote: configured autopilots like the senecaII, c172p, PA24-250. Well yes, but I expected the default aircraft to work. Since the manual and help windows give instructions on using Ctrl-A, Ctrl-W, Ctrl-H, etc, and F11 does open the autopilot settings, I would expect these to work. From the sounds of things, you're attempting to use the Generic Autopilot, GPS and Route Manager on the c172p. That won't work because the c172p has a KAP140 A/P, and no GPS has been integrated. So, I wouldn't expect the Route Manager or GPS to work at all. Just as the Autopilot-Autopilot Settings menu item is disabled for the c172p, so I think these keys should be disabled (and possibly any other aircraft that disable that menu item), or re-assigned to the equivalent KAP140 functions. I'll investigate how to do that, and also ensure that our documentation makes clear that aircraft may not implement the entire suite of Route-Manager/GPS/AP. Of course, once we have a C172 with a G1000 panel, then we'll have support for these goodies ;) Should the old autopilot dialog be ripped out of the c172p? and have all references to using the autopilot removed? I don't think so. The wing leveler and simple heading autopilot had value. The wing leveler and heading autopilot that are part of the KAP140 work well for the c172p. However, using the generic autopilot instead is not something that I would expect to work, so they should be disabled for the c172p. Effectively, you're using the wrong autopilot. Actually, flying the c172p (in yesterday's CVS) around in circles for 10-15 minutes trying to get the heading to go on autopilot, even setting the GPS destination, did not work for me. If it isn't really broken, it sure looks like it. AFAIK the c172p does not contain any GPS, and certainly not one that's integrated with the KAP140 AP. And if I can't figure it out, I doubt any first-time flyers will. The tutorials section of the manual describes how to use the KAP140 autopilot in some detail. http://www.flightgear.org/Docs/getstart/getstartch9.html#x15-1650009.3.1 -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken
Stuart Buchanan wrote: The wing leveler and heading autopilot that are part of the KAP140 work well for the c172p. However, using the generic autopilot instead is not something that I would expect to work, so they should be disabled for the c172p. Agreed. And the help keys removed from the help window. And [F11] disabled? Effectively, you're using the wrong autopilot. Ah, that makes sense now. Thanks, Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken,
James Turner wrote: Okay, so that's where the bug has come from, I need to fix the logic to only drive this property when GPS 'leg' mode is active. Yes, and it works now. Thank you very much! Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. When pressing the Heading Hold button on the panel, my aircraft flies in circles, because this property is constantly changing. Or with c172p press [F11] to load autopilot settings, click True Heading, and attempt to give it a heading to follow! I am surprised the c172p is broken as well, so it is not just my models. Is there a reason the Autopilot on the top menubar is greyed out? I narrowed down the time frame when this changed. It works correctly Aug.11 and early Aug.12 (stays nil until set, and stays as set), and is broken Aug.13 Changes include: P source/src/Airports/simple.hxx P source/src/Autopilot/route_mgr.cxx P source/src/Cockpit/hud.cxx P source/src/Environment/environment_ctrl.cxx P source/src/FDM/JSBSim/ 105 files updated by ehofman (Is that you Eric?) P source/src/Instrumentation/** 5 files If you press [/] right after the scenery starts loading, then quickly click down 2 directory levels, you can watch when this property starts getting set. Throttle up and the autopilot heading starts changing faster and faster, slows down at 180 from current heading, then speeds up as fast as 10 degrees per second. Quite wild. I also searched the last few months of messages, but can't find anything relevant to this. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. I think James can tell more! Cheers HHS Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. When pressing the Heading Hold button on the panel, my aircraft flies in circles, because this property is constantly changing. Or with c172p press [F11] to load autopilot settings, click True Heading, and attempt to give it a heading to follow! I am surprised the c172p is broken as well, so it is not just my models. Is there a reason the Autopilot on the top menubar is greyed out? I narrowed down the time frame when this changed. It works correctly Aug.11 and early Aug.12 (stays nil until set, and stays as set), and is broken Aug.13 Changes include: P source/src/Airports/simple.hxx P source/src/Autopilot/route_mgr.cxx P source/src/Cockpit/hud.cxx P source/src/Environment/environment_ctrl.cxx P source/src/FDM/JSBSim/ 105 files updated by ehofman (Is that you Eric?) P source/src/Instrumentation/** 5 files If you press [/] right after the scenery starts loading, then quickly click down 2 directory levels, you can watch when this property starts getting set. Throttle up and the autopilot heading starts changing faster and faster, slows down at 180 from current heading, then speeds up as fast as 10 degrees per second. Quite wild. I also searched the last few months of messages, but can't find anything relevant to this. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
S Andreason wrote: Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. P source/src/FDM/JSBSim/ 105 files updated by ehofman (Is that you Eric?) It is me indeed, but I just synchronize JSBSim CVS and FlightGear at that point. If JSBSim is the cause (which I find hard to believe at this point) then there' s something severely wrong since JSBSim has no business updating anything under /autopilot. Erik -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 21 Dec 2009, at 16:33, Heiko Schulz wrote: There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. I think James can tell more! The issue / feature here is that the route-manager code has 'always' (for years, at least) directly set /autopilot/settings/true-heading-deg based on its internal route-following logic. Personally I don't think it's a great feature, but people do use it (the route manager) in conjunction with the generic autopilot dialog to quickly navigate between waypoints. When I broke the feature by accident, it was noticed, and people asked for the feature back. As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. The GPS code sets the property /autopilot/settings/true-heading-deg if /instrumentation/gps/config/drive-autopilot is true (which is true by default). I don't know much about the details of the new gps code from James Turner, maybe he could chime in for some explanation... Greetings, Torsten -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 11:17 AM, James Turner wrote: For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. This would only have been the case if there were any pending waypoints in the route manager. If all waypoints had been reached, or no waypoints have been entered, then the 'old' route manager should not have touched the true-heading-target value. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Heiko Schulz wrote: Hi, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. Citation Bravo does not work :-( True Heading goes in circles pete -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi James, As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? Yep, and Torsten already decribed it well: The GPS code sets the property /autopilot/settings/true-heading-deg if /instrumentation/gps/config/drive-autopilot is true (which is true by default). I don't know much about the details of the new gps code from James Turner, maybe he could chime in for some explanation... On the 737 and other aircraft (except those I mentioned in my previous posting) I have to use the DTO-Mode. Otherwise it won't fly to the next waypoint. So several Aircrafts needs fixing. The other thing, but I already mentioned it in the IRC-Chat, is that NAV1-Heading-hold and NAV1-GS-Hold isn't working anymore. Only the one with nasal-scripted Autopilots. We haven't got much of them For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. It worked as long we didn't use the Route-manager. Like Curt already said, with pending waypoints the values are overwritten, but only then. That hasn't changed. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Yep, but though a lot of aircrafts has to be fixed before release, or otherwise we will really have a debacle! Cheers HHS -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Heiko Schulz wrote: Hi, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. Citation Bravo does not work :-( True Heading goes in circles pete Really with current CVS? It is the only aircraft I can use for realistic approaches, SIDs and STARs, Route-flying ... CVS 11/27/2009 Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
One note on using route manager - in a 12/13 CVS - if includes the departure airport as a waypoint automatically. If you activate it on the ground it will move past it on the takeoff roll and proceed to the next waypoint. If you don't activate it until in the air it will circle back to the departure airport as the first waypoint. Peter On Dec 21, 2009, at 12:17 PM, James Turner wrote: On 21 Dec 2009, at 16:33, Heiko Schulz wrote: There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. I think James can tell more! The issue / feature here is that the route-manager code has 'always' (for years, at least) directly set /autopilot/settings/true-heading-deg based on its internal route-following logic. Personally I don't think it's a great feature, but people do use it (the route manager) in conjunction with the generic autopilot dialog to quickly navigate between waypoints. When I broke the feature by accident, it was noticed, and people asked for the feature back. As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 21 Dec 2009, at 17:59, Heiko Schulz wrote: It worked as long we didn't use the Route-manager. Like Curt already said, with pending waypoints the values are overwritten, but only then. That hasn't changed. Okay, so that's where the bug has come from, I need to fix the logic to only drive this property when GPS 'leg' mode is active. Yep, but though a lot of aircrafts has to be fixed before release, or otherwise we will really have a debacle! It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 21 Dec 2009, at 18:10, Peter Brown wrote: One note on using route manager - in a 12/13 CVS - if includes the departure airport as a waypoint automatically. If you activate it on the ground it will move past it on the takeoff roll and proceed to the next waypoint. If you don't activate it until in the air it will circle back to the departure airport as the first waypoint. I thought I'd fixed that back at the start of October, soon after the initial commit - Curt complained that h couldn't start a route 'in-air' so I removed the need for departure/destination airports. Ah, I get it - you're specifying a departure airport, but then not activating the route until airborne. Hmm. I'm not sure that's actually a bug. Activating a route starts a leg to the first waypoint ... regardless of wether that's 'behind' you in the route or anything. In real-life I'd activate the route, then select the enroute waypoint I wanted to 'start' from, and 'DTO' on it, to head straight there - that's exactly how I fly departures where ATC vector me, then clear me to a SID waypoint. What do you think would be a sensible course of action, in the situation you describe? Even if I choose not to add the departure airport for in-air route activation, there's no guarantee that the first route waypoint is where you actually want to be going. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 12:43 PM, James Turner zakal...@mac.com wrote: It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Hi James, The one aircraft I enjoy flying is the Alphajet ... that uses the generic autopilot/route manager system. My one comment with the new route manager is that I've had some variability in the results of building a route. Maybe I'm not understanding the interface correctly, but sometimes my starting airport gets added, even when I'm in the air. Sometimes it gets in there twice. After creating a route, I always need to go in and manually clean up extraneous stuff before I get what I hoped for. (Sorry for using the word always, maybe I should say I feel like I always have to go fix the route manually.) :-P Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken
Hi James, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) I had not noticed because I have not tried using the autopilot for many months. written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own yes, Citation Bravo works for me too. configured autopilots like the senecaII, c172p, PA24-250. Well yes, but I expected the default aircraft to work. Since the manual and help windows give instructions on using Ctrl-A, Ctrl-W, Ctrl-H, etc, and F11 does open the autopilot settings, I would expect these to work. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. Ok, I figured out how to give a destination. The issue / feature here is that the route-manager code has 'always' (for years, at least) directly set /autopilot/settings/true-heading-deg based on its internal route-following logic. Personally I don't think it's a great feature, but people do use it (the route manager) in conjunction with the generic autopilot dialog to quickly navigate between waypoints. When I broke the feature by accident, it was noticed, and people asked for the feature back. As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? I guess I do. In the past this property stayed nil until set by somebody wanting autopilot to navigate on a specific heading. Or yes, if route-manager gets Activated, then it did and does set true-heading-deg as you said. As long as route-manager was deactivated or had no waypoints set, it looked like the right place to tie in my buttons on the panel. For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. No, it is not overwritten when route-manager is disabled. And if it never worked, then how did the Ctrl-W, Ctrl-H ever work?? I still think something in this part is broken. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Yes. Without a destination, the gps code sets wild headings into true-heading-deg, and makes the old autopilot controls act broken and confusing. With a destination set, the GPS code works. Should the old autopilot dialog be ripped out of the c172p? and have all references to using the autopilot removed? I don't think so. The wing leveler and simple heading autopilot had value. Is there a way to set a steady heading without writing my own code, which I thought was discouraged reinventing the wheel :) Maybe I am supposed to study and borrow the flight director code or some part of it that makes smooth turns to a set heading? Actually, flying the c172p (in yesterday's CVS) around in circles for 10-15 minutes trying to get the heading to go on autopilot, even setting the GPS destination, did not work for me. If it isn't really broken, it sure looks like it. And if I can't figure it out, I doubt any first-time flyers will. Maybe the fix for half of this, is to Deactivate the New gps code when it has no destination set. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 12:48 PM, James Turner wrote: I thought I'd fixed that back at the start of October, soon after the initial commit - Curt complained that h couldn't start a route 'in-air' so I removed the need for departure/destination airports. Ah, I get it - you're specifying a departure airport, but then not activating the route until airborne. Hmm. I'm not sure that's actually a bug. Activating a route starts a leg to the first waypoint ... regardless of wether that's 'behind' you in the route or anything. In real-life I'd activate the route, then select the enroute waypoint I wanted to 'start' from, and 'DTO' on it, to head straight there - that's exactly how I fly departures where ATC vector me, then clear me to a SID waypoint. What do you think would be a sensible course of action, in the situation you describe? Even if I choose not to add the departure airport for in-air route activation, there's no guarantee that the first route waypoint is where you actually want to be going. Conceptually, including the starting point in the route seems like it could always be problematic.The airport location is some random point on the airport grounds (probably the average of the center points of the runways.) Even if you haven't taken off yet, it would be possible in some circumstances to not fly close to the center of the airport on take off. Then you would get routed back to the starting point before you could continue on to the next way point. I think we are just getting lucky when we fly close enough to the center of the airport in most situations for most runways to satisfy the route manager and it clicks on to the next waypoint. The KSFO airport layout is very friendly in this regards, but other airports like DFW and DEN are more sprawling. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
James, this is what I've found too. Perhaps I don't understand the proper setup method, but I tend to clean it up as well. Sometimes I get a FL value, others times the point adds with a zero altitude. (or two dep. airport waypoints, one with each altitude) It may be a result of most times the route manager loads with the departure airport already listed. For the time being configure it to not load a depature airport on opening? Peter On Dec 21, 2009, at 1:51 PM, Curtis Olson wrote: On Mon, Dec 21, 2009 at 12:43 PM, James Turner zakal...@mac.com wrote: It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Hi James, The one aircraft I enjoy flying is the Alphajet ... that uses the generic autopilot/route manager system. My one comment with the new route manager is that I've had some variability in the results of building a route. Maybe I'm not understanding the interface correctly, but sometimes my starting airport gets added, even when I'm in the air. Sometimes it gets in there twice. After creating a route, I always need to go in and manually clean up extraneous stuff before I get what I hoped for. (Sorry for using the word always, maybe I should say I feel like I always have to go fix the route manually.) :-P Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hey, could we all agree it's not my fault? :) Erik -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Erik Hofman wrote: Hey, could we all agree it's not my fault? :) Sorry Erik, You are only guilty of submitting the most number of files in that 36 hour period. :) I guessed wrong. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Hey, could we all agree it's not my fault? :) Erik Only if you will correct the airport name: http://wiki.flightgear.org/index.php/File:Tu154Innsbruck.png - pretty flat for LOWI ! :-P Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken
I'll have to add also that I'm a bit confused by the recent changes (I'm sure I'll eventually figure it out) , but how is this new route manager dialog supposed to work ? I try the normal k...@35000 , and hit activate , and then I get my departure airport suddenly added to the list , which causes the aircraft to go back home again before contuing on to the destination Ive also had cases where takeoff is suddenly taken over by the autopilot , usually disasterous , but I haven't looked very closely at that one yet ...could be something Im doing wrong now... Any light shed on the new code behavior , changes , what we should and shouldn't be doing , would be really helpful. I dont like surprises , when they affect my work ;). Thanks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Heiko Schulz wrote: Hi, Hey, could we all agree it's not my fault? :) Only if you will correct the airport name: http://wiki.flightgear.org/index.php/File:Tu154Innsbruck.png - pretty flat for LOWI ! :-P Admittedly I already wondered about it :) But i never thought it would be Schiphol. Anyhow, the filename isn't changed but the corresponding text is. Erik -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
