High-Level Architecture: Difference between revisions

Jump to navigation Jump to search
m
(27 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Official Core Development Effort}}


{{infobox subsystem
{{infobox subsystem
Line 25: Line 26:
# 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>http://sourceforge.net/p/flightgear/mailman/message/34196458/</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.
# 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>http://sourceforge.net/p/flightgear/mailman/message/34196458/</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.


A good overview of how the HLA architecture works can be found here http://www.pitch.se/images/files/tutorial/TheHLAtutorial.pdf.
A good overview of how the HLA architecture works can be found here http://www.pitchtechnologies.com/wp-content/uploads/2014/04/TheHLAtutorial.pdf


==Design==
==Design==
Line 31: Line 32:
The planned overall design is as follows:
The planned overall design is as follows:
* We intend to use OpenRTI as the underlying RTI.  This is an open source IEEE 1516 standard RTI, written by Mathias Fröhlich and available from https://sourceforge.net/projects/openrti/.
* We intend to use OpenRTI as the underlying RTI.  This is an open source IEEE 1516 standard RTI, written by Mathias Fröhlich and available from https://sourceforge.net/projects/openrti/.
* Mathias has also written an open source toolkit to act as an interface library, with a working name of SimKit.  This sits on top of the RTI and simplifies interfacing with the RTI massively.  It also has excellent Python integration, making it very easy to write scripted Federates.
* Mathias has also written an open source toolkit to act as an interface library, with a working name of SimKit.  This sits on top of the RTI and simplifies interfacing with the RTI massively.  It also has excellent Python integration, making it very easy to write scripted Federates. It's available from: https://sourceforge.net/projects/sim-kit/


Using [[SimKit]], the integration point is within the FlightGear code (rather than SimGear), in particular the code under $FG_SRC/Network/HLA.
Using [[SimKit]], the integration point is within the FlightGear code (rather than SimGear), in particular the code under $FG_SRC/Network/HLA.
Line 37: Line 38:
==Federate Object Model==
==Federate Object Model==


A key part of the design is writing the Federation Object Model (FOM), which defines the objects and updated that are published by the RTI.  While it might at first glance seem a good idea to use the FOM to share the internal property tree across multiple federates, this is probably the wrong way to use HLA as the granularity is too low and it's likely to lead to synchonization issues . Instead we'll need to make explicit decisions about the data models to communicate.
A key part of the design is writing the Federation Object Model (FOM), which defines the objects and updates that are published by the RTI.  While it might at first glance seem a good idea to use the FOM to share the internal property tree across multiple federates, this is probably the wrong way to use HLA as the granularity is too low <ref>https://sourceforge.net/p/flightgear/mailman/message/34795859/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/34803436/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/34794675/</ref> and it's likely to lead to synchonization issues. Instead, we'll need to make explicit decisions about the data models to communicate.


The FOM is a set of XML files in [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/HLA/ fgdata/HLA/]
The FOM is a set of XML files in [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/HLA/ fgdata/HLA/]
The orientation data in the FOM (SGOrientationWGS84) are Quaternions ([https://en.wikipedia.org/wiki/Quaternion https://en.wikipedia.org/wiki/Quaternion]), and those are the i,j,k values.  From memory, the orientation is relative to a earth-centered-frame, and there are functions in SimGear to convert to heading/pitch/roll in combination with the object's position.
<ref> {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=280098#p280098
  | title  = <nowiki>Re: HLA </nowiki>
  | author = <nowiki>stuart</nowiki>
  | date  = Mar 21st, 2016
  | added  = Mar 21st, 2016
  | script_version = 0.25
  }}</ref> <ref>{{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34963798/
  | title  = <nowiki>Re: [Flightgear-devel] HLA</nowiki>
  | author = <nowiki>Stuart Buchanan</nowiki>
  | date  = Mar 24th, 2016
  | added  = Mar 24th, 2016
  | script_version = 0.25
  }}
</ref>
Richard's [[Emesary]] system would also probably work quite well with the HLA FOM to give us a way for models to communicate with other models.<ref> {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34985731/
  | title  = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
  | author = <nowiki>Richard Harrison</nowiki>
  | date  = Apr 1st, 2016
  | added  = Apr 1st, 2016
  | script_version = 0.25
  }}
</ref>
{{Appendix}}
==Federates==
Federates can be written in most languages, but SimKit provides very good hooks for writing them in C++ and Python.
For some Subsystems split off from the existing FlightGear source, it's fairly easy to create an executable with its own property tree<ref>https://sourceforge.net/p/flightgear/mailman/message/34632142/</ref> and have shared C++ code to map FOM objects to property values.  However, this is an implementation detail - the whole point of HLA and the FOM is that it makes no assumptions about what Federates do with the data.
Regarding weather, in a HLA/RTI context the way to do this would be to have a weather engine as an RTI Federate. This would run any required weather simulation, and pass (very) local weather conditions to each of the aircraft/tower/windsock in the simulation, plus publish position information on clouds for use by visualiation engines.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35595300/
  |title  =  <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
  |author =  <nowiki> Stuart Buchanan </nowiki>
  |date  =  Jan 10th, 2017
  |added  =  Jan 10th, 2017
  |script_version = 0.40
  }}</ref>


==Current Status ==
==Current Status ==
Last updated: (19/02/2016)
Last updated: (13/01/2017)
 
Stuart is cautiously optimistic that he may be able to provide the start of a HLA implementation quite soon, as one of the blocking factors may be resolved soon.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35595300/
  |title  =  <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
  |author =  <nowiki> Stuart Buchanan </nowiki>
  |date  =  Jan 10th, 2017
  |added  =  Jan 10th, 2017
  |script_version = 0.40
  }}</ref>
 


Currently, there is some very old HLA support in SimGear. This is very out of date and should be ignored.
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 local build, but is waiting for Mathias to officially publish his SimKit before he pushes his changes.  So all of the following is local-only, but included here for information.
Stuart has HLA support using the latest OpenRTI and SimKit working on a local build, but is waiting for Mathias to officially publish his SimKit before he pushes his changes.  So all of the following is local-only, but included here for information.


The Flightgear core currently supports HLA as follows.
The Flightgear core currently supports HLA as follows.
* SimKit integration, reading the SimKit FOM and connecting to an OpenRTI RTI.
* SimKit integration, reading the SimKit FOM and connecting to an OpenRTI RTI.
* Instantiating MP AI objects so users can view objects published over the RTI by other Federates.  This is currently somewhat unsatisfactory as it overloads the MP code, where really these objects are more basic.
* Instantiating MP AI objects so users can view objects published over the RTI by other Federates.  This is currently somewhat unsatisfactory as it overloads the MP code, where really these objects are more basic.
* Pick up Environment Objects for this instance and use them to set the local METAR string for weather generation.


{{See also|FGTraffic}}
We currently have the following other Federates:
We currently have the following other Federates:
* fgogel - An AI model written in python the publishes over to the RTI.  Part of SimKit, but handy nevertheless!
* '''fgogel''' - An AI model written in python the publishes over to the RTI.  Part of SimKit, but handy nevertheless!
* fgtraffic -  to run an AI Scenario externally to the FG Core
* '''fgtraffic''' -  to run an AI Scenario externally to the FG Core
* fgmetar - written in python that retrieves the closest METAR station for other published Federates and publishes the METAR for them to pick up. This could be expanded to provide [[FGPythonSys#Weather_Simulation|a general Weather Engine]].
* '''fgmetar''' - written in python that retrieves the closest METAR station for other published Federates and publishes the METAR for them to pick up. This could be expanded to provide [[FGPythonSys#Weather_Simulation|a general Weather Engine]].
 
Stuart now has the [[AI]] Manager working as an external binary, and publishing updates over the RTI which are displayed as MP Aircraft. Stuart has created a little python script that looks for objects with locations being published over the RTI and publishes the closest METAR to them, then modified FG to pick up the appropriate METAR string for this instance and use it as the real-time input for weather generation.  


Separately, Erik has been doing some preparatory work suitable for supporting HLA in JSBSim  (http://sourceforge.net/p/jsbsim/mailman/message/34720784/)
The python script could be fairly easily enhanced into a more substantial weather engine allowing a single coherent weather environment to be used across the simulation. Stuart also started work modifying [[FGViewer]] so that it works with SimKit. This is a fairly big deal and quite a bit of fairly dull plumbing work but would allow us at least have a view of the simulation entirely separate from the running simulation.
<ref> {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34877355/
  | title  = <nowiki>[Flightgear-devel] HLA Status Update 23/2/2016</nowiki>
  | author = <nowiki>Stuart Buchanan</nowiki>
  | date  = Feb 23rd, 2016
  | added  = Feb 23rd, 2016
  | script_version = 0.25
  }}
</ref>


Separately, Erik has been doing some preparatory work suitable for supporting HLA in JSBSim by adopting so called PropertyObjects to  hopefully get rid of tied properties (http://sourceforge.net/p/jsbsim/mailman/message/34720784/)


<references/>


== Related ==
For additional information, please see:
For additional information, please see:
* [[Technical_Reports#A_New_Architecture_for_FlightGear_Flight_Simulator]]
* [[Technical_Reports#A_New_Architecture_for_FlightGear_Flight_Simulator]]
* [[Decoupling the AI Traffic System]] (currently work-in progress, highlights the limitations of the current AI system related to distributed/multi-instance and multiplayer usage)
* [[FlightGear HLA support (High Level Architecture)]] (outdated, documenting the original HLA infrastructure code)
* [[FlightGear HLA support (High Level Architecture)]] (outdated, documenting the original HLA infrastructure code)
* [[FlightGear CIGI Support (Common Image Generator Interface)]].
* [[FlightGear CIGI Support (Common Image Generator Interface)]].
* [[Modularizing, parallelizing and distributing FlightGear]] (background info/discussions pre-dating HLA adoption in FlightGear)
* [[Distributed Interactive Simulation]] (DIS specific review of the FlightGear multiplayer system/protocol and its limitations, which can be addressed via HLA)


== External links ==
== External links ==
160

edits

Navigation menu