Re: [Flightgear-devel] SID, STAR, and airway data
On Sun, 30 May 2004 21:58:12 +0200 Durk Talsma wrote: I hadn't really thought about that so much. However, while these SIDs and STARs wouldn't be very useful for AI traffic, they probably wouldn't be too problematic either. As long as there is an initial and a final waypoint, the expect vectors would then simply be the most direct route between these two. More precisely, you can define some arbitrary waypoints. For instance, if the SID says climb to zzz ft, you can determine the point (distance) at which the aircraft reaches that altitude, and have it marked as a waypoint in the internal AI flight plan. The next waypoint would then be the first en-route waypoint. Likewise, if the STAR says expect vectors, and if you are supposed to go for an instrument final approach, you can safely assume that ATC will try and vector you to a point approximately 4-6NM before the Final Approach Point, on the same axis as the final approach. I'm currently again leaning more toward a straight-in straight-out take on AI traffic as the first step, because that would simplify automatic flight plan/waypoint generation by quite a bit. Then next, if we have the data available on approach and departure procedures, these could be used instead. And that's more or less the way it works in real life, usually the first step is writing the flight plan, and for this you usually try and find SID and STAR flight paths. If you can't find them, you fall back on direct-to-waypoint-type paths. A good thing to do would be to try and implement the way ATC works as close to real life as possible. You can define these default flight plans for AI aircraft, and implement a clearance limit, which means that the aircraft can follow the flight plan safely up to a given point (usually a waypoint); you can also have altitude clearance (usually in order to avoid other traffic). Before reaching a clearance, an AI aircraft could ask for further directions/clearance from the ATC. If the ATC has a radar, it can detect that the aircraft is approaching the limit and give further directions without having to be asked for them. You might be interested in the rules of ATC (traffic separation using time or distance or altitude), most of it should be in the ICAO document . I don't know where to get it, but I had been given one while I was preparing for the ATPL theory exam. I did a little search with Google, and apparently the document (official title Procedures for Air Navigation Services - Air Traffic Management or PANS-ATM, ICAO document number ) is for sale for $161 on the ICAO website... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SID, STAR, and airway data
On Wednesday 26 May 2004 23:21, David Megginson wrote: I agree. Unfortunately, you will find that many SIDs consist of something along the lines of - fly runway heading - maintain 3,000 ft unless otherwise advised by ATC - expect vectors on course Similarily, many STARs simply provide an altitude and a starting point, and then state that the pilot should expect vectors to the runway. Neither will be too useful for AI work, I'm afraid. I hadn't really thought about that so much. However, while these SIDs and STARs wouldn't be very useful for AI traffic, they probably wouldn't be too problematic either. As long as there is an initial and a final waypoint, the expect vectors would then simply be the most direct route between these two. I'm currently again leaning more toward a straight-in straight-out take on AI traffic as the first step, because that would simplify automatic flight plan/waypoint generation by quite a bit. Then next, if we have the data available on approach and departure procedures, these could be used instead. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SID, STAR, and airway data
In February Erik Hofman mentioned that Robin Peel maintains a database of airway data, for shared use between x-plane and FlightGear. I was wondering if there's also a database of SID and STAR procedures that we could use? The reason I'm asking is that these might be extremely useful in developing AI traffic. IIRC, the airway database is currently not included in the cvs base package. Where would I be able to find it? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SID, STAR, and airway data
Durk Talsma wrote: In February Erik Hofman mentioned that Robin Peel maintains a database of airway data, for shared use between x-plane and FlightGear. I was wondering if there's also a database of SID and STAR procedures that we could use? The reason I'm asking is that these might be extremely useful in developing AI traffic. It would be better than what we have now, but it wouldn't be realistic. SIDs and STARs are fallback procedures in case of lost comms -- in real life, ATC has never had me fly one all the way through, and most of the time, my arrivals and departures bear little resemblance to the SIDs or STARs, even when they were part of my initial clearance. 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. IIRC, the airway database is currently not included in the cvs base package. Where would I be able to find it? DAFIF has a complete airway database. I actually used it once for real-life flight planning when I had my notebook with me but couldn't get online and had left my charts in the plane. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SID, STAR, and airway data
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
Re: [Flightgear-devel] SID, STAR, and airway data
Durk Talsma wrote: 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. I agree. Unfortunately, you will find that many SIDs consist of something along the lines of - fly runway heading - maintain 3,000 ft unless otherwise advised by ATC - expect vectors on course Similarily, many STARs simply provide an altitude and a starting point, and then state that the pilot should expect vectors to the runway. Neither will be too useful for AI work, I'm afraid. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
