| This article describes content/features that may not yet be available in the latest stable version of FlightGear (2018.3).|
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings:
This feature is scheduled for FlightGear 4.x.
If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.
|Note As of 07/2014, this is being worked on via Initializing Nasal early - there are still some issues that need to be solved first, specifically related to making most subsystems optional and fully runtime-configurable using listeners and "property signals" so that SGSubsystems can be dynamically allocated - see Howto:Reset/re-init Troubleshooting and FlightGear Run Levels for further details.|
if we wanted to build a tablet-based emulator ourselves, we could at least join forces with the FSX and X-Plane communities to do it to grow up the pool of talent.
Should there maybe be a separate project to build an embeddable GPS navigator with different faces/UIs (and a default standalone front end)? As others have mentioned, a lot of the backend logic is the same, like doing a gradual transition from RNAV to Localiser on intercept to avoid a sudden jolt in the A/P, or calculating a turn past a fly-by waypoint. Again, that would be a way to join forces with other Sim dev communities.
|Portability & Compatibility|
note that the whole fgcanvas idea is primarily about taking some sort of existing MFD (e.g. PFD or ND) and render it in a fullscreen view using a dialog, e.g. along the lines of the following screenshot:
At that point, you'd obviously have to be running additional fgfs instances (with unneeded stuff disabled), and key data/properties synced with the main fgfs instance
|If we want to remove an subsystem from the flight gear source code, without leaving any trace of it.. What are the essential steps ?(for example, if the sound update has to be removed, what are steps to be followed).
— Divi (Aug 31st, 2015). Steps for Removing subsystems in flightgear source code.
(powered by Instant-Cquotes)
|i was hoping to build a program outside the FG environment
|I am looking for a simple environment to be able to display canvas elements without starting the whole fg and wait a long long time. Does it exists ? Is there any way to do it, do you have any clue ?
| Creating a 'fgcanvas' client analogous to 'FGPanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.
|So, can I run flightgear on my RPi?
Under what OS are you working on the Pi?
|Note we can't run FG itself without major work, since these platforms only support GLES1 or GLES2, and there's many legacy areas of the renderer which would not work.
|In general, we still have very few Canvas-based instruments. The majority of "glass" instruments are still hard-coded, i.e. implemented in C++ space.
Such instruments are also not supported by fgpanel. FGPanel really only supports classic 2D panels that are built using stacked textures.
Anything more sophisticated than that (e.g. a NavDisplay) will require a hard-coded instrument, or Canvas - both of which are unsupported by fgpanel.
However, we're hoping to eventually absorb fgpanel functionality back into fgfs and come up with a special startup mode for running Canvas-based instruments in a standalone "FGCanvas" window, where the majority of subsystems would simply be disabled: http://wiki.flightgear.org/FGCanvas
This would then also make FGPanel obsolete, because we're hoping to unify the 2D rendering back-end using Canvas, i.e. by implementing a 2D panels parser via Nasa/Canvas.
However, there are still several things that need to happen for this to become feasible - currently, it seems this is at least another 3-4 releases away (i.e. 2+ years).
Obviously, this assumption is based on the manpower currently available, and people interested in helping with this. For the time being, there are 3 core developers working towards this and a number of other contributors willing to help to get this done.
Realistically, we could accomplish many things already - and if someone is interested in pursuing this, we can provide a ton of pointers and also help to varying degrees.
| it would even be possible to use built-in FG dialogs in an external window, running in a standalone process - e.g. for an instructor console, but also for a Canvas-driven TerraGear GUI.
We've been talking about having a FGCanvas mode built right into the fgfs binary at some point, analogous to how FGPanel works - just as an integrated part of the main code base, while not only supporting 2D panels, but also MFD-style cockpits and even GUI elements.
Realistically, it is only feasible to support such use-cases by having a single common backend that knows how to deal with multiple windows, rendering contexts, GPUs or multiple fgfs instances.
Basically, FGCanvas is going to be just FlightGear, in a custom startup mode, to make certain features and subsystems optional, so that the runtime footprint is reduced over a conventional full fgfs instance, and computing resources freed.
While FGPanel is great, it's a separate code base, and as such needs to be maintained separately, it also isn't as flexible - and cannot be scripted or used for glass avionics, it also doesn't support any of the existing hardcoded displays - so it's stricly about 2D panels and static/property-driven transformations.
At the moment, there are a handful systems/features in FG that need to be disabled manually, and others that cannot be disabled at all. Which is why you'll currently either need a fairly powerful computer, or use a workaround.
The hope is to make OpenGC/fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone.
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are:
- flight (FDM, no problem)
- scenery (tile manager: no problem, ephemeris)
- view manager (needs restructuring)
- lighting (needs restructuring)
- terrasync (no problem)
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas). Also see Initializing Nasal early.
| The FlightGear forum has a
subforum related to: Canvas
|Which means that you can run Nasal, but also I/O protocols - because all the FlightGear infrastructure would be -optionally- available.
|The I/O protocol part can be greatly simplified by simply using FlightGear's support for multi-instance slaving, i.e. you'd basically disable the FDM/controls part on the FGCanvas side of things, and simply use those values from the FG side:
|hard-coded instruments like the existing PFD/ND stuff cannot be easily set up to support multi-instance setups.
Aircraft using canvas-based instruments can be more easily prepared to support such use-cases, but may still require a few C++ tweaks.
— Hooray (Sat Apr 05). Re: Displaying Cockpit Instrument display on multiple screen.
(powered by Instant-Cquotes)
|I'd suggest to use our built-in Canvas system in combination with Nasal scripting, we already have a standalone "FGPanel" client that renders instruments in a separate program, for distributed multi-machine master/slave setups: http://wiki.flightgear.org/FGPanel
By using a Nasal/Canvas-based framework, you can also easily reuse existing instruments/textures available in FlightGear (ADF, RMI, HSI etc), including various 2D instruments - it's just a matter of some scripting.
And there's already been talk about eventually also supporting this for canvas-based avionics: http://wiki.flightgear.org/FGCanvas
Note that FGPanel is fairly limited feature-wise, it doesn't support any of the hard-coded displays (TCAS, AGRADAR, WXRADAR, NavDisplay) or other owner-drawn gauges, it's stricly for static textures animated through properties.
|Ultimately, the best solution would probably be to have Canvas/ FGpanel running natively in ARM architectures so that they can be used in Android Tablets. I have my doubts regarding the addition of screens to Raspberry PI, Blackbone, Panda, etc. A 10.1" HDMI screen costs around UDS 145 (http://www.adafruit.com/products/1287), which is almost the same price as a cheap tablet. On the other hand, the Raspberry PIs are the best for hacking the hardware needed to make instruments. Here is some paralell work I am doing with my Raspberry PI:
— saul (Thu Jul 31). Re: Flightgear Android Primary Flight Displays for Airliners.
(powered by Instant-Cquotes)
|you should be aware of glass cockpit related efforts, especially Canvas - most airliners & jets will sooner or later benefit from being ported to Canvas, e.g. to use Gijs' NavDisplay framework, or at least Philosopher's MapStructure framework for mapping purposes.
Thus, if this is also about the actual display itself, people should be aware of related canvas efforts, especially FGCanvas: http://wiki.flightgear.org/FGCanvas
I am involved in both, the NavDisplay and MapStructure efforts, and my mid-term plan involves supporting a standalone mode for all Canvas-based glass instruments, including the ND, but also other instruments like the PFD, EICAS, CDU or EFB. This may sound like a lot of work, but it's mainlyy a matter of introducing a a few helper classes and ensuring that people actually adopt and use those.
In the long-term, I really want to support distributed FlightGear setups like those at FSWeekend/LinuxTag, where multiple computers may be used to run a single simulator session - including properly synchronized glass instruments like the PFD/ND etc. This would also help improve the multiplayer experience, especially dual-pilot setups etc.
|There's also the long-term plan to eventually port FGPanel back into FG and come up with some sort of "FGCanvas" mode, where Canvas-based displays could be run in a separate "standalone" mode and interface to the main/master FG instance.
I don't think that the Canvas system currently builds against just OpenGL ES - but it should be possible to identify problematic use-cases and make the Canvas support OpenGL ES by setting some OSG traits accordingly - at some point, i.e. 12+ months from now
In general, it pays off to unify things - otherwise, there's lots of duplication and re-invention involved.
Technically, we could definitely run an OpenGL ES-based Canvas on a mobile device, we just need people interested in pursuing this and playing with it - as well as report any issues/showstoppers
Such an integrated solution would also make it possible to show any canvas texture (instrument, dialog/window, MFD etc) on external devices:
| it would make sense to coordinate such efforts, because the requirements will be very similar.
Even some core developers discussed this on the devel list: http://wiki.flightgear.org/Howto:Optimi ... .2F2013.29
For example, see: http://wiki.flightgear.org/Howto:Optimi ... le_devices
The Canvas is a property tree-based subsystem using listeners, the canvas is primarily a wrapper on top of Shiva and OSG that is invoked via listeners.
So all the OpenGL code is either located in Shiva or in OSG - OSG can be told to use OpenGL ES.
So it would be a matter of experimenting with it.
For this particular project, I would suggest to extract the Canvas into a standalone executable - something like this has been previously done by TorstenD when he came up with FGPanel, he "just" extracted FlightGear's 2D panel code and turned it into a standalone binary.
This alone would help us ensure that we can optimize the canvas to support OpenGL ES - once that is working, you could cross-compile the standalone canvas binary.
Technically, this will involve some -but not all- of the steps outlined at: http://wiki.flightgear.org/FGCanvas
(not all of them, because FGCanvas is eventually intended to be merged back into the main code base)
|I have this cray idea floating around in the back of my head for quite some time. As a long time RC airplane enthusiast, wouldn't it be cool to embed a small display + raspberry pi in the cockpit of a scale model airplane? Wouldn't it be cool if your model airplane had a live, working cockpit display? If you are wondering where I'd get the data to drive the cockpit display, that would come out of the UAV side of my life. The sensor I/O and fusion is already solved. http://gallinazo.flightgear.org/uas/flight-milestones/
— Curtis Olson (Jan 10th, 2016). Re: [Flightgear-devel] FGPanel on the Raspberry Pi.
(powered by Instant-Cquotes)
|Using the Pi as an avionics platform has been on my todo list for a while - I've had a box full of parts just waiting. A 7" HDMI display with a touch screen overlay for it.
— geneb (Jan 10th, 2016). Re: [Flightgear-devel] FGPanel on the Raspberry Pi.
(powered by Instant-Cquotes)
|I'll get a Raspberry Pi soon, so I will probably try to also run the canvas there
|I've just seen that the Raspberry Pi has hardware accelerated OpenVG support, so we won't need ShivaVG and the path rendering should be quite efficient.
|Right, not only is OpenVG natively supported in hardware, but there's even a vector font library available named "vgfont".
This OSG discussion may also be of interest for anybody pursuing this venture: http://forum.openscenegraph.org/viewtop ... &view=next
And specifically: https://code.google.com/p/osgrpi/
FGCanvas (standalone canvas rendering analogous to fgpanel)
Objective: Brainstorming of all ideas related to fgpanel-related (standalone) functionality for the new Canvas subsystem
- Torsten: "fgpanel is the 2d-panel code from flightgear wrapped into a simple standalone application being able to display 2d instruments on very simple hardware with basic OpenGL support. Find the sources dropped here: https://gitorious.org/flightgear-pmpt/panel?p=flightgear-pmpt:panel.git;a=summary " 
- James: " I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people)" 
- Hooray: "the standalone 2D panel is actually a great idea, and if this could be improved on, this could make other solutions (like openGC) obsolete. I think that's important because there are so many similar projects. maybe there is a way to use FG itself in a special "mode" for just rendering 2D instruments, getting the properties for each instrument from a master fgfs instance.Such a new "instrument only"-mode could then run with most subsystems disabled (like i.e. sound, fdm, weather, scenery, terrain etc) and only render FG XML instruments. The corresponding properties could then be retrieved from the fgfs main instance, probably using a custom protocol. So I really like the idea of having a standalone mode, but I am not sure if it should be a completely separate code base (sounds like maintenance hell to me actually). Instead, it would probably make sense to make some more subsystems optional so that they can be disabled on demand, then the same fgfs binary could be used for starting up in an "instrument only" mode that only renders 2D instruments with properties being read from a master instance." 
- James: "That's more or less exactly what it will be - and yes, it will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. " 
- Hooray: "At some point looking again into cigi might actually be interesting to handle fgfs<->fgpanel communications, as you may remember, cigi was first brought up some time ago in the DIS/HLA thread and would seem like a perfect match in this context, it's all open source (GPL in fact) and an established standard used by many major players in the aviation industry:" 
- James: "Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend." 
- Hooray: "Regarding Torsten's fgpanel work, it would be good to eventually generalize this in such a fashion, that "canvas" instruments could also be rendered standalone at some point."
- Hooray: "Unfortunately, there are many hard coded assumptions in the code currently. The code OFTEN assumes that there's a an aircraft, FDM scenery, sound etc. Basically, all the stuff that won't be needed by a standalone FGCanvas/FGPanel. And the next funny thing is that all the Nasal code in $FG_ROOT/Nasal is also making lots of these implicit design assumptions (such as geodinfo() calls (depending on scenery/tile mgr) etc). Basically, this means that there will be lots of refactoring involved for a standalone canvas client, not just C++ code, but also Nasal code."
- TheTom: "Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas..."
Some more ideas have been collected here: SGModule - standalone SGSubsystems.
Property Synchronization between fgfs and fgcanvas
I think even just preparing the SimGear code for this would make sense, the canvas system would have a simple and elegant solution for "aliased" properties with listeners - i.e. where properties may be looked up using different criteria (by-index, by-name).
And for the whole FGPanel/FGCanvas idea, this will definitely be useful - because it's all about allowing two property trees to communicate with each other.
In other words, if we had an option to link properties and "mount" them in some custom location, then it would also be easy to handle the FGCanvas idea such that it always writes to the local fgfs property tree, which is transparently forwarded to the right end point, i.e. the standalone FGCanvas instance.
Currently, in FGPanel, this is handled separately and there's no elegant design or solution at all. The network protocol must be separately set up using an XML/IO protocol file, which duplicates properties from the main instance to the "slave" instance, i.e. explicit networking I/O.
Now if we had a feature to supporting "linking" or mounting, then this could later on be extended such that custom "transport" channels can be added, i.e. IPC via sockets (e.g. some simple form of reliable UDP using the multiplayer code in FG for the basic property primitives like int, float, double, string)- for FGCanvas that would mean, that all Nasal modules would only ever write to their local property tree instance, and that they don't need to be aware of the differences or the transport technique used.
I think the Nasal code could be really kept simple like this, because there would never be a different between a "local" or a "remote" FGCanvas instrument - so no explicit maintenance required.
Probably, the existing aliasing code could be extended to support this: https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/props/props.cxx#l774
Would something like this work for your C130J EICAS or MCDU work, I mean such that all the communications details are handled transparently by a network-enabled property tree with "link/mount" support, so that it would be trivial to run an instrument separately, in a different process - on a different computer, just by writing to a mounted remote property tree?
Referring to Remote Properties and the mentioned "mounting" support:
For displaying one would just need to mount the canvas branch inside the remote EICAS FlightGear instance. If also interaction back to the main FG instance is needed it would also be needed to write to a remote tree. This can be handled the same if remote mounting also supports writing in all directions. So, yes with fill mounting support this would be possible
One would just have to decide on which instance of FG the calculations of the ECIAS and other displays should take place, but with full mounting support this should be easily distributable as computing power is available.
Yes, that's true ... on the other hand, even if we should be able to run the Canvas system standalone via FGCanvas one day, it would still just be a "display" - i.e. full scripting support would be in a different league, because it would require an embedded Nasal interpreter. So many scripted calculations would initially take place in the main fgfs process, and FGCanvas would "just" display the results via some form of mounted "remote property tree", so that the main fgfs process just writes to a certain location which is transparenly sync'ed/mirrored to another "slave" fgfs process, where the canvas would be rendered.
You are right that the computing power would be available - but obviously there's a certain overhead, i.e. for property replication, so this would require some form of "ratio metric" - i.e. average amount of properties synced per second, vs. time spent drawing/updating the display. So that we can know if we are limited by the throughput or by the computing power
By default, I would expect that the various canvas Nasal wrappers just write to the main fgfs property tree directly, which is then transparently forwarded to another process - so everything in scripting space, would still be calculated in the fgfs main loop, while all canvas-related computations triggered via listeners, would then be "distributed", i.e. run in the "delegate" process - because that's where the callbacks would be invoked.
A while ago, I played around with showing canvas instruments in a slaved fgfs instance - and it actually worked pretty well just by using the existing telnet interface, the subscribe command and 20 lines of Nasal to fix up property path index numbers, while the telnet protocol isn't very fast - it was sufficient to show the airport selection map in a slave instance, as a cockpit texture - without any C++ changes. We once had a long discussion about necessary changes to "mount" remote property trees in a local property tree to replicate state - but the experiment showed that even a crude synchronization mechanism like the props protocol works well-enough for a single instrument.
In summary, we really need to make sure that whatever form of caching/optimizations are introduced, that they can work in master/slave setups, and that is automatically the case as long as the property tree is the sole storage and transport mechanism, so if there is some form of cache, it needs to be local and transparent to the property tree - so that slaved instances get their chance to update their local cache, rather than cross-referencing cached items in multiple interlinked instances.
While it may not seem important right now, because most other simulator features are similarly broken or "crippled", the canvas system is the most feasible chance to address these once and for all.