Board index FlightGear Development Aircraft Systems

A general approach to systems modeling in Nasal

Modeling aircraft systems, like electrical stuff, hydraulics, pneumatics? Feel free to ask support.

Re: A general approach to systems modeling in Nasal

Postby Hooray » Fri Nov 08, 2013 11:44 am

I'm all for building a repository of regression tests, especially if we could add it to $FG_ROOT/Nasal.tests and process it while booting, i.e. prior to loading $FG_ROOT/Nasal - hopefully, as part of your bootstrapper script. Icecode used this in FGRadar to run all of Andy's original tests prior to finishing intialization.
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: A general approach to systems modeling in Nasal

Postby dede » Fri Nov 08, 2013 2:38 pm

Hello

About the Electrical System, I'm trying to complete a NASAL generic program for "complex" aircraft (several bus-bar, converters, bus tie, etc...).
The main idea is to have a "clean" electrical program with several possibilities (failures, reconfiguration, ...). This will be also able to compute volts, amps, frequency... and manage circuit breakers / consumers (the objectives are to manage a complex aircraft such as Concorde, B747-200,...). But the main objective is to used it for one of the real Concorde Simulator (set in Toulouse - http://assovirtuailes.free.fr, if you want to help us, you're welcome ;) )
I do it in NASAL because it was simple to write, but if the idea (algorithm) is functional, it could be set in C/C++ in Flightgear for a clean integration.

Today, it seems functional for the volts computation, the electrical generation (CSD, IDG, Battery, alternator,...) and switching (several type of switching components are managed). I have some trouble with the amps computation. It is, on the paper, not a difficult problem but on a complex system I experiment some difficulties... (I test it on the Concorde Electrical System beacause I have a full documentation... not so simple :roll: )

The input will be an XML file for the electrical circuit definition, but a complementary NASAL program is mandatory in order to clearly define reconfiguration rules, specific to each aircraft.
I try to avoid, as far as possible, call to getprop / setprop functions in order to save computer time. I need to find a way to manage properly and quickly more than one hundred of electrical consumers and circuit breakers... (not critical but we have it in the simulator so it could be good to use it...)

I hope that next week I will be able to share the files with you... (unfortunately, I start the program two weeks before the current initial post and I didn't have an Internet link during several weeks - yes, some places do not have a network connection... so I do my job in a standalone mode).

About the performance, by using the debug nasal tool, it took 0.01s to 0.1s to compute an electrical status (1 time per second) but I compute only the busbar volts, frequency and amps.
This is on my "old computer" (6 years old AMD Athlon 2400).
I use the hash / object capabilities and reduce the computation loops with the helps of the tree / graph algorithm and theory.
Last edited by dede on Fri Nov 08, 2013 2:52 pm, edited 1 time in total.
dede
 
Posts: 30
Joined: Sun Aug 11, 2013 10:56 am
Location: Toulouse
Version: 2.10
OS: Linux

Re: A general approach to systems modeling in Nasal

Postby Hooray » Fri Nov 08, 2013 2:52 pm

@dede, that sounds all very interesting, good thing you posted here !
I'm sure we'd all love to see some code examples to better understand everything.
Nasal can certainly be used for prototyping such a thing - performance-wise, you'll want to avoid some constructs however.
On the other hand, it should be possible to use built-in C++ modules and expose those to Nasal, like galvedro mentioned.
BTW: As long as you strictly avoid calls to Nasal's FG APIs (extension functions) you can definitely use threads for multiple concurrent consumers.
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: A general approach to systems modeling in Nasal

Postby Johan G » Fri Nov 08, 2013 4:52 pm

A project that is similar in that it tries to interface avionics and instruments is The L-1011 Project which is documented in a blog. You might find it interesting, though one has to wade through a lot of posts to find what one is looking for at times. I tend to drop in there once in a while, though often more or less unintentional while doing Google image searches. :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: A general approach to systems modeling in Nasal

Postby Hooray » Fri Nov 08, 2013 5:11 pm

I suggest to use FlightGear's XML processing facilities in io.nas - normally, a PropertyList-encoded file should suffice. However, I can see how this could become VERY verbose to express complex systems - so you may want to use "full" XML (including attributes) instead, especially to express graphs - FG's PropertyList subset is probably a bit too wasteful for any non-trivial circuit. Depending on existing standards, we could even support those - there's a plethora of XML formats for expressing graphs for different purposes, writing a Nasal parser should be pretty straightforward and would save us from having to re-invent the wheel.
Also, we do have the possibility to run Nasal in a standalone fashion, without FG - so if you should have a need for this, i.e. for rapid prototyping (but also for testing on less-powerful hardware), we can walk you through the specifics. At the moment, everything is in a slightly modified SimGear branch - but we've been wanting to add this to FG anyways. Depending on your OS, we even have a precompiled Nasal-standalone binary.

The standalone interpreter doesn't current support any FG APIs, including getprop/setprop etc - so you really HAVE to use native Nasal data structures, but you can still use threading.
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: A general approach to systems modeling in Nasal

Postby dede » Fri Nov 08, 2013 5:29 pm

Johan G wrote in Fri Nov 08, 2013 4:52 pm:A project that is similar in that it tries to interface avionics and instruments is The L-1011 Project which is documented in a blog. You might find it interesting, though one has to wade through a lot of posts to find what one is looking for at times. I tend to drop in there once in a while, though often more or less unintentional while doing Google image searches. :wink:



I love it :) Thanks

I will contact them !
Even if we do not have the same aircraft we can share some data and technical solution. :)
dede
 
Posts: 30
Joined: Sun Aug 11, 2013 10:56 am
Location: Toulouse
Version: 2.10
OS: Linux

Re: A general approach to systems modeling in Nasal

Postby galvedro » Sat Nov 09, 2013 7:02 pm

Philosopher wrote in Fri Nov 08, 2013 4:59 am:Sounds like more than two sig digs to me! ;) Excellent reasearch, how long does it take to run the tests, and is it one single script?


Yeah, it's a very simple script. I wrote it on the Nasal console directly just to get a rough idea on relative nasal struct performance. This one runs in about 5 sec in my Linux box:

Code: Select all
var vector = [25, 25, 25];
var time0 = systime();
var i = 0;
var out = 0;

for (i = 0; i < 10000000; i += 1)
  out = 25;

var time1 = systime();

for (i = 0; i < 10000000; i += 1)
  out = vector[1};

var time2 = systime();

print("vector / const = ", (time2 - time1)/(time1 - time0));


And now that I am posting, here is another modeling experiment replicating the builtin vacuum system.

Code: Select all
var suction = func (rpm, pressure) {
    # This magic formula yields about 4 inhg at 700 rpm
    var suction = pressure * rpm / (rpm + 4875.0);

    # simple regulator model that clamps smoothly to about 5 inhg
    # over a normal rpm range
    var max = (rpm > 0 ? 5.39 - 1.0 / (rpm * 0.00111) : 0);
    if (suction < 0.0) suction = 0.0;
    if (suction > max) suction = max;
   
    return suction;
};


var rpm1 = PropertyReader.new("/engines/left/rpm");
var rpm2 = PropertyReader.new("/engines/right/rpm");
var pressure = PropertyReader.new("/environment/pressure-inhg");

# Select the source with higher rpm
var rpm_source = MaxInput.new(
    inputs: [rpm1, rpm2]);

var sys_suction = CustomFunction.new(
    inputs: [rpm_source, pressure],
    function: suction,
    on_update: update_prop("/systems/vacuum/suction-inhg"));

var vacuum_system = UpdateLoop.new(
    components: [rpm1, rpm2, rpm_source, sys_suction]);

setlistener("/systems/static/serviceable",
    func (prop) { rpm_source.scale = prop.getValue()? 1 : 0 });
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: A general approach to systems modeling in Nasal

Postby Johan G » Sun Nov 10, 2013 12:07 am

dede wrote in Fri Nov 08, 2013 5:29 pm:I love it :) Thanks

You are welcome! :D
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: A general approach to systems modeling in Nasal

Postby Hooray » Wed Nov 13, 2013 2:48 pm

galvedro wrote in Tue Nov 05, 2013 1:53 pm:Yes, sure! I have managed to get my development environment up at home, and I am now able to build FG again. I think what I am going to do is to grow a little library in a sandbox (i.e. not interacting with the main code) by borrowing exiting components, and do some experiments with the cppbind framework. I have seen the cppbind code, and it looks really nice indeed!


I have started documenting cppbind for people new to it, C++ familiarity is obviouly required, as is building FG from source - but otherwise, it should be suitable to get people started who don't know much about SG/FG internals. I'm hoping to extend this over time to add more sophisticated examples (with lots of annotations), I'm sure that Philosopher, Zakalawe and TheTom are going to chime in at some point and correct any mistakes I made so far - on the other hand, you're also welcome to contribute obviously :lol:

You'll find the stub at: http://wiki.flightgear.org/Nasal/CppBind
The idea is just to get this started and add to it as required.
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: A general approach to systems modeling in Nasal

Postby Philosopher » Thu Nov 14, 2013 3:45 am

Personally I find CppBind to look particularly ugly; may I suggest C++Bind instead? Obviously Tom can choose what he wants, but seriously, has anyone else referenced it as something other than the directory name? I think I've used C++Bind privately before, and C++bind looks ok too.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: A general approach to systems modeling in Nasal

Postby Hooray » Sat Nov 16, 2013 3:30 am

I think it's to come up with a valid multi-platform file/directory name in the first place, and probably also a valid URL - not sure how well the wiki deals with "C++Bind" in the URL, we already have some unreadable/ugly URLs because of such issues. And I really don't mind it - for the sake of consistency it makes sense to keep referring to CppBind in my opinion - in fact, one could argue that I was already being adventurous by adding capital characters :lol:
Then again, I think the wiki will by default make the first character a capital

And for the sake of accessibility, I'll probably keep on referring to "cppbind" either way, simply because I do know that most search forms (forum, mailing list archives, wiki) do not respond all too well to characters like ++
Using forum/wiki/list search breaks often enough already when looking for source code, which tends to include such characters. So, I'd rather not make matters more complicated than necessary.
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: A general approach to systems modeling in Nasal

Postby Johan G » Sun Nov 17, 2013 12:05 am

Regarding the wiki I have worked on it a bit more intense lately. Some of the things I want to do something about is the documentation for new wiki users, one of them being recommendations for page titles. Some names simply can not be used without breaking the page entirely. Such things would be great to have documented in say Help:Your first article (which by the way says absolutely nil about the wiki markup, and mentions how to create an article only in the last three sentences :wink: ).

Hooray wrote in Sat Nov 16, 2013 3:30 am:And for the sake of accessibility, I'll probably keep on referring to "cppbind" either way, simply because I do know that most search forms (forum, mailing list archives, wiki) do not respond all too well to characters like ++
Using forum/wiki/list search breaks often enough already when looking for source code, which tends to include such characters.

I like the way you are thinking here. Search engine optimisation (SEO) can at times be a really good thing. It is sometimes really hard to find what one is searching for. I often try to think about how useful (and findable) the things I am writing will be in a few years, as well as connecting similar content by linking to older relevant posts and wiki pages (though I maybe should use permalinks more often when linking to the wiki).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: A general approach to systems modeling in Nasal

Postby galvedro » Wed Nov 20, 2013 8:24 pm

Hi!

I have made a change to the design that I think leads to a more generic and extensible architecture.

One think I wanted to achieve was a uniform interface that allowed some kind of "grouping" mechanism, so you could build a system out of library components and then reuse that system as it was a library component itself. I think that is a good approach to managing complexity, and it is something that was missing in the first design.

Another flaw of the previous design was that connectivity between components was quite limited. Components could only have one output named "output", and inputs where other components provided at object construction or properties read internally.

The new design introduces the concept of IO Ports and a library function connect(output, input) that operates on them. IO Ports come in two flavours: InputPorts and OutputPorts. They are Nasal objects themselves that you can add to a component and provide the mechanisms required for connectivity.

With these new elements, a system Component becomes an object that:

    + Has any number of input / output ports
    + Implements a reset() method that initializes or restores internal state
    + Implements an update(dt) method that performs one step computation
So now we can build a complex system by connecting components, and make this system itself a reusable component by providing the appropriate IO ports and the reset() and update() methods. And additionally, the design does not impose any limitation on component inputs and outputs.

The connect() function is kind of "intelligent", and allows you to connect, not only IO ports, but also properties and constants, making it rather intuitive to use. For example:

Code: Select all
var gain = Gain.new(2);
var filter = Dampener.new(dampening: 3);

connect("/environment/temperature-degc", gain.input);
connect(gain.output, filter.input);
connect(filter.output, "/instrumentation/my-instrument/my-property");


This design makes it possible to support a couple of things that Horray suggested at the beginning of this thread: a unit system and a debug system.

Because components now use full fledged objects for communication, those objects can certainly have properties (i.e. units), and could also hold compatibility rules to decide which ports can be connected together. I am not convinced that a unit system is a good idea, but that doesn't mean that the design can't be made good enough to support it. :D

And finally, this new connectivity scheme makes it possible to define feedback loops, something that it was not possible before, as all inputs to a Component had to be provided from objects that where already instantiated. Now, you create the components, and then define the connections as you like. Easy peasy!

I have pushed the code to gitorious if you'd like to have a look. :wink:
EDIT: https://gitorious.org/fg/galvedros-fgda ... ic/Systems
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: A general approach to systems modeling in Nasal

Postby Hooray » Thu Nov 21, 2013 3:59 am

Apologies for not getting back to this earlier, we're currently all kinda busy with some other things (such as the 744 ND, MapStructure.nas etc) - or the recent osgEarth...quake :lol:
That all sounds and looks very exciting, I already followed your latest commits prior to you posting an update here.

I suggest to copy your last posting over to the wiki, so that we can turn it into an "implementation guide" or some simple form of tutorial, so that people (aircraft developers) can refer to it to learn how to implement new systems using your framework, we can probably adapt your existing code and use it as examples.

This isn't touching any existing stuff, so the code review should be pretty straightforward - if you're hoping to see this included in 3.0, it might still be a good idea to file an "official" merge request, so that someone feels responsible to take a look (at some point) :D

From a quality point of view this is cleaner than 95% of the Nasal code we already have in FG_ROOT :)
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: A general approach to systems modeling in Nasal

Postby Johan G » Thu Nov 21, 2013 10:23 am

galvedro wrote in Wed Nov 20, 2013 8:24 pm:The connect() function is kind of "intelligent", and allows you to connect, not only IO ports, but also properties and constants, making it rather intuitive to use. For example:

Code: Select all
var gain = Gain.new(2);
var filter = Dampener.new(dampening: 3);

connect("/environment/temperature-degc", gain.input);
connect(gain.output, filter.input);
connect(filter.output, "/instrumentation/my-instrument/my-property");

...

Now, you create the components, and then define the connections as you like. Easy peasy!


That looks clean enough that even I could follow what's going on. :wink: :lol: Keep it coming. :D
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

PreviousNext

Return to Systems

Who is online

Users browsing this forum: No registered users and 1 guest