Board index FlightGear Development AI Traffic

How advanced is FlightGear's AI?

Intelligent, computer controlled vehicles that drive/fly over the planet!

How advanced is FlightGear's AI?

Postby chriscalef » Wed Jun 25, 2014 8:39 pm

Hi, I'm pretty new to FlightGear and have never messed with AI traffic or done very much with bombable, but I was just wondering if someone could give me a quick overview of the level of AI in the program. I understand there are scripts to simulate regular aircraft traffic, but does this logic actually "fly" the plane in such a manner as to handle unforeseen circumstances? I don't know if flightgear even has the potential for things like big gusts of wind on takeoff or landing, or sudden storms, or random mechanical failures, but is there AI that would be smart enough to compensate for these events?

With bombable, are there AI behaviors capable of putting up a decent dogfight?

Sorry if this is a RTFM question, just trying to wrap my head around the current state of the project in this regard.
chriscalef
 
Posts: 279
Joined: Wed Feb 20, 2013 10:28 pm

Re: How advanced is FlightGear's AI?

Postby Hooray » Wed Jun 25, 2014 8:45 pm

1) no, the built-in AI is extremely simple, and there's no FDM used, and aircraft systems (AP etc) are also not simulated used, the hard-coded AI is agnostic to weather/turbulence
2) bombable is bit more advanced, but works around these limitations in scripting space through scripted FDMs and pilots - it would be possible to create a script "bot" (pilot) that actually flies the thing, and that deals with failures.
3) weather/gusts and wind shear should be possible to simulate through "advanced weather" (also scripted)
4) failure management is meanwhile also scripted through galvedro's work: http://wiki.flightgear.org/A_Failure_Ma ... FlightGear
5) bombable is pretty sophisticated, and could also be extended with NN for better AI

I suggest to check out these postings/threads (covering AI, scripting and Nasal, including bombable):
Subject: AI-Scenarios
Subject: Suitability of this software to run a swarm simulation
Subject: How would I go about controlling an airplane with nasal?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How advanced is FlightGear's AI?

Postby chriscalef » Wed Jun 25, 2014 8:51 pm

Ah, thanks Hooray!
chriscalef
 
Posts: 279
Joined: Wed Feb 20, 2013 10:28 pm

Re: How advanced is FlightGear's AI?

Postby Hooray » Thu Jun 26, 2014 10:52 am

I've started consolidating all related forum discussions here: http://wiki.flightgear.org/Status_of_AI_in_FlightGear
This should be a more friendly than expecting people to read through a ton of postings, it's roughly categorized already.
Feedback/involvement/contributions are obviously appreciated :D


EDIT: The whole "FGCanvas" effort thing is actually about something different, but it entails moving FDM, AP, RM etc into an "AircraftManager" class, which would be the main step required to allow AI aircraft to be also driven by FDM, AP and route manager (and possibly even an aircraft-specific Nasal instance):

Subject: FGCanvas Experiments & Updates
Hooray wrote:
Hooray wrote in Sun Jul 06, 2014 7:55 pm:These are currently hard-coded as separate SGSubsystem instances in fg_init.cxx - even though this is conceptually a headache, simply because these should be all handled by a single SGSubsystemGroup and wrapped there.
If we were to pursure this, this would also mean that the whole shebang could also be reused for AI traffic much more easily, which is another thing that Durk & Zakalawe have been discuussing and working towards


I went ahead to see how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably.
Image

Obviously, all aircraft related subsystems are now in their own group, and no longer show up in the main performance monitor - but performance sampling works at the subsystem-level, so can be fixed - either through a separate dialog just for aircraft related subsystems, or simply by providing a combo/dropdown menu until we have some kind of canvas treeview :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to AI Traffic

Who is online

Users browsing this forum: No registered users and 5 guests