Board index FlightGear Development Aircraft Cockpit development

Glider instrumentation

Discussion about creating 2d and 3d cockpits.

Glider instrumentation

Postby galvedro » Mon Oct 07, 2013 3:30 pm

Greetings!

I have been doing some work on glider specific instrumentation lately, and I thought it would be nice to drop a quick note here in the forums to let you know, and perhaps to get some feedback also. This is my first development for FlightGear, so I hope I am not reinventing the wheel!

My idea is to build up a small library of reusable elements that can be interconnected for assembling real world gliding instruments. Currently, all these elements are implemented in Nasal space, although I don't discard the idea of moving them down to C++ eventually.

The library is still taking shape and some components are still under active development, but for now, it includes the following:

- TotalEnergyProbe: Provides instant total energy variation.
- Dampener: Simulates needle dampening with a given time constant.
- Averager: Moving average of the last X samples.
- PolarSolver: Provides optimal speed to fly given a glider polar (quadratic parametrization for now).
- NettoVario: Properly simulated airmass variometer, taking a total energy readout and substracting a tabulated glider sink rate for current airspeed.
- RelativeVario: Adds gliders minimum sink rate on top of the Netto reading.
- SpeedCommandVario: Provides the difference between current airspeed and "optimal" speed to fly according to classical McCready theory.
- FinalGlideComputer: Computes altitude required to cover a final glide distance for a given McCready setting. Takes provided wind into account.

Elements that perform time related computations take simulation speed into account and are framerate independent, so vario needles do not drop suddenly if you set simulation speed to 4x, for example, or don't oscillate when framerate gets jittery.

A couple of examples of what I would like to achieve:

- The ILEC SC7 electronic variometer currently available in the sim can be implemented by putting together a total energy probe, one dampener, and a 25 sec averager.

- A "speed to fly" vario like a Borgelt B500 would be implemented by connecting a TotalEnergyProbe, a Dampener, an Averager, a PolarSolver and a SpeedCommandVario.

- A more advanced flight computer like a Cambridge MNAV/LNAV for example would make use of all elements in the library for the computations, plus a high level Nasal script for the user interaction part.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Mon Oct 07, 2013 3:59 pm

Hi & welcome,

this is an interesting project - IMO, there should be little need to move stuff to C++ space - Nasal scripting and the Canvas system should provide all that you need, you may also want to check out: http://wiki.flightgear.org/Improving_Gl ... ism#Gauges

As you can see, we've had a fair bit of discussion on improving glider gauges.

Regarding TE-compensated various, see the variometer section:
Please Note that as of 06/2010 there is now a TE compensated variometer available in FlightGear HEAD: $FG_ROOT/Aircraft/Instruments-3d/glider/vario/ilec-sc7. It has been implemented for the ASK13 glider. (As of 02/2011 there is also a second TE compensated variometer available, implemented for the DG-101G.)
People interested in adding this instrument to other gliders, will want to refer to the README_install file.



A library like the one you described, would ideally be implemented using an OOP design, so that it can be easily extended/customized but also re-implemented using inheritance.

Let us know if you need any help with the Nasal/Canvas side of things, we have dedicated sub forums for both.

Feel free to add a note about your own effort to that article, but also to the upcoming newsletter: http://wiki.flightgear.org/Next_newsletter
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: Glider instrumentation

Postby galvedro » Tue Oct 08, 2013 9:25 am

Thank you for the pointers Hooray. If that information is up to date (and I assume it is), they draw a very clear picture of current status. I think what I am doing will fit very well in the long term goals. I will update the page to add some information about this little project.

On a side note. Yesterday I tested the Netto and Relative (Super Netto) variometers by plugging them into the ASK13 cockpit. In order to use these components, the aircraft designer has to provide three parameters to characterize the gliders polar curve (as one would do to calibrate their real world counterparts). I didn't know the performance curves of the simulated ASK13, so I added parameters for the real thing.

The instruments work nicely, but what I discovered was this: The Netto vario is a very good tool indeed for fine tuning flight models. You can calibrate the instrument with the desired polar you would like to achieve, and what you get in the dial is a zero reading (assuming still air) as long as you stay close to the polar. If the FDM deviates for a given speed range, the needle will go up or down accordingly. This might sound like a very stupid conclusion, but I didn't realize until yesterday the netto could be used for that! :)
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Tue Oct 08, 2013 10:22 pm

you may want get in touch with Bomber who's currently working on improving the ASK13 FDM, so he'll probably appreciate any additional tools to refine the FDM. There's a separate download available with the refined FDM, just search for "T4T" (or just Bomber) and "ASK13"
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: Glider instrumentation

Postby galvedro » Sun Oct 13, 2013 8:32 am

Hi,

The library is coming out nicely so I thought I would post an example of how the it looks like from a user point of view. The following snippet could be either part of an instrument, or part of an aircraft, driving the gliding instruments for the entire cockpit.

There are advantages to both approaches. The advantage of implementing each instrument separately is of course modularity. Every instrument is a closed package that authors can plug&play in the cockpit. The advantage of using one script for driving the entire cockpit in contrast is performance. The library is designed to be fast, so when you create an arrangement like the one below, every computation is performed only once, and interactions to the outside world via the property tree are reduced to the minimum. Data flow within the different elements is performed in Nasal space only. You can´t apply these optimizations when every instrument is implemented in isolation.

So for example. This script drives the ASK13 cockpit, controlling both the ILEC SC7 and the Winter variomenters:

Code: Select all
# Some helper functions for updating properties
# on instrument refresh or user action
var update_avg_props = func(value) {
   setprop("instrumentation/ilec-sc7/average", math.abs(value));
   setprop("instrumentation/ilec-sc7/average-sign", math.sgn(value));
};

var update_sensitivity = func {
   sc7_needle.dampening = getprop("/instrumentation/ilec-sc7/sensitivity");
};

# Instrument setup:
# One TE probe feeds two vario needles (winter and sc7) and a 25s averager
var probe = TotalEnergyProbe.new();

var winter_needle = Dampener.new(
   input: probe,
   dampening: 2.8,
   on_update: update_prop("/instrumentation/variometer/te-reading-mps"));

var sc7_needle = Dampener.new(
   input: probe,
   dampening: 3,
   on_update: update_prop("/instrumentation/ilec-sc7/te-reading-mps"));

var averager = Averager.new(
   input: probe,
   size: 25,
   on_update: update_avg_props);

# Put everything together into an instrument
var cockpit = SoaringInstrument.new(
   fast_update_elements: [probe, winter_needle, sc7_needle],
   slow_update_elements: [averager]);

# Change electric vario dampening when the pilot flips the switch
setlistener("/instrumentation/ilec-sc7/sensitivity", update_sensitivity);

# Start the fun
cockpit.enable();



P.S. Now that I have tested the netto more, I will pm Bomber in case he is interested in using the netto for fdm fine tuning (and beta testing the library while at it) :)
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Sun Oct 13, 2013 9:24 am

this looks really good and exceptionally clean/readable!
Please feel free to add your code snippets / integration examples to the wiki - to get your code committed to fgdata, I'd suggest to get in touch with Philosopher, who doesn't mind looking at elegant Nasal code once in a while :lol:
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: Glider instrumentation

Postby Philosopher » Sun Oct 13, 2013 2:27 pm

Haha, looks awesome!! :D
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Glider instrumentation

Postby Hooray » Sun Oct 13, 2013 3:27 pm

from a design point of view it would be a good idea to keep some things in mind, such as:
  • handle simulator signals properly (fdm init, reset/re-init, pause/freeze, replay) - i.e. to manage/clean up listeners/timers and other resources
  • support multiple instrument instances (not that important here, but maybe for other instruments)
  • prepare support for instrument failures via control properties (think instructor console or built-in dialog)

In general, scripted systems are basically also true subsystems and should usually follow the same coding protocols and conventions that the C++ code (namely, SGSubsystem) follows, so that there's no subtle breakage introduced over time - hence, scripted subsystems like local weather, bombable or instrumentation systems like this one should behave like a proper subsystem that handles the most important events (signals) and interacts properly with other important features (think replay, pausing or resetting/switching aircraft at runtime).

Philosopher once mentioned that we could introduce a scripting-space wrapper that resembles the C++ SGSubsystem interface, so that scripted subsystems follow a proper design by requiring them to implement the corresponding interface and register themselves globally, where signals and events can be propagated automatically - basically, a properly designed interface could be reused for other scripted instruments. From a performance standpoint, there's actually little need to have our existing instruments hardcoded in C++ - the majority could be easily re-implemented in scripting space, and thus become better maintainable, and easier to contribute to, for non-developers. Obviously, they just need to keep on using a MVC pattern, so that the visualization is kept separate from the internal model and control (via properties).

And adding some basic support for failing instruments/ input sensors (think pitot tubes) would make sense because higher-level avionics (flight computers) should ideally only get certain input data and be otherwise unaware of internals like these. Meanwhile, most features available in a real flight computer like XCSoar, can be built using Nasal scripting and the canvas system.
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: Glider instrumentation

Postby galvedro » Mon Oct 14, 2013 9:31 am

These are very good points Hooray.

So far I have been learning about FG internals by looking at how similar scripts are written (ask13 and dg101 mainly), and resolving some flaws that I was able to identify, like performance, structure and simulated time management.

But as you say, there are some limitations currently that I would eventually like to address. Interaction with other systems is one, in the case of glider instrumentation, that would be the battery powered electrical system mainly. Failure management is another one: the TE probe should be able to fail on command as the pitot does, for example. (Not the first time I loose one of them in flight, it's good to be prepared for that.. :D )

I was planning on releasing a first "drop" quite soon with the basic stuff in place and perhaps refactoring existing glider cockpits to make use of the library (if you find it appropriate). That would resolve some issues with existing implementations and add total energy compensated variometers to gliders that don't have them. But I am not sure if I should address those other "core framework" limitations before a first delivery. What do you think is best?

From a performance standpoint, there's actually little need to have our existing instruments hardcoded in C++


I think Nasal performance is definitively not an issue for the instruments in a glider cockpit, and possibly neither is for light aircraft. The main update loop running the configuration shown above runs in about 40us in my computer. That is about 0.1% of the framerate I get. But I am not sure what the impact would be in a full fledged cockpit like the A-10 for example, if it was mostly running in scripting land.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Mon Oct 14, 2013 12:23 pm

galvedro wrote in Mon Oct 14, 2013 9:31 am:I was planning on releasing a first "drop" quite soon with the basic stuff in place and perhaps refactoring existing glider cockpits to make use of the library (if you find it appropriate). That would resolve some issues with existing implementations and add total energy compensated variometers to gliders that don't have them. But I am not sure if I should address those other "core framework" limitations before a first delivery. What do you think is best?

Like you say, releasing something now for some form of peer-review seems like a good idea, also to allow early-adopters to give it a try - you might be lucky so that Philosopher can also look over your code and provide some additional feedback

From a performance standpoint, there's actually little need to have our existing instruments hardcoded in C++

I think Nasal performance is definitively not an issue for the instruments in a glider cockpit, and possibly neither is for light aircraft. The main update loop running the configuration shown above runs in about 40us in my computer. That is about 0.1% of the framerate I get. But I am not sure what the impact would be in a full fledged cockpit like the A-10 for example, if it was mostly running in scripting land.


Depending on the type of coding, and size of data structures, certain coding patterns are a bit problematic and may unnecessarily increase garbage collection (GC) pressure - but that's also something that Philosopher can comment on - at your current stage, you are unlikely to hit anything related to this - it's just worthwhile to keep in mind because there are usually dozens of other Nasal scripts running interleaved with your own code, via timers and listeners (callbacks) - so that there's never a single script running, and there are quite a number of scripts that were developed by people who learned programming via FlightGear, i.e. who didn't have any formal programming training - so that performance may sometimes suffer a bit, without people being aware of it - looking at your code, you seem to have previous programming experience, so I wouldn't be overly worried.
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: Glider instrumentation

Postby Philosopher » Mon Oct 14, 2013 1:49 pm

A "serviceable" property is most used to switch failures on/off; i.e. something like props.globals.initNode("instrumentation/.../serviceable", 1, "BOOL")
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Glider instrumentation

Postby Hooray » Mon Oct 14, 2013 3:25 pm

yes, that used to be pretty common in the steam gauge days, I am just not sure if it's sufficiently fine grained, given that there are possible failure scenarios that are not just black/white or on/off
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: Glider instrumentation

Postby galvedro » Thu Oct 17, 2013 8:16 am

I have started to integrate the library with the existing instruments and cockpits. While I was at it, I took the opportunity to complete the SC7 vario implementation by adding temperature reading and a fake battery level indication. The final script driving the instrument (excluding property initialization and listener setup for switches and sim signals) looks like this now:

Code: Select all
var probe = TotalEnergyProbe.new();

var sc7_needle = Dampener.new(
   input: probe,
   dampening: 3,
   on_update: update_prop("/instrumentation/ilec-sc7/te-reading-mps"));

var extra_needle = Dampener.new(
   input: probe,
   dampening: 2.7,
   on_update: update_prop("/instrumentation/variometer/te-reading-mps"));

var averager = Averager.new(
   input: probe,
   size: 25);

var battery_level = { output: 9.9 };

var temperature = PropertyReader.new(
   property: "/environment/temperature-degc",
   scale: 0.1);

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

# Wrap everything together into an instrument
var instrument = SoaringInstrument.new(
   fast_update_components: [probe, sc7_needle, extra_needle],
   slow_update_components: [averager, temperature, lcd_controller]);

# Go!
instrument.enable();


I added an extra needle to the SC7 because this instrument will almost always be installed together with a mechanical vario, so by providing an extra hook we avoid having to load a another script for driving the secondary vario.

Now I am facing the problem of how to load the library. So far, I have been placing it under Aircraft/Generic, and manually including it in the in the nasal section of the aircraft-set.xml file. But that was a quite hackish way of doing it.

If I understood the doc correctly, if I place the library under /Nasal, then it will be available right away. But that is not really what I want, as most aircraft will not use the library so it is not reasonable to load it every time.

I have seen that nasal supports an import directive (https://github.com/andyross/nasal/blob/master/lib/driver.nas). But I was unable to make it work yesterday in FG 2.12 (tried with import(...) and driver.import(...)). Is this supported somehow?

And finally, I have also seen that Philosoher is working on a "require()" directive that goes in this direction as well. So I am a bit confused :D What would be the preferred way of loading a nasal library on demand from an instrument (i.e. rather than from the aircraft)?
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Philosopher » Thu Oct 17, 2013 1:01 pm

Haha, how'd you get the AndyRoss repo? The src directory is what SimGear's Nasal used to look like, but everything else hasn't been included in FlightGear. :D

And yeah, the require is a work in progress (also needs C++ changes, so not for most people). In other words, what you're doing currently (including it in the aircraft Nasal section) is what works currently :(.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Glider instrumentation

Postby Hooray » Thu Oct 17, 2013 3:02 pm

But that is not really what I want, as most aircraft will not use the library so it is not reasonable to load it every time.

you can use this to dynamically load modules on demand:

https://gitorious.org/fg/fgdata/source/ ... io.nas#L12
Code: Select all
io.load_nasal(filename);
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

Next

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 2 guests