20,741
edits
Using listeners and signals with Nasal: Difference between revisions
Jump to navigation
Jump to search
Using listeners and signals with Nasal (view source)
Revision as of 20:02, 19 May 2013
, 19 May 2013→Nasal code coupled to the autopilot system: http://flightgear.org/forums/viewtopic.php?f=66&t=15189&p=149376&hilit=#p149376
(→Nasal code coupled to the autopilot system: http://flightgear.org/forums/viewtopic.php?f=66&t=15189&p=149376&hilit=#p149376) |
|||
| Line 193: | Line 193: | ||
=== Nasal code coupled to the autopilot system === | === Nasal code coupled to the autopilot system === | ||
Some people have a need to run Nasal code at the same rate as the simulation/FDM. Currently, without modifying the source code for FlightGear, the only way to do this is to find a property updated at the right time in the simulation cycle and set a listener on it. From a code quality standpoint, this is less than ideal. | |||
Autopilot rules, FDM and important instruments run at fixed rate of 120Hz and are already _independant_ of frame rate (Note: this does not help those who try to implement APs manually using Nasal, since Nasal can only run at frame rate. But please do use the "autopilot property rule" system for the fast control part of the autopilot - and only do slow stuff in Nasal (such as switching between autopilot modes), which does not require a close coupling to the FDM/autopilot. The 777 is a good example showing this: dynamic part of AP is done by property rules; switching between AP modes, like "hold glideslope" => "flare" is done in Nasal). | Autopilot rules, FDM and important instruments run at fixed rate of 120Hz and are already _independant_ of frame rate (Note: this does not help those who try to implement APs manually using Nasal, since Nasal can only run at frame rate. But please do use the "autopilot property rule" system for the fast control part of the autopilot - and only do slow stuff in Nasal (such as switching between autopilot modes), which does not require a close coupling to the FDM/autopilot. The 777 is a good example showing this: dynamic part of AP is done by property rules; switching between AP modes, like "hold glideslope" => "flare" is done in Nasal). | ||
| Line 209: | Line 212: | ||
asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of | asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of | ||
non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems. | non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems. | ||
Some FDM stuff would like to be tied to the FDM update rate, and that's a desirable goal. What about a callback function then? The FDM subsystem would set /sim/signals/fdm-update, and you could attach a listener to that which does all the things that should interact with the FDM, such as AP, FCS, etc. The rest of Nasal would keep running with the frame rate. | Some FDM stuff would like to be tied to the FDM update rate, and that's a desirable goal. What about a callback function then? The FDM subsystem would set /sim/signals/fdm-update, and you could attach a listener to that which does all the things that should interact with the FDM, such as AP, FCS, etc. The rest of Nasal would keep running with the frame rate. | ||
| Line 232: | Line 232: | ||
You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS). There are some nice examples with fgdata/Git aircraft. You could look at the 777. | You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS). There are some nice examples with fgdata/Git aircraft. You could look at the 777. | ||
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. | |||
Guideline | |||
* 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. | |||
This is also how such things are done in the real world: controllers aren't implemented in imperative programming languages these days - especially not in scripting languages. People use model-based design and connect controller elements - using graphical tools like MATLAB/Simulink. Obviously, FG is missing a graphical interface to specify the controller rules - but the idea of specifying through XML is the same and specification is straight forward. | This is also how such things are done in the real world: controllers aren't implemented in imperative programming languages these days - especially not in scripting languages. People use model-based design and connect controller elements - using graphical tools like MATLAB/Simulink. Obviously, FG is missing a graphical interface to specify the controller rules - but the idea of specifying through XML is the same and specification is straight forward. | ||