Avidyne Entegra R9 Refactoring
| 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 ?
Highly sophisticated Glass Cockpit/Integrated Flight Deck (IFD)
|Status||Under active development as of 06/2013|
|Related Canvas Frameworks|
| The FlightGear forum has a
subforum related to: Canvas
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) .
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.
|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 .
|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.
The widget selects the way it updates the canvas.
— D-Leon (Sat Feb 22). extra500 - Avidyne Entegra 9 IFD - approach.
|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 ?
— Hooray (Sat Feb 22). Re: extra500 - Avidyne Entegra 9 IFD - approach.
|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.
— Hooray (Sat Feb 22). Re: extra500 - Avidyne Entegra 9 IFD - approach.
|Performance||Improve overall Entegra/R9 performance||Not done||(people)||should adopt MapStructure for mapping|
|Generalization||Unify MapIconCache with SymbolCache and move it to the canvas namespace||Not done||Hooray|
|Generalization||Identify, extract & generalize useful code (e.g. MFD handling for buttons, modes and pages)||Hooray||also look at Garmin GPSMap 196|
|Additional Charts||Investigate which MapStructure are needed||Not done||...||...|
|Modularization||get rid of internal design assumptions and decouple the design||Not done||...||...|
|Frameworks||extract wrappers for PFD & animation handling||Not done||...||...|
|NavDisplay support||generalize Gijs' NavDisplay code to support the R9||Not done||Hooray||...|
|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.