Nasal Flightplan: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (Add WIP notice)
(Some more cleanup; comment out examples for now, because it uses APIs that aren't implemented. (Several bits of this article appear to have been based on the Airbus A320neo implementation of an FMS)
Line 4: Line 4:
{{Nasal Navigation}}
{{Nasal Navigation}}


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.
Because FlightGear's [[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
The Nasal functions relating to the route manager system include:
* {{func link|flightplan()}}
* {{func link|airwaysRoute()|page=Nasal library}}


== Flightplan ==
Flightplans are based on waypoints, which, in C++, inherit from the {{API Link|flightgear|class|FGPositioned}} class.
<syntaxhighlight lang="nasal">
 
appendWP        : func(wp)      : int    // returns the index it was inserted at
=== Waypoint hashes ===
insertWP        : func(wp, idx)
The following are members of a waypoint ghost, as generated by, for example, {{func link|airwaysRoute()|page=Nasal library}}:
insertWPAfter  : func(wp, idx)
replaceWPAt    : func(wp, idx)
findWPName      : func(name)   : fmsWP
findWPType      : func(type)    : fmsWP
getWP          : func(idx)    : fmsWP
clearPlan      : func()
getPlanSize    : func()        : int
clearWPType    : func(type)
</syntaxhighlight>


=== Procedure and waypoint hashes ===
; wp_name : Name of the waypoint, returned as string.
<syntaxhighlight lang="nasal">
; wp_type : Waypoint type, returned as string. One of "basic," "navaid," "offset-navaid," "runway," "hdgToAlt," "dmeIntercept," "radialIntercept," or "vectors."
The fmsWP model class contains;
; wp_role: Role of waypoint.
        me.wp_name        = "";        # fix, navaid or pseudo waypoint name
; wp_lat ''or'' lat : Latitude of waypoint.
        me.wp_parent_name = "";        # if a SID/STAR WP then the SID/STAR name, or AIRWAY name
; wp_lon ''or'' lon : Longitude of waypoint.
        me.wp_type        = "FIX";      # FIX, NAVAID, Termination Point, transition wp, Final Fix, Appr Fix, RWY transition, SID/STAR WP,
; wp_parent_name : Name of waypoint's parent.
        me.fly_type      = "FlyOver";  # flyOver, flyBy, Hold,  
; wp_parent : Waypoint's parent.
        me.action        = "DIRECT";  # direct, trk, intercept, vectors (not used)
; fly_type : How to waypoint should be flown over or reacted to. One of "Hold," "flyOver," or "flyBy."
        me.wp_lat         = 0.0;       # latitude
; heading_course : Heading of runway.
        me.wp_lon         = 0.0;       # longitude
        me.alt_cstr      = 0;         # alt constraint from db or calculated altitude in ft
        me.alt_cstr_ind  = 0;          # if the alt is a programmed constraint or just calculated (as part of STAR)
        me.spd_cstr      = 0;          # spd constraint in kts, mach or zero
        me.spd_cstr_ind  = 0;          # 0 - calculated speed, 1 - constraint
        me.hdg_radial    = 0.0;       # either heading/track or radial
        me.leg_distance  = 0;          # NM for this leg
        me.leg_bearing    = 0.0;        # deg bearing for this leg
</syntaxhighlight>


== Examples ==
<!-- == 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 193: Line 177:
}
}


</syntaxhighlight>
</syntaxhighlight> -->


[[Category:Nasal]]
[[Category:Nasal]]
[[Category: Core development projects]]
[[Category: Core development projects]]
[[Category: Core developer documentation]]
[[Category: Core developer documentation]]

Revision as of 21:47, 8 November 2015

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.
Note  Whenever possible, please refrain from modeling complex systems, like an FDM, autopilot or Route Manager with Nasal. This is primarily to help reduce Nasal overhead (especially GC overhead). It will also help to unify duplicated code. The FlightGear/SimGear code base already contains fairly generic and efficient systems and helpers, implemented in C++, that merely need to be better generalized and exposed to Nasal so that they can be used elsewhere. For example, this would enable Scripted AI Objects to use full FDM implementations and/or built-in route manager systems.

Technically, this is also the correct approach, as it allows us to easily reuse existing code that is known to be stable and working correctly, .

For details on exposing these C++ systems to Nasal, please refer to Nasal/CppBind. If in doubt, please get in touch via the mailing list or the forum first.


Because FlightGear's 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

The Nasal functions relating to the route manager system include:

Flightplans are based on waypoints, which, in C++, inherit from the FGPositioned (doxygen) class.

Waypoint hashes

The following are members of a waypoint ghost, as generated by, for example, airwaysRoute() :

wp_name
Name of the waypoint, returned as string.
wp_type
Waypoint type, returned as string. One of "basic," "navaid," "offset-navaid," "runway," "hdgToAlt," "dmeIntercept," "radialIntercept," or "vectors."
wp_role
Role of waypoint.
wp_lat or lat
Latitude of waypoint.
wp_lon or lon
Longitude of waypoint.
wp_parent_name
Name of waypoint's parent.
wp_parent
Waypoint's parent.
fly_type
How to waypoint should be flown over or reacted to. One of "Hold," "flyOver," or "flyBy."
heading_course
Heading of runway.