Board index FlightGear Development

Virtual Panel/Control from Web Browser

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Re: Virtual Panel/Control from Web Browser

Postby Kabuki » Tue Dec 17, 2013 7:46 pm

Raptor831 wrote in Mon Dec 16, 2013 3:18 pm:
It theory, it would remove the same origin problem because if I run MAMP/WAMP, I can place the script that calls over to FG and the actual display (what page the browser is at) in the same folder. I was planing on AJAXing the script page, having the script receive the most recent set of data, and then the script would return/echo the JSON or whatever back to the display page. All of this would be on the same server, probably running on the remote computer.


No, it doesn't matter which folder you're using. You are using two different *servers*. Using "WAMP..." doesn't mean anything special. An Apache server, and the flightgear httpd server. Different servers.

You can work around this by using "fopen-URL" functions in PHP and treat the httpd's output like a file, parse it, and send JSON to your page via request. But I found that it was slow, and there were timing issues. That's when I looked for, and found a way to disable the 'same origin' policy, which meant that I could do away with the extra server and PHP completely, and simply navigate to the page as a file, rather than have to serve it via Apache. MUCH more efficient.

However, for something like live instruments, http probably isn't the way to go, and I'm looking at websockets now.

The thing I don't want to do is have to run a filtering middleman server to enable it to work. Must. Keep. Simple.
This is a family-friendly saloon. No talk stink.
Kabuki
 
Posts: 587
Joined: Fri Oct 23, 2009 11:21 pm
Location: Usually on the ground, always in the sky, except when underwater.
Callsign: Kabuki
Version: 3.0.0
OS: Windows 7

Re: Virtual Panel/Control from Web Browser

Postby Raptor831 » Tue Dec 17, 2013 11:45 pm

Kabuki wrote in Tue Dec 17, 2013 7:46 pm:No, it doesn't matter which folder you're using. You are using two different *servers*. Using "WAMP..." doesn't mean anything special. An Apache server, and the flightgear httpd server. Different servers.


True, I still have to run both the local server and some kind of FG server. The trick is though if I'm not AJAXing to FG's server, but the one that contains both the display file and the script/middleman then browsers won't throw the 'same-origin' error. The trick is that the script has to connect to FG in some way. Currently there's no way around the middleman unless I'm content with just AJAXing switch calls in and parsing the returning HTML for the <input>'s value attribute, which seems absurdly complicated for what amounts to a "get" call.

PHP wasn't cutting it for me, as I could not for the life of me get a connection from FG. But I'm using Python now, and I think I can read/write data via the telnet server (which should be fast enough for switches and basic steam gauges), and then present a basic http server from which I can serve both the view HTML page and the fake "response" page (which nullifies the 'same-origin' issue).

Kabuki wrote in Tue Dec 17, 2013 7:46 pm:Must. Keep. Simple.


Agreed! :wink: Which is why I'll be trying to get the needed code so Nasal can make WebSockets/AJAX/JSON/servers straight from FG. WebSockets would be best for beefier data streams, but the AJAX would be just fine for simple switches or binary displays. Best part is the simplicity of only having to script the server/protocol in Nasal and then just building a webpage.
Raptor831
 
Posts: 42
Joined: Fri Nov 15, 2013 8:51 pm
Location: Raleigh, NC, USA
Callsign: N-R831
Version: 2.12.1
OS: Mac OS X, Win XP

Re: Virtual Panel/Control from Web Browser

Postby Hooray » Wed Dec 18, 2013 6:20 am

Which is why I'll be trying to get the needed code so Nasal can make WebSockets/AJAX/JSON/servers straight from FG. WebSockets would be best for beefier data streams, but the AJAX would be just fine for simple switches or binary displays. Best part is the simplicity of only having to script the server/protocol in Nasal and then just building a webpage.

once the building blocks are there, it really shouldn't matter if it's AJAX, JSON, REST or WebSockets - it should be similarly straightforward, and an implementation of either will probably serve as the reference for all the others. Thus, it would be better to prototype things using the more sophisticated protocol, to ensure that the infrastructure is flexible enough to also support the others.

BTW: You could even integrate the website building part in FG ($FG_ROOT) itself - it would just be a special directory that's used for serving files - I would find this preferable over using a separate website, especially in cases like this, i.e. a web-based cockpit panel, because that would not just be a niche-use, it would be generally useful.
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: Virtual Panel/Control from Web Browser

Postby Raptor831 » Wed Dec 18, 2013 2:37 pm

I had been thinking about getting the "server" at somewhere in $FG_ROOT, as you mentioned something like that previously in the thread. If I could serve the files from a particular point, then I could have everything you'd need right there. I'd aim for that as well, just for simplicity's sake. The less an end user has to set up, the better, in my opinion.
Raptor831
 
Posts: 42
Joined: Fri Nov 15, 2013 8:51 pm
Location: Raleigh, NC, USA
Callsign: N-R831
Version: 2.12.1
OS: Mac OS X, Win XP

Re: Virtual Panel/Control from Web Browser

Postby Kabuki » Wed Dec 18, 2013 3:00 pm

Raptor831 wrote in Tue Dec 17, 2013 11:45 pm:
Kabuki wrote in Tue Dec 17, 2013 7:46 pm:No, it doesn't matter which folder you're using. You are using two different *servers*. Using "WAMP..." doesn't mean anything special. An Apache server, and the flightgear httpd server. Different servers.


True, I still have to run both the local server and some kind of FG server. The trick is though if I'm not AJAXing to FG's server, but the one that contains both the display file and the script/middleman then browsers won't throw the 'same-origin' error. The trick is that the script has to connect to FG in some way. Currently there's no way around the middleman unless I'm content with just AJAXing switch calls in and parsing the returning HTML for the <input>'s value attribute, which seems absurdly complicated for what amounts to a "get" call.



Exactly. It works, and it's powerful, but it's cumbersome as hell.

Raptor831 wrote in Tue Dec 17, 2013 11:45 pm:PHP wasn't cutting it for me, as I could not for the life of me get a connection from FG..


The trick is to use "fopen URL" from PHP. It's a way of reading the output of a URL as if it's a file. Bone up on fopen() in the PHP documentation and use that, Alas, it's yet another thing to wait for, and the opening, reading and closing of localhost: takes a noticeable amount of time. Plus, you can't put+get data in the same round trip from the fg httpd.
Raptor831 wrote in Tue Dec 17, 2013 11:45 pm:WebSockets would be best for beefier data streams, but the AJAX would be just fine for simple switches or binary displays. Best part is the simplicity of only having to script the server/protocol in Nasal and then just building a webpage.


Websockets looks good to me. I see it's already been enabled by default on my issue of firefox on windows. I guess you already know that there needs to be a handshake with proper headers to first establish communication. I'm not sure what happens after that, if a protocol.xml file needs to be made, and how the browser is going to know which port to read from, if there is going to be both a websocket stream, as well as the capability to perform other browser communication (getting html output)
This is a family-friendly saloon. No talk stink.
Kabuki
 
Posts: 587
Joined: Fri Oct 23, 2009 11:21 pm
Location: Usually on the ground, always in the sky, except when underwater.
Callsign: Kabuki
Version: 3.0.0
OS: Windows 7

Re: Virtual Panel/Control from Web Browser

Postby Raptor831 » Wed Dec 18, 2013 4:07 pm

Kabuki wrote in Wed Dec 18, 2013 3:00 pm:The trick is to use "fopen URL" from PHP. It's a way of reading the output of a URL as if it's a file. Bone up on fopen() in the PHP documentation and use that, Alas, it's yet another thing to wait for, and the opening, reading and closing of localhost: takes a noticeable amount of time. Plus, you can't put+get data in the same round trip from the fg httpd.


I just don't like that way. :) It'd be slow anyway, and if I really wanted to I could make simply AJAXing work by disabling the browser 'same-origin'. It'd be less work for more speed.

Kabuki wrote in Wed Dec 18, 2013 3:00 pm:Websockets looks good to me. I see it's already been enabled by default on my issue of firefox on windows. I guess you already know that there needs to be a handshake with proper headers to first establish communication. I'm not sure what happens after that, if a protocol.xml file needs to be made, and how the browser is going to know which port to read from, if there is going to be both a websocket stream, as well as the capability to perform other browser communication (getting html output)


I think the best part of WebSockets is that it's a web standard. At this point, I believe it comes enabled on most modern browsers. And, when in doubt, just download Firefox or Chrome.

The handshake is what killed it initially, trying to use a generic protocol. It happens once on the initial connection, with a random secure key, that you need to respond back to with the correct answer. There was no way the generic protocol could handle that, as the XML you dictate is for every packet sent.

Once we can use Nasal for setting up the protocol, we could receive the request, send back the response, then commence sending the data over the socket back and forth. Then you only have to use Javascript on the client side to process the data.

For the server/port question, you could either hardcode those numbers in the server you build with Nasal and just use those in the JS code, or set up a few <input> fields that get read by the JS when the connection is made.
Raptor831
 
Posts: 42
Joined: Fri Nov 15, 2013 8:51 pm
Location: Raleigh, NC, USA
Callsign: N-R831
Version: 2.12.1
OS: Mac OS X, Win XP

Re: Virtual Panel/Control from Web Browser

Postby Hooray » Wed Dec 18, 2013 4:46 pm

the whole handshake thing only needs the building blocks used by the httpd/telnetd code, so once that stuff is exposed via Nasal, it can be implemented with very little code - we'd probably want to add some form of "htdocs" folder to $FG_ROOT, possibly with different sub folders for the most common needs (AJAX, REST, JSON and WebSockets) - but we could also support a property for overriding folders, i.e. to serve custom folders, outside $FG_ROOT.

For prototyping purposes, you could also extend the telnet/props protocol to support a WebSockets handshake, which should give you a rough idea what's needed bindings-wise.

Regarding the protocol and handshake, the implementation seems straightforward:
http://en.wikipedia.org/wiki/WebSocket# ... _handshake
http://simonewebdesign.it/blog/101-web- ... handshake/
http://www.websocket.org/aboutwebsocket.html
http://popdevelop.com/2010/03/a-minimal ... et-server/
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: Virtual Panel/Control from Web Browser

Postby Raptor831 » Thu Dec 19, 2013 7:06 pm

No progress yet on WebSockets/Nasal, but I do have a working concept now. Was able to code up a server in Python that serves the HTML views and connects to an FG telnet instance. It's also live on your whole network, so any computer can connect to it. Not sure it's the most network safe, but it specifically only serves the needed files and gives a test page otherwise.

Code is up on Gitorious here: https://gitorious.org/fgwebpanel You'll need to run the Python script from a shell or a Python IDLE instance, and you'll need Python 3.3. But, once you run the script you'll be able to go to http://<hostname>:5500/ (either localhost or the network IP of the computer running the server). Punch in the appropriate host and port for your telnet server, and you'll be set.

The actual layout isn't good, but it was intended at this point to make it simply work. You'll see an option to set your flaps and comm radio frequencies, and there is an altitude "display" at the bottom. They will be updated regularly (5hz at the most), so changes you make either in either the FG window or the browser window will be synced.

I believe all of the instruments are extendable at this point, so I shouldn't need to touch the server code much. I probably need to add some better type-ing, just because some of those floats/doubles will get rather large if I let them. But, this just leaves the visual coding left.
Raptor831
 
Posts: 42
Joined: Fri Nov 15, 2013 8:51 pm
Location: Raleigh, NC, USA
Callsign: N-R831
Version: 2.12.1
OS: Mac OS X, Win XP

Re: Virtual Panel/Control from Web Browser

Postby Hooray » Fri Dec 20, 2013 6:37 am

a similar, but more self-contained, proof-of-concept could be implemented on top of the existing telnet protocol, simply by extending it to also support HTTP headers - that way, you would set up telnet on port 1080 for example, and connect your browser to it (which already works, try it!) - but as the HTTP headers are not valid telnet commands, you'll get the help message shown for each unrecognized HTTP header in return. You can edit props.cxx to extend the telnet code - for starters, you can locate the help message and add push(cmd); to the top of it - which will push the full command back to the client (browser in this case), so that you can see the full HTTP headers received by the telnet client. At that point, it's straightforward to teach the telnet code to handle conventional HTTP requests, too.

Obviously, that's just for prototyping purposes, the scripted backend would be more flexible and better - but to get something working quickly, this shouldn't take longer than 15-20 minutes to make it recognize HTTP headers and switch to HTTP on demand, and respond with webpages.
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: Virtual Panel/Control from Web Browser

Postby Raptor831 » Sat Dec 21, 2013 12:02 am

I accidentally discovered that the other day, working on the server code. Pointed my browser to the wrong port and I was greeted with the help display!

Really, I wanted practice with the web end, and I figured rolling through the scripting with a language I've already worked with would only help the process later. Plus, versions of FlightGear without the proposed bindings need something too! :)

I'm looking into SVG gauges, and I've found a nice jQuery library that makes it a bit easier. MIT license, so I believe that is compatible with GPL. (If it's not, let me know!) Hopefully, I'll have some layouts done and some bindings written soon.
Raptor831
 
Posts: 42
Joined: Fri Nov 15, 2013 8:51 pm
Location: Raleigh, NC, USA
Callsign: N-R831
Version: 2.12.1
OS: Mac OS X, Win XP

Re: Virtual Panel/Control from Web Browser

Postby Hooray » Sat Dec 21, 2013 7:24 am

Raptor831 wrote in Sat Dec 21, 2013 12:02 am:Really, I wanted practice with the web end, and I figured rolling through the scripting with a language I've already worked with would only help the process later. Plus, versions of FlightGear without the proposed bindings need something too! :)


Well, to be honest: I don't know, 3.0 will be coming out soon - so realistically, you can target 3.2 with this - until then, most people in need for something like this will simply use FGPanel instead in the meantime.

But the deployment overhead is not as much when using a built-in HTTP server that simply serves SVG instruments to the browser. Also, you don't necessarily need OpenGL/hardware acceleration to make this work.

You could even build an instructor station on top of this, and it would be straightforward to set up and use once fully integrated - which no longer applies to anything based on FGPanel, but also any other scripted approach, i.e. beyond just Nasal. Thus, frankly, I do not see many people using a multi-layered solution - but you can obviously ask around (or even run a poll) to see for yourself, maybe I'm wrong here - but just look at the number of people responding here, or the number of similar threads. So, I wouldn't make up a demand that isn't there - to be brutally honest: look at the low number of FGPanel users we have, or simply the low number of FGPanel related discussions, which mirrors just how "niche" it is - another indicator would the wiki: the FGPanel has been there since the end of 2011, so for almost 2 years meamwhile - and the number of views is still under 7k - which translates into roughly ~250 views per month only - now compare that with addons that we know are popular, which typically have 3x as many article views.

So I wouldn't over-engineer things for a community that simply isn't there - anything that uses networking for inter-linking multiple fgfs instances or to connect FG to other software is highly niche and qualifies usually as pretty "geeky" :D

In general, people don't want to set up multiple pieces of software to use such features, they want to download & install FG, and be just done.

I'm looking into SVG gauges, and I've found a nice jQuery library that makes it a bit easier. MIT license, so I believe that is compatible with GPL. (If it's not, let me know!) Hopefully, I'll have some layouts done and some bindings written soon.


For rapid prototyping, I would simply use an existing JavaScript/Gauges library and customize it as needed, see for example:
https://developers.google.com/chart/int ... lery/gauge
http://justgage.com/
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: Virtual Panel/Control from Web Browser

Postby pommesschranke » Sat Dec 21, 2013 12:48 pm

Raptor831:

I like what your are working on!

I did not use FGpanel yet because it needs OpenGL and because I prefer glass-cockpit style PFD & ND

http://wiki.flightgear.org/FlightGearMap is somehow similar to FGpanel - it runs on android phones & tablets. The author did already start to code a modern PFD, but is not interested at the moment. So I was thinking of continuing his work on that or try to make my own PFD in python/kivy ( http://kivy.org/ )

It would be cool to find a way to use all those new canvas based flightgear instruments in 2D applications.
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: Virtual Panel/Control from Web Browser

Postby pommesschranke » Sat Dec 21, 2013 12:59 pm

Hooray wrote in Fri Dec 13, 2013 6:41 pm:3) FGPanel will be also built if you used the scripted/Superbuild method


how ?

I used download_and_compile.sh to succesfully build simgear,flightgear,fgcom
but how can I build fgpanel with it ?
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: Virtual Panel/Control from Web Browser

Postby Hooray » Sat Dec 21, 2013 1:06 pm

see the utils/fgpanel folder - it's all there ...
to update the binary, just run "make fgpanel" inside $FG_BUILD

It would be cool to find a way to use all those new canvas based flightgear instruments in 2D applications.

to be honest, FlightGear's canvas instruments are completely different from HTML5/Canvas, FlightGear's Canvas uses OpenGL/OSG and provides full hardware acceleration - so there's really no direct advantage when it comes to reusing FG's canvas instruments in some form of browser-based cockpit view. Your best bet still is FGPanel or the FGCanvas effort (which is really just going to be FG in a down-stripped runtime mode, nothing more).

To render glass cockpits in some separate program, you would need to use the canvas system available in SimGear - which is exactly what the FGCanvas idea is all about, just as part of the main fgfs code base.

However, you could create a PFD or ND in a browser using HTML5/Canvas - you would just need very little data out of FG, so there's no problem here - but you would basically be recreating things, there's no sane way to reuse existing FG resources here.

So, as someone familiar with most recent glass cockpit developments using the Canvas, I would suggest to either abandon the idea of using FG/Canvas instruments, or look into required changes for supporting FGCanvas, analogous to FGPanel. But ultimately, that still means that you'll need OpenGL to run things.

Otherwise, you would need to create a PFD/ND from scratch using just JavaScript and HTML5 and use FlightGear to provide the required data - definitely do-able, not even difficult, but kinda redundant obviously. On the other hand, being able to render glass cockpit stuff in a browser would indeed be kinda cool.

Okay, thinking about it, there's a workaround: A hybrid approach would involve serializing Canvas images and sending them to the browser so that they can be used in texture maps, that would delegate all the instrument/canvas rendering to FG, and would merely send the resulting image and hot spots to the browser, which would basically look and act like an animated/interactive GIF to the end user that responds to mouse clicks etc.

Technically, there isn't much missing to get an osg::Image of a canvas and send it to the browser, there's existing code in FG doing similar stuff, such as the screen shot feature, or the jpeg-httpd server - these bits could be reused and integrated, and you would end up with canvas images that could be sent to a browser, and that could even respond to GUI events.

That's the only sane way I can come up with to reuse existing Canvas technology in FlightGear, including the recent PFD/ND or MapStructure work. The browser would just end up displaying an image stream and delegating mouse events to FG, which would in turn update the streamed 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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Virtual Panel/Control from Web Browser

Postby Raptor831 » Sat Dec 21, 2013 5:21 pm

Hooray wrote in Sat Dec 21, 2013 7:24 am:Well, to be honest: I don't know, 3.0 will be coming out soon - so realistically, you can target 3.2 with this - until then, most people in need for something like this will simply use FGPanel instead in the meantime.
--snip--
So I wouldn't over-engineer things for a community that simply isn't there - anything that uses networking for inter-linking multiple fgfs instances or to connect FG to other software is highly niche and qualifies usually as pretty "geeky" :D


'Tis true. Honestly, I'm really only building this for myself. I saw something I'd like to do and was going to figure a way to do it. But I also figured someone else might want the same thing, so I'll build it like I'm going to release it. If people find it useful, cool. If not, no big.

I don't expect this to be used a ton, except by the "geeky" anyway. Somehow I would imagine that people who would build a simpit, even a glass one, are a very small subset of people who play these games! :lol:

Hooray wrote in Sat Dec 21, 2013 7:24 am:For rapid prototyping, I would simply use an existing JavaScript/Gauges library and customize it as needed, see for example:
https://developers.google.com/chart/int ... lery/gauge
http://justgage.com/


Oh, hey, good find! I was looking at Raphael anyway, so that's perfect. Thanks.

pommesschranke wrote in Sat Dec 21, 2013 12:59 pm:I used download_and_compile.sh to succesfully build simgear,flightgear,fgcom
but how can I build fgpanel with it ?


I got it to work, you just need to use make instead of the script, I believe. Dig around on the wiki for details, because I'm still figuring it all out myself!

pommesschranke wrote in Sat Dec 21, 2013 12:48 pm:I like what your are working on!


Thanks! It's been a learning experience all the way around. :)

Regarding the FG Canvas stuff, I wasn't planning on having that kind of detail, but that'd still be awesome! You could recreate a PFD with the data I'm already pulling, but having the PFD you're using would be much better. The ND is a bit more data to pull, but yeah, you could still swing it. Gotta say, glass cockpit displays similar to FGPanel would be very cool.
Raptor831
 
Posts: 42
Joined: Fri Nov 15, 2013 8:51 pm
Location: Raleigh, NC, USA
Callsign: N-R831
Version: 2.12.1
OS: Mac OS X, Win XP

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 20 guests