AI Traffic: Difference between revisions

Jump to navigation Jump to search

AI Traffic (view source)

Revision as of 12:51, 18 May 2020

397 bytes added ,  18 May 2020
m
Groundnets Intro and Tech perspective refresh & udpate
m (Re ordered Pushback section, Positive Examples first, caveats last)
m (Groundnets Intro and Tech perspective refresh & udpate)
Line 288: Line 288:


== Ground networks ==
== 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 pick up this type of routing information from an XML file inside the <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml</tt>, where ICAO stands for the 4 letter ICAO code for the airport in question.


For example, see the ground network for EHAM, which is found in <tt>[[$FG_SCENERY]]/Airports/E/H/A/EHAM.groundnet.xml</tt>. See the end of this page for a small excerpt from this file.  
[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircrafts can park precisely at the Terminal gates]]
 
Using the traffic files information above, the AI Traffic Manager knows which AI aircraft should land at (and take off from) each airport and when. It will automatically place the relevant aircraft models in the scenery and animate them so they navigate from the runways to the gates and vice versa, according to their individual schedule.
 
Although the physical layout of each airport is stored in FlightGear's APT.DAT master file, the information is not accurate enough to determine which specific routes AI models can use; Instead, Traffic manager will rely on a dedicated file containing a simple wireframe/network of taxiways and gates AI aircrafts can follow whilst on the ground ie a GroundNet. A groundnet is made of 3 different elements: Parking Positions, Nodes and Segments (to join nodes and Parking together).
 
This routing information is aggregated, per airport, in a XML, stored and distributed by Terrasync as '''/Terrasync/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml''' where ICAO stands for the 4 letter ICAO code of the relevant airport.
 
Similarly to Terrain and Objects, Terrasync groundnets can be overridden by placing a personalized version in your custom scenery folder, using the same path structure: /Custom Scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml.
 
Older versions of FlightGear store groundnets on your computer as $FG_SCENERY/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml
 
Groundnets are not mandatory but, in absence of this routing information, AI Aircrafts cannot park anywhere; they will still try to stick to their schedule, appearing magically at the centre of the airport and taxiing directly to the runways’ thresholds, over grass, buildings and static objects, on time.
 
Groundnets rely on the runway threshold information stored in /Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml to calculate the point at which an AI aircraft has reached a runway and can initiate take off, along the headings stored in this very same file.  


FlightGear versions older than 2.4.0 look up the ground network in <tt>[[$FG_ROOT]]/AI/Airports/[ICAO]/parking.xml</tt>.


=== A technical perspective ===
=== A technical perspective ===
A ground network xml file consists of four major sections:
A ground network xml file consists of four tables:
* 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.  
* '''<frequencies>''' The Airport’s radio frequencies (Optional). As of v1.9.0, FlightGear uses these to display some ATC messages like start-up approval requests. You can "hear" them by tuning to the first ground frequency listed in the section.
* The second section of the file contains the parameters of the airport's parking locations.
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircrafts can use them.
* The third section contains a list of all the nodes in the ground network.
* '''<TaxiNodes>''' The list of all the nodes in the ground network.
* The fourth and final section contains a list of segments, or "arcs" as David Luff called them initially, which basically describe which node is connected to which other node.  
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.


Each parking and AI node has a unique index number, which is used by the
Each Parking and Node element in the groundnet has a unique index number, allowing routes be formed (from one ID to the next via a segment/arc) between parking positions and runways
segments to link the startup location and the taxiways together. Parking spaces and
AI nodes have the following parameters:
* '''index (unique, consecutively numbered id)
* '''lat''' (latitude in decimal minutes format, for example <code>N50 56.988</code>)
* '''lon''' (longitude in decimal minutes format, for example <code>W01 21.756</code>)
* '''name''' (name as found on airport charts, for example <code>D23</code> or <code>C1</code>).


In addition, each parking space has a number of additional parameters:
''Parking Positions Parameters:''
* '''type:''' specifies what type of aircraft can use this parking space. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are:  
* '''index''' Unique ID, internal to the file structure
* '''lat''' latitude in decimal minutes format, for example <code>N50 56.988</code>)
* '''lon''' longitude in decimal minutes format, for example <code>W01 21.756</code>)
* '''name & number ''' (gate identification as found on airport charts, for example <code>D23</code> or <code>C1</code>).
* '''type:''' The type of aircraft which can use this space. Matched to the <flighttype> parameter found in traffic files:
** '''ga''' (general aviation),  
** '''ga''' (general aviation),  
** '''cargo''' (cargo)
** '''cargo''' (cargo/freighter)
** '''gate''' (commercial passenger traffic)  
** '''gate''' (commercial passenger traffic)  
** '''mil-fighter''' (military fighter)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)
** '''mil-cargo''' (military transport)
* '''heading:''' The heading at which the aircraft parks in this space.
* '''radius:''' The size of the parking spot. Matched to the aircraft <radius> parameter in traffic files to determine if a given AI Aircraft model will fit the position. See [[aircraft radii]]
* '''airlineCodes:''' a comma-separated list of ICAO airline codes allowed to park at this gate. Matched to the aircraft  <airline> parameter of traffic files. Leave blank for all airline to be able to use the gate.
* '''pushBackRoute:''' The ID of the next node in the network along a pushback route. 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.
''Nodes parameters:''


* '''number:''' Currently used in combination with the <name> parameter to determine the full name of the gate.
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, 0 otherwise. Aircrafts waiting to take off will line up behind the last node marked “not on runway” (“0”) until the runway is clear
* '''heading:''' The heading at which the aircraft are parked in this space.
* '''holdPointType''' can have the following values:
* '''radius:''' A value used to determine whether the aircraft will fit in this space: 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.
** '''None''' Not a holding point (normal taxi-through node)
* '''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.
** '''PushBack''' The node marks the end of a pushback route, where the aircraft stops rolling backward and start rolling forward upon clearance. A pushback Holding Point can be part of more than one pushback route. See Pushback 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.
** '''Normal''' (Not yet supported): a regular taxiway holding point.
** '''CAT II/III''' (Not yet supported): a special holding point for IFR conditions.


Taxiway nodes contain two additional parameters:
''segments parameters:''
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, or 0 otherwise
* '''holdPointType''' Describes whether the current point should be considered a holding point. This parameter can have the following values:
** '''none''' No holding point
** '''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.
** '''PushBack''' A push back hold point type. Each parking space can be connected to one and only one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can be only one connected to each gate or parking space.


Finally, the taxiway segments contain three parameters.
* '''begin''' The id of the parking space or AINode where this segment starts
* '''begin''' The id of the parking space or AINode where this segment starts
* '''end''' The id of the parking space or AINode where this segment ends
* '''end''' The id of the parking space or AINode where this segment ends
BecOzIcan
86

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/124742"

Navigation menu