AI Traffic: Difference between revisions

Traffic patterns are stored in data files in extended markup language (.xml) format. The actual location of these files are version dependent. For FlightGear 0.9.x, traffic files are  stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in:

For FlightGear 1.9.0 and later, a new traffic file format was introduced (henceforth referred to as "traffic manager II" format (TM-II), in which aircraft and flights are no longer directly coupled, leading to more flexibility.  

== Defining a flight ==

The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g.,

             <repeat>WEEK</repeat>

         </flight>

The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels, however, these should mostly be self-explanatory. The following keywords should be specified:

After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In earlier versions of FlightGear, this used to involve quite a bit of editing, because every file had to be referenced in a master traffic file, named fgtraffic.xml.

Since traffic files for FlightGear 1.9.0 are stricktly speaking no longer tied to one particular aircraft, or aircraft type, the traffic files were moved to a different directory, namely data/AI/Traffic. Again, the actual traffic files should be stored in a subdirectory one level below /AI/Traffic. In the demo that is provided with FlightGear 1.9.0, all traffic is organized by airline, and stored in a single letter directory. For example, KLM traffic can be found in data/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in data/AI/Traffic/U/UAL.xml. Although currently no formal definition exists for military or general aviation traffic, a similar scheme could be adapted. For instance, military traffic could be placed in data/AI/Traffic/mil/USAF.xml

Secondly, the author of the traffic manager code has written some scripts, mainly for private use,  that will allow one to input the flight data into a simple text format and then convert the resulting text file to xml. These scrips are not available yet, because they haven't been tested well enough for general use, but that is likely to change in the not too distant future.  

= Ground networks =

The next major aspect of the AI traffic system contains taxiway information. Although the physical layout of each airport is contained in FlightGear's airport database, this information is not sufficient to provide taxiway information. Therefore AI aircraft pickup this type of routing information from an xml file inside the data/AI/Airports directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called data/AI/Airports/[ICAO]/parking.xml, where ICAO stands for the 4 letter ICAO code for the airport in question.  

excerpt from this file. It should be noted that current development work is planned that aims to move these files from the base package to the scenery repository, so that ground network information and the physical layout of the airport can be updated in parallel. Once this is done, the new location / name for the file will be [fg-scenery]/Airports/[ICAO1]/[ICAO2]/[ICA03]/[ICAO].groundnet.xml. Here [ICAO] stands for the 4 letter ICAO code of the airport in question, and [ICAO1], [ICAO2], and [ICAO3] for the first to third letter of this code.  

In addition, FlightGear cvs of approximately the same date also has support for reading the ground networks from the scenery directory. This feature is not enabled by default. To enable, make sure the property /sim/traffic-manager/use-custom-scenery-data is set to true. This can be done by editing preferences.xml or specifying this property on the command line.  

== A technical perspective ==  

A ground network file consists of 4 major sections. The first section is optional, although recent versions of TaxiDraw add this section automatically. This section contains a list of all the radio frequencies for the airport in question. FlightGear currently (as of 1.9.0) uses these frequencies to display some ATC messages. As of FlightGear 1.9.0, only startup approval requests are implemented. You can "hear" these by tuning to the first ground frequency listed in the frequencies section.  

* '''lon'''    (position in longitude)

* '''name'''  (name as found on airport charts: e.g. D23, or C1).  

In addition, each parking has a number of additional parameters:

** '''mil-fighter'''  (military fighter)

** '''mil-cargo'''    (military transport)

* '''number:'''  Currently used in combination with the <name> parameter to determine the full name of the gate.

== TaxiDraw ==

=== Obtaining TaxiDraw ===

Windows users can also do this either by using the free winCVS program or  

=== Creating the network ===

==== Set up a rough outline ====

To make best use of the background image, right click, choose the "view" menu, and unselect "taxiways", this way, all network drawing can be based on the real airport location. First, select the "Insert startup location" edit mode. This way, each left mouse click will place a startup location at the position of the mouse cursor. Once the major startup locations have been placed, switch back to "selection" mode, by clicking the little arrow button.  

Repeat this procedure until all parking locations are connected to each runway.

==== Refining the network: Mark points on the runway as such ====

With the basic infrastructure in place, the next step is to fine-tune the network. The first step in this process is to mark the network nodes that are located on a runway. This is important for a number of reasons: Taxidraw needs these OnRunway points for it's network verification tool. Secondly, the use of the type of runway marking will be used in future versions of FlightGear for runway entrance / exit calculations, in addition to a host of other possible uses in routing (such as blocking a certain node then a crossing runway is in use, etc, etc).  

==== Refining the network: Set Holding points ====

Holding points are nodes in the network that do something special. They can be used by FlightGear to make traffic wait at certain specific locations. As a matter of fact, the 'normal' and 'Cat II/III' hold points are not yet used by FlightGear, but are part of the development plan. Currently, hold points are implicitly assigned by the FlightGear AI code. For instance, traffic waiting for takeoff clearance is holding at the first point before the runway. Likewise, traffic can receive a hold position instruction just before an intersection in the taxiway system, when traffic is approaching at the other leg. While these implicit hold points work reasonably, there are some limitations. Consider for example runway 07 at CYYC (Calgary Intl, Canada). In the FlightGear rendition of this airport, there are no taxiways leading to this runway, so departing aircraft should back track the runway from an entrance point at the middle of the runway. Currently that point will also become the runway entrance holding point. This is clearly undesirable, because it means that traffic is actually waiting ''on the runway'' in order to get clearance to enter it. For this reason, airport ground network designers should have a means to have explicit control over holding points. The normal hold point is meant for just that.

==== Refining the network: Pushback routes ====

With the above-mentioned refinements, the ground network should be fully working, with one notable exception. Aircraft will be driving forward when leaving the gate, making a sharp turn (while probably destroying themselves and the terminal building in the process). To prevent this, a ''push back'' route should be created. A push back route consists of at least one or more taxiway segments that have the "PushBack Route" property set to true. The last of these segments should be terminated by a PushBack HoldPoint network node.  

It is important to note that the "Verify Ground network" process ''should be run'' in order to get a correctly working push back system, because this function runs some internal consistency checks. Push back routes can be very simple, from just one route segment, to fairly complex, as illustrated below. Shown here are 3 examples from the EHAM ground network. 1) Shows a fairly complex example, where all aircraft from one side of the E terminal are being linked to one shared push back point. In the example, the push back route of an aircraft departing from gate E20 is illustrated. 2) Shows a simple example, where one aircraft is being pushed back, and makes a left turn. In essence, 3) shows a similar example, but now in a slightly more crowded space, where pushback nodes are overlapping. The current push back system allows for fairly complicated behavior. To get a full understanding of it's workings, it is advisable to play with some of the existing ground networks. EHAM and KFSO currently provide the most complex setups.  

==== Verifying the network ====

Finally, with a network complete, it is important to verify it! The verification function not only detects obvious problems with the network, it also updates some internal states that FlightGear relies. on. Presumably, an automatic verification process will be added to the export function, but until that is the case, make sure to do this manually. The verify network function can be found in the "Tools" menu.  

* '''On runway points''' Added on January 24, 2009, this check is most likely not yet available in any distributed version. This is currently just a very lame check to see if any point in the network has been marked as such. This check is not exhaustive, but simply meant as a reminder to the editor that the OnRunway points should still be marked. Ultimately, this check should be replaced by the aformentioned automatic geometry function.

== Editing the startup location parameters ==

== Copying the ground network into FlightGear's data directory ==

== Testing the network ==

= SIDs / STARs =

SID is an acronym for Standard Instrument Departure. Likewise, STAR is an acronym for [[Standard Terminal Arrival Route]]. Directly after takeoff, in particular at busy airports, aircraft follow a standard flightpath, that will keep them safely separated from arriving traffic, avoid ground obstructions, and also keeps traffic away from populated areas as much as possible. Currently, steps are in progress to allow FlightGear traffic to follow SIDs. Ultimately, the plan is to provide SID and star data in a format that can also be used by the user controlled Aircraft's Flight Management Computer. Currently, some sample data exist in the form of a PropertyList formatted xml file that contains a list of waypoints.  

= Appendix: Special Notes =

== Realism ==

With [[FGFS 1.0.0]] Interactive Traffic also responds to other Non-AI aicraft.

==Perfomance==

Unfortunately you can't change this at runtime yet, so you need a little bit trial and error! However, it should allow the combination of slower computers and dense traffic files.

==External links==