Hi all, long promised and now checked in: 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 a s 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. What do you need to make use of that: * Todays simgear and flightgear as well as the data package. * An RTI-1.3 implementation. 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. I have used the open source rti implementation from www.certi.org for most of the time of my development. While this one works somehow, it is sometimes difficult to handle and relatively slow. During the last few weeks I have replaced that one here 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. For what is now checked in, I hope that I have not broken anything for the default case, when you have no such library installed. For the case you make use of this new features, If you have any problems, suggestions, improovements or rants, drop me a note. Greetings Mathias ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
