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.

Virtual Panel/Control from Web Browser

Postby Raptor831 » Thu Dec 12, 2013 9:31 pm

I had an idea, but I need a bit of direction to continue. I wanted to do something like a custom cockpit, but using my laptop as my external. Trouble is, I can't run another copy of FG because the laptop is not up to par (it's an old MacBook, 2GHz Core 2 Duo, 64MB integrated Intel GMA 950). I looked at FGPanel, but I'm not completely sure how that would work, and I didn't see if that could send information to the master FG process as well.

What I am after is basically a virtual panel that could receive data to display (gauges, lights, switch positions) and send data to the sim (mostly switches, dials, etc and not control inputs). The catch is that I wanted this in a web browser, which my laptop can actually run.

While searching, I found the wiki articles on the networking options. After looking at those I feel like this is possible, but I'm not sure how to get FG and the external browser to talk to each other. Does anyone have a suggestion of where to start there? I don't know Nasal (yet...) but I have a feeling that would be an option. I'm also thinking that the native or generic protocol might be good, but I'm not sure what the data is looking like coming out of FG. I know with the generic protocol I can set up an XML document, so that might be the best.

Also, if anyone has some insight on setting up the listeners on the web end, I'd love to hear some ideas. This is a bit outside FG's scope, but can't hurt to ask.

I'm taking this on as a web development project to learn new skills. Since I do web development, it'd be a fun project to try and pick up some new skills. Also, this could turn into a very platform-agnostic way to have a cheap cockpit.
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 » Thu Dec 12, 2013 11:02 pm

Whenever someone asks a question that begins with "Is it possible to...xxx with flightgear?" the answer is usually "yes".

You can do all kinds of things with the built in HTTPD server in conjunction with your web browser. To do simple things, you don't need to know any nasal. You don't even have to be online. Just navigate your browser to the address+port number that the HTTPD is talking to, and you can browse the property tree. In places, you'll see input fields and buttons that allow you to set values of certain (not all are settable) properties. Take a look at your address field on the browser, and you can see how values can be set.

To get fancy, you'll need to know HTML+JavaScript and Nasal. My approach is to add a property via Nasal called something like 'cmd', and have Nasal listen to that property for changes. You then use your web browser to "get" (actually set) the 'cmd' property to some value that Nasal interprets as a command -- and at the same time, it can replace the 'cmd' you sent, with a value e.g. a success code, or whatever.

I'm not at home right now, so my answer has to be brief, but I can explain it deeper at some future time.

I've also had good luck connecting flightgear with Google Earth's browser plugin to do various things, such as have it display on the browser the Google image of where you're flying -- or use it to make a flightplan by clicking on locations on the Google map, and feed it to flightgear. This requires overriding the browser's "same origin policy", which can be done with a firefox addon.

The sky is the limit. I've been grounded for several months, so I'm a bit rusty on the code involved, but if you're interested in this, well... so am I.
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 » Thu Dec 12, 2013 11:24 pm

I did play around with the HTTPD property browser and had some fun editing the properties while I was in-game. I did see the URL structure that was used, but I think that'd get cumbersome for an FGPanel-like setup really quick. Also not sure I want to be pinging the "server" (as it were) at the kind of rates I want to be able to update at.

Basically, after some more research, I'm narrowing options down to two different ideas:

1) Figure out how to interface WebSockets to the FG sockets. The principle is there, I just don't know what the data is going to look like coming out of FG for me to parse on the client-side. If I can figure out how to parse the data, I can move into the display side.

2) Use an AJAX solution. This looks a bit more straightforward, and I can use Nasal to push XML or JSON to the browser (I think). The only hitch with this is that I'll probably be polling the game ("server") a lot, so I don't know what kind of performance hit I'll take.

I'd rather use option 1 since sockets are designed for real-time and AJAX isn't. And I'm not up on the code, as my expertise is more front-end HTML/CSS/jQuery stuff.
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 13, 2013 3:55 am

Play a bit more with it, it's definitely possible - and not even difficult, you could use a JavaScript program to animate SVG-based instruments via FG properties.
You could use JavaScript WebSockets for this - or use an intermediate layer (python/JS script) that syncs properties between fgfs and your browser.
Instead of parsing HTTP (via HTTPD), it would be more straightforward to use the telnet/props protocol: http://wiki.flightgear.org/Telnet_usage
that's then just plain text processing.

Regarding AJAX/RESTful HTTPD, we do have a long-standing feature request, you may want to leave feedback (or your vote) there, see: https://code.google.com/p/flightgear-bu ... ail?id=396

Make sure to go through the discussion there in the tracker, and you may learn a few more things about how to do that properly.

Finally, I would suggest to really consider FGPanel, if necessary, via CPU-software emulated OpenGL - FGPanel was specifically designed for this, so no need to reinvent the wheel here.

And if you cannot use FGPanel for some reason, another feasible option would be FlightGearMap: http://wiki.flightgear.org/FlightGearMap
viewtopic.php?f=31&t=16136&hilit=android+map

By looking at that code, you can also see how the interfacing part is implemented.

Personally, I would prefer your requirements to be laid out exactly (use the issue tracker) so that we can look into generalizing the networking system accordingly - I think extending the HTTPD code to serve SVGs with JavaScript animations should be straightforward to do - and it would make this a native capability of FlightGear, i.e. having a directory like $FG_ROOT/http where you can put an index.html file that loads JavaScript and SVG files to render an instrument or a whole cockpit panel. Assuming that you already have some programming experience, and that you are able to build FG from source, those changes should be really straightforward - the HTTPD code is very old and hasn't been maintained in years, but it's also exceptionally simple/crude C++ code that's doing token processing via the STL.

To look at the code, see: https://gitorious.org/fg/flightgear/sou ... /httpd.cxx


So extending this to serve files from $FG_ROOT should be less than 200 lines of modified/new code.

In the long run, it would be better to use cppbind and add wrappers for FGProtocol (used by both, telnet and httpd), that would allow new protocols to be implemented in Nasal, and Nasal does have CGI bindings, so that would be roughly 200 lines of C++ code, and about 50-100 lines of Nasal to create a WebServer from Nasal, at that point you could transfer any files, including html/JavaScript and vector images. So, the implementation would be moved into FlightGear, i.e. done via JavaScript/SVG and HTML files that would be served by JavaScript to your browser, with images being animated through a property live-feed from FlightGear.

Like I said, most of us here believe this to be the better approach - simply because the httpd/telnet code is already extremely convoluted and hasn't been actively maintained. So instead of adding even more stuff to it, it would be better to expose its "workhorse" to scripting space and allow such things to be implemented with ~30 lines of Nasal code.
So I would be willing to walk you through the details here, but only if you are able to build FG from source and know some basic coding already (preferably C/C++) :D

http://wiki.flightgear.org/Nasal/CppBind
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Virtual Panel/Control from Web Browser

Postby Raptor831 » Fri Dec 13, 2013 6:00 pm

Thanks for the details Hooray. Much appreciated. :)

Unfortunately, I haven't got a clue on how to build from source, and even more importantly I don't know C/C++. Also, since FGPanel isn't built into the Mac version of FlightGear, I don't have an app to run. The response I'd get for that would be "You can build it from the source", but again I'm clueless about that. :) Although, FGPanel might push me to figure that out anyway.

As for the task at hand, I just can't seem to connect the browser to *incoming* data. I've figured out a few ways I could send data, specifically with the HTTPD server. I can run an AJAX call and my property is updated. The bummer is that there's no data coming back. I can't really display any useful data inside the browser without some information coming back. Nothing's updated on the browser window so you're unaware of the current state.

If Nasal can send data out over the network, I could use that. I haven't seen how to do that yet. I've seen this page: http://wiki.flightgear.org/Howto:Making ... from_Nasal That seems the reverse of what I need.

The trick seems to be that browsers use web sockets which require a server presenting the same protocol. Which isn't the same as FlightGear is sending, at least not with the --generic=... flag that I've been trying. I was trying to avoid having a Python middle-man for this, but it looks like I may not have a choice.

If I were to set out my requirements, I'd probably just be looking for a websocket protocol to be established in FGProtocol. Ideally, you could use a similar flag as the generic protocol, so something like --generic=websocket,bi,10,localhost,5500,udp or maybe --websocket=bi,10,localhost,5501,udp. This way, you could be sending out on a "server" that the client-side can connect to and read the data from, and manipulating the data is easy enough after that. Something like sending { type: 'update', data:{ 'airspeed' : '/velocities/airspeed-kt' } } would comply with the protocol, I think.

Also, setting properties should be possible via the same pipe. I believe websockets are bi-directional by nature, so being able to just send a message back to the master like { type: 'set', data: { '/controls/flight/flaps' : 1} }. These are both akin to Nasal getprop/setprop, if I'm reading the wiki correctly. As I've said, I'm unsure of the low level stuff going on here, so I can't be sure of what's needed. But, I don't think this would be too tricky.

So, in MVC, your model is the FG master data/properties, your controller is the I/O and it's controls, and your view is simply the HTML/CSS/JS in the browser. The controller and the view would probably end up in the external "package", as any user/developer could change the layout, base images, colors, or even which properties/gauges/switches are needed/wanted. Portability and tweakability. Heck, some of the tweaks could be controlled by XML, in line with the rest of FG.

That sound like something useful I could put in the issue tracker?
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 13, 2013 6:41 pm

Hi, just briefly:

1) these days, building FG from source can be largely automated, check out the "Superbuild" article in the wiki.
2) The degree of C/C++ knowledge required here is negligible, and straightforward to obtain for anybody who's previously done any OOP
3) FGPanel will be also built if you used the scripted/Superbuild method
4) browser I/O: use WebSockets - establish a telnet connection into fgfs (which is bidirectional by nature), but there are still some challenges here, see: http://stackoverflow.com/questions/4725 ... javascript
5) you can always use an intermediate layer, i.e. a python script or whatever to act as the proxy between FG and your browser app
6) the most straightforward (least elegant) option would be using Ajax to simply make HTTPD calls and process the response
7) Nasal cannot currently be used as a server, as is - but it's recently got HTTP bindings, extending/exposing the FGProtocol via Nasal should be straightforward
8) otherwise, you would need to combine Nasal + the generic protocol - you could build your own protocol on top of this, by controlling the value of generic properties via Nasal.
9) right, the tutorial that you found is all about loading HTTP pages (XML files actually) into FG, and it's kinda outdated due to the recent addition of native http bindings
10) again right, FG does not currently support the WebSocket protocol, but you could probably hack it into FG, possibly even without touching the C++ code
11) the "middle-man" approach will work either way - regardless of it being writte in Python or JavaScript or whatever else
12) WebSockets via FGProtocol should also not be difficult to add, but I don't like the idea of doing that in a hardcoded fashion, I would prefer this to be done via Nasal, i.e. after FGProtocol gets exposed to Nasal space
13) the generic line you came up with still uses the generic protocol, which is a different beast - entirely XML configurable, but not related to the telnet/props or httpd code - so that's also not where you'd add WebSocket support via FGProtocol
14) the JSON/AJAX idea would be less specific and more widely useful, while also being accessible to projects like your's - so better add your comments to the issue in the tracker

Yes, feel free to use the issue tracker - that's what it's there for after all

Like I said, you could try to combine the generic protocol and Nasal to see how far this gets you regarding WebSocket support - in theory, you should be able to process input by writing it to a single property and using a Nasal listener to process it further - likewise for responses, which would be created by Nasal and written to a property that gets sent
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Virtual Panel/Control from Web Browser

Postby Kabuki » Fri Dec 13, 2013 7:53 pm

I appreciate this conversation, because I didn't know about websockets. So it's probably not worth mentioning, but it's definitely possible to get incoming data via AJAX or a jquery "get" request. You send a request from your browser and flightgear HTTPD will always sent a formatted web page as the 'result'. You have to parse that result to get the data. (use a regular expression to extract it). Also note that you can use the same property tree address to both send a command and read the data that would be the result of the command, in a single AJAX request.

It has its uses, and it has it's limitations, of course. I wouldn't think of reading some value(s) in real time. But to do something like change radio frequencies, or autopilot settings -- any kind of command (other than stick and rudder) would be OK. There's no polling required, just a Nasal listener on the property you use to send and get data. The only conversation occurs when you initiate it from the browser, and it's only one AJAX request.

I'm not sure how you'd implement an instrument on a web page, other than a digital one. I'd be more inclined to work within flightgear's standard approach to instruments and panels than use a web page, anyway.

For turning things off and on, or keeping a flight log, messing with the autopilot or route manager, ... all those things are easily done directly via AJAX and the HTTPD. And if you disable the 'same origin' policy on your browser, you can connect that page to some interesting things, like online charts, Google Earth, etc.

So once again, the right tool depends on the job. The main advantage of using AJAX/HTTPD is that it can be done in a direct manner with flightgear and browser "out of the box".
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 Hooray » Fri Dec 13, 2013 9:26 pm

Most of the *configurable *networking stuff in FG is based on FGProtocol (in $FG_SRC/Network/protocol.?xx): https://gitorious.org/fg/flightgear/sou ... otocol.cxx

FGProtocol is a wrapper for SGIOChannel: http://docs.freeflightsim.org/simgear/c ... annel.html

The existing httpd/props/telnet/jpg-server code is all based on PLIB's NetChat class (now in SimGear), if you have ever written any code yourself, you'll surely understand this part: https://gitorious.org/fg/flightgear/sou ... /httpd.cxx

The way the current code is written, it looks and feels a lot like php actually - so it's not too difficult to understand what's going on there.

Making the existing code support basic WebSocket features should not take longer than 20-30 minutes, so if all you need is quick hack, that's where you'll want to look.

You only need to check out the foundTerminator method and extend it slightly: https://gitorious.org/fg/flightgear/sou ... d.cxx#L193
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Virtual Panel/Control from Web Browser

Postby Raptor831 » Sat Dec 14, 2013 4:43 am

I would have to agree with Hooray, at the moment, on the idea that exposing the FGProtocol to Nasal would be best. I'll see if I can get comfortable building from the source and set up a nice dev environment on my master machine. I've seen enough code to understand what's going on in the files you've referenced, even if I don't understand the details of the language. If I get my bearings there, I'll see if I can't get the Nasal bindings worked out. I have a feeling I'll be learning lots of code in my near future. :)

In the meantime, I'm still figuring out a nice way to read data. I'm settling on probably telnet, since the FlightGearMap app works that way. Conceptually, I've got the data sent out of FG, connecting to the telnet server through some middleman, parsing the data via Javascript, and finally displaying data in the browser.

I get the idea of using "input" and "output" properties in conjunction with Nasal, and parsing the properties with listeners. Maybe setup a telnet subscriber to changes to the "output" property, which would then be used to update the browser info. Any changes on the client side (i.e. click on "Flaps - Full") could be immediately sent to the "input" property and parsed by the Nasal listener to set the appropriate properties in FG. Next cycle would send the changes back to the browser.

So the pieces are there in my head. Just need to figure a good middleman piece. A Java applet would work (found a library that does just this), or Python script. Once I find the right "translator" I think I'll be golden.
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 14, 2013 7:53 am

there's examples for both in $FG_SRC, a Java demo and a Python script using the telnet/props protocol.

If you want to play with the C++ code, I suggest to use the Superbuild for getting a build environment up and running: http://wiki.flightgear.org/Superbuild
Once you have all the dependencies installed (compiler, libraries), this should set up a build environment in a mostly scripted/automated fashion, with very little input/action required.

Also, you will probably find it easier to extend the props/telnet mechanism to support WebSockets, because it wouldn't require many changes, see: http://www.websocket.org/aboutwebsocket.html


Raptor831 wrote in Sat Dec 14, 2013 4:43 am:I would have to agree with Hooray, at the moment, on the idea that exposing the FGProtocol to Nasal would be best. I'll see if I can get comfortable building from the source and set up a nice dev environment on my master machine. I've seen enough code to understand what's going on in the files you've referenced, even if I don't understand the details of the language. If I get my bearings there, I'll see if I can't get the Nasal bindings worked out. I have a feeling I'll be learning lots of code in my near future. :)

Okay, I have created some simple stubs to get you started more quickly, this will already successfully build and it includes the required headers - so you only need to read up on FGProtocol, NetChat/NetChannel to come up with the methods (class functions) that are required, and expose those via cppbind. Which typically involves providing to_nasal/from_nasal helper functions.

You will find that cppbind itself has lots of comments and documentation in the source code, check out $SG_SRC/nasal/cppbind - there's also a unit test program named "cppbind-test", which contains additional examples.

See this for the stubs: https://gitorious.org/fg/hoorays-flight ... 30360122be

If you have any Nasal/cppbind questions, I suggest to get in touch via the Nasal forum - TheTom is the maintainer and developer of cppbind, so if we cannot answer something directly, he's usually able to fill in any gaps :D

If I find some more time, I may add some more stuff to it, or at least some decent example - but the commit itself should handle at least the ingration details already, but you will undoubtedly want to look at other Nasal/cppbind examples to learn how to expose required methods.

EDIT: I have now slightly extended those stubs, so that they now create valid FGProtocol objects and echo some info to the console when called - the next steps would basically be:
  • also wrap simgear::NetChat and simgear::NetChannel
  • register Nasal Protocols at the I/O subsystem level so that they are updated (see $FG_SRC/Main/fg_io.cxx): https://gitorious.org/fg/flightgear/sou ... s.cxx#L628
  • provide a means to either implement the FGProtocol interface, or alternatively, register your own callbacks

To understand, how things are hanging together in FG, see: http://docs.freeflightsim.org/flightgea ... tocol.html
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Virtual Panel/Control from Web Browser

Postby Raptor831 » Mon Dec 16, 2013 1:56 am

Thanks again Hooray for the kick in the pants. :) Guess this is as good of a reason as any to learn some proper C++, even if it is mostly copy/paste. Can't hurt in the long run!

Hit a hitch in getting the dev environment set up though. The archive.zip from Jenkins for the Mac dependancies is coming out corrupted, at least on the last two builds. Any ideas for that, or should I just get them individually? I'm just going to do it from CMake, as the wiki is saying here: http://wiki.flightgear.org/Building_using_CMake Figured I should know how to do it properly at least once. ;)

Still tinkering with my hopefully FG->PHP->AJAX->Browser option as well, just for the practice. I'm trying to use a PHP socket to read the FG data, which runs on the same local server (MAMP in this case) as the display page. This removes the 'same origin' problem and allows me to format the data in any way I want for the Javascript.

I'm having trouble actually getting the socket to read any data, though. I have a few more tricks to try, but I'm almost stumped on this one. I've been setting up a "client" on the PHP side that connects to FG (which has a socket out in the current setting). I'm thinking of trying to set up the "server" on the PHP side and let FG "connect" to it instead.

I have a bad habit of jumping in the deep end to learn how to swim. :D
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 » Mon Dec 16, 2013 5:26 am

Raptor831 wrote in Mon Dec 16, 2013 1:56 am:Still tinkering with my hopefully FG->PHP->AJAX->Browser option as well, just for the practice. I'm trying to use a PHP socket to read the FG data, which runs on the same local server (MAMP in this case) as the display page. This removes the 'same origin' problem and allows me to format the data in any way I want for the Javascript.


Does it *really* remove the 'same origin' problem? Because when I was doing the same thing -- running an Apache server, I still got the problem. This is because the 'same origin' means 'same server' -- NOT 'same host'. I was able to fread() from the flightgear httpd server, but it was inefficient and didn't satisfy my heart.

I finally found a firefox extension that overrides the same origin policy (and I believe the the latest browsers allow it to be overridden by some setting (?)).

After that, I stopped using the Apache/PHP step, and just got data directly from the flightgear http server and parsed it with JavaScript.

Again, it all depends on what you're trying to do, but I don't quite see how a web browser is the appropriate tool if you're wanting to process streaming data. A web browser is event-driven, and http is a "stateless" protocol. If you're going to make occasional readings or settings, it's fine. But a live instrument, like with a needle that moves over a bezel... how are you going to program that in JavaScript? A loop that reads a variable that's automatically updated via a socket? Is JavaScript up to something like that?

As I've said, there is a lot of interesting stuff you can do by connecting a browser to flightgear. But I'm not sure how it would work with a passive client that has data being pushed to it. Flash, maybe, but do we need yet another layer of programming?
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 Hooray » Mon Dec 16, 2013 6:39 am

The C++ part is not too difficult, most of the really low-level details are handled by the cppbind framework - so it really just involves some copy/paste and customizing, and reading some docs/code (examples) obviously. So far, it's roughly 100 lines of C++ code, and it already contains all building blocks to expose most things required.

Regarding the corrupted ZIP file, I just gave it a try and went to: http://flightgear.simpits.org:8080/view ... arty-deps/
And downloaded the ZIP file, I ended up with a 35MB file and it's not corrupted here - so maybe it's your connection i.e. use a download manager ?
But I have forwarded your report to the Jenkins admin (Zakalawe) so that he can have a look.

Regarding cmake, it doesn't matter - the Superbuild also uses CMake, and it should involve not as many steps.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Virtual Panel/Control from Web Browser

Postby Raptor831 » Mon Dec 16, 2013 3:18 pm

Kabuki wrote in Mon Dec 16, 2013 5:26 am:Does it *really* remove the 'same origin' problem? Because when I was doing the same thing -- running an Apache server, I still got the problem. This is because the 'same origin' means 'same server' -- NOT 'same host'. I was able to fread() from the flightgear httpd server, but it was inefficient and didn't satisfy my heart.

I finally found a firefox extension that overrides the same origin policy (and I believe the the latest browsers allow it to be overridden by some setting (?)).

After that, I stopped using the Apache/PHP step, and just got data directly from the flightgear http server and parsed it with JavaScript.

Again, it all depends on what you're trying to do, but I don't quite see how a web browser is the appropriate tool if you're wanting to process streaming data. A web browser is event-driven, and http is a "stateless" protocol. If you're going to make occasional readings or settings, it's fine. But a live instrument, like with a needle that moves over a bezel... how are you going to program that in JavaScript? A loop that reads a variable that's automatically updated via a socket? Is JavaScript up to something like that?

As I've said, there is a lot of interesting stuff you can do by connecting a browser to flightgear. But I'm not sure how it would work with a passive client that has data being pushed to it. Flash, maybe, but do we need yet another layer of programming?


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.

As far as bandwidth, I'm not sure the web tech can handle that much data. :) That was part of the reason for me to try. HTML5 has Canvas technologies, so the display isn't really an issue once I learn to leverage that. jQuery can do some pretty interesting things, as well. And, if we can get WebSockets up and running, I can even cut out the middle-man PHP and just connect to the display page directly.

The "Hello, world!" of all the WebSocket info I've found is a live chat room. The principle is the same as the chat: send message to the client that gear position has changed, client reads data and changes display accordingly. I probably won't be able to have data streaming at 60hz for every gauge, I know that. But having an airspeed indicator, an altitude indicator, and maybe an attitude indicator wouldn't be so crazy. For use cases, I was imagining mostly switches and toggles, or a radio stack. Stuff I'd like in view but can't always see when I'm trying to look out the front window! Like flap setting, radio frequencies, maybe gear toggle, maybe autopilot toggles.

This is a grand experiment, so I don't honestly know if it will work like I want it to. :)

Hooray wrote in Mon Dec 16, 2013 6:39 am:Regarding the corrupted ZIP file, I just gave it a try and went to: http://flightgear.simpits.org:8080/view ... arty-deps/
And downloaded the ZIP file, I ended up with a 35MB file and it's not corrupted here - so maybe it's your connection i.e. use a download manager ?
But I have forwarded your report to the Jenkins admin (Zakalawe) so that he can have a look.


I'm going to try different browsers and find a DL manager. I only got a 1MB .zip file from the link you sent, so it's apparently something on my end.

EDIT: It appears Chrome is the issue. I tried the download within Firefox and I got the 35MB file and it opened just fine.
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 » Mon Dec 16, 2013 3:35 pm

for conventional steam gauges, bandwidth is not going to be an issue - especially if you manage to get data "on demand", instead of just polling - even updating 20 instruments at 5 hertz will only result in 100 transmissions per second, and those are likely to be merely floats/doubles - so it's really not an issue. You would probably want to use something like SVG/SMIL to serve animated vector images, so would not even need to use HTML5/Canvas to recreate every instrument.

In theory, you could in fact even serve FlightGear textures (instruments) and update those via HTML5 Canvas, but I'd suggest to use vector images instead.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 3 guests