Complex Canvas avionics

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

Background

See also Canvas_News#Moving_map.2FRNAV_discussion.

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)

As of 09/2017, Stuart started making some tentative steps towards a full Garmin G1000 simulation, he started with the excellent xkv1000 as a starting point, particularly for the PFD which very closely mirrors the G1000.

For the MFD he's planning to use the Canvas MapStructure layers (obviously). One area he is going to have to develop is tiled mapping, which the MapStructure in fgdata doesn't currently support as a layer.

Stuart's thoughts are:

1. Create an OverlayLayer layer with a controller that is analogous to the SymbolLayer, but likely with a simple update method rather than SearchCmd, and no .symbol equivalent
2. Convert the tiled map example from the wiki, but also other layers such as a compass rose, airport diagram, lat/lon grid.

Stuart is currently undecided on how to handle the projection - whether to have the layer itself have to interpret the centerpoint of the map and scale, and then make a projection itself, or to provide it from the Map. The latter in undoubtably cleaner, but for something like a tiled map he suspects that the management will need to be quite low down the stack.

Objective

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

Ideas

• Integrate Gijs' projection handling patches (see Map dialog)
• reduce/speed up property I/O
• Come up with new Nasal APIs for operating on Nasal vectors (setpropv/getpropv)
• 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
• Equally look at some of the other MFD examples to see if generic building blocks can be extracted
• 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)

Navigation data

There's no public-domain source right now, so we'll have to make it happen somehow.

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

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.

The G1000 & Canvas

Here's the list of main pages and how they would map:

1. Map - We already have mapping solutions, and the canvas one would seem to get most of the way there
2. Traffic - Again, we've already got AI objects displayed on in-sim maps, so this is done
3. Terrain - Slightly trickier. Depending on the resolution required, we could do some terrain sampling and colour a canvas?
4. Weather - This looks much more challenging. Not sure if we could do this.
5. Default Nav - this is just some straightforward property display 6) Flight Plan - This is a UI interfacing the FG Route manager. Frankly, I suspect we'd probably just bring up the existing Route Manager dialog at this point, as entering a route via a simulated touchscreen doesn't sound like a fun way to spend a Sunday afternoon! :)
6. Proc - Setting the STAR/SID to use. We already have this function in the Route Manager. There is an issue with getting the underlying data, though there are tools to upload Navigraph into the Route Manager.
7. Nearest - This is just a lookup into our existing airport and fix DBs. So, I think most of the fundamentals are there - it's "just" a case of combining them into an instrument that mimics the GTN 650.

the buttonology is an important part of training, so we'll need to support that somehow (if we want to be used for IFR training). For the route manager, we might have to make some tweaks, including fly-by vs fly-over waypoints.

Overall, the display doesn't have more than 50 unique parameters you need to update per cycle - for most pages significantly less. All the config pages have lots of items - but you only need to update them when they change. All the fancy airport and weather charts absolutely do not need updates per-frame - your airport isn't going anywhere or changing in a hurry - you can just draw the whole layer _once_ before you bring it on-screen and then use a global transform to move it as the plane moves and run lay updates on the edges. Precipitation you can update whenever FG updates precipitation (every few minutes). Most maps can be done as cheap raster images rather than vector data (the Saab Viggen just downloads them on the fly for instance). So yeah, 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.

after looking into the G1000 manual, it's Thorsten's considered opinion that it is possible to use canvas to render it with decent performance on mid-range modern hardware (not on 10 year old computers though), that I he has a decent picture how it needs to be organized and that the Shuttle MDU code (using Richard's framework to organize everything into pages and the optimization techniques we've learned to use for the pages themselves) exemplifies this

there's code examples and experience available. You can basically start by looking into Richard's MFD canvas wrapper and go from there.

The FG Route Manager provide the RNAV function (http://wiki.flightgear.org/Route_manager), plus logic to connect it as an autopilot source. Switching the CDI to an ILS at the end of the route is pretty straightforward: just put a Nasal listener on /route-manager/signals/finished and then check for a decent ILS signal.

there will be some tweaks requires for the Route Manager for fly-by, fly-over, those radius turn things. But that's really just an extension of what is already there.

we already have a ton of this code - sids, stars, approaches, tagging missed approach segments, fly-over vs fly-by waypoints.

How to proceed

One thing Stuart pointed out is that, in the last couple of years, that aircraft development has moved on from being a "one man show" to being a team effort, with tightly knit teams working together to produce really high quality work. Examples are the updated c172p, Shuttle, J3Cub and probably many others. This is is a (very positive!) reaction to the amount of work required for high fidelity models, and has allowed much more rapid development, which has created a positive feedback loop, as well as allowing specialiation. That model seems to bode well for developing a complex system like this, and can develop organically.

the FG team (in the very wide sense) has the skills and infrastructure to do this, and with sufficient interest could have a respectable G1000 implementation within 12 months.

Stuart suggested that identifying a particular piece to develop as a "reference model" in the same way that the c172p is the "reference aircraft" would be a good start as it would allow us to focus on getting one thing right, doing the G1000 (NXi) would be most useful, as it's fitted to the Cessna 172, 182, Caravan, Mustang, and Piper Archer, many of which we already have as airframes in FG. The G1000 also has the advantage tha takh has already done some of the work already for the zhk1000 (https://seb.lautre.net/git/seb/zkv1000).

since we're not writing software for a real hardware device but just a simulation of one, this is _a lot_ less work than a real GPS. Not only do we never need to extract any information from real satellite signals, but we also utilie TONS of existing work - for instance a canvas display call goes through the canvas API, that calls Shiva (or how it's called) - which we didn't write - that in turn calls OSG (which we didn't write), this calls OpenGL code (which we didn't write), that ultimately calls GPU driver functionality (which we didn't write),... if you sum all that, we are likely effectively utilizing 'millions of lines' of code (or a lot anyway) - we just don't have to write it all ourselves.

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.

References

References