galvedro wrote in Tue Nov 05, 2013 9:33 am:The more I think about it, the more I am leaning towards unifying the different system modeling blocks in the C++ core under a generic interface that is exposed (or linked in some way) to Nasal. Think the PID controller, the different filters, flip-flops, etc. They are not substantially different to the basic bricks I am writing...
Note that "static XML" isn't all that static in the cause of the AP system - it makes heavy use of so called "Tied Properties", which are basically "live" properties, properties linked to C++ variable. The more modern, and more future-proof approach is using so called SGPropertyChangeListener or so called "PropertyObjects"- which is basically a C++ template class that may subscribe to property tree events and which gets called subsequently to update internal state - you'll find that this is used by subsystems like the AP or the AI Traffic system: there's sort of an API modeled on top of properties and the property tree - which is why the configuration may be considered "static", but it's often using "live" properties and therefore pretty dynamic.
The appealing thing here is that the API is automatically exposed to all property frontends - not just Nasal scripting via setprop/getprop etc - but also the property browser, the built-in httpd daemon - but also the telnet/props server, which makes it possible to "remote-control" FlightGear in an RPC fashion.
The canvas system makes extensive use of these listeners for modeling a whole 2D drawing API on top of the property tree
The basic idea would be to detach those blocks from their specific application (autopilot, for example) and refactor them into an independent library with bindings in Nasal and a similar interface to what I have been showing so far. The end result would be quite simulinkish in flavour. It is already starting to smell a bit to that actually...
An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal. Sounds too ambitious?
Yeah, it does sound ambitious - not necessarily too ambitious though. You would obviously need to be able to build FG from source, because that would no longer touch "just" Nasal code.
A while ago, Philosopher also suggested something along these lines, he came up with the idea to implement SimGear's SGSubsystem class as a Nasal/cppbind binding, so that FGData/Nasal contributors would ideally follow the SGSubsystem approach and implement the required interfaces/methods (analogous to C++ devs) - what we're currently seeing is lots of listeners and timers being used instead to implement "pseudo subsystems" in Nasal, which is not too easy to control in terms of certain simulator events (restart, suspend, reset/re-init etc).
It would seem possible to generalize the SGSubsystem/SGChangePropertyListener approach such that subsystems would also expose scripting bindings (optionally).
Originally, SGSubsystem was intended to be the common interface for all subsystems, but that was over a decade ago - we still have a bunch of subsystems that don't really use it.
http://docs.freeflightsim.org/simgear/c ... ystem.htmlhttp://simgear.sourceforge.net/doxygen/ ... ystem.htmlIn the meantime, it would indeed be possible to expose such FG/SG building blocks thanks to TheTom's cppbind framework, which is to be found in simgear/nasal/cppbind:
https://gitorious.org/fg/simgear/source ... al/cppbindTom's cppbind framework makes heavy use of modern C++, so that C++ data structures and classes/methods can now be easily exposed to Nasal space and vice versa.
Implementation examples are to be found in $FG_SRC/Scripting:
https://gitorious.org/fg/flightgear/sou ... /ScriptingFor example, see the most recent addition, which is exposing SimGear's HTTP client code to Nasal space with less than 140 lines of code:
https://gitorious.org/fg/flightgear/sou ... alHTTP.cxxThere's still plenty of "old" code that doesn't yet use the cppbind framework - check the header inclusions at the top of the file.
Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal,
just to prevent scripters from implementing APs in Nasal (due to garbage collection issues) - so that should be a no-brainer actually, and such work should be appreciated:
Subject: 2 Questions: vacuum & electricalTorsten wrote:I think, performance of Nasal code and XML based property rules is pretty close. The big advantage of the property rules is that they don't produce garbage that a garbage collector has to clean up. But as nothing in life comes for free (except FlightGear, of course) XML tends to be much more verbose - as you correctly stated.
My personal guideline for using one or the other system is:
- Computing properties from a well defined set of other properties once per frame: use a property rule.
- If there is no other way to get it done: use Nasal.
Great minds think alike. I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind. This _might_ end up in something like
- Code: Select all
var myPid = pidController.new();
myPid.Td = 0.0001;
myPid.Ti = 123.4;
myPid.Kp = 0.2;
myPid.input = "/foo";
myPid.reference = "/bar";
myPid.output = "/baz";
etc, etc.
But that's probably a little off topic now.