Board index FlightGear Support Hardware

Instruments for homecockpit panel.

Joysticks, pedals, monitors.

Instruments for homecockpit panel.

Postby julian » Fri Mar 07, 2014 12:38 pm

Hello,
i started a cockpit building project and i am aiming to build a 2-seat generic cockpit using flightgear. I use flightgear because it is so easy to get/set parameters and my inputs (knobs, sticks etc.) can be wired and connected by i²c-bus.
By now, i have a good computer for 3 "window"-outputs. It already works by good (enough) frame-rate.
I have an second (old) pc for showing instruments. What i want to have is actually the fgpanel functions.

But there are two unsolved questions for me:

1) Instruments: The fgpanel instruments given by default are not enough, i need to have a setup for 2-prop-planes and small passenger aircraft, too. I already know basics of making 2d-panels by xml, but does fgpanel support instruments like the pfd etc? I read somewhere that those instruments are made with canvas, and that might be not supported by fgpanel.
So is there any idea of how i can make the instrument panels the best way?

2) At the moment i use a camera-views.xml to design 3 cameras in fullscreen. I read that others generate one wide window with different views in it. Is it the same efficiency? What might be better?


I'm sorry if my questions are trivial oder already answered somewhere else. I read much in this forum before and played with flightgear a lot, but i dont find an answer and i dont want to do it wrong..;)
If there is some hardware/cockpit to show later, i will write an building log with fotos etc. if someone is interested. Maybe i can post the project in the wiki then, too. The building section in the wiki is very small by now..

Best wishes,
Julian.
julian
 
Posts: 5
Joined: Fri Mar 07, 2014 11:26 am
Location: NRW, Germany
Version: 3.0.0
OS: Windows 8.1, Ubuntu

Re: Instruments for homecockpit panel.

Postby litzi » Sun Jun 15, 2014 5:24 pm

Julian,

I have recently ported (and slightly modified) the code and textures for the existing Primus 1000 PFD for use in 2D panels (under fg 2.8.0). It therefore also works within fgpanel standalone, in a separate window (see screenshot below). If you are interested I can share the code and textures with you including details.

Martin

Image
Last edited by litzi on Sun Jun 15, 2014 5:34 pm, edited 2 times in total.
litzi
 
Posts: 123
Joined: Sat May 03, 2014 9:59 pm
Location: AT
Version: 2018.3.1
OS: Ubuntu 14.04

Re: Instruments for homecockpit panel.

Postby Hooray » Sun Jun 15, 2014 6:35 pm

litzi's work looks useful, and I'd suggest to get in touch with Torsten so that he can commit these changes.

In general, we still have very few Canvas-based instruments. The majority of "glass" instruments are still hard-coded, i.e. implemented in C++ space.
Such instruments are also not supported by fgpanel. FGPanel really only supports classic 2D panels that are built using stacked textures.
Anything more sophisticated than that (e.g. a NavDisplay) will require a hard-coded instrument, or Canvas - both of which are unsupported by fgpanel.

However, we're hoping to eventually absorb fgpanel functionality back into fgfs and come up with a special startup mode for running Canvas-based instruments in a standalone "FGCanvas" window, where the majority of subsystems would simply be disabled: http://wiki.flightgear.org/FGCanvas

This would then also make FGPanel obsolete, because we're hoping to unify the 2D rendering back-end using Canvas, i.e. by implementing a 2D panels parser via Nasa/Canvas.

However, there are still several things that need to happen for this to become feasible - currently, it seems this is at least another 3-4 releases away (i.e. 2+ years).
Obviously, this assumption is based on the manpower currently available, and people interested in helping with this. For the time being, there are 3 core developers working towards this and a number of other contributors willing to help to get this done.

Realistically, we could accomplish many things already - and if someone is interested in pursuing this, we can provide a ton of pointers and also help to varying degrees.

Maybe i can post the project in the wiki then, too. The building section in the wiki is very small by now.

yes, sounds like a good idea ! Feel free to get in touch if you need help contributing to the wiki!
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: Instruments for homecockpit panel.

Postby Torsten » Sun Jun 15, 2014 8:22 pm

I hope nobody every backports FGPanel to the fg core. The fgpanel is an extract of old fg functionality, the old 2d panel code to be more precise. It's goal is to run standalone on old and/or slow hardware and to render old steam gauges with great level of details. I would not suggest implementing PFD/MFD like devices using FGPanel as there are better ways to do so.
I am currently experimenting with HTML5 Canvas and SVG using the new websocket and AJAX interface. No more spooky XML files, no proprietary scripting language without a debugger. Just standard HTML, CSS and JavaScript and 100% cross platform.
Of course, thats for external displays only. For displays inside 3d models, the FG-Canvas/Nasal is the way to go (at least until Tom implements Gecko/SpiderMonkey ;-)

Cheers,
Torsten

Martin, if you like and license permits, I'll add your primus implementation and changes to FGPanel.
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: Instruments for homecockpit panel.

Postby litzi » Sun Jun 15, 2014 8:32 pm

Hi,

happy about the positive feedback!

I am aware from reading the forum that the 2D panel approach may be outdated, but the XML way of defining the instruments there made it very simple and clear for me to implement what it wanted.

However, before commiting this work I believe it needs to be better structured and documented. Its quite a hack in some places.. :-)

Below a brief overview of the status of this.

Features
========

* Standard stuff: AI, HSI, VSI, Altimeter tape, Speed tape
* Rolling least significant digits of Alt. and IAS numerals
* Below 10000 ft indicator in digital Alt.
* GS deviation indicator
* Outer, middle, inner marker annunciators
* ADF1, NAV1, NAV2 needles support (reads nav[0],nav[1],adf[0] properties)
(one of nav1 or nav2 needles shown in HSI dep. on AP selection)
* DME, NAV-id, NAV-type display
* Wind-speed and direction indicator
* Normalized AoA
* G-force
* Compatible for integration with fgpanel to show in a stand alone window
* V1,V2 and VS (T/O decision, T/O save, stall-speed ; only one at a time !) indicators alongside speed tape
* VS indicator blinks on IAS to VS difference < 10 kt


Dependencies
============

* Tested only under fg 2.8.0
* Depends on a nasal script that computes some properties needed by the instrument
* Integrated and tested only with the Citation-X A/C,
use for other A/C will need some adoption of the nasal code

Known Issues
============

* AP modes and AP engaged are not supported, althoug modes are indicated
* Normalized AoA is relative to a fixed 15 deg (hardcoded in
the nasal script) stall AoA, use for other A/C might need some adoption of the nasal code
* V1,V2 and VS values valid for Citation X only, hardcoded in the nasal script
use for other A/C might need some adoption of the nasal code
* Rolling least significant digits of Alt. and IAS numerals are just overlaid instruments to the main instrument and therefore need manual repositioning on the panel once the PFD is moved on the panel.
* Radar altitude is missing
* decision height is missing
* Ground speed is missing
* "arc" mode of the P 1000 is not supported

litzi
litzi
 
Posts: 123
Joined: Sat May 03, 2014 9:59 pm
Location: AT
Version: 2018.3.1
OS: Ubuntu 14.04

Re: Instruments for homecockpit panel.

Postby Hooray » Sun Jun 15, 2014 9:18 pm

Torsten wrote in Sun Jun 15, 2014 8:22 pm:I hope nobody every backports FGPanel to the fg core. The fgpanel is an extract of old fg functionality, the old 2d panel code to be more precise. It's goal is to run standalone on old and/or slow hardware and to render old steam gauges with great level of details.

Well, this has already been discussed on the devel list several times - the idea is not to touch fgpanel itself, but rather to allow FG to start up in a mode that would allow most subsystems to remain disabled, work that needed to be done as part of the reset/re-init effort anyway. So FlightGear as a whole would benefit from more fine-grained initialization/subsystem control.

And fgpanel itself, like you said, is "just" the legacy 2D panels code, which we're hoping to unify/modernize via a Nasal/Canvas parser anyway. Here, HTML5/Canvas and JavaScript would help us very little unfortunately, unless you're volunteering to handle the integration :D

I would not suggest implementing PFD/MFD like devices using FGPanel as there are better ways to do so.
I am currently experimenting with HTML5 Canvas and SVG using the new websocket and AJAX interface. No more spooky XML files, no proprietary scripting language without a debugger. Just standard HTML, CSS and JavaScript and 100% cross platform.

right, had we had that option 5+ years ago, this would have surely become a "standard", as it is extremely flexible, and doesn't keep the main loop busy.
And we would have the added advantage that these are all W3C "standards"
(Besides, I wouldn't exactly call Nasal "proprietary": http://en.wikipedia.org/wiki/Proprietary )

But there are other disadvantages involved here, those that come with running stuff outside the main process, i.e. due not being able to easily access certain data structures.
You've already worked around some of those by exposing FGPositioned via AJAX meanwhile, but obviously things get tricky once we're dealing with binary data that need to be accessed at higher rates, such as images or image streams.

A standalone canvas mode would not just allow MFDs to be run, but also any other Canvas-based graphics, i.e. HUDs, 2D panels, including even our GUI - which includes arbitrarily complex displays.
For that reason, even if nobody else is going to work on this, I am still going to pursue this.

Of course, thats for external displays only. For displays inside 3d models, the FG-Canvas/Nasal is the way to go (at least until Tom implements Gecko/SpiderMonkey ;-)

The main problem here is lack of consistency: we've seen half a dozen of glass cockpit related efforts over the years - including stuff like OpenGC (early 2000s) and FGGC (mid 2000s), and quite a few others in the meantime.

At the end of the day, this always meant that we had competing, and even conflicting, technology stacks involved - where one technology (instrument/MFD) would not work within the other run-time environment. Canvas, coupled with HLA (or even just remote/telnet properties), has the potential to solve this once and for all. We've actually been in touch with several avionics manufacturers that are now hoping to use the combination of FlightGear/Canvas + J661 for these reasons.

Now, given your recent work, I fully realize that we're probably not going to agree here - but I guess we have to accept that there are people here who've been working on Nasal/Canvas-based solutions for problems that you are now solving in a very different, and very elegant/standards-oriented, way - which is still not "native" to FlightGear, like you said.

But, ultimately, HTML5/Canvas + JavaScript isn't going to be hardware-accelerated in the form that FlightGear's Canvas system is. Then again, what you mentioned regarding HTML5/JavaScript support isn't all that far-fetched either - OSG can certainly already render WebKit views to a texture. So this is, once again, one of those cases where FlightGear turns out to be a very much disorganized, with even conflicting solutions being worked on by different contributors- obviously, this isn't the first time, and it's also not going to be the last time something like this happens. I think we simply have to embrace the opportunity and see what prevails.
From my standpoint, having -yet again- different types of instruments that are specific to an external run-time environment is very much a maintenance nightmare.

Technically, I even agree that a HTML5/Canvas+JavaScript based system would have been great to have years ago, and it would have helped unify several obsolete technologies - but meanwhile, Canvas is our most solid and most unified approach to tackle those challenges, without them being specific to an external run-time environment, while still providing all the theoretical benefits, plus quite a few more. There used to be a talk on the devel list about adopting JavaScript/XUL several years ago, back then, nobody like the idea - but some of the recent mongoose work looked very much in line with the debate we saw back then.

Obviously, that doesn't have to mean that things inevitably have to remain just accessible through Nasal though.
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: Instruments for homecockpit panel.

Postby Torsten » Mon Jun 16, 2014 1:36 pm

litzi wrote in Sun Jun 15, 2014 8:32 pm:I am aware from reading the forum that the 2D panel approach may be outdated, but the XML way of defining the instruments there made it very simple and clear for me to implement what it wanted.

I would not consider it outdated. I still provides the most simple way to create a standalone 2d panel for use with FlightGear. Nothing more, but nothing less.

litzi wrote in Sun Jun 15, 2014 8:32 pm:However, before commiting this work I believe it needs to be better structured and documented. Its quite a hack in some places.. :-)

Feel free to contact me whenever you think you are ready.


Hooray wrote in Sun Jun 15, 2014 9:18 pm:But there are other disadvantages involved here, those that come with running stuff outside the main process, i.e. due not being able to easily access certain data structures.

That's true but also true for a standalone FG/Canvas applications.

The main advantage of standalone applications using HTML/CSS/JS/AJAX is that they run on almost every browser without the need for installation of software. My prototype PFD runs on iOS, Android, Windows, Linux, OSX by just punching a URL into the browser's address field.

Torsten

Hooray wrote in Sun Jun 15, 2014 9:18 pm:(Besides, I wouldn't exactly call Nasal "proprietary": http://en.wikipedia.org/wiki/Proprietary )

Right, probably "niche product" is more appropriate :wink:

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: Instruments for homecockpit panel.

Postby Hooray » Mon Jun 16, 2014 2:26 pm

Torsten wrote in Mon Jun 16, 2014 1:36 pm:The main advantage of standalone applications using HTML/CSS/JS/AJAX is that they run on almost every browser without the need for installation of software. My prototype PFD runs on iOS, Android, Windows, Linux, OSX by just punching a URL into the browser's address field.


This is true, had we had a HTML/CSS/JavaScript-based GUI/MFD system in place prior to Canvas, it would surely have become the "standard", as it is so much superior to our existing method of using stacked textures and hard-coded glass instruments.
Being able to run such things in any supported browser is obviously pretty cool, and often time, people don't really need full hardware acceleration. The thing that I find a little difficult is the lack of consistency - obviously, glass/MFD support is something that's been lacking in FG pretty much since the very beginning.

And I find the idea very compelling not to have -yet again- different "code bases" implementing semantically equivalent instruments/functionality, like a PFD and/or ND, EICAS/EFIS or EFB displays.

Thus, I am really interested in supporting efforts like the work that Gijs and Hyde have done with the NavDisplay: It supports multiple instances per aircraft, and can easily be integrated with other aircraft - and it is even prepared to support different styling, and different types of NDs. The way the NavDisplay/MapStructure efforts have evolved meanwhile, the work originally written by a single guy (Gijs) can now be used in a ton of places with very little work involved, and basically zero programming. Including the fact that these displays are not longer aircraft or instrument specific, and can directly be used in any FlightGear dialog, PUI or Canvas.

The other issue with a purely "W3C-based" approach is that we'd need to become fairly creative once it comes to supporting modern avionics/MFD features, such as for example tail view cameras or even providing full GUI support along the lines of ARINC 661. Canvas has become sort of a technology enabler, it is not so much about end-user features, but it's become a platform that ties together features that were previously implemented in a very inconsistent fashion, one that also didn't exactly improve our degree of OpenGL compatibility due to a ton of legacy code all over the place, often not even using OSG StateSets etc.

Once you find it sufficiently complete, I suggest you announce/document your "W3C PFD" :D using the wiki (newsletter) so that we all can take a look.

Who knows, maybe there's even a way that we can find a compromise to optionally integrate both worlds to /some/ degree - i.e. we could serve Canvas-based textures as PNGs to a browser and actually let users decide on which side they want to use "native" FlightGear solutions, and where they'd prefer to use W3C options instead.

Obviously, JavaScript is in many ways superior to Nasal, and the way Nasal is integrated in FG, we cannot easily write async code either.

Being able to stream Canvas images/video to an external browser/viewer (via a worker thread) would also allow us to support a variety of other interesting use-cases, such as UAV stuff, OpenCV post-processing etc. The only thing that's missing to pull this off is a new placement type that exposes a canvas as either an osg::Image buffer that is serialized to a browser-format like PNG, or to some video stream. At that point, a browser could -in theory- even render live FG camera views streamed via UDP to implement a browser-based instructor console that can view individual Canvas MFDs/instruments, but even scenery views.

This kind of stuff has been discussed a number of times, and even Curt & Tim agreed (in the pre-canvas days) that this would be cool to support at some point: http://wiki.flightgear.org/Canvas_Devel ... ter_Vision
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: Instruments for homecockpit panel.

Postby litzi » Wed Jun 24, 2015 6:26 am

Hello all,

I have have quite advanced the fgpanel based "glass" panel and would be ready to contribute this now. I would need some instructions how and where to commit the code.

Below are 4 screen shots of the panel during various flight phases. More detailed description will follow.

Image

Also I propose to relocate this to another thread as it is not really "hardware" related (although the panel may be used as a basis for building a "mini" home cockpit).

Litzi
litzi
 
Posts: 123
Joined: Sat May 03, 2014 9:59 pm
Location: AT
Version: 2018.3.1
OS: Ubuntu 14.04

Re: Instruments for homecockpit panel.

Postby rustemy » Sun Mar 20, 2016 12:55 pm

Litzi,
Did this ever get submitted? I'm interested in doing something like this for my home cockpit.

Rustemy
rustemy
 
Posts: 24
Joined: Fri Jun 21, 2013 2:15 pm
Version: PPA-Edge
OS: Linux Mint 20.2 Uma

Re: Instruments for homecockpit panel.

Postby litzi » Mon Mar 21, 2016 10:50 pm

Hi,

thanks for your interest!

No, its not yet part of the flightgear distribution. I am still working to finalize this towards having it submitted. But if you are interested you can have this in advance as a zipped collection of 2d panel files. Will take a week or so as I am currently in holidays.

litzi
litzi
 
Posts: 123
Joined: Sat May 03, 2014 9:59 pm
Location: AT
Version: 2018.3.1
OS: Ubuntu 14.04


Return to Hardware

Who is online

Users browsing this forum: No registered users and 3 guests