117
edits
AI Traffic: Difference between revisions
Jump to navigation
Jump to search
Major update of Taxidraw's groundnetwork editing capabilities part 2.
(Language Cleanup) |
(Major update of Taxidraw's groundnetwork editing capabilities part 2.) |
||
| Line 303: | Line 303: | ||
== TaxiDraw == | == TaxiDraw == | ||
Although currently no officially released version of [[TaxiDraw]] (http://taxidraw.sourceforge.net/) exists with the ground editing capability, the current CVS version is capable of doing so. Network editing capabilities in taxidraw are currently about as stable as the other editing features, however, the ground network module is still somewhat separate from the rest of the airport project code, and ground networks will 'not' automatically be saved together with the airport project. Therefore, do regular exports while editing, to prevent loss of work. | |||
=== Obtaining TaxiDraw === | === Obtaining TaxiDraw === | ||
Until an official release has been done, linux users can try to check out a version of taxidraw from CVS by following | |||
linux users can try to check out a version of taxidraw from CVS by following | |||
the instructions on http://taxidraw.sourceforge.net/#download | the instructions on http://taxidraw.sourceforge.net/#download | ||
| Line 328: | Line 323: | ||
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. | 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 | 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 wether 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 inported. | ||
| Line 335: | Line 330: | ||
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. | 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. | ||
Next, start editing all the relevant startup location parameters. Parking heading | Next, start editing all the relevant startup location parameters. Parking heading can be changed by dragging the little red circular heading indicator. The parking's radius can be changed by clicking anywhere on the big red circle allows one to change the parking'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 is not visible, press [cntrl-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. | ||
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 | 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. | ||
Create a second branch from the existing route, which goes to another runway. To do so, press [cntrl-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. | Create a second branch from the existing route, which goes to another runway. To do so, press [cntrl-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. | ||
| Line 346: | Line 341: | ||
==== Refining the network: Mark points on the runway as such ==== | |||
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: First, FlightGear (as of 1.9.0) explicitly requires the runway side of the taxi route to be marked as such. Secondly, taxidraw needs these OnRunway points for it's network verification tool. Thirdly, future versions of FlightGear will use other runway points 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). | |||
It should be noted that there is no reason why TaxiDraw should not be able to mark the runway points as such automatically. After all, the geometry information of both runways and AI nodes is available. Although this automatic feature is planned, the taxidraw developers have as of yet not found the opportunity to implement this feature. Until that time, on runway marking has to be done by hand. | |||
==== Refining the network: Set Holding points ==== | ==== Refining the network: Set Holding points ==== | ||
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, 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 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: 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. | |||
Notice that a push back route is optional, but that parkings may never have more than one push back route. The formal criterium for a valid push back route is that each gate should have a maximum of one pushback node associated with it, which can be reached using one route only. From an editing point of view, it is sufficient to just mark a number of taxiway segments as push back, and mark the ending node as such as well. | |||
It is important to note that the "Verify Ground network" process ''should be run'' in order to get a correctly working push back system, because this function runs some internal consistency checks. Push back routes can be very simple, from just one route segment, to fairly complex, as illustrated below. Shown here are 3 examples from the EHAM ground network. 1) Shows a fairly complex example, where all aircraft from one side of the E terminal are being linked to one shared push back point. In the example, the push back route of an aircraft departing from gate E20 is illustrated. 2) Shows a simple example, where one aircraft is being pushed back, and makes a left turn. In essence, 3) shows a similar example, but now in a slightly more crowded space, where pushback nodes are overlapping. The current push back system allows for fairly complicated behavior. To get a full understanding of it's workings, it is advisable to play with some of the existing ground networks. EHAM and KFSO currently provide the most complex setups. | |||
[[Image:TaxiDraw2.png]] | |||
==== Verifying the network ==== | |||
Finally, with a network complete, it is important to verify it! The verification function not only detects obvious problems with the network, it also updates some internal states that FlightGear relies. on. Presumably, an automatic verification process will be added to the export function, but until that is the case, make sure to do this manually. The verify network function can be found in the "Tools" menu. | |||
Notice that taxidraw does not automatically fix problems. It is left to the user to fix the problems manually. TaxiDraw does select the offending node(s) / segments(s) for easier identification. Also note that TaxiDraw stops verifying at the first problem encountered, so it is worthwhile to continue checking until no further errors are found. Currently, the following checks are performed. | |||
* '''On runway points''' Added on January 24, 2009, this check is most likely not yet available in any distributed version. This is currently just a very lame check to see if any point in the network has been marked as such. This check is not exhaustive, but simply meant as a reminder to the editor that the OnRunway points should still be marked. Ultimately, this check should be replaced by the aformentioned automatic geometry function. | |||
* '''Duplicate Taxiway Segments''' It's easy to connect two network nodes twice. While this doesn't really hurt, it does add dead weight, so checking for duplicates is not a bad thing. | |||
* '''Routing''' One of the most persisting problems, headache causing problems is that of a disconnected parking in the network. FlightGear will happily place an aircraft there, but bail out when that aircraft cannot reach the runway. The routing check attempts to prevent this. Notice that it is of utmost importance that the OnRunway points are set correctly, because TaxiDraw relies on these points for it's route finding algorithm (like FlightGear does). Because the route finding algorithm is rather computationally intensive, some progress information is currently written to the console (a proper progress bar would be nice). When a disconnected parking is found, TaxiDraw selects both the parking and the runway node. It is still left to the user to trace a route between these two points and find where the two pieces are disconnected. | |||
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency. | |||
== Editing the startup location parameters == | == Editing the startup location parameters == | ||