Jump to: navigation, search

High-Level Architecture

1,579 bytes removed, 17:54, 19 February 2016
Integration of relevant insta-quotes into main text and update on current status
# It provides a very good framework to allow anyone to create components that interact with FlightGear using programming languages other than C/C++ (think Ada, Java, Python etc), which may be running in their own threads, and reside in separate binaries<ref></ref>, which will be also easier to debug/troubleshoot (think regression testing, i.e. running a self-contained subsystem in a dedicated gdb/valgrind session), without having to know how to modify/patch and rebuild FlightGear.
As A good overview of late 2015, Stuart has started work on re-architecting parts of FlightGear to use how the HLA, though this is expected to be a multi-year projectarchitecture works can her found here http://www. Anyone interested in the current status of development should subscribe to the Flightgear -devel mailing
{{FGCquote|1= For those looking for a summary of HLA, the following PDF provides a useful overview:|2= {{cite web | url Design= | title = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki> | author = <nowiki>Stuart Buchanan</nowiki> | date = Nov 19th, 2015 | added = Nov 19th, 2015 | script_version = 0.23 }}}}
{{FGCquoteThe planned overall design is as follows:|1= Depsite appearances moving the rendering * We intend to a seperate node/process is probably the easiest to implement use OpenRTI as the inter module dependencies aren't that strongunderlying RTI. This is an open source IEEE 1516 standard RTI, or at least those that are strong can be shipped as a block update at the end of the simulation frame.|2= {{cite web | url = httpwritten by Mathias Fröhlich and available from | title * Mathias has also written an open source toolkit to act as an interface library, with a working name of SimKit. = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki> | author = <nowiki>Richard Harrison</nowiki> | date = Nov 19thThis sits on top of the RTI and simplifies interfacing with the RTI massively. It also has excellent Python integration, 2015 | added = Nov 19th, 2015 | script_version = 0making it very easy to write scripted Federates.23 }}}}
{{FGCquote|1= I'm hoping that OpenRTI will provide Using SimKit, the infrastructure for the data sharing so I don't need to worry about shared memory etc. As I mentioned previously, I'm planning to use an IEEE 1516 standard RTI, of which OpenRTI integration point is a conveniently free implementation. AFAICT this is one of within the main standards for distributed simulation communication FlightGear code (the other being DISrather than SimGear). I think that will address the communications side of the equation, and OpenRTI can work both as a local RTI and over a network. It's also got a robust logical time implementation, and in particular the ability to clock the simulation.|2= {{cite web | url = http:code under src/Network/ | title = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki> | author = <nowiki>Stuart Buchanan</nowiki> | date = Nov 19th, 2015 | added = Nov 19th, 2015 | script_version = 0.23 }}}}
{{FGCquote==Federate Object Model==|1= HLA is really intended to operate at a much higher level A key part of granularity and pass objects around a distributed simulation. The use-case I'm working on at the moment passes an AI instance as an object design is writing the Federation Object Model (with positionFOM), velocity, accelerations, model to be displayed). How a HLA Federate maps which defines the objects and updated that data internally is an implementation decision. There shouldn't be any race conditions because no assumptions are made about how published by the data is used or mappedRTI. At present, I'm not thinking that HLA will be used as While it might at first glance seem a mechanism good idea to provide a shared use the FOM to share the internal property tree across multiple Federates. I think that's federates, this is probably the wrong way to use HLAas the granularity is too low and it's likely to lead to synchonization issues . Instead you we'll need to make explicit decisions about the data models you will to communicate.  The other reason FOM is a set of XML files in [ isn't / fgdata/HLA/] ==Current Status (19/02/2016== Currently there is some very old HLA support in SimGear. This is very out of date and should be ignored. Stuart has HLA Support using the latest OpenRTI and SimKit working on a good choice local build, but is waiting for Mathias to do with simulation clockingofficially publish his SimKit before he pushes his changes. I'm still getting my head around this properly So all of the following is local-only, but included here for information. The Flightgear core currently supports HLA as follows.* SimKit integration, reading the overall model is one where SimKit FOM and connecting to an OpenRTI RTI.* Instantiating MP AI objects so users can view objects published over the simulation clock RTI by other Federates. This is advancedcurrently somewhat unsatisfactory as it overloads the MP code, and where really these objects are more basic. We currently have the instance following other Federates:* fgogel - An AI model written in python the updates and publishes changes over to the RTI . Part of SimKit, but handy nevertheless!* fgtraffic - to run an AI Scenario externally to the FG Core* fgmetar - written in python that will be picked up by retrieves the closest METAR station for other instances at published Federates and publishes the next clock advanceMETAR for them to pick up. This could be expanded to provide a general Weather Engine.|2= {{cite web | url = Separately Erik has been doing some preparatory work suitable for supporting HLA in JSBSim ( | title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API (was Re: A FGPythonSys implementation: ...)</nowiki> | author = <nowiki>Stuart Buchanan</nowiki> | date = Jan 26th, 2016 | added = Jan 26th, 2016 | script_version = 0.23 }}}}
|1= For now I've only added the code but not used it anywhere. This has the advantage of getting (compiler) errors early before new functionality gets added. Most of the code remains the same, even the Tie functions are still there and for stand alone programs they are perfectly fine.
But JSBSim will be used in a HLA environment soon because that's where FlightGear is heading and for that the new code is useful (accessing tied properties from multiple sources).
|2= {{cite web
| url =
| title = <nowiki>[Flightgear-devel] (JSBSim) Standalone Properties</nowiki>
| author = <nowiki>Erik Hofman</nowiki>
| date = Dec 25th, 2015
For additional information, please see:

Navigation menu