Board index FlightGear Development New features

FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby Torsten » Mon Sep 22, 2014 8:46 pm

Hi,

during the last couple of weeks, I have developed and now added a new FGPanel implementation to FlightGear.
FGWebPanel or FGPanel 2.0, whatever it will be called, is based on current web standards and runs in any modern web browser and on a wide variety of devices.

Without the need for writing a single line of code you can now create almost any kind of instrument. This is the perfect solution for cockpit builders who want to display great looking instruments on a separate screen. No matter if you need classic steam gauges or want a state of the art PFD. FGWebPanel does them all.

Creation of instruments is a simple and fast progress:
- Start FlightGear with it's internal web server enabled
- Design your instruments in whatever kind of vector graphic design software you like (Inkscape does a great job)
- Create a simple set of text files to define the properties and how they animate the instrument's scalable vector graphics.
- Define the layout of your panel and place the instruments by creating a html page using standard html techniques for the layout
- Load your new html page through FlightGear's internal webserver and enjoy the result.
- If you are not satisfied, correct any errors, hit "Refresh" on your browser and immediately see the result. No need to ever restart FlightGear.

Facts:
* Scales without artefacts from tiny icon sized instruments to giant megapixel retina displays.
* Adds almost no load to your FlightGear.
* Based on web standards and widely adopted JavaScript libraries.
* Cross platform, runs on OSX, Android, iOS, Linux, Windows - on a Raspberry PI, on tablets, smartphones, desktop pc.
* No need for software installation. Just enter a URL into your browser.
* No need to write code.
* No need to write fancy protocol definition files.
* No need to create fancy multi-screen FlightGear installations

With latest git, you can check out a simple example at http://localhost:8080/gui/examples/FGPanel-Sample.html
use
Code: Select all
--httpd=8080
on your command line to start the internal web server of FlightGear.

The code for this PFD style attitude indicator can be found under $FGDATA/webgui/examples/
Image

A little more complex is the work-in-progess 2d panel for the SenecaII:
Image

Use
Code: Select all
--httpd=8080 --aircraft=SenecaII
and select "Seneca->Panel in a browser" from the menu.

Future plans:
- Complete the animation system to support text-, scale-, skew-, matrix-, color- and select animations.
- Implement the animation system in core FlightGear to make the instruments reusable on a FlightGear Canvas.
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 637
Joined: Fri Feb 01, 2008 9:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby Hooray » Tue Sep 23, 2014 5:26 am

This is pretty cool stuff, and some of us have been discussing behind the scenes how to generalize and unify both approaches so that Canvas instruments can be served by mongoose and vice versa.

Some of the early ideas were about serializing an existing Canvas to a SVG and serving that via mongoose - we already have a function that turns a SVG into a Canvas group obviously, and we could also serialize a whole Canvas to SVG using the same method, which would mean that people wanting to do avionics development could develop all their artwork in Inkscape.

For animations, it would make sense to come up with a subset of JavaScript and Nasal which wrappers to hide the differences between the browser and fgfs, i.e. by wrapping props.nas/maketimer and building an animation framework on top of this safe subset. That way, we could allow people to create MFDs/instruments in Inkscape and a restricted subset of JavaScript/Nasal, which would mean that we could collaborate and grow a shared library of instruments that would be useful to both "front-ends".

Like you said, Canvas animations would be ideally augmented through C++ hooks at some point - both, TheTom and Zakalawe have mentioned that they'd like to expose your autopilot/property-list system to allow arbitrary systems to be modeled using those generic building blocks (see their todo lists on the wiki) - which we could then map to osg::Group switches/multi-switches, sequences for handling animations more efficiently, without necesssarily going through Nasal space - basically, the idea is to use an osg::Node visitor that also sub-classes SGPropertyChangeListener to directly animate a scene graph branch using properties.

Currently, switch/mode handling for MFDs is a huge hack in scripting space, even though all of this logic could be expressed using existing AP/SimGear building blocks (especially the state machine stuff created by Zakalawe).

Understandably, all of this is still in a very early state, i.e. just being discussed currently - but it would obviously be great if we could work out a way to better collaborate, because ideally, we'd really become front-end agnostic, so that we can provide the infrastructure that would allow people to create MFDs/instruments using just SVGs and a subset of JavaScript/Nasal. Alternatively, we can dynamically rewrite a subset of Nasal code to turn it into valid JavaScript - e.g. props.nas would be mapped to your ported JavaScript props APIs. I am sufficiently familiar with both, JavaScript and Nasal, and both languages provide support for dynamically compiling program code at run-time - so we could just as well come up with a very limited "instrument animation markup" that is interpreted by roughly ~250 lines of Nasal code, and mapped to JavaScript or Nasal/Canvas animation logic respectively.

I don't think this would necessarily be a lot of work, it's primarily a matter of agreeing that we want to support these use-cases in the mid-term.
Also, serializing an existing Canvas to a SVG could be done by introducing a handful of wrappers for mapping Canvas elements back to valid SVG markup, we can certainly prototype that in scripting space (which is how svg parsing currently works already) - even though some more C++ hooks would definitely be possible.

If we could manage to pull this off, there'd no longer be any disparity between both approaches, and they would be fully compatible - and people interested in either method could help grow the library of instrument. The only thing that we might want to explore sooner or later is serializing a Canvas to a raster image that can be served by mongoose - you already seem to have code serializing screen shots to an osg::Image, so we could use the same method to serve an arbitrary Canvas to a browser, which will be useful for more complex layers that cannot be easily represented using just scripting (no matter if it's JavaScript or Nasal).

For instance, a few months ago we had someone working on exposing FlightGear's view manager to Canvas, which would basically render views to a CanvasImage element (raster image) and update the whole thing dynamically - something like that would only be feasible to support via mongoose/browser by serving some kind of streamed live image, and given the existing screen shot serving code (jpg-httpd) we seem to be halfway there, which would also mean that an instructor console implemented on top of JavaScript/mongoose could show FlightGear scenery streamed via http push.

Regarding the animation logic that you have created for the RBAR EFIS, it would be great to see that moved to a standalone Nasal module so that it can be reused by other aircraft/instruments, without being aircraft specific - your code is much more generic than any existing Nasal/Canvas code we currently have for doing this, and it could help generalize and unify other Canvas-based MFDs.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby Milo » Wed Sep 24, 2014 6:48 pm

Hi,
I use the last Git version onf FGFS, i have enabled htttpd=8080 on FGRun nighly version on (Win8.1) It is under the command line pannel,
I try to run the Panel in browser but i just get the error message that the webserver is not running and that I have to turn on -httpd=8080, notice the one "-".
It is turned on though because i can run the hidden map and the FGPannel-Sample.

Am I done something wrong?
Any one has an idea?

Regards.
GVX0250 _ FGFS v.Git _ Win10_ Asus N76V, RAM8GB, CPU: i7 2.4
Milo
 
Posts: 47
Joined: Sun Feb 06, 2011 11:11 pm
Location: Luxembourg
Callsign: GAX0250
Version: Git
OS: Win8.1

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby Alant » Wed Sep 24, 2014 9:00 pm

From what you have said it seems that all is OK as FGPannel is running. The error message may need investigation. I am sure that you should use --httpd.

Also Torsten has just pushed some patches which may help.

Alan
Alant
 
Posts: 912
Joined: Wed Jun 23, 2010 5:58 am
Location: Portugal
Callsign: Tarnish99
Version: from Git
OS: Windows 10

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby pommesschranke » Sun Oct 05, 2014 11:39 am

I have FG 3.2.0 with --httpd=8080

at http://i3:8080
I get the "FlightGear Help System" Documentation

but those URLs did not work:

http://i3:8080/gui/
http://i3:8080/gui/map/
http://i3:8080/gui/examples/FGPanel-Sample.html

-> 404 Not Found
pommesschranke
 
Posts: 1104
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby Gijs » Sun Oct 05, 2014 11:53 am

It was/is not included in 3.2. You need current Git.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9364
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby pommesschranke » Tue Oct 14, 2014 8:49 am

Gijs wrote in Sun Oct 05, 2014 11:53 am:You need current Git.


...or Saiarcot895's Ubuntu PPL "flightgear-edge" Packages.
http://ppa.launchpad.net/saiarcot895/fl ... dge/ubuntu

the moving map and Seneca's Instrument Panel are both very nice!

http://localhost:8080/aircraft-dir/WebPanel/Panel1.html

thank you very much!
pommesschranke
 
Posts: 1104
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby vaipe » Thu Jan 01, 2015 9:16 am

This is such a great feature! Thank you so much! :D

I was learning how to use this by copying few gauges to another aircraft folder and changing properties addresses and property names in .json files. When I started modifying .svg files layer names and gauges .json, suddenly gauge stopped working. I found out that I had to use Inkscapes own XML Editor to rename layers id to be same as in gauges .json files "element" line. Renaming layer in Inkscapes View Layers tool was not enough. Inkscapes version 0.48 used in Ubuntu 14.04.

-VaiPe
vaipe
 
Posts: 12
Joined: Thu Dec 18, 2014 12:15 pm
Location: Finland
Version: 2017.3.1
OS: Ubuntu 17.10

Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html

Postby tigert » Wed Jul 01, 2015 8:02 pm

I was testing this with an ipad and the SenecaII panel, and looks like I don't get satisfactory update rates. Has anyone been running this with a tablet with smooth frame rates?

FGPanel was smooth but the issue of course is that you need something that can run FG to run it, the web panel is nice, and it is reasonably smooth on my laptop that also runs FG, so building a sim setup with two monitors works, but I wonder if the tablets throttle the updates somehow to conserve battery or something?

Having the panel on any web browser definitely has its advantages, and I hope this is just something we can fix. I will try with just one gauge to see whether it is a problem with transmitting too much data, or is the svg animation just slow on mobile devices?
tigert
 
Posts: 106
Joined: Sat Nov 08, 2014 9:57 am


Return to New features

Who is online

Users browsing this forum: No registered users and 9 guests