Difference between revisions of "FG1000"

From FlightGear wiki
Jump to: navigation, search
m (November 2017: https://forum.flightgear.org/viewtopic.php?f=71&t=32764&p=322826#p322762)
(Update current status.)
Line 1: Line 1:
 
[[File:Fg1000 mfd.jpg|thumb|PUI-canvas FG1000 early prototype using PUI dialog to speed up development]]
 
[[File:Fg1000 mfd.jpg|thumb|PUI-canvas FG1000 early prototype using PUI dialog to speed up development]]
  
== Status ==
+
== Current Status ==
  
Most of the underlying MapStructure layers are now written (though they require styling, and/or would benefit from replacement with vector data)Stuart has started working on the initial architecture using the MFD framework, using an initial PUI-based prototype to speed up development.  This has the great benefit of allowing all the code to be re-loaded every time the dialog loads, rather than requiring a re-init of the aircraft.  It also helps ensure the architecture isn't dependent on a particular model.
+
An initial implementation of the MFD with two pages (Navigation Map and Traffic Map) is available on git/next from the Debug Menu->FG1000It includes a PUI-based surround, Engine Information System (early prototype), page group selection using the FMS control, and the two pages.
  
{{Main article|Canvas_News#G1000_.26_MapStructure_improvements}}
+
Most of the underlying MapStructure layers are now written (though they require styling, and/or would benefit from replacement with vector data).  
Stuart wants to build a set of layers for a G1000-like implementation - the canvas map UI is really just a way to display it. <ref>{{cite web
+
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36059733/
+
  |title  =  <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
+
VFR Sectionals </nowiki>
+
  |author =  <nowiki> Stuart Buchanan </nowiki>
+
  |date  =  Oct 1st, 2017
+
  |added  =  Oct 1st, 2017
+
  |script_version = 0.40
+
  }}</ref>
+
  
 
+
Next steps:
See [[#Layers]]
+
- Writing the remaining (large) number of pages
 
+
- Styling the pages - making the iconography match Garmin exactly.
=== November 2017 ===
+
Here is a little update o the G1000 emulation. Stuart has now got the key [[MapStructure]] layers in place, though they are not styled correctly for the '''G1000''' yet and Stuart would like to replace some of them (airspace in particular) with vector data, and started on the MFD architecture. For prototyping he hacked together a [[PUI]] dialog box, which speeds up development massively as it reloads all the Nasal code each time it's opened.
+
 
+
There's a screenshot of it here: [[File:Fg1000_mfd.jpg]]
+
 
+
There's also a wiki page of the current status here: http://wiki.flightgear.org/FG1000 Next steps are to get the MFD architecture in place - this will probably require some changes to Richard's generic [[Canvas MFD Framework|MFD]] to support buttons that don't change the MFD pages better. Stuart has not yet pushed this to fgdata - he'll wait until he's happy with the overall architectures so that there is a solid base for anyone else interested in helping out.<ref>{{cite web
+
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36103513/
+
  |title  =  <nowiki> [Flightgear-devel] FG1000 update </nowiki>
+
  |author =  <nowiki> Stuart Buchanan </nowiki>
+
  |date  =  Nov 4th, 2017
+
  |added  =  Nov 4th, 2017
+
  |script_version = 0.40
+
  }}</ref>
+
 
+
Richard kindly added the Emesary support so that Stuart could use it for the FG1000 to help get the architecture right. For the moment he's got the GUI calling Emesary directly, but there's no reason why he can't change that to fgcommands in the future. Stuart thinks he wants to get slightly further in my work before he'll do that though - i.e. he wants to have some confidence that he is creating the right granularity of commands first.
+
 
+
Stuart is hoping to have a first version of the FG1000 MFD using a PUI surround and with two example pages (Navigation Map and the Traffic Map), the EIS and page navigation complete in mid December 2017. He is hoping that once he's got that done he'll have created enough of a framework that the rest of the MFD pages can be created relatively easily without some massive re-factoring effort <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=32764&p=322826#p322762</ref>.
+
 
+
=== October 2017 ===
+
[[File:MapStructure-GRID-layer.png|thumb|Screenshot showing Stuart's new MapStructure GRID layer <ref>https://sourceforge.net/p/flightgear/fgdata/ci/4bd57492f454a05f725e6fe5a80dc246cb5e5e0f/</ref>]]
+
 
+
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/36075357/
+
  |title  =  <nowiki> [Flightgear-devel] Updated Select Airport dialog </nowiki>
+
  |author =  <nowiki> Stuart Buchanan </nowiki>
+
  |date  =  Oct 13th, 2017
+
  |added  =  Oct 13th, 2017
+
  |script_version = 0.40
+
  }}</ref>
+
 
+
Stuart also implemented a GRID layer for rendering a lat/lon grid <ref>https://sourceforge.net/p/flightgear/fgdata/ci/4bd57492f454a05f725e6fe5a80dc246cb5e5e0f/</ref>.
+
 
+
=== September 2017 ===
+
Stuart added some new Nasal Canvas MapLayers to support Slippy Maps, as used by most web-based mapping services such as openstreetmap. This allows us to display sectional charts (for the US - vfrmap.com), and airspace information (courtesy of openaip.org), as well as a openstreetmap data. The canvas Map dialog has been updated to support these layers. Map data is retrieved over http and cached locally.<ref>{{cite web
+
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36056088/
+
  |title  =  <nowiki> [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
+
VFR Sectionals </nowiki>
+
  |author =  <nowiki> Stuart Buchanan </nowiki>
+
  |date  =  Sep 28th, 2017
+
  |added  =  Sep 28th, 2017
+
  |script_version = 0.40
+
  }}</ref>
+
  
 
== Motivation ==
 
== Motivation ==

Revision as of 18:09, 24 November 2017

PUI-canvas FG1000 early prototype using PUI dialog to speed up development

Current Status

An initial implementation of the MFD with two pages (Navigation Map and Traffic Map) is available on git/next from the Debug Menu->FG1000. It includes a PUI-based surround, Engine Information System (early prototype), page group selection using the FMS control, and the two pages.

Most of the underlying MapStructure layers are now written (though they require styling, and/or would benefit from replacement with vector data).

Next steps: - Writing the remaining (large) number of pages - Styling the pages - making the iconography match Garmin exactly.

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.[1]


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: http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf Writing a G1000 isn't that hard. Writing a feature complete G1000 is a ton of work. [2]


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

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.[4]

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. [5]


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.[6]

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.[7]

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. [8]

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)[9]

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.[10]

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.[11]

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 [12]


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.[13]


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.[14]

Plan

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 Richard's MFD code and making as generic pages as possible for other glass cockpit applications.[15]


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 Garmin Site Wayback machine, page 153, and the mapping to the equivalent MapStructure Layer.

Layer MapStructure Layer Status Page Notes
Flight Plan Route Lines RTE Requires styling p.190
Flight Plan Route Waypoints WPT Requires styling p.190
Rivers/Lakes VFRChart p.148 Currently using downloaded raster from web. Perhaps generate similarly to Atlas[16], or could be vector data from scenery. Tom originally suggested to render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using Icecode GL's recent camview element.(see Canvas Tile Element)
Topography Data VFRChart Synthetic p.145 Height-map at chart-resolution. Perhaps generate similarly to Atlas? Tom originally suggested to render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using Icecode GL's recent camview element.(see Canvas Tile Element)
International Borders p.148 Vector data from scenery?
Track Vector p.156 Forward looking display of track. Look-ahead time selectable.
Navigation Range Ring p.159 Straightforward extension of APS.
Fuel Range Ring 159 Straightforward extension of APS.
Terrain Data 364 Should be straightforward, with exception of obstacles. Profile view also required.
Traffic TFC 394,423 Various options, each with different iconography and data displayed.
Airways VFRChart 154 Needs to be replaced with vector data
NEXRAD 282 Heaps of weather data with complex symbology.
XM Lightning Data WXR Change to symbol for lightning? 294 Optional
Airports APT, RWY Require re-style based on size 149, 163
Runway Labels RWY 148 Needs to be added to RWY. Should be straightforward
Restricted OpenAIP 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data.
MOA (Military) OpenAIP 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data.
User Waypoints
Latitude/Longitude Grid GRID
NAVAIDs APT, VOR, FIX, NDB Requires styling 162
Class B Airspaces/TMA OpenAIP 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data.
Class C Airspaces/TCA OpenAIP 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data.
Class D Airspaces OpenAIP 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data.
Other Airspaces/ADIZ OpenAIP 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data.
TFRs 310
Obstacles OpenAIP 182 Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data.
Land/Country Text 148 Currently using raster data from web. Replace with POI?
Cities VFRChart 148 Currently using raster data from web. Perhaps generate similarly to Atlas, or could be vector data from scenery. Tom originally suggested to render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using Icecode GL's recent camview element.(see Canvas Tile Element)
Roads VFRChart 148 Currently using raster data from web. Requires vector data from scenery
Railroads VFRChart 148 Currently using raster data from web. Requires vector data from scenery
State/Province Boundaries VFRChart 148 Currently using raster data from web. Requires vector data from scenery
River/Lake Names VFRChart 148 Currently using raster data from web. Replace with POI?
Selected Altitude Intercept Arc 161 Simple extention to APS
SafeTaxi (Optional) RWY, TAXI 493 We don't currently have the data to display taxiway identifier or holding points
ChartView (Optional) 503 Rendering of PDFs. Might be possible to integrate with NaviGraph chart data?
FliteChart (Optional) 521 Rendering of PDFs. Might be possible to integrate with NaviGraph chart data?

Existing work

Avionics / Cockpits

Nasal / Canvas

C++

  • Atlas map creation
  • Synthetic Vision element for rendering viewmgr views to a Canvas
  • Canvas PDF element - for rendering PDF files (think EFB functionality)

Possible Work

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

Structure

Design

Resources

Related

Commits

References

References
  1. Robin van Steenbergen  (Oct 2nd, 2007).  Re: [Flightgear-devel] Glass cockpit and external gauges. .
  2. geneb  (Jul 3rd, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  3. David Megginson  (Jul 3rd, 2017).  [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  4. David Megginson  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  5. Thorsten Renk  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  6. Thorsten Renk  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  7. Stuart Buchanan  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  8. James Turner  (Oct 22nd, 2009).  Re: [Flightgear-devel] ZKV500 GPS instrument; (New?) GPS code bug .
  9. Torsten Dreyer  (Sep 29th, 2017).  Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .
  10. Thorsten Renk  (Sep 29th, 2017).  Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .
  11. Stuart Buchanan  (Sep 29th, 2017).  Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .
  12. James Turner  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  13. David Megginson  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  14. Stuart Buchanan  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  15. Stuart Buchanan  (Aug 1st, 2017).  [Flightgear-devel] G1000 (was Re: Nasal property lookup performance) .
  16. Torsten  (Mar 17th, 2014).  Re: Atlas still in use ? .