FlightGear Newsletter November 2015: Difference between revisions

Most [[JSBSim]] aircraft developers probably know about [[Aeromatic]], a web-based configuration file generator for JSBSim. In the past month, AeromatiC++ was created using the PHP code from Aeromatic2. AeromatiC++ is a flexible command line utility which, like Aeromatic2, can create JSBSim configuration files based an a minimal set of input variables. But AeromatiC++ is much more flexible by design which allows it to create appropriate subdirectories, engines and thruster files but also systems files.

Engines now have code to reasonably guess the fuel consumption based on a minimal number of inputs. The turboprop engine is now transformed from a turbine simulated turboprop configuration to a true JSBSim turboprop engine with propeller. Support has also been added for the electric engine.

Every system adds its own lift, drag and/or side force and pitch, roll and/or yaw moments if selected.

Stuart Buchanan has started looking at the [[HLA]] (High-Level Architecture) integration for FG, after some very useful discussion with Mathias Froehlich. This is just a note to say what he's looking at and how he's thinking of developing it. Any comments/advice is welcome.

As background, we currently have a partial HLA implementation in SimGear which has a dependency on [[OpenRTI]]. As the name suggests, OpenRTI is an open-source RTI, which is developed by Mathias himself.  

This is all very well, but the HLA world has moved on since this code was written, and the code doesn't support some of the modern constructs.  

Mathias has been working on a toolkit that provides a lot of the "plumbing" required for a HLA client, in a much nicer package. This toolkit doesn't yet have a name, but would allow us to ditch most/all of the SimGear HLA code. (Note that like the current HLA dependency, this is completely optional and only required if one is compiling with the ENABLE_RTI boolean cmake option.)

As a first use-case Stuart expects to start looking at a very basic AI integration so other aircraft in the federation are displayed within FG (see [[Decoupling the AI Traffic System]]). That doesn't really leverage the power of HLA, but should at least allow us to get to grips with the problems and architecture before moving onto more ambitious plans, including the Holy Grail of separating the viewer from the FDM.  

A lot of the challenge is likely to be in designing the data to be shared across the RTI, which will require a lot more thought than one might naively assume. <ref>http://sourceforge.net/p/flightgear/mailman/message/34600516/</ref>.

 

 

The next steps Stuart is planning are as follows: - Flesh out the Viewer Federate implementation, possibly to include mapping of HLA data to properties. - Publish the FlightGear aircraft instance position to the RTI so it can be picked up by other viewers. - Create a Multiplayer Proxy as a Federate that proxies between the MP network and the RTI. This will run in a separate thread or as a separate executable. - Split out the traffic Manager in a similar way. This is obviously focussing on the viewer aspect, and doesn't address splitting out the FDM or control elements.<ref>http://sourceforge.net/p/flightgear/mailman/message/34625641/</ref>