FGTraffic
| This article is a stub. You can help the wiki by expanding it. |
| Note Development on this has stalled |
 |
The FlightGear forum has a subforum related to: AI Traffic |
| Developed by | Durk |
|---|---|
| Initial release | n/a (RFC) [1] |
| Latest release | n/a |
| Written in | C++ |
| OS | Cross platform (using cmake) |
| Development status | stalled [2] |
| 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]
Scripting
For the time being, AI scenarios are hardly ever generic in the sense that you have to specify positions in advance. The beauty of the Nasal AI tanker is that you notice you run out of fuel, you can call it and it'll be with you runtime, and it'll avoid cloud layers at your location. The AI tankers you have to set up in advance and they'll follow their flightplan even in dense clouds. The AW thermals will just be there where there is a cloud generated anyway - no need to think in advance where you want to have them. AI scenarios may seem pretty useless unless you want to spend some time to prepare a special mission setup - like FGUK sometimes does - i.e. have a tanker waiting at a pre-arranged position, have a ship in distress you must find and rescue, have an intercept target... Which definitely is a valuable use case, but it requires more than casual user skills to get anything out of it because you need to understand AI scenario configuration and edit xml. But, well, hardly generic. [8]
the AI system has pretty low overhead (ignore the traffic system which does a lot of work), whereas hundreds more Nasal objects, could have quite a serious impact. James stated his preference there would be to add a Nasal-C++ object analogous to AIbase which Nasal can control (set motion parameters, etc) but which does its per-frame updates in C++ with no timers or update loops on the Nasal side. (Or even via some PID controllers, so Nasal could set heading / speed / rate-of-climb infrequently but have a ‘NasalAIAircraft’ then run the PIDs and motion updates in C++.[9]
Erik started the AISim FDM (found under src/FDM/SP for now) but unfortunately he did not have time to finish it. Also there is a generic-ish autopilot developed which could be used to fill in the missing gaps.[10]
property rules are perfectly up to the job. Thorsten found a hybrid approach with Nasal doing the high-level decisionmaking and AP code doing the frame-to-frame work rather successful.[11]
Consider the following use case: a six deg of freedom motion solver for a Flight Manual folder in the Shuttle cabin - you can see it float in mid-air inero g, watch it bounce against the walls when you fire thrusters or observe it slowly spinning down due to air friction. http://www.science-and-fiction.org/FG/pics/milestone9_01.jpg http://www.science-and-fiction.org/FG/pics/milestone9_04.jpg It's a rather special use case, we're unlikely to need hundreds of these, and it illustrates what scripting can do in terms of objects and their interaction with your craft. )[12]
also, it might be premature to assume all AI stuff is airplane... the shuttle's floating manual folder doesn't have a rate of climb, it has an inertial position, an inertial speed and it feels wall interactions and gravity. It seems, the only ability we need is an fgcommand which takes a file path as an argument and dynamically instances the content as property rules runtime. Right now what we can do is have property rules (or AP tags) prepared at startup time and (at least in JSBSim) we can switch the channel to active when we need it, but we can not dynamically instance property rule or AP computing chains. Say if I want to simulate missile fired and I have an equation of motion solver coded, I need to have the tags for every missile written in the aircraft xml and set channel[i] active when firing missile i. It'd be much nicer to instance the channel the moment a missile is needed. Thus, I suspect to make your preferred option (which is also my preferred option) possible would be easy, but, well, for aircraft-side or addon-side stuff, it'll not be guaranteed that it's actually used....[13]
Motivation
To summarize, in the current code base, worldwide 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.[14]
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.[15]
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 [16]
- 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[17]
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.[18]
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.[19]
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.[20] 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).[21]
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.[22]
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.[23]
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. [24]
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. [25]
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.[26]
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.[27]
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. [28]
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).[29]
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.[30]
it would be good for such a distributed approach to also work in a HLA environment if we ever get that off the ground.[31]
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?[32]
Related
- Scripted AI Objects
- Ground Services
- mpdummy
- Fgms - the FlightGear multiplayer server
- Multiplayer protocol
- FGRadar - a SGSubsystemMgr-based standalone program reusing a handful of FlightGear subsystems (by IcecodeGL)
- FGAIS - an fgms-based program to inject arbitrary traffic/feeds into FlightGear using the existing MP infrastructure (by F-JJTH)
- High-Level Architecture - Stuart's ongoing work on integrating Mathias' HLA/SimKit groundwork into FlightGear
- fgai - AI via HLA