Changes

Jump to: navigation, search

High-Level Architecture

2,646 bytes added, 20:51, 13 January 2017
Federates
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==
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 ==
Last updated: (1913/0201/20162017Stuart 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.
* 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:
* '''fgogel''' - An AI model written in python the publishes over to the RTI. Part of SimKit, but handy nevertheless!
19,381
edits

Navigation menu