AI Traffic: Difference between revisions

Jump to navigation Jump to search

AI Traffic (view source)

Revision as of 12:03, 7 July 2020

3,146 bytes removed ,  7 July 2020
no edit summary
mNo edit summary
No edit summary
Line 382: Line 382:


Finally, the approach to creating a groudnet is described below as three separate phases, each one including its own specific testing which will hopefully simplify your journey.
Finally, the approach to creating a groudnet is described below as three separate phases, each one including its own specific testing which will hopefully simplify your journey.
[[File:Gate Definition in FG Airports.png|300px|thumb|FG Airports UI for Parking Position]]
=== Creating the base network ===


Objective:
* You have enough gates for all AI aircrafts using the airport
* 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
* Departing Aircrafts can reach any threshold, from any parking position
* Arriving Aircrafts can reach any suitable parking position from any threshold


=== Creating the network ===
The current documentation describes the procedure for the TaxiDraw NEW_GUI_CODE branch, which is rather drastically different from the procedure used by the original TaxiDraw, previously documented here. This section describes some of the general procedures involved in building a ground network.


Note: export your work regularly: Although ground network editing capabilities have improved dramatically, this part of TaxiDraw is still somewhat separate from the rest of the code, and ground networks are not automatically saved together with the project. When exporting, TaxiDraw asks whether the ground network should be saved directly into FlightGear's data directory. Usually, this is okay, so just clicking "yes" takes care of saving the file in the correct location. Likewise, while importing an existing network, TaxiDraw first looks in FlightGear's data directory, to check for an existing default file to be imported.
'''Step 1 : Place and configure the Parking Positions'''


[Scenery v2]: For 850 Airports, a python script is available, to automatically create a basic ground net out of WED's earth.wed file. It converts Yellow Markings and Park Positions into a ground net which can be read, and refined by Taxidraw. Note that both Centerline and borders are converted (remove border nodes once in Taxidraw) See [http://forum.flightgear.org/viewtopic.php?f=23&t=17990 HERE]
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]]
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.


Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters.
Military and General Aviation can also be used if you are running personalized traffic files on your machine.


==== Set up a rough outline ====
Adjust the heading and radius for each of your gates according to the maximum wingspan the stand can accommodate. See [[aircraft radii]].  
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.  
Set a unique name for the gate.
Leave the AIRLINE field empty at this point.


Next, start editing all the relevant startup location parameters, Parking heading can be changed by dragging the little red circular heading indicator. The parking space's radius can be changed by clicking anywhere on the big red circle. Then you can change the parking space's radius by dragging the mouse. Although this usually works for setting up a rough draft.  these parameters can directly be changed in the properties dialog. If the properties dialog UI is not visible, press [ctrl-p] to bring it up. It is possible to select multiple startup locations by pressing the shift key while selecting, and the parameters for each selected startup location can be changed at the same time. This is a powerful feature for editing the parameters of a whole series of parking locations, and also for equating and orienting gate radius and heading.
'''Step 2 : Place and configure the Runway accesses'''


With the startup locations in place, select one of them. The next step will be to connect this parking area to each runway end. After selecting the parking, click on the "insert bidirectionally connected network nodes" (the two green dots icon), and start drawing. Place nodes at strategic locations, such as intersections, corners, and arcs. finally, place one node at the centerline of one of the runways. Once this is finished, one gate is connected to one end of one runway. The next job is to extend the network by connecting more gates and more runways.  
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.


Traffic Manager 'calculates/understands' each runway centreline as the line between the two threshold points stored in the matching airport ICAO file in Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml. Whenever placing a route end node on a runway, you should ensure the node sits on or close to this line. Traffic manager will then use the vector between the two threshold to trigger the AI aircraft take off sequence (deciding that the aircraft has reached the centreline and can start speeding up) as well as setting its take off heading. This is most important in case of displaced thresholds.  
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.
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.


''Backtracking''
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.
[[File:Using the runway to backtrack to the threshold.jpg|thumb|AI Groudnet configuration for backtracking in absence of parallel taxiway]]
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.
Certain airports do not have taxiways along the runway and aircrafts will 'backtrack' on the runway itself to reach the threshold (and pivot on a turnaround area to align for take off). In this scenario, you must place nodes and segments to form a route on the runway to guide the AI aircrafts all the way from their access point to the threshold, including on the turnaround area
[[File:Multiple Route leading to a single Threshold.png|thumb|Runway access routes must be unique]]
Your access route must be unique: Traffic manager does not handle intersections (nodes with 4 routes) very well. Your take off points should not be connected to more than one route (case of taxiways on both sides of the runway feeding a single take off point from both sides as shown on the right.


Create a second branch from the existing route, which goes to another runway. To do so, press [ctrl-a] to deselect all objects. Then, select the point where you want to branch off from. Select this point using a left mouse click, while holding down the shift key. Since TaxiDraw is still in node connect mode, simply left-clicking would have resulted in placing a new node. With this node selected, continue drawing. Repeat this procedure until all runways are connected.
Select each of the nodes placed on the physical runway (not the ones leading to it) and mark them "On Runway" with the toggle in their properties panel


Then, start adding the additional gates to the network. Press [ctrl-a] to deselect all objects. Then select a gate by pressing [shift-left mouse button], and start drawing until the the gate in question is one segment away from being connected. Then, [shift left-click] the network node that this route segment should be connected to, and make sure that the correct node is selected. Then, right click, and select "connect nodes bidirectionally" from the AI nodes menu.  
'''Step 3 : Connect ParPos and Runway Access routes to form the groundnet.'''


Repeat this procedure until all parking locations are connected to each runway.
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.


==== Refining the network: Mark points on the runway as such ====
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.
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).  


Taxidraws's verification tool will automatically detect and report discrepancies (Node not marked 'on runway' where it should and vice versa) for as long as the runway(s) elements are included in the project file.
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).


==== Refining the network: Set Holding points ====
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.
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 well, 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 down 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.


The Cat II/III hold point type is meant as an extension to this scheme for special IFR conditions. Support for these types in FlightGear is planned for a later stage of development though.
=== Refining the network: Routes, Circuits and Flow ===
This sections is WIP


==== Refining the network: Pushback routes ====
=== 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. Pushback routes are optional (if you like the terminal crashing scenario described above).
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. Pushback routes are optional (if you like the terminal crashing scenario described above).


BecOzIcan
86

edits

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

Navigation menu