On Wednesday 26 May 2004 19:15, David Megginson wrote: > The reason they don't work in real life is that everyone is flying at a > different speed. There's typically one STAR for every arrival direction > (often centred around a major intersection or navaid), but ATC has IFR > traffic ranging from 100 kt Cherokee 140s to 180 kt twins and turboprops to > jets flying just barely under the 250 kt low-altitude limit (or not, in the > case of some military jets). They also have to get departures off the > runway in-between arrivals. Obviously, they cannot send us all in on the > same route even if the STAR does have separate altitudes for jets and > props, so the STAR usually gets abandoned not long after the initial fix. > Jets and turboprops typically get vectored to a long final (say, 15 nm or > more), while slow twins and singles get turned in just before (or sometimes > on top of) the final approach fix so that they'll spend the minimum amount > of time clogging up approach path. >
David, Thanks for your real-life perspective. Let me just add a little bit of back ground information about my request and add a little bit of a perspective from a software development point of view. During the last couple of weeks, I finished a first draft of a traffic manager for FlightGear. The traffic manager is a subsystem that generates AI Aircraft, by calling David Culp's AIModel code. Curently, this is done on the basis of a time table stored in a database, but this could be easily be expanded to randomly, or heuristically generated traffic. David and I have exchanged some ideas on how to integrate the traffic manager with the AIModel system, and in the mean time, David Luff and I have talked about some possibilities of implementing ATC in this system (Please correct me if I'm wrong guys). So, initially I proposed to develop the FlightGear AI traffic system roughly guided by the following schedule, or at least that's probably how I would approach the problem if I had to do this myself. 1: Write a top level traffic manager 2: Make sure the traffic manager can create AI Aircraft entities (for visuals, radar contact, and a more detailed simulation of the route taken). 3: Make sure the whole system works without worrying about the details (e.g., separation conflicts, parking problems, or approaches and departures. Just let every aircraft make a straight out straight in) 4: Add SID/STAR support 5: Add code to detect and predict separation conflicts. 6: Add support for more sophisticated parking/taxiing. 7: Add FIR support With each additional step, the system would become more complex and add sophistication. Also, the role of air traffic control would become more sophisticated with each additional step. However, as reality turns out to be more diverse and complex than schedules, I'm currently working pretty much on points 1 trhough 4 simultaneously. The traffic manager runs fairly well now on my system and it is capable (albeit still very crudely), of communicating with the AIModel code. There are a few issues that we need to solve, but in my opinion this could be done best after I've submitted the initial code, because then all parties involved can have a look at it. Point three, is the one that I'm currently spending most of my evening hours on. All the flights that I've listed sofar in the traffic manager's database require a flight plan, and I still need to create a few of these . In future versions, it's likely that a lot of these flightplans can be created dynamically, but we're currenly not yet at that stage. And this is also where my question came from: We need to create these plans anyhow, so if we could pick the approaches or departures from a database, instead of hand typing them, that would speed up the development of this system by quite a bit. Now, points 4 and 5, are specifically interesting with regard to your real world experience. The way I currently see AI traffc in FlightGear is that it is accomplished by three subsystems running in parrallel. The first system is the traffic manager, which determines when and where traffic should be generated. The second system is the AI Model manager, which actually generates the aircraft, and flies it according to the flight plan it has been assigned. The third subsystem, the ATC manager, has the important role of monitoring all traffic and the authority to modify the routes taken by each AI aircraft, for example by changing it's waypoints. If properly implimented, and provided that the combined IQ of this developers list can make the ATC manager smart enough, this could then lead to the situation that you describe: The standard procedures are a theoretical requirement, but in practice, more often than not, the ATC module decides to give instructions that are more appropriate for the local situation. However, until we are at that point of sophistication, I would rather see some standard approach and departure patterns being used than nothing at all. Cheers, Durk _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
