FGTraffic: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Related: https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=319285#p319285)
Line 264: Line 264:


== Related ==
== Related ==
* [[Scripted AI Objects]]
* [[Ground Services]]
* [https://gitlab.com/fgms/fgms-1-x/blob/master/src/mpdummy/mpdummy.cxx mpdummy]
* [https://gitlab.com/fgms/fgms-1-x/blob/master/src/mpdummy/mpdummy.cxx mpdummy]
* [[Fgms]] - the FlightGear multiplayer server
* [[Fgms]] - the FlightGear multiplayer server

Revision as of 19:44, 23 September 2017

This article is a stub. You can help the wiki by expanding it.
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3).
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .

This feature is scheduled for FlightGear 2020.4[1]. 10}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.


FGTraffic
Developed by Durk
Initial release n/a (RFC) [2]
Latest release n/a
Written in C++
OS Cross platform (using cmake)
Development status request for comments
License GNU General Public License v2
[n/a Website]

Background

After a couple of years of intense involvement, development of the AI traffic system came to quite a sudden halt after Durk's day job responsibilities had to take precedence. Durk has been very reluctant to pick up the pace again afterwards, because he's been in much doubt whether to continue with the existing code base or to restart from scratch.[3]


Durk is inclined to break away from the approach he took for the current AI traffic system. The code has become too clunky too be maintainable, he will try to spend a limited portion of his development time for bug fixing the current code, but please don't expect any major changes any more. The new approach he has in mind should surpass everything we currently have, but it's going to take some time until it's all implemented. [4]

Status

Durk is currently leaning towards developing a system that uses a locally run mp server that connects one or more given instances of FlightGear with an AI Traffic generator [5]. For now, it seems like using the current multiplayer server will be sufficient for testing purposes. Once Durk has something decent running, he will leave it up to the maintainers of the multiplayer infrastructure whether they want to allow AI traffic to be pushed onto the multiplayer network.[6]


It's Durk's explicit intention to make the new system 100% compatible with the current content (traffic database, AI Aircraft, liveries, etc). Finally, although Durk wants to keep the technical side of the discussion focused on the mailing list, as per project policy, he's open to suggestions for improvement from content developers. [7]

Motivation

To summarize, in the current code base, world wide AI Traffic is controlled from an aircraft and flight information database, known as the Traffic Manager. Whenever an aircraft is sufficiently close to the user’s aircraft, a more detailed simulation is set up using the AIModels code. Currently, the user controlled aircraft can interact with the AI generated flights in a very limited fashion.[8]

the ability of ‘ATC’ to also set AI objects such as carriers, thermals for glider events and the weather centrally for consistent runway selection + ATIS are all valuable. Essentially the ‘world state’ (other objects besides the local aeroplane) should come from ‘the MP/AI’ source’ which could be the current MP network, or could be a local simulation of traffic, weather, dual controls, AI scenarios or whatever. How the world state is calculated for each scenario is then to be decided, if someone can create ‘traffic’ aircraft which can exist in the MP+ATC environment then fantastic but I expect this needs to be regulated somehow.[9]

Limitations

There are a number of severe limitations of the current approach and therefore Durk decided that it is probably a much better idea to start developing something new from scratch. [...] More specifically, there are the following fundamental limitations in the current code base:

  • AI traffic runs in the FlightGear main loop
  • AI traffic cannot currently make use of existing FlightGear subsystems (FDMShell, Autopilot, Route Manager), i.e. there is code duplication [10]
  • AI Traffic is not synchronized across multiple instances of FlightGear
  • Unclear distribution of labor between the AIModels, ATC, and Traffic Manager subsystems
  • A single set of (hard-coded) traffic rules may work well at one airport, but fail miserably at another one.
  • The development cycle is slow due to the requirement to recompile, restart and wait until specific conditions are met.
  • The currently huge traffic database results in slow updating of all Traffic Manager controlled aircraft, resulting in slow and inconsistent initializations[11]

The Future

To eliminate these problems, Durk is proposing to slowly deprecate the current approach, in favor of a more distributed approach. The idea is to write a standalone program that is interacting with the FlightGear multiplayer system, the general idea is that this new program can either transmit AI traffic data via a multiplayer servers, or that it directly communicates with FlightGear by acting as a multiplayer server itself, the details of which still need to be worked out, but the general idea is that the new traffic generator will receive positional information from FlightGear, and in exchange generate traffic information for a small radius surrounding the user-controlled aircraft.[12]

The test setup consists of a local multiplayer server running on a linux box, one instance of FlightGear running on the same machine, and a second instance of FlightGear running on a laptop. From here, Durk intends to replace the FlightGear instance on the laptop with something the generates traffic, and feeds that to the local multiplayer server.[13]

Design

Retaining accessing values like the root property tree, fg_home and the subsystems via a structure /called/ globals (in a class called FGGlobals, whatever it contains) keeps the code much closer to what we currently have, and doesn’t reduce testability or modularity at all.[14] There is no reason to suggest any test binary or AI/Traffic add-on would not run its own subsystem manager (and the same for timing, potentially).[15]


The preference would be to have the intelligence reside on the Traffic generator side. If we decouple it from FlightGear, there's no fundamental limit at how smart wek can make these aircraft.[16]


One major advantage of going for a distributed approach is that we can make each single AI aircraft as smart as we want. In addition to having autopilots and a simple FDM might be to add some real AI to these aircraft, i.e. mimic some pilot behaviour that goes beyond just simple autopilot functionality. For instance, it would allow us to more easily simulate VFR traffic, or pilots executing missed approaches in function of deteriorating wether conditions. All of this would make the virtuals skies more interesting.[17]

Our multiplayer protocol has a lot of room for being more "energy efficient" and we should be able to push more information around without increasing bandwith [...] if AI information can be reduced to some waypoint information ("proceed direct FOBAR") it /might/ work. [18]

Erik is working on a simple linear 6DoF FDM specific for AI aircraft, he will add the code to FDM/SP at some point just for manual testing. [19]

The goal for the AI FDM Erik is working on is just that, no fancy capabilities but enough to make it feel real. Therefore it will use a select number of linear coefficients rather than full 3D tables.[20]


Durk willl probably start working by reusing the current AIModels code. Once that's more or less on the road, we can work out the details on incorporating Erik's FDM into this.[21]


Every AI entity might need:

  • a simple autopilot
  • a simple linear 6 DoF FDM

Then you would instruct the AI model to fly from way-point to way point (implicitly, that also means having Route Manager support) and let the autopilot decide which actions to take for a certain stage (gear up/down, flaps extended/retracted, compensate for wind, like crabbing, possibly gear compression, etc). By building it up in modules like this from the start you could start with very simple code but make it smarter and more realistic due time. [22]


One approach would be to extend the MP protocol into an ‘AI’ protocol, and have the option to run all current AI types (carriers, tankers, scenarios, MP, traffic) via that protocol. With the same prediction in the client (current flightgear side) but nothing else really. Then we run the ‘server’ side which runs scenarios / traffic / carriers as a separate thread or process. Ideally we allow a given FG client to show ‘AI objects’ from multiple sources for testing. When you connect to an ‘MP’ server you’re really joining a consistent simulation environment, whether that be a local server, local thread or an Internet server. Oh, weather should also fit into this ideally, so again weather comes from ‘the world’, again that might simply mean a local thread commonly but as soon as you’re flying MP it should be more. This is quite achievable but we need to decouple some code from the local property tree, and have some way to configure the systems (eg current weather and scenarios GUIs).[23]

We should also try to keep it able to run inside fgfs as a thread, as well as living in its own process. We can easily short-circuit the networking layer to efficiently pass messages between the threads.[24]

it would be good for such a distributed approach to also work in a HLA environment if we ever get that off the ground.[25]

Which means we need to explore if it is feasible to start using the multiplayer protocol and eventually replace the MP protocol with an HLA one?[26]

Related

References

References
  1. https://sourceforge.net/p/flightgear/mailman/message/35485443/
  2. https://sourceforge.net/p/flightgear/flightgear/ci/f7424271a7fa1bf0ae0061f9a266e6b06de69597/
  3. Durk Talsma  (Nov 11th, 2016).  [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  4. durk  (Nov 12th, 2016).  FGTraffic 2020: Road map for a new AI traffic system design .
  5. https://sourceforge.net/p/flightgear/flightgear/ci/f7424271a7fa1bf0ae0061f9a266e6b06de69597/
  6. Durk Talsma  (Nov 14th, 2016).  Re: [Flightgear-devel] Proposal for storing the mp server information in DNS instead of a web service .
  7. durk  (Nov 12th, 2016).  FGTraffic 2020: Road map for a new AI traffic system design .
  8. Durk Talsma  (Nov 11th, 2016).  [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  9. James Turner  (Nov 15th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  10. http://flightgear.org/forums/viewtopic.php?p=134970#p134970
  11. Durk Talsma  (Nov 11th, 2016).  [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  12. Durk Talsma  (Nov 11th, 2016).  [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  13. Durk Talsma  (Nov 14th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  14. James Turner  (Nov 27th, 2016).  Re: [Flightgear-devel] RFC: Improving FlightGear's modularity .
  15. James Turner  (Nov 27th, 2016).  Re: [Flightgear-devel] RFC: Improving FlightGear's modularity .
  16. Durk Talsma  (Nov 14th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  17. Durk Talsma  (Nov 12th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  18. Torsten Dreyer  (Nov 12th, 2016).  Re: [Flightgear-devel] Proposal for storing the mp server information in DNS instead of a web service .
  19. Erik Hofman  (Nov 15th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  20. Erik Hofman  (Nov 16th, 2016).  Re: [Flightgear-devel] How does it all go together? (some worries) .
  21. Durk Talsma  (Nov 15th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  22. Erik Hofman  (Nov 11th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  23. James Turner  (Nov 12th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  24. James Turner  (Nov 14th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  25. Stuart Buchanan  (Nov 15th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .
  26. Durk Talsma  (Nov 15th, 2016).  Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic .