The latter is usually also used for hooking up external plotting/analysis tools to fgfs for visualization purposes. for in-house developments that aren't intended to be shared. 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.Įxternal interfacing (matlab etc) is usually used by professional/proprietary projects that may need to work with closed-source code/data, e.g. If you're looking for a totally integrated solution, Nasal/Canvas is offering a ton of possibilities, as can be seen by FGPlot
People with a coding background and/or "tinkering mentality" should be just fine using Nasal, replacing performance-critical stuff with XML-based PropertyRules.
People intimately familiar with JSBSim and its concepts (or with a strong background in control theory or aerodynamics), will usually want to use JSBSim.Įqually, 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). 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).Įxternal interfacing works pretty well but isn't as integrated obviously, and brings a certain setup/maintenance overhead with it, too. 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. 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. 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. The flight control systems can be built in many ways. 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 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.
The two ones currently in use are YASim and JSBSim. 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.ĭepending on which aircraft is used there can be different FDMs that determine how the aircraft acts in the air (and on the ground). In addition to the joystick configuration file there is also a keyboard configuration file with bindings, of with are related to flight controls. The joystick configuration files lives in $FG_ROOT/Input/Joysticks. 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. 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 is the location of the "data" directory/folder of your FlightGear installation. $FG_ROOT will be referenced few times.These properties are used for interfacing various things. The "nervous system" of FlightGear is the property tree, which is a tree-like structure that store the values of properties.Lets start by mentioning a few things that will be good to have further down.
0 kommentar(er)
