Status of AI in FlightGear

From FlightGear wiki
Revision as of 05:38, 26 June 2014 by Hooray (Talk | contribs) (Scripted AI Missiles)

Jump to: navigation, 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)
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

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 he 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

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

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