FG1000: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(239 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Stub}}
 
[[File:Mirrored MFD.png|thumb|FG1000 MFD being displayed (incorrectly!) in a DA-40, and mirrored to a GUI window at 50% scale (02/2018)]]
[[File:FG1000 SVG UI.jpg|thumb|Stuart pushed an SVG UI for the FG1000, replacing the PUI version. (01/2018)]]
 
{{Infobox subsystem
|name        = FG1000
|started      = 07/2017
|description  = G1000-based MFD emulation
|status      = Under active development as of 07/2017
|developers  = {{Usr|Stuart}}, Richard (via [[Emesary]]), Michat (UI graphics), www2 (3D artwork) <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=32764&start=60#p327229</ref>
|changelog = {{fgdata source | path = Aircraft/Instruments-3d/FG1000/ | view = log}}
|folders =  {{fgdata source | path = Aircraft/Instruments-3d/FG1000/}}
}}
 
The FG1000 is a simulation of the Garmin G1000 glass panel flight deck.  The FG1000 was developed in reference to the pilot's manual for the Cessna NAVIII variant, as fitted to the Cessna 182, but is designed to be flexible and also work with other airframes.  For detailed instructions on how to use it, refer to the [https://static.garmin.com/pumac/G1000:CessnaNavIII_PilotsGuide_SystemSoftwareVersion0563.11orlater_.pdf Garmin Pilot's Guide].  Or read the Cheat's guide below.
 
== Current Status (26/08/2020) ==
 
Key features:
* Primary Flight Display (PFD).  Fully functional and 99% complete vs. the real thing.  (Alerts, ALT units and alternative HSI displays are the remaining pieces)
* Multi Function Display (MFD).  Fully functional and 90% complete vs. the real thing.  Includes moving map, navigation features, flightplan, traffic, engine information. .
* MFD and PFD can be displayed
** as part of an aircraft cockpit
** as a window within FlightGear
** on a separate window or monitor using [[FGQCanvas]]. 
* GFC700 autopilot.  Fully functional and integrated with the route manager, PFD and MFD.  Includes all modes apart from VNV (vertical navigation to follow a flightplan) and BC (ILS back-course).
 
The following aircraft are available from the official hangar and use the FG1000:
* [[Cessna 182S|Cessna 182T]] (c182t)
* [[Diamond DA40]] (da40)
* [[Piper J3 Cub]] (j3cub)
 
Next steps:
* Writing the remaining pages
* Styling the pages - making the iconography match Garmin exactly.
 
=== Gallery ===
<gallery mode=packed widths=230px heights=230px>
PFD 20180406.png|FG1000 PFD showing inset map, current wind data, HSI with GPS bearing, active flightplan list
MFD 20180406.png|FG1000 MFD with Cessna 182T Engine Information System (EIS), and Active Flightplan
FG1000_Checklist_MFD_page.png|FG1000 MFD with Checklist page displayed
</gallery>
 
== A Cheat's Guide to Using the FG1000 ==
 
For those without the time or interest to read the G1000 User Guide, here's a very quick run-down on navigating through the MFD:
 
General:
* Click on the buttons, though some are not implemented yet.
* Use the mouse wheel to scroll the knobs (NAV, HDG, ALT, COM, CRS/BARO, RANGE, FMS).  For knobs with both and inner and an outer (NAV, COM, CRS/BARO, FMS), scrolling when pressing the Shift key changes the outer knob.
* Use the outer FMS knob (shift-mouse wheel on the FMS knob on the bottom right) to navigate through the page groups.
* Use the inner FMS knob (mouse wheel on the FMS knob on the bottom right) to navigate through the pages within the group.  The currently selected page is shown in blue. If you stop moving the cursor, the page will be loaded in 0.5s.
* Within a page, click on the FMS knob to activate the cursor (CRSR).  You you should see some element highlighted on the page, typically flashing.  You can navigate around the page using the outer and inner FMS knobs.  The Outer FMS knob (shift-mouse wheel) typical moves the cursor between elements.  The Inner FMS knob typically changes the selected item.
* Use the RANGE knob to zoom map views in/out.
 
===PFD===
* Artificial horizon, compass rose, altimeter and airspeed indicator are all hopefully obvious!
* HSI can display NAV1, NAV2, GPS information (press the CDI softkey)
* Wind information (press PFD->WIND then select one of the options for display)
* Bearings to NAV1, NAV2, GPS (press PFD then BRG1/BRG2 to cycle through the options)
* Inset Map (Press INSET softkey)
* Active Flight Plan (press FPL when there is an active flightplan to display)
* DirectTo GPS (press DTO)
* Transponder (press XPDR)
* NRST scrolls through information on the 10 nearest airports (press NRST)
 
===MFD===
* There is a two channel NAV/COM with an active and standby frequency and automatic ID of NAV frequencies at the top of the UI.  They all integrate with the standard properties, so should work automatically with most aircraft.
* If you have a frequency highlighted in any of the pages (e.g. WPT - AIRPORT INFORMATION) press the ENT key to load it into the standby NAV/COM frequency as appropriate.
* To set up a GPS Direct To route:
** Press the DTO button (D with an arrow through it on the right side of the panel, below the word "PAN").  This will bring up a Direct To window, allowing you to enter the ID of an airport, Fix etc. to navigate to.
** You can enter the ID in one of three ways:
*** Scroll the FMS knob backwards to bring up a sub-menu of waypoints categories (FPL, NRST, RECENT, USER, AIRWAY).  Use the inner FMS knob to scroll between the different categories, and the outer FMS knob to select a specific item. 
*** Scroll the FMS knob forwards to enter an ID manually using the FMS knob.  Use the outer FMS knob to move to the next poisition in the ID.
*** Use multikey support to type in the ID using the keyboard - type ":ms" followed by the ID.  This is by far the fastest method!
** Once you've got an ID, press ENT which will load details into the window and highlight the ACTIVATE button.
** Press ENT once more to load the Direct-to into the GPS and activate it.
* To view airport information, select the WPT - AIRPORT INFORMATION page.  Use the outer FMS knob to move between the AIRPORT, RUNWAYS and FREQUENCY boxes, and the inner FMS to edit the airport ID, scroll through available runways, or highlight a frequency.
* To edit the current flightplan, press the FPL page, then press the CRSR and enter waypoints for DTO above.
 
 
===GFC700 Autopilot===
The GFC700 autopilot is a two axis autopilot with independent lateral and vertical modes.  The default later/vertical modes are ROL and PIT, which hold the current roll and pitch respectively.
If installed on the aircraft, the GFC700 autopilot is enabled by pressing any of the buttons on the bottom left of the PFD/MFD fascia:
* AP enables/disables autopilot
* FD enables a Flight Director mode, displaying control bars to follow manually.  Note that this button is disabled when the autopilot is enabled.
* HDG enables a heading mode, tracking the blue heading bug.  Use the HDG knob on the PFD to set.
* VS enables Vertical Speed hold.  Current target is displayed at the top of the PFD.  It may be adjusted by using NOSE UP / NOSE DN.
* ALT enables Altitude Hold, which holds the current altitude.
* GA enables Go Around, which sets ROL to 0 and PIT to 7 degrees nose up.
* NAV enables NAV mode.  The navigation source depends on what the CDI is set to on the PFD.  Currently this is only implemented for GPS.
* APR enables Approach mode for both vertical and lateral GPS or ILS approaches.  Will use the currently selected CDI source.
* VNV enables vertical NAV mode (not yet implemented)
* FLC enables Flight Level Change, where the autopilot will maintain the current airspeed by pitch.  NOSE UP / NOSE DN is used to set the target airspeed, which is displayed at the top of the PFD, and on the airspeed tape.
* BC enables Back Course mode (not yet implemented)
 
 
Buttons toggle modes on/off, defaulting to ROL for lateral and PIT for vertical.  The current pitch setting in PIT mode can be adjusted by using the NOSE UP and NOSE DN buttons.
 
In PIT/VS/FLC mode, Selected Altitude Capture mode (ALTS) is armed, targetting the current altitude bug.  Once the aircraft gets within 200ft of the selected altitude the autopilot will automatically transition to ALTS and then ALT mode to track that altitude.  Note that once the altitude is fixed in ALTS mode changing the altitude bug will not change the target altitude.
 
(Control Wheel Steering (CWS) can be used to set new ROL/PIT targets, but is not yet implemented)
 
===Multikey Support===
 
To improve usability, the FG1000 also supports multikey.  If installed on the aircraft (aircraft developers need to include Aircraft/Instruments-3d/FG1000/fg1000-multikey.xml), the following keys are available.
 
* ":p" controls the PFD
** 1- 12 selects the softkeys
** s allows you to use the keyboard to enter text directly into the PFD, e.g. when entering an airport
* ":m" controls the MFD
** 1-12 selects the softkeys
** a selects the Airport Information page
** c selects the Checklists page
** f selects the Flightplan page
** m selects the Navigation Map page
** n selects the Nearest Airports page
** s allows you to use the keyboard to enter text directly into the PFD, e.g. when entering an airport
** t selects the Traffic Map page
 
== Aircraft Installation ==
 
Adding the FG1000 to an aircraft is intended to be fairly straightforward, but there is a little complexity due to properties that different aircraft use, and the Engine Information System (EIS) needing to be different for different powerplants.  The J3Cub is a good example to use to see how the FG1000 integration can be done (the c182t isn't a good example as it uses the default FG1000 implementation).
 
=== Add the GDU to the cockpit ===
 
Place one or more of the display (GDU) units in your model.  The XML files
are in GDU104X directory and are named  <model>.<device-number>.xml, e.g.
 
GDU-1045.1.xml  GDU-1045.2.xml  GDU-1045.3.xml  GDU-1045.4.xml
 
The <device-number> is referenced later to identify which displays to used
for each PFD, MFD etc.  You must only used one of each <device-number> value,
though you can mix and match the GDU models.
 
The different GDU models are as follows:
 
* GDU-1040 - No autopilot controls
* GDU-1044B - autopilot controls without VNAV
* GDU-1045 - autopilot controls with VNAV
 
=== Include the GFC700 autopilot (optional)===
 
If using the 1044B or 1045 GDU, the GFC700 autopilot can be incorporated by adding the following to under /sim/systems
<syntaxhighlight lang="xml">
<autopilot>
      <path>Aircraft/Instruments-3d/FG1000/GFC700.xml</path>
</autopilot>
</syntaxhighlight>
 
The autopilot has been tuned for the Cessna 182, so may not be correct for light jets.
 
=== Load the Interfaces to provide data ===
 
This is used to provide airdata, navdata, NAV/COM settings, engine information
to the GDUs.  There is a
generic interface (GenericInterfaceController) that uses the standard FG route
manager, GPS, navigation data and NAV/COM settings, and engine data for a single
piston engine.
 
You need to load it as follows:
 
<syntaxhighlight lang="nasal">
var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
io.load_nasal(nasal_dir ~ 'Interfaces/GenericInterfaceController.nas', "fg1000");
 
var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();
</syntaxhighlight>
 
You may want to create your own version depending on what properties you are
using for the NAV/COM, and your engine configuration.  In which case you should
copy /Aircraft/Instruments-3d/FG1000/Nasal/Interfaces/GenericInterfaceController.nas
into your aircraft Nasal directory, edit it to load any updated interfaces and
load it instead:
 
<syntaxhighlight lang="nasal">
var aircraft_dir = getprop("/sim/aircraft-dir");
io.load_nasal(aircraft_dir ~ '/Nasal/GenericInterfaceController.nas', "fg1000");
 
var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();
</syntaxhighlight>
 
Note that you should only start the interface after you've started the FG1000
as they will publish information at start of day that the displays need.
 
=== Create an EIS Display ===
 
This is the Engine Information System and displays on the left side of the MFD. 
 
A simply EIS for the Cessna 182T is provided.  For other aircraft you will need to create your own.  The simplest way to do this is
 
# Copy Aircraft/Instruments-3d/FG1000/EIS into your aircraft Nasal directory.  Re-name EIS-c182t.nas to something sensible (e.g. EIS-[aircraft].nas).  Don't forget to rename the class itself!
# Copy one of the EIS .svg files from Aircraft/Instruments-3d/FG1000/MFDPages into your aircraft Nasal.  Modify it as required, noting the names of objects and how they map to the EIS.nas file.
# Edit the SVG and EIS-[aircraft].nas as appropriate.  In particular note that the Fuel submenu is used to set the contents of the fuel tanks manually, with a fuel totalizer approach.
# Copy Aircraft/Instruments-3d/FG1000/Nasal/Interfaces/GenericEISPublisher.nas into your Nasal directory, and rename it (e.g. [aircraft]EISPublisher.nas.  Don't forget to rename the class itself! Modify it to publish the correct set of properties to Emesary.  Note that for multiple engine aircraft you need to modify the publish() method.
# As noted above, you will need to load a modified version of GenericInterfaceController.nas
# Finally, modify whatever Nasal you use to load the FG1000 to pass in the new EIS class and SVG file.  Note that you need to load the EIS Controller, style and Options classes as well.
 
This is what your Nasal file may look like at the end:
 
<syntaxhighlight lang="nasal">
 
# Load a customer Interface controller
var aircraft_dir = getprop("/sim/aircraft-dir");
io.load_nasal(aircraft_dir ~ '/Nasal/GenericInterfaceController.nas', "fg1000");
 
var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();
 
io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EIS-J3Cub.nas', "fg1000");
io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EISController.nas', "fg1000");
io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EISStyles.nas', "fg1000");
io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EISOptions.nas', "fg1000");
 
# This is the class in EIS-J3Cub.nas, loaded above.
var EIS_Class = fg1000.EISJ3Cub;
 
# Create the FG1000 using custom EIS Class, and the appropriate .svg file.
var fg1000system = fg1000.FG1000.getOrCreateInstance(EIS_Class:EIS_Class, EIS_SVG: "Nasal/EIS/EIS-J3Cub.svg");
</syntaxhighlight>
 
=== Using custom SVG files ===
 
To assist in implementing related glass cockpits (e.g. Garmin Perspective on the Cirrus SR22T), you can specify a directory to be used instead of /Aircraft/Instruments-3d/FG1000/MFDPages/ for the SVG files used by the MFD.  Note that you must copy across all the .svg files.
 
<syntaxhighlight lang="nasal">
# Create the FG1000 using custom EIS Class, and the appropriate .svg file, and a custom path to other SVG files
var fg1000system = fg1000.FG1000.getOrCreateInstance(EIS_Class:EIS_Class, EIS_SVG: "Nasal/EIS/EIS-J3Cub.svg", SVG_Path: "MFDPages/");
</syntaxhighlight>
 
 
 
=== Add multikey support ===
Include <code>Aircraft/Instruments-3d/FG1000/fg1000-multikey.xml</code> in your -set.xml file to support multikey. 
 
<syntaxhighlight lang="xml">
  <input>
    <keyboard n="0">
      <multikey include="Aircraft/Instruments-3d/FG1000/fg1000-multikey.xml"/>
    </keyboard>
  <input>
</syntaxhighlight>
 
 
See [[Howto:Add_multi-key_commands_to_an_aircraft]] for further details.
 
=== Load and start the FG1000 system ===
 
A simple FG1000 using the generic EIS, and displaying PFD on device-number 1 and an MFD on device-number 2 is as follows:
 
<syntaxhighlight lang="nasal">
var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
io.load_nasal(nasal_dir ~ 'FG1000.nas', "fg1000");
 
# Create the FG1000
var fg1000system = fg1000.FG1000.getOrCreateInstance();
 
# Create a PFD as device 1, MFD as device 2
fg1000system.addPFD(index:1);
fg1000system.addMFD(index:2);
 
# Map the devices to placement objects Screen{i}, in this case Screen1 and Screen2
fg1000system.display(index:1);
fg1000system.display(index:2);
 
# Show the devices
fg1000system.show(index:1);
fg1000system.show(index:2);
 
#  Display a GUI version of device 1 at 50% scale.
#fg1000system.displayGUI(index:1, scale:0.5);
</syntaxhighlight>
 
== Page Status ==
 
This is the current status of the individual pages.  Full progress bars indicate that they are functionally complete, though the iconography is not correct.
 
{| class="wikitable sortable"
|-
! Page !! Reference !! Status !! Notes
|-
| {{FG1000 file|name=NavigationMap|label=Navigation Map}} ||  || {{progressbar|100|20}} || See Layers below
|-
| {{FG1000 file|name=TrafficMap|label=Traffic Map}} ||  || {{progressbar|100|20}} || Zoom controls unclear
|-
| {{FG1000 file|name=Stormscope|label=Storm Scope}} ||  || {{progressbar|0|20}} ||
|-
| {{FG1000 file|name=WeatherDataLink|label=Weather Data Link}} ||  || {{progressbar|0|20}} ||
|-
| {{FG1000 file|name=TAWSB|label=TAWS-B}}||  || {{progressbar|0|20}} ||
|-
| {{FG1000 file|name=AirportInformation|label=Airport Information}} ||  || {{progressbar|100|20}} || Needs additional page of AOPA information, which we don't have
|-
| {{FG1000 file|name=IntersectionInfo|label=Intersection Information}} ||  || {{progressbar|100|20}} ||
|-
| {{FG1000 file|name=NDBInfo|label=NDB Information}} ||  || {{progressbar|100|20}} ||
|-
| {{FG1000 file|name=VORInfo|label=VOR Information}} ||  || {{progressbar|100|20}} ||
|-
| User WPT Information ||  || {{progressbar|0|20}} ||
|-
| Trip Planning ||  || {{progressbar|0|20}} ||
|-
| Utility ||  || {{progressbar|0|20}} ||
|-
| GPS Status ||  || {{progressbar|0|20}} ||
|-
| XM Radio ||  || {{progressbar|0|20}} ||
|-
| System Status ||  || {{progressbar|0|20}} ||
|-
| {{FG1000 file|name=ActiveFlightPlanNarrow|label=Active Flight Plan}} ||  || {{progressbar|100|20}} || Viewing and editing of the active flight plan implemented.  VNAV and the "wide view" not yet implemented
|-
| Flight Plan Catalog ||  || {{progressbar|0|20}} ||
|-
| Stored Flight Plan ||  || {{progressbar|0|20}} ||
|-
| {{FG1000 file|name=Checklist|label=Checklist}} ||  || {{progressbar|100|20}} ||
|-
| {{FG1000 file|name=NearestAirports|label=Nearest Airports}} ||  || {{progressbar|100|20}} ||
|-
| {{FG1000 file|name=NearestIntersections|label=Nearest Intersections}} ||  || {{progressbar|100|20}} ||
|-
| {{FG1000 file|name=NearestNDB|label=Nearest NDB}} ||  || {{progressbar|100|20}} ||
|-
| {{FG1000 file|name=NearestNDB|label=Nearest VOR}} ||  || {{progressbar|100|20}} ||
|-
| Nearest User Waypoints ||  || {{progressbar|0|20}} ||
|-
| Nearest Frequencies ||  || {{progressbar|0|20}} ||
|-
| Nearest Airspaces ||  || {{progressbar|0|20}}||
|}
 
This is the current status of the major functional elements
 
{| class="wikitable"
|-
! Area !! Status !! Notes
|-
| Navigation - FMS || {{progressbar|100|20}} ||
|-
| Softkeys || {{progressbar|100|20}} ||
|-
| MENU key || {{progressbar|0|20}} ||
|-
| NAV/COM  || {{progressbar|90|20}} || Volume controls to be added
|-
| GPE Header || {{progressbar|0|20}} ||
|}


== Motivation ==
== Motivation ==
Line 15: Line 366:


The airspace system is in the process of changing drastically [...]  this isn't just a matter of throwing up a canvas showing some GPS waypoints and a magenta line. Modern navigators are astoundingly-complex devices — probably an order of magnitude more lines of code than FlightGear itself — and even their basic flight planning algorithms and databases (e.g. fly-by waypoints vs fly-over waypoints, open vs closed approach procedures, transitions into RNAV approaches, etc.) are far beyond the scope of anything we've tried, and we'd also need an up-to-date database far more complex than the ones we have now. Once you get to the extra features, like FIS-B weather or TIS-B traffic info over ADS-B, or TAWS (terrain alerting), we're probably in way over our heads trying to emulate even the simplest general-aviation IFR GPS.
The airspace system is in the process of changing drastically [...]  this isn't just a matter of throwing up a canvas showing some GPS waypoints and a magenta line. Modern navigators are astoundingly-complex devices — probably an order of magnitude more lines of code than FlightGear itself — and even their basic flight planning algorithms and databases (e.g. fly-by waypoints vs fly-over waypoints, open vs closed approach procedures, transitions into RNAV approaches, etc.) are far beyond the scope of anything we've tried, and we'd also need an up-to-date database far more complex than the ones we have now. Once you get to the extra features, like FIS-B weather or TIS-B traffic info over ADS-B, or TAWS (terrain alerting), we're probably in way over our heads trying to emulate even the simplest general-aviation IFR GPS.
This may help folks understand what the G1000 is all about:<ref name="Pilot's Guide">{{cite web
| url            = http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf
| title          = Garmin G1000 Pilot’s Guide for Cessna Nav III, Rev. A
| date            = October, 2011
| publisher      = Garmin International, Inc.
| format          = pdf
| archiveurl      = https://web.archive.org/web/20170708032442/http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf
| archivedate    =
| accessdate      = May 8, 2019
}}</ref>
Writing a G1000 isn't that hard. Writing a '''feature complete''' G1000 is a ton of work. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35925783/
  |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
  |author =  <nowiki> geneb </nowiki>
  |date  =  Jul 3rd, 2017
  |added  =  Jul 3rd, 2017
  |script_version = 0.40
  }}</ref>


Depending on how we deal with this challenge, the question is whether that means that the usefulness of FlightGear will also gradually taper off. <ref>{{cite web
Depending on how we deal with this challenge, the question is whether that means that the usefulness of FlightGear will also gradually taper off. <ref>{{cite web
Line 26: Line 398:
   }}</ref>
   }}</ref>


This may help folks understand what the G1000 is all about: http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf
Instead of just making one-off tweaks like the consumer sims did, we (as a team) emulated entire systems like the vacuum, pitot-static, and electrical systems, so that failures would be realistic. In the RNAV age, we need to do the same thing; it's just that it's a bigger job. FlightGear will still be great for people who want to practice the mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but will slip further and further behind for people who want to use it for real IFR practice.<ref>{{cite web
Writing a G1000 isn't that hard. Writing a '''feature complete''' G1000 is a ton of work. <ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35927088/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35925783/  
   |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
   |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
  air navigation </nowiki>  
  air navigation </nowiki>  
   |author =  <nowiki> geneb </nowiki>  
   |author =  <nowiki> David Megginson </nowiki>  
   |date  =  Jul 3rd, 2017  
   |date  =  Jul 4th, 2017  
   |added  =  Jul 3rd, 2017  
   |added  =  Jul 4th, 2017  
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>


== Background ==
{{Main article|Complex Canvas Avionics}}
== Challenges ==
=== Performance ===
{{See also|Canvas_Development#Property_I.2FO_observations|Canvas_MapStructure#Performance}}
Nasal as such is fast, and compared with the cost of rendering the terrain, rendering a canvas display is fast on the GPU (you can test by rendering but not updating a canvas display), and unless you're doing something very inefficient, calculating a display but not writing it to the property tree is fast (you can test this by disabling the write commands). It's the property I/O which you need to structure well, and then canvas will run fast. And of course the complexity of your underlying simulation costs - if you run a thermal model underneath to get real temperature reading, it costs more than inventing the numbers. But that has nothing to do with canvas. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35926343/
  |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  Jul 4th, 2017
  |added  =  Jul 4th, 2017
  |script_version = 0.40
  }}</ref>


== Performance ==


it's a lot of work to code all these displays which someone has to do, but there's no reason to assume it'd be hopeless performance-wise.<ref>{{cite web
it's a lot of work to code all these displays which someone has to do, but there's no reason to assume it'd be hopeless performance-wise.<ref>{{cite web
Line 50: Line 435:
   }}</ref>
   }}</ref>


we need to be realistic here: The G1000 is a fairly significant piece of computer hardware that we're going to emulate. It's not going to be "free" particularly for those on older hardware that's already struggling. However, hopefully we can offload a chunk of the logic (route management, autopilot/flight director) to the core, and do things like offline generation of terrain maps to minimie the impact.<ref>{{cite web
we need to be realistic here: The G1000 is a fairly significant piece of computer hardware that we're going to emulate. It's not going to be "free" particularly for those on older hardware that's already struggling. However, hopefully we can offload a chunk of the logic (route management, autopilot/flight director) to the core, and do things like offline generation of terrain maps to minimize the impact.<ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35926745/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35926745/  
   |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
   |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
Line 60: Line 445:
   }}</ref>
   }}</ref>


== Background ==
=== Route Manager ===
{{Main article|Complex Canvas Avionics}}
that's exactly the kind of device James hopes the new code can support. He's read the G1000 pilot's manual, and  *thinks* that nearly all the functions can be provided by the current GPS code It would be great if people could look over the current GPS features and indicate any pieces you think might be missing - additional commands, additional search features, extra data, or anything really. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/23814733/
  |title  =  <nowiki> Re: [Flightgear-devel] ZKV500 GPS instrument; (New?) GPS code bug </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Oct 22nd, 2009
  |added  =  Oct 22nd, 2009
  |script_version = 0.40
  }}</ref>
 
=== tile servers ===
Please keep in mind that most tile servers discourage bulk downloads. For the whole planet,oomlevel 8 is approx. 67k files, at zoomlevel 9 you have 265k, level 10 has a little over one million tiles. And one would probably want to go up to level 15 (roughly 1e9 files)<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36057678/
  |title  =  <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Sep 29th, 2017
  |added  =  Sep 29th, 2017
  |script_version = 0.40
  }}</ref>
 
=== Offline mode ===
would it be possible to provide an offline tool to pre-fetch a region, like TerraMaster, or terrasync.py? Call me old-fashioned or paranoid, but I don't want FG to go online and do stuff automatically, I prefer downloading what I need manually so that I know what gets onto my harddisk. Also - think of all the people with poor home internet which might have larger bandwidth only in a library elsewhere.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36057499/
  |title  =  <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  Sep 29th, 2017
  |added  =  Sep 29th, 2017
  |script_version = 0.40
  }}</ref>


== Plan ==
that would certainly be possible - the code retrieving the data is pretty trivial and porting the Nasal code to python or some other script should be straightforward.<ref>{{cite web
Stuart has been in contact with the author (Sébastien MARQUE) of the ZKV-1000. While he himself doesn't plan to implement a G1000, he's very happy for it to be developed in that direction. Stuart's broad plan is to make a copy of this in fgdata or fgaddon, and use it as the basis for a G1000, taking the opportunity to use [[Canvas MFD Framework|Richard's MFD code]] and making as generic pages as possible for other glass cockpit applications.<ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/36057657/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35976465/  
   |title  =  <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
   |title  =  <nowiki> [Flightgear-devel] G1000 (was Re: Nasal property lookup performance) </nowiki>  
VFR Sectionals </nowiki>  
   |author =  <nowiki> Stuart Buchanan </nowiki>  
   |author =  <nowiki> Stuart Buchanan </nowiki>  
   |date  =  Aug 1st, 2017  
   |date  =  Sep 29th, 2017  
   |added  =  Aug 1st, 2017  
   |added  =  Sep 29th, 2017
  |script_version = 0.40
  }}</ref>
 
=== Navdata ===
we need some better data sources, especially with direct routing replacing airways in many areas, and having airspace data would help the map displays, but the current API is specifically designed to support G430, G1000 and similar class devices. Adding RNAV approaches is eminently doable, see the the RNavController base class which the GPS/FMS layer uses to allow new waypoint / route segments to define how they are flown and drive CDIs <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35927598/
  |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Jul 4th, 2017
  |added  =  Jul 4th, 2017
  |script_version = 0.40
  }}</ref>
 
 
Getting the algorithms right, and keeping the data up to date every 7 weeks (we have only a tiny sliver of that data currently), is going to be much more of a challenge. I expect that it's probably an order of magnitude more complicated than our current flight dynamics (etc.), so we'd have to grow our contributor base, and find funding to pay at least Curt (and maybe a couple of others) full time to manage the project. Note that that's what has happened for other complex FOSS projects, like office suites and browsers, which generally end up working through a foundation, rather than our current relaxed circle-of-friends arrangement. The reason it's so much harder now is that the software *is* the product for GPS navigators, FMSs, etc. (unlike with older avionics, where the hardware was the main thing). That means that emulating even a simple unit like the GTN 650 or GNS 430W is almost difficult as building one, so we're trying to keep up with armies of full-time software developers at Garmin, Avidyne, etc.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35927243/
  |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
  |author =  <nowiki> David Megginson </nowiki>
  |date  =  Jul 4th, 2017
  |added  =  Jul 4th, 2017  
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>


== Status ==
{{Main article|Canvas_News#G1000_.26_MapStructure_improvements}}


=== October 2017 ===
According to the Route Manager wiki page, we already have support for SID/STAR data provided from Navigraph, which is released on the AIRAC cycle, and costs a pretty small amount (9 EUR for a single download of FMS data, or 90 EUR per year) Given the relatively low cost, I don't think that we as an organiation want to get into trying to digitize data ourselves just to make it open-source or public domain. Particularly given the low cost of a download. We might want to digitize the STAR/SIDs for the default airport with each release so there are some approaches available for those who don't want to purchase the data.<ref>{{cite web
Stuart committed some changes to update the Select Airport dialog to use Canvas MapStructure Layers to display airport information, rather than the now deprecated map layers. The change should be largely transparent to end users - the only significant change is that your can display navigation symbols. This is all part of a long-term effort to provide the building blocks for a Garmin G1000 - these layers could be used for the airport display on the MFD, and could easily be combined with the APS layer to show a moving aircraft.<ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35927426/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/36075357/  
   |title  =  <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
   |title  =  <nowiki> [Flightgear-devel] Updated Select Airport dialog </nowiki>  
air navigation </nowiki>  
   |author =  <nowiki> Stuart Buchanan </nowiki>  
   |author =  <nowiki> Stuart Buchanan </nowiki>  
   |date  =  Oct 13th, 2017  
   |date  =  Jul 4th, 2017  
   |added  =  Oct 13th, 2017  
   |added  =  Jul 4th, 2017  
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>
everyone agrees we would like to add airspace data - what we’re missing is a suitable data source with the correct license. Torsten found a raster-based source but for wider use in the sim we really need vector data, so we can render it ourselves directly. <ref>{{cite web  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36178857/  |title  =  <nowiki> Re: [Flightgear-devel] [flightgear/simgear] Nasal regex patch </nowiki>  |author =  <nowiki> James Turner </nowiki>  |date  =  Jan 5th, 2018  |added  =  Jan 5th, 2018  |script_version = 0.36  }}</ref>
For airspace data we could use [https://openflightmaps.org/ https://openflightmaps.org/] . It provides community created navigation data for many countries in (currently only) Europe with a free license.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=326105#p326105
  |title  =  <nowiki> Re: Canvas G1000 </nowiki>
  |author =  <nowiki> TheTom </nowiki>
  |date  =  Jan 9th, 2018
  |added  =  Jan 9th, 2018
  |script_version = 0.36
  }}</ref>
we definitely want vector data.  Stuart is hoping that we might convince the source of the raster data we're using at present to provide it as raw vector data, but we haven't had any luck so far.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=326201&sid=137f64d32b770e50a3c4061be42ce28a#p326201
  |title  =  <nowiki> Re: Canvas G1000 </nowiki>
  |author =  <nowiki> stuart </nowiki>
  |date  =  Jan 10th, 2018
  |added  =  Jan 10th, 2018
  |script_version = 0.36
  }}</ref>
== Airport Data (US - only )==
At least for the US, all required information is available in the form of regularly updated UDFF files:
* https://www.ngs.noaa.gov/AERO/aero.html
* https://www.ngs.noaa.gov/AERO/uddf/WESTERN-PACIFIC/CALIFORNIA/SFO__03B.F77
* https://www.ngs.noaa.gov/AERO/annof_7.pdf
It would seem relatively straightforward to provide a scripted parser to create the corresponding charts procedurally.
As a matter of fact, this could even be done in a background thread or using a separate Python script, i.e. if we wanted to ship pre-created imagery as part of fgdata.
However, if the built-in Canvas system is extended to provide these charts, [[Phi]] could also be entirely self-contained by rendering the same  airport charts without having to depend on external data sources.
== Layers  ==
{{See also|Canvas_Sandbox#CanvasShapefile}}
Following is the list of layers displayed by the G1000 system (see page 153 of the 190-00498-07 Rev. A), and mapping to the equivalent MapStructure Layer.
Many of these would also be good to have for other avionics/GUI dialogs, including the NavDisplay framework, which is currently re-implementing this functionality separately, i.e. not yet using MapStructure.
Following is the list of layers displayed by the G1000 system, based on the Garmin G1000 Integrated Flight Deck Pilot's Guide for the Cessna Nav III,<ref name="Pilot's Guide" /> page 153, and the mapping to the equivalent MapStructure Layer.
Richard mentioned that if he were to implement approach plates in the EFB he'd probably use raster images provided via http and provide an http service within FG to do this, or to allow the EFB to use any other external web service. Other content for the EFB could be also provided as SVG via http.<ref>{{cite web  |url    =  https://forum.flightgear.org/viewtopic.php?p=259194#p259194  |title  =  <nowiki> Re:  </nowiki>  |author =  <nowiki> Richard </nowiki>  |date  =  Sep 29th, 2015  |added  =  Sep 29th, 2015  |script_version = 0.36  }}</ref>
{| class="wikitable"
|-
! Layer !! [[Canvas MapStructure Layers|MapStructure Layer]] !! Type !! Status !! Page in <ref name="Pilot's Guide" /> || Notes
|-
| Flight Plan Route Lines || {{MapStructure_File|name=RTE|type=lcontroller}} || offline || Requires styling || 190 ||
|-
| Flight Plan Route Waypoints || {{MapStructure_File|name=WPT|type=lcontroller}} || offline || Requires styling || 190 ||
|-
| Rivers/Lakes || {{MapStructure_File|name=VFRChart|type=lcontroller}} || online  ||  || 148 || Currently using downloaded raster from web.  Perhaps generate similarly to Atlas<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=203495#p203495
  |title  =  <nowiki> Re: Atlas still in use ? </nowiki>
  |author =  <nowiki> Torsten </nowiki>
  |date  =  Mar 17th, 2014
  |added  =  Mar 17th, 2014
  |script_version = 0.40
  }}</ref>, or could be vector data from scenery. {{AtlasVsCanvasCameras}}
|-
| Topography Data || {{MapStructure_File|name=VFRChart|type=lcontroller}}|| online || Synthetic  || 145 || Height-map at chart-resolution.  Perhaps generate similarly to Atlas? {{AtlasVsCanvasCameras}}
|-
| International Borders ||  || ||  || 148 || Vector data from scenery?
|-
| Track Vector ||  || ||  || 156 || Forward looking display of track. Look-ahead time selectable.
|-
| Navigation Range Ring ||  || offline||  || 159 || Straightforward extension of {{MapStructure_File|name=APS|type=lcontroller}}.
|-
| Fuel Range Ring || || offline  ||  || 159 || Straightforward extension of {{MapStructure_File|name=APS|type=lcontroller}}.
|-
| Terrain Data ||  || - ||  || 364 || Should be straightforward, with exception of obstacles.  [[Spoken GCA|Profile view]] also required.
|-
| Traffic || {{MapStructure_File|name=TFC|type=lcontroller}} || offline||  || 394, 423 || Various options, each with different iconography and data displayed.
|-
| Airways || {{MapStructure_File|name=VFRChart|type=lcontroller}} || online||  ||  154 || Needs to be replaced with vector data
|-
| NEXRAD || || unknown  ||  || 282 || Heaps of weather data with complex symbology.
|-
| XM Lightning Data || {{MapStructure_File|name=WXR|type=lcontroller}} || offline|| Change to symbol for lightning? || 294 || Optional 
|-
| Airports || {{MapStructure_File|name=APT|type=lcontroller}}, {{MapStructure_File|name=RWY|type=lcontroller}} || offline|| Require re-style based on size  ||  149, 163 ||
|-
| Runway Labels || {{MapStructure_File|name=RWY|type=lcontroller}} || offline||  || 148 || Needs to be added to {{MapStructure_File|name=RWY|type=symbol}}.  Should be straightforward
|-
| Restricted ||  {{MapStructure_File|name=OpenAIP|type=lcontroller}}  || online ||  ||  182 || {{NeedVectorData}}
|-
| MOA (Military) ||  {{MapStructure_File|name=OpenAIP|type=lcontroller}} || online ||  ||  182 || {{NeedVectorData}}
|-
| User Waypoints || || offline  ||  || 
|-
| Latitude/Longitude Grid || {{MapStructure_File|name=GRID|type=lcontroller}} || offline||  || 
|-
| NAVAIDs || {{MapStructure_File|name=APT|type=lcontroller}}, {{MapStructure_File|name=VOR|type=lcontroller}}, {{MapStructure_File|name=FIX|type=lcontroller}}, {{MapStructure_File|name=NDB|type=lcontroller}} || offline|| APT, requires styling  ||  162 ||
|-
| Class B Airspaces/TMA || {{MapStructure_File|name=OpenAIP|type=lcontroller}}  || online ||  || 182 || {{NeedVectorData}}
|-
| Class C Airspaces/TCA || {{MapStructure_File|name=OpenAIP|type=lcontroller}} || online||  ||  182 || {{NeedVectorData}}
|-
| Class D Airspaces || {{MapStructure_File|name=OpenAIP|type=lcontroller}}  || online||  ||  182 || {{NeedVectorData}}
|-
| Other Airspaces/ADIZ || {{MapStructure_File|name=OpenAIP|type=lcontroller}}  || online||  ||  182 || {{NeedVectorData}}
|-
| TFRs || || unknown  ||  || 310 ||
|-
| Obstacles || {{MapStructure_File|name=OpenAIP|type=lcontroller}}  || online||  ||  182 || {{NeedVectorData}}
|-
| Land/Country Text || || online  ||  || 148 || Currently using raster data from web. Replace with {{MapStructure_File|name=POI|type=lcontroller}}?
|-
| Cities  || {{MapStructure_File|name=VFRChart|type=lcontroller}}|| online ||  ||  148 || Currently using raster data from web.  Perhaps generate similarly to Atlas, or could be vector data from scenery. {{AtlasVsCanvasCameras}} [https://forum.flightgear.org/viewtopic.php?f=31&t=37158&p=364650&#p364643]
|-
| Roads || {{MapStructure_File|name=VFRChart|type=lcontroller}} || online ||  ||  148 || Currently using raster data from web.  Requires vector data from scenery
|-
| Railroads || {{MapStructure_File|name=VFRChart|type=lcontroller}} || online ||  ||  148 || Currently using raster data from web.  Requires vector data from scenery
|-
| State/Province Boundaries || {{MapStructure_File|name=VFRChart|type=lcontroller}}  || online||  ||  148 || Currently using raster data from web.  Requires vector data from scenery
|-
| River/Lake Names || {{MapStructure_File|name=VFRChart|type=lcontroller}} || online ||  ||  148 || Currently using raster data from web.  Replace with {{MapStructure_File|name=POI|type=lcontroller}}?
|-
| Selected Altitude Intercept Arc |||| offline  ||  ||  161 || Simple extention to APS
|-
| SafeTaxi (Optional) || {{MapStructure_File|name=RWY|type=lcontroller}}, {{MapStructure_File|name=TAXI|type=lcontroller}} || offline||  || 493  || We don't currently have the data to display taxiway identifier or holding points
|-
| ChartView (Optional) ||  || offline||  || 503  || [[Canvas_Sandbox#CanvasPDF|Rendering of PDFs.]]  Might be possible to integrate with NaviGraph chart data?
|-
| FliteChart (Optional) || || offline||  || 521  || [[Canvas_Sandbox#CanvasPDF|Rendering of PDFs.]]  Might be possible to integrate with NaviGraph chart data?
|}


== Existing work ==
== Existing work ==
{{See also|Complex Canvas Avionics}}
=== Avionics / Cockpits ===
* [[User:Zakharov/zkv1000 installation guide|zkv1000]] see [https://forum.flightgear.org/viewtopic.php?f=14&t=32056]
* [[Extra500]] / Avidyne Entegra R9000
===  Nasal / Canvas ===
* [[Canvas MFD Framework]]
* MapStructure
* MapStructure Layers
* [[Howto:Creating a Canvas GUI Widget]]
* [[Emesary]]
=== C++ ===
* [[Atlas]] map creation
* [[Howto:Canvas View Camera Element|Synthetic Vision]] element for rendering viewmgr views to a Canvas
* [[Canvas_Sandbox#CanvasPDF|Canvas PDF]] element - for rendering PDF files (think EFB functionality)
== Possible Work ==
=== Architectural TODO List ===
This is a short list of architectural improvements I've noted during development that need to be revisited:
* Use NavMap for MFD Navigation Map, DirectTo, Nearest, Information pages.
* Separate out the HSI, tapes from the PFD and make them generic MFD UI Elements
* Improve the performance of the maps, perhaps using a cache for queries, definitely by more aggressive clipping of the SlippyMap layers based on map size.
The layers table shown above mentions a few limitations and ideas, such as:
=== Nasal/Canvas ===
* <image> tag support for svg.nas (patch: [http://wiki.flightgear.org/Howto:Extend_the_Canvas_SVG_module])
* MapStructure: [[MapStructure_Optimizations#Allocating_selectable_ranges_into_groups|Allocating selectable ranges into Canvas groups]]
=== C++ ===
* fix up [[Canvas_MapStructure#Performance|projection issues]], and adopt Gijs' [[Canvas_Development#Projections|projection handling code]] for the hard-coded PUI [[Map]], to get rid of the standard Sanson-Flamsteed projection
* adding a profile view, probably in conjunction with terrain sampling
* using atlas code to generate heightmaps/topography
* adding ESRI shapefile support to the Canvas system
* adding PDF rendering support the Canvas system
== Design ==
The broad structure of the Nasal files in Aircaft/Instruments-3d/FG1000/Nasal is as follows:
* MFD.nas - top level MFD device, loads the other Nasal files (likely to be moved elsewhere later) and pages.
* PageGroupControllers.nas - controller for the Page Group display in the bottom right of the MFD, controlled by the FMS knob, and which allows selection between different page groups and individual pages.
* [PageName]/[PageName].nas - MFD page, inheriting from the MFDPage.nas.  Creates any required MapStructure and hierarchy of softkeys.
* [PageName]/[PageName]Controller.nas - Controller for the MFD page and the MapStructure layers, inheriting from MFDPageController.nas
* [PageName]/[PageName]Style.nas - Style controls for the MapStructure layers for the given Page.
* [PageName]/[PageName]Options.nas - Options for the MapStructure layers for the given Page.
Key design notes:
* Most of the underlying Canvas [[MapStructure]] layers are now written (though they require styling, and/or would benefit from replacement with vector data).
* [[Emesary]] IPC framework is used to link between the MFD and underlying simulation state. This should make it easy to run the MFD on a separate FG instance, and provides a good demarkation between the individual aircraft systems and the FG1000 itself.
* Various underlying UI classes are used to handle highlighting, selection and scrolling of fields.  See [[Canvas MFD Framework]] for details of the elements now supported.


== Resources ==
== Resources ==
{{#ev:youtube|I0y6p0ct1m0}}


== Related ==
== Related ==
=== Commits ===
This section is intended to help keep track of related fgdata commits, so that if/when the project should stall, people can more easily look up related changes.
* {{fgdata commit|da252c8a18fe2ce88066c051f6df588639377792|text=Initial Direct To page}}(01/2018)
* {{fgdata commit|0c4544c1e1788f3396330c86016b66df8643fd3b|text=Add Config Store and MFD Header display.}}(01/2018)
* {{fgdata commit|9bd10f8273a6e64b12b9a034ca4952d87090f921|text=SVG MFD UI from miChat}}(01/2018)
* {{fgdata commit|f6f5efe9f442ff058d9d425d85337139b2a9bf1f|text=Use Emesary interface rather than airportinfo()}}(01/2018)
* {{fgdata commit|d306e7ba100840f5c3909123a383b19f7e7d7540|text=Set standby COM frequency from Airport pages}}(01/2018)
* {{fgdata commit|cbb281759cd3f2b830bffdd12ba72d456996a13a|text=NAV/COM Radio support}}(01/2018)
* {{fgdata commit|a25c66850a93f0ae7a6f7ad8769680c1fba99887|text=Add full set of hardkeys to fg1000 PUI dialog.}}(01/2018)
* {{fgdata commit|ab8774a3e0aa3909ad284a65194f5d80dc097c6e|text=extend MFDPageController to handle Emesary register}}(01/2018)
* {{fgdata commit|73424c1791242e053efcdac37a7dd3b66226387b|text=Update NAV/COMM frequencies from properties}}(01/2018)
* {{fgdata commit|ad77dc2f9cd2a1e1ebd5efd4226cbfbf3a522008|text=Modify FG1000 EIS to use Emesary}}(01/2018)
* {{fgdata commit|9eb91171b4689b29910db06757bc47767ff59d2c|text=FG1000 Nearest Airports page}}(01/2018)
* {{fgdata commit|475fd505859b7841e29de725d4c1c39db7ad4ee5|text=PFD UI Elements and NearestAirports page}} (12/2017)
* {{fgdata commit|d0203549e833b32b719697b3a2c2a63e16fcef16|text=Add AirportInfo and template pages for FG1000}} (12/2017)
* {{fgdata commit|3d31775ff36bf3aa08a929992b70f32f2a525509|text=Initial commit of FG1000 MFD}} (11/2017)
MapStructure related:
* {{fgdata commit|4bd57492f454a05f725e6fe5a80dc246cb5e5e0f|text=GRID layer}} (10/2017)
* {{fgdata commit|d84c527ca747dd6bbd9634507f0664ff3631bdef|text=RWY, TAXI, TWR, PARKING}} (10/2017)
* {{fgdata commit|e38ec03c609b882664d0496932709aa623e486cb|text=STAMEN}} (10/2017)
* {{fgdata commit|2fbc1dc491da867e0fd4f8fc810c5cddd80ced1f|text=VFRChart}} (09/2017)
* {{fgdata commit|85b7665c19ebaae02d746fef53f25f8d8974eb13|text=OSM and OpenAIP}} (09/2017)
=== References ===
{{Appendix}}
{{Appendix}}
[[Category:Canvas]]
[[Category:Emesary]]
[[Category:Electronic flight instrument systems]]

Revision as of 11:08, 26 August 2020

FG1000 MFD being displayed (incorrectly!) in a DA-40, and mirrored to a GUI window at 50% scale (02/2018)
Stuart pushed an SVG UI for the FG1000, replacing the PUI version. (01/2018)
FG1000
Started in 07/2017
Description G1000-based MFD emulation
Contributor(s) Stuart, Richard (via Emesary), Michat (UI graphics), www2 (3D artwork) [1]
Status Under active development as of 07/2017
Folders flightgear/fgdata/next/Aircraft/Instruments-3d/FG1000/
Changelog flightgear/fgdata/next/Aircraft/Instruments-3d/FG1000/ log view

The FG1000 is a simulation of the Garmin G1000 glass panel flight deck. The FG1000 was developed in reference to the pilot's manual for the Cessna NAVIII variant, as fitted to the Cessna 182, but is designed to be flexible and also work with other airframes. For detailed instructions on how to use it, refer to the Garmin Pilot's Guide. Or read the Cheat's guide below.

Current Status (26/08/2020)

Key features:

  • Primary Flight Display (PFD). Fully functional and 99% complete vs. the real thing. (Alerts, ALT units and alternative HSI displays are the remaining pieces)
  • Multi Function Display (MFD). Fully functional and 90% complete vs. the real thing. Includes moving map, navigation features, flightplan, traffic, engine information. .
  • MFD and PFD can be displayed
    • as part of an aircraft cockpit
    • as a window within FlightGear
    • on a separate window or monitor using FGQCanvas.
  • GFC700 autopilot. Fully functional and integrated with the route manager, PFD and MFD. Includes all modes apart from VNV (vertical navigation to follow a flightplan) and BC (ILS back-course).

The following aircraft are available from the official hangar and use the FG1000:

Next steps:

  • Writing the remaining pages
  • Styling the pages - making the iconography match Garmin exactly.

Gallery

A Cheat's Guide to Using the FG1000

For those without the time or interest to read the G1000 User Guide, here's a very quick run-down on navigating through the MFD:

General:

  • Click on the buttons, though some are not implemented yet.
  • Use the mouse wheel to scroll the knobs (NAV, HDG, ALT, COM, CRS/BARO, RANGE, FMS). For knobs with both and inner and an outer (NAV, COM, CRS/BARO, FMS), scrolling when pressing the Shift key changes the outer knob.
  • Use the outer FMS knob (shift-mouse wheel on the FMS knob on the bottom right) to navigate through the page groups.
  • Use the inner FMS knob (mouse wheel on the FMS knob on the bottom right) to navigate through the pages within the group. The currently selected page is shown in blue. If you stop moving the cursor, the page will be loaded in 0.5s.
  • Within a page, click on the FMS knob to activate the cursor (CRSR). You you should see some element highlighted on the page, typically flashing. You can navigate around the page using the outer and inner FMS knobs. The Outer FMS knob (shift-mouse wheel) typical moves the cursor between elements. The Inner FMS knob typically changes the selected item.
  • Use the RANGE knob to zoom map views in/out.

PFD

  • Artificial horizon, compass rose, altimeter and airspeed indicator are all hopefully obvious!
  • HSI can display NAV1, NAV2, GPS information (press the CDI softkey)
  • Wind information (press PFD->WIND then select one of the options for display)
  • Bearings to NAV1, NAV2, GPS (press PFD then BRG1/BRG2 to cycle through the options)
  • Inset Map (Press INSET softkey)
  • Active Flight Plan (press FPL when there is an active flightplan to display)
  • DirectTo GPS (press DTO)
  • Transponder (press XPDR)
  • NRST scrolls through information on the 10 nearest airports (press NRST)

MFD

  • There is a two channel NAV/COM with an active and standby frequency and automatic ID of NAV frequencies at the top of the UI. They all integrate with the standard properties, so should work automatically with most aircraft.
  • If you have a frequency highlighted in any of the pages (e.g. WPT - AIRPORT INFORMATION) press the ENT key to load it into the standby NAV/COM frequency as appropriate.
  • To set up a GPS Direct To route:
    • Press the DTO button (D with an arrow through it on the right side of the panel, below the word "PAN"). This will bring up a Direct To window, allowing you to enter the ID of an airport, Fix etc. to navigate to.
    • You can enter the ID in one of three ways:
      • Scroll the FMS knob backwards to bring up a sub-menu of waypoints categories (FPL, NRST, RECENT, USER, AIRWAY). Use the inner FMS knob to scroll between the different categories, and the outer FMS knob to select a specific item.
      • Scroll the FMS knob forwards to enter an ID manually using the FMS knob. Use the outer FMS knob to move to the next poisition in the ID.
      • Use multikey support to type in the ID using the keyboard - type ":ms" followed by the ID. This is by far the fastest method!
    • Once you've got an ID, press ENT which will load details into the window and highlight the ACTIVATE button.
    • Press ENT once more to load the Direct-to into the GPS and activate it.
  • To view airport information, select the WPT - AIRPORT INFORMATION page. Use the outer FMS knob to move between the AIRPORT, RUNWAYS and FREQUENCY boxes, and the inner FMS to edit the airport ID, scroll through available runways, or highlight a frequency.
  • To edit the current flightplan, press the FPL page, then press the CRSR and enter waypoints for DTO above.


GFC700 Autopilot

The GFC700 autopilot is a two axis autopilot with independent lateral and vertical modes. The default later/vertical modes are ROL and PIT, which hold the current roll and pitch respectively. If installed on the aircraft, the GFC700 autopilot is enabled by pressing any of the buttons on the bottom left of the PFD/MFD fascia:

  • AP enables/disables autopilot
  • FD enables a Flight Director mode, displaying control bars to follow manually. Note that this button is disabled when the autopilot is enabled.
  • HDG enables a heading mode, tracking the blue heading bug. Use the HDG knob on the PFD to set.
  • VS enables Vertical Speed hold. Current target is displayed at the top of the PFD. It may be adjusted by using NOSE UP / NOSE DN.
  • ALT enables Altitude Hold, which holds the current altitude.
  • GA enables Go Around, which sets ROL to 0 and PIT to 7 degrees nose up.
  • NAV enables NAV mode. The navigation source depends on what the CDI is set to on the PFD. Currently this is only implemented for GPS.
  • APR enables Approach mode for both vertical and lateral GPS or ILS approaches. Will use the currently selected CDI source.
  • VNV enables vertical NAV mode (not yet implemented)
  • FLC enables Flight Level Change, where the autopilot will maintain the current airspeed by pitch. NOSE UP / NOSE DN is used to set the target airspeed, which is displayed at the top of the PFD, and on the airspeed tape.
  • BC enables Back Course mode (not yet implemented)


Buttons toggle modes on/off, defaulting to ROL for lateral and PIT for vertical. The current pitch setting in PIT mode can be adjusted by using the NOSE UP and NOSE DN buttons.

In PIT/VS/FLC mode, Selected Altitude Capture mode (ALTS) is armed, targetting the current altitude bug. Once the aircraft gets within 200ft of the selected altitude the autopilot will automatically transition to ALTS and then ALT mode to track that altitude. Note that once the altitude is fixed in ALTS mode changing the altitude bug will not change the target altitude.

(Control Wheel Steering (CWS) can be used to set new ROL/PIT targets, but is not yet implemented)

Multikey Support

To improve usability, the FG1000 also supports multikey. If installed on the aircraft (aircraft developers need to include Aircraft/Instruments-3d/FG1000/fg1000-multikey.xml), the following keys are available.

  • ":p" controls the PFD
    • 1- 12 selects the softkeys
    • s allows you to use the keyboard to enter text directly into the PFD, e.g. when entering an airport
  • ":m" controls the MFD
    • 1-12 selects the softkeys
    • a selects the Airport Information page
    • c selects the Checklists page
    • f selects the Flightplan page
    • m selects the Navigation Map page
    • n selects the Nearest Airports page
    • s allows you to use the keyboard to enter text directly into the PFD, e.g. when entering an airport
    • t selects the Traffic Map page

Aircraft Installation

Adding the FG1000 to an aircraft is intended to be fairly straightforward, but there is a little complexity due to properties that different aircraft use, and the Engine Information System (EIS) needing to be different for different powerplants. The J3Cub is a good example to use to see how the FG1000 integration can be done (the c182t isn't a good example as it uses the default FG1000 implementation).

Add the GDU to the cockpit

Place one or more of the display (GDU) units in your model. The XML files are in GDU104X directory and are named <model>.<device-number>.xml, e.g.

GDU-1045.1.xml GDU-1045.2.xml GDU-1045.3.xml GDU-1045.4.xml

The <device-number> is referenced later to identify which displays to used for each PFD, MFD etc. You must only used one of each <device-number> value, though you can mix and match the GDU models.

The different GDU models are as follows:

  • GDU-1040 - No autopilot controls
  • GDU-1044B - autopilot controls without VNAV
  • GDU-1045 - autopilot controls with VNAV

Include the GFC700 autopilot (optional)

If using the 1044B or 1045 GDU, the GFC700 autopilot can be incorporated by adding the following to under /sim/systems

<autopilot>
      <path>Aircraft/Instruments-3d/FG1000/GFC700.xml</path>
</autopilot>

The autopilot has been tuned for the Cessna 182, so may not be correct for light jets.

Load the Interfaces to provide data

This is used to provide airdata, navdata, NAV/COM settings, engine information to the GDUs. There is a generic interface (GenericInterfaceController) that uses the standard FG route manager, GPS, navigation data and NAV/COM settings, and engine data for a single piston engine.

You need to load it as follows:

var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
io.load_nasal(nasal_dir ~ 'Interfaces/GenericInterfaceController.nas', "fg1000");

var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();

You may want to create your own version depending on what properties you are using for the NAV/COM, and your engine configuration. In which case you should copy /Aircraft/Instruments-3d/FG1000/Nasal/Interfaces/GenericInterfaceController.nas into your aircraft Nasal directory, edit it to load any updated interfaces and load it instead:

var aircraft_dir = getprop("/sim/aircraft-dir");
io.load_nasal(aircraft_dir ~ '/Nasal/GenericInterfaceController.nas', "fg1000");

var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();

Note that you should only start the interface after you've started the FG1000 as they will publish information at start of day that the displays need.

Create an EIS Display

This is the Engine Information System and displays on the left side of the MFD.

A simply EIS for the Cessna 182T is provided. For other aircraft you will need to create your own. The simplest way to do this is

  1. Copy Aircraft/Instruments-3d/FG1000/EIS into your aircraft Nasal directory. Re-name EIS-c182t.nas to something sensible (e.g. EIS-[aircraft].nas). Don't forget to rename the class itself!
  2. Copy one of the EIS .svg files from Aircraft/Instruments-3d/FG1000/MFDPages into your aircraft Nasal. Modify it as required, noting the names of objects and how they map to the EIS.nas file.
  3. Edit the SVG and EIS-[aircraft].nas as appropriate. In particular note that the Fuel submenu is used to set the contents of the fuel tanks manually, with a fuel totalizer approach.
  4. Copy Aircraft/Instruments-3d/FG1000/Nasal/Interfaces/GenericEISPublisher.nas into your Nasal directory, and rename it (e.g. [aircraft]EISPublisher.nas. Don't forget to rename the class itself! Modify it to publish the correct set of properties to Emesary. Note that for multiple engine aircraft you need to modify the publish() method.
  5. As noted above, you will need to load a modified version of GenericInterfaceController.nas
  6. Finally, modify whatever Nasal you use to load the FG1000 to pass in the new EIS class and SVG file. Note that you need to load the EIS Controller, style and Options classes as well.

This is what your Nasal file may look like at the end:

# Load a customer Interface controller
var aircraft_dir = getprop("/sim/aircraft-dir");
io.load_nasal(aircraft_dir ~ '/Nasal/GenericInterfaceController.nas', "fg1000");

var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();

io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EIS-J3Cub.nas', "fg1000");
io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EISController.nas', "fg1000");
io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EISStyles.nas', "fg1000");
io.load_nasal(aircraft_dir ~ '/Nasal/EIS/EISOptions.nas', "fg1000");

# This is the class in EIS-J3Cub.nas, loaded above.
var EIS_Class = fg1000.EISJ3Cub;

# Create the FG1000 using custom EIS Class, and the appropriate .svg file.
var fg1000system = fg1000.FG1000.getOrCreateInstance(EIS_Class:EIS_Class, EIS_SVG: "Nasal/EIS/EIS-J3Cub.svg");

Using custom SVG files

To assist in implementing related glass cockpits (e.g. Garmin Perspective on the Cirrus SR22T), you can specify a directory to be used instead of /Aircraft/Instruments-3d/FG1000/MFDPages/ for the SVG files used by the MFD. Note that you must copy across all the .svg files.

# Create the FG1000 using custom EIS Class, and the appropriate .svg file, and a custom path to other SVG files
var fg1000system = fg1000.FG1000.getOrCreateInstance(EIS_Class:EIS_Class, EIS_SVG: "Nasal/EIS/EIS-J3Cub.svg", SVG_Path: "MFDPages/");


Add multikey support

Include Aircraft/Instruments-3d/FG1000/fg1000-multikey.xml in your -set.xml file to support multikey.

  <input>
    <keyboard n="0">
      <multikey include="Aircraft/Instruments-3d/FG1000/fg1000-multikey.xml"/>
    </keyboard>
  <input>


See Howto:Add_multi-key_commands_to_an_aircraft for further details.

Load and start the FG1000 system

A simple FG1000 using the generic EIS, and displaying PFD on device-number 1 and an MFD on device-number 2 is as follows:

var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
io.load_nasal(nasal_dir ~ 'FG1000.nas', "fg1000");

# Create the FG1000
var fg1000system = fg1000.FG1000.getOrCreateInstance();

# Create a PFD as device 1, MFD as device 2
fg1000system.addPFD(index:1);
fg1000system.addMFD(index:2);

# Map the devices to placement objects Screen{i}, in this case Screen1 and Screen2
fg1000system.display(index:1);
fg1000system.display(index:2);

# Show the devices
fg1000system.show(index:1);
fg1000system.show(index:2);

#  Display a GUI version of device 1 at 50% scale.
#fg1000system.displayGUI(index:1, scale:0.5);

Page Status

This is the current status of the individual pages. Full progress bars indicate that they are functionally complete, though the iconography is not correct.

Page Reference Status Notes
Navigation Map 100}% completed See Layers below
Traffic Map 100}% completed Zoom controls unclear
Storm Scope 0}% completed
Weather Data Link 0}% completed
TAWS-B 0}% completed
Airport Information 100}% completed Needs additional page of AOPA information, which we don't have
Intersection Information 100}% completed
NDB Information 100}% completed
VOR Information 100}% completed
User WPT Information 0}% completed
Trip Planning 0}% completed
Utility 0}% completed
GPS Status 0}% completed
XM Radio 0}% completed
System Status 0}% completed
Active Flight Plan 100}% completed Viewing and editing of the active flight plan implemented. VNAV and the "wide view" not yet implemented
Flight Plan Catalog 0}% completed
Stored Flight Plan 0}% completed
Checklist 100}% completed
Nearest Airports 100}% completed
Nearest Intersections 100}% completed
Nearest NDB 100}% completed
Nearest VOR 100}% completed
Nearest User Waypoints 0}% completed
Nearest Frequencies 0}% completed
Nearest Airspaces 0}% completed

This is the current status of the major functional elements

Area Status Notes
Navigation - FMS 100}% completed
Softkeys 100}% completed
MENU key 0}% completed
NAV/COM 90}% completed Volume controls to be added
GPE Header 0}% completed

Motivation

1rightarrow.png See Canvas_News#Moving_map.2FRNAV_discussion for the main article about this subject.

The enormous variety in current glass flight decks means we really need to think of a new way of defining glass cockpit layouts.[2]


The airspace system is in the process of changing drastically [...] this isn't just a matter of throwing up a canvas showing some GPS waypoints and a magenta line. Modern navigators are astoundingly-complex devices — probably an order of magnitude more lines of code than FlightGear itself — and even their basic flight planning algorithms and databases (e.g. fly-by waypoints vs fly-over waypoints, open vs closed approach procedures, transitions into RNAV approaches, etc.) are far beyond the scope of anything we've tried, and we'd also need an up-to-date database far more complex than the ones we have now. Once you get to the extra features, like FIS-B weather or TIS-B traffic info over ADS-B, or TAWS (terrain alerting), we're probably in way over our heads trying to emulate even the simplest general-aviation IFR GPS.

This may help folks understand what the G1000 is all about:[3] Writing a G1000 isn't that hard. Writing a feature complete G1000 is a ton of work. [4]


Depending on how we deal with this challenge, the question is whether that means that the usefulness of FlightGear will also gradually taper off. [5]

Instead of just making one-off tweaks like the consumer sims did, we (as a team) emulated entire systems like the vacuum, pitot-static, and electrical systems, so that failures would be realistic. In the RNAV age, we need to do the same thing; it's just that it's a bigger job. FlightGear will still be great for people who want to practice the mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but will slip further and further behind for people who want to use it for real IFR practice.[6]

Background

1rightarrow.png See Complex Canvas Avionics for the main article about this subject.

Challenges

Performance

Nasal as such is fast, and compared with the cost of rendering the terrain, rendering a canvas display is fast on the GPU (you can test by rendering but not updating a canvas display), and unless you're doing something very inefficient, calculating a display but not writing it to the property tree is fast (you can test this by disabling the write commands). It's the property I/O which you need to structure well, and then canvas will run fast. And of course the complexity of your underlying simulation costs - if you run a thermal model underneath to get real temperature reading, it costs more than inventing the numbers. But that has nothing to do with canvas. [7]


it's a lot of work to code all these displays which someone has to do, but there's no reason to assume it'd be hopeless performance-wise.[8]

we need to be realistic here: The G1000 is a fairly significant piece of computer hardware that we're going to emulate. It's not going to be "free" particularly for those on older hardware that's already struggling. However, hopefully we can offload a chunk of the logic (route management, autopilot/flight director) to the core, and do things like offline generation of terrain maps to minimize the impact.[9]

Route Manager

that's exactly the kind of device James hopes the new code can support. He's read the G1000 pilot's manual, and *thinks* that nearly all the functions can be provided by the current GPS code It would be great if people could look over the current GPS features and indicate any pieces you think might be missing - additional commands, additional search features, extra data, or anything really. [10]

tile servers

Please keep in mind that most tile servers discourage bulk downloads. For the whole planet,oomlevel 8 is approx. 67k files, at zoomlevel 9 you have 265k, level 10 has a little over one million tiles. And one would probably want to go up to level 15 (roughly 1e9 files)[11]

Offline mode

would it be possible to provide an offline tool to pre-fetch a region, like TerraMaster, or terrasync.py? Call me old-fashioned or paranoid, but I don't want FG to go online and do stuff automatically, I prefer downloading what I need manually so that I know what gets onto my harddisk. Also - think of all the people with poor home internet which might have larger bandwidth only in a library elsewhere.[12]

that would certainly be possible - the code retrieving the data is pretty trivial and porting the Nasal code to python or some other script should be straightforward.[13]

Navdata

we need some better data sources, especially with direct routing replacing airways in many areas, and having airspace data would help the map displays, but the current API is specifically designed to support G430, G1000 and similar class devices. Adding RNAV approaches is eminently doable, see the the RNavController base class which the GPS/FMS layer uses to allow new waypoint / route segments to define how they are flown and drive CDIs [14]


Getting the algorithms right, and keeping the data up to date every 7 weeks (we have only a tiny sliver of that data currently), is going to be much more of a challenge. I expect that it's probably an order of magnitude more complicated than our current flight dynamics (etc.), so we'd have to grow our contributor base, and find funding to pay at least Curt (and maybe a couple of others) full time to manage the project. Note that that's what has happened for other complex FOSS projects, like office suites and browsers, which generally end up working through a foundation, rather than our current relaxed circle-of-friends arrangement. The reason it's so much harder now is that the software *is* the product for GPS navigators, FMSs, etc. (unlike with older avionics, where the hardware was the main thing). That means that emulating even a simple unit like the GTN 650 or GNS 430W is almost difficult as building one, so we're trying to keep up with armies of full-time software developers at Garmin, Avidyne, etc.[15]


According to the Route Manager wiki page, we already have support for SID/STAR data provided from Navigraph, which is released on the AIRAC cycle, and costs a pretty small amount (9 EUR for a single download of FMS data, or 90 EUR per year) Given the relatively low cost, I don't think that we as an organiation want to get into trying to digitize data ourselves just to make it open-source or public domain. Particularly given the low cost of a download. We might want to digitize the STAR/SIDs for the default airport with each release so there are some approaches available for those who don't want to purchase the data.[16]

everyone agrees we would like to add airspace data - what we’re missing is a suitable data source with the correct license. Torsten found a raster-based source but for wider use in the sim we really need vector data, so we can render it ourselves directly. [17]

For airspace data we could use https://openflightmaps.org/ . It provides community created navigation data for many countries in (currently only) Europe with a free license.[18]

we definitely want vector data. Stuart is hoping that we might convince the source of the raster data we're using at present to provide it as raw vector data, but we haven't had any luck so far.[19]

Airport Data (US - only )

At least for the US, all required information is available in the form of regularly updated UDFF files:

It would seem relatively straightforward to provide a scripted parser to create the corresponding charts procedurally. As a matter of fact, this could even be done in a background thread or using a separate Python script, i.e. if we wanted to ship pre-created imagery as part of fgdata.

However, if the built-in Canvas system is extended to provide these charts, Phi could also be entirely self-contained by rendering the same airport charts without having to depend on external data sources.


Layers

Following is the list of layers displayed by the G1000 system (see page 153 of the 190-00498-07 Rev. A), and mapping to the equivalent MapStructure Layer. Many of these would also be good to have for other avionics/GUI dialogs, including the NavDisplay framework, which is currently re-implementing this functionality separately, i.e. not yet using MapStructure.

Following is the list of layers displayed by the G1000 system, based on the Garmin G1000 Integrated Flight Deck Pilot's Guide for the Cessna Nav III,[3] page 153, and the mapping to the equivalent MapStructure Layer.

Richard mentioned that if he were to implement approach plates in the EFB he'd probably use raster images provided via http and provide an http service within FG to do this, or to allow the EFB to use any other external web service. Other content for the EFB could be also provided as SVG via http.[20]

Layer MapStructure Layer Type Status Page in [3] Notes
Flight Plan Route Lines RTE offline Requires styling 190
Flight Plan Route Waypoints WPT offline Requires styling 190
Rivers/Lakes VFRChart online 148 Currently using downloaded raster from web. Perhaps generate similarly to Atlas[21], or could be vector data from scenery. Tom originally suggested to directly render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using a custom Canvas View Camera Element, based on the Hackathon Proposal: CompositeViewer and Canvas experiments (see the ideas summarized at Canvas Tile Element). Fernando agreed already that it would be straightforward to apply custom node masks, LOD ranges and even effect schemes per Compositor instance.
Topography Data VFRChart online Synthetic 145 Height-map at chart-resolution. Perhaps generate similarly to Atlas? Tom originally suggested to directly render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using a custom Canvas View Camera Element, based on the Hackathon Proposal: CompositeViewer and Canvas experiments (see the ideas summarized at Canvas Tile Element). Fernando agreed already that it would be straightforward to apply custom node masks, LOD ranges and even effect schemes per Compositor instance.
International Borders 148 Vector data from scenery?
Track Vector 156 Forward looking display of track. Look-ahead time selectable.
Navigation Range Ring offline 159 Straightforward extension of APS.
Fuel Range Ring offline 159 Straightforward extension of APS.
Terrain Data - 364 Should be straightforward, with exception of obstacles. Profile view also required.
Traffic TFC offline 394, 423 Various options, each with different iconography and data displayed.
Airways VFRChart online 154 Needs to be replaced with vector data
NEXRAD unknown 282 Heaps of weather data with complex symbology.
XM Lightning Data WXR offline Change to symbol for lightning? 294 Optional
Airports APT, RWY offline Require re-style based on size 149, 163
Runway Labels RWY offline 148 Needs to be added to RWY. Should be straightforward
Restricted OpenAIP online 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[22]

Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[23] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [24]

MOA (Military) OpenAIP online 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[25]

Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[26] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [27]

User Waypoints offline
Latitude/Longitude Grid GRID offline
NAVAIDs APT, VOR, FIX, NDB offline APT, requires styling 162
Class B Airspaces/TMA OpenAIP online 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[28]

Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[29] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [30]

Class C Airspaces/TCA OpenAIP online 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[31]

Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[32] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [33]

Class D Airspaces OpenAIP online 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[34]

Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[35] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [36]

Other Airspaces/ADIZ OpenAIP online 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[37]

Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[38] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [39]

TFRs unknown 310
Obstacles OpenAIP online 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[40]

Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[41] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [42]

Land/Country Text online 148 Currently using raster data from web. Replace with POI?
Cities VFRChart online 148 Currently using raster data from web. Perhaps generate similarly to Atlas, or could be vector data from scenery. Tom originally suggested to directly render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using a custom Canvas View Camera Element, based on the Hackathon Proposal: CompositeViewer and Canvas experiments (see the ideas summarized at Canvas Tile Element). Fernando agreed already that it would be straightforward to apply custom node masks, LOD ranges and even effect schemes per Compositor instance. [1]
Roads VFRChart online 148 Currently using raster data from web. Requires vector data from scenery
Railroads VFRChart online 148 Currently using raster data from web. Requires vector data from scenery
State/Province Boundaries VFRChart online 148 Currently using raster data from web. Requires vector data from scenery
River/Lake Names VFRChart online 148 Currently using raster data from web. Replace with POI?
Selected Altitude Intercept Arc offline 161 Simple extention to APS
SafeTaxi (Optional) RWY, TAXI offline 493 We don't currently have the data to display taxiway identifier or holding points
ChartView (Optional) offline 503 Rendering of PDFs. Might be possible to integrate with NaviGraph chart data?
FliteChart (Optional) offline 521 Rendering of PDFs. Might be possible to integrate with NaviGraph chart data?

Existing work

Avionics / Cockpits

Nasal / Canvas

C++

Possible Work

Architectural TODO List

This is a short list of architectural improvements I've noted during development that need to be revisited:

  • Use NavMap for MFD Navigation Map, DirectTo, Nearest, Information pages.
  • Separate out the HSI, tapes from the PFD and make them generic MFD UI Elements
  • Improve the performance of the maps, perhaps using a cache for queries, definitely by more aggressive clipping of the SlippyMap layers based on map size.

The layers table shown above mentions a few limitations and ideas, such as:

Nasal/Canvas

C++

  • fix up projection issues, and adopt Gijs' projection handling code for the hard-coded PUI Map, to get rid of the standard Sanson-Flamsteed projection
  • adding a profile view, probably in conjunction with terrain sampling
  • using atlas code to generate heightmaps/topography
  • adding ESRI shapefile support to the Canvas system
  • adding PDF rendering support the Canvas system

Design

The broad structure of the Nasal files in Aircaft/Instruments-3d/FG1000/Nasal is as follows:

  • MFD.nas - top level MFD device, loads the other Nasal files (likely to be moved elsewhere later) and pages.
  • PageGroupControllers.nas - controller for the Page Group display in the bottom right of the MFD, controlled by the FMS knob, and which allows selection between different page groups and individual pages.
  • [PageName]/[PageName].nas - MFD page, inheriting from the MFDPage.nas. Creates any required MapStructure and hierarchy of softkeys.
  • [PageName]/[PageName]Controller.nas - Controller for the MFD page and the MapStructure layers, inheriting from MFDPageController.nas
  • [PageName]/[PageName]Style.nas - Style controls for the MapStructure layers for the given Page.
  • [PageName]/[PageName]Options.nas - Options for the MapStructure layers for the given Page.

Key design notes:

  • Most of the underlying Canvas MapStructure layers are now written (though they require styling, and/or would benefit from replacement with vector data).
  • Emesary IPC framework is used to link between the MFD and underlying simulation state. This should make it easy to run the MFD on a separate FG instance, and provides a good demarkation between the individual aircraft systems and the FG1000 itself.
  • Various underlying UI classes are used to handle highlighting, selection and scrolling of fields. See Canvas MFD Framework for details of the elements now supported.

Resources

Related

Commits

This section is intended to help keep track of related fgdata commits, so that if/when the project should stall, people can more easily look up related changes.


MapStructure related:

References

References
  1. https://forum.flightgear.org/viewtopic.php?f=71&t=32764&start=60#p327229
  2. Robin van Steenbergen  (Oct 2nd, 2007).  Re: [Flightgear-devel] Glass cockpit and external gauges. .
  3. 3.0 3.1 3.2 Garmin G1000 Pilot’s Guide for Cessna Nav III, Rev. A (pdf). Published by Garmin International, Inc.. Archived from the original. Retrieved May 8, 2019.
  4. geneb  (Jul 3rd, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  5. David Megginson  (Jul 3rd, 2017).  [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  6. David Megginson  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  7. Thorsten Renk  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  8. Thorsten Renk  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  9. Stuart Buchanan  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  10. James Turner  (Oct 22nd, 2009).  Re: [Flightgear-devel] ZKV500 GPS instrument; (New?) GPS code bug .
  11. Torsten Dreyer  (Sep 29th, 2017).  Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .
  12. Thorsten Renk  (Sep 29th, 2017).  Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .
  13. Stuart Buchanan  (Sep 29th, 2017).  Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .
  14. James Turner  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  15. David Megginson  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  16. Stuart Buchanan  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  17. James Turner  (Jan 5th, 2018).  Re: [Flightgear-devel] [flightgear/simgear] Nasal regex patch .
  18. TheTom  (Jan 9th, 2018).  Re: Canvas G1000 .
  19. stuart  (Jan 10th, 2018).  Re: Canvas G1000 .
  20. Richard  (Sep 29th, 2015).  Re: .
  21. Torsten  (Mar 17th, 2014).  Re: Atlas still in use ? .
  22. https://sourceforge.net/p/flightgear/mailman/message/37236857/
  23. https://sourceforge.net/p/flightgear/mailman/message/35134193/
  24. https://sourceforge.net/p/flightgear/mailman/message/32143737/
  25. https://sourceforge.net/p/flightgear/mailman/message/37236857/
  26. https://sourceforge.net/p/flightgear/mailman/message/35134193/
  27. https://sourceforge.net/p/flightgear/mailman/message/32143737/
  28. https://sourceforge.net/p/flightgear/mailman/message/37236857/
  29. https://sourceforge.net/p/flightgear/mailman/message/35134193/
  30. https://sourceforge.net/p/flightgear/mailman/message/32143737/
  31. https://sourceforge.net/p/flightgear/mailman/message/37236857/
  32. https://sourceforge.net/p/flightgear/mailman/message/35134193/
  33. https://sourceforge.net/p/flightgear/mailman/message/32143737/
  34. https://sourceforge.net/p/flightgear/mailman/message/37236857/
  35. https://sourceforge.net/p/flightgear/mailman/message/35134193/
  36. https://sourceforge.net/p/flightgear/mailman/message/32143737/
  37. https://sourceforge.net/p/flightgear/mailman/message/37236857/
  38. https://sourceforge.net/p/flightgear/mailman/message/35134193/
  39. https://sourceforge.net/p/flightgear/mailman/message/32143737/
  40. https://sourceforge.net/p/flightgear/mailman/message/37236857/
  41. https://sourceforge.net/p/flightgear/mailman/message/35134193/
  42. https://sourceforge.net/p/flightgear/mailman/message/32143737/