FlightGear high-level architecture support: Difference between revisions

{{Rendering}}

{{FGCquote

|1= what is very near is that we can do the phsyics in parallel with the cull and draw stage on a different cpu. That will utilie multi core machines in this current generation very well. Also osg allows us to feed multiple views from within one single application where each view runs its cull and draw on its own cpu. Osg provides much more here, but for the first cut this describes it well enough. Given that in the near future only the update step does communication between the physics part and the IG part we have many places where the physics pipeline stage feeds the IG pipeline stage identified, I can see a good chance to do that update step with data feed over a network interface.

<references/>

{{FGCquote|1= I've started looking at the HLA integration for FG, after some very useful discussion with Mathias Froehlich. This is just a note to say what I'm looking at and how I'm thinking of developing it. Any comments/advice is welcome - this is a new area for me. As background, we currently have a partial HLA implementation in SimGear which has a dependency on OpenRTI. As the name suggests, OpenRTI is an open-source RTI, which is developed by Mathias himself. This is all very well, but the HLA world has moved on since this code was written, and the code doesn't support some of the modern constructs. Mathias has been working on a toolkit that provides a lot of the "plumbing" required for a HLA client, in a much nicer package. This toolkit doesn't yet have a name, but would allow us to ditch most/all of the SimGear HLA code. (Note that like the current HLA dependency, this is completely optional and only required if one is compiling with the ENABLE_RTI boolean cmake option.) As a first use-case I expect to start looking at a very basic AI integration so other aircraft in the federation are displayed within FG. That doesn't really leverage the power of HLA, but should at least allow me to get to grips with the problems and architecture before moving onto more ambitious plans, including the Holy Grail of separating the viewer from the FDM. A lot of the challenge is likely to be in designing the data to be shared across the RTI, which I think will require a lot more thought than one might naively assume. -Stuart|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34600516/  | title  = <nowiki>[Flightgear-devel] HLA developments</nowiki>  | author = <nowiki>Stuart Buchanan</nowiki>  | date  = Nov 6th, 2015  }}}}

Also see [[FlightGear CIGI Support (Common Image Generator Interface)]].

When you start up FlightGear on a 8-12-core machine, you'll find that most cores aren't really utilized at all. This is in stark contrast to X-Plane for example. There are many computations being run as part of the FG main loop, that don't stricly belong there, and which could obviously run outside the main loop, either in a separate thread or a dedicated process.  

For professional users, it is extremely important to guarantee reliable frame rates, ideally separating the visualization from the underlying computation, so that separate computers can be used for different systems [http://forum.flightgear.org/viewtopic.php?f=18&t=15755&p=153295&hilit=hla+relevant#p153288].

Distributed multi-process configurations are in fact exactly the way professional simulators work, too: They are distributed and communicate using sockets. Mathias' ongoing HLA work is going to make that increasingly feasible.

There are languages far better suited for multithreaded programming, such as Ada - because they have language-level primitives to create "tasks" and "protected types".

HLA/RTI is message distribution API used for distributed and paralell real time simulation systems. There are

The API is standardized by an IEEE standard and used with commercial simulation systems as well, and depending on the RTI implementation, available with different language bindings like C++, java, ada. Additionally there are implementations hooking on to of those given ones for matlab, python, fortran and probably more. This should also extend the abilities to communicate with components using the tools and languages we cannot handle currently in any sensible way.

The nice thing is that the ipc is hidden behind something that is also able to distribute this across multiple machines. A local network connect is mostly sufficient. But doing the same by an infniband connect is possible too. Experimenting with shared memory did not bring notable improvements over a system local network connect. At least not on linux...

driven by exactly those problems that need to be solved once you dig into such kind of implementation. So one of the benefits is that you gain a encapsulated communication library that does what you need. This library can be tested independently of such an application beast like flightgear. And this is IMO a huge benefit.

the RTI c++ interface is defined in a way that you do not need to recompile anything. Everything is done with pure virtual classes and factories to get them. So however this is implemented in the shared object/dll you should just need to get a 'standard' implementation dependent RTI header and compile with that. So you should in theory be able to change the RTI library of an already compiled binary. For the case that a particular RTI implementation does not follow this rule,  you need to compile flightgear explicitly for this particular library.  

is a generic problem when running real time applications in parallel. I know a lot of really smart people who can even understand complex environments very well, but have no clue about the problems introduced by round trips. Seen this, this is the reason why I started that hla stuff, since this provides a framework which supports and even encourages a programming model that is able to hide latencies as good as possible. Anyway, there is a chance that you even use this api in a way that really hurts in this corner. And this is actually the really bad thing I want to avoid: If you are the first component that does not get that right you might just notice little to nothing - especially if you are running on extremely fast hardware. But when the next kind of problem is introduced this really starts to hurt more and more. And most people do not have any chance to see what happens and why.

We can have a completely independent weather module using the HLA stuff that runs in an own process/thread. So, at that time you might be able to do more sophisticated stuff. May be it will then be possible to do a full cfd for subparts of the scene. That might be a good thing for a glider scene where you might want to have a more detailed fluid behavior ...

simulation to get good results for thermals in some small area. The same goes for every component you can think of splitting out.

{{Main article|FGTraffic}}

A simple [[Decoupling the AI Traffic System|AI  model]] does just the trick what it does today. But more sophisticated modules might contain an own fdm so that these machines really live in the same fluid that the weather module provides data for.Note that the RTI API already provides a subscriber model that ensures that you don't feed data to participants that don't need that.May ba a radar controller screen that can be attached there to see the machines in this word. But sure that radar screen is not interested in flap animations for the aircraft ...

release.

Or take the viewers (also see [[FGViewer]]), if you just exchange data by a shared memory segment, you are limited to a single machine. So that's nice for the 3-chanel thing you have. But I know of installs with 9 chanels I have been visiting some few time ago. They run flightgear on that beast by the way. Or I know of installs that currently run 14 or 16 chanels within a single view. For that reason I thought: better have a technology that is also extensible for this kind of installs instead of programming everything on top of something limited machine local.

In thinking about it a bit and being reminded of the existing HLA interface that FlightGear has, I'm leaning toward proposing something built with Python and the PyQT4 GUI library.  Both components are cross-platform and there is a Python binding for the CERTI HLA library (PyHLA).

not a problem when such a component runs in its own process, python in core components that need to run in threaded mode is essentially a no go.

The management application wouldn't be running any of the sub-systems, just "observing" them. One of the issues that caught me up short was the requirement to sift through the chosen aircrafts configuration and Nasal files in order to take into account all the little custom menu items and controls that would have to be replicated on the manager interface. That was pretty discouraging all by itself.

My initial concept would essentially perform the same functions as the instructor console in a commercial FFS. You could tweak any parameter of the simulator from that point, including aircraft selection, position, configuration, etc. This app wouldn't be running on the same machine as the simulator & scene generator itself. (What would be neat is a three machine setup - one for the scene generator, one for the flight/systems model and one for the instructor/manager console.)

[http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.p We've toyed with the idea of an FDM server for a while], and there was even some work done on JSBSim towards making that happen. Recently, HDWysong has added the capability to use FlightGear as a visual front end for JSBSim as a separate, scripted application. It certainly would be a huge paradigm shift.

The author of fgms would be pretty much interrested to implement fgms as part of a HLA infrastructur. What detained me from going that way is, that I found no free (as is free  beer) documentation on HLA specifications and the quite complex structure  (too complex for a one-man-show). Additionaly I'm not sure about license  issues involved. Are we allowed to publish all parts of (our) HLA  infrastructur under the GPL (which will kind of undermine cash-flow of documentation providers like the IEEE)?  

What will come in the shorter term is a standalone viewer (see [[FGViewer]] that can sit on any of the configured views. There are beginnings of that checked in but there is a  lot more in preparation.

Source: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32973.html

OpenRTI provides one mode where you can just access a process local federation from multiple threads. There is no network configuration needed and you do not setup any server in this operation mode (sure it also provides the usual networking mode). So the plan is to use this mode as an aid to paralellize flightgear on a local machine. The basic advantage is that each federate is strictly programmed single threaded. All the thread syncronization is handled by the rti library and hidden in that thing. The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example.

What do you need:

* Latest simgear and flightgear as well as the data package.

usually had. So, --hla-local=rti://localhost/FlightGear is a shortcut for a longer --hla= line.

Just search the archives (list/forum) for "HLA" or "RTI":  

* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39181.html

* http://wiki.flightgear.org/images/1/1e/New_FG_architecture.pdf

* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16023.html