FlightGear high-level architecture support: Difference between revisions

Jump to navigation Jump to search
https://gitorious.org/fg/flightgear/trees/next/utils/fgai
(https://gitorious.org/fg/flightgear/trees/next/utils/fgai)
Line 19: Line 19:
* 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
* https://gitorious.org/fg/flightgear/commit/d79b2385b4f4a64a2460c32e6123ea399bfa83d6
* https://gitorious.org/fg/flightgear/trees/next/utils/fgai


= Background =
= Background =
Line 130: Line 131:
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 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 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 [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 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  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  [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.


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  

Navigation menu