86
edits
AI Traffic: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 3: | Line 3: | ||
'''AI Traffic''' (Artificial Intelligence), '''AI-Traffic''', or '''Interactive Traffic''' was introduced with [[FlightGear]] version 0.9.5. The purpose of AI traffic is to automatically populate airports sceneries with animated aircraft models reflecting the actual daily movements at and between airports to enrich the flightgear experience and improve its realism. This page aims at providing the documentation needed to populate airports with AI traffic. | '''AI Traffic''' (Artificial Intelligence), '''AI-Traffic''', or '''Interactive Traffic''' was introduced with [[FlightGear]] version 0.9.5. The purpose of AI traffic is to automatically populate airports sceneries with animated aircraft models reflecting the actual daily movements at and between airports to enrich the flightgear experience and improve its realism. This page aims at providing the documentation needed to populate airports with AI traffic. | ||
In essence, the AI controlled traffic system is comprised of | In essence, the AI controlled traffic system is comprised of four elements: | ||
# AI Aircrafts models : Are part of the base package under <tt>$DATA/AI/Aircrafts</tt> and cannot be flown by end user like regular FDM models as they are dedicated and exclusive to AI systems. | # AI Aircrafts models : Are part of the base package under <tt>$DATA/AI/Aircrafts</tt> and cannot be flown by end user like regular FDM models as they are dedicated and exclusive to AI systems. | ||
# AI traffic schedules : Are part of the base package under <tt>$DATA/AI/Traffic</tt> and define where and when AI aircrafts should fly. Files are unique per Operator's ICAO and split in sub-folders using the ICAO Initial. For example, traffic for United Airlines is stored under <tt>[[$FG ROOT]]/AI/Traffic/U/UAL.xml</tt> | # AI traffic schedules : Are part of the base package under <tt>$DATA/AI/Traffic</tt> and define where and when AI aircrafts should fly. Files are unique per Operator's ICAO and split in sub-folders using the ICAO Initial. For example, traffic for United Airlines is stored under <tt>[[$FG ROOT]]/AI/Traffic/U/UAL.xml</tt> | ||
# Groundnets : Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircrafts on the ground from gates to runways and vice versa, at each individual airport (one per airport) | # Groundnets : Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircrafts on the ground from gates to runways and vice versa, at each individual airport (one per airport) | ||
# Runway Use : Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and condition which runway(s) are for AI take off and landings based on the time of the day and wind conditions. | |||
| Line 498: | Line 500: | ||
=== Airports with ground networks === | === Airports with ground networks === | ||
= Runway Usage Configuration = | |||
ICAO.rwyuse.XML dictates which runway(s) should be used for AI take off and which ones accept AI landings (Runway Configuration Pattern), based on the time of the day and wind conditions. Examples below taken from the Amsterdam Schiphol EHAM.rwyuse.xml file. | |||
Wind conditions are stored at the beginning of the file and indicate the maximum values of Crosswind and Tailwind acceptable authorise take off and landing at the airport the file refers to. These values vary with each airport and shall be sourced from published data. | |||
<syntaxhighlight lang="xml"> | |||
<wind tail="7" | |||
cross="20" /> | |||
</syntaxhighlight> | |||
Each pattern (schedule) activation is determined by the < time > table in the file. | |||
For instance, at EHAM, the commercial "inbound" schedule/pattern is active from 06:20 to 08h30 UTC, at a time where there is more inbound than outbound traffic and the airport needs to allocate more runways to landing than to take off. | |||
<syntaxhighlight lang="xml"> | |||
<time start = "06:20" | |||
end = "08:30" | |||
schedule = "inbound"/> | |||
</syntaxhighlight> | |||
In most cases, a single schedule can apply 24h every day. | |||
<syntaxhighlight lang="xml"> | |||
<time start = "00:00" | |||
end = "24:00" | |||
schedule = "Day"/> | |||
</syntaxhighlight> | |||
The different patterns of runways allocation are listed in each < schedule > table by order of preference and can be read/deciphered vertically as ”columns” delimited by commas. | |||
When wind conditions do not allow the use of a pattern, the next one will apply (next “column”). | |||
Still using the EHAM.rwyuse.xml file as example, from 06:20 to 08:30 UTC, when the Inbound schedule applies; AI traffic will preferably use runway 36L for take-offs, and both 06 and 36R for landings (first “column” of data). | |||
<syntaxhighlight lang="xml"> | |||
<schedule name="inbound"> | |||
<takeoff>36L, 24, 18L, 36L, 24, 24, 18L, 09</takeoff> | |||
<landing>06, 18R, 18R, 36R, 27, 18R, 18R, 06</landing> | |||
<landing>36R, 18C, 18C, 36C, 18R, 22, 22, 09</landing> | |||
</schedule> | |||
</syntaxhighlight> | |||
Shall wind conditions prevent the use of this configuration (Tailwind or Crosswind values exeeding the ones defined in <wind> above), the next pattern or “column” will apply ie 24 for take-offs, and 18R + 18C for landings. | |||
Again, if wind conditions prevent this configuration use, the next pattern will be used (18L for take-offs, 18R and 18C for landing). | |||
This test of runway patterns against wind values will continue with the rest of the patterns until a valid one is found and applied. | |||
It is necessary for each of the <takeoff> and <landing> entries to have an equal number of runway values, per schedule, so each pattern contains the same number of runways. | |||
[https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAMbEsE46ontK4G43zmrEqLEk%3D8ZK5sQ-vxZup%3DNjpaUDgb-ASw%40mail.gmail.com/#msg37166996 Source from Durk post in Devel] | |||
= Model Animation = | = Model Animation = | ||