FlightGear high-level architecture support: Difference between revisions

Jump to navigation Jump to search

FlightGear high-level architecture support (view source)

Revision as of 18:00, 9 March 2016

94 bytes removed ,  9 March 2016
Switch to {{flightgear commit}}, {{flightgear url}}, and {{flightgear source}} to fix the broken Gitorious links. And OpenRTI has been switched from Gitorious to the current SourceForege repository via {{sourceforge source}}.
m (outdated article, movign infobox to more current article)
(Switch to {{flightgear commit}}, {{flightgear url}}, and {{flightgear source}} to fix the broken Gitorious links. And OpenRTI has been switched from Gitorious to the current SourceForege repository via {{sourceforge source}}.)
Line 130: Line 130:
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32045.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32045.html
* http://www.mail-archive.com/search?q=fgai&l=flightgear-devel%40lists.sourceforge.net
* http://www.mail-archive.com/search?q=fgai&l=flightgear-devel%40lists.sourceforge.net
* https://gitorious.org/fg/flightgear/commit/d79b2385b4f4a64a2460c32e6123ea399bfa83d6
* {{flightgear commit|d79b2385b4f4a64a2460c32e6123ea399bfa83d6}}
* https://gitorious.org/fg/flightgear/trees/next/utils/fgai
* {{flightgear url|path=utils/fgai}}




Line 248: Line 248:
For over a decade, we've been talking about moving the AI traffic subsystem out of the fgfs main loop, not just to free computing resources, but also to make it easier to synchronize AI traffic with multiple instances, i.e. using multiplayer or master/slave setups with possibly dozens of computers (see [[Decoupling the AI Traffic System]]) and the link at [http://wiki.flightgear.org/images/1/1e/New_FG_architecture.pdf]. This requirement has been also extensively discussed over at the fgms project, and in the [[Distributed Interactive Simulation]] article.
For over a decade, we've been talking about moving the AI traffic subsystem out of the fgfs main loop, not just to free computing resources, but also to make it easier to synchronize AI traffic with multiple instances, i.e. using multiplayer or master/slave setups with possibly dozens of computers (see [[Decoupling the AI Traffic System]]) and the link at [http://wiki.flightgear.org/images/1/1e/New_FG_architecture.pdf]. This requirement has been also extensively discussed over at the fgms project, and in the [[Distributed Interactive Simulation]] article.


The [https://gitorious.org/fg/flightgear/trees/next/utils/fgai fgai proof-of-concept], is just a brief sketch chat could be done in that corner. It already  contains most if what is needed in complex infrastructure. You can inject vehicles and you can now get ground queries. I am for a long time running here also a brief python script which does about  the same than [https://gitorious.org/fg/flightgear/trees/next/utils/fgai fgai]. While a scripting language is not fast enough to drive a lot of ai traffic, it is rather nice to do only a few such objects without much  worries.
The {{flightgear source|path=utils/fgai|text=fgai proof-of-concept}}, is just a brief sketch chat could be done in that corner. It already  contains most if what is needed in complex infrastructure. You can inject vehicles and you can now get ground queries. I am for a long time running here also a brief python script which does about  the same than {{flightgear source|path=utils/fgai|text=fgai}}. While a scripting language is not fast enough to drive a lot of ai traffic, it is rather nice to do only a few such objects without much  worries.


The basic idea to have an external component that drives ai traffic, or at least a thread that does the same is a good one I think. For the long term I do not care about the multiplayer protocol since it has severe limitations that would require a very similar solution that one the OpenRTI implementation does. For the short term, I am not sure if we are already at the point where I can just switch over. Therefore this bridge component bridging the mp protocol with hla. For the ADS-B traffic, packing this into a module that you can attach to your  simulation instead of an artificial traffic component is an nice addition. Having  
The basic idea to have an external component that drives ai traffic, or at least a thread that does the same is a good one I think. For the long term I do not care about the multiplayer protocol since it has severe limitations that would require a very similar solution that one the OpenRTI implementation does. For the short term, I am not sure if we are already at the point where I can just switch over. Therefore this bridge component bridging the mp protocol with hla. For the ADS-B traffic, packing this into a module that you can attach to your  simulation instead of an artificial traffic component is an nice addition. Having  


Whatever happens here, if you are really driving a lot of ai models it  requires a huge amount of thoughts to get that scalable. Updates to specific  
Whatever happens here, if you are really driving a lot of ai models it  requires a huge amount of thoughts to get that scalable. Updates to specific  
models as well as specific parts of those need to be updated in an sparse and  intelligent way to make this somehow work. This includes the basic part of the [https://gitorious.org/fg/flightgear/trees/next/utils/fgai fgai] implementation which aims to have steady and differentiable movements.  This is at this time not made use of so much, but the classes that I called  something like *Physics* in there are mostly there to make sure that all  components can see and even extrapolate the same steady movements than the  originating component does. There is also infrastructure there to play some  tricks with timing so that nobody needs to wait for ai traffic updates to  arrive  - they should just already be there.
models as well as specific parts of those need to be updated in an sparse and  intelligent way to make this somehow work. This includes the basic part of the {{flightgear source|path=utils/fgai|text=fgai}} implementation which aims to have steady and differentiable movements.  This is at this time not made use of so much, but the classes that I called  something like *Physics* in there are mostly there to make sure that all  components can see and even extrapolate the same steady movements than the  originating component does. There is also infrastructure there to play some  tricks with timing so that nobody needs to wait for ai traffic updates to  arrive  - they should just already be there.


There is also a small gatweay application translating between the old  multiplayer and hla that might go into the utils directory past the next  
There is also a small gatweay application translating between the old  multiplayer and hla that might go into the utils directory past the next  
Line 312: Line 312:
While this one works somehow, it is sometimes difficult to handle and relatively slow.  
While this one works somehow, it is sometimes difficult to handle and relatively slow.  


Meanwhile, this has been replaced almost entirely with [https://gitorious.org/openrti/openrti OpenRTI], a new RTI from https://gitorious.org/openrti/openrti that is way easier to set up and use and that provides way more features we might make use of with flightgear.
Meanwhile, this has been replaced almost entirely with {{sourceforge source|openrti|OpenRTI|text=OpenRTI}}, a new RTI from {{sourceforge url|openrti|OpenRTI}} that is way easier to set up and use and that provides way more features we might make use of with flightgear.


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.
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.
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/95338"

Navigation menu