Avidyne Entegra R9 Refactoring

From FlightGear wiki
Jump to: navigation, search
This article has been nominated for deletion since 18 April 2020. To discuss it, please visit the talk page.

Do not remove this tag until the discussion is closed.

Reason for the nomination: Obviously obsolete, none of this got ever addressed, and there no longer seems to be any interest in generalizing the instrument to make it reusable by other aircraft ?

Avidyne Entegra R9
Started in 06/2013

Highly sophisticated Glass Cockpit/Integrated Flight Deck (IFD)

  • D-LEON
  • D-EKEW
Status Under active development as of 06/2013
Topic branches:
fgdata gitorious/extra500/extra500/HEAD (Nasal/AvidyneEntegra9)

The Avidyne Entegra R9 is a glass cockpit instrument that is currently only available on the Extra500, it makes extensive use of Nasal, OOP and Canvas. The purpose of this article is not to document the actual instrument, but to streamline future development in order to avoid wasted/redundant efforts due to lack of coordination among Nasal/Canvas developers working on conceptually similar/identical MFD instruments/displays.

The code implementing the instrument is among the most-structured pieces of Nasal avionics code currently available in FlightGear, which makes use of lots of advanced programming constructs, including design patterns like MVC, observer, singletons etc. Unlike the majority of other Canvas-based instruments like the PFD/ND and EFB code, it was also properly designed to support multiple instances per aircraft right from the beginning, and encapsulates the concept of MFD pages and different page elements.

While the code itself is fairly sophisticated it is currently still highly specific to the extra500, but also to the Entegra R9 instrument itself, despite the fact that there's a lot of shared/common, and even identical, functionality required to model any MFD instrument, such as e.g. the Garmin GPSMap 196.

We believe that refactoring the code to isolate useful building blocks and encapsulate functionality, would help reduce the overhead to further develop and maintain the code, while also ensuring that useful contributions can be gathered in a dedicated library/framework, so that similar efforts can benefit from the existing code, such as NavDisplay, MapStructure, Canvas Animation Framework and Canvas MFD Framework.

Over time, these frameworks will basically materialize automatically if we constantly generalize complex avionics code and try to put similar functionality into corresponding libraries.

In addition, the R9 is one of the most complex, and most integrated, glass cockpit displays, much more integrated and sophisticated than typical airliner avionics, because it contains PFD/ND/CDU and EFB functionality and also fairly advanced GUI support, thus it is an ideal use-case, and testbed, to identify, extract and generalize useful functionality that will automatically benefit other aircraft, which are likely to require much less sophisticated avionics in comparison.

Also, the R9 contains fairly advanced support for different types of maps and charts, those should ideally be implemented on top of the MapStructure framework in order to ensure that these are efficiently handled, but also so that such charts can be easily reused for other purposes, including GUI use-cases.

Even just the "mapping" part of the instrument could greatly benefit from MapStructure (and vice versa, once the Avidyne implements the corresponding layers) [1].

The whole point of using a framework-centric approach is is BECAUSE Nasal IS slower than C/C ++

That is why we NEED to have a single back-end that can be heavily optimized, and parts of it re-implemented in C++ This is already happening with the MapStructure code.

MapStructure is not just a "generic map", it is a MVC framework for Nasal/Canvas in general, mapping is just one manifestation of it at the moment. Right, it wasn't planned that way, but we have already added layers that are not strictly about mapping.


Cquote1.png But the most surprising aspect to me is this: There's exceptionally well-written Nasal code all over the place that's making use of Canvas, and it is much cleaner than the NavDisplay code we have - even though, the latter s certainly more efficient mainly due to MapStructure.

Overall, I am kinda surprised that we have people around here who write such high quality Nasal/Canvas code, without getting involved in the NavDisplay/MapStructure or Canvas efforts themselves - the extra500 Nasal/Canvas code really is exceptionally clean, it is object-oriented and uses interfaces and design patterns - so whoever wrote it, should really get involved immediately in the NavDisplay/MapStructure/Canvas effort to help ensure that things are sufficiently generalized and reusable.

It really is kinda unfortunate that much of this code has apparently been written prior to us starting with the whole ND/MapStructure journey without anybody here speaking up, it could have saved you & us quite some time ... I don't think that our work was "hidden" at all.

Now, fact is: 1) The NavDisplay code is not going to beat the quality of code in the extra500, but likewise: the extra500 Nasal/Canvas code is not going to beat the performance and generic nature of the NavDisplay/MapStructure efforts anytime soon - in other words: please speak up and get involved, so that we coordinate things a little better here and ensure that both frameworks are sufficiently generalized and can benefit from each other.

— Hooray (Thu Feb 20). Re: New Aircraft: the .
Cquote1.png I am just trying to make sure that good & useful stuff can be easily reused in other places, but also maintained by others, i.e. by not being aircraft-specific. This is basically the same issue that we talked about in the context of the IFD/mapping mode vs. MapStructure:

You guys are not just average FG contributors who only just picked up programming recently, most of your code is of much higher quality than we get to see in aircraft-specific code - no matter if it's the Avidyne Entegra R9 or now the checklist.nas stuff - it's just implemented in a very use-case and aircraft-specific fashion, which I find a pity - given that there are so many opportunities for similar efforts to mutually benefit from each other. Your GUI/widget handling stuff is another example, because it's clearly overlapping with our Canvas/GUI efforts.

Overall, I'd suggest to keep the amount of aircraft/instrument-specific "code" low, and try to use separate modules (clas...s about sharing our workload and finding common/overlapping areas of work.
Currently, we have a few optimizations pending on the MapStructure side of things, from which the extra500/Avidyne Entegra R9 cannot benefit for the time being - and I am sure that you guys are also working on features that would be useful to have outside the extra500, no matter if that involves MapStructure and Canvas or not. $FG_ROOT/Nasal exists for a reason: to keep generic code outside $FG_AIRCRAFT, and to allow it to be reusable. Imagine for a second that TheTom's canvas system would only be supported by his C130J, or that the ND/map code would only be available in Gijs' 747-400 or Hyde's 777-200 - yes, coordination and collaboration can be painful at times, but it's well worth it

— Hooray (Tue Jun 24). Re: New Aircraft: the Extra500.
(powered by Instant-Cquotes)
Cquote1.png the main challenge remains thinking in terms of building blocks and frameworks that are simple and generic enough to satisfy all existing use-cases.

We have a number of people doing heavily related work without any collaboration, or even just coordination, going on here unfortunately. And obviously, skills, experience and expertise vary greatly. Unfortunately, some of the most skilled contributors are least willing to collaborate efficiently, while some of the most active contributors have yet to wrap their heads around important Nasal/Canvas concepts. All this is further complicated by the fact that some people write exceptionally good code that is never generalized and committed, while others write pretty poor code, that is directly committed to fgdata. So there's that, too ...

Organizing this whole mess takes up a lot of energy, and usually turns out to take away all the "fun" for people unfortunately.
But there's at least a dozen people here, with varying Nasal/Canvas expertise, that are doing heavily redundant work due to lack of coordination and collaboration, sometimes it's even up to 60-80% of their work/time that could be saved by communicating up-front and getting in touch with people who've done similar things. Unfortunately, that's something that still has to happen ...

— Hooray (Wed Jul 23). Re: Garmin gns530.
(powered by Instant-Cquotes)
This is an adapted version of the Garmin GPSMap 196 that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space without using any Nasal, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, NavDisplay or EFB. For details, please see Canvas Glass Cockpit Efforts.

Error creating thumbnail: File missing
This demonstrates how a purely XML-based MFD framework can instantiate dynamic MapStructure layers - none of this involves any Nasal coding now, it's just an XML file - to learn more, see Canvas Glass Cockpit Efforts.

Refactoring reasons

Cquote1.png if a object is not visible there should be no call to the canvas api.

The update20Hz/update2Hz are selectively used by the widgets to avoid foreach calls in the Page.

At initialization time the page parse the svg and creates the widgets by pushing the "root-group" into the widget. I thought one svg per page is better to maintain.

The widget collects the needed elements by "getElementById()" and stores it for later use.
So at runtime there should be no "getElementById()" call and only the necessary animation calls of the visible objects are pumped.

The widget selects the way it updates the canvas.
Via update20Hz, update2Hz, listener or direct button callback.

NOTE: This sounds like a reusable framework but the encapsulation isn't as far and its optimised for the internal need.
There are some calls going over parents where no interface is "rechable" or defined.

— D-Leon (Sat Feb 22). extra500 - Avidyne Entegra 9 IFD - approach.
Cquote1.png we already spent 20 minutes examining all your code there -like I said in the other thread, we were kinda surprised seeing OOP code using design patterns solving a problem that we have been working on for several months. Actually, had we seen your code earlier, it would have been a much more mature foundation for a generic ND/MapStructure framework, because of it's OO nature. But in the meantime, we've come up with something fairly generic - mostly thanks to Philosopher's MapStructure framework. We were actually planning on getting in touch with you, to help you generalize things a little more, and extract useful bits out into a dedicated Canvas module, while also adopting the ND code (or at least MapStructure) internally. Is that something that you'd be interested in working out with us ?
Cquote1.png I find this pretty discouraging - in this instance, it's "just" a 3D model and maybe a few textures triggering the removal of the Honda jet, but it affects the contribution as a whole, i.e. possibly hundreds of hours of time that now went into the "waste bin" - traditionally, our aircraft developers are really not "developers" at all, they're usually "artists", in the sense that they create artwork like 3D models and textures.

Many aircraft developers struggle with important concepts like "reusability" and "modularization". Despite those being feasible, even in 3D modeling and XML space.

At the end of the day, that means that we're yanking 100% of the work (i.e. the whole aircraft), even though it may very well only be 10-20% of the work that is "offending" - simply because of the way FlightGear development is disorganized and chaotic at times, and because aircraft developers tend to ignore the bigger picture, i.e. implement individual aircraft, rather than focus on generic building blocks that are modular, and live outside the aircraft directory.
Cquote1.png what would make sense is teaching aircraft developers how to contribute in a "safer" fashion, through generic contributions that are aircraft-agnostic, that come in the form of modular building blocks, and that cannot be realistically requested to be yanked completely from the simulator.
Cquote1.png We have other examples for very complex aircraft, modeled fairly well within FG - such as the extra500, and its Avidyne Entegra R9 avionics - once some copyright holders show up and request removal of certain aircraft/instruments, all that work would also be wasted.
Which is another reason why "aircraft developers" should honestly follow the advice given by more experienced developers to favor a less aircraft-specific development philosophy, and really focus on generic building blocks instead, that live outside the actual aircraft folder.
Cquote1.png For example, look at Gijs' original Boeing/NavDisplay code: realistically, it represents maybe 5-10% of the functionality provided by the real thing - but someone requesting for it, and the 747-400, to be removed from FG, may very well be possible, as has been demonstrated by this precedent.
Thus, what we really need to do is identify building blocks and ensure that contributions are aircraft-agnostic, so that there's never a single point of failure, no matter the scenario.

In the case of Gijs' original NavDisplay code, it's no longer aircraft specific, and it is not even device specific - so no matter how many copyright holders will show up, stuff could be removed, without affecting the key functionality, which is these days the MapStructure framework created by Philosopher.

Cquote1.png Another consideration that was important in the way the ND code ended up being "structured" is that we wanted to decouple aircraft specific development from "framework" development. Currently, there's really just a single ND version coded: Boeing - but it's prepared to be easily adaptable for other types of aircraft/manufacturers.

Cquote1.png Seriously, back in the pre-canvas days we had just a handful of hard-coded "glass" instruments, like the agradar, wxradar, groundradar and Zakalawe's navdisplay - technically, those were all SPOFs to the project - because people didn't focus on building blocks and infrastructure, but instead implemented specific devices. These days, Canvas is no longer about a single thing, it's not about a single aircraft, not about a single instrument, or a certain type of instrument. It's as generic as it can get.
Cquote1.png I would very much regret seeing more work, like the extra500, pulled from FlightGear due to questionable reasons - but given the lack of legal backup and funding, it is not unlikely to see certain contributions be endangered at some point - even if just for the single reason that there are companies providing similar products as pay-ware, wanting to protect their revenue.


Goal Description Progress People Comments
Performance Improve overall Entegra/R9 performance Not done Not done (people) should adopt MapStructure for mapping
Generalization Unify MapIconCache with SymbolCache and move it to the canvas namespace Not done Not done Hooray
Generalization Identify, extract & generalize useful code (e.g. MFD handling for buttons, modes and pages) 10}% completed Hooray also look at Garmin GPSMap 196
Additional Charts Investigate which MapStructure are needed Not done Not done ... ...
Modularization get rid of internal design assumptions and decouple the design Not done Not done ... ...
Frameworks extract wrappers for PFD & animation handling Not done Not done ... ...
NavDisplay support generalize Gijs' NavDisplay code to support the R9 Not done Not done Hooray ...

MapStructure Integration

Cquote1.png Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term. This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code. But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time.
— Hooray (Wed May 14). Re: scaling instruments in xml.