Board index FlightGear Support Hardware

DIY simulator with full cockpit hardware

Joysticks, pedals, monitors.

DIY simulator with full cockpit hardware

Postby thepete » Mon Jun 21, 2021 8:27 am

Hi everyone and hello to the forum as this is my first post here ...

Currently, I'm planning to build a open source/open hardware fixed base flight simulator by modelling a complete, modern C172 (glass, FG1000) cockpit. There are many options for flight simulators to be used as a basis but I want to go with FlightGear first, as this seems to be the only reasonable open source solutions.

Anyway - Background: I'm a software engineer with solid embedded hardware skills so I neither fear custom electronics development nor advanced software development in any way. And of course the project will be released under an open source or open hardware license where appropriate.

After doing some initial reading on FlightGear, I came across some potential obstacles, where I would appreciate if you could point me into the right direction.

First let me give the overall intended simulator architecture:

Simple Visual System:
* 3x 55" 4K monitors in 60° angle to replicate a 180° sphere.
* some appropriate PC with a capable graphics card (details not really relevant right now)

Intended Cockpit Hardware:
* DIY remaining round instruments using stepper motors and RC servos, each controlled by an individual uC. Communication with FG will be either over Ethernet, CAN or simply RS485 so it can be completely modular. Maybe a system in between to aggregate all the input streams.
* Switches, throttle etc. will be built in the same, modular way.
* Potentially DIY force feedback yoke / pedals but we will see ... this is a complex subject on its own.

The aforementioned parts are pretty clear (great doc and examples!) how to interface them to the main FG computer.
However, the real problems seem to start arising when considering the FG1000 PFD and MFD.

How would I build these? In my ideal world, I would love to run them on a dedicated SBC (e.g. Raspberry pi, or Raspberry CM3+ or the like) having its own 10" display with a replicated bezel with all the knobs and rotary encoders connected. That would then just require a single ethernet connection to the main computer running FG.

Is that possible (of course it is - but I mean with reasonable effort) with FG's architecture right now? Can you point me into a useful direction?

@Moderator: It that is the wrong sub-forum, please feel free to move this post.
thepete
 
Posts: 6
Joined: Mon Jun 21, 2021 7:50 am

Re: DIY simulator with full cockpit hardware

Postby Johan G » Mon Jun 21, 2021 9:09 am

thepete wrote in Mon Jun 21, 2021 8:27 am:The aforementioned parts are pretty clear (great doc and examples!) how to interface them to the main FG computer.

At least sometimes there FlightGear have great documentation. :wink:

thepete wrote in Mon Jun 21, 2021 8:27 am:[...] the real problems seem to start arising when considering the FG1000 PFD and MFD.

How would I build these? In my ideal world, I would love to run them on a dedicated SBC (e.g. Raspberry pi, or Raspberry CM3+ or the like) having its own 10" display with a replicated bezel with all the knobs and rotary encoders connected. That would then just require a single ethernet connection to the main computer running FG.

While not having experience with it, running Canvas on separate hardware would likely be a good choice if it could be done. There seem to be a Qt based software able to run Canvas remotely, FGQCanvas, but I am unsure of its development status. If that would work well that could be a good approach, even if there would be some bugs to iron out.

Another approach could possibly be to try extend the web based EFIS of Phi. It seems that most of what would be needed is there, but it likely would require reimplementing most of the GUI.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: DIY simulator with full cockpit hardware

Postby thepete » Tue Jun 22, 2021 8:34 am

Thanks for this elaborate answer. Checking the forum and doing a bit of research it seams that the FG1000 would only work partially with FGQCanvas. Generally it seems a bit hacky to me. It is further unclear how I could remotely control the FG1000 (as in forwarding button interaction).

Thus, I will probably go down the web based EFIS route but start off with a much simpler display device (e.g. EFIS D100). For the map, I can simulate a separate simpler device (e.g. FlymapL) on a separate machine.

Thus, the two devices would be simulated entirely on independent Raspberry PIs and only get aircraft data from FlightGear. I can have GPIO-Buttons with key-binding to locally control the view of the display devices.

Any objections?
thepete
 
Posts: 6
Joined: Mon Jun 21, 2021 7:50 am

Re: DIY simulator with full cockpit hardware

Postby Hooray » Tue Jun 22, 2021 8:47 pm

Hi & welcome !

thepete wrote in Mon Jun 21, 2021 8:27 am:However, the real problems seem to start arising when considering the FG1000 PFD and MFD.

How would I build these? In my ideal world, I would love to run them on a dedicated SBC (e.g. Raspberry pi, or Raspberry CM3+ or the like) having its own 10" display with a replicated bezel with all the knobs and rotary encoders connected. That would then just require a single ethernet connection to the main computer running FG.

Is that possible (of course it is - but I mean with reasonable effort) with FG's architecture right now? Can you point me into a useful direction?
[...]
Generally it seems a bit hacky to me. It is further unclear how I could remotely control the FG1000 (as in forwarding button interaction).

Thus, I will probably go down the web based EFIS route but start off with a much simpler display device (e.g. EFIS D100). For the map, I can simulate a separate simpler device (e.g. FlymapL) on a separate machine.

Thus, the two devices would be simulated entirely on independent Raspberry PIs and only get aircraft data from FlightGear. I can have GPIO-Buttons with key-binding to locally control the view of the display devices.



Given that you have a software engineering background, you can probably have your cake and eat it too - i.e. as long as you're able to use git/cmake to patch/rebuild FlightGear from source and as long as you don't mind #ifdef'ing out some stuff/subsystems.

Regarding the FG1000 in particular, there's no problem triggering its buttons/events, since it's using an MPI-like interface called "Emesary" (wiki) - these can be wrapped in fgcommands (bindings) - and that way you can trigger bindings using arbitrary front-ends (for instance, the cockpit, GUI dialogs, http/browser, telnet etc).

For the visuals, you could then use a stripped down version of FlightGear, i.e. by building only a subset of FlightGear - there's currently related work going on (devel list), but in the meantime it will suffice to disable subsystems that you don't need on the IGs (image generators).

For instance, you probably won't need the FDM, sound, AI, autopilot, route manager subsystems - these can be explicitly disabled.
It would then be up to you to either run a subset of the corresponding FG1000 on the IG machine(s), or alternatively replicate the Canvas RTT/FBO explicitly by using a networking mechanism (a relatively new option is DDS: https://wiki.flightgear.org/Data_Distri ... es_support )

The background here being that FlightGear avionics are scripted using a built-in scripting language called "Nasal" (analogous to JavaScript in a browser), then there''s the property tree, and a dedicated "listener" API which is used to implement full APIs/subsystems on top of this stack consisting of 1) scripting and 2) properties.

There are high level wrappers for setting up an invisible rendering context on the GPU (called an FBO/RTT), and that texture can be addressed via the global property tree.
In that tree, your texture gets its own location/subtree - and this is where dedicated rendering primitives can be added using a recursive hierarchy.
These primitives are called "elements" - e.g. to add vector graphics (using OpenVG), raster images, or text/fonts

Under the hood, the C++ engine will create a full scene graph representation - thus, the initial setup is somewhat costly (it's mostly scripting after all), but once everything is set up, it's pretty fast, because most stuff is handled in native code.

Let us know if you have any follow-up questions - I would not mind going into more details if you'd be willing to document your journey by using the wiki, ideally in conjunction with setting up a public git repo so that we can track your progress.

Regarding fgqcanvas in particular, it's unfortunately right that it's a complete re-implementation of the Canvas system (using Qt5), and as such it is not fully compatible with the Canvas system and the FG1000 in particular - in fact, the FG1000 developer happens to be a core developer too and has been pointing out a number of issue over the years, for example see: https://sourceforge.net/p/flightgear/codetickets/2366/




PS: Given your background, I'd REALLY suggest to check out this topic (and possibly reach out to the user too): Standalone EFIS, Autopilot, and Synoptic Framework
(in other words, if the two of you could find a way to team up, you'll stand a pretty good chance of succeeding at this - and you might have a few more mentors too) :D
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: DIY simulator with full cockpit hardware

Postby thepete » Tue Jun 22, 2021 11:36 pm

Oh wow, a ton of stuff to digest :-) This seems to be quite some rabbit hole I let myself into.

Anyway, just to make sure I unterstand the approach. So what you basically suggest as one option is to strip down FlightGear (by compile time config and/or #ifdef code exclusion) to just be able to interpret Nasal code (and other infrastructure) to sufficient render an instrument panel (with one instrument only) locally on a low-power IG machine (e.g. Raspberry Pi). Basically degrade FlightGear into an instrument simulator.

The rest of this project would then need to ensure a fast enough data binding between the two machines to keep everything in sync.
If I understand correctly, parts of this synchronisation (maybe even all of it?) seems to be already available through property tree distribution: https://wiki.flightgear.org/Howto:Multi ... FlightGear

Thank you very much for this input and I'm reaching out for collaboration.
Sure, if the initial experiments turn out to be promising, I'll setup a public git repo.

I think I need to start coding ...
thepete
 
Posts: 6
Joined: Mon Jun 21, 2021 7:50 am

Re: DIY simulator with full cockpit hardware

Postby Hooray » Wed Jun 23, 2021 5:18 pm

So what you basically suggest as one option is to strip down FlightGear (by compile time config and/or #ifdef code exclusion) to just be able to interpret Nasal code (and other infrastructure) to sufficient render an instrument panel (with one instrument only) locally on a low-power IG machine (e.g. Raspberry Pi). Basically degrade FlightGear into an instrument simulator.


right, that's basically correct: that is how "fgpanel" came to be, too (just specific to legacy/steam instrumentation only and pre-dating the canvas era). With FGQCanvas being a re-implementation of the fgpanel idea, with a focus on replicating Canvas avionics remotely using a separate/standalone binary. However, FGQCanvas comes with its own pros & cons (it being a re-implementation of the canvas system itself, and it using Qt5 under the hood). As you have pointed out already, there are some compatibility issues when it comes to FGQCanvas and more sophisticated avionics (like the FG1000).

We already have support to interlink multiple fgfs instances to create a single simulator environment - for that purpose, fgfs can be told to disable a number of built-in subsystems and use a so called "master/slave" setup, where multiple "slaves" receive state from a master node (think flight dynamics).

In other words, you would only need those bits of FlightGear required to render instruments and sync/replicate state between multiple instances (which exists already!)

Some subsystems can already be toggled on/off during startup (or even dynamically), others not yet - and it's those that you'd need to explicitly disable using either feature toggles and/or #ifdef blocks in conjunction with dedicated cmake build options. That's the trivial part actually, and it's well documented in the wiki.
The less trivial part is figuring out conflicts due to implicit/hard-coded assumptions in existing subsystems - because some subsystems may assume that stuff like "ai traffic", "autopilot" or "route manager" is always available - which basically means a null pointer access at run-time, if you don't grep through the sources to identify such hard-coded assumptions.

Other than that, when it comes to the Canvas, you don't even need Nasal necessarily - because under the hood the setup is relatively basic:

1) Nasal scripting is used to assemble/compile a property tree structure under /canvas
2) there's a dedicated Canvas subsystem that processes write accesses to /canvas
3) internally, this will set up a scene graph structure using a handful of rendering primitives
4) finally, there's an offscreen rendering context created/updated (animated)

Thus, to replicate a Canvas TEXTURE, all you need is to replicate the local property tree structure of a certain /canvas/by-index/texture[0] - and forward the corresponding updates to the other slave/child instance to a matching node underneath the remote /canvas tree.

At that point, the remote fgfs instance will happily replicate the texture remotely, without requiring Nasal - Nasal would only be running on the master/parent instance in that scenario to set up/assemble and update the canvas texture(s)
You would then use an IPC mechanism (a number of which are built-in/supported "as is") to forward local updates to the remote fgfs instance.
And that remote fgfs instance would then be running a lightweight version of FlightGear, or a stripped-down "runtime mode" (let's call it "canvas display server" for now).

Over the years, we have seen the recurring idea to introduce dedicated support for different "startup modes": https://wiki.flightgear.org/Startup_Modes

the rest of this project would then need to ensure a fast enough data binding between the two machines to keep everything in sync.
If I understand correctly, parts of this synchronisation (maybe even all of it?) seems to be already available through property tree distribution


The most relevant/up to date work in that area is Erik's DDS work actually (previously linked to above): https://wiki.flightgear.org/Data_Distri ... es_support
However, we have also previously succeeded replicating/synchronizing canvas trees (textures) by using the existing props/telnet and http protocols - but those are not binary, so unnecessarily verbose and not very performance friendly.

To learn more about the number/name of FlightGear subsystems, use the built-in performance monitor:
https://wiki.flightgear.org/Howto:Use_t ... em_monitor
Image

To learn more about FlightGear's subsystem architecture, see: https://wiki.flightgear.org/Howto:Create_new_subsystems

How to optionally disable FlightGear subsystems is illustrated here:

https://wiki.flightgear.org/Howto:Disab ... l_entirely

Edward (bugman on the forum) has been doing a bunch of work related to this: https://wiki.flightgear.org/Howto:Make_ ... s_optional
More recently, Scott (xDraconian on the forum) has been working on commenting out legacy code in order to work towards OpenGL Core Profile migration, and he mentioned separately that he's considering introducing support for dedicated "feature toggles" (basically so that SGSubsystems can be individually disabled via properties and/or startup flags): https://wiki.flightgear.org/OpenGL#Status

Some of us have previously suceeded at using this approach to manually disable stuff for more constrained systems (and some folks even toyed with the idea of implementing "run levels" for FlightGear to make its initialization less monolithic).

The following screen shot shows a heavily patched/stripped down version of FlightGear where numerous subsystems are removed/disabled, and others are added to a dedicated subsystem group:

https://wiki.flightgear.org/Reset_%26_re-init
Image

Again, depending on what you have in mind, you might also want to consider posting to the FlightGear developers mailing list.

Also, if latency/throughput is an issue (think in a multiplayer environment), it would actually be preferable not to replicate the Canvas PFD/MFD at the primitives level (canvas tree/elements), or the texture level (streaming texture updates). Instead, you could also use a customized fgfs binary to run a slaved/child fgfs instance that merely processes the same inputs (brezel) - that way, you would be running the MFD/PFD code on each slaved/child instance - and while these would be independent instances running the whole thing, these would be using a common input layer. That, too, can be accomplished by using Nasal/Emesary - and it would not require much C++ work (if any). However, the setup would obviously be a bit heavier performance-wise, because you're -unnecessarily- running the same code on multiple machines, even though you really only need the visuals (texture). But for an MP environment, that would still be a pretty good setup, since the amount of traffic/bandwidth required, would be marginal at best - whereas the tree-level replication of a MFD/PFD via canvas primitives, is going to cause hundreds of "updates" in the form of property GET/SET instructions. But again, a binary protocol (or DDS based), should make this still pretty appealing.

In the meantime, it would be great if you could reach out to the OP in the other topic, and maybe discuss if/how the two of you might collaborate here - especially since you seem to have overlapping requirements, and apparently you're bringing useful skills to the table, too :wink:

PS: As long as you're willing to document/share your journey with the community by using the wiki/forum and a public git repo, I would also be willing to answer related questions directly (via PM), since I have previously done something very similar (as you can see by looking at those screen shots). But again, if Qt5 works for you, then you don't have to do any work at all - and in fact, another option might be fixing up/extending the Qt5 port of the Canvas. If in doubt, please talk to the other user interested in working on this, and then we can take it from there.
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


Return to Hardware

Who is online

Users browsing this forum: No registered users and 1 guest