Nasal Flightplan: Difference between revisions

Jump to navigation Jump to search

Nasal Flightplan (view source)

Revision as of 19:45, 8 November 2015

3,375 bytes removed ,  8 November 2015
Start rewriting and cleanup
No edit summary
(Start rewriting and cleanup)
Line 1: Line 1:
{{Systems_Modeling_Disclaimer}}
{{Systems Modeling Disclaimer}}
{{Autoflight Navigation}}
{{Autoflight Navigation}}
{{Template:Nasal Navigation}}
{{Nasal Navigation}}


Discussion of interacting with the [[Route manager]] and flight-planning via Nasal.
Because FlightGear's [[autopilot]]/[[route manager]] flightplan system is exposed to [[Nasal]], '''Nasal can be used to interact with flightplans'''. Obviously, this is very useful, especially for aircraft like airliners, which have complex route managers systems. This article shows how this can be done.


== Background ==
== Background ==
The C++ route manager system relies on


Several advanced aircraft have created FMS and CDU implementations using custom Nasal code, with some (or no) interaction with the C++ route-manager, and often with code that overlaps. There's a goal to improve this, while keeping the complex, especially aircraft-dependant functionality in Nasal so it can be tailored and extended easily.
== Flightplan ==
 
<syntaxhighlight lang="nasal">
Scott has defined a FMS procedure, flight-plan and waypoint interface in Nasal, which James intends to replicate and extend from the C++ side, and then hopefully aircraft can be ported to use this instead of their own route and flight plan structures. Thus the C++ code and Nasal model will be in sync, and the user experience will be better!
 
== Data Sources ==
 
The current C++ code reads airways data from airways.dat, and can read the Level-D 767 procedure files if they are added to the Airports scenery data. However, it's intended that any other format can be supported.
 
== Current Nasal Model ==
 
As defined by Scott several years ago, basically stable and working but independent of the route-manager at the moment. (Where does it load procedure data from? Or airways data?)
 
=== Flightplan ===
<pre>
appendWP        : func(wp)      : int    // returns the index it was inserted at
appendWP        : func(wp)      : int    // returns the index it was inserted at
insertWP        : func(wp, idx)
insertWP        : func(wp, idx)
Line 31: Line 20:
getPlanSize    : func()        : int
getPlanSize    : func()        : int
clearWPType    : func(type)
clearWPType    : func(type)
</pre>
</syntaxhighlight>
 
=== FMS DB functions ===
<pre>
fmsDB
new            : func(icao)
getSIDList      : func(runway)
getSTARList    : func(runway) 
getApproachList : func(runway, radio)
getSid          : func(name)
getStar        : func(name)
getIAP          : func(name)
</pre>
 
=== Procedure and Waypoint hashes ===
<pre>
These return a fmsTP class or an array of fmsTP that then contain an array of fmsWP amongst other things;
        me.wp_name        = "";
        me.tp_type        = "";        # SID, STAR, IAP
        me.radio          = "";        # ILS, VOR, NDB, RNAV approach
        me.runways        = [];        # array of runway names of this procedure
        me.wpts          = [];        # array of fmsWP
        me.rwy_tw        = [];        # array of runway transition waypoints if SID or approach transition for STAR
        me.transitions    = [];        # array of transition paths
 


=== Procedure and waypoint hashes ===
<syntaxhighlight lang="nasal">
The fmsWP model class contains;
The fmsWP model class contains;
         me.wp_name        = "";        # fix, navaid or pseudo waypoint name
         me.wp_name        = "";        # fix, navaid or pseudo waypoint name
Line 72: Line 39:
         me.leg_distance  = 0;          # NM for this leg
         me.leg_distance  = 0;          # NM for this leg
         me.leg_bearing    = 0.0;        # deg bearing for this leg
         me.leg_bearing    = 0.0;        # deg bearing for this leg
</pre>
</syntaxhighlight>
 
== Proposed Nasal API ==
 
* The fmsDB is mostly subsumed by the methods James is adding to the airport hash - only a couple more are required to get a 'procedure' hash corresponding to a flightgear::Procedure
* the fmsWP hash will stay almost the same, but gain some methods to set explicit or calculated speeds, and attach custom data.
* the flightplan class will gain methods and state to tracy departure and arrival airport / runway / procedures explicit, as the C++ code already does
* flightplan will support setting callback functions for Nasal to (re-) compute pseudo waypoints and VNAV profile when waypoints are added/removed/edited
* Although flight plans will support loading and saving to a standard XML format, it should be possible with the API to use Nasal to parse (or write) any other file format, and then build the flight plan using the setter methods. Moving the standard XML loading and saving to Nasal (from C++) would be a nice bonus.
 
== To Be Decided ==
 
* In the current C++ API, the route-manager sets the runway / procedure, and the transition is automatically selected, and the waypoints inserted into the flight-plan. In the code below I'm (James) exposing this logic to Nasal, on the assumption that any other behaviour is more complicated and unnecessary. If it's better, to follow Scott's API above, then instead 'procedure' would simple expose its waypoints as an array, and flight plan would gain a 'insertWaypoints(type, waypoint_vec), where type is 'sid', 'star', 'approach' or similar. (And the code knows the correct insert location). This needs another callback when the departure or arrival data changes from 'outside', i.e the route-manager properties or similar.
 
== Example Nasal ==


== Examples ==
Setting flight-plan global (non-waypoint) data. Potentially this can include lots of FMS data - cruise profile, EPR setting, company route ID and so on. But most of that is probably better handled in Nasal, so long as the flight plan object provides a way to persist it.
Setting flight-plan global (non-waypoint) data. Potentially this can include lots of FMS data - cruise profile, EPR setting, company route ID and so on. But most of that is probably better handled in Nasal, so long as the flight plan object provides a way to persist it.
<syntaxhighlight lang="nasal">
<syntaxhighlight lang="nasal">
Line 177: Line 131:
# (maybe not saved to XML? depends on the type)
# (maybe not saved to XML? depends on the type)
wpt.setData('customfield', ..... any nasal var .... );
wpt.setData('customfield', ..... any nasal var .... );
</syntaxhighlight>
</syntaxhighlight>


Line 201: Line 154:


# any other way of building up an array of waypoints is also find - suggestions?
# any other way of building up an array of waypoints is also find - suggestions?
</syntaxhighlight>
</syntaxhighlight>


Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/89443"

Navigation menu