An integrated AI traffic system

Caution  Developer information: Some, and possibly most, of the details below are likely to be affected, or even deprecated, by the ongoing work on FGTraffic. This is because Durk is inclined to break away from the approach he took for the current AI traffic system. In his opinion, the code has become too clunky too be maintainable, he will try to spend a limited portion of his development time for bug fixing the current code, but please don't expect any major changes any more. The new approach he has in mind should surpass everything we currently have, but it's going to take some time until it's all implemented. To avoid conflicting efforts, you are advised not to start working on anything directly related to this without first coordinating your ideas with FlightGear core developers using the FlightGear developers mailing list. talk page..

Goals

• improve interoperability between AI traffic and AI ATC
• integrate existing AI traffic code with the FlightGear autopilot and route manager systems, so that AI traffic may make use of these systems
• improve realism of AI traffic by allowing AI traffic to be optionally FDM driven (i.e. JSBSim/YaSim)
• make AI traffic fully script-able
• make AI ATC fully script-able

Background

• 12/2001: "We need to be able to have multiple instances of various FDM's running concurrenty (and with your proposed changes, accessible through the property manager interface.) I'm thinking of things like random 'traffic' that would get created and deleted. For instance we have fdm[0], fdm[1], fdm[2], fdm[3] and then we delete fdm[1] because it flew out of range, but now another aircraft flies into view so we need to create fdm[4], etc."[1]

• 12/2001: "The cleanest solution is to have a separate property tree for each instance; globals could manage that, and make sure that the right one is always returned."[2]

• 11/2003: "wouldnt it make more sense to use the full FDM code with scripting to drive the existing autopilot code ?? i.e. script sets desired altitude, heading, speed, limits on pitch yaw roll rate of descent, etc allowed during manuevers, updates the desired settings in realtime based on positions of other planes and/or radio message traffic -- autopilot caries out those instructions -- isolates the AI from the actual complexities of controlling the aircraft "[3]

• 11/2003: "I started working on a generalized and scriptable version of my tanker, but have been sidetracked by other stuff."[4]

• 11/2003: "What I'm driving at here is having a headless client that does multiple fdm/autopilot sims on behalf of a server which may itself be handling several planes in addition to the net connections -- no graphics at all -- though a side effect will be to have a user controled plane + one or more AI planes -- it may not get used that way -- but someone might"[5]

• 11/2003: "what I'm asking is "everything looks like it works through globals rather than discrete instances of aircraft+fdm+autopilot -- am I looking at a serious architectural change to get multiple independent ac+fdm+ap simulated concurrently ??"[6]

• 11/2003: "wether or not the discrete aircraft code gets used in a single user, or server only environment isnt relevant"[7]

• 11/2003: "I was hoping to have multiple airplanes (each controlled by an individual program), each being updated once per video render instead of having independent execution frequency."[8]

• 11/2003: "FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either."[9]

Scripted AI Traffic

• 11/2003: "Yes I would prefer an ac+fdm+autopilot solution strictly for realism purposes" [10]

• 11/2003: "I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. I can see right off that it must be event driven, able to interupt its current procedure/task in response to external inputs, able to process complicated nested procedures with completion of a "statement" based on the current aircraft state or external inputs such as radio message or radar. It must span every level of interaction from "turn the plane to a specific heading" or "change altitude to a specified level" at the low end, up to extremely abstract commands like "fly the plane to to a specified airport and land" which would encompass all the procedures and interactions neccessary to take off from one airport and land at another, including all standard interactions with ATC and other planes along the way."[11]

• 11/2003: "At the bottom end, the script module should generate commands suitable to feed to an autopilot, AIPlane or, if desirable, directly to the plane being simulated (I havent looked at how kb/stick inputs interface to the simulation - do they feed into the fdm ??) -- this may end up requiring multiple "output" interfaces for the scripting engine."[12]

• 11/2003: "The reason I was looking at ac+fdm+ap is the autopilot provided out-of-the-box low level code to manuever the plane without the AI code needing to know the specifics of how to make the plane perform a given manuever. Adding low level capabilities to the autopilot would the expand the range of capabilities for the AI scripts. (think of the autopilot as the hardcoded manuevers that form the core of the AI language -- anything more complicated than that would be handled by scripted AI procedures based on the core manuevers)"[13]

• 11/2003: "the engine will have to handle the idea that different planes may have different low level routines, for instance, how you setup and perform a takeoff is different for every plane, so a generic script in common use by many planes must use the low level routines for the specific plane being controlled, wether or not that low level routine is hard coded or scripted (i.e. aircraft specific commands/procedures override more generic code in any shared command/procedure library) "[14]

• 11/2003: "I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures."[15]

• 11/2003: "Equally, the script engine output could be taken at a level where there is no FDM to control, for instance the AIPlane class, simply by defining hard coded procedures for that specific interface that override the low level FDM interface, and registering them with the script engine before starting a script. (thats getting complicated, but its much more possible if I know up front that I need to handle multiple aircraft interfaces)"[16]

• 11/2003: "Therefore low level control procedures need to be defined in layers so that implementors can pick where to hook in, and have a well defined list of procedures that must be implemented to hook in at that level."[17]

FDM driven AI Traffic

• "The present AIAircraft fdm won't do it though. It only handles "normal" maneuvers, like normal climbs, descents and turns."[18]

• "need a full FDM to pull that off, with the AI manipulating the stick and pedals directly.. something I talked about as a possibility for my script engine to accomplish. I'm using David's AIAircraft (as I believe Eric is for the Nasal interface), but a full FDM could be interfaced if needed :)"[19]

• "I personally think that fdm/autopilot is overkill given that they're dots in the sky unless you're illegally close."

• "Not always -- for example, watching another plane land or take-off while holding short is the best way to tell what the wind is doing (is the plane in a major slip on short final? is it crabbed way to the right on climbout to hold runway heading? is it bouncing around like a mechanical bull from gusts and turbulence?). In a busy circuit, it's not uncommon to be following only 0.5mi behind another plane, and depending on screen resolution, you can probably tell again whether it's crabbed, what its pitch angle is, etc. I agree that you should not normally be close enough to see control surfaces move unless you're practicing formation flying."[20]

• "Temperature and air pressure are important because they affect density altitude -- the plane should climb very lethargically on a hot day at a mountain airport and quite vigorously on a cold day at sea level -- again, these are things you watch while holding short of the runway."[21]

• "Furthermore, above FL180 (and north of about 60deg latitude at all altitudes) altimeters are set to pressure altitude, so you'll have to take air pressure into account eventually."[22]

• "Even in the circuit, circuit altitude is based on the altimeter reading, which (even when corrected for pressure) can be off a bit due to temperature and humidity. That's not a problem as long as everyone's altimeter is off the same amount."[23]

• "You can go through and try to support all of this, but in the end, it will probably be easier just to create a new instance of an FDM and autopilot and let them fly the plane. Note that I'm not suggesting that you do this now -- what you've done already is quite impressive. However, be careful that you don't end up unintentionally creating your own new FDM in its stead."[24]

• "I really think you should use FDM instances for the AI traffic: (1) So differenty types of aircraft will be handled correctly, (2) So slips, wind drift corrections and turbulence will happen right, (3) So we can use one autopilot interface and one FDM interface for both, (4) So the AI aircraft can merge nicely with multiplayer support"[25]

• "I do think you need to do a simplified thingy that just knows how to shuffle huge quantities of aircraft efficiently around the sky, so that they (eg)fly the pattern, or fly between airports, or wander around airways, or keep doing missed approaches at the same sequence of airports, or similar."[26]

• "However, I think you should build it as an FDM (or extend an existing FDM, if you prefer) to provide the functionality. That way, 90% of the AI vehicles can be completely trivially simulated and will be trivially rendered as a tiny distant white blob (due to someone finally putting a ssgRangeSelector on the aircraft visual model infrastructure)."[27]

• "Taking that approach lets us easily have the remaining 10% that we will be flying close to be extremely realistic, even for formation flight (which is permitted by the FAA, by the mutual agreement of both pilots). The only time that you can be illegally close to another aircraft is if the other pilot doesn't expect you to be there (or if you busted another rule to get that close, of course)."[28]

• "a lot of good reasons for using an fdm/autopilot combination for AI traffic from David Megginson and Alex Perry, I can see the point of wanting a proper simulation when within reasonably close visual distance of the target. My concern was that if there were a lot of traffic being simulated, a lot of it known to the pilot only through the radio communication, then using an fdm thats updating at 120Hz and simulating right down to the exhaust gas temperature is overkill, and that using a greately simplified model with basically a look-up table of typical speeds and climb/descent rates would allow the additional traffic to be updated in a queue with, say, only one plane updated per timestep if far enough away from the viewer. My concern was that updating a number of fdms per timestep could possibly introduce a noticable delay. I can accept the fact that when reasonably close the realistic behaviour of other aircraft provides useful piloting cues - I hadn't recognised the full significance of that. I personally think that a switch from a full autopilot/fdm combination to a greatly simplified where-to-fly/how-to-fly logic when beyond a certain distance/direction from the user is probably eventually justified (IMHO). "[29]

• "That's a good point. The other option would be to cut down the Hz for the AIs -- how low could we make it before the autopilot lost control -- 10Hz? 2Hz?"[30]