Federate: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
| author = <nowiki>Stuart Buchanan</nowiki> | | author = <nowiki>Stuart Buchanan</nowiki> | ||
| date = Nov 19th, 2015 | | date = Nov 19th, 2015 | ||
}} | |||
}} | |||
Furthermore, there may be [[FlightGear Headless|headless]] federates (e.g. AI traffic), or those having their own graphics window (think ATC/RADAR client, fgviewer etc): | |||
{{FGCquote | |||
|1= A python script simulating a radar screen. This is receiving updates from both the KC-135 Federate and the FlightGear Federate and displaying them. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34694887/ | |||
| title = <nowiki>[Flightgear-devel] HLA Update</nowiki> | |||
| author = <nowiki>Stuart Buchanan</nowiki> | |||
| date = Dec 14th, 2015 | |||
| added = Dec 14th, 2015 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= In real time simulators all nodes must start each frame at exactly the same point by the wall clock and the simulator clock. Any node drift causes massive problems that aren't fixable. A node can start late but it must finish on time. In a certified simulator if any node runs over the end of the frame [8] the whole thing (including the motion based) performs an emergency stop and needs to be restarted. The image generator is an exception to this as it is usually only receiving position information[9] and tends to do its own thing in terms of frame rate indepedently to the host simulation nodes' frame rate. Image generators have been known to drop frames, and part of the certification process requires banking over the aircraft to fill the screens with terrain and check for any evidence of frame drop. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34631875/ | |||
| title = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki> | |||
| author = <nowiki>Richard Harrison</nowiki> | |||
| date = Nov 19th, 2015 | |||
| added = Nov 19th, 2015 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= the first thing in the HLA is to figure out how to synchronie the start time of each node. If you don't do this then sharing the data becomes much harder. Latency is one of the main problems. It is not sufficient to merely ensure that nodes start off with the same data (i.e. a bulk update at the end of each frame) - as this introduces a minium of one frame latency and often more. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34631875/ | |||
| title = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki> | |||
| author = <nowiki>Richard Harrison</nowiki> | |||
| date = Nov 19th, 2015 | |||
| added = Nov 19th, 2015 | |||
| script_version = 0.23 | |||
}} | }} | ||
}} | }} | ||
Revision as of 20:29, 29 December 2015
A Federate is a simulation component of a HLA Federation.
A FlightGear federate is likely to be a wrapper around a conventional SGSubsystem (think AI), having its own private property tree:
|
In terms of integration with the property tree, I'm thinking that in the short term all the different components that we split out into separate threads or executables will simply use their own properties trees, and use the RTI to reflect the particular (minimal) data that needs to be passed between components. — Stuart Buchanan (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes) |
|
Furthermore, there may be headless federates (e.g. AI traffic), or those having their own graphics window (think ATC/RADAR client, fgviewer etc):
|
|
A python script simulating a radar screen. This is receiving updates from both the KC-135 Federate and the FlightGear Federate and displaying them. |
|
|
|
In real time simulators all nodes must start each frame at exactly the same point by the wall clock and the simulator clock. Any node drift causes massive problems that aren't fixable. A node can start late but it must finish on time. In a certified simulator if any node runs over the end of the frame [8] the whole thing (including the motion based) performs an emergency stop and needs to be restarted. The image generator is an exception to this as it is usually only receiving position information[9] and tends to do its own thing in terms of frame rate indepedently to the host simulation nodes' frame rate. Image generators have been known to drop frames, and part of the certification process requires banking over the aircraft to fill the screens with terrain and check for any evidence of frame drop. — Richard Harrison (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes) |
|
|
|
the first thing in the HLA is to figure out how to synchronie the start time of each node. If you don't do this then sharing the data becomes much harder. Latency is one of the main problems. It is not sufficient to merely ensure that nodes start off with the same data (i.e. a bulk update at the end of each frame) - as this introduces a minium of one frame latency and often more. — Richard Harrison (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes) |
|