20,741
edits
Using listeners and signals with Nasal: Difference between revisions
Jump to navigation
Jump to search
m
Using listeners and signals with Nasal (view source)
Revision as of 19:44, 19 May 2013
, 19 May 2013→Nasal code coupled to the autopilot system: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38173.html
(→Nasal code coupled to the autopilot system: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html) |
m (→Nasal code coupled to the autopilot system: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38173.html) |
||
| Line 210: | Line 210: | ||
Unfortunately, some core developers are opposed to the idea, i.e. avoid *any* Nasal in the fast simulation loop of the FDM, because Nasal execution is slow and non-deterministic. Running it in the fast simulation loop is the last thing we want[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html]. | Unfortunately, some core developers are opposed to the idea, i.e. avoid *any* Nasal in the fast simulation loop of the FDM, because Nasal execution is slow and non-deterministic. Running it in the fast simulation loop is the last thing we want[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html]. | ||
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. | |||
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. | |||
Creating an autopilot (or any GNC or system model, for that matter) can be done very effectively with discrete objects such as summers, gains, controllers, filters, switches, etc., much as JSBSim has done with the system components. This is a standard approach in industry, as exemplified by Mathwork's $imulink product. | |||
Scilab/Scicos is similar in concept. Control system topologies are often diagrammed in a way that can lead to a one-to-one correspondence between a | |||
block and a control system object that can be referenced in an XML file, if the control system component library has been defined properly. This, again, | |||
is the way that JSBSim has approached the solution. | |||
Some benefits to such an approach include (IMHO) better testability, more predictability, and easier interface (someday) with a GUI tool, should one | |||
materialize. The downside is that XML can be verbose. | |||
Also see: | Also see: | ||