Canvas PFD framework

From FlightGear wiki
Revision as of 20:13, 29 February 2016 by Bugman (talk | contribs) (Switch to {{gitorious source}} and {{fgaddon source}} to provide functional links to the archived repositories.)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

Note: While this article is based on considerable community feedback, there's nobody working on this currently.
So if you'd like to help in one way or another, please get in touch or just help improve the article in the meantime!
Useful Skills:
PropertyList XML File, Property Tree, Nasal scripting, Canvas, Gijs' 747-400 PFD, CanvasMFD, NavDisplay, MapStructure


People:

Mentors: Gijs, Hooray (get in touch to learn more)
It's possible that this article hasn't been updated in a while, so to catch up with the latest developments, you are advised not to start working on anything directly related to this without first coordinating your ideas with fellow FlightGear contributors using the FlightGear developers mailing list or the FlightGear forums. See also the talk page.


Canvas PFD Framework
Boeing 747-400 PFD and ND approach EHAM 18R.png
Started in not yet...
Description PFD Framework
Contributor(s) Hooray (if nobody beats me to it),
Status discussion
Subforum http://forum.flightgear.org/viewforum.php?f=71



Background

Note  Please also see Howto:Coding a simple Nasal Framework and check out the 744 and Avidyne Entegra R9 PFD https://gitorious.org/extra500/extra500?p=extra500:extra500.git;a=blob;f=Nasal/AvidyneEntegra9/page_PFD.nas
Cquote1.png Note that I'm still working on the PFD, so I'd suggest not to spend too much time on it right now. I've planned to have an aircraft agnostic version, like the ND, well in time for FlightGear 3.4..
— Gijs (Mon Sep 22). Re: Boeing 707 VIP.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Regarding the PFD, I'd prefer not to add too much to that code, until it is sufficiently generalized, too - currently, it's suffering from very real design limitations, and we cannot easily support multiple instances, or different aircraft. Before anybody adopts/integrates the 747 PFD code, please do get in touch so that we can coordinate the necessary steps. It is not necessarily much work, and not even very difficult - but it may take a few iterations to be sufficiently generic. But anybody who understands basic Nasal OOP, and maybe even Canvas, should be able to work through the necessary steps within 3-4 weekends. We wouldn't be changing any functionality, it would be just about refactoring, generalization and modularization - very much in line with the original ND restructuring efforts. In other words, I'd urge anybody interested in a Canvas-based PFD to get in touch first, and not to use the code directly "as is".
Cquote2.png
Cquote1.png Gijs has started cleaning up the update() method in navdisplay.mfd - once that work is finished, navdisplay.mfd should be down to ~500 lines probably. The ND-specifics should be under 100 lines by then, which means that we can reuse the same code to also port the existing PFD.nas code to use a more flexible approach by coming up with a generic "MFD" class that deals with switches, pages and modes and which merely uses a hash of SVG element IDs and Nasal animation callbacks.


Ultimately, that should allow people to easily provide a customized SVG file and their own animation callbacks.

I am not saying that this approach is "ideal", but it's at least sufficiently generic and flexible without introducing a ton of copy & paste.

The actual integration in ND.nas already is just boilerplate code, and can be easily reduced further by moving identical code to a helper function, which should reduce the whole thing to under 50 lines on the aircraft side.

Regarding the update() method it would be great if some more comments could be added so, in terms of what each conditional should handle, i.e. different modes/settings, so that we can extend the hash instead, to move things there over time.


— Hooray (Wed Jul 09). Re: SVG editing skills needed.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Given the lack of progress in the PFD department, people interested in developing a simple PFD framework should look at Torsten's recent work which is sufficiently generic to support any kind of SVG-based MFD instrument, includinig PFDs and NDs - but also other EICAS/EFIS stuff, e.g. CDUs/EFBs etc.


The relevant aircraft is the ZivkoEdge, and the code is to be found in $FG_ROOT/Aircraft/ZivkoEdge/Models/EFIS (not the most obvious place to look for): $FG_AIRCRAFT/Aircraft/ZivkoEdge/Models/EFIS

As can be seen, Torsten has also started extracting not just EFIS functionality, but also MFD/screen functionality.

For the time being, this must be considered the most mature approach for implementing MFD-functionality in an aircraft, and use-case, agnostic fashion.
So people looking to implement their own MFD-style instruments, should have a look.
Even though it would make sense to obviously move generic code out of the aircraft folder, and specifically support address requirements for a MFD framework and a SVG-based animation framework eventually.


— Hooray (Fri Aug 22). Re: SVG editing skills needed.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png If Torsten's keeps on making this degree of progress, it would probably make sense for "us" (the PFD/ND guys) to look at his code and reuse the generic stuff in the PFD/ND code prototyped by Gijs.


The EFIS.nas file can be found here: $FG_AIRCRAFT/Aircraft/ZivkoEdge/Models/EFIS/EFIS.nas

The other relevant effort is Philosopher's code introduced at: Canvas animations


— Hooray (Fri Aug 22). Re: SVG editing skills needed.
(powered by Instant-Cquotes)
Cquote2.png

Gijs: now that I've most of the 744's EICAS pages done, I started converting the PFD to Canvas. I think I can implement all of its functionality. Right now both PFDs are identical, so there's just a single Canvas. Of course for a complete simulation we'd need independent PFDs. The PFD is mostly done now and so are the EICAS displays. It's a lot of work, but very rewarding and fun to do, since you get to dig knee-deep into all systems and discover things you never knew existed . I've been in contact with James about this, so don't worry, it won't conflict with his plans. The dialog will eventually use the same map. Anyhow, the ND is more than just a map, but for the map part I make use of the map API. Feel free to work on the EFB (don't have that in the 744), but please don't waste any time on the rest of the displays. I already have PFD and ND for the 744 and am making them as generic as possible. They will end up in Instruments/ so we can re-use them on other aircraft. The VSD thing is nice, but it's low on my priority list. There's still lots of basic functionality missing that I'd like to have before 3.0. And then there's also the PFD that needs to be done...

Zakalawe:Gijs' experiment is looking pretty good already - I was able to give him some help with it on IRC. It certainly means we can deprecate the C++ NavDisplay code going forwards. Ideally we might want some alternative spatial queries (to address a sorting problem which also affects the C++ versions), again we discussed this and I can add them relatively easily. I believe Gijs' work on the PFD and EICAS are already in Git - you could adapt the 777 to use them already, and it would improve some features (or simplify the 3D models, and cut down on the textures). Certainly if I get any time to work on the NG (unlikely before 3.0) that's what I will be using.

Hooray:Looking at Gijs' pfd.nas file currently, does the PFD work properly with multiple instances, i.e. captain/copilot ? Just wondering because I haven't looked at how the code is loaded, but just noticed that you are initializing a bunch of global variables at the top of the script, rather than instance-specific member variables, which I would have expected here. With 2-3 helper functions, and using a vector of lookup keys (for the SVG handles, assuming that the member fields can have identical names) and automatically initializing a corresponding member field then, something along the lines of this (in the constructor). regarding multiple PFD/ND/MFD instances, I think that can be easily accomplished by doing what I suggested earlier, i.e. turning your global variables into instance variables (members), as shown above.

Philosopher:I will offer to help restructure code and such. My primary goal would be to clean up class structure, do MVC (I think I understand what that means...), etc. once we agree what module we want to develop. I'll have to take a look at Gijs' design, but map.nas looks like an easy target for me to clean up. I also need to figure out where bootstrapping fits in, because if anything it would be higher priority for me, and it might even help with dependency management here.

Zakalawe:In terms of the EADI I haven't thought about structure at all - if there is a system to use, point me at it. Certainly for the .nas file which drives the PFD & EADI, I would expect it to be 99% the same (just needs to handle missing elements better) - and likely is very similar for all PFD-type displays including Airbus and G1000. I don't think using a single global SVG file is going to work - the problem is this is a totally different technology generation to the 747-400 / 777 / 737-NG displays, so although the symbols are similar, the actual appearance is different. Maybe 'new Boeing' and 'old Boeing' files would work? Since the 737-Classics, 757 and 767 all use this earlier style of EADI. (And similarly the EHSI is a simplified version of the ND). Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself

Maybe you could make a system where symbols can be grouped arbitrarily in SVG files, and layered together? Eg one layer for the speed-tape, one for the altitude-tape, one for the horizon. (Does Inkscape support including a layer from another SVG file?). Since I agree being able to position elements visually is very nice.

Hooray: I mentioned a couple of times that I was hoping to look into it as some point, specifically with the intention to make things as portable and as flexible as the ND framework - i.e. to support at least multiple independent instances per aircraft, but also support different types of aircraft (beyond just Boeing and Airbus). Obviously, this requires a fair deal of generalizing things and getting rid of hard-coded assumptions. The other use-case that the ND code now supports is easily rendering these instruments in GUI dialogs, no matter if these are PUI widgets or "native" Canvas windows. Basically, the idea iss to generalize the ND code some more and come up with helper classes for 1) SGSubsystems, 2) MFD instruments and 3) image generators, 4) displays and display switches/selectors. Introducing a handful of helper classes would allow us to support all important use-cases that are common in modern glass cockpits, including switching between different FMCs or PFDs/NDs.

Hooray:Overall, removing SVG elements to come up with custom SVG files is not such a good idea - the approach taken by the ND module is to have a common/shared SVG file for different types of NDs, with added symbols for different types of aircraft - these are loaded into canvas groups, i.e. can be trivially animated, but also shown/hidden. The long term idea here being to encourage developers to maintain a single SVG file that lives within $FG_ROOT, rather than within $FG_AIRCRAFT - so that we can grow a library of symbols and different "styles" (themes) - for different types of aircraft and glass cockpit systems.

This approach is also favored by Gijs and Hyde.

In general, we really don't want to see a ton of custom files for different aircraft, no matter if this is a ton of Nasal spaghetti code, or custom SVG files - these PFDs are similar enough to be driven by a common generic back-end, using symbols from a single SVG file with different groups/layers. The way the ND code has been reworked, makes it possible to factor out custom stuff into helper hashes, which animate a single element independently - this can be triggered via listeners, timers - or permanently run via polling in a single update() loop.

Generalizing Gijs' PFD code accordingly would probably take 2-3 weekends, integrating and unifying this with the ND "framework" would be another 2-3 weekends. I would really prefer to closely coordinate things here - we really don't want to have people come up with hugely different approaches for different types of MFDs.

TheTom:I'm not sure if it is really a good solution to use a single svg files with all possible PFD elements and combine them (from Nasal?). We could to a collection of elements and copy them together, but there are so many different types of layouts that it will not be possible to cover every possible visualization. Also positioning and resizing the elements is much easier and faster from within InkScape. A common framework in the background (with some common elements like "rotating" numbers, HSI logic, trend vector calculations, etc.) is definitely a good idea.

Hooray:When we came up with the idea of sharing a common SVG file, this was primarily about the Boeing series of airliners (747, 747, 777, 757 etc) - the point being that we want to avoid unnecessary duplication of functionality - if we introduce separation too early, things are likely to be adopted in a "copy & paste" fashion probably - that's in fact how Hyde started adapting Gijs' 747 ND for use in the 777, and neither Gijs or myself were really thrilled about it. As a compromise, I would suggest to maintain manufacturer specifics SVG files instead - i.e. either based on aircraft manufacturers (Boeing/Airbus) or based on EFIS manufacturers like Honeywell. Overall, I would just suggest not to separate things too early - or people are going to end up using lots of "copy & paste" to implement certain features. FG development isn't overly organized - so we basically need to "force" people to generalize things by adopting a corresponding framework that encourages generalization at its core. But I can perfectly understand that the C130J would not be well served by a Boeing or Airbus-based SVG file... so better grow a "library" of symbols for different manufacturers, but ensure that this does NOT live within $FG_AIRCRAFT

Roadmap

Also see http://forum.flightgear.org/viewtopic.php?f=71&t=21840&p=201333#p201333

Design