Status of AI in FlightGear

From FlightGear wiki
Jump to navigation Jump to search

AI Scenarios vs. Scripting

Cquote1.png I have the feeling they're a bit of a legacy feature. The AI system is pretty limited in what you can do, so AI gets replaced by more versatile Nasal solutions.

Compare tanker.nas with the AI aerial refueling demos - you can call the Nasal-spawned tanker everywhere when you're out of fuel, it interactively can provide you instructions to reach it, it automatically selects the tanker apprpriate for what you're flying,...

Compare the thermal demo with Advanced Weather - the AI thermals are on pre-defined locations, so there's just zero element of surprise in glider flight, you have to do a lot of preparation up-front in order to get gliding in a different location - Advanced Weather just generates them anywhere in the world, merged right into the other weather patterns,...

Nasal in static models makes them interact with aircraft, no need to pre-define AI or pre-load anything.

So if not for the Carriers, I think we could safely get rid of the AI scenarios - Nasal-driven Wingmen would be far superior in interactivity.

— Thorsten (Fri Feb 08). Re: AI-Scenarios.
(powered by Instant-Cquotes)
Cquote1.png I have to agree completely with Thorsten here. Scripting via Nasal makes it possible to move development of such features to the base package and delegate it to "user space" (contributors not core developers).

So that core developers can focus on writing C++ core. Just look at examples like tanker.nas, fox2.nas, [url]Curt's fully autonomous f14 demo[/url] or flug's bombable addon: They all use Durk's AI traffic system as their backbone and foundation, but they provide totally different and novel features on top of it.
In fact, there has so much more "AI" development taken place, just because the AI traffic system has become scriptable through the property tree.

Using Nasal, it would be possible to create AI traffic that responds to ATC instructions, and even ATC controllers that control simulated and AI traffic
So there's tons of flexibility here without C++ developers and their spare time being the bottleneck

— Hooray (Fri Feb 08). Re: AI-Scenarios.
(powered by Instant-Cquotes)
Cquote1.png The AI system itself is not all that flexible, but the various scripted approaches (tanker.nas, bombable etc) do use it as the backend for placing traffic, even though all the control logic is then handled in scripting space.
Cquote1.png the code to do this is already readily available in FlightGear.

$FG_ROOT/tanker.nas is a good demonstration for code that iterates over the AI properties.
Another good example is the multiplayer pilot list, which also iterates over the property tree.
You only need to combine snippets from these two files to come up with what you need.

— Hooray (Mon Nov 29). Re: Working with AI/Multiplayer properties.
(powered by Instant-Cquotes)
Cquote1.png the most flexible approach would be using scripting - FligthGear has a built-in scripting language (called "Nasal"), that can be used to control aircraft, and even to instantiate multiple AI aircraft, one of the most straightforward examples is the "tanker.nas" script, which creates a fully scripted AI tanker - that could be easily extended to create dozens of tankers, and obviously you could also change the 3D model if you wanted to. In fact, we have a separate addon, named "bombable" that adds "AI bots" to the simulator, for dogfighting purposes - none of that required C++ changes, it's all done in scripting space. Another users implemented a fully scripted missile (fox2.nas) that tracks aircraft - and we also have a feature for "wingman" support, too.

Actually, you could even create scripted AI pilots and scripted AI ATC that interact with eachother - it's all doable, and doesn't require rebuilding FlightGear from source.

Cquote1.png For starters, I'd suggest to read through these:


You'll find a few analogies in those articles - but basically, Nasal scripting works exactly like JavaScript in your browser: it's an embedded extension language, that is integrated into FlightGear as a conventional FlightGear subsystem - during each frame, the Nasal interpreter gets its time slice to process scripts - which is why badly written scripts may slow down the sim and affect frame rate/frame spacing - in addition, Nasal supports dozens of FG-specific extension functions to do various FG-related things - which allows callbacks to be registered in the form of property listeners (which get invoked whenever a property is written to) or via timers (that may expire and trigger a callback). In addition, there's a standard library of Nasal library functions and a plethora of FlightGear-specific modules in $FG_ROOT/Nasal that greatly simplify coding stuff from scratch.

To learn more about timers, see: List_of_Nasal_extension_functions#settimer.28.29

To learn more about listeners, see: Using_listeners_and_signals_with_Nasal

You can start playing around with Nasal by using the so called "Nasal Console": Nasal_Console
Nasal console.png


Scripted AI in FlightGear

Cquote1.png Another example is the "tanker.nas" script in $FG_ROOT which implements a simple scripted AI tanker for AAR purposes: search.php?st=0&sk=t&sd=d&sr=posts&keywords=tanker.nas ...

And then we have the fox2.nas script which implements a fox2 AI missile using Nasal: search.php?st=0&sk=t&sd=d&sr=posts&keywords=fox2.nas

The "bombable" addon is completely implemented in Nasal and created multiple virtual pilots for dogfighting purposes: Bombable

<iframe width="420" height="315" src="" frameborder="0" allowfullscreen=""></iframe>

Cquote1.png The simplest solution is probably using scripted AI traffic nodes. Note however that AI traffic cannot currently make use of any FDMs (JSBSim/YaSim), instead you need to come up with your own "pseudo FDM" in scripting space.

You might be able to circumvent this restriction by coming up with a separate FDM and communicating with FG using sockets.

We have a number of more or less complex examples for this. $FG_ROOT/Nasal/tanker.nas is the simplest test case you'll find, which basically spawns an "AI tanker" that can be used for refueling purposes. It would be possible to generalize the script some more in order to spawn an arbitrary number of aircraft. Also, you could equip them with a scripted control loop, so that each node can be controlled individually, i.e. by either setting a bunch of properties, or even by issuing ATC instructions.

Curt has recently provided a more complex example.
The most complex example for this technique is certainly the "bombable addon" which implements "AI bots" entirely in scripting space to provide "dog fighting" support.

I would suggest to search the archives (wiki, forum, mailing list) and look into the aforementioned examples.

Also, you'll inevitably need to look into the Nasal documentation, too: Nasal_scripting_language

— Hooray (Tue Jan 03). Re: Multiple intelligent flyers.
(powered by Instant-Cquotes)
Cquote1.png It really doesn't take any longer than say 2-3 minutes to open the tanker.nas script, change the model file name to point to the 3D model of a bird, what you end up with is a "funny bird" flying at 330+ kts ground speed at 17000 ft AMSL (I took the first freely available bird model that I could find...):

(see the linked image)

As a next step, one could change the heuristics that move the bird (assuming that you don't want it to keep flying refueling patterns...), making it search actual thermals (local weather) would also not seem too complicated - it would just involve calls into the local weather code.

Probably, you'll want to add some collision detection code then.
Once this is working, you may want to animate the whole thing and probably change its size, too.

Like I said, it's all perfectly possible with the tanker.nas script.

— Hooray (Wed Sep 22). Re: Bird strikes script.
(powered by Instant-Cquotes)

Scripted AI Missiles

Cquote1.png xiii is the developer of the F14b's fox2 implementation, the original thread was: Subject: Missiles with seeking capabilities.

To find related threads, see:

Subject: Custom dialog, nasal console etc. to fire a missile?

<iframe width="420" height="315" src="" frameborder="0" allowfullscreen=""></iframe>

— Hooray (Sun May 05). Re: F-14B's Weapon System  .
(powered by Instant-Cquotes)

Learning AI

Cquote1.png most everything is possible here.

Just a little damper, Bombable is not really supported and imho wasn't conceived with software architecture in mind. I think it would be better to think on a robust and modular AI implementation so any other existing or future piece could use it without requiring Bombable. This doesn't say that Bombable couldn't use it.

Cquote1.png It is certainly possible (like xiii said already), however it will require a solid background in AI and coding. It could definitely be implemented without touching any C++ though (i.e. using scripted Nasal code).

I am disagreeing a little with xiii regarding the feasibility of using the bombability package for this, it's actually pretty well-written and well-commented source code. However, it is obviously a huge and complex piece of software. Just understanding how everything works, will take weeks or even months.
In other words, it might be simpler to start out with something standalone - i.e. based on the tanker.nas example, so that you could first create an AI bot using NN which controls the tanker (or some other aircraft) and then consider integrating this with the bombable package later on.

— Hooray (Sun Jul 08). Re: Possibility of incorporating "learning" AI?.
(powered by Instant-Cquotes)
Cquote1.png Bombable is definitely large & complex and though I'm interested in continuing to develop it I am also very limited in my spare time available right now.

Flip side is, it could written (in fact probably SHOULD be written) as a completely stand alone module that just reads the location & other info from the property tree for the main AC and the AI AC of interest, and gets the general geographical and other information it needs to navigate the through the regular FG functions and the property tree variables for that sort of thing.

Then you could develop some kind of API type thing to communicate with Bombable where the AI pilot module puts the current piloting info into the property tree (or just a nasal data structure, probably better for speed), including info like:

  • which direction/how much to turn/turn rate
  • which direction/how much to climb or dive/climb or dive rate
  • whether to speed up, slow down and by how much, and rate
  • Also right now Bombable implements loops as a special/separate routine - but they are easy enough to trigger with the same API type of approach, just send the data along via the API to say 'start loop' and a few parameters to define what the loop will do.

Cquote1.png Bombable could then read these nasal variables and/or the property tree or however the module-to-module communications API is worked out, and take the appropriate action.

This would be pretty simple to implement just because Bombable is already doing something very similar to this, but it uses its own internal logic to make those decisions about turning, climbing, diving, looping, etc. It could just as easily take those cues from an outside module.

The only other things that Bombable is currently using for AI aircraft decision-making are (1) weapons hits and near hits on the AI/AC, (2) overall AI/AC damage level, and (3) in the last version I implemented some code to simulate the AI/AC's fuel situation (with good fuel reserves the AC will attack aggressively, when fuel gets low it turns tail and slows down to conserve fuel). Those things could easily be implemented via the AI module as well, with info passed back & forth via the property tree or a nasal data structure. There are only a few simple parameters for all of those items.

So--I think this *could* be done with Bombable as a completely separate module that only interfaces with Bombable via an API type interface and furthermore, the API would be pretty simple. I think. (Famous last words, I know!)

Cquote1.png The other flip side is, even if this is the long term plan it might still be smarter to start by implementing this same kind of an AI system (including the idea of an API-type interface that would allow the new AI piloting module to get needed info from other modules as needed and transmit the piloting instructions back to another different module that would do the actual piloting) but choosing a much simpler task for the first project.

Then once the basic ideas have been worked out and are functional, tackle the much more complicated project of making a convincing AI fighter pilot module--which, really when you think about it, is what is needed for Bombable.

Making an complete, realistic AI fighter pilot module is a pretty daunting project, really! The only thing that makes me think it is even possible at all is that the current Bombable pilot AI really only has a very, very few basic behaviors (attack in certain situations, evade in certain situations, do a loop in certain situations, retreat in certain situations--that's about it) and it really works much better than I ever imagined it would, given that absolute simplicity and complete unsophisticated-ness of the AI pilot model it's using.

Cquote1.png we should probably consider this a long-term goal, and then it would make sense to extract the AI control code from bombable into some separate "ai.nas" module, i.e. splitting up bombable into separate files.

So that some of these could eventually be moved to the Nasal standard library directory in $FG_ROOT/Nasal, this is where we could then have a separate "ai.nas" module that allows controlling AI objects via the property tree. And another "pilot.nas" module which uses the ai.nas module.

It should definitely be simpler to do this with some standalone aircraft, or maybe just the tanker.nas module. So that we could tackle this task separately, reuse as much of the bombable code as possible, and re-integrate the results later on via some sort of API, like you say.

— Hooray (Thu Aug 02). Re: Possibility of incorporating "learning" AI?.
(powered by Instant-Cquotes)
Cquote1.png Custom "pilot" implementations could then be provided for different purposes, i.e. by reimplementing an abstract "pilot" base class and overriding functionality as required.

Currently, the major showstopper is probably the complexity of the whole system, and having to understand it in its entirety, if bombable could be split up into separate modules, that should be made easier - also, adding the bombable package as a Nasal subsystem (sub module) to the base package should be easier then.

Also it's worth mentioning that there have been discussions on exposing the autopilot/route manager system and the FDM system to Nasal space via the property tree and/or new Nasal extension functions, that could also help to make some old code obsolete, i.e. because a real autopilot or FDM could be used for scripted AI traffic eventually.

— Hooray (Thu Aug 02). Re: Possibility of incorporating "learning" AI?.
(powered by Instant-Cquotes)

Neural Networks

Cquote1.png the AI in its current form is fortunately still hard coded and not based on neural networks, otherwise they may even predict your actions/evasive maneuvers
Cquote1.png If you know Nasal, you could certainly teach bombable to become a bit smarter, i.e. by adding support for standard combat maneuvers (like you mentioned). In its simplest form you could code a state machine that responds to standard situations with a randomly chosen standard response (and maybe some dynamic variation). It would be a matter of coming up with a state machine implementation in Nasal so that the AI can match up situations against suitable responses. It is definitely possible. I was in fact talking to flug a while ago about adding neural network-based AI to bombable. If there are enough people interested in this aspect of making bombable even smarter, then we could certainly come up with some more challenging AI bots.
Cquote1.png I just looked into bombable's Nasal code, and it seems really not only well commented but also pretty well structured and generalized already, and I think another possibility to balance the whole experience would be to provide an option for setting up AI bots (or wingmen) to help you fight the bad boys.

Pretty much like AI bots that help you defend/protect an objective - while helping fight other AI bots.

One possible method would be to set up an option to spawn friendly forces on demand. To come and help you. Either using a hotkey or a GUI dialog.
They could either be spawned at a configurable fixed position (i.e. KSFO) or within a configurable range of your current position (say 20 miles).

There is also some good information available on creating autonomous dogfight agents: CREATING A DOGFIGHT AGENT: The design and implementation of a fully autonomous agent that can fly an airplane during a one-to-one dogfight.

Cquote1.png Basically, the technique is now called "adaptive control systems", which resulted in "self-reconfiguring bots" that could really learn things like controlling a simulated aircraft.

This "learning" was based on a "punish/reward" system, and these agents were actually able to cooperate to a certain degree, to achieve their goals.

In fact, these "Norns" were even so good at doing their job in the simulated world, that they were immediately used to fly real aircraft, namely UAVs

Cquote1.png We talked about this a number of times, and the bombable developer (flug) repeatedly indicated an interest in adding this
— Hooray (Sat Jul 07). Re: Possibility of incorporating "learning" AI?.
(powered by Instant-Cquotes)
Cquote1.png I like this idea a lot.

One basic problem is that Bombable is basically sitting on top of the FG AI flight system, which is indeed designed to make aircraft fly "like airliners".

But, especially if there is interest to make like a neural net type intelligent/learning system for AI fighter aircraft I think both the Bombable and Flightgear problems could rather easily be solved. The changes that would be required in FlightGear's C code are not that difficult, I believe.

Cquote1.png Right now, the Bombable aircraft only do three things:

1. Steer directly towards you if you are within their detection range  (and steering towards you means, both in heading and altitude)
2. Wait until they have passed you by a certain distance to steer back towards you
3. Dodge if you shoot close to them or hit them

They also try to avoid crashing into the ground a few other basic things like that.

Considering the very, very basic nature of their behavior programming, they actually engage in some pretty complex behavior.

Cquote1.png However it is only (and is only intended to be) a proof of concept--that we can control the AI aircraft within FG, using fairly simple nasal scripting and pretty simple behavior patterns, and make some pretty interesting behavior out of it.

I think if we were to implement an idea like Hooray's we could have some very interesting AI aircraft flying indeed, and it probably wouldn't need to be that hard or complicated.

As I've mentioned in a few other messages, Bombable is always limited by FG's native AI flight system, which is very sedate both as far as turning and (even more so) climbing & diving. It's really designed to model airliners flying sedately from there to there & it will take just a few changes to the underlying C code to make more complex & aggressive maneuvers possible.


Controlling the main Airplane

Cquote1.png I'd suggest to get started by looking at the tanker.nas script instead - fox2.nas, the f14b demo and the bombable script are much more sophisticated, while tanker.nas is really pretty simple and straightforward: ... tanker.nas
Cquote1.png That would be great - but you'll probably want to look at tanker.nas for now, and look up the various APIs used there (see the wiki).

The other examples are a little more involved.

Also, it will be important if you are going to control the main aircraft, or some form of AI aircraft - because properties may differ then ...

Cquote1.png If this is all about "bots" controlling aircraft, then you can do this already.

Take for example a look at another discussion a couple of days ago: viewtopic.php?f=5&t=6807&p=66463#66463 (should probably also be moved to the new AI sub forum), where I roughly sketched out how to use Nasal to control an aircraft.

So this could then be used to create such "bots" (scripted pilots) for aircraft by using Nasal.

— Hooray (Sat Mar 20). Re: AI development (bots) / AI engine.
(powered by Instant-Cquotes)
Cquote1.png you can simply look at the autopilot dialog of your aircraft (e.g. c172p, b1900d or 777) - sometimes, looking at the cockpit panel may also make sense (MCP) - otherwise, you can then simply use the autopilot system to control the aircraft, which also includes support for flying complete routes via the built-in route manager, for details, see:


These are just XML files (GUI dialogs in $FG_ROOT/gui/dialogs or somewhere in $FG_AIRCRAFT - if customized) - so you can simply open those files and look up the properties for the various autopilot modes that you want to use (heading hold, wings level, altitude hold etc).

Equally, the route manager is well-documented:

So, basically, you really only need to set properties via setprop/prop.nas to control the route manager and/or autopilot, which will in turn allow you to control the main aircraft - this is much more straightforward than controlling AI traffic, because all these hooks aren't currently exposed yet.

Cquote1.png you will mainly use the autopilot to control the aircraft (since it has a real FDM it's kinda hard to control), and we would definitely recommend one with a developed autopilot (the 777s are really excellent with everything and has a good autopilot with all features you want). I don't fly in aircraft a lot, and like only three times with an autopilot, so I can't recommend any other aircraft with good autopilots. But one option with the 777 is that you could potentially use Nasal to dynamically edit routes that the aircraft just flies – not much work there. Another approach would be manually adjusting the autopilot parameters (like heading hold, bank angle, and stuff like that) through Nasal feedback algorithms for aircraft that don't have a.route manager. You could also couple this with the XML autopilot (now called "property rule") system to have real PIDs, easy lowpass, etc.

Cquote1.png there are two aspects to Nasal: that of interaction with itself and with the property tree. For your purposes, the property tree is going to be your communication with the wider FlightGear code. Nasal also can use its own mechanisms to interact with different things (file system, route manager, fgcommands, ...). In interest of the web browser analogy, XML in FlightGear is like HTML. Specifically it is responsible for setting up much of the property tree that FlightGear's subsystems act off of. David Megginson (creator of FG's property tree) once said that "XML should provide the nouns, Nasal should be the verbs" (or something, that isn't a direct quote) – so PropertyList XML is really good at providing data that Nasal can work off of. For like the fox2.nas script, this means that ideally all of the specific data about the missile would be taken from Nasal and stored in an XML file (which would be loaded by the Nasal file and the data would be copied over).
Cquote1.png Curt posted on his blog this article about circle holding which will be of interest: ... r-control/. If he isn't too busy, you could ask him about some more of the details or ask where to learn about the algorithms he used. I don't have time to reread it, but I think he used like the rascal or other small aircraft and a Nasal algorithm consisting of (I'm just guessing here) bank hold (to set up an approximate radius and to turn in a circle) and bank angle correction (to get the right radius, to stay on track and correct errors, etc.). He also mentions a lot of control mixing in the article required to maintain the fine balance of throttle/speed, bank angle/turn radius, and pitching/altitude, so it was probably more sophisticated than that.
Cquote1.png he algorithmic side of things should be fairly straightforward in this case, because it's all hidden in the depths of the AP/RM systems, so from a high-level standpoint, it's really nothing else than using setprop() to switch between AP/RM modes and then setting the corresponding parameters (altitude, speeds, heading, course etc).

You could even fly a holding pattern automatically like this, without ever having to do any fancy maths.


Fully Automatized Missions

Cquote1.png Yes, it is possible "to make" such a mission - but you will literally have to MAKE it by writing a script to outline all required steps for your aircraft.

Curt did that a while back for the f14b, which did a fully automated carrier approach using just Nasal scripting: ... simulation ... 33987.html ... =4&t=13615

<iframe width="420" height="315" src="" frameborder="0" allowfullscreen=""></iframe>