4,400
edits
AI Traffic: Difference between revisions
Jump to navigation
Jump to search
m
Robot: Cosmetic changes
m (Bot: Automated text replacement (-aicraft +aircraft, -aircaft +aircraft)) |
m (Robot: Cosmetic changes) |
||
| Line 11: | Line 11: | ||
== Building Traffic Files == | == Building Traffic Files == | ||
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 | 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: | ||
<tt>[[$ | <tt>[[$FG ROOT]]/Traffic/</tt> | ||
In FlightGear 1.0, the traffic files can be found in a subdirectory of: | In FlightGear 1.0, the traffic files can be found in a subdirectory of: | ||
<tt>[[$ | <tt>[[$FG ROOT]]/AI/Aircraft/</tt> | ||
For example, traffic belonging to a united airlines 737 would be located in: <tt>[[$ | For example, traffic belonging to a united airlines 737 would be located in: <tt>[[$FG ROOT]]/AI/Aircraft/737/737-UnitedAirlines-traffic.xml</tt> | ||
FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in: | FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in: | ||
<tt>[[$ | <tt>[[$FG ROOT]]/AI/Traffic/</tt> | ||
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. | 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. | ||
| Line 31: | Line 31: | ||
== Some Details: TrafficManager, Aircraft, and Flights == | == Some Details: TrafficManager, Aircraft, and Flights == | ||
As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by [[McDonnell Douglas MD11]] aircraft. For instance, the MD11's operated by KLM | As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by [[McDonnell Douglas MD11]] aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day. | ||
In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis. | In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis. | ||
| Line 154: | Line 154: | ||
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments. | * '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments. | ||
* '''<flighttype>''' In the near future, this keyword will be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures. This line is also used for gate assignments and should be one of the following: | * '''<flighttype>''' In the near future, this keyword will be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures. This line is also used for gate assignments and should be one of the following: | ||
** '''ga''' | ** '''ga''' (general aviation), | ||
** '''cargo''' | ** '''cargo''' (cargo) | ||
** '''gate''' | ** '''gate''' (commercial passenger traffic) | ||
** '''mil-fighter''' | ** '''mil-fighter''' (military fighter) | ||
** '''mil-cargo''' | ** '''mil-cargo''' (military transport) | ||
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported: | * '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported: | ||
** '''light_aircraft''' (prop driven single or twin), | ** '''light_aircraft''' (prop driven single or twin), | ||
** '''ww2_fighter''' | ** '''ww2_fighter''' (world war two fighter), | ||
** '''jet_transport''' | ** '''jet_transport''' (modern commercial jet), | ||
** '''jet_fighter''' | ** '''jet_fighter''' (modern fighter aircraft) | ||
** '''tanker''' | ** '''tanker''' (tanker aircraft), or. | ||
** '''ufo''' | ** '''ufo''' (allows extreme accel/decel capabilities). | ||
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused. | * '''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused. | ||
*'''<heavy>''' Can be true or false. Reserved for future use by ATC, to determine whether the postfix "Heavy" should be appended to the aircraft's callsign. | * '''<heavy>''' Can be true or false. Reserved for future use by ATC, to determine whether the postfix "Heavy" should be appended to the aircraft's callsign. | ||
== Defining a flight == | == Defining a flight == | ||
| Line 232: | Line 232: | ||
One major motivation for introducing the traffic manager II file format is to make it easier for FlightGear users to contribute to the traffic database. To further motivate this, some tools are currently in development that aim to make user interaction even easier. Although most of these tools are not ready for public use yet, it is probably worth mentioning some of these developments. First of all, the custrom scenery project is working on extending their scene model database to store traffic. A web based front end will allow users to enter their favorite flight, and thus collect an extensive amount of traffic data. Users will be able to download the collected results and place the downloaded files in their traffic directory. | One major motivation for introducing the traffic manager II file format is to make it easier for FlightGear users to contribute to the traffic database. To further motivate this, some tools are currently in development that aim to make user interaction even easier. Although most of these tools are not ready for public use yet, it is probably worth mentioning some of these developments. First of all, the custrom scenery project is working on extending their scene model database to store traffic. A web based front end will allow users to enter their favorite flight, and thus collect an extensive amount of traffic data. Users will be able to download the collected results and place the downloaded files in their traffic directory. | ||
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. The most important of these scripts is now available for download | 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. The most important of these scripts is now available for download [http://www.xs4all.nl/~dtalsma/trafficdata.zip trafficdata.zip]. This zip archive contains a collection of traffic configuration files, along with a perl script to convert these scripts to xml. | ||
Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malayasian project): | Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malayasian project): | ||
| Line 291: | Line 291: | ||
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. | 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 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. | 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. | ||
| Line 303: | Line 303: | ||
segments to link the startup location and the taxiways together. Parkings and | segments to link the startup location and the taxiways together. Parkings and | ||
AI nodes have the following parameters: | AI nodes have the following parameters: | ||
* '''index | * '''index (unique, consecutively numbered id) | ||
* '''lat''' | * '''lat''' (position in latitude) | ||
* '''lon''' | * '''lon''' (position in longitude) | ||
* '''name''' | * '''name''' (name as found on airport charts: e.g. D23, or C1). | ||
In addition, each parking has a number of additional parameters: | In addition, each parking has a number of additional parameters: | ||
* '''type:''' specifies what type of aircraft can use this parking bay. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are: | * '''type:''' specifies what type of aircraft can use this parking bay. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are: | ||
** '''ga''' | ** '''ga''' (general aviation), | ||
** '''cargo''' | ** '''cargo''' (cargo) | ||
** '''gate''' | ** '''gate''' (commercial passenger traffic) | ||
** '''mil-fighter''' | ** '''mil-fighter''' (military fighter) | ||
** '''mil-cargo''' | ** '''mil-cargo''' (military transport) | ||
* '''number:''' | * '''number:''' Currently used in combination with the <name> parameter to determine the full name of the gate. | ||
* '''heading:''' The heading at which the aircraft are parked in this bay. | * '''heading:''' The heading at which the aircraft are parked in this bay. | ||
*'''radius:''' | * '''radius:''' A value used to determine whether the aircraft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above. FlightGear uses a standard list of [[aircraft radii]] for gate assignment. | ||
*'''airlineCodes:''' a comma-separated list of ICAO airline codes used to indicate which airlines should park here. Leave this field blank if you want any aircraft to park here. | * '''airlineCodes:''' a comma-separated list of ICAO airline codes used to indicate which airlines should park here. Leave this field blank if you want any aircraft to park here. | ||
*'''pushBackRoute:''' A number that refers to another node in the network. In a correctly configured network, the AI aircraft will taxi to this node in reverse, thus simulating being pushed back. See the documentation for the PushBack hold point type below. | * '''pushBackRoute:''' A number that refers to another node in the network. In a correctly configured network, the AI aircraft will taxi to this node in reverse, thus simulating being pushed back. See the documentation for the PushBack hold point type below. | ||
Taxiway nodes contain two additional parameters: | Taxiway nodes contain two additional parameters: | ||
* '''isOnRunway'''' | * '''isOnRunway'''' A logical value that is 1 when the node is on the runway, or 0 otherwise | ||
* '''holdPointType''' Describes wether the current point should be considered a holding point. This parameter can have the following values: | * '''holdPointType''' Describes wether the current point should be considered a holding point. This parameter can have the following values: | ||
** '''none''' | ** '''none''' No holding point | ||
** '''normal''' | ** '''normal''' A regular holding point. This point should be placed just before the runway entrance / exit points, so that traffic will not enter the runway before receiving clearance to enter the runway. Note that support for this type of holding point is not implemented yet, but should appear sometime during 2009. | ||
** '''CAT II/III''' A special holding point for IFR conditions. Currently not supported yet. | ** '''CAT II/III''' A special holding point for IFR conditions. Currently not supported yet. | ||
** '''PushBack''' | ** '''PushBack''' A push back hold point type. Each parking can be connected to maximally one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can maximally only be one connected to each gate. | ||
Finally, the taxiway segments contain three parameters. | Finally, the taxiway segments contain three parameters. | ||
* '''begin''' | * '''begin''' The id of the parking or AINode where this segment starts | ||
* '''end''' | * '''end''' The id of the parking or AINode where this segment ends | ||
* '''IsPushBackRoute''' a logical value. Should be one if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise. | * '''IsPushBackRoute''' a logical value. Should be one if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise. | ||
* '''name''' | * '''name''' Name of the taxiway. | ||
== Creating a ground network, a practical approach == | == Creating a ground network, a practical approach == | ||
| Line 348: | Line 348: | ||
the instructions on http://TaxiDraw.sourceforge.net/#download | the instructions on http://TaxiDraw.sourceforge.net/#download | ||
[[Ubuntu]] or [[Debian]] users may look at the [[ | [[Ubuntu]] or [[Debian]] users may look at the [[Ubuntu fg tools]] page to have TaxiDraw installed in a easy way. | ||
Windows users can also do this either by using the free winCVS program or | Windows users can also do this either by using the free winCVS program or | ||
| Line 395: | Line 395: | ||
Finally, please notice that you need a version of TaxiDraw with a build date of February 5, 2009, or later, for this to work correctly. Earlier version did not export the pushBackRoute attribute correctly. Support for this functionality was introduced late January 2009, but versions earlier than February 4 contain a potentially fatal bug, that may seriously damage your work. | Finally, please notice that you need a version of TaxiDraw with a build date of February 5, 2009, or later, for this to work correctly. Earlier version did not export the pushBackRoute attribute correctly. Support for this functionality was introduced late January 2009, but versions earlier than February 4 contain a potentially fatal bug, that may seriously damage your work. | ||
[[ | [[File:TaxiDraw2.png|500px]] | ||
==== Verifying the network ==== | ==== Verifying the network ==== | ||
| Line 415: | Line 415: | ||
Editing the starup location radius, type, airlineCodes, and pushBack parameters is not yet possible in TaxiDraw. So changing these requires saving the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project. | Editing the starup location radius, type, airlineCodes, and pushBack parameters is not yet possible in TaxiDraw. So changing these requires saving the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project. | ||
You can edit the remaining parameters by loading this groundnet.xml file into a text editor. Once you are done editing make sure you import these changes into TaxiDraw immediately. Do this by going to [File| Import FlightGear AI Network]. This will open a file selection dialog. Choose the file you just edited and click okay. TaxiDraw will ask for confirmation to overwrite existing ground network data and confirm this | You can edit the remaining parameters by loading this groundnet.xml file into a text editor. Once you are done editing make sure you import these changes into TaxiDraw immediately. Do this by going to [File| Import FlightGear AI Network]. This will open a file selection dialog. Choose the file you just edited and click okay. TaxiDraw will ask for confirmation to overwrite existing ground network data and confirm this by clicking on "yes". | ||
== Copying the ground network into FlightGear's data directory == | == Copying the ground network into FlightGear's data directory == | ||
Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in FlightGear's <tt>data/Airports/AI</tt> directory, with the name of the ICAO code of your airport. For example <tt>[[$ | Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in FlightGear's <tt>data/Airports/AI</tt> directory, with the name of the ICAO code of your airport. For example <tt>[[$FG ROOT]]/Airports/AI/EHAM</tt>. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml". | ||
== Testing the network == | == Testing the network == | ||
| Line 435: | Line 435: | ||
The [[Airbus A320|A320]] ( and maybe some others) has working flaps and gears. | The [[Airbus A320|A320]] ( and maybe some others) has working flaps and gears. | ||
==Perfomance== | == Perfomance == | ||
With FGFS 1.0.0, the AI Interactive Traffic needs a lot of CPU-power. With the current CVS-versions, however, we now have much better performance so realistic density of traffic is currently possible, even for slower computers. For those who are still afraid, there is an, as of yet, unpublished feature: Set a new property "/sim/traffic-manager/proportion" to any value between 0 and 1 in your preferences.xml. During program start up, the traffic manager draws a random number (between 0 and 1) for each aircraft, and if that random number is smaller than the value specified in /sim/traffic-manager/proportion, the aircraft is added, otherwise it is discarded. In essence, only the specified proportion of aircraft will be loaded. | With FGFS 1.0.0, the AI Interactive Traffic needs a lot of CPU-power. With the current CVS-versions, however, we now have much better performance so realistic density of traffic is currently possible, even for slower computers. For those who are still afraid, there is an, as of yet, unpublished feature: Set a new property "/sim/traffic-manager/proportion" to any value between 0 and 1 in your preferences.xml. During program start up, the traffic manager draws a random number (between 0 and 1) for each aircraft, and if that random number is smaller than the value specified in /sim/traffic-manager/proportion, the aircraft is added, otherwise it is discarded. In essence, only the specified proportion of aircraft will be loaded. | ||
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. | 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== | == External links == | ||
* [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page] | * [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page] | ||
* [http://www.ilovelinux.de/svn/fgfs-ffm/user/data/AI/ Created a dense AI traffic for EDDF, LSZH and a lot of other airports depending on real timetables. More to come!] | * [http://www.ilovelinux.de/svn/fgfs-ffm/user/data/AI/ Created a dense AI traffic for EDDF, LSZH and a lot of other airports depending on real timetables. More to come!] | ||