FlightGear wiki - User contributions [en]

AI Traffic

2007-05-28T01:47:33Z

Deskin: /* Testing the network */

== Interactive Traffic in FlightGear ==

Starting with version 0.9.5, FlightGear has an interactive traffic system that is based on the AIModels subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
1. Create Traffic files, 2) Download and install the required AI Aircraft, and 3)Build ground networks for the Airports containing traffic.

== Building Traffic Files ==

Traffic patterns are stored in data files in extended markup language (.xml) format. Depending on version, these files are either stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<nowiki>
${FGROOT}/Traffic
</nowiki>

or in the AI Aircraft's directory. Current FlightGear CVS (as of late December 2007) has its traffic files in the aircraft directories (e.g., in data/AI/Aircraft/737/, and older versions as well as the current PLIB built version of FlightGear have this file in <nowiki>${FGROOT}/Traffic</nowiki>.
Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==

As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by McDonnel Douglas MD11 aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database is constructed on the basis of a routing table assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and the FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remain the same, unless the database is updated. Real aircraft require mainanance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintanance in this respect.

== An example of a traffic file ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>

<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0589</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>1/12:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>DGAA</port>
<time>1/19:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0590</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DGAA</port>
<time>1/21:15:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>2/04:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0681</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>2/08:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>CYVR</port>
<time>2/18:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0682</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYVR</port>
<time>2/20:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/05:40:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0871</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>3/09:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>VIDP</port>
<time>3/17:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0872</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>VIDP</port>
<time>3/19:20:00</time>
</departure>
<cruise-alt>350</cruise-alt>
<arrival>
<port>EHAM</port>
<time>4/04:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0587</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>4/10:30:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>DNMM</port>
<time>4/16:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0588</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DNMM</port>
<time>4/21:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>5/06:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0671</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>5/12:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>CYUL</port>
<time>5/19:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0672</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYUL</port>
<time>5/22:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>6/04:45:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0667</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>6/12:05:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KMSP</port>
<time>6/20:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0668</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KMSP</port>
<time>6/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>0/07:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</aircraft>
</trafficlist>

== Disecting the traffic file ==

Here I will discuss the general structure of a traffic file in more detail. As discussed in the introduction, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.

== General Layout ==

The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.

== Defining the aircraft ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<flight>
...
</flight>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter ICAO airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<actype>''' A description of the aircraft type reserved for future use in ATC.
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' This line is also used for gate assignments and should be one of the following:
'''ga''' (general aviation),
'''cargo''' (cargo)
'''gate''' (commercial passenger traffic)
In addtion, it is expected that a '''mil''' value will be valid sometime soon. In the near future, this keyword will also be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures.
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:

'''light_aircraft''' (prop driven single or twin),
'''ww2_fighter''' (world war two fighter),
'''jet_transport''' (modern commercial jet),
'''jet_fighter''' (modern fighter aircraft)
'''tanker''' (tanker aircraft), or.
'''ufo''' (allows extreme accel/decel capabilities).
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.

== Defining a flight ==

The next series of lines within the '''<aircraft>''' section define the flights. Again, each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at the first two
flights specified in our PH-KCA example.


<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels. The following keywords should be specified:
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplification from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival.
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours).
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
* '''<time>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).

== Putting it all together: Including a traffic file ==

After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In the next few sections, I will explain how to do this.

== fgtraffic.xml ==

If you use a current version of FlightGear cvs HEAD/ OpenSceneGraph, activating traffic is easy: Just copy the traffic file into the same directory as where the AI aircraft file resides (for example: data/AI/Aircraft/737). If you use an older version, or if you use the PLIB based version of FlightGear, traffic can be activated according to the following instructions.

At startup, FlightGear (older versions, or CVS PLIB) reads a file called '''fgtraffic.xml'''. In order to let FlightGear use our newly built traffic file, all we need to do is add a reference to the new file. Suppose we saved our file as PH-KCA.xml, all that would be required would be to add the following line:

<traffic include="<path>/PH-KCA.xml",

where '''<path>''' is the directory where the file is located, relative to the main '''Traffic''' directory. For example, fgtraffic could look like this:

<?xml version="1.0"?>
<trafficlist>
<traffic include="KLM/KLM.xml"/>
<traffic include="UAL/UAL.xml"/>
<traffic include="general/KSFO/c172.xml"/>
</trafficlist>

== Organizing by airline ==

Although the example above works and is perfectly legal, I would prefer to see the individual files grouped together by airline and aircraft type. One way to do this is to organize files by airline and within each airline by aircraft type. For example, we could group all KLM flights together. Then we bundle these into a file called \verb|KLM.xml|, which would look like the following:

<?xml version="1.0"?>
<trafficlist>
<airline include="KLM/MD11/MD11.xml"/>
</trafficlist>

This file currently contains only one line, which includes the '''MD11.xml''' group, but more could be added easily.

== Organizing by aircraft type ==

Finally, the '''MD11.xml''' file could look like this.

<trafficlist>
<traffic include="KLM/MD11/PH-KCA.xml"/>
<traffic include="KLM/MD11/PH-KCB.xml"/>
<traffic include="KLM/MD11/PH-KCC.xml"/>
<traffic include="KLM/MD11/PH-KCD.xml"/>
<traffic include="KLM/MD11/PH-KCE.xml"/>
<traffic include="KLM/MD11/PH-KCF.xml"/>
<traffic include="KLM/MD11/PH-KCG.xml"/>
</trafficlist>

One final note on the organization of the schedules is that I'm consisdering changing the organization. In order to make the whole system more ''plug-and-play'' compatible, I'd like to add in the ability to drop traffic files right in a dedicated AI directory that FLightGear would automatically scan for new traffic files. Until those ideas are finally fleshed out, the current organisation is probably likely to stay in place.

== Ground networks: A technical perspective ==

AI aircraft pickup taxiway information from an xml file that resides in
FlightGear's data directory. This is done on an airport by airport basis. the
precise location of this file is data/Airports/AI/[ICAO-id]/parking.xml. For
an example, see the groundnetwork for EHAM, which is found in
data/Airports/AI/EHAM/parking.xml. See the end of this message for a small
excerpt from this file.

The first section of the file contains the parameters of the airport's parking
locations. This section is followed by a list of all the nodes in the ground
network, and the 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.

Each parking and ai node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
- index (unique, consecutively numbered id)
- lat (position in latitude)
- lon (position in longitude)
- name (name as found on airport charts: e.g. D23, or C1).

Name is currently not used, Parking names will be used in future ATC, but AINode names will probably not be used except for some specific internal functions.
airlineCodes= list any (comma separated) ICAO airline codes here to specify
which airlines are allowed here.
-pushBack (used to determine whether departing aircraft can make left or right
turns after pushback

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay: Valid values for this parameter are: ''cargo, gate'' (=usually intermediate to heavy airline traffic), ''ramp'' (=usually smaller regional jets and commuter aircraft), ''ga'' (=general aviation), and ''mil'' (=military). See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison.
* '''number:''' Currently unused, and likely to be removed.
* '''heading:''' the heading the aircraft parked in this bay.
*'''radius:''' a value used to determine whether the aircaft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above.
*'''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:''' Currently Unused.

Finally, the taxiway segments contain three parameters.
* '''begin''' (= the id of the parking or AINode this segment starts)
* '''end''' (= the id of the parking or AINode this segment ends)
* '''name''' (= name of the taxiway. Currently still unused)

== Creating a ground network, a practical approach ==

Okay that finishes the technical description of the parking file format. The
good news is that one probably doesn't need to know too much about the technical
side of the file structure to create a ground network.

== TaxiDraw ==

The CVS version of taxidraw (http://taxidraw.sourceforge.net/) has ground
network editing capabilities, and will in the short to intermediate term
probably be the best option to create a ground network for FlightGear.
Notice that the ground editing facilities in TaxiDRaw are still rather new, and although the stability of this feature has increased dramatically over the last few weeks, there are still a few issues related to the undo function, so be prepared for a bit of frustration, and make regular backups.

== Obtaining TaxiDraw ==

I'm hoping that we can do a release of taxidraw fairly soon, so that the
groundnet editing capabilities will become easily accesible. Until that time,
linux users can try to check out a version of taxidraw from CVS by following
the instructions on http://taxidraw.sourceforge.net/#download

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment.

== Getting good reference material ==

The first step in preparation of creating a ground network consists of getting
some reference material. Ideally, You'd like to find a good satellite or arial image. If you can't find that, using a schematic diagram might also work. In most cases, using http://maps.google.com, and selecting the satellite imagery will work pretty well as reference. You can't save the google images, so importing them as a background image in taxidraw won't work. However, using these images as a reference and placing the parking notes at the approximate location indicated by the map will (at least for an initial version) give reasonable results.

== Creating the network ==

== Startup locations ==

Once you have the reference material, it's time to start building the ground
network. I typically start by placing all the parkings first. There are two
ways to do this. 1) Using the mouse, choose [insert|Startup Location] from
the main menu. This will create a new startup location. Then left-click on it
and drag it to its desired location. 2) Move the mouse to the location where
you want to place the startup location and press the 's' key on the keyboard.
This places the startup location directly where the mouse is located.

== AI Network Nodes ==

Next you want to insert the AINodes, without connecting them yet. The
procedure is basically the same as placing the startup locations. Either
select [Insert| Add AI Network Node ] from the menu, or move the mouse to the
location where you want to place the node. Press the 'n' key to actually add
the node.

== Connecting the nodes: Drawing the network ==

Once you are finished adding all the nodes, and startup locations, it's time
to connect the nodes . This is the time to save your work and MAKE A BACKUP,
as the nodes connection code is not entirely stable yet.

Connecting nodes can be done by switching the editor to arcing mode, by
pressing the 'm' key. The edit mode of taxidraw is indicated in the lower
right corner of the status bar. After pressing 'm' it should read ARC. If you
need to switch back to the standard edit mode press 'm' again.

Making sure we are still in "ARC" mode, select the first node or parking
you want to connect to the network by clicking on it. The node you have
clicked will be selected, and a red line with an arrow symbol will be drawn
between this node and the mouse cursor. Now, select the second node that you
wish to connect this node to. Click it with the mouse, and the red line will
now be drawn between the the two nodes. You have created a taxiroute. Now
repeat this process for all the nodes you want to connect.

Note that taxi segments are unidirectional. If you want to create
bidirectional taxiways, make sure you not only connect node "1" to node "2"
but also to connect node "2" to node "1".

Second, notice also that once you have connected two nodes to each other, and
want to create a second taxiway that starts at the node that the previous
node ended, you have to select this node again, to become the first node in
the next taxiway.

== Editing the startup location parameters ==

Once you have created a ground network, you'll find that it probably won't
work yet in flightgear. The main reason for this is that the default gate
size is set to a fairly small size, and most aircraft won't fit into the
gate. Therefore, you'd need to edit the parking parameters. In addition,
you'd also need to give each parking a name, and a heading, and probably
airlines codes. Changing name, and heading can be done in taxidraw, by right
clicking on the startup location. This will bring up a dialog, in which you
can change latitude, longitude, heading, and name, Once you're done editing,
click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack
parameters is not yet possible in taxidraw. So changing these requires saving
the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (taxidraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

You can edit the remaining parameters by loading this groundnet.xml file into
a text editor. Once you are done editing make sure you import these changes
into taxidraw immediately. Do this by going to [File| Import FlightGear AI
Network]. This will open a file selection dialog. Choose the file you just
edited and click okay. TaxiDraw will ask for confirmation to overwrite
existing ground network data and confirm this by clicking on "yes".

== Copying the ground network into FlightGear's data directory ==

Finally, once you have finished creating a groundnet work you can test it in
FlightGear. Create a directory in FlightGear's data/Airports/AI directory,
with the name of the ICAO code of your airport. For example
data/Airports/AI/EHAM. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml".

== Testing the network ==

Startup flightGear at the airport for which you have just created the network,
and make sure you have traffic for that aircraft. FlightGear will check the
network and report errors on the console. Aircraft than can't be placed at
one of the parking locations will be placed at a default location.

If the FlightGear AI system can't find a valid route between startup location
and runway, it will list which nodes are not connected and exit.

== Appendix: ==

An below is an example section from data/Airports/AI/EHAM/parking.xml

<?xml version="1.0"?>
<groundnet>
<parkinglist>
<Parking index="0"
type="cargo"
name="R02"
number="1"
lat="N52 17.664"
lon="E04 44.527"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
<Parking index="1"
type="cargo"
name="R04"
number="1"
lat="N52 17.682"
lon="E04 44.572"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
[SNIP]
<Parking index="198"
type="gate"
name="J80"
number="1"
lat="N52 18.678"
lon="E04 44.659"
heading="0"
radius="15"
airlineCodes="NONE"
pushBack="left"/>
</parkinglist>
<TaxiNodes>
<node index="199" lat="N52 20.778" lon="E04 42.626" name="AI waypointnode"/>
<node index="200" lat="N52 20.622" lon="E04 42.771" name="AI waypointnode"/>
<node index="201" lat="N52 20.478" lon="E04 42.592" name="AI waypointnode"/>
<node index="202" lat="N52 20.394" lon="E04 42.685" name="AI waypointnode"/>
<node index="203" lat="N52 20.406" lon="E04 42.754" name="AI waypointnode"/>
<node index="204" lat="N52 20.310" lon="E04 42.740" name="AI waypointnode"/>
<node index="205" lat="N52 20.148" lon="E04 42.565" name="AI waypointnode"/>
[SNIP]...
<node index="597" lat="N52 18.666" lon="E04 45.372" name="AI waypointnode"/>
<node index="598" lat="N52 18.678" lon="E04 45.358" name="AI waypointnode"/>
<node index="599" lat="N52 18.678" lon="E04 45.377" name="AI waypointnode"/>
</TaxiNodes>
<TaxiWaySegments>
<arc begin="237" end="234" name="Route"/>
<arc begin="234" end="239" name="Route"/>
<arc begin="239" end="242" name="Route"/>
<arc begin="242" end="245" name="Route"/>
<arc begin="369" end="374" name="Route"/>
<arc begin="374" end="369" name="Route"/>
<arc begin="370" end="373" name="Route"/>
<arc begin="373" end="370" name="Route"/>
</TaxiWaySegments>
</groundnet>

AI Traffic

2007-05-28T01:43:40Z

Deskin: /* Organizing by aircraft type */

== Interactive Traffic in FlightGear ==

Starting with version 0.9.5, FlightGear has an interactive traffic system that is based on the AIModels subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
1. Create Traffic files, 2) Download and install the required AI Aircraft, and 3)Build ground networks for the Airports containing traffic.

== Building Traffic Files ==

Traffic patterns are stored in data files in extended markup language (.xml) format. Depending on version, these files are either stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<nowiki>
${FGROOT}/Traffic
</nowiki>

or in the AI Aircraft's directory. Current FlightGear CVS (as of late December 2007) has its traffic files in the aircraft directories (e.g., in data/AI/Aircraft/737/, and older versions as well as the current PLIB built version of FlightGear have this file in <nowiki>${FGROOT}/Traffic</nowiki>.
Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==

As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by McDonnel Douglas MD11 aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database is constructed on the basis of a routing table assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and the FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remain the same, unless the database is updated. Real aircraft require mainanance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintanance in this respect.

== An example of a traffic file ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>

<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0589</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>1/12:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>DGAA</port>
<time>1/19:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0590</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DGAA</port>
<time>1/21:15:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>2/04:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0681</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>2/08:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>CYVR</port>
<time>2/18:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0682</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYVR</port>
<time>2/20:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/05:40:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0871</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>3/09:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>VIDP</port>
<time>3/17:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0872</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>VIDP</port>
<time>3/19:20:00</time>
</departure>
<cruise-alt>350</cruise-alt>
<arrival>
<port>EHAM</port>
<time>4/04:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0587</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>4/10:30:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>DNMM</port>
<time>4/16:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0588</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DNMM</port>
<time>4/21:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>5/06:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0671</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>5/12:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>CYUL</port>
<time>5/19:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0672</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYUL</port>
<time>5/22:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>6/04:45:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0667</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>6/12:05:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KMSP</port>
<time>6/20:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0668</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KMSP</port>
<time>6/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>0/07:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</aircraft>
</trafficlist>

== Disecting the traffic file ==

Here I will discuss the general structure of a traffic file in more detail. As discussed in the introduction, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.

== General Layout ==

The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.

== Defining the aircraft ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<flight>
...
</flight>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter ICAO airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<actype>''' A description of the aircraft type reserved for future use in ATC.
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' This line is also used for gate assignments and should be one of the following:
'''ga''' (general aviation),
'''cargo''' (cargo)
'''gate''' (commercial passenger traffic)
In addtion, it is expected that a '''mil''' value will be valid sometime soon. In the near future, this keyword will also be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures.
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:

'''light_aircraft''' (prop driven single or twin),
'''ww2_fighter''' (world war two fighter),
'''jet_transport''' (modern commercial jet),
'''jet_fighter''' (modern fighter aircraft)
'''tanker''' (tanker aircraft), or.
'''ufo''' (allows extreme accel/decel capabilities).
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.

== Defining a flight ==

The next series of lines within the '''<aircraft>''' section define the flights. Again, each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at the first two
flights specified in our PH-KCA example.


<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels. The following keywords should be specified:
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplification from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival.
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours).
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
* '''<time>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).

== Putting it all together: Including a traffic file ==

After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In the next few sections, I will explain how to do this.

== fgtraffic.xml ==

If you use a current version of FlightGear cvs HEAD/ OpenSceneGraph, activating traffic is easy: Just copy the traffic file into the same directory as where the AI aircraft file resides (for example: data/AI/Aircraft/737). If you use an older version, or if you use the PLIB based version of FlightGear, traffic can be activated according to the following instructions.

At startup, FlightGear (older versions, or CVS PLIB) reads a file called '''fgtraffic.xml'''. In order to let FlightGear use our newly built traffic file, all we need to do is add a reference to the new file. Suppose we saved our file as PH-KCA.xml, all that would be required would be to add the following line:

<traffic include="<path>/PH-KCA.xml",

where '''<path>''' is the directory where the file is located, relative to the main '''Traffic''' directory. For example, fgtraffic could look like this:

<?xml version="1.0"?>
<trafficlist>
<traffic include="KLM/KLM.xml"/>
<traffic include="UAL/UAL.xml"/>
<traffic include="general/KSFO/c172.xml"/>
</trafficlist>

== Organizing by airline ==

Although the example above works and is perfectly legal, I would prefer to see the individual files grouped together by airline and aircraft type. One way to do this is to organize files by airline and within each airline by aircraft type. For example, we could group all KLM flights together. Then we bundle these into a file called \verb|KLM.xml|, which would look like the following:

<?xml version="1.0"?>
<trafficlist>
<airline include="KLM/MD11/MD11.xml"/>
</trafficlist>

This file currently contains only one line, which includes the '''MD11.xml''' group, but more could be added easily.

== Organizing by aircraft type ==

Finally, the '''MD11.xml''' file could look like this.

<trafficlist>
<traffic include="KLM/MD11/PH-KCA.xml"/>
<traffic include="KLM/MD11/PH-KCB.xml"/>
<traffic include="KLM/MD11/PH-KCC.xml"/>
<traffic include="KLM/MD11/PH-KCD.xml"/>
<traffic include="KLM/MD11/PH-KCE.xml"/>
<traffic include="KLM/MD11/PH-KCF.xml"/>
<traffic include="KLM/MD11/PH-KCG.xml"/>
</trafficlist>

One final note on the organization of the schedules is that I'm consisdering changing the organization. In order to make the whole system more ''plug-and-play'' compatible, I'd like to add in the ability to drop traffic files right in a dedicated AI directory that FLightGear would automatically scan for new traffic files. Until those ideas are finally fleshed out, the current organisation is probably likely to stay in place.

== Ground networks: A technical perspective ==

AI aircraft pickup taxiway information from an xml file that resides in
FlightGear's data directory. This is done on an airport by airport basis. the
precise location of this file is data/Airports/AI/[ICAO-id]/parking.xml. For
an example, see the groundnetwork for EHAM, which is found in
data/Airports/AI/EHAM/parking.xml. See the end of this message for a small
excerpt from this file.

The first section of the file contains the parameters of the airport's parking
locations. This section is followed by a list of all the nodes in the ground
network, and the 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.

Each parking and ai node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
- index (unique, consecutively numbered id)
- lat (position in latitude)
- lon (position in longitude)
- name (name as found on airport charts: e.g. D23, or C1).

Name is currently not used, Parking names will be used in future ATC, but AINode names will probably not be used except for some specific internal functions.
airlineCodes= list any (comma separated) ICAO airline codes here to specify
which airlines are allowed here.
-pushBack (used to determine whether departing aircraft can make left or right
turns after pushback

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay: Valid values for this parameter are: ''cargo, gate'' (=usually intermediate to heavy airline traffic), ''ramp'' (=usually smaller regional jets and commuter aircraft), ''ga'' (=general aviation), and ''mil'' (=military). See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison.
* '''number:''' Currently unused, and likely to be removed.
* '''heading:''' the heading the aircraft parked in this bay.
*'''radius:''' a value used to determine whether the aircaft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above.
*'''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:''' Currently Unused.

Finally, the taxiway segments contain three parameters.
* '''begin''' (= the id of the parking or AINode this segment starts)
* '''end''' (= the id of the parking or AINode this segment ends)
* '''name''' (= name of the taxiway. Currently still unused)

== Creating a ground network, a practical approach ==

Okay that finishes the technical description of the parking file format. The
good news is that one probably doesn't need to know too much about the technical
side of the file structure to create a ground network.

== TaxiDraw ==

The CVS version of taxidraw (http://taxidraw.sourceforge.net/) has ground
network editing capabilities, and will in the short to intermediate term
probably be the best option to create a ground network for FlightGear.
Notice that the ground editing facilities in TaxiDRaw are still rather new, and although the stability of this feature has increased dramatically over the last few weeks, there are still a few issues related to the undo function, so be prepared for a bit of frustration, and make regular backups.

== Obtaining TaxiDraw ==

I'm hoping that we can do a release of taxidraw fairly soon, so that the
groundnet editing capabilities will become easily accesible. Until that time,
linux users can try to check out a version of taxidraw from CVS by following
the instructions on http://taxidraw.sourceforge.net/#download

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment.

== Getting good reference material ==

The first step in preparation of creating a ground network consists of getting
some reference material. Ideally, You'd like to find a good satellite or arial image. If you can't find that, using a schematic diagram might also work. In most cases, using http://maps.google.com, and selecting the satellite imagery will work pretty well as reference. You can't save the google images, so importing them as a background image in taxidraw won't work. However, using these images as a reference and placing the parking notes at the approximate location indicated by the map will (at least for an initial version) give reasonable results.

== Creating the network ==

== Startup locations ==

Once you have the reference material, it's time to start building the ground
network. I typically start by placing all the parkings first. There are two
ways to do this. 1) Using the mouse, choose [insert|Startup Location] from
the main menu. This will create a new startup location. Then left-click on it
and drag it to its desired location. 2) Move the mouse to the location where
you want to place the startup location and press the 's' key on the keyboard.
This places the startup location directly where the mouse is located.

== AI Network Nodes ==

Next you want to insert the AINodes, without connecting them yet. The
procedure is basically the same as placing the startup locations. Either
select [Insert| Add AI Network Node ] from the menu, or move the mouse to the
location where you want to place the node. Press the 'n' key to actually add
the node.

== Connecting the nodes: Drawing the network ==

Once you are finished adding all the nodes, and startup locations, it's time
to connect the nodes . This is the time to save your work and MAKE A BACKUP,
as the nodes connection code is not entirely stable yet.

Connecting nodes can be done by switching the editor to arcing mode, by
pressing the 'm' key. The edit mode of taxidraw is indicated in the lower
right corner of the status bar. After pressing 'm' it should read ARC. If you
need to switch back to the standard edit mode press 'm' again.

Making sure we are still in "ARC" mode, select the first node or parking
you want to connect to the network by clicking on it. The node you have
clicked will be selected, and a red line with an arrow symbol will be drawn
between this node and the mouse cursor. Now, select the second node that you
wish to connect this node to. Click it with the mouse, and the red line will
now be drawn between the the two nodes. You have created a taxiroute. Now
repeat this process for all the nodes you want to connect.

Note that taxi segments are unidirectional. If you want to create
bidirectional taxiways, make sure you not only connect node "1" to node "2"
but also to connect node "2" to node "1".

Second, notice also that once you have connected two nodes to each other, and
want to create a second taxiway that starts at the node that the previous
node ended, you have to select this node again, to become the first node in
the next taxiway.

== Editing the startup location parameters ==

Once you have created a ground network, you'll find that it probably won't
work yet in flightgear. The main reason for this is that the default gate
size is set to a fairly small size, and most aircraft won't fit into the
gate. Therefore, you'd need to edit the parking parameters. In addition,
you'd also need to give each parking a name, and a heading, and probably
airlines codes. Changing name, and heading can be done in taxidraw, by right
clicking on the startup location. This will bring up a dialog, in which you
can change latitude, longitude, heading, and name, Once you're done editing,
click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack
parameters is not yet possible in taxidraw. So changing these requires saving
the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (taxidraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

You can edit the remaining parameters by loading this groundnet.xml file into
a text editor. Once you are done editing make sure you import these changes
into taxidraw immediately. Do this by going to [File| Import FlightGear AI
Network]. This will open a file selection dialog. Choose the file you just
edited and click okay. TaxiDraw will ask for confirmation to overwrite
existing ground network data and confirm this by clicking on "yes".

== Copying the ground network into FlightGear's data directory ==

Finally, once you have finished creating a groundnet work you can test it in
FlightGear. Create a directory in FlightGear's data/Airports/AI directory,
with the name of the ICAO code of your airport. For example
data/Airports/AI/EHAM. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml".

== Testing the network ==

Startup flightGear at the airport for wich you have just created the network,
and make sure you have traffic for that aircraft. FlightGear will check the
network and report errors on the console. Aircraft than can't be placed at
one of the parking locations will be placed at a default location.

If the FlightGear AI system can't find a valid route between startup location
and runway, it will list which nodes are not connected and exit.

== Appendix: ==

An below is an example section from data/Airports/AI/EHAM/parking.xml

<?xml version="1.0"?>
<groundnet>
<parkinglist>
<Parking index="0"
type="cargo"
name="R02"
number="1"
lat="N52 17.664"
lon="E04 44.527"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
<Parking index="1"
type="cargo"
name="R04"
number="1"
lat="N52 17.682"
lon="E04 44.572"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
[SNIP]
<Parking index="198"
type="gate"
name="J80"
number="1"
lat="N52 18.678"
lon="E04 44.659"
heading="0"
radius="15"
airlineCodes="NONE"
pushBack="left"/>
</parkinglist>
<TaxiNodes>
<node index="199" lat="N52 20.778" lon="E04 42.626" name="AI waypointnode"/>
<node index="200" lat="N52 20.622" lon="E04 42.771" name="AI waypointnode"/>
<node index="201" lat="N52 20.478" lon="E04 42.592" name="AI waypointnode"/>
<node index="202" lat="N52 20.394" lon="E04 42.685" name="AI waypointnode"/>
<node index="203" lat="N52 20.406" lon="E04 42.754" name="AI waypointnode"/>
<node index="204" lat="N52 20.310" lon="E04 42.740" name="AI waypointnode"/>
<node index="205" lat="N52 20.148" lon="E04 42.565" name="AI waypointnode"/>
[SNIP]...
<node index="597" lat="N52 18.666" lon="E04 45.372" name="AI waypointnode"/>
<node index="598" lat="N52 18.678" lon="E04 45.358" name="AI waypointnode"/>
<node index="599" lat="N52 18.678" lon="E04 45.377" name="AI waypointnode"/>
</TaxiNodes>
<TaxiWaySegments>
<arc begin="237" end="234" name="Route"/>
<arc begin="234" end="239" name="Route"/>
<arc begin="239" end="242" name="Route"/>
<arc begin="242" end="245" name="Route"/>
<arc begin="369" end="374" name="Route"/>
<arc begin="374" end="369" name="Route"/>
<arc begin="370" end="373" name="Route"/>
<arc begin="373" end="370" name="Route"/>
</TaxiWaySegments>
</groundnet>

AI Traffic

2007-05-28T01:35:12Z

Deskin: /* Defining a flight */

== Interactive Traffic in FlightGear ==

Starting with version 0.9.5, FlightGear has an interactive traffic system that is based on the AIModels subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
1. Create Traffic files, 2) Download and install the required AI Aircraft, and 3)Build ground networks for the Airports containing traffic.

== Building Traffic Files ==

Traffic patterns are stored in data files in extended markup language (.xml) format. Depending on version, these files are either stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<nowiki>
${FGROOT}/Traffic
</nowiki>

or in the AI Aircraft's directory. Current FlightGear CVS (as of late December 2007) has its traffic files in the aircraft directories (e.g., in data/AI/Aircraft/737/, and older versions as well as the current PLIB built version of FlightGear have this file in <nowiki>${FGROOT}/Traffic</nowiki>.
Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==

As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by McDonnel Douglas MD11 aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database is constructed on the basis of a routing table assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and the FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remain the same, unless the database is updated. Real aircraft require mainanance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintanance in this respect.

== An example of a traffic file ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>

<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0589</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>1/12:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>DGAA</port>
<time>1/19:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0590</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DGAA</port>
<time>1/21:15:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>2/04:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0681</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>2/08:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>CYVR</port>
<time>2/18:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0682</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYVR</port>
<time>2/20:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/05:40:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0871</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>3/09:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>VIDP</port>
<time>3/17:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0872</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>VIDP</port>
<time>3/19:20:00</time>
</departure>
<cruise-alt>350</cruise-alt>
<arrival>
<port>EHAM</port>
<time>4/04:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0587</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>4/10:30:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>DNMM</port>
<time>4/16:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0588</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DNMM</port>
<time>4/21:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>5/06:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0671</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>5/12:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>CYUL</port>
<time>5/19:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0672</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYUL</port>
<time>5/22:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>6/04:45:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0667</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>6/12:05:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KMSP</port>
<time>6/20:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0668</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KMSP</port>
<time>6/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>0/07:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</aircraft>
</trafficlist>

== Disecting the traffic file ==

Here I will discuss the general structure of a traffic file in more detail. As discussed in the introduction, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.

== General Layout ==

The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.

== Defining the aircraft ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<flight>
...
</flight>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter ICAO airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<actype>''' A description of the aircraft type reserved for future use in ATC.
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' This line is also used for gate assignments and should be one of the following:
'''ga''' (general aviation),
'''cargo''' (cargo)
'''gate''' (commercial passenger traffic)
In addtion, it is expected that a '''mil''' value will be valid sometime soon. In the near future, this keyword will also be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures.
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:

'''light_aircraft''' (prop driven single or twin),
'''ww2_fighter''' (world war two fighter),
'''jet_transport''' (modern commercial jet),
'''jet_fighter''' (modern fighter aircraft)
'''tanker''' (tanker aircraft), or.
'''ufo''' (allows extreme accel/decel capabilities).
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.

== Defining a flight ==

The next series of lines within the '''<aircraft>''' section define the flights. Again, each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at the first two
flights specified in our PH-KCA example.


<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels. The following keywords should be specified:
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplification from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival.
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours).
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
* '''<time>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).

== Putting it all together: Including a traffic file ==

After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In the next few sections, I will explain how to do this.

== fgtraffic.xml ==

If you use a current version of FlightGear cvs HEAD/ OpenSceneGraph, activating traffic is easy: Just copy the traffic file into the same directory as where the AI aircraft file resides (for example: data/AI/Aircraft/737). If you use an older version, or if you use the PLIB based version of FlightGear, traffic can be activated according to the following instructions.

At startup, FlightGear (older versions, or CVS PLIB) reads a file called '''fgtraffic.xml'''. In order to let FlightGear use our newly built traffic file, all we need to do is add a reference to the new file. Suppose we saved our file as PH-KCA.xml, all that would be required would be to add the following line:

<traffic include="<path>/PH-KCA.xml",

where '''<path>''' is the directory where the file is located, relative to the main '''Traffic''' directory. For example, fgtraffic could look like this:

<?xml version="1.0"?>
<trafficlist>
<traffic include="KLM/KLM.xml"/>
<traffic include="UAL/UAL.xml"/>
<traffic include="general/KSFO/c172.xml"/>
</trafficlist>

== Organizing by airline ==

Although the example above works and is perfectly legal, I would prefer to see the individual files grouped together by airline and aircraft type. One way to do this is to organize files by airline and within each airline by aircraft type. For example, we could group all KLM flights together. Then we bundle these into a file called \verb|KLM.xml|, which would look like the following:

<?xml version="1.0"?>
<trafficlist>
<airline include="KLM/MD11/MD11.xml"/>
</trafficlist>

This file currently contains only one line, which includes the '''MD11.xml''' group, but more could be added easily.

== Organizing by aircraft type ==

Finally, the '''MD11.xml''' file could look like this.

<trafficlist>
<traffic include="KLM/MD11/PH-KCA.xml"/>
<traffic include="KLM/MD11/PH-KCB.xml"/>
<traffic include="KLM/MD11/PH-KCC.xml"/>
<traffic include="KLM/MD11/PH-KCD.xml"/>
<traffic include="KLM/MD11/PH-KCE.xml"/>
<traffic include="KLM/MD11/PH-KCF.xml"/>
<traffic include="KLM/MD11/PH-KCG.xml"/>
</trafficlist>

One final note on the organization of the schedules is that I'm consisdering changing the organization. In order to make the whole system more ''plug-and-play'' compatible, I'd like to add in the ability to drop traffic files right in a dedicated AI directory that FLightGear would automatically scan for new traffic files. Until those ideas are finally fleshed out, the current organisation is prbably likely to stay in place.

== Ground networks: A technical perspective ==

AI aircraft pickup taxiway information from an xml file that resides in
FlightGear's data directory. This is done on an airport by airport basis. the
precise location of this file is data/Airports/AI/[ICAO-id]/parking.xml. For
an example, see the groundnetwork for EHAM, which is found in
data/Airports/AI/EHAM/parking.xml. See the end of this message for a small
excerpt from this file.

The first section of the file contains the parameters of the airport's parking
locations. This section is followed by a list of all the nodes in the ground
network, and the 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.

Each parking and ai node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
- index (unique, consecutively numbered id)
- lat (position in latitude)
- lon (position in longitude)
- name (name as found on airport charts: e.g. D23, or C1).

Name is currently not used, Parking names will be used in future ATC, but AINode names will probably not be used except for some specific internal functions.
airlineCodes= list any (comma separated) ICAO airline codes here to specify
which airlines are allowed here.
-pushBack (used to determine whether departing aircraft can make left or right
turns after pushback

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay: Valid values for this parameter are: ''cargo, gate'' (=usually intermediate to heavy airline traffic), ''ramp'' (=usually smaller regional jets and commuter aircraft), ''ga'' (=general aviation), and ''mil'' (=military). See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison.
* '''number:''' Currently unused, and likely to be removed.
* '''heading:''' the heading the aircraft parked in this bay.
*'''radius:''' a value used to determine whether the aircaft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above.
*'''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:''' Currently Unused.

Finally, the taxiway segments contain three parameters.
* '''begin''' (= the id of the parking or AINode this segment starts)
* '''end''' (= the id of the parking or AINode this segment ends)
* '''name''' (= name of the taxiway. Currently still unused)

== Creating a ground network, a practical approach ==

Okay that finishes the technical description of the parking file format. The
good news is that one probably doesn't need to know too much about the technical
side of the file structure to create a ground network.

== TaxiDraw ==

The CVS version of taxidraw (http://taxidraw.sourceforge.net/) has ground
network editing capabilities, and will in the short to intermediate term
probably be the best option to create a ground network for FlightGear.
Notice that the ground editing facilities in TaxiDRaw are still rather new, and although the stability of this feature has increased dramatically over the last few weeks, there are still a few issues related to the undo function, so be prepared for a bit of frustration, and make regular backups.

== Obtaining TaxiDraw ==

I'm hoping that we can do a release of taxidraw fairly soon, so that the
groundnet editing capabilities will become easily accesible. Until that time,
linux users can try to check out a version of taxidraw from CVS by following
the instructions on http://taxidraw.sourceforge.net/#download

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment.

== Getting good reference material ==

The first step in preparation of creating a ground network consists of getting
some reference material. Ideally, You'd like to find a good satellite or arial image. If you can't find that, using a schematic diagram might also work. In most cases, using http://maps.google.com, and selecting the satellite imagery will work pretty well as reference. You can't save the google images, so importing them as a background image in taxidraw won't work. However, using these images as a reference and placing the parking notes at the approximate location indicated by the map will (at least for an initial version) give reasonable results.

== Creating the network ==

== Startup locations ==

Once you have the reference material, it's time to start building the ground
network. I typically start by placing all the parkings first. There are two
ways to do this. 1) Using the mouse, choose [insert|Startup Location] from
the main menu. This will create a new startup location. Then left-click on it
and drag it to its desired location. 2) Move the mouse to the location where
you want to place the startup location and press the 's' key on the keyboard.
This places the startup location directly where the mouse is located.

== AI Network Nodes ==

Next you want to insert the AINodes, without connecting them yet. The
procedure is basically the same as placing the startup locations. Either
select [Insert| Add AI Network Node ] from the menu, or move the mouse to the
location where you want to place the node. Press the 'n' key to actually add
the node.

== Connecting the nodes: Drawing the network ==

Once you are finished adding all the nodes, and startup locations, it's time
to connect the nodes . This is the time to save your work and MAKE A BACKUP,
as the nodes connection code is not entirely stable yet.

Connecting nodes can be done by switching the editor to arcing mode, by
pressing the 'm' key. The edit mode of taxidraw is indicated in the lower
right corner of the status bar. After pressing 'm' it should read ARC. If you
need to switch back to the standard edit mode press 'm' again.

Making sure we are still in "ARC" mode, select the first node or parking
you want to connect to the network by clicking on it. The node you have
clicked will be selected, and a red line with an arrow symbol will be drawn
between this node and the mouse cursor. Now, select the second node that you
wish to connect this node to. Click it with the mouse, and the red line will
now be drawn between the the two nodes. You have created a taxiroute. Now
repeat this process for all the nodes you want to connect.

Note that taxi segments are unidirectional. If you want to create
bidirectional taxiways, make sure you not only connect node "1" to node "2"
but also to connect node "2" to node "1".

Second, notice also that once you have connected two nodes to each other, and
want to create a second taxiway that starts at the node that the previous
node ended, you have to select this node again, to become the first node in
the next taxiway.

== Editing the startup location parameters ==

Once you have created a ground network, you'll find that it probably won't
work yet in flightgear. The main reason for this is that the default gate
size is set to a fairly small size, and most aircraft won't fit into the
gate. Therefore, you'd need to edit the parking parameters. In addition,
you'd also need to give each parking a name, and a heading, and probably
airlines codes. Changing name, and heading can be done in taxidraw, by right
clicking on the startup location. This will bring up a dialog, in which you
can change latitude, longitude, heading, and name, Once you're done editing,
click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack
parameters is not yet possible in taxidraw. So changing these requires saving
the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (taxidraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

You can edit the remaining parameters by loading this groundnet.xml file into
a text editor. Once you are done editing make sure you import these changes
into taxidraw immediately. Do this by going to [File| Import FlightGear AI
Network]. This will open a file selection dialog. Choose the file you just
edited and click okay. TaxiDraw will ask for confirmation to overwrite
existing ground network data and confirm this by clicking on "yes".

== Copying the ground network into FlightGear's data directory ==

Finally, once you have finished creating a groundnet work you can test it in
FlightGear. Create a directory in FlightGear's data/Airports/AI directory,
with the name of the ICAO code of your airport. For example
data/Airports/AI/EHAM. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml".

== Testing the network ==

Startup flightGear at the airport for wich you have just created the network,
and make sure you have traffic for that aircraft. FlightGear will check the
network and report errors on the console. Aircraft than can't be placed at
one of the parking locations will be placed at a default location.

If the FlightGear AI system can't find a valid route between startup location
and runway, it will list which nodes are not connected and exit.

== Appendix: ==

An below is an example section from data/Airports/AI/EHAM/parking.xml

<?xml version="1.0"?>
<groundnet>
<parkinglist>
<Parking index="0"
type="cargo"
name="R02"
number="1"
lat="N52 17.664"
lon="E04 44.527"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
<Parking index="1"
type="cargo"
name="R04"
number="1"
lat="N52 17.682"
lon="E04 44.572"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
[SNIP]
<Parking index="198"
type="gate"
name="J80"
number="1"
lat="N52 18.678"
lon="E04 44.659"
heading="0"
radius="15"
airlineCodes="NONE"
pushBack="left"/>
</parkinglist>
<TaxiNodes>
<node index="199" lat="N52 20.778" lon="E04 42.626" name="AI waypointnode"/>
<node index="200" lat="N52 20.622" lon="E04 42.771" name="AI waypointnode"/>
<node index="201" lat="N52 20.478" lon="E04 42.592" name="AI waypointnode"/>
<node index="202" lat="N52 20.394" lon="E04 42.685" name="AI waypointnode"/>
<node index="203" lat="N52 20.406" lon="E04 42.754" name="AI waypointnode"/>
<node index="204" lat="N52 20.310" lon="E04 42.740" name="AI waypointnode"/>
<node index="205" lat="N52 20.148" lon="E04 42.565" name="AI waypointnode"/>
[SNIP]...
<node index="597" lat="N52 18.666" lon="E04 45.372" name="AI waypointnode"/>
<node index="598" lat="N52 18.678" lon="E04 45.358" name="AI waypointnode"/>
<node index="599" lat="N52 18.678" lon="E04 45.377" name="AI waypointnode"/>
</TaxiNodes>
<TaxiWaySegments>
<arc begin="237" end="234" name="Route"/>
<arc begin="234" end="239" name="Route"/>
<arc begin="239" end="242" name="Route"/>
<arc begin="242" end="245" name="Route"/>
<arc begin="369" end="374" name="Route"/>
<arc begin="374" end="369" name="Route"/>
<arc begin="370" end="373" name="Route"/>
<arc begin="373" end="370" name="Route"/>
</TaxiWaySegments>
</groundnet>

AI Traffic

2007-05-28T01:32:19Z

Deskin: /* Defining the aircraft */ Readability

== Interactive Traffic in FlightGear ==

Starting with version 0.9.5, FlightGear has an interactive traffic system that is based on the AIModels subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
1. Create Traffic files, 2) Download and install the required AI Aircraft, and 3)Build ground networks for the Airports containing traffic.

== Building Traffic Files ==

Traffic patterns are stored in data files in extended markup language (.xml) format. Depending on version, these files are either stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<nowiki>
${FGROOT}/Traffic
</nowiki>

or in the AI Aircraft's directory. Current FlightGear CVS (as of late December 2007) has its traffic files in the aircraft directories (e.g., in data/AI/Aircraft/737/, and older versions as well as the current PLIB built version of FlightGear have this file in <nowiki>${FGROOT}/Traffic</nowiki>.
Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==

As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by McDonnel Douglas MD11 aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database is constructed on the basis of a routing table assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and the FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remain the same, unless the database is updated. Real aircraft require mainanance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintanance in this respect.

== An example of a traffic file ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>

<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0589</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>1/12:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>DGAA</port>
<time>1/19:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0590</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DGAA</port>
<time>1/21:15:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>2/04:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0681</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>2/08:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>CYVR</port>
<time>2/18:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0682</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYVR</port>
<time>2/20:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/05:40:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0871</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>3/09:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>VIDP</port>
<time>3/17:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0872</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>VIDP</port>
<time>3/19:20:00</time>
</departure>
<cruise-alt>350</cruise-alt>
<arrival>
<port>EHAM</port>
<time>4/04:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0587</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>4/10:30:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>DNMM</port>
<time>4/16:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0588</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DNMM</port>
<time>4/21:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>5/06:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0671</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>5/12:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>CYUL</port>
<time>5/19:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0672</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYUL</port>
<time>5/22:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>6/04:45:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0667</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>6/12:05:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KMSP</port>
<time>6/20:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0668</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KMSP</port>
<time>6/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>0/07:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</aircraft>
</trafficlist>

== Disecting the traffic file ==

Here I will discuss the general structure of a traffic file in more detail. As discussed in the introduction, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.

== General Layout ==

The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.

== Defining the aircraft ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<flight>
...
</flight>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter ICAO airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<actype>''' A description of the aircraft type reserved for future use in ATC.
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' This line is also used for gate assignments and should be one of the following:
'''ga''' (general aviation),
'''cargo''' (cargo)
'''gate''' (commercial passenger traffic)
In addtion, it is expected that a '''mil''' value will be valid sometime soon. In the near future, this keyword will also be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures.
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:

'''light_aircraft''' (prop driven single or twin),
'''ww2_fighter''' (world war two fighter),
'''jet_transport''' (modern commercial jet),
'''jet_fighter''' (modern fighter aircraft)
'''tanker''' (tanker aircraft), or.
'''ufo''' (allows extreme accel/decel capabilities).
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.

== Defining a flight ==

The next series of lines within the '''<aircraft>''' section define the flights. Again, each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at the first two
flights specified in our PH-KCA example.


<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels. The following keywords should be specified:
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required or use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplyfication from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival.
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours).
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
* '''<time>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).

== Putting it all together: Including a traffic file ==

After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In the next few sections, I will explain how to do this.

== fgtraffic.xml ==

If you use a current version of FlightGear cvs HEAD/ OpenSceneGraph, activating traffic is easy: Just copy the traffic file into the same directory as where the AI aircraft file resides (for example: data/AI/Aircraft/737). If you use an older version, or if you use the PLIB based version of FlightGear, traffic can be activated according to the following instructions.

At startup, FlightGear (older versions, or CVS PLIB) reads a file called '''fgtraffic.xml'''. In order to let FlightGear use our newly built traffic file, all we need to do is add a reference to the new file. Suppose we saved our file as PH-KCA.xml, all that would be required would be to add the following line:

<traffic include="<path>/PH-KCA.xml",

where '''<path>''' is the directory where the file is located, relative to the main '''Traffic''' directory. For example, fgtraffic could look like this:

<?xml version="1.0"?>
<trafficlist>
<traffic include="KLM/KLM.xml"/>
<traffic include="UAL/UAL.xml"/>
<traffic include="general/KSFO/c172.xml"/>
</trafficlist>

== Organizing by airline ==

Although the example above works and is perfectly legal, I would prefer to see the individual files grouped together by airline and aircraft type. One way to do this is to organize files by airline and within each airline by aircraft type. For example, we could group all KLM flights together. Then we bundle these into a file called \verb|KLM.xml|, which would look like the following:

<?xml version="1.0"?>
<trafficlist>
<airline include="KLM/MD11/MD11.xml"/>
</trafficlist>

This file currently contains only one line, which includes the '''MD11.xml''' group, but more could be added easily.

== Organizing by aircraft type ==

Finally, the '''MD11.xml''' file could look like this.

<trafficlist>
<traffic include="KLM/MD11/PH-KCA.xml"/>
<traffic include="KLM/MD11/PH-KCB.xml"/>
<traffic include="KLM/MD11/PH-KCC.xml"/>
<traffic include="KLM/MD11/PH-KCD.xml"/>
<traffic include="KLM/MD11/PH-KCE.xml"/>
<traffic include="KLM/MD11/PH-KCF.xml"/>
<traffic include="KLM/MD11/PH-KCG.xml"/>
</trafficlist>

One final note on the organization of the schedules is that I'm consisdering changing the organization. In order to make the whole system more ''plug-and-play'' compatible, I'd like to add in the ability to drop traffic files right in a dedicated AI directory that FLightGear would automatically scan for new traffic files. Until those ideas are finally fleshed out, the current organisation is prbably likely to stay in place.

== Ground networks: A technical perspective ==

AI aircraft pickup taxiway information from an xml file that resides in
FlightGear's data directory. This is done on an airport by airport basis. the
precise location of this file is data/Airports/AI/[ICAO-id]/parking.xml. For
an example, see the groundnetwork for EHAM, which is found in
data/Airports/AI/EHAM/parking.xml. See the end of this message for a small
excerpt from this file.

The first section of the file contains the parameters of the airport's parking
locations. This section is followed by a list of all the nodes in the ground
network, and the 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.

Each parking and ai node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
- index (unique, consecutively numbered id)
- lat (position in latitude)
- lon (position in longitude)
- name (name as found on airport charts: e.g. D23, or C1).

Name is currently not used, Parking names will be used in future ATC, but AINode names will probably not be used except for some specific internal functions.
airlineCodes= list any (comma separated) ICAO airline codes here to specify
which airlines are allowed here.
-pushBack (used to determine whether departing aircraft can make left or right
turns after pushback

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay: Valid values for this parameter are: ''cargo, gate'' (=usually intermediate to heavy airline traffic), ''ramp'' (=usually smaller regional jets and commuter aircraft), ''ga'' (=general aviation), and ''mil'' (=military). See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison.
* '''number:''' Currently unused, and likely to be removed.
* '''heading:''' the heading the aircraft parked in this bay.
*'''radius:''' a value used to determine whether the aircaft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above.
*'''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:''' Currently Unused.

Finally, the taxiway segments contain three parameters.
* '''begin''' (= the id of the parking or AINode this segment starts)
* '''end''' (= the id of the parking or AINode this segment ends)
* '''name''' (= name of the taxiway. Currently still unused)

== Creating a ground network, a practical approach ==

Okay that finishes the technical description of the parking file format. The
good news is that one probably doesn't need to know too much about the technical
side of the file structure to create a ground network.

== TaxiDraw ==

The CVS version of taxidraw (http://taxidraw.sourceforge.net/) has ground
network editing capabilities, and will in the short to intermediate term
probably be the best option to create a ground network for FlightGear.
Notice that the ground editing facilities in TaxiDRaw are still rather new, and although the stability of this feature has increased dramatically over the last few weeks, there are still a few issues related to the undo function, so be prepared for a bit of frustration, and make regular backups.

== Obtaining TaxiDraw ==

I'm hoping that we can do a release of taxidraw fairly soon, so that the
groundnet editing capabilities will become easily accesible. Until that time,
linux users can try to check out a version of taxidraw from CVS by following
the instructions on http://taxidraw.sourceforge.net/#download

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment.

== Getting good reference material ==

The first step in preparation of creating a ground network consists of getting
some reference material. Ideally, You'd like to find a good satellite or arial image. If you can't find that, using a schematic diagram might also work. In most cases, using http://maps.google.com, and selecting the satellite imagery will work pretty well as reference. You can't save the google images, so importing them as a background image in taxidraw won't work. However, using these images as a reference and placing the parking notes at the approximate location indicated by the map will (at least for an initial version) give reasonable results.

== Creating the network ==

== Startup locations ==

Once you have the reference material, it's time to start building the ground
network. I typically start by placing all the parkings first. There are two
ways to do this. 1) Using the mouse, choose [insert|Startup Location] from
the main menu. This will create a new startup location. Then left-click on it
and drag it to its desired location. 2) Move the mouse to the location where
you want to place the startup location and press the 's' key on the keyboard.
This places the startup location directly where the mouse is located.

== AI Network Nodes ==

Next you want to insert the AINodes, without connecting them yet. The
procedure is basically the same as placing the startup locations. Either
select [Insert| Add AI Network Node ] from the menu, or move the mouse to the
location where you want to place the node. Press the 'n' key to actually add
the node.

== Connecting the nodes: Drawing the network ==

Once you are finished adding all the nodes, and startup locations, it's time
to connect the nodes . This is the time to save your work and MAKE A BACKUP,
as the nodes connection code is not entirely stable yet.

Connecting nodes can be done by switching the editor to arcing mode, by
pressing the 'm' key. The edit mode of taxidraw is indicated in the lower
right corner of the status bar. After pressing 'm' it should read ARC. If you
need to switch back to the standard edit mode press 'm' again.

Making sure we are still in "ARC" mode, select the first node or parking
you want to connect to the network by clicking on it. The node you have
clicked will be selected, and a red line with an arrow symbol will be drawn
between this node and the mouse cursor. Now, select the second node that you
wish to connect this node to. Click it with the mouse, and the red line will
now be drawn between the the two nodes. You have created a taxiroute. Now
repeat this process for all the nodes you want to connect.

Note that taxi segments are unidirectional. If you want to create
bidirectional taxiways, make sure you not only connect node "1" to node "2"
but also to connect node "2" to node "1".

Second, notice also that once you have connected two nodes to each other, and
want to create a second taxiway that starts at the node that the previous
node ended, you have to select this node again, to become the first node in
the next taxiway.

== Editing the startup location parameters ==

Once you have created a ground network, you'll find that it probably won't
work yet in flightgear. The main reason for this is that the default gate
size is set to a fairly small size, and most aircraft won't fit into the
gate. Therefore, you'd need to edit the parking parameters. In addition,
you'd also need to give each parking a name, and a heading, and probably
airlines codes. Changing name, and heading can be done in taxidraw, by right
clicking on the startup location. This will bring up a dialog, in which you
can change latitude, longitude, heading, and name, Once you're done editing,
click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack
parameters is not yet possible in taxidraw. So changing these requires saving
the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (taxidraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

You can edit the remaining parameters by loading this groundnet.xml file into
a text editor. Once you are done editing make sure you import these changes
into taxidraw immediately. Do this by going to [File| Import FlightGear AI
Network]. This will open a file selection dialog. Choose the file you just
edited and click okay. TaxiDraw will ask for confirmation to overwrite
existing ground network data and confirm this by clicking on "yes".

== Copying the ground network into FlightGear's data directory ==

Finally, once you have finished creating a groundnet work you can test it in
FlightGear. Create a directory in FlightGear's data/Airports/AI directory,
with the name of the ICAO code of your airport. For example
data/Airports/AI/EHAM. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml".

== Testing the network ==

Startup flightGear at the airport for wich you have just created the network,
and make sure you have traffic for that aircraft. FlightGear will check the
network and report errors on the console. Aircraft than can't be placed at
one of the parking locations will be placed at a default location.

If the FlightGear AI system can't find a valid route between startup location
and runway, it will list which nodes are not connected and exit.

== Appendix: ==

An below is an example section from data/Airports/AI/EHAM/parking.xml

<?xml version="1.0"?>
<groundnet>
<parkinglist>
<Parking index="0"
type="cargo"
name="R02"
number="1"
lat="N52 17.664"
lon="E04 44.527"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
<Parking index="1"
type="cargo"
name="R04"
number="1"
lat="N52 17.682"
lon="E04 44.572"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
[SNIP]
<Parking index="198"
type="gate"
name="J80"
number="1"
lat="N52 18.678"
lon="E04 44.659"
heading="0"
radius="15"
airlineCodes="NONE"
pushBack="left"/>
</parkinglist>
<TaxiNodes>
<node index="199" lat="N52 20.778" lon="E04 42.626" name="AI waypointnode"/>
<node index="200" lat="N52 20.622" lon="E04 42.771" name="AI waypointnode"/>
<node index="201" lat="N52 20.478" lon="E04 42.592" name="AI waypointnode"/>
<node index="202" lat="N52 20.394" lon="E04 42.685" name="AI waypointnode"/>
<node index="203" lat="N52 20.406" lon="E04 42.754" name="AI waypointnode"/>
<node index="204" lat="N52 20.310" lon="E04 42.740" name="AI waypointnode"/>
<node index="205" lat="N52 20.148" lon="E04 42.565" name="AI waypointnode"/>
[SNIP]...
<node index="597" lat="N52 18.666" lon="E04 45.372" name="AI waypointnode"/>
<node index="598" lat="N52 18.678" lon="E04 45.358" name="AI waypointnode"/>
<node index="599" lat="N52 18.678" lon="E04 45.377" name="AI waypointnode"/>
</TaxiNodes>
<TaxiWaySegments>
<arc begin="237" end="234" name="Route"/>
<arc begin="234" end="239" name="Route"/>
<arc begin="239" end="242" name="Route"/>
<arc begin="242" end="245" name="Route"/>
<arc begin="369" end="374" name="Route"/>
<arc begin="374" end="369" name="Route"/>
<arc begin="370" end="373" name="Route"/>
<arc begin="373" end="370" name="Route"/>
</TaxiWaySegments>
</groundnet>

AI Traffic

2007-05-28T01:31:06Z

Deskin: /* Defining the aircraft */

== Interactive Traffic in FlightGear ==

Starting with version 0.9.5, FlightGear has an interactive traffic system that is based on the AIModels subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
1. Create Traffic files, 2) Download and install the required AI Aircraft, and 3)Build ground networks for the Airports containing traffic.

== Building Traffic Files ==

Traffic patterns are stored in data files in extended markup language (.xml) format. Depending on version, these files are either stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<nowiki>
${FGROOT}/Traffic
</nowiki>

or in the AI Aircraft's directory. Current FlightGear CVS (as of late December 2007) has its traffic files in the aircraft directories (e.g., in data/AI/Aircraft/737/, and older versions as well as the current PLIB built version of FlightGear have this file in <nowiki>${FGROOT}/Traffic</nowiki>.
Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==

As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by McDonnel Douglas MD11 aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database is constructed on the basis of a routing table assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and the FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remain the same, unless the database is updated. Real aircraft require mainanance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintanance in this respect.

== An example of a traffic file ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>

<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0589</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>1/12:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>DGAA</port>
<time>1/19:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0590</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DGAA</port>
<time>1/21:15:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>2/04:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0681</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>2/08:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>CYVR</port>
<time>2/18:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0682</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYVR</port>
<time>2/20:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/05:40:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0871</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>3/09:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>VIDP</port>
<time>3/17:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0872</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>VIDP</port>
<time>3/19:20:00</time>
</departure>
<cruise-alt>350</cruise-alt>
<arrival>
<port>EHAM</port>
<time>4/04:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0587</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>4/10:30:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>DNMM</port>
<time>4/16:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0588</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DNMM</port>
<time>4/21:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>5/06:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0671</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>5/12:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>CYUL</port>
<time>5/19:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0672</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYUL</port>
<time>5/22:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>6/04:45:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0667</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>6/12:05:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KMSP</port>
<time>6/20:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0668</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KMSP</port>
<time>6/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>0/07:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</aircraft>
</trafficlist>

== Disecting the traffic file ==

Here I will discuss the general structure of a traffic file in more detail. As discussed in the introduction, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.

== General Layout ==

The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.

== Defining the aircraft ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<flight>
...
</flight>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter ICAO airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<actype>''' A description of the aircraft type reserved for future use in ATC.
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' This line is also used for gate assignments and should be
'''ga''' (general aviation),
'''cargo''' (cargo)
'''gate''' (commercial passenger traffic)
In addtion, it is expected that a '''mil''' value will be valid sometime soon. In the near future, this keyword will also be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures.
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:

'''light_aircraft''' (prop driven single or twin),
'''ww2_fighter''' (world war two fighter),
'''jet_transport''' (modern commercial jet),
'''jet_fighter''' (modern fighter aircraft)
'''tanker''' (tanker aircraft), or.
'''ufo''' (allows extreme accel/decel capabilities).
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.

== Defining a flight ==

The next series of lines within the '''<aircraft>''' section define the flights. Again, each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at the first two
flights specified in our PH-KCA example.


<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels. The following keywords should be specified:
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required or use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplyfication from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival.
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours).
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
* '''<time>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).

== Putting it all together: Including a traffic file ==

After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In the next few sections, I will explain how to do this.

== fgtraffic.xml ==

If you use a current version of FlightGear cvs HEAD/ OpenSceneGraph, activating traffic is easy: Just copy the traffic file into the same directory as where the AI aircraft file resides (for example: data/AI/Aircraft/737). If you use an older version, or if you use the PLIB based version of FlightGear, traffic can be activated according to the following instructions.

At startup, FlightGear (older versions, or CVS PLIB) reads a file called '''fgtraffic.xml'''. In order to let FlightGear use our newly built traffic file, all we need to do is add a reference to the new file. Suppose we saved our file as PH-KCA.xml, all that would be required would be to add the following line:

<traffic include="<path>/PH-KCA.xml",

where '''<path>''' is the directory where the file is located, relative to the main '''Traffic''' directory. For example, fgtraffic could look like this:

<?xml version="1.0"?>
<trafficlist>
<traffic include="KLM/KLM.xml"/>
<traffic include="UAL/UAL.xml"/>
<traffic include="general/KSFO/c172.xml"/>
</trafficlist>

== Organizing by airline ==

Although the example above works and is perfectly legal, I would prefer to see the individual files grouped together by airline and aircraft type. One way to do this is to organize files by airline and within each airline by aircraft type. For example, we could group all KLM flights together. Then we bundle these into a file called \verb|KLM.xml|, which would look like the following:

<?xml version="1.0"?>
<trafficlist>
<airline include="KLM/MD11/MD11.xml"/>
</trafficlist>

This file currently contains only one line, which includes the '''MD11.xml''' group, but more could be added easily.

== Organizing by aircraft type ==

Finally, the '''MD11.xml''' file could look like this.

<trafficlist>
<traffic include="KLM/MD11/PH-KCA.xml"/>
<traffic include="KLM/MD11/PH-KCB.xml"/>
<traffic include="KLM/MD11/PH-KCC.xml"/>
<traffic include="KLM/MD11/PH-KCD.xml"/>
<traffic include="KLM/MD11/PH-KCE.xml"/>
<traffic include="KLM/MD11/PH-KCF.xml"/>
<traffic include="KLM/MD11/PH-KCG.xml"/>
</trafficlist>

One final note on the organization of the schedules is that I'm consisdering changing the organization. In order to make the whole system more ''plug-and-play'' compatible, I'd like to add in the ability to drop traffic files right in a dedicated AI directory that FLightGear would automatically scan for new traffic files. Until those ideas are finally fleshed out, the current organisation is prbably likely to stay in place.

== Ground networks: A technical perspective ==

AI aircraft pickup taxiway information from an xml file that resides in
FlightGear's data directory. This is done on an airport by airport basis. the
precise location of this file is data/Airports/AI/[ICAO-id]/parking.xml. For
an example, see the groundnetwork for EHAM, which is found in
data/Airports/AI/EHAM/parking.xml. See the end of this message for a small
excerpt from this file.

The first section of the file contains the parameters of the airport's parking
locations. This section is followed by a list of all the nodes in the ground
network, and the 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.

Each parking and ai node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
- index (unique, consecutively numbered id)
- lat (position in latitude)
- lon (position in longitude)
- name (name as found on airport charts: e.g. D23, or C1).

Name is currently not used, Parking names will be used in future ATC, but AINode names will probably not be used except for some specific internal functions.
airlineCodes= list any (comma separated) ICAO airline codes here to specify
which airlines are allowed here.
-pushBack (used to determine whether departing aircraft can make left or right
turns after pushback

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay: Valid values for this parameter are: ''cargo, gate'' (=usually intermediate to heavy airline traffic), ''ramp'' (=usually smaller regional jets and commuter aircraft), ''ga'' (=general aviation), and ''mil'' (=military). See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison.
* '''number:''' Currently unused, and likely to be removed.
* '''heading:''' the heading the aircraft parked in this bay.
*'''radius:''' a value used to determine whether the aircaft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above.
*'''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:''' Currently Unused.

Finally, the taxiway segments contain three parameters.
* '''begin''' (= the id of the parking or AINode this segment starts)
* '''end''' (= the id of the parking or AINode this segment ends)
* '''name''' (= name of the taxiway. Currently still unused)

== Creating a ground network, a practical approach ==

Okay that finishes the technical description of the parking file format. The
good news is that one probably doesn't need to know too much about the technical
side of the file structure to create a ground network.

== TaxiDraw ==

The CVS version of taxidraw (http://taxidraw.sourceforge.net/) has ground
network editing capabilities, and will in the short to intermediate term
probably be the best option to create a ground network for FlightGear.
Notice that the ground editing facilities in TaxiDRaw are still rather new, and although the stability of this feature has increased dramatically over the last few weeks, there are still a few issues related to the undo function, so be prepared for a bit of frustration, and make regular backups.

== Obtaining TaxiDraw ==

I'm hoping that we can do a release of taxidraw fairly soon, so that the
groundnet editing capabilities will become easily accesible. Until that time,
linux users can try to check out a version of taxidraw from CVS by following
the instructions on http://taxidraw.sourceforge.net/#download

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment.

== Getting good reference material ==

The first step in preparation of creating a ground network consists of getting
some reference material. Ideally, You'd like to find a good satellite or arial image. If you can't find that, using a schematic diagram might also work. In most cases, using http://maps.google.com, and selecting the satellite imagery will work pretty well as reference. You can't save the google images, so importing them as a background image in taxidraw won't work. However, using these images as a reference and placing the parking notes at the approximate location indicated by the map will (at least for an initial version) give reasonable results.

== Creating the network ==

== Startup locations ==

Once you have the reference material, it's time to start building the ground
network. I typically start by placing all the parkings first. There are two
ways to do this. 1) Using the mouse, choose [insert|Startup Location] from
the main menu. This will create a new startup location. Then left-click on it
and drag it to its desired location. 2) Move the mouse to the location where
you want to place the startup location and press the 's' key on the keyboard.
This places the startup location directly where the mouse is located.

== AI Network Nodes ==

Next you want to insert the AINodes, without connecting them yet. The
procedure is basically the same as placing the startup locations. Either
select [Insert| Add AI Network Node ] from the menu, or move the mouse to the
location where you want to place the node. Press the 'n' key to actually add
the node.

== Connecting the nodes: Drawing the network ==

Once you are finished adding all the nodes, and startup locations, it's time
to connect the nodes . This is the time to save your work and MAKE A BACKUP,
as the nodes connection code is not entirely stable yet.

Connecting nodes can be done by switching the editor to arcing mode, by
pressing the 'm' key. The edit mode of taxidraw is indicated in the lower
right corner of the status bar. After pressing 'm' it should read ARC. If you
need to switch back to the standard edit mode press 'm' again.

Making sure we are still in "ARC" mode, select the first node or parking
you want to connect to the network by clicking on it. The node you have
clicked will be selected, and a red line with an arrow symbol will be drawn
between this node and the mouse cursor. Now, select the second node that you
wish to connect this node to. Click it with the mouse, and the red line will
now be drawn between the the two nodes. You have created a taxiroute. Now
repeat this process for all the nodes you want to connect.

Note that taxi segments are unidirectional. If you want to create
bidirectional taxiways, make sure you not only connect node "1" to node "2"
but also to connect node "2" to node "1".

Second, notice also that once you have connected two nodes to each other, and
want to create a second taxiway that starts at the node that the previous
node ended, you have to select this node again, to become the first node in
the next taxiway.

== Editing the startup location parameters ==

Once you have created a ground network, you'll find that it probably won't
work yet in flightgear. The main reason for this is that the default gate
size is set to a fairly small size, and most aircraft won't fit into the
gate. Therefore, you'd need to edit the parking parameters. In addition,
you'd also need to give each parking a name, and a heading, and probably
airlines codes. Changing name, and heading can be done in taxidraw, by right
clicking on the startup location. This will bring up a dialog, in which you
can change latitude, longitude, heading, and name, Once you're done editing,
click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack
parameters is not yet possible in taxidraw. So changing these requires saving
the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (taxidraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

You can edit the remaining parameters by loading this groundnet.xml file into
a text editor. Once you are done editing make sure you import these changes
into taxidraw immediately. Do this by going to [File| Import FlightGear AI
Network]. This will open a file selection dialog. Choose the file you just
edited and click okay. TaxiDraw will ask for confirmation to overwrite
existing ground network data and confirm this by clicking on "yes".

== Copying the ground network into FlightGear's data directory ==

Finally, once you have finished creating a groundnet work you can test it in
FlightGear. Create a directory in FlightGear's data/Airports/AI directory,
with the name of the ICAO code of your airport. For example
data/Airports/AI/EHAM. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml".

== Testing the network ==

Startup flightGear at the airport for wich you have just created the network,
and make sure you have traffic for that aircraft. FlightGear will check the
network and report errors on the console. Aircraft than can't be placed at
one of the parking locations will be placed at a default location.

If the FlightGear AI system can't find a valid route between startup location
and runway, it will list which nodes are not connected and exit.

== Appendix: ==

An below is an example section from data/Airports/AI/EHAM/parking.xml

<?xml version="1.0"?>
<groundnet>
<parkinglist>
<Parking index="0"
type="cargo"
name="R02"
number="1"
lat="N52 17.664"
lon="E04 44.527"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
<Parking index="1"
type="cargo"
name="R04"
number="1"
lat="N52 17.682"
lon="E04 44.572"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
[SNIP]
<Parking index="198"
type="gate"
name="J80"
number="1"
lat="N52 18.678"
lon="E04 44.659"
heading="0"
radius="15"
airlineCodes="NONE"
pushBack="left"/>
</parkinglist>
<TaxiNodes>
<node index="199" lat="N52 20.778" lon="E04 42.626" name="AI waypointnode"/>
<node index="200" lat="N52 20.622" lon="E04 42.771" name="AI waypointnode"/>
<node index="201" lat="N52 20.478" lon="E04 42.592" name="AI waypointnode"/>
<node index="202" lat="N52 20.394" lon="E04 42.685" name="AI waypointnode"/>
<node index="203" lat="N52 20.406" lon="E04 42.754" name="AI waypointnode"/>
<node index="204" lat="N52 20.310" lon="E04 42.740" name="AI waypointnode"/>
<node index="205" lat="N52 20.148" lon="E04 42.565" name="AI waypointnode"/>
[SNIP]...
<node index="597" lat="N52 18.666" lon="E04 45.372" name="AI waypointnode"/>
<node index="598" lat="N52 18.678" lon="E04 45.358" name="AI waypointnode"/>
<node index="599" lat="N52 18.678" lon="E04 45.377" name="AI waypointnode"/>
</TaxiNodes>
<TaxiWaySegments>
<arc begin="237" end="234" name="Route"/>
<arc begin="234" end="239" name="Route"/>
<arc begin="239" end="242" name="Route"/>
<arc begin="242" end="245" name="Route"/>
<arc begin="369" end="374" name="Route"/>
<arc begin="374" end="369" name="Route"/>
<arc begin="370" end="373" name="Route"/>
<arc begin="373" end="370" name="Route"/>
</TaxiWaySegments>
</groundnet>

AI Traffic

2007-05-28T01:26:29Z

Deskin: /* Interactive Traffic in FlightGear */

== Interactive Traffic in FlightGear ==

Starting with version 0.9.5, FlightGear has an interactive traffic system that is based on the AIModels subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
1. Create Traffic files, 2) Download and install the required AI Aircraft, and 3)Build ground networks for the Airports containing traffic.

== Building Traffic Files ==

Traffic patterns are stored in data files in extended markup language (.xml) format. Depending on version, these files are either stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<nowiki>
${FGROOT}/Traffic
</nowiki>

or in the AI Aircraft's directory. Current FlightGear CVS (as of late December 2007) has its traffic files in the aircraft directories (e.g., in data/AI/Aircraft/737/, and older versions as well as the current PLIB built version of FlightGear have this file in <nowiki>${FGROOT}/Traffic</nowiki>.
Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==

As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by McDonnel Douglas MD11 aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database is constructed on the basis of a routing table assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and the FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remain the same, unless the database is updated. Real aircraft require mainanance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintanance in this respect.

== An example of a traffic file ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>

<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0589</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>1/12:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>DGAA</port>
<time>1/19:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0590</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DGAA</port>
<time>1/21:15:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>2/04:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0681</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>2/08:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>CYVR</port>
<time>2/18:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0682</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYVR</port>
<time>2/20:20:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/05:40:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0871</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>3/09:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>VIDP</port>
<time>3/17:20:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0872</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>VIDP</port>
<time>3/19:20:00</time>
</departure>
<cruise-alt>350</cruise-alt>
<arrival>
<port>EHAM</port>
<time>4/04:00:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0587</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>4/10:30:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>DNMM</port>
<time>4/16:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0588</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DNMM</port>
<time>4/21:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>5/06:10:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0671</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>5/12:20:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>CYUL</port>
<time>5/19:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0672</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYUL</port>
<time>5/22:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>6/04:45:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0667</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>6/12:05:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KMSP</port>
<time>6/20:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0668</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KMSP</port>
<time>6/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>0/07:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</aircraft>
</trafficlist>

== Disecting the traffic file ==

Here I will discuss the general structure of a traffic file in more detail. As discussed in the introduction, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.

== General Layout ==

The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.

== Defining the aircraft ==

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<flight>
...
</flight>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter ICAO airline code here, in case of commercial traffic. This keyword is unlikely to be used fore general aviation and military traffic.
* '''<actype>''' A description of the aircraft type reserved for future use in ATC.
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' This line is also used for gate assignments and should be
'''ga''' (general aviation),
'''cargo''' (cargo)
'''gate''' (commercial passenger traffic)
In addtion, it is expected that a '''mil''' value will be valid sometime soon. In the near future, this keyword will also be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures.
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:

'''light_aircraft''' (prop driven single or twin),
'''ww2_fighter''' (world war two fighter),
'''jet_transport''' (modern commercial jet),
'''jet_fighter''' (modern fighter aircraft)
'''tanker''' (tanker aircraft), or.
'''ufo''' (allows extreme accel/decel capabilities).
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.

== Defining a flight ==

The next series of lines within the '''<aircraft>''' section define the flights. Again, each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at the first two
flights specified in our PH-KCA example.


<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/09:45:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
<time>0/20:55:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
<time>0/23:00:00</time>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
<time>1/09:35:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels. The following keywords should be specified:
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required or use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplyfication from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival.
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours).
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
* '''<time>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).

== Putting it all together: Including a traffic file ==

After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In the next few sections, I will explain how to do this.

== fgtraffic.xml ==

If you use a current version of FlightGear cvs HEAD/ OpenSceneGraph, activating traffic is easy: Just copy the traffic file into the same directory as where the AI aircraft file resides (for example: data/AI/Aircraft/737). If you use an older version, or if you use the PLIB based version of FlightGear, traffic can be activated according to the following instructions.

At startup, FlightGear (older versions, or CVS PLIB) reads a file called '''fgtraffic.xml'''. In order to let FlightGear use our newly built traffic file, all we need to do is add a reference to the new file. Suppose we saved our file as PH-KCA.xml, all that would be required would be to add the following line:

<traffic include="<path>/PH-KCA.xml",

where '''<path>''' is the directory where the file is located, relative to the main '''Traffic''' directory. For example, fgtraffic could look like this:

<?xml version="1.0"?>
<trafficlist>
<traffic include="KLM/KLM.xml"/>
<traffic include="UAL/UAL.xml"/>
<traffic include="general/KSFO/c172.xml"/>
</trafficlist>

== Organizing by airline ==

Although the example above works and is perfectly legal, I would prefer to see the individual files grouped together by airline and aircraft type. One way to do this is to organize files by airline and within each airline by aircraft type. For example, we could group all KLM flights together. Then we bundle these into a file called \verb|KLM.xml|, which would look like the following:

<?xml version="1.0"?>
<trafficlist>
<airline include="KLM/MD11/MD11.xml"/>
</trafficlist>

This file currently contains only one line, which includes the '''MD11.xml''' group, but more could be added easily.

== Organizing by aircraft type ==

Finally, the '''MD11.xml''' file could look like this.

<trafficlist>
<traffic include="KLM/MD11/PH-KCA.xml"/>
<traffic include="KLM/MD11/PH-KCB.xml"/>
<traffic include="KLM/MD11/PH-KCC.xml"/>
<traffic include="KLM/MD11/PH-KCD.xml"/>
<traffic include="KLM/MD11/PH-KCE.xml"/>
<traffic include="KLM/MD11/PH-KCF.xml"/>
<traffic include="KLM/MD11/PH-KCG.xml"/>
</trafficlist>

One final note on the organization of the schedules is that I'm consisdering changing the organization. In order to make the whole system more ''plug-and-play'' compatible, I'd like to add in the ability to drop traffic files right in a dedicated AI directory that FLightGear would automatically scan for new traffic files. Until those ideas are finally fleshed out, the current organisation is prbably likely to stay in place.

== Ground networks: A technical perspective ==

AI aircraft pickup taxiway information from an xml file that resides in
FlightGear's data directory. This is done on an airport by airport basis. the
precise location of this file is data/Airports/AI/[ICAO-id]/parking.xml. For
an example, see the groundnetwork for EHAM, which is found in
data/Airports/AI/EHAM/parking.xml. See the end of this message for a small
excerpt from this file.

The first section of the file contains the parameters of the airport's parking
locations. This section is followed by a list of all the nodes in the ground
network, and the 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.

Each parking and ai node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
- index (unique, consecutively numbered id)
- lat (position in latitude)
- lon (position in longitude)
- name (name as found on airport charts: e.g. D23, or C1).

Name is currently not used, Parking names will be used in future ATC, but AINode names will probably not be used except for some specific internal functions.
airlineCodes= list any (comma separated) ICAO airline codes here to specify
which airlines are allowed here.
-pushBack (used to determine whether departing aircraft can make left or right
turns after pushback

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay: Valid values for this parameter are: ''cargo, gate'' (=usually intermediate to heavy airline traffic), ''ramp'' (=usually smaller regional jets and commuter aircraft), ''ga'' (=general aviation), and ''mil'' (=military). See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison.
* '''number:''' Currently unused, and likely to be removed.
* '''heading:''' the heading the aircraft parked in this bay.
*'''radius:''' a value used to determine whether the aircaft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above.
*'''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:''' Currently Unused.

Finally, the taxiway segments contain three parameters.
* '''begin''' (= the id of the parking or AINode this segment starts)
* '''end''' (= the id of the parking or AINode this segment ends)
* '''name''' (= name of the taxiway. Currently still unused)

== Creating a ground network, a practical approach ==

Okay that finishes the technical description of the parking file format. The
good news is that one probably doesn't need to know too much about the technical
side of the file structure to create a ground network.

== TaxiDraw ==

The CVS version of taxidraw (http://taxidraw.sourceforge.net/) has ground
network editing capabilities, and will in the short to intermediate term
probably be the best option to create a ground network for FlightGear.
Notice that the ground editing facilities in TaxiDRaw are still rather new, and although the stability of this feature has increased dramatically over the last few weeks, there are still a few issues related to the undo function, so be prepared for a bit of frustration, and make regular backups.

== Obtaining TaxiDraw ==

I'm hoping that we can do a release of taxidraw fairly soon, so that the
groundnet editing capabilities will become easily accesible. Until that time,
linux users can try to check out a version of taxidraw from CVS by following
the instructions on http://taxidraw.sourceforge.net/#download

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment.

== Getting good reference material ==

The first step in preparation of creating a ground network consists of getting
some reference material. Ideally, You'd like to find a good satellite or arial image. If you can't find that, using a schematic diagram might also work. In most cases, using http://maps.google.com, and selecting the satellite imagery will work pretty well as reference. You can't save the google images, so importing them as a background image in taxidraw won't work. However, using these images as a reference and placing the parking notes at the approximate location indicated by the map will (at least for an initial version) give reasonable results.

== Creating the network ==

== Startup locations ==

Once you have the reference material, it's time to start building the ground
network. I typically start by placing all the parkings first. There are two
ways to do this. 1) Using the mouse, choose [insert|Startup Location] from
the main menu. This will create a new startup location. Then left-click on it
and drag it to its desired location. 2) Move the mouse to the location where
you want to place the startup location and press the 's' key on the keyboard.
This places the startup location directly where the mouse is located.

== AI Network Nodes ==

Next you want to insert the AINodes, without connecting them yet. The
procedure is basically the same as placing the startup locations. Either
select [Insert| Add AI Network Node ] from the menu, or move the mouse to the
location where you want to place the node. Press the 'n' key to actually add
the node.

== Connecting the nodes: Drawing the network ==

Once you are finished adding all the nodes, and startup locations, it's time
to connect the nodes . This is the time to save your work and MAKE A BACKUP,
as the nodes connection code is not entirely stable yet.

Connecting nodes can be done by switching the editor to arcing mode, by
pressing the 'm' key. The edit mode of taxidraw is indicated in the lower
right corner of the status bar. After pressing 'm' it should read ARC. If you
need to switch back to the standard edit mode press 'm' again.

Making sure we are still in "ARC" mode, select the first node or parking
you want to connect to the network by clicking on it. The node you have
clicked will be selected, and a red line with an arrow symbol will be drawn
between this node and the mouse cursor. Now, select the second node that you
wish to connect this node to. Click it with the mouse, and the red line will
now be drawn between the the two nodes. You have created a taxiroute. Now
repeat this process for all the nodes you want to connect.

Note that taxi segments are unidirectional. If you want to create
bidirectional taxiways, make sure you not only connect node "1" to node "2"
but also to connect node "2" to node "1".

Second, notice also that once you have connected two nodes to each other, and
want to create a second taxiway that starts at the node that the previous
node ended, you have to select this node again, to become the first node in
the next taxiway.

== Editing the startup location parameters ==

Once you have created a ground network, you'll find that it probably won't
work yet in flightgear. The main reason for this is that the default gate
size is set to a fairly small size, and most aircraft won't fit into the
gate. Therefore, you'd need to edit the parking parameters. In addition,
you'd also need to give each parking a name, and a heading, and probably
airlines codes. Changing name, and heading can be done in taxidraw, by right
clicking on the startup location. This will bring up a dialog, in which you
can change latitude, longitude, heading, and name, Once you're done editing,
click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack
parameters is not yet possible in taxidraw. So changing these requires saving
the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (taxidraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

You can edit the remaining parameters by loading this groundnet.xml file into
a text editor. Once you are done editing make sure you import these changes
into taxidraw immediately. Do this by going to [File| Import FlightGear AI
Network]. This will open a file selection dialog. Choose the file you just
edited and click okay. TaxiDraw will ask for confirmation to overwrite
existing ground network data and confirm this by clicking on "yes".

== Copying the ground network into FlightGear's data directory ==

Finally, once you have finished creating a groundnet work you can test it in
FlightGear. Create a directory in FlightGear's data/Airports/AI directory,
with the name of the ICAO code of your airport. For example
data/Airports/AI/EHAM. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml".

== Testing the network ==

Startup flightGear at the airport for wich you have just created the network,
and make sure you have traffic for that aircraft. FlightGear will check the
network and report errors on the console. Aircraft than can't be placed at
one of the parking locations will be placed at a default location.

If the FlightGear AI system can't find a valid route between startup location
and runway, it will list which nodes are not connected and exit.

== Appendix: ==

An below is an example section from data/Airports/AI/EHAM/parking.xml

<?xml version="1.0"?>
<groundnet>
<parkinglist>
<Parking index="0"
type="cargo"
name="R02"
number="1"
lat="N52 17.664"
lon="E04 44.527"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
<Parking index="1"
type="cargo"
name="R04"
number="1"
lat="N52 17.682"
lon="E04 44.572"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
[SNIP]
<Parking index="198"
type="gate"
name="J80"
number="1"
lat="N52 18.678"
lon="E04 44.659"
heading="0"
radius="15"
airlineCodes="NONE"
pushBack="left"/>
</parkinglist>
<TaxiNodes>
<node index="199" lat="N52 20.778" lon="E04 42.626" name="AI waypointnode"/>
<node index="200" lat="N52 20.622" lon="E04 42.771" name="AI waypointnode"/>
<node index="201" lat="N52 20.478" lon="E04 42.592" name="AI waypointnode"/>
<node index="202" lat="N52 20.394" lon="E04 42.685" name="AI waypointnode"/>
<node index="203" lat="N52 20.406" lon="E04 42.754" name="AI waypointnode"/>
<node index="204" lat="N52 20.310" lon="E04 42.740" name="AI waypointnode"/>
<node index="205" lat="N52 20.148" lon="E04 42.565" name="AI waypointnode"/>
[SNIP]...
<node index="597" lat="N52 18.666" lon="E04 45.372" name="AI waypointnode"/>
<node index="598" lat="N52 18.678" lon="E04 45.358" name="AI waypointnode"/>
<node index="599" lat="N52 18.678" lon="E04 45.377" name="AI waypointnode"/>
</TaxiNodes>
<TaxiWaySegments>
<arc begin="237" end="234" name="Route"/>
<arc begin="234" end="239" name="Route"/>
<arc begin="239" end="242" name="Route"/>
<arc begin="242" end="245" name="Route"/>
<arc begin="369" end="374" name="Route"/>
<arc begin="374" end="369" name="Route"/>
<arc begin="370" end="373" name="Route"/>
<arc begin="373" end="370" name="Route"/>
</TaxiWaySegments>
</groundnet>

AI Systems

2007-05-28T01:12:53Z

Deskin: /* ATC */

== ATC ==

FlightGear has a simple Air Traffic Control system.

For airports with a tower frequency, if that frequency is tuned in to your radio, you may contact ATC.

To obtain the tower frequencies for an airport within range of ATC, go to the ATC/AI menu, choose Frequencies to display the dialog. If there are any airports within 40nm range, a button with the airport designation will appear. Click see the frequencies. Tune the tower frequency in on the COM1 radio and then hit the single quote key to open the ATC window.

Points:

* Untowered airports are not supported in any way by ATC.
* You must be within 40 nautical miles of an ATC facility (towered airport with tower frequencies) to contact ATC.

== AI Air Traffic ==

Todo

Add a space in the wiki to mak a AI repository to cut and paste new AI sceneries.

== AI Models ==

Starting with FlightGear version 0.9.4 you can place AI objects in the "FlightGear world". In version 0.9.4 the AI objects can be defined in the preferences.xml file, or in an airplane's *-set.xml file. In later versions they are defined in a "scenario file" only. The types of AI objects you can have are airplanes, ships, thunderstorms, thermals and ballistic objects. AI objects have some things in common: The have a location in the "FlightGear world", they can have an associated exterior 3D model, and they can move according to an internal FDM (flight dynamics model). As of now, these objects are created at simulator start-up by adding some XML code to a scenario file. The scenario file must be in the data/AI directory. You select which scenario files you want to use by naming it in the preferences.xml file. The preferences.xml file has an entry that looks like this (FlightGear versions newer than 0.9.4, including CVS):

<AI>
<ENABLED type="bool">true</ENABLED>
<SCENARIO>aircraft_demo</SCENARIO>
</AI>

The above bit of XML enables the AI system and selects a scenario file called aircraft_demo.xml.

The scenario file contains one entry for each AI object. The entry specifies what kind of object to create, what its initial conditions will be, and optionally (for aircraft and ships) a flight plan. The entry for a sailboat could look like this:

<ENTRY>
<TYPE>ship</TYPE>
<MODEL>Models/Geometry/sailboat.xml</MODEL>
<SPEED-KTAS type="double">12.0</SPEED-KTAS>
<ALTITUDE-FT type="double">0.0</ALTITUDE-FT>
<LONGITUDE type="double">-122.33333</LONGITUDE>
<LATITUDE type="double">37.61667</LATITUDE>
<HEADING type="double">20.0</HEADING>
</ENTRY>

Most of the parameters are self-explanitory. The "type" of object can be one of "aircraft", "ship", "storm", "thermal", "ballistic" or "static". The rest of the items give the AI object a model, a starting location, and a starting speed and direction. You use the <MODEL> item to give the object any valid exterior model. You can even make the ship look like an airplane if you want! The "ship" type can also have a <RUDDER> value specified, which will cause the ship to move in a circle (HINT: use small values, five degrees or less, and right rudder is positive). Here is an example of how to create an aircraft AI object:


<ENTRY>
<TYPE>aircraft</TYPE>
<CLASS>light</CLASS>
<MODEL>Aircraft/a4/Models/a4-blue.xml</MODEL>
<SPEED-KTAStype="double">320.0</SPEED-KTAS>
<ALTITUDE-FT type="double">7000.0</ALTITUDE-FT>
<LONGITUDE type="double">-122.6</LONGITUDE>
<LATITUDE type="double">37.9</LATITUDE>
<HEADING type="double">210.0</HEADING>
<BANK type="double">-15.0</BANK>
</ENTRY>

It looks much the same as the ship AI code. There are two differences, the <CLASS> item and the <BANK> item. If the class is set to "tanker" the airplane will allow you to refuel if you can get close behind it. The bank is of course similar to the ship's rudder. In the above example the A-4 will be orbiting to the left at 15 degrees of bank. You can also create a ship or airplane with a flight plan. In this case the object will follow the flight plan, and then delete itself when it reaches the end. The flight plans are kept in data/Data/AI/FlightPlans. To create an airplane with a flightplan do this:

<ENTRY>
<TYPE>aircraft</TYPE>
<CLASS>jet-transport</CLASS>
<MODEL>Aircraft/737/Models/737.xml</MODEL>
<FLIGHTPLAN>KSFO_ILS28L.xml</FLIGHTPLAN>
</ENTRY>

To make a thunderstorm, use this:


<ENTRY>
<TYPE>storm</TYPE>
<MODEL>Models/Geometry/thunderstorm.xml</MODEL>
<SPEED-KTAS type="double">20.0</SPEED-KTAS>
<ALTITUDE-FT type="double">4000.0</ALTITUDE-FT>
<LATITUDE type="double">37.3917</LATITUDE>
<LONGITUDE type="double">-122.2817</LONGITUDE>
<HEADING type="double">90</HEADING>
</ENTRY>

There's not much to it. No, they don't turn :) To create a thermal, use this:

<ENTRY>
<TYPE>thermal</TYPE>
<LATITUDE type="double">37.61633</LATITUDE>
<LONGITUDE type="double">-122.38334</LONGITUDE>
<STRENGTH-FPS type="double">8.33</STRENGTH-FPS>
<DIAMETER-FT type="double">4000</DIAMETER-FT>
<HEIGHT-MSL>6000</HEIGHT-MSL>
<MODEL>Models/Geometry/thermalcap.xml</MODEL>
</ENTRY>

The AI thermals don't move, they are invisible, and they don't "lean" downwind. The <STRENGTH-FPS> defines the maximum vertical velocity of the airmass at the center of the thermal. The strength decreases to zero at the thermal's edge. A
model can be assigned to the thermal, and usually this will be a small cloud to mark the thermal's location. To create a sink, just give a "thermal" a negative strength, and give it a null model. Please see the demo scenario (thermal_demo.xml) for examples.

A ballistic AI object starts with an initial azimuth, elevation and speed, then follows a ballistic path from there (with air resistance included). Try this:

<ENTRY>
<TYPE>ballistic</TYPE>
<MODEL>Models/Geometry/rocket.xml</MODEL>
<SPEED-FPS type="double">500.0</SPEED-FPS>
<ALTITUDE-FT type="double">50.0</ALTITUDE-FT>
<LONGITUDE type="double">-122.39</LONGITUDE>
<LATITUDE type="double">37.62</LATITUDE>
<HEADING type="double">200.0</HEADING>
<AZIMUTH type="double">70.0</AZIMUTH>
<ELEVATION type="double">45.0</ELEVATION>
</ENTRY>

The AI storm objects can be displayed on weather radar. See the Aircraft/Instruments/wxradar.xml file for details. The AI aircraft objects can be displayed on radar. See the Aircraft/Instruments/radar.xml file for details, or fly the T-38 for a demo.

=== Using Interpolation Tables ===

Interpolation tables are very handy for effecting animations that are non-linear in relation to the property they are referenced to.

They save the use of factors, offsets and min/max values.

For example; relating flap extension to airspeed of an AI model. Typically an aircraft will extend flaps on final approach to control Indicated Airspeed (IAS) and stall speed to affect a low speed controlled landing. Upon touchdown the extra lift efficiency introduced by the flaps is no longer required or desirable, hence the flaps will be retracted ASAP after touch down.

This is relatively simple in a sim aircraft as the /surface-positions/flap-pos-norm property is a normalised indicator of the flap setting chosen by the pilot.

AI aircraft have no pilots to control flaps nor does the flight plan <flaps-down>true/false</flaps-down> parameter effect the /AI property tree parameter, a relationship to the IAS is the next best choice.

To effect this relationship (IAS/flap-position) using factors/offsets and min/max would be quite difficult and non-intuitive. Using interpolation tables allows the following scenario to be setup very easily and intuitively:

: '''C172P'''
{| border="1"
|-
| Max
| 123 KIAS
|-
| Cruise
| 90 KIAS
|-
| Stall (no flaps)
| 50 KIAS
|-
| Flaps
| 0, 10, 20, 30 deg.
|-
| Approach
| 90 KIAS
|-
| 10° flaps
| 90 KIAS
|-
| 20° flaps
| 70 KIAS
|-
| 30° flaps
| 60 KIAS
|-
| Flare & touch down
| 50 KIAS
|-
| Brake
| 45 KIAS
|-
| Retract flaps
| 45 KIAS
|}

'''Table IAS/flap extension'''
{| border="2"
|+
| IAS (kt) || Flaps
|-
| 90
| 0
|-
| 70 - 89
| 10
|-
| 60-69
| 20
|-
| 45-59
| 30
|-
| < 45
| 0
|}

When the pilot extends the flaps "one notch" they will extend to "10°" etc. In the property tree, these 4 steps will typically be normalised to 0.00, 0.33, 0.66, 1.00. This will differ from aircraft to aircraft. If the aircraft does not have equal extensions for each "notch" of flaps, the values observed may be; 0.00, 0.10, 0.30, 0.66, 1.00. Modeling this non-linear extension using "factor, offset, min/max" would be extremely difficult if not impossible. Modeling it using interpolation tables is very easy, as you shall see.

For sim animations, the actual physical rotation of the control surface in the real world needs to be researched; this may reveal a linear or non-linear relationship between "nominal flap extension indicator" and physical rotation of the surface. That is, "10 degrees of flap" might only involve rotating the flap surface 5 degrees around its axis in the wing structure. In our 0,10,20,30 scenarios, assuming a linear relationship, 30 degrees of flap would result in the flap being rotated 15 degrees around its wing axis. Therefore the normalised /surface-positions/flap-pos-norm property would have a factor of 15 applied to the rotate animation

The way to change a linear relationship that uses "factor, offset, min/max" in the sim animation to a interpolation table in the AI animation is best understood by examining how "factor, offset, min/max" approach works:

# Take normalised value of the flaps (0=retracted, 1=extended)
# Apply the factor.
# Apply the offset
# Apply the min/max values

e.g.
factor=60
offset= -30
min=-10
max+10

these figures are nonsense but are used to illustrate a point:

flaps retracted(0°) = 0 x 60 = 0, (offset=-30) = -30, (min= -10) = -10
flaps extended(10°) = 0.33 x 60 = 20, (offset=-30) = -10, (min= -10) = -10
flaps extended(20°) = 0.66 x 60 = 40, (offset=-30) = 10, (min= -10/max=10) = 10
flaps extended(30°) = 1.00 x 60 = 60, (offset=-30) = 30, (max=10) = 10

more realistically, offset and min max are not used for flaps, only a factor.

say 27°, this represents the maximum rotation of the 3-D component in the model around its defined axis.

flaps retracted(0°) = 0 x 27 = 0
flaps extended(10°) = 0.33 x 27 = 9
flaps extended(20°) = 0.66 x 27 = 18
flaps extended(30°) = 1.00 x 27 = 27

from this it can be seen that the 3-D object will be rotated 0°, 9°, 18° & 27° to represent the 0°, 10°, 20° & 30° deployment of the flaps.

Relating this back to the speeds above:

{| border="1"
|+
| IAS (kt)
| <rotate> value
|-
| 0
| 0
|-
| 44
| 0
|-
| 45
| 27
|-
| 59
| 27
|-
| 60
| 18
|-
| 69
| 18
|-
| 70
| 9
|-
| 89
| 9
|-
| 90
| 0
|-
| 100
| 0
|}

this gives a stepped effect, where the movement is limited to 1knt of airspeed. That is the 3-D object will linearly move from 9° to 18° while the aircraft looses speed from 70 knots to 69 knots. This behaviour will make the need for an upper and lower limit of a stepped value obvious.

a simplified table of:

{| border="1"
|+
| IAS (kt)
| <rotate> value
|-
| 0
| 0
|-
| 45
| 27
|-
| 60
| 18
|-
| 70
| 9
|-
| 90
| 9
|-
| 100
| 0
|}

will cause the flaps to start extending at the rate of 1/45 x 27 degrees per knot of airspeed gained until 45 knots when the rate of change will adjust to the new gradient. This is not how flaps behave, but can be used to good effect with "tail dragger" animations where at a certain IAS the tail starts rising, maybe at an increasing rate, until flying attitude is reached when it stops rising any further. The tail rising is not a stepped function of IAS.

Now we have the basic ideas behind interpolation tables, the question is how are they implemented…answer;…easy ….an example of the stepped flaps animation above

<interpolation>
<entry><ind>0.000></ind><dep>0.000</dep></entry>
<entry><ind>44.00></ind><dep>0.000</dep></entry>
<entry><ind>45.00></ind><dep>27.00</dep></entry>
<entry><ind>59.00></ind><dep>27.00</dep></entry>
<entry><ind>59.00></ind><dep>27.00</dep></entry>
<entry><ind>60.00></ind><dep>18.00</dep></entry>
<entry><ind>69.00></ind><dep>18.00</dep></entry>
<entry><ind>70.00></ind><dep>9.000</dep></entry>
<entry><ind>89.00></ind><dep>9.000</dep></entry>
<entry><ind>90.00></ind><dep>0.000</dep></entry>
<entry><ind>100.0></ind><dep>0.000</dep></entry>
</interpolation>

Here endth Interpolation tables 101
:-Dene

== Submodels ==

Submodels are AI ballistic objects that emanate from, fall from, or launch from the user aircraft. They are presently used to model smoke, contrails, flares, tracers, bombs, drop tanks and flight path markers.

Submodels are controlled by the submodel manager. The manager reads a submodel configuration file at the start of the sim session. This configuration file is written by the aircraft author and defines all the submodels for that particular aircraft.

As an example examine the submodels file in the Aircraft/737-300 directory. This file creates two submodels which will become the airplane's left and right engine contrails. Each contrail needs its own submodel definition because the contrails begin at different locations. Each contrail consists of a train of individual "puff" models that are released in rapid succession as long as the "trigger" property is true. We ensure an unlimited supply of puffs by setting the "count" parameter to -1. The individual puffs, being AIBallistic objects, will follow their own ballistic paths once released. In this case we have used the "bouyancy" parameter to negate gravity in the ballistic path. The puffs have been given a life span of eight seconds. At cruising speed the 737 will thus have about 400 puffs behind it at any moment.

Property tree

2007-05-27T19:21:54Z

Deskin: /* consumables/ */

== Property Server ==

For instance, start FlightGear with the following option:

--httpd=5400

You can pick any port number, but 5400 will probably work just fine.

Now on the same machine, fire up a web browser and open up the following url:

http://localhost:5400/

Now you can browse the entire FG property tree "live" and even change values if you like. You can configure autopilot modes and even set control inputs so you can literally fly the airplane from your web browser, although it's not the most convenient interface for doing that. ;-)

There is a similar interface minus the html wrappings that you can enable with the following option:

--props=5401

Note that you can setup as many of these as you want ... for instance, just to be obscene you could do:

--httpd=5400
--httpd=5401
--httpd=5402
--props=5403
--props=5404
--props=5405

Now you have 6 different network interfaces running that you can access from anywhere. We can't find a wiki named Note.

If you have a 'props' inteface configured you can now "telnet localhost 5401" and interact with the property system (again live) and set and examine values using a 'command line' style interface.

The cool thing is that you can easily write scripts to access this --props=<port#> interface.

Take a look at:

FlightGear/source/scripts/perl/examples/

Note that there is no requirement that you do this with perl. You could just as easily interact with FlightGear this way using perl, C, C++, java, probably even <ack> visual basic or anything else that can do tcpip network communication ... matlab? netcat?

Also note that the downside to this interface is that you can't blast a lot of data across it. It's fine if you want to monitor location and speed every second or 1/4 second and occasionally set some values (such as dump in a new weather configuration, reset the aircraft location, or read a set of values, etc.)

But if you need to track 100 different variables at 60hz, this isn't the interface for you.

== Property Tree ==
A detailed list of all nodes within the property tree and their purpose, as well as possible values

==== accelerations/ ====
==== ai/ ====
==== autopilot/ ====
==== command/ ====
==== consumables/ ====

* fuel/
** tank/
** tank[1]/
** tank[2]/
** tank[3]/
** total-fuel-gals
** total-fuel-lbs
** total-fuel-norm

Note: The number of tanks will vary between aircraft. Please take this into account when you are designing your script

==== controls/ ====
==== devices/ ====
==== engines/ ====
==== environment/ ====
==== fdm/ ====
==== gear/ ====
==== input/ ====
==== instrumentation/ ====
==== logging/ ====
==== models/ ====
==== nasal/ ====
==== orientation/ ====
The set of properties in orientation/ detail the orientation of the aircraft (pitch, yaw and roll).

* alpha-deg
* heading-deg
* heading-magnetic-deg
* pitch-deg
* pitch-rate-degps
* roll-deg
* roll-rate-degps
* side-slip-deg
* side-slip-rad
* yaw-deg
* yaw-rate-degps

==== position/ ====
The set of properties in position/ track the lat/lon location of the user's aircraft, as well as altitude and ground elevation immediately below the aircraft.

* longitude-deg -- Current longitude of the aircraft in degrees.
* latitude-deg -- Current latitude of the aircraft in degrees.
* altitude-ft -- Current altitude of the aircraft above mean sea level.
* ground-elev-m -- elevation of the ground below the aircraft, in meters. Note that for this property, ground structures are considered part of the ground. Thus, flying over any ground structure (a building, a sign, a radio tower, whatever) will raise the value of this property for as long as the aircraft is over the structure.
* altitude-agl-ft -- Current altitude of the aircraft above ground/ground structures below.

==== sim/ ====
* aero --
* ai
* ai-traffic
* aircraft --
* aircraft-dir --
* aircraft-min-status --
* alarms --
* allow-toggle-cockpit --
* ATC
* atc
* author --
* auto-coordination -- boolean (true/false) flag indicating whether auto-coordination is on or off.
* chase-distance-m --
* control-mode --
* current-view
* description --
* flight-model --
* frame-rate --
* freeze
* hud
* input
* instrumentation
* instrument-options
* intl
* logging
* model-hz --
* multiplay
* panel
* presets
* rendering
* sound
* speed-up --
* startup
* status --
* time
* view-mode --
* menubar/
* model/
* mouse/
* navdb/
* number-views = '6' (int)
* replay/
* sceneryloaded = 'true' (bool)
* submodels/
* systems/
* temp/
* tower/
* traffic-manager/
* user/
* view/
* view[1]/
* view[2]/
* view[3]/
* view[4]/
* view[5]/
* virtual-cockpit = 'false' (bool)

==== surface-positions/ ====
==== systems/ ====
==== velocities/ ====
<nowiki>
</nowiki>
[http://www.beispiel.de Link-Text]
[[Media:Beispiel.mp3]]
[[Image:Beispiel.jpg]]
fgfs --aircraft=(beispiel-737)

Realism

2007-05-27T19:16:02Z

Deskin: /* Visuals */ Removed duplicate --enable-real-weather-fetch from list

How realistic is FlightGear aircraft and environment? How can I get the most realism out of the FlightGear environment?

== Aircraft ==

Todo: instruments

== Flight ==

Todo: qualities of flight models

== Environment ==

=== Extensive and Accurate World Scenery Data Base ===

* Over 20,000 real world airports included in the full scenery set.
* Correct runway markings and placement, correct runway and approach lighting.
* Taxiways available for many larger airports (even including the green center line lights when appropriate.)
* Sloping runways (runways change elevation like they usually do in real life.)
* Directional airport lighting that smoothly changes intensity as your relative view direction changes.
* World scenery fits on 3 DVD's. (I'm not sure that's a feature or a problem!) But it means we have pretty detailed coverage of the entire world.
* Accurate terrain worldwide, based on the most recently released SRTM terrain data.) 3 arc second resolution (about 90m post spacing) for North and South America, Europe, Asia, Africa, and Australia.
* Scenery includes all vmap0 lakes, rivers, roads, railroads, cities, towns, land cover, etc.
* Nice scenery night lighting with ground lighting concentrated in urban areas (based on real maps) and headlights visible on major highways. This allows for realistic night VFR flying with the ability to spot towns and cities and follow roads.
* Scenery tiles are paged (loaded/unloaded) in a separate thread to minimize the frame rate hit when you need to load new areas.

Real world tower registration data was used to locate towers in the United States. The data was sourced from the United States Federal Communications Commission tower registration database.

Thousands of objects have been added through the [FlightGear Scenery Database http://fgfsdb.stockill.org/].

* 2700+ obstructions added for France (not sure of the source for this obstruction data)

Todo: what are the sources for scenery database? The FAA obstructions data may have been used to populate the scenery database, but I am not sure.

== Weather ==

Todo: weather

FlightGear can periodically download weather (METAR) data. This information is used to influence the environment. This can be most easily enabled with <tt>--enable-real-weather-fetch</tt>

As of FG 0.9.10, for the current METAR station, FG models:

* Visibility for the rendered visual environment is set equal to the current METAR visibility. If the current METAR reports 10 statute mile visibility, the rendered visibility is 10 statute miles.

* If the METAR reports rain, FlightGear renders rain (precipitation).

* If METAR reports a thunderstorm, lightning is rendered and thunder produced through the audio system.

* FG appears to honor METAR dewpoint, "altimeter" or air pressure and reported sea level air pressure. It honors wind direction, speed and gust speed.

'''Notes'''

* Precipitation is modeled, but the graphics require improvement. Sufficient only to indicate rain.

* Lightning is present when a thunderstorm is near, the graphics are a fair representation, but also require improvement.

* The METAR weather fetch, parsing and rendering process causes momentary reductions in the simulator's frame rates.

* The METAR wind updates are applied without any smoothing, which can cause an aircraft yaw response, sometimes described as a "rudder kick".

References

If you want to prove the relationship between FG and METAR, you can open the property browser. Monitor

/environment/metar/max-visibility-m == 9656m

and

/environment/visibility-m == 9656m

The values should be the same. When you press Z/z on the keyboard, you should see the second value change, showing this value controls the rendered visibility.

You can do the same for cloud layers. For example METAR code SCT 10 translates to coverage: scattered, elevation: 10039 and FG automatically sets thickness and transition for the layer.

== Visuals ==

Settings for maximum visual experience and rendering quality.

FlightGear command options:

--enable-horizon-effect
--enable-clouds3d
--enable-specular-highlight (enabled by default)
--enable-real-weather-fetch
--shading-smooth (default)
--enable-skyblend (default)
--enable-textures (default)

Sky Blend

This rendering option enables "fog" and haze in the distance. "sky and terrain look realistic"

Smooth Shading

Smooths shading.

Textures

Terrain texturing.

Volumetric (3D) Clouds

''This renders clouds with three-dimensional realism.''

{|
| [[Image:Clouds1_2006-06-23.jpg]]
''Default Clouds''
| [[Image:Clouds2_2006-06-23.jpg]]
''Volumetric (3D) Clouds''
|}

Geometry/Resolution

This is the resolution the FlightGear window is rendered in. The higher the resolution, the greater the detail.

640x480 blocky and lacking in detail
800x600
1024x768
...
1600 x 1200 very fine detail
and up

Use anti-aliasing if you video card supports and your system can handle the extra load.

Real Weather (METAR)

This downloads current real world weather data into FlightGear from the nearest weather station (METAR report). The data is used to influence the environment. The cloud cover specified in the METAR report will be rendered.

Time

Set the current time for your location. If it's dark in San Francisco, it will be dark in the sim.

Yoke and Rudder Pedals

Rudder pedals add to realistic operation and make it much easier to accurately use the rudder over a twist stick. The yoke is less necessary, but can add to realism.

=== Accurate and Detailed Sky Model ===

FlightGear implements extremely accurate time of day modeling with correctly placed sun, moon, stars, and planets for the specified time and date. FlightGear can track the current computer clock time in order to correctly place the sun, moon, stars, etc. in their current and proper place relative to the earth. If it's dawn in Sydney right now, it's dawn in the sim right now when you locate yourself in virtual Sydney. The sun, moon, stars, and planets all follow their correct courses through the sky. This modeling also correctly takes into account seasonal effects so you have 24 hour days north of the arctic circle in the summer, etc. We also illuminate the correctly placed moon with the correctly placed sun to get the correct phase of the moon for the current time/date, just like in real life.