Status of AI in FlightGear: Difference between revisions
No edit summary |
m (→C++ Issues) |
||
Line 526: | Line 526: | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
|date=<nowiki>Mon Feb 04</nowiki> | |date=<nowiki>Mon Feb 04</nowiki> | ||
}} | |||
}} | |||
== C++ Issues == | |||
{{FGCquote | |||
|It would be great if the flexibility of the current system could at least be retained or possibly even extended, for example: your heavy use of the property tree and listeners for instantiating new traffic has made many things possible that you probably never were planning to support, such as AI traffic or AI guided missiles controlled by Nasal scripts.<br/> | |||
<br/> | |||
If this pattern could also be transferred over to the ATC component, then we might eventually have ATC controllers scripted entirely in Nasal space, interacting with AI "pilots" controlled from Nasal. The C++ code would just provide the interface for Nasal scripts.<br/> | |||
<br/> | |||
Given the small number of C++ developers working on the ATC/AI systems and given the complexity of creating a full working AI/ATC system, it would seem to be a sensible decision to move more and more parts out into scripting space where functionality can be developed, contributed and maintained by users rather than core developers? <br/> | |||
<br/> | |||
The underlying C++ code is already fairly sizable and complex, so it would be great if it could be controlled from scripting space and down-stripped to just provide the required interface itself, that should also make your job much easier. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134933&sid=b6751abc5e37df35975f178c70838e28#p134933 | |||
|title=<nowiki>Re: New ATC / AI interactions</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Wed Aug 31</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|Note that I won't oppose other ideas, and if you have nasal code that would require certain components of the AI system to be shutdown, or need specific hooks to interface certain C++ components with nasal bindings, than I would certainly be willing to support that. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134970&sid=b6751abc5e37df35975f178c70838e28#p134970 | |||
|title=<nowiki>Re: New ATC / AI interactions</nowiki> | |||
|author=<nowiki>durk</nowiki> | |||
|date=<nowiki>Wed Aug 31</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|Regarding "flight plans", I was just reading [http://sourceforge.net/mailarchive/forum.php?thread_name{{=}}m1wrkaf65u.fsf%40usa.net&forum_name{{=}}atlas-devel this] on the atlas mailing list.<br/> | |||
It seems there is some confusion regarding the different types and roles of "flight plans" supported by FG.<br/> | |||
<br/> | |||
In the long run it would be great if the concept of a "flight plan" could become well-defined for all affected systems, so that the same code could be used for both, the AI/ATC systems, as well as the built-in route manager - then we would have just one single type of "flight plan", which would eventually also improve code reuse and sharing among related systems.<br/> | |||
<br/> | |||
I think zakalawe mentioned plans along those lines some time ago, so it'd be good to keep those things in mind:<br/> | |||
<br/> | |||
For instance, the addition of support for DPs, STARs and IAPs is something that would quite obviously be useful for all 3 components, AI, ATC and the route manager. Same applies to RNAV support, I guess? | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134933&sid=b6751abc5e37df35975f178c70838e28#p134933 | |||
|title=<nowiki>Re: New ATC / AI interactions</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Wed Aug 31</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|James and I have plans to unify our approaches. One of the reasons why I have put my plans to implement SIDs and STARs, as well as more complicated airway following in flight flightplans on the back burner is to give James some time to finish is work on the route manager. This way we can work towards a common format that is shared between the route manager and the AI system. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134970&sid=b6751abc5e37df35975f178c70838e28#p134970 | |||
|title=<nowiki>Re: New ATC / AI interactions</nowiki> | |||
|author=<nowiki>durk</nowiki> | |||
|date=<nowiki>Wed Aug 31</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|I guess, it might be a good idea to eventually start collecting a list of things that would need to be changed, i.e. like what Thorsten did for prioritizing core-changes to improve his local weather system using the wiki. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=140381&sid=4aa5400d0368eaa508a44abd83e43073#p140381 | |||
|title=<nowiki>Re: AI & MP Dogfighting now working! Bombable ships, aircraf</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Sat Oct 15</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|I was looking into the code, and I think this is a "problem" that can be easily solved by disabling some of durk's AI traffic code, basically it is simply "too smart" and making too many assumptions about the type of aircraft/flights it is controlling, at the moment. <br/> | |||
<br/> | |||
Disabling code should be merely a matter of introducing a bunch of new properties to make such assumptions optional. <br/> | |||
Sort of like a more pure, or a "raw" controlling mode where everything related to "airliner assumptions" is simply disabled.<br/> | |||
<br/> | |||
I think, durk won't mind that at all, because it's not really introducing new code or touching existing code, it would by default keep everything "as is", but only introduce a bunch of control properties to disable some of these defaults.<br/> | |||
<br/> | |||
For your Nasal code, that would basically mean to set those new properties and handle those things in Nasal space instead. Maybe, you could come up with a list of "airliner-characteristics" that you would like to disable/control yourself eventually? | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=140382#p140382 | |||
|title=<nowiki>Re: AI & MP Dogfighting now working! Bombable ships, aircraf</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Sat Oct 15</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
| this is helpful. I've never managed to get the target-hdg or target pitch methods to work.<br/> | |||
<br/> | |||
However, the solution to most of the problems I've outlined above would be to create 1. a new heading/directional mode that disables target roll and target hdg and 2. a new altitude control mode that disables target altitude and target pitch.<br/> | |||
<br/> | |||
Then, using Nasal, we can just input our roll and vertical speed directly and not have the AI system try to change them. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=140919#p140919 | |||
|title=<nowiki>Re: AI & MP Dogfighting now working! Bombable ships, aircraf</nowiki> | |||
|author=<nowiki>flug</nowiki> | |||
|date=<nowiki>Sat Oct 22</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|The AI System btw. has it's drawbacks regarding non-aircraft Entities. Also it is hard to pass specific Properties to an AI Model. It will always try to bank and pitch, which needs to be corrected per Model. This all can be solved by using animations and Nasal, but creates a lot overhead. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=206786#p206786 | |||
|title=<nowiki>Re: Tutorials/Missions/Adventures: requests for features</nowiki> | |||
|author=<nowiki>DFaber</nowiki> | |||
|date=<nowiki>Wed Apr 23</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|lug mentioned a while ago that he ran into the same issue with regard to his bombable/combat addon | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207065#p207065 | |||
|title=<nowiki>AI support</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Fri Apr 25</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|If you can provide a list of problematic behavior patterns, I can check the C++ code to see if/how things can be made more configurable there, i.e. with a focus on non-aircraft, but also aircraft that may not fly like airliners | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207065#p207065 | |||
|title=<nowiki>AI support</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Fri Apr 25</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|OK, here's my wishlist part 1:<br/> | |||
<br/> | |||
<br/> | |||
Disable the banking when turning with Ground Vehicles. There are Ground vehicles in FG, but mainly Trains, which I haven't been able to utilize for Cars. Also Cars need to lookup Ground elevation which AI Aircraft don't do too.<br/> | |||
<br/> | |||
FG determines submodel hits on AI/MP Objects by square Boxes around the Aircrafts Origin. These are too wide to be useful with Ground Vehicles and small Aircraft. Some more Size opions would be useful.<br/> | |||
<br/> | |||
When a new Target Heading is selected AI Aircraft don't turn harder than 30 degrees. It would be good to be able to configure this per Aircraft.<br/> | |||
<br/> | |||
I'd like to specify Model specific Properties like Livery, Type in the AI Scenario file. Right now I need to create and set them within the nasal section.<br/> | |||
<br/> | |||
These are some from the top of my head. More to come ... | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207095#p207095 | |||
|title=<nowiki>Re: AI support</nowiki> | |||
|author=<nowiki>DFaber</nowiki> | |||
|date=<nowiki>Fri Apr 25</nowiki> | |||
}} | }} | ||
}} | }} |
Revision as of 14:14, 26 June 2014
|
AI Scenarios vs. Scripting
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.
— Hooray (Thu Aug 29). Re: Suitability of this software to run a swarm simulation.
(powered by Instant-Cquotes) |
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. |
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.
— Hooray (Wed Aug 28). Re: Suitability of this software to run a swarm simulation.
(powered by Instant-Cquotes) |
For starters, I'd suggest to read through these: What_is_Nasal — Hooray (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
Scripted AI in FlightGear
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 <iframe width="420" height="315" src="http://www.youtube.com/embed/LL7bdHrR8uI" frameborder="0" allowfullscreen=""></iframe>
— Hooray (Mon Feb 04). Re: Possibility to run a fully automatized mission ?.
(powered by Instant-Cquotes) |
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.
|
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...):
|
Scripted AI Missiles
xiii is the developer of the F14b's fox2 implementation, the original thread was: Subject: Missiles with seeking capabilities.
<iframe width="420" height="315" src="http://www.youtube.com/embed/UL7jQkl1qe4" frameborder="0" allowfullscreen=""></iframe>
|
AI ATC vs. AI Pilot Interactions
Learning AI
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. — Hooray (Sun Jul 08). Re: Possibility of incorporating "learning" AI?.
(powered by Instant-Cquotes) |
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.
— Hooray (Thu Aug 02). Re: Possibility of incorporating "learning" AI?.
(powered by Instant-Cquotes) |
Custom "pilot" implementations could then be provided for different purposes, i.e. by reimplementing an abstract "pilot" base class and overriding functionality as required.
— Hooray (Thu Aug 02). Re: Possibility of incorporating "learning" AI?.
(powered by Instant-Cquotes) |
Neural Networks
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
— Hooray (Thu Jul 08). Re: AI & MP Dogfighting now working! Bombable ships, aircraft....
(powered by Instant-Cquotes) |
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.
— Hooray (Tue Oct 11). Re: AI & MP Dogfighting now working! Bombable ships, aircraf.
(powered by Instant-Cquotes) |
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.
— Hooray (Fri Jul 09). Re: AI & MP Dogfighting now working! Bombable ships, aircraft....
(powered by Instant-Cquotes) |
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.
— Hooray (Fri Jul 09). Re: AI & MP Dogfighting now working! Bombable ships, aircraft....
(powered by Instant-Cquotes) |
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) |
I like this idea a lot.
— flug (Fri Oct 14). Re: AI & MP Dogfighting now working! Bombable ships, aircraf.
(powered by Instant-Cquotes) |
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)
— flug (Fri Oct 14). Re: AI & MP Dogfighting now working! Bombable ships, aircraf.
(powered by Instant-Cquotes) |
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.
— flug (Fri Oct 14). Re: AI & MP Dogfighting now working! Bombable ships, aircraf.
(powered by Instant-Cquotes) |
Controlling the main Airplane
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
— Hooray (Thu Sep 19). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
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. — Hooray (Thu Sep 19). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
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. |
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:
— Hooray (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
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. — Philosopher (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
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).
— Philosopher (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
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.
— Philosopher (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
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).
— Hooray (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?.
(powered by Instant-Cquotes) |
Fully Automatized Missions
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: <iframe width="420" height="315" src="http://www.youtube.com/embed/cvbtSG9cy20" frameborder="0" allowfullscreen=""></iframe>
— Hooray (Mon Feb 04). Re: Possibility to run a fully automatized mission ?.
(powered by Instant-Cquotes) |
C++ Issues
Regarding "flight plans", I was just reading this on the atlas mailing list. It seems there is some confusion regarding the different types and roles of "flight plans" supported by FG. |
I guess, it might be a good idea to eventually start collecting a list of things that would need to be changed, i.e. like what Thorsten did for prioritizing core-changes to improve his local weather system using the wiki.
— Hooray (Sat Oct 15). Re: AI & MP Dogfighting now working! Bombable ships, aircraf.
(powered by Instant-Cquotes) |
I was looking into the code, and I think this is a "problem" that can be easily solved by disabling some of durk's AI traffic code, basically it is simply "too smart" and making too many assumptions about the type of aircraft/flights it is controlling, at the moment.
— Hooray (Sat Oct 15). Re: AI & MP Dogfighting now working! Bombable ships, aircraf.
(powered by Instant-Cquotes) |
this is helpful. I've never managed to get the target-hdg or target pitch methods to work.
— flug (Sat Oct 22). Re: AI & MP Dogfighting now working! Bombable ships, aircraf.
(powered by Instant-Cquotes) |
The AI System btw. has it's drawbacks regarding non-aircraft Entities. Also it is hard to pass specific Properties to an AI Model. It will always try to bank and pitch, which needs to be corrected per Model. This all can be solved by using animations and Nasal, but creates a lot overhead.
— DFaber (Wed Apr 23). Re: Tutorials/Missions/Adventures: requests for features.
(powered by Instant-Cquotes) |
lug mentioned a while ago that he ran into the same issue with regard to his bombable/combat addon
|