Board index FlightGear Development Aircraft Autopilot and route manager

Route manager leg modes

Designing a stable autopilot is one of the hardest things. Need help?

Route manager leg modes

Postby Alant » Tue Aug 18, 2015 11:14 pm

I am trying to make the route manager follow the tracks between waypoints. At the moment I do not care if this is done by anticipating the waypoint when making the turn, or by starting the turn at the waypoint, overshooting the new track and then coming back onto the new track.
However all I have been able to achieve so far is the turn starts over the waypoint, and then the aircraft flies directly to the next waypoint, making no attempt to get back to the leg track.
A picture is always better. I want either of the Fly-by, Track to fix, or Fly-over, Track to Fix shown in http://fgfs.goneabitbursar.com/screenshots/FlyByType-LegType.svg, but can only achieve Fly-over, Direct to Fix.
I include an example route
Code: Select all
<?xml version="1.0"?>

<PropertyList>
   <version type="int">2</version>
   <route>
      <wp>
         <type type="string">navaid</type>
         <alt-restrict type="string">at</alt-restrict>
         <altitude-ft type="double">30</altitude-ft>
         <ident type="string">EGNO</ident>
         <lon type="double">-2.900178</lon>
         <lat type="double">53.741567</lat>
      </wp>
      <wp n="1">
         <type type="string">basic</type>
         <alt-restrict type="string">at</alt-restrict>
         <altitude-ft type="double">96</altitude-ft>
         <ident type="string">Preston</ident>
         <lon type="double">-2.714973</lon>
         <lat type="double">53.763039</lat>
      </wp>
      <wp n="2">
         <type type="string">basic</type>
         <alt-restrict type="string">at</alt-restrict>
         <altitude-ft type="double">682</altitude-ft>
         <ident type="string">HebdenBridge</ident>
         <lon type="double">-2.012719</lon>
         <lat type="double">53.742409</lat>
      </wp>
      <wp n="3">
         <type type="string">basic</type>
         <alt-restrict type="string">at</alt-restrict>
         <altitude-ft type="double">308</altitude-ft>
         <ident type="string">Huddersfield Mkt</ident>
         <lon type="double">-1.782228</lon>
         <lat type="double">53.646672</lat>
      </wp>
      <wp n="4">
         <type type="string">basic</type>
         <alt-restrict type="string">at</alt-restrict>
         <altitude-ft type="double">772</altitude-ft>
         <ident type="string">DerwentDam</ident>
         <lon type="double">-1.741897</lon>
         <lat type="double">53.404875</lat>
      </wp>
      <wp n="5">
         <type type="string">basic</type>
         <alt-restrict type="string">at</alt-restrict>
         <altitude-ft type="double">1303</altitude-ft>
         <ident type="string">HucklowAirfield</ident>
         <lon type="double">-1.730856</lon>
         <lat type="double">53.304587</lat>
      </wp>
      <wp n="6">
         <type type="string">navaid</type>
         <alt-restrict type="string">at</alt-restrict>
         <altitude-ft type="double">30</altitude-ft>
         <ident type="string">EGNO</ident>
         <lon type="double">-2.900178</lon>
         <lat type="double">53.741567</lat>
      </wp>
   </route>
</PropertyList>


and my gps/route manager configuration, which is in my aircraft.set file.
Code: Select all
   <gps n="0">
       <serviceable type="bool">true</serviceable>
<!--      <cdi-deflection>0</cdi-deflection>
      <indicated-track-true-deg>0</indicated-track-true-deg>
      <indicated-ground-speed-kt>0</indicated-ground-speed-kt>
      <raim>0</raim>
      <wp>
         <leg-true-course-deg>0</leg-true-course-deg>
         <leg-mag-course-deg>0</leg-mag-course-deg>
         <leg-distance-nm>0</leg-distance-nm>
         <wp n="1">
            <course-error-nm>0</course-error-nm>
            <distance-nm>0</distance-nm>
            <bearing-true-deg type="double">0</bearing-true-deg>
         </wp>
      </wp> -->
      <config>
         <turn-anticipation type="bool">true</turn-anticipation>
         <drive-autopilot type="bool">true</drive-autopilot>
         <follow-leg-track-to-fix type="bool">true</follow-leg-track-to-fix>
      </config>
   </gps>


This is as basic as it can get, but before I start coding my real route manager code I need to find out how I can control it.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Route manager leg modes

Postby Johan G » Wed Aug 19, 2015 1:26 am

I would guess you know better than me, but is there any properties exposing how far perpendicular off track and/or how from from the track heading one is? If it was, one should be able to set up autopilot filters.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Route manager leg modes

Postby Alant » Wed Aug 19, 2015 8:57 am

Yes Johan, these prperties are all available, and therefore I could use a VOR/ILS beam capture algorithm to do the job. However my reading of the various wiki articles leads me to believe that the Route manager/GPS code already includes this.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Route manager leg modes

Postby Hooray » Wed Aug 19, 2015 11:13 am

I guess, you would be better off asking Zakalawe directly - but if you cannot find it in the code, it's probably not there: http://sourceforge.net/p/flightgear/fli ... te_mgr.cxx

Personally, I am not convinced that we should continue with a hard-coded route manager, implemented in C++, at all - especially given that quite a few aircraft have begun implementing their own scripted variants - in the mid term, I would hope that there's simply a RM infrastructure in place that can be augmented via Nasal delegates (e.g. via cppbind). The route manager currently being a singleton "by accident" is another unnecessary issue, that is preventing people from using it elsewhere (e.g. for AI traffic).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Route manager leg modes

Postby Alant » Wed Aug 19, 2015 12:15 pm

It probably is in the code, but this is spread over quite a few files - and I can´t find the wood in the trees.

Re your comments on the hard-coded RM, the wiki has great notices saying the exact opposite. ,-(

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Route manager leg modes

Postby Alant » Wed Aug 19, 2015 11:34 pm

Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.
A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.
As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage.

I think that Mr Z is on holiday this week, so will have to wait until he is back.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Route manager leg modes

Postby Hooray » Thu Aug 20, 2015 11:29 am

to be honest, there is only so much that can be done by having "mode properties" and properties to customize those modes.

So I do think that delegating this to scripting space is the right thing to do (e.g. via design patterns/OO) - no matter if core developers agree with this or not, it has already been happening in a variety of places anyway.

The only question is whether this is going to be actively supported by core developers (so that performance critical stuff remains in C/C++ space), or if "external contributors" (non core developers) are going to have to work around all the awkward RM functionality that they want to replace, which will sooner or later mean that the RM will be entirely replaced with a scripted implementation, without any code reuse.

The latter has already happened with some aircraft's autopilots, simply because the AP/property rule system isn't exposed at all to scripting space, despite it being much more powerful, much faster (it being native code) and much more elegant/flexible than any scripted AP code we've seen so far.

Given the complexity, and variety, of modern aircraft systems that are intended to be emulated via AP/RM building blocks, it makes absolutely sense to expose this to scripting space via cppbind, so that Nasal can be used to augment/customize existing functionality - but also so that multiple instances of APs/RMs may co-exist (think AI traffic, independent aircraft systems, or even scripted demos/benchmarks etc)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Route manager leg modes

Postby Johan G » Fri Aug 21, 2015 10:16 pm

Hooray wrote in Thu Aug 20, 2015 11:29 am:to be honest, there is only so much that can be done by having "mode properties" and properties to customize those modes.

I assume you mean that in regard to the route manager.

Hooray wrote in Thu Aug 20, 2015 11:29 am:... the AP/property rule system isn't exposed at all to scripting space ...

Unless the aircraft/system developer expose the relevant input/output properties to the property tree and make them available to scripting space that way. ;)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Route manager leg modes

Postby Hooray » Sat Aug 22, 2015 1:08 pm

Johan G wrote in Fri Aug 21, 2015 10:16 pm:
Hooray wrote in Thu Aug 20, 2015 11:29 am:... the AP/property rule system isn't exposed at all to scripting space ...

Unless the aircraft/system developer expose the relevant input/output properties to the property tree and make them available to scripting space that way. ;)


no, you're mistaken or your understanding is just incomplete: http://wiki.flightgear.org/Template:Cpp ... erty_Rules

Subject: 2 Questions: vacuum & electrical
Torsten wrote in Thu Feb 02, 2012 10:08 pm:I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind. This _might_ end up in something like
Code: Select all
var myPid = pidController.new();
myPid.Td = 0.0001;
myPid.Ti = 123.4;
myPid.Kp = 0.2;
myPid.input = "/foo";
myPid.reference = "/bar";
myPid.output = "/baz";

etc, etc.

But that's probably a little off topic now.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Route manager leg modes

Postby Johan G » Sat Aug 22, 2015 11:16 pm

Johan G wrote in Fri Aug 21, 2015 10:16 pm:Unless the aircraft/system developer expose the relevant input/output properties to the property tree and make them available to scripting space that way. ;)

Hooray wrote in Sat Aug 22, 2015 1:08 pm:no, you're mistaken or your understanding is just incomplete: http://wiki.flightgear.org/Template:Cpp ... erty_Rules

I must have misunderstood what you meant. What I meant was for example something like this (though I am not completely sure it would work fully):
Code: Select all
 <filter>
   <type>gain</type>
   <gain>/some/gain/property</gain>
   <input>/some/input/property</input>
   <output>/some/output/property</output>
 </filter>
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit


Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 0 guests