AI Traffic: Difference between revisions

Jump to navigation Jump to search

AI Traffic (view source)

Revision as of 07:52, 11 September 2023

49 bytes removed ,  11 September 2023
m
s/aircrafts/aircraft/
(→‎Ground traffic rendering: Add more info for different options to pack vertex data. Add a part about passenger and ground personnel animation options.)
m (s/aircrafts/aircraft/)
 
Line 4: Line 4:


In essence, the AI controlled traffic system is comprised of four elements:  
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 Aircraft models: Are part of the base package under <tt>$DATA/AI/Aircraft</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 aircraft 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).  The parking stands defined in an airport groundnet can also be used as Starting Positions when flying an FDM aircraft. They are shown and can be selected in Flightgear's "Location" startup tab.
# Groundnets: Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircraft on the ground from gates to runways and vice versa, at each individual airport (one per airport).  The parking stands defined in an airport groundnet can also be used as Starting Positions when flying an FDM aircraft. They are shown and can be selected in Flightgear's "Location" startup tab.
# Runway Use Configurations (RWYUSE) : 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.
# Runway Use Configurations (RWYUSE): 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 14: Line 14:
Traffic pattern describe the relationship between two separate entities: Aircraft and Flights.
Traffic pattern describe the relationship between two separate entities: Aircraft and Flights.


In real life, Flight Scheduling aims at maximizing the number of flights operated with the fleet of aircrafts available, taking in account each aircraft’s initial location, the length of each flight, the required turnaround time at each airport and of course the routes operated. In practice an aircraft will fly different routes of different length on different day/time and not all aircrafts will return to their home base the same day, especially in the case of long haul routes. The list of flights an aircraft will operate during a set period of time is the Aircraft Schedule.
In real life, Flight Scheduling aims at maximizing the number of flights operated with the fleet of aircraft available, taking in account each aircraft’s initial location, the length of each flight, the required turnaround time at each airport and of course the routes operated. In practice an aircraft will fly different routes of different length on different day/time and not all aircraft will return to their home base the same day, especially in the case of long haul routes. The list of flights an aircraft will operate during a set period of time is the Aircraft Schedule.
AI aircrafts provide some extra benefits: They do not need maintenance (or crew replacement) and so can be scheduled for use 24h00 per day; they are also never late nor cancelled hence they will perform 100% of their assigned flights on time.
AI aircraft provide some extra benefits: They do not need maintenance (or crew replacement) and so can be scheduled for use 24h00 per day; they are also never late nor cancelled hence they will perform 100% of their assigned flights on time.


To minimize the amount of data handled, a frequency is attached to each flight as either daily or weekly; For example an aircraft based at EHAM can fly daily in the morning to EGLL (and back) but then to different destinations in the afternoon depending on the day of the week (LFPG on Monday, EDDF on Tuesday etc). In this scenario the EGLL flights are operated daily and the LFPG and EDDF ones, weekly as it will take another full week before they are operated again.
To minimize the amount of data handled, a frequency is attached to each flight as either daily or weekly; For example an aircraft based at EHAM can fly daily in the morning to EGLL (and back) but then to different destinations in the afternoon depending on the day of the week (LFPG on Monday, EDDF on Tuesday etc). In this scenario the EGLL flights are operated daily and the LFPG and EDDF ones, weekly as it will take another full week before they are operated again.


Like in real life, the flights assigned to an aircraft must follow a logical routing sequence and the arrival city of one flight must be the departure city of the next (AI aircrafts do not time travel no teleport).  
Like in real life, the flights assigned to an aircraft must follow a logical routing sequence and the arrival city of one flight must be the departure city of the next (AI aircraft do not time travel no teleport).  
Flightgear schedules are set for a full week and repeat indefinitely until the traffic file is updated. As a result, the routing sequence described above must be consistent with the schedule weekly reset: If the last flight in an aircraft schedule (Sunday night) take it to KSFO then the first flight in the schedule (Monday morning) must depart from KSFO.
Flightgear schedules are set for a full week and repeat indefinitely until the traffic file is updated. As a result, the routing sequence described above must be consistent with the schedule weekly reset: If the last flight in an aircraft schedule (Sunday night) take it to KSFO then the first flight in the schedule (Monday morning) must depart from KSFO.
From the above. The Home Base of an aircraft is always the departure city of its first flight in the schedule ie the airport it will be departing from for its first flight on Monday morning.
From the above. The Home Base of an aircraft is always the departure city of its first flight in the schedule ie the airport it will be departing from for its first flight on Monday morning.
Line 162: Line 162:


=== Defining a flight ===
=== Defining a flight ===
The Traffic Manager II file formats contains separate sections for both aircrafts and flights information, with the common denominator being a shared key that links aircraft and flight information together. In other words, the general layout of a Traffic Manager II file looks something like this:
The Traffic Manager II file formats contains separate sections for both aircraft and flights information, with the common denominator being a shared key that links aircraft and flight information together. In other words, the general layout of a Traffic Manager II file looks something like this:
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
  <aircraft>  
  <aircraft>  
Line 210: Line 210:
All traffic is organized by Operator ICAO code, and stored in a single letter directory. For example, KLM traffic can be found in [[$FG_ROOT]]/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in [[$FG_ROOT]]/AI/Traffic/U/UAL.xml.
All traffic is organized by Operator ICAO code, and stored in a single letter directory. For example, KLM traffic can be found in [[$FG_ROOT]]/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in [[$FG_ROOT]]/AI/Traffic/U/UAL.xml.


The name of the file is the ICAO of the operator (aircraft owner) which is normally the same that the one found in the <airline> tag in the file itself but not alway. For example Compass Airlines in Minneapolis, has the ICAO code CPZ but operates flights for both American Airlines (AAL) and Delta Airlines (DAL). In this scenario the traffic file will be stored as [[$FG_ROOT]]/AI/Traffic/C/CPZ.xml and will contain a series of aircrafts with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.
The name of the file is the ICAO of the operator (aircraft owner) which is normally the same that the one found in the <airline> tag in the file itself but not alway. For example Compass Airlines in Minneapolis, has the ICAO code CPZ but operates flights for both American Airlines (AAL) and Delta Airlines (DAL). In this scenario the traffic file will be stored as [[$FG_ROOT]]/AI/Traffic/C/CPZ.xml and will contain a series of aircraft with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.


= Ground networks =
= Ground networks =


[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircrafts can park precisely at the Terminal gates]]
[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircraft 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.
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).  
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 aircraft 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.
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.
Line 224: Line 224:
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.
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.


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 are not mandatory but, in absence of this routing information, AI Aircraft 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 determine where runways are (the space between each pair of thresholds in the file) and their heading. This data is used to determine an aircraft has reached the runway and can initiate take off. Similarly it is used to select where an arriving AI aircraft can touch down and start braking.  
Groundnets rely on the runway threshold information stored in /Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml to determine where runways are (the space between each pair of thresholds in the file) and their heading. This data is used to determine an aircraft has reached the runway and can initiate take off. Similarly it is used to select where an arriving AI aircraft can touch down and start braking.  
Line 231: Line 231:
A ground network xml file consists of four tables:
A ground network xml file consists of four tables:
* '''<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.
* '''<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.
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircrafts can use them.
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircraft can use them.
* '''<TaxiNodes>''' The list of all the nodes in the ground network.
* '''<TaxiNodes>''' The list of all the nodes in the ground network.
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.
Line 255: Line 255:
''Nodes parameters:''
''Nodes parameters:''


* '''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
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, 0 otherwise. Aircraft waiting to take off will line up behind the last node marked “not on runway” (“0”) until the runway is clear
* '''holdPointType''' can have the following values:
* '''holdPointType''' can have the following values:
** '''None''' Not a holding point (normal taxi-through node)  
** '''None''' Not a holding point (normal taxi-through node)  
Line 336: Line 336:
FG Scenery and Traffic manager have their limitations and dependencies which create specific challenges of their own. For example:
FG Scenery and Traffic manager have their limitations and dependencies which create specific challenges of their own. For example:
[[File:AI Traffic at KJFK former Terminal 3.jpg|300px|thumb|AI Traffic sitting on top of KJFK former Terminal 3]]
[[File:AI Traffic at KJFK former Terminal 3.jpg|300px|thumb|AI Traffic sitting on top of KJFK former Terminal 3]]
* TM does not space landing aircrafts. You will most likely see packs of landing aircrafts hitting your runways at once, sometimes from both ends. Departures are spaced properly though  
* TM does not space landing aircraft. You will most likely see packs of landing aircraft hitting your runways at once, sometimes from both ends. Departures are spaced properly though  
* TM does not yet use Regular/Cat III Holding points data and so you cannot force an AI aircraft to pause/hold on a route.  
* TM does not yet use Regular/Cat III Holding points data and so you cannot force an AI aircraft to pause/hold on a route.  
* TM does not support the conditional use of gates (Do not use A if B is occupied); Always assume all the Parking position you set will be occupied.  
* TM does not support the conditional use of gates (Do not use A if B is occupied); Always assume all the Parking position you set will be occupied.  
* AI Aircrafts cannot "pivot" on their parking positions. The last segment on a route leading to or exiting a parking position must have the same heading than the parking position itself (Park Straight)  
* AI Aircraft cannot "pivot" on their parking positions. The last segment on a route leading to or exiting a parking position must have the same heading than the parking position itself (Park Straight)  


* Groundnets, terrain and scenery objects are independent. If you see your AI aircrafts rolling on grass or sitting on buildings and for as long as your groundnet lat.lon data is correct, consider that the airport terrain/layout may be outdated or misplaced. Similarly, Building/Object may have been placed at certain Lat/Lon but since demolished (example of JFK Terminal 3 on the right) to make space for a new taxiway as airports expand and change layout regularly.
* Groundnets, terrain and scenery objects are independent. If you see your AI aircraft rolling on grass or sitting on buildings and for as long as your groundnet lat.lon data is correct, consider that the airport terrain/layout may be outdated or misplaced. Similarly, Building/Object may have been placed at certain Lat/Lon but since demolished (example of JFK Terminal 3 on the right) to make space for a new taxiway as airports expand and change layout regularly.


Make sure you have verified the data in your ICAO.threshold.xml before starting building your groundnet. If the data is incorrect, locate the correct one on the web and post a request for adjustment in the FlightGear AI forum with a link to the correct data source.
Make sure you have verified the data in your ICAO.threshold.xml before starting building your groundnet. If the data is incorrect, locate the correct one on the web and post a request for adjustment in the FlightGear AI forum with a link to the correct data source.


Your candidate groundnet will need to be tested thoroughly by running it in FG, at different time of the day as wind conditions and traffic patterns will impact which runways are used and how many AI aircrafts are handled.  
Your candidate groundnet will need to be tested thoroughly by running it in FG, at different time of the day as wind conditions and traffic patterns will impact which runways are used and how many AI aircraft are handled.  
You should have log/debug enabled as traffic manager will create :ai entries, allowing easier troubleshooting.
You should have log/debug enabled as traffic manager will create :ai entries, allowing easier troubleshooting.


Line 355: Line 355:


Objective:
Objective:
* You have enough gates for all AI aircrafts using the airport
* You have enough gates for all AI aircraft using the airport
* Each gate has a valid incoming and outgoing link (route) to the rest of the groundnet
* Each gate has a valid incoming and outgoing link (route) to the rest of the groundnet
* Each Runway(s) threshold has a unique link to the rest of the groundnet
* Each Runway(s) threshold has a unique link to the rest of the groundnet
* Departing Aircrafts can reach any threshold, from any parking position  
* Departing Aircraft can reach any threshold, from any parking position  
* Arriving Aircrafts can reach any suitable parking position from any threshold
* Arriving Aircraft can reach any suitable parking position from any threshold




Line 366: Line 366:
Place a parking position at each location an aircraft is allowed to park. Use your AIP Lat/Lon data and/or the FGA OSM background for extra precision.
Place a parking position at each location an aircraft is allowed to park. Use your AIP Lat/Lon data and/or the FGA OSM background for extra precision.
[[File:Extend Route passed Displaced THR.png|thumb|Example of route ended after a displaced Threshold]]  
[[File:Extend Route passed Displaced THR.png|thumb|Example of route ended after a displaced Threshold]]  
AI Aircrafts will be positioned so their centre of rotation (main gear and/or X=0 in .ac model file) sits at the Lat/Lon defined for the parking position.
AI Aircraft will be positioned so their centre of rotation (main gear and/or X=0 in .ac model file) sits at the Lat/Lon defined for the parking position.


Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters.  
Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters.  
Line 377: Line 377:
'''Step 2 : Place and configure the Runway accesses'''
'''Step 2 : Place and configure the Runway accesses'''


AI aircrafts need an access route to each threshold of each runway you want them to use for take off or landing. Your groundnet will need at least one route to one threshold for validation.
AI aircraft need an access route to each threshold of each runway you want them to use for take off or landing. Your groundnet will need at least one route to one threshold for validation.


At this stage, place only two access route per runway, one at each end, do not create routes starting/ending hallway (to vacate the runway at midpoint).
At this stage, place only two access route per runway, one at each end, do not create routes starting/ending hallway (to vacate the runway at midpoint).
Your access routes will be used to ‘guide’ the aircraft all the way to a final node at which point it will be ‘handed over’ to the tower, start accelerating and take off.
Your access routes will be used to ‘guide’ the aircraft all the way to a final node at which point it will be ‘handed over’ to the tower, start accelerating and take off.
This final node of each access route (Take Off Point) must sit within the runway thresholds. If not, departing aircrafts will simply stop and queue at the entrance of the runway. This is crucial when dealing with displaced thresholds. As a rule of thumb, your access route should end up on the white marking indicating the runway number/identification.
This final node of each access route (Take Off Point) must sit within the runway thresholds. If not, departing aircraft will simply stop and queue at the entrance of the runway. This is crucial when dealing with displaced thresholds. As a rule of thumb, your access route should end up on the white marking indicating the runway number/identification.


Backtracking: Certain airports do not have taxiways along the runway and aircrafts will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example [[:File:Using_the_runway_to_backtrack_to_the_threshold.jpg|HERE]].
Backtracking: Certain airports do not have taxiways along the runway and aircraft will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example [[:File:Using_the_runway_to_backtrack_to_the_threshold.jpg|HERE]].


Your access routes (all routes at this stage in fact) must be bi directional so they can also be used for aircraft to vacate the runway if they taxi all the way to the threshold.
Your access routes (all routes at this stage in fact) must be bi directional so they can also be used for aircraft to vacate the runway if they taxi all the way to the threshold.
Line 394: Line 394:


Link each of your parking positions and runway access routes by marking the taxiways with segments, avoiding sharp 90 degrees angles by breaking curves into 2 or 3 segments.
Link each of your parking positions and runway access routes by marking the taxiways with segments, avoiding sharp 90 degrees angles by breaking curves into 2 or 3 segments.
Keep the network as unconstrained as possible; Make all segments bi-directional, do not include any holding points (Pushback, Regular or Cat III) and do not mark any segment as pushback; At this stage, the idea is to give AI aircrafts as many routing options as possible.
Keep the network as unconstrained as possible; Make all segments bi-directional, do not include any holding points (Pushback, Regular or Cat III) and do not mark any segment as pushback; At this stage, the idea is to give AI aircraft as many routing options as possible.


Nodes should be placed only at points where the aircraft will change heading so they should be none in the middle of straight routes and definitely none at taxiway crossings.
Nodes should be placed only at points where the aircraft will change heading so they should be none in the middle of straight routes and definitely none at taxiway crossings.


Segments starting (or ending) at a parking position must have the same heading than the parking stand. AI aircrafts park straight and leave their parking straight (rolling forward or pushing back).
Segments starting (or ending) at a parking position must have the same heading than the parking stand. AI aircraft park straight and leave their parking straight (rolling forward or pushing back).


Your groundnet does not need to cover 100% of the airport taxiways; certain areas (like De Icing stations or Engine Test Areas) will not be used by AI aircrafts. In essence draw just enough routes so that all gates and runways are connected.
Your groundnet does not need to cover 100% of the airport taxiways; certain areas (like De Icing stations or Engine Test Areas) will not be used by AI aircraft. In essence draw just enough routes so that all gates and runways are connected.


'''Step 4 : Visual Check'''
'''Step 4 : Visual Check'''
Line 418: Line 418:
What to expect (normal behaviour with base groundnet, if FG has AI traffic at the airport):
What to expect (normal behaviour with base groundnet, if FG has AI traffic at the airport):
[[File:Base GRoundnet Visual Check.jpg|border|right|950px|Base Taxidraw Groundnet for SBGR]]  
[[File:Base GRoundnet Visual Check.jpg|border|right|950px|Base Taxidraw Groundnet for SBGR]]  
* Parked aircraft will start appearing on the parking stands you have set. Departing aircrafts will light up (red/green nav lights on wing tips, flashing beacon on top)
* Parked aircraft will start appearing on the parking stands you have set. Departing aircraft will light up (red/green nav lights on wing tips, flashing beacon on top)
* Upon ATC clearance (automatic) Departing aircrafts will roll forward into the terminal buildings then dance around a bit then join a taxiway and head for a threshold. The route they will use may not be the shortest nor the one you expected but it will be a route you have set.
* Upon ATC clearance (automatic) Departing aircraft will roll forward into the terminal buildings then dance around a bit then join a taxiway and head for a threshold. The route they will use may not be the shortest nor the one you expected but it will be a route you have set.
* Departing Aircrafts will queue up at the threshold. The first in line will enter the runway, accelerate (strobes lights activate) and take off. Aircraft will climb in a straight line and after +/- 10 seconds, change heading. At this point, the next aircraft in line will enter the runway and initiate its take off
* Departing Aircraft will queue up at the threshold. The first in line will enter the runway, accelerate (strobes lights activate) and take off. Aircraft will climb in a straight line and after +/- 10 seconds, change heading. At this point, the next aircraft in line will enter the runway and initiate its take off
* Arriving aircrafts will start landing. The touchdown position will depend on the type of aircraft. Arrivals are not spaced out and you can see more than one aircraft landing at once on a single runway. After slowing down, they will taxi all the way to the end of the runway, exit via the access route you have set then head for an available parking position. Again the route they will use may not be the shortest or the one you expected and they may not park where you wanted. Once parked, Nav Lights will turn off
* Arriving aircraft will start landing. The touchdown position will depend on the type of aircraft. Arrivals are not spaced out and you can see more than one aircraft landing at once on a single runway. After slowing down, they will taxi all the way to the end of the runway, exit via the access route you have set then head for an available parking position. Again the route they will use may not be the shortest or the one you expected and they may not park where you wanted. Once parked, Nav Lights will turn off
* At any given intersection (4 or more segments sharing a node) and at any time during the test, one aircraft will get stuck. Aircrafts following it will start queueing. The intersection will remain clogged and AI taxiing stuck until you decide to shut down Flightgear.
* At any given intersection (4 or more segments sharing a node) and at any time during the test, one aircraft will get stuck. Aircraft following it will start queueing. The intersection will remain clogged and AI taxiing stuck until you decide to shut down Flightgear.
* Aircrafts will taxi from both directions on single taxiways, eventually passing through each other
* Aircraft will taxi from both directions on single taxiways, eventually passing through each other
* On larger airports where AI aircrafts can use more than one route to go from one point to another and/or can park at multiple aprons they will show a geographical preference (normally North West) so parking and routes in this area will be busier.  
* On larger airports where AI aircraft can use more than one route to go from one point to another and/or can park at multiple aprons they will show a geographical preference (normally North West) so parking and routes in this area will be busier.  
What to look for (abnormal behaviour with base groundnet, if FG has AI traffic at the airport):
What to look for (abnormal behaviour with base groundnet, if FG has AI traffic at the airport):
* Aircraft appearing in the middle of the airport and not following taxiways (not enough Parking Positions or not suitable in size or type CARGO/GATE)
* Aircraft appearing in the middle of the airport and not following taxiways (not enough Parking Positions or not suitable in size or type CARGO/GATE)
* No aircrafts (no AI traffic at this airport or not activated in FG options)
* No aircraft (no AI traffic at this airport or not activated in FG options)
* Aircrafts queue up at runway but do not take off (Misplaced Threshold in ICAO.threshold.xml)
* Aircraft queue up at runway but do not take off (Misplaced Threshold in ICAO.threshold.xml)




Line 436: Line 436:
* All Objectives in the "Creating the base Network" section
* All Objectives in the "Creating the base Network" section
* No clogging at intersections
* No clogging at intersections
* No Head on crashes of aircrafts sharing a single taxiway
* No Head on crashes of aircraft sharing a single taxiway


The traffic manager code is not fully documented nor maintained so only repeated testing (and discussions on the FG AI Forum) will allow you to form and understanding of the way AI aircrafts will behave based on the type of groundnet data you feed them. This is an interesting but potentially frustrating exercise.
The traffic manager code is not fully documented nor maintained so only repeated testing (and discussions on the FG AI Forum) will allow you to form and understanding of the way AI aircraft will behave based on the type of groundnet data you feed them. This is an interesting but potentially frustrating exercise.


You will eventually realize that AI traffic has a “mind of its own” which fluctuates between two extremes:  
You will eventually realize that AI traffic has a “mind of its own” which fluctuates between two extremes:  
Line 452: Line 452:


To better understand how efficient routing is achieved, draw on your experience at an airport Baggage carousel (or at a ‘Sushi Train' restaurant) where all bags arrive from one or two tunnels onto a moving belt and are then distributed to passengers waiting around the carousel.  
To better understand how efficient routing is achieved, draw on your experience at an airport Baggage carousel (or at a ‘Sushi Train' restaurant) where all bags arrive from one or two tunnels onto a moving belt and are then distributed to passengers waiting around the carousel.  
That is all bags (Aircrafts) arrive from a limited number of tunnels (Thresholds) and can reach any standing passenger (ParkPos) using a single belt (routing flow). It does not matter where the passenger stands nor what order the bags arrives in; if you wait long enough all bags will meet their owner, (unless you are at Heathrow).
That is all bags (Aircraft) arrive from a limited number of tunnels (Thresholds) and can reach any standing passenger (ParkPos) using a single belt (routing flow). It does not matter where the passenger stands nor what order the bags arrives in; if you wait long enough all bags will meet their owner, (unless you are at Heathrow).


An advantage AI aircrafts have over bags is that they can ‘transfer’ from one belt to another if a segment belongs to more than one belt/route. Putting it visually, a typical routing flow will resemble something like the image on the right : ‘Belts’ in green rotate clockwise, red ones rotate counter clockwise, segments in blue provide access in and out of the belts. The main belt along the northern runway includes bypasses allowing an aircraft to quickly reach the other side of the belt without having to travel its full length.
An advantage AI aircraft have over bags is that they can ‘transfer’ from one belt to another if a segment belongs to more than one belt/route. Putting it visually, a typical routing flow will resemble something like the image on the right : ‘Belts’ in green rotate clockwise, red ones rotate counter clockwise, segments in blue provide access in and out of the belts. The main belt along the northern runway includes bypasses allowing an aircraft to quickly reach the other side of the belt without having to travel its full length.


Using the diagram, you can pick any combination of one runway access (threshold or intermediate vacating point) and one parking position and realize you can always find a unique route from A to B and another unique route from B to A without ever coming across an intersection, always using "Y" shaped merging lanes.
Using the diagram, you can pick any combination of one runway access (threshold or intermediate vacating point) and one parking position and realize you can always find a unique route from A to B and another unique route from B to A without ever coming across an intersection, always using "Y" shaped merging lanes.
Line 461: Line 461:
An additional benefit of the technique is visible when comparing the routing flow diagram and the base network image in the previous section: A groundnet with proper routing uses less nodes and segments than a full network, saving you time during the building phase. In fact, as you get more familiar with the technique you will realize it is a good idea to map your routing flow before building your groundnet so you create just enough nodes and segments. It is also important to know that you do NOT need to mark each and every segment as "unidirectional" but only the ones forming your Y shaped intersections.
An additional benefit of the technique is visible when comparing the routing flow diagram and the base network image in the previous section: A groundnet with proper routing uses less nodes and segments than a full network, saving you time during the building phase. In fact, as you get more familiar with the technique you will realize it is a good idea to map your routing flow before building your groundnet so you create just enough nodes and segments. It is also important to know that you do NOT need to mark each and every segment as "unidirectional" but only the ones forming your Y shaped intersections.


The belt technique can easily be adjusted to the specific shape of different airports: All of KJFK’s traffic is routed with only 2 belts set as concentric rings running in opposite directions. The inner ring connects all the aprons in an infinite loop; the external ring connects all the runways in a similar loop. A small number of “transfer belts” allow aircrafts to move from one belt to the other.
The belt technique can easily be adjusted to the specific shape of different airports: All of KJFK’s traffic is routed with only 2 belts set as concentric rings running in opposite directions. The inner ring connects all the aprons in an infinite loop; the external ring connects all the runways in a similar loop. A small number of “transfer belts” allow aircraft to move from one belt to the other.


You can have a look at existing groundnets’ routing to better understand how this technique can be applied to your project. VVNB has the most basic version; LEMD and LFPG have very elaborate ones.
You can have a look at existing groundnets’ routing to better understand how this technique can be applied to your project. VVNB has the most basic version; LEMD and LFPG have very elaborate ones.
Line 515: Line 515:
Using this particular configuration, once the aircraft 'cleared for taxi', it will ignore the taxiway segments on its left and right and keep its heading, rolling forward towards the original parking position, then 'get lost' and start spinning around, looking for a node to re-anchor to.  
Using this particular configuration, once the aircraft 'cleared for taxi', it will ignore the taxiway segments on its left and right and keep its heading, rolling forward towards the original parking position, then 'get lost' and start spinning around, looking for a node to re-anchor to.  


The "Roll Forward on my current heading" rules also applies to Parking position with no pushback route. These are often used for smaller propeller aircrafts which "pivot" on their parking position before rolling forward. You cannot currently replicate this pivot behaviour in Flightgear AI  
The "Roll Forward on my current heading" rules also applies to Parking position with no pushback route. These are often used for smaller propeller aircraft which "pivot" on their parking position before rolling forward. You cannot currently replicate this pivot behaviour in Flightgear AI  




Flughund
392

edits

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

Navigation menu