Phi: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
{{Note|This article is currently in the process of being updated/rewritten by {{Usr|Jaxsin}}}}
[[File:Early-Phi-screen shot.PNG|thumb|right|Early Phi screenshot]]
[[File:Early-Phi-screen shot.PNG|thumb|right|Early Phi screenshot]]



Revision as of 22:02, 21 March 2016

Note  This article is currently in the process of being updated/rewritten by Jaxsin
Early Phi screenshot

Phi - 'map in browser'

Phi is an HTML5/JavaScript/CSS based multi-platform user interface and instructor station. The implementation uses some state-of-the-art JavaScript libraries, most notably jQuery, knockoutjs and requirejs (files included for offline usage). Phi is capable of being run on any device that has a web browser or web app's like Apple's iPad without the browser decorations. See Usage section below for further details.

Background

While working on the new radio/atis implementation, Torsten rediscovered the internal httpd (aka web-server) to browse the property tree. It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal property browser and navigate to the locations after each sim restart. After a while, I got disappointed by the functionality, look, and feel of the http property-browser. So I had a look at the code to see if it could be improved. I quickly realized, that the implementation was simple but not scale-able. I looked for alternatives already available on the GPL market. I found Mongoose as a well maintained, feature rich and yet simple implementation of a web server and started to embed that into FlightGear. [1]

Probably, a video is more descriptive, here is a shot of an earlier (incomplete) version:

You can see a FlightGear instance on the top right of the big monitor and Firefox on the left showing the EFIS. Both run on the same computer. Below the monitor are an old iPod touch (left) and a Nexus 7 (right), both running the EFIS as a web-app in full screen mode connected over WLAN. The EFIS in the FlightGear window is based on Canvas/Nasal. The other EFISes are 100% Nasal free, just HTML/SVG/CSS/JavaScript[2]

FI = Flight Instructor (you sure know that), or FlightGear Interface. In Deutsch (my native language) the spoken FI sounds like the Greek letter Phi. And I like the uppercase letter of Phi for it's symmetry. It's vertical bar reminds me of the projector screen in a simulator, watched from both sides: the trainer and the trainee. For the less philosophical meanings of Phi, check out Phi This is a link to a Wikipedia article and pick the one that suits best ;-) [3]

Usage

Qt5 Launcher

1rightarrow.png See Integrated Qt5 Launcher for the main article about this subject.

To use Phi you need to start the internal httpd server before FlightGear is started. The easiest way to do this is using the built-in Qt5 launcher and add the following line to Settings > Additional options.


Qt5 launcher option for Phi

FFGo

Add the --httpd command switch somewhere in the config file. Please visit FFGo for further details


FFGo launcher

Console

run fgfs with the command line switch --httpd Example.

 fgfs --httpd=8080


Once FlightGear is up and running we can access the Phi user interface from the main menu in FlightGear. Select Equipment > Map (opens in browser) or launch a web browser and enter the URL

 http://localhost:8080

Screen Shots

You can access the new screenshot handler after starting FlightGear per instructions here Usage

 http://localhost:8080/screenshot

It understands some request parameters:

  • type: either png or jpg (guess what this does)
  • window: the name of the window to capture (for those with multi screen setups)
  • stream: provide mjpeg stream

Examples:

Single screenshot

send png instead of jpg (jpg is default)

 http://localhost:8080/screenshot?type=png

send a png screenshot from the window named "WindowA" as defined under rendering/camera-group/window/name in your screen configuration.

 http://localhost:8080/screenshot?type=png&window=WindowA

use default jpg encoding

 http://localhost:8080/screenshot?window=WindowA

Motion-jpeg

Send a motion-jpeg encoded video stream.

 http://localhost:8080/screenshot?window=WindowA&stream=y

Can be used by ffmpeg to directly encode various video formats.

 ffplay -f mjpeg http://localhost:8080/screenshot/stream=y

Compression level for PNG is hardcoded to 9 (highest) and JPEG_QUALITY hardcoded to 80. These seem to be a good balance of performance vs. quality

Web-based EFIS

Cquote1.png I have made some improvement and created a basic JavaScript API.


First victim of my work is the SenecaII.
Pull latest fgdata and run fgfs --aircraft=SenecaII --httpd=8080

Select "Panel in a browser" from the "Seneca" menuentry in the menubar.
A browser should pop up, showing the Airspeed indicator after a short
loading-delay.


— Torsten Dreyer (2014-09-18). Re: [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png for a long time, I have been dreaming of a cross-platform, simple

solution to render 2d panels on a remote device.

I have just succeeded with my first partial implementation of a EFIS PFD
rendered in a web browser using nothing but existing web standards and a
running FlightGear instance having the internal web server enabled.


— Torsten Dreyer (2014-09-17). [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The EFIS is created from scalable vector graphics (svg), is animated by

JavaScript and driven by properties from FlightGear over websockets.
The same svg files that are used for the FlightGear internal canvas
based instruments can also be used for the browser based display, so
both instruments (that of the 3d model and that in your browser) look
100% alike. Websocket properties are exchanged at frame rate making
animations as smooth as they can get. Because it uses SVG, instruments
are always rendered at the highest available resolution of the device
without scaling artefacts.


— Torsten Dreyer (2014-09-17). [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The most exciting part is, the web based instrument runs on any modern

platform without the need to install any spooky software. See a
screenshot of the EFIS rendered on my iPad.
https://www.dropbox.com/s/uo6hu7jeubuy0vn/EFIS.png?dl=0
It also runs flawless on my Android phone and tablet and of course in a
standard browser (Firefox and Chrome tested). On mobile OSes, you can
add it to your home screen, making this a full-screen web-app to get rid
of the browser navigation and toolbar (like shown in the screenshot).

There is not much required on the FlightGear side - recent git has all
it needs. Workload for FlightGear is neglible, for the current EFIS, on
page load a few hundret kilobyte of static files are transmitted and
once fully loaded, 10 (ten!) properties are observed and transmitted on
change. All the rendering takes place on the web browser's device.


— Torsten Dreyer (2014-09-17). [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png If you want to give it a try, make sure you have fg and fgdata from

latest git HEAD.
Clone my ZivkoEdge repository from
git@...:t3r-fg-ac/zivkoedge.git, add the folder to your
--fg-aircraft option, fire up the Edge and pick "EFIS" from the "EDGE"
menu item.

As always: feedback is welcome.


— Torsten Dreyer (2014-09-17). [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png

EFIS via SVG

Cquote1.png I use Inkscape to draw the svgs. The elements to animate are selected by

their id attribute, so you have to set a reasonabl name for those.
To get proper scaling of the svg, you need to set the viewBox, width,
height and preserveAspectRation of the <svg> element.
It should be also possible to draw svg on the fly e.g. from svg.js and
animate this, too. I havn't looked into this so far.

The port number for the httpd is set from the commandline, use whatever
suits your needs. No other ports are involved or hardcoded, everything
runs over http protocol at that port, the websocket included. The
individual services are distinguished by their url (/props/, /json/,
/screenshot/, PropertyListener etc). Again, everything runs over port
8080 (or whatever you told http to bind to).


— Torsten Dreyer (2014-09-22). Re: [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Personally, I like to stick with fgdata as the repo. Master branch is a

good enough playground. During the development cycle things don't
necessarily have to be stable to get checked in there, if they are new
and mostly unused parts and do not get sucked into the running fgfs
instance.
I am planning to move the .js library files out of the aircraft
directory into common fgdata once they seem to be in someway usable.
If you want to contribute to that area, I'm happy to handle merge
requests or appyl diffs.


— Torsten Dreyer (2014-09-22). Re: [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png