Hello Durk, I'd like to start working on ATC and AI with you. Not today and probably not this month, but soon. I currently don't have a lot of time so let me make this short and quote from IRC (hope you could manage to get on there).
My actual point being the following - I know this sounds a kind of supervisorish given that I've yet to contribute something but I think I'm the kind of guy who is good at keeping the overview and I consider myself a very clean and structured coder and abstract thinker, so give my opinion a chance, will you: What you have achieved so far is very good I think, but it's right what its needed and where we need to stop at. I'll explain this statement later. Given two building blocks * Airports Good job there. My info comes mostly from the wiki. I agree that one airport should be one distinct chunk that contains it all. "All" includes ** Ground Networks (already fully implemented) ** Airspace specs, Navaids of the AP (I learned there is no such thing yet) ** Buildings/Geometry Right here, the important thing is to define the specs and leave implementation open so far. Again, my understaning is limited and solely based upon the wiki but I find that ground networks is just the way it should be: A precise and self-contained description of the ground network which defines details which are of use to future extensions. Airspace specs / navaids holding patterns / approach plates - well I know rather nothing about how this is handled so far. I assume the data exists but I'm pretty sure it's damn difficult to get this specified. I know microsoft managed in their FSX so we will sure as hell manage, too. A remark: I think MS FS(X) has, despite its shortcomings quite a few properties we might closely align ourselves too. This topic being one of them. Check the garmin/GPS of FSX and you'll know what I mean. I think screetshots will already be impressive. Back to topic: As with groundnetworks, I find that arirports should contain all their airspace data. After all a airport could be considered an overlay over global air corridors and such. Right here, its all specification again. How is the data stored and provided. --Example : approach plates are pretty well formalized already so they could be copied as-is into xml files, referencing ndbs vors etc where needed and defining holding patterns as vector data-- --Example : Airspace specs can go in a distinct file. One airport-"package" can define an abritrary amount of airspaces and have difference frequencies/controlers handle them-- But let's not go into the details too much. This was building block one: Airport specification, including ground, airspace and the actual look (geometry) Second building block: AI * AI AI now refers to the actual IMPLEMENTATION of AI, however on a rather crude and low level. AI driven planes should provide an interface to receive a set of instructions. Given ahead: These functions should again be called from an encompassing AI engine which interfaces with ATC - see later **Highlevel - on ground: GOTO __adjacent__ (and adjacent only) ground network node -> plane travels thereFREEZE right there -> plane brakes and wont move **Highlevel - airborne: GOTO vor/ndb/etc -> plane changes heading and heads straight for the navpoint GOTO position -> plane heads straight for that position HEIGHT height + sinkrate -> plane changes FL or height with given sinkrate **Lowlevel: CONTROL control -> plane performs a maneuver (like pitch by 2 deg or increase thrust) ACTION -> plane performs an action (like lower gears) These are fundamental AI functions, of course just a rough set of examples to make my point clear. Here we have two building blocks which already fairly well implemented. The point is to realize that those two are the foundations of a much bigger framework. And since this foundation has to support a big third building block, which is actually more like the hosue itsself, its crucial that the two former building blocks are matured and thought-out. I'm proposing to clearly say that these two buildings blocks are then finshed, polished and self-contained. they may lay arround useless for a while, all on their own, but its important to maintain this very self-containment and not reach out further from there. Instead, in order to achieve a much bigger and visionary goal we will step back, walk arround the problem and now tackle it from another side, another perspective and we will eventually converge to our final goal from two sides. With the two rather fundamental (yet powerful - i admider the groundnetwork) building blocks on one side of the issue, the third massive building block lies on the other side: * ATC ATC - the singleton - mama and papa to the two other building blocks is where the real work starts. So far, we have specs, no implementation (apart from an orphaned rather low-level AI implementation). the ATC is, again, rather a house and for the sake of clarity to be split it several chunks. The point: Change of perspective. From the individual plane-centric vantage point to the point of controlling all AI (plus human pilots). From here, the actual framework emerges. It's straight forward tho - not easy but still, straightforward. Chunk 1: Ground control: We need alhorithms, given the position, states and demands of all positions on the ground, which route the planes. Ground control will communicate with a planes AI - which is not the low level AI of building block 2 but an ATC-aware encompassing AI, which I already mentioned above but would like to count to the ATC-building block. Ground control ROUTES planes. It accounts for their DEMANDS - not for any SCHEDULES. Ground control is not aware of schedules and flightplans (another chunk is - which kind of reflects reality). Ground control ROUTES, or rather TRIES to route by giving out instractions to the AI (again, no part of ATC communicates with low level ai building block 2 directly - only the encompassing ATC-aware AI does, which is yet to be defined) Chunk 2: Air control: Handed over planes, given their positions, states and demands AND flight plans. It does what air control does - do not confuse logical structure with real-world structure. Air control can be approach communications and airspace communicatiosn alike. its just classified by the fact that it knows the planes schedules. It accounts for navaids, approaches, etc. Again, it TRIES to ROUTE planes, this time in airspace, giving out instructions to the ATC-aware AI. Chunk 3: ATC-aware AI: It emulates, more or less, a real artificial Intelligence, rather than the low level ai which is mere mechanics. Chunk 3 of building block 3 is were a lot of flexibility is given. Indeed, the implementation of the Ground- and Air-control is by my suggestion also pretty much open to anything. However, as opposed to Ground and Air control which HAVE to meet at least certain requirements to be considered functional, we can vary the ATC aware AI from incredibly dumb (no CPU usage ^^) to stunningly smart. Air and Ground Control is mere algorithmic: Find the best taxiway from G12 to R7, Check for possible collisiosn and communicate planes to stop, Select approach based upon and accounting for preference of the pilot, available runways and waiting planes and so forth. The Control chunks make no decisions - they just make calculations. The ATC ware AI has a flightplan which it tries to fulfil. the flightplan - i dont think i have to mention that - is what is already implemented by you: Traffic files. An example to convey the responsibilities of the chunks and building blocks: shorthands AI = ATC aware AI A = low level AI (block 2) GC = ground control AC = air control TF = traffic file TF => AI: Fly from X to Y AI => AC: Give me a flightplan AC calculates flightplan in global corridors AC => AI: Suggests flightplan AI (flexibility applies) says either yes or no, or unconditionally yes to the flightplan AI => TF: Is it time to go? Once it is: AI decides which runway to take AI => GC: Requesting to taxi GC => AI: gogogo! *calculates taxiways* Here is how you taxi AI => A: push back, goto 1st point on taxiway AI => A: ok keep going, next node AI => A: you know the drill... GC calculates there is a colision ahead GC => AI: Halt! AI => A: FREEZE GC => AU: gogogo! AI => A: UNFREEZE AI reaches end of taxi AI => GC: Wanna go on runway (blindly follow my take of routinge -> flexibility) GC => AI: aight. AI => A: take off GC => AI: you get a new assignment ... well, ill skip the rest as its not only pretty obvious by now - if you look thorugh it it should become apparent that while we have difficult parts ahead, if you break it down it becomes pretty straightforward and many parts are mereley methodic. the clue: while an elaborate ATC seems difficult at first, with what you have already implemented you just set the exact right corner stones for us to build upon - not blindly improving the cornerstones to become conerpillars and eventually cornerhouses but rather by leaving the cornerstones modular as they are and step onto the next level. all of you guys appear pretty solid software devs (so i consider myself) so i think we all know that many projects with great potential fail because one looses the perspective half of the way. looks like you have not only brought new persepective into the AI section of FG you havent lost a bit of its so far. everything perfectly settled and ready to be aligned with eachother - lets not spoil it ^^ Ok now, nothing ingenious in my "AI: hello atc, may i...? ATC: yes, ofc you may..." which is cool because if you look at it like that and realize just any valid structure behind it its like made for straight forward object oriented programming and with these kinda small parts easily extensible. of course there are issues. but if you sleep over it for a night i feel the issues will break down and you can see that we are facing isolated problems, not so much intertangled as the assignment "build an AI which is integrated with a player-oriented ATC" may sound. bringing approach plates and the-like into a database might be one of the biggest tasks and one of those we will have to think about a lot how to do it properly. my personal feeling is that once we got the Air-control of ATC figured out to direct planes at least HALF-way correctly we are 30% done - at least to me it seems like the biggest part. ground control has a pretty solid codebase already, i take it so no matter that we would probably toss the current plane-centric ground-control AI away, the algorithms and the experience are there. anyway, i dont want to go into details right now, there are better people to elaborate on the finesse and techincal dificulties such a project might face. i just have a last, rather unrelated comment on how to handle all this efficiently: i find that we need NOT to implement a detailed management that keeps track of all the planes arround the world. right now planes that leave a reasonable range from any human pilot are just calculated based upon how long they fly and their turnarrounds are. if I see a boeing leaving JFK for EDDF (is there such a route, i dont know) and take of for EDDF an hour later, i wouldnt care if that very boeing had arrived 5 hours before me or even arrives an hour later than me. i wouldnt care as a pilot and even if im that obsessed with realism i could not argue that it might have had an unexpected stop or something (assuming that i even knew its flight plan). that said i would reduce calculating anything reasoable for the planes in the immediate proximity. thanks for your time ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
