Board index FlightGear Development Canvas

Framework-centric aircraft-agnostic avionics development

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Framework-centric aircraft-agnostic avionics development

Postby Hooray » Sat Jun 07, 2014 11:50 pm

Given the recent trend of having several MFD-related efforts without any kind of collaboration/code reuse going on here among our contributors (PFD, ND, Avidyne Entegra R9, EFB), I have started prototyping a generic MFD framework that is purely XML-based, inspired by discussions we've had over the last couple of weeks, and lessons learnt from the missions subsystem.

The whole thing works with building blocks like a screen, buttons, modes, pages, and page elements. It is intended to:
  • support multiple independent instances
  • be totally aircraft agnostic
  • support a pure dialog-driven mode
  • support skinning/theming

It is supposed to support modeling complex avionics like a PFD, ND, EFB, CDU etc - and, eventually, also the Avidyne Entegra R9.

It's currently just a prototype, but it gets away with very little code and we really only need a few more "skins" for common avionics.
I am willing to extend this over time and help maintain it if people can agree to use something like this.

It should be straightforward to allow such "MFDs" to be reloaded from disk at run-time, i.e. for more rapid prototyping.

The following screen shots will probably seem very familiar, but the GPSMap196 instrument shown here was constructed without using any Nasal code, it's just declarative PropertyList XML:

http://wiki.flightgear.org/Canvas_Glass_Cockpit_Efforts
Image
Image
Image
Image

This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Framework-centric aircraft-agnostic avionics development

Postby MechAero » Sat May 29, 2021 12:48 am

Thank you for all your hard work and forethought, Hooray,

I am currently trying to build or find a solution for making glass cockpits for aircraft simulated outside of flight gear, possibly using FGCanvas, FGQCanvas, or another technology/system/library/framework. Starting from scratch would be a last resort. There seem to have been several similar needs and related discussions on the Flight Gear forum for years, and I wonder if your overall position on the best approach has changed at all since this forum's last post: https://forum.flightgear.org/viewtopic.php?p=214980#p214980

I am leaning toward a Canvas solution, and the type of aircraft-agnostic framework described in the current thread is just what I need if provides reusable elements for PFDs, MFDs, NDs, etc. However, the platform-independence of Torsten's approach (http://forum.flightgear.org/viewtopic.php?p=212632#p212632) is attractive, especially since the group I am working with is using Rasberry Pi computers for displays.

Any thoughts or suggestions? Any good discussions or wiki pages I should look at?

Thanks.

(Raspberry Pi is a trademark of the Raspberry Pi Foundation)
Last edited by MechAero on Tue Jun 01, 2021 10:20 pm, edited 1 time in total.
MechAero
 
Posts: 9
Joined: Fri May 28, 2021 11:46 pm
Location: Virginia, United States
Version: 2020.3

Re: Framework-centric aircraft-agnostic avionics development

Postby jsb » Sat May 29, 2021 7:19 am

Just a reminder we already have some frameworks so please make sure you do not re-invent the wheel
https://wiki.flightgear.org/Canvas_EFIS_framework
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Framework-centric aircraft-agnostic avionics development

Postby Hooray » Sat May 29, 2021 9:29 am

I agree
MechAero wrote in Sat May 29, 2021 12:48 am:I am leaning toward a Canvas solution, and the type of aircraft-agnostic framework described in the current thread is just what I need if provides reusable elements for PFDs, MFDs, NDs, etc. However, the platform-independence of Torsten's approach (http://forum.flightgear.org/viewtopic.php?p=212632#p212632) is attractive, especially since the group I am working with is using Rasberry Pi computers for displays.


In general, I tend to agree with jsb - you have done a great job searching the forum and digging out this thread, but most recently, it's really jsb's work that's shaping the way Canvas-based avionics are done. To some extent, the shuttle also has interesting routines.

Anyway, there are some underlying issues when it comes to how the Canvas and the Nasal engine are integrated.
Thus, it might be a good idea to share your requirements/goals with us, so that we can discuss the various pros & cons of different approaches.

For instances, there's FGQCanvas - however, that's basically a port/re-implementation of the Canvas engine in FlightGear, as such it also comes with different pros & cons: it has a much more modern code base, requires Qt5 - but is not entirely portable, in the sense that some native Canvas features are unsupported, or only partially implemented - and others don't work entirely like the real thing in FlightGear.

Then, there's Phi - and basically it would make sense to use a SVG based approach if people want to use their Canvas instruments in conjunction with Phi.
We already have working support to "stream" Canvas avionics (textures) to another process over http - and there have been talks about using a tiny subset of both JavaScript and Nasal to extend our SVG parser so that we can create self-contained SVGs that can be interpreted by both, a browser with JavaScript support and FlightGear via the Canvas and Nasal.

At the end of the day, it really all comes down to your specs and requirements.
Also, it will matter whether you're able to patch&rebuild fgfs or if you'd rather stay in fgdata space.

Personally, I consider jsb to be the maintainer of the Nasal/Canvas side of things these days - then again, he keeps stating that he's unfortunately busy with real life. So there's that, too.

There are other aircraft/efforts that do have interesting Nasal/Canvas code that you could look at - but again, it's best to share your goals and requirements with us first, possibly in a new topic. And then different people can provide their feedback.

For the sake of completeness, if you have a professional background in avionics/aviation - we have working ARINC 661 integration in the sense that we have a way to interface the open source J661 CDS with FlightGear. That, too, could also be better linked with the Canvas system, and Thomas Geymayer (creator of the Canvas system) was once contemplating doing just that. James Turner (leading core developer) has also developed some of his native avionics with a focus on A661.

For the FlightGear project it would obviously be very interesting to extend it so that we can run/display actual A661 DF and use FlightGear as the CDS.
If that's a possible venue for you, that will inevitably require some C++ modifications - but those additions could pay off greatly, because you could basically run a standard avionics development suite and hook up those avionics to FlightGear directly. That is one of the reasons why I developed the integration originally - i.e. you can even hook up FlightGear to an actual FTD or FMS.

Again, this will certainly require some tinkering, but you would be able to reuse existing avionics toolkits and could create avionics without having to do so in Nasal space or Inkscape.

You mentioned RPi style hardware, at which point I would definitely consider Phi - again, SVG/XML can be extened using custom elements - and our parser is implemented in scripting space, so it would be possible to create dedicated elements for things like "compass rose", then implement that using jsb's routines, but run the whole thing through a Nasal2JavaScript translator/subset, so that the same SVG file could be interpreted by Nasal/Canvas, but also by a standalone browser - after all, all that's needed is a way to animate such elements by using properties and running fgcommands. None of that would involve any patching/C++ work.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Framework-centric aircraft-agnostic avionics development

Postby MechAero » Tue Jun 01, 2021 7:19 pm

Thank you, jsb and Hooray.

I was unaware of that framework, jsb. It seems promising.

I want to make sure I understand what all the tools referred to around this forum are. Please tell me if it sounds like I am misunderstanding how they are used from the following hypothetical example: custom SVG files animated using the EFIS framework are rendered using Canvas calls in Nasal, and these Canvas textures are displayed on a panel's 3D model and/or in a browser window using Phi. So Canvas is just the renderer, unless graphics are constructed from SVG paths with Canvas calls.

I guess FGCanvas would be a more FG-native alternative to Phi. What is the status of FGCanvas?

I might open another topic describing my project's requirements as suggested.
MechAero
 
Posts: 9
Joined: Fri May 28, 2021 11:46 pm
Location: Virginia, United States
Version: 2020.3

Re: Framework-centric aircraft-agnostic avionics development

Postby Hooray » Tue Jun 01, 2021 7:30 pm

Yes, that sounds about right:

Nasal relates to FlightGear like JavaScript relates to your browser
The Canvas system is a property driven subsystem in FlightGear to implement render-to-texture support via FBOs
This is done in a hardware accelerated fashion using OpenSceneGraph
The Canvas exposes a handful of native drawing primitives (so called "elements"): text, raster images, OpenVG paths
These elements can be grouped in a hierarchical manner (tree-like) using "groups", which may in turn have their own child elements
SVG files are supported by a custom parser written in Nasal that translates /some/ SVG markup into OpenVG paths
Under the hood, Nasal will set up a property tree hierarchy underneath the /canvas location
There are helpers/wrappers to do some of the more common rendering (think compass rose)
At that point, the texture lives in C++ space - but whenever something changes, it is updated by writing to the property tree (or using an associated Nasal API), which then marks the texture/element "dirty" and updates/redraws it as necessary.

At that point, the texture itself isn't really "visible" - it's just a rendering context that has a matching tree hierarchy in the global property tree - for the texture to be displayed in the simulator, a so called "placement" needs to be added the scene (cockpit, livery, scenery or GUI dialog/window, tooltip etc).

That is why avionics can be easily shown inside cockpits as well as inside GUI dialogs, without duplicating any code.

In addition, there's a feature to stream a canvas texture over http to another process - analogous to the screen shot feature, which basically looks like this:

https://wiki.flightgear.org/Read_canvas_image_by_HTTP
Image


FGQCanvas is an actual thing, but it requires Qt - and it's a re-implementation of the Canvas system, not using the native implementation, and not fully compliant either.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Framework-centric aircraft-agnostic avionics development

Postby MechAero » Wed Jun 02, 2021 3:52 pm

Thank you very much for the clarification, Hooray,

I opened a new topic here: https://forum.flightgear.org/viewtopic.php?f=18&t=39276
MechAero
 
Posts: 9
Joined: Fri May 28, 2021 11:46 pm
Location: Virginia, United States
Version: 2020.3


Return to Canvas

Who is online

Users browsing this forum: No registered users and 4 guests