Federate
Jump to navigation
Jump to search
A Federate is a simulation component of a HLA Federation.
I'm currently doing something in a similar area by integrating FG with HLA, with the eventual aim of splitting the various FG components out into separate FG Federates. Depending on what you already have in your DIS-simulation, and whether that is also able to work in a HLA environment, you may be able to plug your simulation directly into FG in the (possibly distant!) future. One of the pieces I will be working on will be a HLA/MP proxy. — stuart (Nov 30th, 2015). Re: How to publish self-developed add on for MPS.
(powered by Instant-Cquotes) |
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) |
my understanding is that we'd have probably one federation with some federates. I'm tending to the opinion that all vehicles in the system (AI, MP, Controllables) probably are best implemented using a single SOM. Within the controllables there would be the dynamics, the environment, etc, pretty much most of what's in the property tree. The SOM would contain enough to places these controllables in the viewer(s). Obviously there's going to have to be something coming back to the vehicle from the viewer to allow for events and model interactions (height above terrain, terrain / model interactions). I suspect there might also need to be something in there to manage the input devices and routing input events to the currently selected controllable. I think it's important to have the environment within the controllable, and maybe to have static viewpoints as a form of controllable or possibly one static to allow for different viewpoints and walker. I'm hoping this approach would allow the easy selection of different controllables (aircraft, cars, etc.) — Richard Harrison (Nov 28th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes) |