Board index FlightGear Development Aircraft Cockpit development

Glider instrumentation

Discussion about creating 2d and 3d cockpits.

Re: Glider instrumentation

Postby galvedro » Fri Jan 17, 2014 10:22 am

Hi! Good to see there is more people interested in the soaring niche! :D

A first iteration of my work was merged to mainstream a couple of months ago. From a user perspective, the only change you will see in the next FG release is that all gliders have now total energy compensated varios. The scripts that drive them are much more capable though, and already support all types of advanced varios: Netto, Relative and Speed Command.

I have two stickies in my board right now for this project: One is to build a simplified advanced vario gauge (like Condor's electronic vario) and get it integrated into one of the higher profile gliders already available (ASW20 perhaps?). That would serve as a first example of how to use the soaring instrumentation kit for implementing more advanced glider avionics.

The second sticky is to do a cleanup round in the wiki pages related to soaring instrumentation to better reflect current state of affairs, and also document the new Nasal library so aircraft authors can actually use it.

BTW, may I ask what are you missing from Condor/SilentWings? (I know what I miss, but perhaps you miss other interesting stuff as well :wink:).
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Fri Jan 17, 2014 10:38 am

Using the Canvas + Nasal, we should be able to re-create even sophisticated gliding computers now in FlightGear. I don't think there's anything really missing at the moment, there should be basically no C++ changes required to make this happen.
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: 12090
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby galvedro » Fri Jan 17, 2014 1:02 pm

What I think is missing is a pattern for building "stuff" in a reusable way, for example instruments that can be picked from the shelf and installed in a cockpit with perhaps certain customization applied per instance.

The current ILEC SC7 vario is reusable in the sense that you can load that script from an aircraft, and it will update the property tree appropriately, but you can not install two units in the same cockpit easily. You can not feed the instrument with aircraft specific stuff in a clean way either. This is not really necessary for the SC7, but it is a requirement for advanced variometers where an aircraft specific set of performance parameters needs to be provided to the instrument (the polar curve, for example).

I have a devel branch with an object oriented version of the SC7 that supports instancing. In that implementation, what you do is instantiate a Nasal library object from your aircraft, and assign it a place to live in the property tree. This is a more sane way to work I think, i.e. you plug the instruments to your cockpit, rather than your cockpit to the instruments! :D
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Fri Jan 17, 2014 5:24 pm

re: "installing multiple units per aircraft", this is something that we really want to support - and it should be greatly simplified by using OOP with different instances per instrument, like you say.
I think it's one of the things we discussed originally. In general, this is definitely technically possible - like you say, it's all about encapsulating all instrument-specific stuff in a class, and using the property tree accordingly. Most aircraft developers simply tend not to develop things this way, because it is obviously more difficult - and because it requires thinking like a "programmer" - we've seen this in various other places, including in new Nasal/canvas instruments like the 747-400 NavDisplay code, which originally also didn't support multiple aircraft, or multiple independent instances per aircraft.
I think what's really missing here is a framework, preferably modeled on top of a SGSubsystem wrapper, so that aircraft developers only need to specify instance specific variables and properties, and global/shared ones - conceptually, this is straightforward to do, and the NavDisplay framework is now doing this implicitly - i.e. it doesn't matter if you need once instance, 2 instances or 20 instances - they're all independent, and use different property branches accordingly. In fact, we generalized the code such that it now cannot only be used on different airliners/aircraft, but even use AI traffic as "source", i.e. you get to see the traffic situation from the point of view of each AI aircraft.

This is something where having a dedicated "subsystem" and "instrument" framework could help aircraft developers come up with generic instruments that do not suffer from hard-coded restrictions.
I would be very interested in helping with this, because there's quite a number of instruments that contain such hard-coded design limitations - and it would be awesome to get rid of those, for the sake of the project, but also to ensure that other aircraft developers can more easily reuse instruments, and customize/contribute things as required.

One of the things I was hoping to look into sooner or later would be generalizing the 747-400 PFD code accordingly, so that it can also be used on other aircraft, but also easily parameterized for different types of aircraft. The work isn't really difficult, but it touches a ton of places, especially because people tend to come up with "singleton" designs that are not really flexible at all.
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: 12090
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby F-JYL » Fri Jan 17, 2014 5:36 pm

look at the MFD panels in the 777 instruments directory it is more object oriented not perfect but could be easily improved in that way
F-JYL
 
Posts: 54
Joined: Mon Mar 11, 2013 8:34 pm
Callsign: F-JYL
Version: git
OS: Ubuntu 13.10

Re: Glider instrumentation

Postby Hooray » Fri Jan 17, 2014 5:58 pm

we probably need to generalize things a bit to identify and move aircraft-agnostic stuff out of the aircraft folders into the shared Nasal directory instead - otherwise, we will end up with a handful of more or less "generic" components that are still aircraft specific, i.e. cannot be easily reused in other aircraft without tons of editing.

@galvedro: you may want to add a note about your work to the changelog for the 3.0 release, see: http://wiki.flightgear.org/Changelog_3.0
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: 12090
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby galvedro » Fri Jan 17, 2014 8:22 pm

Hooray wrote in Fri Jan 17, 2014 5:58 pm:@galvedro: you may want to add a note about your work to the changelog for the 3.0 release, see: http://wiki.flightgear.org/Changelog_3.0

Done!

Hooray wrote in Fri Jan 17, 2014 5:24 pm:This is something where having a dedicated "subsystem" and "instrument" framework could help aircraft developers come up with generic instruments that do not suffer from hard-coded restrictions.

I Agree. The way I envision it currently is something along the lines plotted here: http://forum.flightgear.org/viewtopic.php?f=66&t=21217&start=15#p194416. Instruments implemented in a framework like this would not even be controling (nor be controlled by) properties directly, for example. Instead, they would define input/output ports that the aircraft developer would connect to the appropriate locations according to his design. This schemma gives a lot of flexibility and generality by isolating subsystem behavior from any external context. You want to send an output to a property? You can. You want to send an output to another cascaded subsystem, you can also do it. You can even do both at the same time in the current prototype! 8)

However, I have my caveats regarding the scalability and performance of this approach, perhaps I am being a bit naive. We will see...
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Fri Jan 17, 2014 8:35 pm

Yes, that sounds like a good approach - not too sure about any caveats here, it is definitely better than the current method, including the hacks used in C++ space.
However, it would be great if we could support use-cases and concepts like having "ports" or "sensors" that can be cascaded/nested - i.e. complex aircraft will typically have several instruments that can be driven by different "sources" (think different gyros, pitot tubes or even FMCs) - also, MFDs can typically be toggled to show different PFDs/NDs - we briefly talked about this a while ago, i.e. encapsulating the concept of "data providers" and "visualization", by introducing a "source" class that can be mapped to cockpit switches.
This is something that would be really useful for all the ongoing airliner development, which will be making use of more and more Canvas-based instruments, where supporting mutiple image generators for a single data source would be a common use-case, based on RL.
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: 12090
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby galvedro » Fri Jan 17, 2014 8:57 pm

Hooray wrote in Fri Jan 17, 2014 8:35 pm:it would be great if we could support use-cases and concepts like having "ports" or "sensors" that can be cascaded/nested - i.e. complex aircraft will typically have several instruments that can be driven by different "sources" (think different gyros, pitot tubes or even FMCs)

Absolutely, that is a fundamental part of the design! The architecture is designed to be "recursive": a component can be made of other components and export a similar port based iterface to the outside world. Even the SC7 instrument currently in the repo implements this multi-source concept, albeit in a primitive way:

Code: Select all
var lcd_controller = InputSwitcher.new(
    inputs: [battery_level, averager, temperature],
    active_input: 1,
    on_update: update_lcd_props);

Complex displays are not as simple of course. I haven´t give them much thought yet, but I guess it would only be a matter of encapsulating the display source in an object that can be passed through the ports.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Fri Jan 17, 2014 9:30 pm

Canvas MFD displays are just canvas textures, which are just represented as "properties", or rather, "property branches" - in the form of /canvas/by-index/texture[x] - you can use the property tree browser to check how these work - but basically, each canvas texture can have multiple "placements", such as "aircraft", "scenery" or GUI (dialog/window) - these placements maintain a reference count internally.

Toggling between different image sources is also accomplished by supporting recursion through "nested canvases" - i.e. a canvas can "include" (reference) another canvas and use it as the image source (raster image).

Thus, technically, the only thing involved would be coming up with two classes for "displays" and "image generators" - where each would be internally mapped to a canvas texture, the image generator would be "black box" where rendering takes place - while the "display" would be just a simple canvas that references the proper canvas texture, based on the currently selected switch/mode.
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: 12090
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby Philosopher » Sat Jan 18, 2014 11:22 pm

Unfortunately, I think the big problem with multiple instances is the property references in model files – one would have to be made for each instrument, which I can see no way to change :(. I think galvedro's framework otherwise supports multiple instances (though use of property indexes – procedural code could easily be made to instantiate a control path with a certain index, just by calling the proper functions in galvedro's framework).

Thanks for adding it to the changelog too. :0
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1588
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Glider instrumentation

Postby Hooray » Sun Jan 19, 2014 7:48 am

like you say, this is typically solved by using indexed property branches - so I am not sure if there's a real problem here ?
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: 12090
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby galvedro » Wed Jan 22, 2014 8:04 am

Philosopher wrote in Sat Jan 18, 2014 11:22 pm:Unfortunately, I think the big problem with multiple instances is the property references in model files – one would have to be made for each instrument, which I can see no way to change :(.


Perhaps model files should be treated as "templates" instead, leaving to the instancing code in the core the responsibility of binding object property hooks to their final locations in the property tree. The final location could be controlled by aircraft authors in the cockpit definition files.

I am just thinking aloud. I have only really been exposed to the instruments I tweaked when integrating the soaring toolkit, so I have not much experience on how the binding actually work.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Gijs » Wed Jan 22, 2014 9:05 am

Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9361
Joined: Tue Jul 03, 2007 2:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Glider instrumentation

Postby Hooray » Fri Jan 31, 2014 5:17 pm

F-JYL wrote in Fri Jan 17, 2014 5:36 pm:look at the MFD panels in the 777 instruments directory it is more object oriented not perfect but could be easily improved in that way

Looked at it: https://gitorious.org/fg/jlebleus-fgdat ... FD/mfd.nas

If we could generalize this, I would like to reuse your code to come up with a shared "MFD" class, whose interface would then be implemented by the PFD & ND modules.

We only need to add helper classes for "screens" (CRT/LCD) and "switches", so that we can toggle display modes (source) or settings (brightness etc)
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: 12090
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 1 guest