Board index FlightGear Support Interfacing

Instructor Station

Connecting two computers, using generic protocol, connecting with Matlab?

Instructor Station

Postby Djmax444 » Sat Dec 27, 2014 9:54 pm

I was thinking of making a instructor station for Flightgear. The only problem is i don't know how to get buttons(from Microsoft Forms) to interface with Flightgear. I am using Microsoft Visual Studio C++ 2010.
Djmax444
 
Posts: 5
Joined: Sat Dec 27, 2014 9:48 pm

Re: Instructor Station

Postby Johan G » Sat Dec 27, 2014 10:58 pm

I have no experience of this myself, but some resources that might be of use are the FlightGear wiki articles Generic protocol, Property Tree/Sockets and Telnet usage.
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: 6625
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: Instructor Station

Postby Hooray » Sun Dec 28, 2014 12:18 am

The pointers Johan has posted are spot-on WRT external interfacing, and we already have more than a dozen of external tools doing exactly this - e.g. see:
Subject: Instructor station for FlightGear (Java project)

Fortunately, these days, you don't need to use any external tools to create an instructor console - you could easily create one using HTTP + JavaScript using the built-in httpd server.
That will be the easiest option for people less familiar with coding, i.e. basic JavaScript + HTML should suffice.

However, for people familiar with C++, Canvas + Nasal is probably a more flexible approach, because the C++ code can be easily extended where necessary.
Obviously, you should first of all be able to build FlightGear from source and be sufficiently familiar with git/gitorious.

Overall, an instructor console/station is a fairly popular request among professional users (or even just private pilost).
So it would be good to have some kind of prototype/proof-of-concept that could be extended over time.

If you're considering the Canvas/Nasal approach, here are a few more pointers:

FlightGear supports scripting via its built-in scripting language (analogous to JavaScript in your Browser): http://wiki.flightgear.org/Nasal
For 2D rendering purposes, FlightGear supports a property-tree based 2D rendering API that sits on top of OpenGL/OSG and ShivaVG: http://wiki.flightgear.org/Canvas
There are object-oriented Nasal bindings for using this 2D API: http://wiki.flightgear.org/Canvas_Nasal_API

An instructor console will typically have the need to show dynamic and interactive maps/charts, for this we have a dedicated mapping/charting framework implemented on top of Nasal/Canvas: http://wiki.flightgear.org/MapStructure

Image

Equally, an instructor console will typically have a need for rendering cockpit instruments, including even complex avionics (MFDs) - this, too, can be easily supported via Canvas:
Image

Note that this is a conventional Canvas texture shown in a legacy GUI (PUI) dialog.
But we can also show native Canvas windows/dialogs instead:
Image

Equally, it is possible to combine modern Canvas features with our legacy GUI:
Image

None of this requires any C++ level coding/patching or rebuilding FG.
However, there are some things where C++/building knowledge will be useful - for instance, the JavaScript/HTML route has serious shortcomings once it comes to using native C++ data structures - equally, Canvas cannot currently do certain things - such as for example rendering custom scenery/aircraft/cockpit views to a texture/camera.

However, Canvas can be easily extended - for once, by exposing new C++ functionality to Nasal (scripting) space: http://wiki.flightgear.org/Nasal/CppBind
But also by extending the Canvas system itself via C++ additions: http://wiki.flightgear.org/Canvas_Development

Speaking from experience, it is better for efforts like these (but also FlightGear), if people can be convinced to use a "native" FlightGear approach, so that FlightGear is extended where necessary, and existing solutions refined over time (no matter if you're using Mongoose (httpd/Javascript) or Nasal/Canvas).

If you're interested in modern C++ coding, Canvas is probably the right place to be for you.

PS: I've started a new wiki article (stub for now) to gather all related discussions/feedback there: http://wiki.flightgear.org/Instructor_Station
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: Instructor Station

Postby Alant » Sun Dec 28, 2014 12:31 am

What kind of instructor station are you thinking of?

Is it a general (ATC, IFR, VFR) procedure trainer or an aircraft specific systems trainer.?

Either way Flightgear can support you. The infrastructure is all there, but the aircraft specific stuff is very variable depending upon the authors.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Instructor Station

Postby Hooray » Sun Dec 28, 2014 12:39 am

To be honest, I think there's much more than just infrastructure - so I see no need to start yet another 3rd party tool only to see it being abandoned a few years from now.
No matter if the OP favors HTML/JavaScript or Nasal/Canvas, everything that's needed is pretty much there already - so it's mainly a matter of integration.
But if the OP is seriously interested in C++ development, I'd suggest to concentrate on Nasal/Canvas and extend the system where needed.

Equally, no matter the focus of the trainer/instructor station (ATC/VFR/IFR etc), it would take much more time to implement functionality in an external tool than it would take using FlightGear itself, simply because FlightGear already has a huge pool of resources, not just in terms of actual infrastructure (think scripting, GUI, 2D rendering, sound, replay, flight recorder etc) but also in terms of artwork (3D models, instruments, textures, sounds etc).

Thus, FlightGear already contains most of the resources and infrastructure that should come in handy when creating an instructor console/station - while an external tool (even using a RAD IDE like VBA) would still need to be written from scratch. Also, FlightGear can already be hooked up to other instances, and even the MP system - and it already supports multiple views and windows. These are all features that would sooner or later come in handy, while being difficult to add later on - so I'd suggest to consider FlightGear a "platform" that can be extended, with certain features merely having to be disabled (e.g. think in terms of fgcanvas)

Getting started with Nasal/Canvas is fairly simple, especially using a bunch of snippets available at: http://wiki.flightgear.org/Canvas_Snippets
And even using existing instruments is pretty straightforward: http://wiki.flightgear.org/Howto:Parsin ... the_Canvas
Image


Outside FlightGear, these are just resources - inside FlightGear they have an actual purpose and logic/functionality, so that using FlightGear makes sense - unless someone wants to rewrite most of the code already available in FG.

And we already have people (Necolatis & galvedro) working on a Canvas-based Failure Management GUI:
Subject: How does serviceable and failures work?

Necolatis wrote:Here is with trigger buttons to install various triggers:
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: Instructor Station

Postby Necolatis » Sun Dec 28, 2014 4:32 am

Yes, if you write the instructor console in nasal/Canvas, the above failure GUI can plug right into it since it is a Canvas widget. If you decide to do that and need help just ask.
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 2232
Joined: Mon Oct 29, 2012 1:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2020.3.19
OS: Windows 10

Re: Instructor Station

Postby Torsten » Sun Dec 28, 2014 3:24 pm

I will push a HTML5 based user interface / instructor station druing the next development cycle.
It will work on any hardware that has a modern web browser. It has support for theming, supports a wide range of screen sizes and resolutions from small mobile devices up to 5k retina displays. It's all based on HTML/CSS3/JavaScript, enriched with powerful 3rd party libraries like jQuery.js and friends, svg.js and friends, leaflet.js et. al.

Curious how it will look like?

There is a toolbar on top with small all-time-visible real-time-update widgets (here: clock, radio settings and a PFD)
There is a horizontal tab-bar for main navigation.
And a vertical tab-bar for navigation within main content.

Example: Display aircraft checklist
Image

Widgets in the toolbar are interactive. Clicking on a frequency in the radiosettings widget opens a dialog to change e.g. frequencies:
Image

It will have all current PUI dialogs implemented, most of them will be rewritten for better usability. The time settings dialog gives full control over the simulators internal time (the one hour offset between digital and analog clock is a bug :-/ ).
Image

And I promised theming, it comes with a set of 24 prebuilt themes from the jQuery UI ThemeRoller which also has a nice interface to create own themes.
Image

All this in your FGDATA git after the feature freeze and packed with the FlightGear release scheduled for Summer 2015!

Anybody with HTML5/jQuery experience willing to contribute is more than welcome!

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: Instructor Station

Postby Hooray » Sun Dec 28, 2014 9:26 pm

In other words, there should really be little -if any- need to re-invent this functionality via some kind of external tool - in general, the mongoose/http approach should be able to satisfy 90% of all use-cases that most people may need, and it is fully integrated and will be maintained over time.

And even if you need access to internal C++ data structures, e.g. for rendering FlightGear cockpit instruments/MFDs or scenery/camera views, extending mongoose to stream an OSG::Camera to the browser, analogous to the existing screen shot server, should be simple enough.

If you need a more integrated solution than a browser-based instructor console, an external tool is unlikely to fit your requirements either way - in which case it would make sense to use Nasal/Canvas instead, and extend the system as desired, which would mean that all the fgdata (base package) resources would not just be "artwork", but actual working components.

Keep in mind that a real instructor console will typically require only a tiny subset of the functionality provided by the actual simulator itself - therefore it is pretty straightforward to consider the simulator itself as the platform for implementing such functionality - the opposite, i.e. turning an instructor console into a flight simulator, would not be possible - btw, this is also the approach taken by X-Plane, which does have the benefit that internal camera views, cockpit instruments, MFDs can be trivially reused -which doesn't apply to 3rd party approaches, including the mongoose/http route - unless you're really just streaming a texture to an embedded flash video viewer, which would either lack interactivity or have round trip/latency issues.

As usual, this is one of those areas where FlightGear development is "just happening" and is unfortunately not very coordinated - so please don't add to the confusion by creating yet another external "FlightGear remote control" - we already have 15+ different GUI launchers implemented in roughly 10 different "programming languages" because people generally don't manage to collaborate properly - there's really no need to repeat the same mistake again.

Bottom line being, if the httpd/mongoose approach can conceivably satisfy all your use-cases, just get involved there - you'll only need to know JavaScript and HTML.
If you need a more native solution, and if you're already able to build FlightGear from source (knowing C++/OSG), you can still consider the Nasal/Canvas approach instead, which is not specific to just a single use-case (instructor console).
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: Instructor Station

Postby Johan G » Mon Dec 29, 2014 2:53 am

@Torsten: That looks very good. :D
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: 6625
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: Instructor Station

Postby Hooray » Mon Dec 29, 2014 5:33 am

Torsten wrote:It will have all current PUI dialogs implemented, most of them will be rewritten for better usability.

Wow, did you literally rewrite those ? If so, that must have been a lot of work - and that would sound like a potential maintenance issue sooner than later (i.e. features/functionality diverging at some point) - we were considering to write a parser for our PropertyList GUI dialogs - which is also the easiest approach to map those PUI dialogs to sane JQuery/JavaScript dialogs without having to manually port/rewrite and maintain those dialogs over the course of the next few years ...
I haven't looked at your mongoose integration recently, so I don't know if you can call Nasal scripts as a CGI there, but the PUI->Canvas translation will be implemented using a simple Nasal parser that transparently converts PUI widgets/dialogs into Canvas widgets/windows. You might want to consider using the same approach to ensure that there's no manual maintenance work required.

We're already overloading print/printf to redirect Nasal output via SG_LOG() - so the same method could be used to let Nasal scripts echo output that should be served by mongoose.
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: Instructor Station

Postby Torsten » Mon Dec 29, 2014 3:28 pm

My goal is to more or less create a complete new run-time user interface for FlightGear in HTML5/CSS/JavaScript.
The current XML/PUI dialogs are of a dying species, so I am not too worried about long term maintenance issues here as they will go away anyway.

I didn't simply convert the existing dialogs to HTML because most of them are not state of the art w.r.t. to design and usability. Actually converting the UI would have been a simple task. What takes a lot of time is to dig through all the embedded Nasal code and understand what is happening there. Over the years, a lot of badly designed code has crept in that should not be part of a user interface.

To answer your questions:

Yes, you can run Nasal through the httpd as it exposes all fg-commands.
However, I'd avoid this whenever possible as this will cause just another level of confusion. If there is a need for changing the state of the simulator, this should be implemented in core c++ as a command so it is accesible from any kind of user interface.

No, I will not use the Nasal SG_LOG wrapper to output messages to the fgfs.log/console. Most browsers have a developer console built in and support console.log() to print runtime information. (And they come with a debuger and other powerful tools, too). I havn't encountered a single use case where I needed to use Nasal from a web page and I don't think I ever will.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: Instructor Station

Postby Hooray » Tue Dec 30, 2014 8:15 am

I do agree that there's an unfortunate amount of custom Nasal code embedded in all kinds of PUI dialogs and that it would be a good thing to get rid of that, or at least standardize on it - i.e. so that a safe subset of Nasal can be used that would also be valid JavaScript.

Sorry for not being clear about it, but the idea was to invoke Nasal as a CGI (=server/fgfs side scripting forwarding output to the browser) - exactly to avoid having to use C++ for trivial additions, so that there's no patching/rebuilding of the binary involved.

I only mentioned the SG_LOG macro because that's one existing way for forwarding Nasal output to a C++ std::stream (see the loglist widget in the existing PUI Nasal Console) - in other words, the same approach could be used to let Nasal write to a std::stream that could be forwarded by mongoose to the client/browser. Which would mean that JavaScript would be running client-side, while it could talk to server/fgfs-side Nasal, or even just invoke certain scripts. Introducing a bunch of new fgcommands/C++ APIs for all conceivable needs would seem pretty tedious and not exactly scalable. So JavaScript satisfies the client-side scripting needs, but server/fgfs-side, there must be a better method than having to use C++ extensions - especially given that a httpd is traditionally all about invoking CGIs and forwarding STDOUT to the client.

Torsten wrote:I havn't encountered a single use case where I needed to use Nasal from a web page and I don't think I ever will.

Well, it depends on what you have in mind I guess - but for example: we could serve dynamically-created SVGs to the client, which could in turn be based on existing instruments.
Equally, we could serve dynamic textures that way. So there's a lot of potential by supporting the CGI use-case, without this necessarily having to be specific to Nasal at all (perl, php etc would just as well work, Nasal just happens to be tightly integrated with fgfs already)
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: Instructor Station

Postby Johan G » Tue Dec 30, 2014 9:27 am

I think that this might be a sign that MVC separation could/should be taken further. What I mean is that the definition of the GUI should not by necessity have to contain low level code for handling updating property values and GUI field values like the current PUI dialogs does.

In essence the framework/API/property-list tags or whatever is used for defining the dialogs should have as little to do with both the data and what is done to it, more or less being a connection point between data and code, albeit with the possibility to show the current values in a way that is easy to interpret and understand and of course also to accept input from the user.

One way to do this could be to have smarter widgets or, even better, some ready made Nasal functions or fgcommands that would handle the low-level stuff. This would be really good for maintenance and if or rather when the next GUI makeover is done. If done smartly it would also help the development of other GUIs, like Torsten's GUI above, as he obviously have had to figure out what all that Nasal code in the PUI dialogs (and related Nasal code outside the dialogs) have been doing and try to re-implement relevant parts of it in ECMAscript. It could quite possibly also make it easier to develop for example smartphone apps that could interface FlightGear to do similar things to what a GUI within does.
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: 6625
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: Instructor Station

Postby Hooray » Tue Dec 30, 2014 9:50 am

It is like he said: The PUI-based GUI, and our PropertyList-GUI files, are pretty archaic - they contain a ton of "workarounds" for doing stuff in a non-standard way, simply because 1) PUI is so extremely basic, 2) things have to work through the property tree (fgcommands are used for dialog creation etc), 3) the Nasal integration in FlightGear is fairly basic and 4) FlightGear is far from being thread-safe and 5) Nasal is not JavaScript - so there are many factors affecting a FlightGear-based GUI running within the main loop, no matter if it contains Nasal or not: even the new Canvas-based GUI will be a affected by a number of these issues - so there are certain benefits when using a completely separate application (aka "browser") with its own asynchronous scripting environment (JavaScript) - but there are also certain restrictions when it comes to accessing certain internal data structures (think live imagery, instruments etc) - because FlightGear as a platform is unavailable to the browser, which means for example that instruments/MFDs need be developed from scratch and cannot be used/shown/updated and animated as easily as within FlightGear (e.g. via PUI and/or the Canvas GUI).

Supporting a completely separate GUI is the way to go for professional purposes, but obviously we cannot easily phase out the default/integrated GUI, for all the use-cases where people need the GUI to be built-in, i.e. don't want to be using a browser for controlling FlightGear - which is always going to be just a fancy "remote control", even if it should show streamed live audio/imagery/video from FlightGear itself, certain things are going to be increasingly difficult.


A completely front-end agnostic GUI markup langauge would need to be supported by PUI, Canvas and mongoose - i.e. this would be quite a challenge without any significant gains - the main problem we're currently facing is that we're establishing diverging means for doing pretty much the same thing: controlling FlightGear, no matter if it's locally (PUI/Canvas) or remotely using a browser - it is very unfortunate when people have to completely port/rewrite existing functionality using a different language/paradigm - and it isn't very future-proof, i.e. we'll be facing a situation similar to the different rendering pipelines we have (native vs. Rembrandt/deferred), scenery engines (default vs. osgEarth), lighting schemes (default vs. Rembrandt vs. ALS), weather systems (basic weather vs. advanced weather) or even just FDMs (JSBSim vs. YASim) - which means that -sooner or later - there'll be a "preferred" (and comparatively better-maintained) solution, while other solutions will be neglected over time, or even just phased out.

Overall the legacy PUI-based GUI predates the modern notion of "MVC" by almost a decade meanwhile, so it is no surprise that the integration leaves a lot to be desired, and the way people tend to stuff Nasal code all over the place is a general problem, not specific to the GUI at all - i.e. can be seen in pretty much most aircraft, but also increasingly in $FG_ROOT/Nasal.

A modern GUI, and even a remote GUI (aka instructor console), is a very desirable thing to have - but as usual, there's very little coordination or collaboration taking place, which means that other efforts are affected by this, e.g. so that certain other efforts are simply going to be incompatible with this development/trend unfortunately, despite this not being necessary at all.
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 Interfacing

Who is online

Users browsing this forum: No registered users and 0 guests