Status of AI in FlightGear

From FlightGear wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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)
Cquote2.png
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)
Cquote2.png
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.
Cquote2.png
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)
Cquote2.png
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.


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

What_is_Nasal
Nasal_for_C++_programmers

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
List_of_Nasal_extension_functions#maketimer.28.29_.28v._2.11.2B.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


Cquote2.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

http://www.mail-archive.com/search?q=ta ... eforge.net

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="http://www.youtube.com/embed/LL7bdHrR8uI" frameborder="0" allowfullscreen=""></iframe>

Cquote2.png
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)
Cquote2.png
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)
Cquote2.png

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:
search.php?st=0&sk=t&sd=d&sr=posts&keywords=fox2.nas

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

<iframe width="420" height="315" src="http://www.youtube.com/embed/UL7jQkl1qe4" frameborder="0" allowfullscreen=""></iframe>

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

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.


Cquote2.png
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)
Cquote2.png
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.

Cquote2.png
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!)


Cquote2.png
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.


Cquote2.png
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)
Cquote2.png
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)
Cquote2.png

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: https://gitorious.org/fg/fgdata/source/ ... tanker.nas
Cquote2.png
Cquote1.png hat 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 ...


Cquote2.png
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:


Autopilot.jpg
Custom-autopilot-dialog.png
Autopilot

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:
Route_Manager
Route_manager_internals

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.


Cquote2.png
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.

Cquote2.png
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).
Cquote2.png
Cquote1.png Curt posted on his blog this article about circle holding which will be of interest: http://gallinazo.flightgear.org/uas/spi ... 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.
Cquote2.png
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.


Cquote2.png

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:

http://diydrones.com/profiles/blogs/uas ... simulation
http://www.mail-archive.com/flightgear- ... 33987.html
http://www.flightgear.org/forums/viewto ... =4&t=13615

<iframe width="420" height="315" src="http://www.youtube.com/embed/cvbtSG9cy20" frameborder="0" allowfullscreen=""></iframe>

Cquote2.png