FlightGear high-level architecture support

From FlightGear wiki
Revision as of 21:46, 5 March 2012 by Hooray (talk | contribs) (start documenting things by copying stuff from the list archives)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Objective

Document the ongoing HLA effort, to help people better understand how this affects a number of related FlightGear efforts and projects (particularly related to improved modularization, concurrency support and the multiplayer system).

Status 01/2011

Source: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30433.html

First attempt of HLA/RTI support in flightgear.

For the ones that do not know about that, HLA/RTI is message distribution api used for distributed and paralell real time simulation systems. There are a few api variants out there where the newest two ones are an IEEE standard known as rti1516 and rti1516e. This api is used in some open source simulation systems and in plenty simpulation systems you can by on the market. The api might look difficult at the first time, but it provides a carefully designed set of communication methods that avoid communication latencies - the worst problem in real time simulations - for a distributed simulation system. The api is standardized, and depending on the RTI implementation, available with different language bindings like C++, java, ada. Additionally there are implementations hooking on to of those given ones for matlab, python, fortran and probably more I do not know about. This should also extend the abilities to communicate with components using the tools and languages we cannot handle currently in any sensible way.

>From my point of view, this communication infrastructure based on rti provides a huge potential to split the simulation into components that run on different cores or even machines but still being tight coupled.

What is to be commited is in this step is an alternative to the multiplayer protocol which does not cover really all what the multiplayer protocol can do today. But there is a proof of concept and some playground to start with. The current implementation in flightgear is flexible enough to adapt to the needs of very different simulation systems. The default object model that you get is adapted to the needs of flightgear, but the implementaiton is flexible enough to change the object model to the AviationSim object model for example at startup time.

So, this should not only provide a way to distribute flightgears simulation systems across cpus or may be machines, this should also provide a way to increase connectivity of flightgear to other simulation systems.

Also included is an RTI variant abstraction layer inside simgear to help with some common tasks that are often needed in an HLA/RTI implementation. One of the design goals of this layer was to provide a framework where interaction with the RTI api consumes as little overhead as possible.

In particular, this means that indies (fast mappings) are used wherever possible and allocations are minimized.

Currently the only implemented RTI variant is the old nonstandard HLA-1.3 api, which was the only api I had available from an open source project at the time I began with that work. But it should be straight forward to extend that to the two IEEE standard RTI variants.

Testing

What do you need:

  • Todays simgear and flightgear as well as the data package.
  • An RTI-1.3 implementation.

The rti implementation from www.certi.org was used most of the time during development. While this one works somehow, it is sometimes difficult to handle and relatively slow.

Meanwhile, this has been replaced almost entirely with OpenRTI, a new RTI from openrti.berlios.de that is way easier to set up and use and that provides way more features we might make use of with flightgear.

So, the implementation in flightgear does not make any assumptions about some internal features of the RTI implementation, except the way the rti is configured to connect to its federation server. That means, that you can use any RTI implementation you like, if you care for the apropriate connection setup. But for the default setup that we might choose, I intent to provide a configuration that makes use of some properties of OpenRTI. So in theory, you should not need to know anything about that, until you make sophisticated use of these features.


Install and understand how to run your RTI version. Recompile simgear and flightgear with the --with-rti13[=<prefix to your rti>] configure option.

There is some initial cmake integration. Set up a server for your RTI implementation.

Start flightgear with "--hla=bi,<hz>,<federateType>,<federationName>,<profile>", where <hz> is the communication frequency, <federateType> is the name of your federate - note that this must be unique with certi - and <federationName> is the federation you want to join. The <profile> argument defaults to the top level configuration file mp-aircraft.xml, which defines some flightgear adapted RTI/HLA federation definition. But there is already an alternate av- aircraft.xml top level configuration file that should enable flightgear being used in an AviationSim federation that is the c++ hardcoded federation type of the other flightgear hla implementation out there.

Additional info

Just search the archives (list/forum) for "HLA":

Resources

Retrieved from "https://wiki.flightgear.org/w/index.php?title=FlightGear_high-level_architecture_support&oldid=43775"