Introduction to flight control systems

This article is a stub. You can help the wiki by expanding it.

This is an introduction to flight control systems in FlightGear. A flight control system (FCS) is kind of a middleman between the pilots flight controls and the flight control surfaces such as the elevator, ailerons and rudders.

More advanced FCSs might have different control laws depending on for example airspeed, Mach number, altitude and of course system failures.

Do note that the FCS of an aircraft does not necessarily have to be digital or even electronic, some have been entirely mechanical, for example making flight stick inputs closer to the center result in smaller changes of aileron and elevator deflections.

Some things to begin with

Lets start by mentioning a few things that will be good to have further down.

• The "nervous system" of FlightGear is the property tree, which is a tree-like structure that store the values of properties. These properties are used for interfacing various things.
• $FG_ROOT will be referenced few times. This is the location of the "data" directory/folder of your FlightGear installation.

Inputs

When FlightGear is starting up it among other things read a joystick configuration file (or several if you for example have joystick, pedals and a throttle). This configuration file is a XML file with bindings that maps axles and buttons to properties, and can do that conditionally or even with embedded scripts. The joystick configuration files lives in $FG_ROOT/Input/Joysticks.

In addition to the joystick configuration file there is also a keyboard configuration file with bindings, of with are related to flight controls. That file lives in $FG_ROOT.

The bindings are themselves stored in the property tree, and in fact the configuration files are a so called PropertyList file that contains the properties serialized in XML form.

Flight dynamic models (FDMs)

Depending on which aircraft is used there can be different FDMs that determine how the aircraft acts in the air (and on the ground). The two ones currently in use are YASim and JSBSim.

The properties with the control inputs are fed to them and will usually control the deflection of the control surfaces or are driving a flight control system.

Flight control systems (FCSs)

Most aircraft does not have an FCS and in essence feed the control inputs directly to the control surfaces, however some do have one.

The flight control systems can be built in many ways. Some are programs in FlightGear's scripting language Nasal and some are built using property rules in a way similar to how autopilots in FlightGear are configured.

One can of course also mix Nasal and property rules, for example having a cockpit control with a binding that will call a Nasal script that sets some properties that will in turn override some control laws of the FCS.

JSBSim aircraft can have the FCS integrated in the FDM configuration file and the way they are set up is very much like how they are set up with property rules.

Summary

How you should proceed is mainly determined by your requirements/goals - for instance, JSBSim involves XML and possibly C++ level changes - property rules/ap stuff is generally pretty flexible but also somewhat verbose and restricted in a few ways, Nasal is fairly succinct and flexible but generally frame-rate/garbage-collection bound, so may affect frame-spacing and frame rate of the fg main loop (with threading generally being an option to people familiar with FG internals and threading concepts).

External interfacing works pretty well but isn't as integrated obviously, and brings a certain setup/maintenance overhead with it, too.

People intimately familiar with JSBSim and its concepts (or with a strong background in control theory or aerodynamics), will usually want to use JSBSim. Equally, people aware of Nasal's GC (garbage collection) issues or with no considerable background in coding, will want to use XML-based systems (either JSBSim and/or PropertyRules).

People with a coding background and/or "tinkering mentality" should be just fine using Nasal, replacing performance-critical stuff with XML-based PropertyRules. If you're looking for a totally integrated solution, Nasal/Canvas is offering a ton of possibilities, as can be seen by FGPlot

Whenever something is supposed to be aircraft/FDM agnostic, it makes sense to evaluate the merits of using a pure (or hybrid) Nasal/PropertyRules approach.

External interfacing (matlab etc) is usually used by professional/proprietary projects that may need to work with closed-source code/data, e.g. for in-house developments that aren't intended to be shared.

The latter is usually also used for hooking up external plotting/analysis tools to fgfs for visualization purposes.

In addition, there are some hard-coded restrictions affecting if/how certain solutions may be feasible/appropriate - but the details will heavily depend on your concrete use-case/scenario. JSBSim stuff generally works great and it's a fairly accessible code-base, too - so can be easily extended by people familiar with C++ - and extending JSBSim also doesn't necessarily involve building FlightGear from source, so is pretty straightforward (fgfs can use jsbsim in "external fdm" mode). Rebuilding fgfs from source is a completely different challenge - but once you've got a working build environment, it's hard to beat the degree of integration offered by using built-in means (PropertyRules, Nasal, Canvas, I/O etc).