160
edits
High-Level Architecture: Difference between revisions
Jump to navigation
Jump to search
m
→Design
m (→Design) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 26: | 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. | 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 32: | 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 76: | Line 76: | ||
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. | 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: ( | 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. | ||