FIX 717 AND A320 AUTOPILOTS!!!

[Hooray]

Ideally this would be done in the C++ code that drives the route manager, or using property rules in the autopilot. It is possible to do it in Nasal, and I have a script that does so, but I was told, rightly so, that a general Nasal sclution would not be accepted into FGDATA because of garbage collection issues with Nasal running so intensively. Many aircraft do it this way, however.

I don't know who you were talking to - but the main issue is running FDM/AP-coupled Nasal code, because that may trigger the Nasal GC several times per frame possibly, while it can currently only be triggered once per frame (well, in theory).

In general, the idea is to use C++ delegates so that performance-critical stuff takes place in C++ space - and once you look at the code in question, you will see that this is pretty much what it is doing already. So it would be straightforward to map the control logic to Nasal space, so that Nasal would never be running the logic, but just control the undelying "mode" to be used - which could be implemented in AP/RM space, but also via property rules.

The real issue here is not so much that Nasal's GC scheme sucks big time, but that we have much better systems available in C++ space, which are simply not properly exposed to scripting space - so that aircraft developers tend to come up with all sorts of ugly workarounds, that reflect badly upon Nasal, its GC and fgfs as a whole.

If the people involved in the AP/property rule and RM subsystems spent less time complaining about the Nasal GC and its issues, and instead focused on exposing this to property tree space, the whole issue would be solved once and for all, because Nasal would only ever be used to configure/switch modes and control logic, but never run any performance critical code at frame rate, let alone, FDM rate.

For some context, I suggest to look at what others have previously stated in this particular context, especially core developers (Torsten:autopilot/property rules and James: route-manager/Nasal delegates), and those doing related work:

Subject: 2 Questions: vacuum & electrical

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.

especially if these configurations could be instantiated at run time

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.

http://flightgear.org/forums/viewtopic. ... 99#p128052

One thing I would add is that the existing waypoints don't seem to contain enough information, I've written some more Nasal classes to handle SID/STAR/IAP, Top of Climb and Top of Descent pseudo waypoints and Altitude constraints versus FMS calculated altitudes etc.

Right, and that's the next question - I don't want to hard-code that kind of logic in C++, if I can avoid it - but we need to work out a way for Nasal to set the values into the route-manager or GPS data, so the ND can pick it up - especially all the cruise/phase-of-flight/altitude/energy stuff. I apologise for being lazy, but can you remind me where the relevant Nasal code is? Then we can have a discussion (possibly involving some other people) about which parts can be in C++, and some standard locations the ND can look for Nasal-computed value, and so on.

Subject: Route manager leg modes

Personally, I am not convinced that we should continue with a hard-coded route manager, implemented in C++, at all - especially given that quite a few aircraft have begun implementing their own scripted variants - in the mid term, I would hope that there's simply a RM infrastructure in place that can be augmented via Nasal delegates (e.g. via cppbind). The route manager currently being a singleton "by accident" is another unnecessary issue, that is preventing people from using it elsewhere (e.g. for AI traffic).

Subject: Route manager leg modes

Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.
A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.
As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage.

Thus, the real problem is not Nasal or its GC, but it is existing C++ code that is simply not exposed to Nasal space, so that aircraft developers have to reinvent the wheel.

And in all fairness, the most recent memory leak (and segfault!) was route manager/routePath related, and it could have never happened in Nasal space - simply due to it using a GC.

[sanhozay]

I don't know who you were talking to - but the main issue is running FDM/AP-coupled Nasal code, because that may trigger the Nasal GC several times per frame possibly, while it can currently only be triggered once per frame (well, in theory)

...

the real problem is not Nasal or its GC, but it is existing C++ code that is simply not exposed to Nasal space, so that aircraft developers have to reinvent the wheel.

It was Zakalawe. Looking back, I may have misunderstood the reasoning behind the reluctance to consider to a generic Nasal script as a waypoint switcher. It was probably a result of not reading the last sentence of:

Whenever possible, please refrain from modeling complex systems, like a FDM, autopilot or route manager in Nasal space, this is primarily to help reduce Nasal/scripting overhead (especially GC overhead), as well as to help increasingly unify related features to avoid duplicate code. In particular, this applies to FDM-rate coupled code/features.

http://wiki.flightgear.org/Howto:Design_an_autopilot

[Hooray]

That's irony at work: I added that disclaimer all over the place, specifically to discourage people from implementing custom FDMs/APs and route managers in scripting space
Anyway, like you mentioned, this is already common-place practice in various aircraft/hangars, simply because the underlying building blocks are not at all exposed to scripting space - so there really are only two options 1) writing such systems in Nasal, and 2) modifying the C++ code accordingly.
Given the barrier to entry/steep learning curve involved in patching/building SG/FG, it is understandable that aircraft developers opt to use Nasal, no matter how unfortunate it is to write a AP/RM system from scratch.

Sooner or later this stuff will need to be exposed to scripting space, because it simply does not make sense to reinvent the wheel whenever somebody wants to do these things - we are also seeing this in Red Leader's scriptable AI missiles effort: people need ways to have AI traffic with FDMs, APs and route manager functionality - so unless existing systems are exposed accordingly, people are going to continue using Nasal to implement such systems, instead of leveraging existing code, which is going to reflect badly upon Nasal obviously, for all the right reasons that Torsten once mentioned:



http://sourceforge.net/p/flightgear/mai ... /15645373/

Setting up a development system is not a big deal
(even I managed to do it, so anybody else should be able to) but its not that
easy to get your changes into the system.
I am not complaining about this and I acknowledge that changing the internal
program is a thing that has to be carefully reviewed. Writing some Nasal code
usually does not affect the whole system and can be maintained for a single
aircraft.

[Octal450]

I did a little work on the 717 autopilot, and that is up