8,695
edits
AI Traffic: Difference between revisions
Jump to navigation
Jump to search
m
wikilinks added
m (wikilinks added) |
|||
| Line 1: | Line 1: | ||
== 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 | Starting with version 0.9.5, [[FlightGear]] has an interactive traffic system that is based on the AI-Models 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: | In essence, setting-up the AI controlled traffic system involves three steps: | ||
# Create Traffic files, | |||
# Download and install the required AI [[Aircraft]] | |||
# Build ground networks for the Airports containing traffic. | |||
== Building Traffic Files == | == 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: | 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: | ||
| Line 18: | Line 19: | ||
== Some Details: TrafficManager, Aircraft, and Flights == | == 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 [[McDonnell 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. | |||
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 | |||
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. | 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. | ||
| Line 27: | Line 27: | ||
== Realistic == | == Realistic == | ||
With FGFS 1.0.0 Interactive Traffic also reacts on other Non-AI Aicrafts. | With FGFS 1.0.0 Interactive Traffic also reacts on other Non-AI Aicrafts. | ||
The A320 ( and maybe some others) has working flaps and gears. | The [[Airbus A320|A320]] ( and maybe some others) has working flaps and gears. | ||
== An example of a traffic file == | == An example of a traffic file == | ||
| Line 258: | Line 258: | ||
== Disecting the traffic file == | == 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. | 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 == | == General Layout == | ||
The general layout of each file should look like the above example. | The general layout of each file should look like the above example. | ||
<?xml version="1.0"?> | <?xml version="1.0"?> | ||
| Line 272: | Line 270: | ||
== Defining the aircraft == | == Defining the aircraft == | ||
<?xml version="1.0"?> | <?xml version="1.0"?> | ||
<trafficlist> | <trafficlist> | ||
| Line 291: | Line 288: | ||
</aircraft> | </aircraft> | ||
</trafficlist> | </trafficlist> | ||
The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics. | The first lines inside the '''<aircraft>''' clause define the aircraft's performance characteristics. | ||
| Line 297: | Line 293: | ||
* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear. | * '''<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. | * '''<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. | * '''<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. | * '''<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. | * '''<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. | ||
| Line 317: | Line 313: | ||
== Defining a flight == | == 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 | 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. | flights specified in our PH-KCA example. | ||
| Line 365: | Line 360: | ||
== Putting it all together: Including a traffic file == | == 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. | 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 == | == 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. | 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. | ||
| Line 377: | Line 370: | ||
where '''<path>''' is the directory where the file is located, relative to the main '''Traffic''' directory. For example, fgtraffic could look like this: | 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"?> | <?xml version="1.0"?> | ||
| Line 387: | Line 379: | ||
== Organizing by airline == | == 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: | 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: | ||
| Line 398: | Line 389: | ||
== Organizing by aircraft type == | == Organizing by aircraft type == | ||
Finally, the '''MD11.xml''' file could look like this. | Finally, the '''MD11.xml''' file could look like this. | ||
<trafficlist> | <trafficlist> | ||
| Line 411: | Line 400: | ||
<traffic include="KLM/MD11/PH-KCG.xml"/> | <traffic include="KLM/MD11/PH-KCG.xml"/> | ||
</trafficlist> | </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. | 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 == | == Ground networks: A technical perspective == | ||
AI aircraft pickup taxiway information from an xml file that resides in | 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 | FlightGear's data directory. This is done on an airport by airport basis. the | ||
| Line 433: | Line 420: | ||
segments to link the startup location and the taxiways together. Parkings and | segments to link the startup location and the taxiways together. Parkings and | ||
AI nodes have the following parameters: | 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. | 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. | ||
| Line 458: | Line 445: | ||
== Creating a ground network, a practical approach == | == Creating a ground network, a practical approach == | ||
Okay that finishes the technical description of the parking file format. The | 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 | good news is that one probably doesn't need to know too much about the technical | ||
| Line 464: | Line 450: | ||
== TaxiDraw == | == TaxiDraw == | ||
The CVS version of [[TaxiDraw]] (http://taxidraw.sourceforge.net/) has ground | |||
The CVS version of | |||
network editing capabilities, and will in the short to intermediate term | network editing capabilities, and will in the short to intermediate term | ||
probably be the best option to create a ground network for FlightGear. | probably be the best option to create a ground network for FlightGear. | ||
| Line 471: | Line 456: | ||
== Obtaining TaxiDraw == | == Obtaining TaxiDraw == | ||
I'm hoping that we can do a release of taxidraw fairly soon, so that the | 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, | groundnet editing capabilities will become easily accesible. Until that time, | ||
| Line 481: | Line 465: | ||
== Getting good reference material == | == Getting good reference material == | ||
The first step in preparation of creating a ground network consists of getting | 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. | 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 == | == Creating the network == | ||
== Startup locations == | == Startup locations == | ||
Once you have the reference material, it's time to start building the ground | 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 | network. I typically start by placing all the parkings first. There are two | ||
| Line 498: | Line 479: | ||
== AI Network Nodes == | == AI Network Nodes == | ||
Next you want to insert the AINodes, without connecting them yet. The | Next you want to insert the AINodes, without connecting them yet. The | ||
procedure is basically the same as placing the startup locations. Either | procedure is basically the same as placing the startup locations. Either | ||
| Line 506: | Line 486: | ||
== Connecting the nodes: Drawing the network == | == Connecting the nodes: Drawing the network == | ||
Once you are finished adding all the nodes, and startup locations, it's time | 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, | to connect the nodes . This is the time to save your work and MAKE A BACKUP, | ||
| Line 534: | Line 513: | ||
== Editing the startup location parameters == | == Editing the startup location parameters == | ||
Once you have created a ground network, you'll find that it probably won't | 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 | work yet in flightgear. The main reason for this is that the default gate | ||
| Line 557: | Line 535: | ||
== Copying the ground network into FlightGear's data directory == | == Copying the ground network into FlightGear's data directory == | ||
Finally, once you have finished creating a groundnet work you can test it in | 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, | FlightGear. Create a directory in FlightGear's data/Airports/AI directory, | ||
| Line 564: | Line 541: | ||
== Testing the network == | == Testing the network == | ||
Startup flightGear at the airport for which you have just created 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 | and make sure you have traffic for that aircraft. FlightGear will check the | ||
| Line 574: | Line 550: | ||
== Appendix: == | == Appendix: == | ||
An below is an example section from data/Airports/AI/EHAM/parking.xml | An below is an example section from data/Airports/AI/EHAM/parking.xml | ||
| Line 636: | Line 611: | ||
</TaxiWaySegments> | </TaxiWaySegments> | ||
</groundnet> | </groundnet> | ||
==External links== | |||
* [http://www.xs4all.nl/~dtalsma/flightgear.html The FlightGear AI aircraft download page] | |||