Board index FlightGear Development Aircraft Autopilot and route manager

Actual programming language for autopilot implementation?

Designing a stable autopilot is one of the hardest things. Need help?

Re: Actual programming language for autopilot implementation

Postby Hooray » Tue Aug 28, 2012 11:42 pm

Yes, it's just a conventional property - see /sim/signals/* in the property tree - i.e. fgSetBool() - so that a standard Nasal listener can be attached, which will then be fired automatically - so that the corresponding Nasal callback gets called: http://gitorious.org/fg/flightgear/blob ... xx#line717

Note that this would mean that the Nasal callback will get invoked for each iteration of the FDM loop, without introducing another event systems - but via the props system.
My original solution would have the advantage that the execution time of all FDM-coupled callbacks can be more easily tracked, i.e. via the performance monitor
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: 11925
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby flameout » Wed Aug 29, 2012 4:09 am

Alternatively, as a short-term solution that does not rely on editing C++ code, you could just trigger off an internal autopilot property... :wink:

Perhaps we could set up a trigger that is fired by the Autopilot subsystem, immediately before the autopilot executes. However, someone more familiar with FG's code base than me can probably come up with a more elegant solution. I feel like adding a new events system and a parameter to settimer is cleaner than a signal -- and that if a signal is added, the Autopilot subsystem is probably not the place to add it.

Perhaps I should bring this up on the development mailing list? This seems like it has come up before.

Thank you for all your help,
Johnathan Van Why
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Re: Actual programming language for autopilot implementation

Postby Hooray » Wed Aug 29, 2012 10:24 am

Hey, yes: That's also pretty clever: trigger a boolean property for each iteration, so that the Nasal listener can pick it up.
However, you will need to make sure that the AP code doesn't use a tied property here - otherwise, the listener won't work.
The problem is that there's still tons of code in FG which makes use of tying - which is incompatible with many other system, such as property listeners: http://wiki.flightgear.org/Howto:Use_Pr ... ee_Objects

Feel free to bring it up on the devel list, especially if you want this to be added to the main repository - we have 2-3 different solutions here, including a patch.
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: 11925
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby zakalawe » Wed Aug 29, 2012 1:18 pm

Just as an observation - another possibility is to extend the declarative expression logic, which is already supported by the autopilot components, to allow a Nasal expression. Then you mix the declarative components (which you're going to want for most autopilot laws) with some scripted ones.

Since the expression evaluation would be driven by the autopilot subsystem, it would run at whatever frame-rate that itself runs at - which is currently in lock-step with the FDM.

This would also work with tied properties, although they should still be killed off, for the reasons Hooray mentioned.
zakalawe
 
Posts: 1161
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Actual programming language for autopilot implementation

Postby Hooray » Wed Aug 29, 2012 2:36 pm

Yes, being able to directly add Nasal code sections to autopilot XML files would be pretty cool.

On the other hand, there are many non-obvious issues and relationships to consider here:
I do know for a fact that a number of core developers are currently opposed to adding more Nasal code to the main loop, until the Nasal/GC issues are resolved. And this probably applies even moreso to code that isn't "just" run at frame rate, but even at FDM rate? Even if it's just hooks?

So this raises a number of issues, many of which aren't directly related to the AP system, but to Nasal and to the way Nasal support is currently added to subsystems, and to the way C++ subsystems are exposed to Nasal.

I mean, both, Torsten and ThorstenB have previously stated that they are opposed to adding even more Nasal code (and hooks) for these very reasons.
Thus, I am not sure if Torsten in particular (given that he's the primary AP developer and maintainer) likes the idea?
And obviously, we don't want Nasal to have a negative effect on the FDM at all.

I have been experimenting with the additional "fdm-events" (fdm coupled) subsystem, and it's working fine here - and while it may obviously trigger Nasal code (including the GC!), this also means that the GC gets to run more frequently, i.e. at simulation/fdm rate, rather than just at frame rate.

Furthermore, it is worth noting that Torsten was going to expose the AP system to scripting space anyhow, via a dedicated Nasal interface - which he mentioned a while ago: viewtopic.php?f=66&t=15189&p=149369&hilit=property+rules+torsten#p149376

Now, regarding the GC, I am a little familiar with the internals (after having documented it here), and I think it would be possible to ensure that there's enough free space available in all pools for most needs, so that the mark/sweep phase could be postponed when running an FDM-coupled callback, so that the GC shouldn't get triggered when running an FDM-coupled callback.

In general, there's an increasing trend to support embedded Nasal blocks in PropertyList-encoded XML files, which is good, but there's a fair amount of duplicate code already, because this is always individually implemented, without sharing any code. The same goes for all the recently added hooks to expose FG/C++ objects to Nasal.

I have been talking to Tom (Canvas developer) on adding an OOP interface to SimGear for SGSubsystem and other C++ objects that should be exposed to Nasal space, so that this would be mostly about implementing an abstract interface with some template<> magic to create Nasal ghosts and a bunch of helper methods automatically for FG/SG objects that should be accessible from Nasal space.

Having a single OOP interface for such objects would also make it easier for us to ensure that we stop adding "raw" extension functions, and instead add full "objects" instead, which can compute their results lazily: http://wiki.flightgear.org/Howto:Extend ... 8ghosts.29

Currently, this is also the only sane option for us to provide runtime-dependency resolution for Nasal scripts that depend on certain subsystems, which is what makes the whole FGCanvas idea pretty tricky at the moment.

At the moment, all the helpers in NasalPositioned and NasalCanvas are deliberately made static, so there's tons of duplicate code which could be generalized and turned into an OOP wrapper: http://wiki.flightgear.org/Howto:Extend ... al_objects

Likewise, we could add an interface for subsystems that parse PropertyList-encoded files and which need to support embedded Nasal blocks, there are already various places where this is done, and it would definitely be a good idea to unify this.

If that's really what we want to do, then it's also worth noting that there's a SWIG module for Nasal available, which could be updated and used to create parts of the OOP wrapper automatically: http://members.tripod.com/gaku_n/swig-nasal/
SWIG is well-supported by cmake, so that it could be a real time-saver.

Please feel free to use/adapt/modify the code that I have posted, but to be honest, I feel that this is really more about "software engineering" and "design", rather than about "programming" and implementing this particular feature.

The real problem is that Nasal is currently not maintained, so that it's easy to keep adding lots of "workarounds", even though what's really needed is an improved design to unify Nasal<->C++ interfacing, so that Nasal code can be more easily run and used by C++ systems, and so that C++ objects can be more easily exposed to Nasal. This is one of those situations where having the input from Melchior Franz or even Andy Ross would definitely be very helpful.
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: 11925
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 1 guest