Complex Canvas avionics

This article is a stub. You can help the wiki by expanding it.

Background

The airspace system is in the process of changing drastically, and I'm following it this summer by finally biting the bullet and installing an IFR GPS (Garmin GTN 650) and ADS-B transponder (Garmin GTX 345) in my Piper Warrior II. What this means that for the first time in the 15 years since I started flying in real life, I won't be able to use FlightGear to practice the IFR approaches I'm flying in real life. — David Megginson  (Jul 3rd, 2017).  [Flightgear-devel] RFD: FlightGear and the changing state of air navigation . (powered by Instant-Cquotes)

Objective

Provide a summary of potential improvements to make the development of complex Canvas-based avionics feasible.

Ideas

• Integrate Gijs' projection handling patches (see Map dialog)
• Avoid/speed up property I/O
• Implement support for symbol/element instancing (as per James' original comments)
• Use native C++ code for animation handling instead of dozens of Nasal timers/listeners per element
• Review Richard's MFD framework to make concepts like "screen", "page", "pageElement" first class concepts at the Canvas::Element/Canvas::Group level
• state management should probably be handled by the corresponding SimGear state machine code and not tons of custom Nasal code
• determine what may be missing in terms of new/optimized Canvas elements for special purposes (i.e. best using native C++ code instead of custom Nasal hacks), e.g.:
  • CanvasPDF - for EFBs
  • Canvas3DModel - for visualizing airspaces

Making an MFD

Note that 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. — David Megginson  (Jul 3rd, 2017).  [Flightgear-devel] RFD: FlightGear and the changing state of air navigation . (powered by Instant-Cquotes)

As I tell my students in real life: Don't get intimidated or hypnotied by the huge number of features. 90% of the value comes from 10% of the features. Actually that's becoming more and more of an understatement. With rare exceptions, you can ignore the features you're not using. This is relevant to FG in the sense that it is not important to implement all the features. Most can be left out in the short term, and some can be left out forever. — John Denker  (Jul 3rd, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation . (powered by Instant-Cquotes)

I think there has been some development in this area for some time, but it's not clear how complete it is in terms of going beyond a PFD displaying basic flight information digitally. For example zakharov on the forum has been developing a Garmin G1000 clone called the zkv1000: https://forum.flightgear.org/viewtopic.php?f=14&t=32056 The DA-42 model uses some form of G1000 as well - which may be an older version of the zkv1000. I agree that this is something we need to address, as our GA aircraft will otherwise become more and more old-fashioned. I'm more optimistic than David - I think we do have the capability to write this - for example just look at the complexity of the Shuttle model. — Stuart Buchanan  (Jul 3rd, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation . (powered by Instant-Cquotes)

References

References