Board index FlightGear Development AI Traffic

"Sophisticated AI aircraft" ... ?

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

Re: "Sophisticated AI aircraft" ... ?

Postby Hooray » Wed Feb 24, 2010 10:33 am

durk wrote:In essence, you want to be able to simulate an AI aircraft to perform aerobatic manouvres.


That's also my understanding, but in addition to that, he also wants the track of an AI aircraft to be based on flight data that was previously recorded in FlightGear, for example by using the generic protocol system or the replay subsystem, both of which may provide said data.

So, if I am not mistaken, Sharrif wants to turn a recorded flight into an AI traffic "flight plan", so that the previously recorded flight can be replayed by AI traffic system, instead of having to manually create a flight plan?

Such a feature sounds pretty interesting because it would allow users to easily contribute AI traffic in the form of recorded flight paths so that any flight could be used for AI traffic purposes eventually.

The problems for using the AI traffic system in its current form for this idea is the fact that AI traffic does not (to my knowledge) currently provide or handle all the data (or at least not at the needed resolution) that would be required for high fidelity playback of recorded flights (think fast maneuvering, dog fighting, formation flying etc).

So it's not just aircraft attitude/orientation that would need to be additionally exposed and handled by AI traffic system.

But, given that this would mean that users could use any FlightGear aircraft for recording AI traffic flights, there would also need to be a way to handle those (aircraft specific) properties that are not normally used by the AI traffic systems (such as for example custom animations).

For instance, imagine a scenario where the user starts a flight using the bo105 and wants to save the flight as an AI traffic flight plan in order to fly in formation with the previously recorded flight.

Thus, the AI traffic system would need the capability to insert any installed aircraft model as virtual traffic and also animate it properly (like the multiplayer system mostly does).

durk wrote:Of these, AccelTo, ClimbTO, and TurnTo are used by the current waypoint based flight plans. I don't seen any principle limitation as to why there couldn't be instructions in a FlightPlan that would feed the PitchTo, RollTo, or YawTo, functions. This would probably require some modification of the xml code that reads the flightplans and that does the waypoint following logic, as well as some modifications of the performance database.


Yes, that sounds like it could work pretty well.

However, just exposing these properties to the flight plan XML format would still not provide a migration path for users between the data from the generic protocol/replay systems and the AI system itself.

In other words, there would still need to take place a conversion to the flight plan format that is internally used by the AI traffic system for the saved data (no matter if the data is coming from the generic protocol system or the replay system).
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: "Sophisticated AI aircraft" ... ?

Postby sharrif » Wed Feb 24, 2010 10:42 am

I agree with that on all, almost : with a dedicated protocol i made, i recorded already flights in format of flightplan, so for me the recording part is no more a problem.

But as you said, flightplan and AI system are not designed at that time to have a waypoint every seconds for example
AND it is based on performance database between waypoints ...

If you want my protocol file to record in (xml) flightplan format, let me know it and i'll share it.
sharrif
 
Posts: 39
Joined: Thu Jan 28, 2010 10:50 am
Location: France

Re: "Sophisticated AI aircraft" ... ?

Postby jano » Wed Feb 24, 2010 11:12 am

hi, did you have a look in Nasal/tanker.nas ?

this nasal script put a tanker on request, without using a scenario or the traffic manager.
you can set it attitude/orientation (and more) at will.
but i don't know whats needed to make it follow the registered data's you've got, i sometimes recorded udp paquets to make formation flightgtest, but that cause the server to send me twice the datas.

jano
jano
 
Posts: 221
Joined: Fri Nov 30, 2007 12:32 am
Location: france
Callsign: jano
Version: git
OS: debian SID

Re: "Sophisticated AI aircraft" ... ?

Postby Hooray » Wed Feb 24, 2010 12:56 pm

with a dedicated protocol i made, i recorded already flights in format of flightplan, so for me the recording part is no more a problem.


Your custom protocol, does it also contain all those fields (properties) that are not currently handled by the AI traffic system (such as the aircraft attitude properties like pitch/bank and yaw angles)?

But as you said, flightplan and AI system are not designed at that time to have a waypoint every seconds for example


That's a matter of efficiency I guess, it boils down to the sampling rate used, but also to the way everything is stored (in XML):

I mean, the flight plans you create with your custom protocol, probably end up pretty sizable, right?
Probably several 100 kbytes?

Such files will obviously take a while to be loaded and processed.

So, then this isn't so much about the AI traffic system - processing XML files that are several 100kbytes in size, will inevitably take a while.

The real issue then is the storage format used for such dumps or lists of waypoints.
And XML in general, but also the property list format in particular, are certainly not ideal for such dumps of data.

However, it would probably be possible to extend the generic protocol so that an option is added to help reduce file size by writing only new/modified properties.

In other words, the generic protocol could optionally only log (write) those properties that were modified since the last write. That should help reduce the file size significantly.

AND it is based on performance database between waypoints ...


To be honest, I think in your case that shouldn't be much of an issue, as all stored waypoints in your flight plans will be based on numbers that were provided by actual FDM calculations previously run inside fgfs.

So, if you do find these interpolations to be an issue (jerky movements?), simply set your sampling rate higher:

Assuming an update rate of 1 hz, there is some amount of time that the AI system will interpolate.

So, even assuming a very fast jet flying at 900 kts (15 miles over ground per minute, i.e. 1.5 miles in 6 seconds or 0.25 miles per second) means, that the AI system will need to interpolate only for this segment of flight.

Maybe just post your custom flightplan protocol, as well as a link to a created flightplan - that should help us get an impression of what's needed to improve things.
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: "Sophisticated AI aircraft" ... ?

Postby sharrif » Wed Feb 24, 2010 1:26 pm

Ok, i'll give you the link for the files as soon as i am on MY pc (so tonight).

Just in advance : the flightplan created doesn't take into account pitch (but only bank and heading which are supported) because i have just been inspirated by a simple flightplan of a liner. But if these variables can be passed in a flightplan, it's only few lines to add to the protocol.


For me the performance database is a problem because : either it interpolates with dummy(= not related to original aircraft fdm) values between real data "too spaced" in time,
either we raise sampling rate to avoid that and we have huge size file for flightplan. So my idea to deactivate performancedata base and for example just lineary interpolate between real data values at 1 or 2 Hz.

Just another question : is a flightplan loaded before "the flight" or is it readed in realtime ? Because if the flightplan is huge and is used to be readed in realtime, maybe we could read it "before" the flight to improve performance ?
sharrif
 
Posts: 39
Joined: Thu Jan 28, 2010 10:50 am
Location: France

Re: "Sophisticated AI aircraft" ... ?

Postby Hooray » Wed Feb 24, 2010 1:35 pm

Sorry, I think I misunderstood your posting, and now I see the distinction between performance database and AI traffic interpolations that you are making:

From my personnal point of view, the problem is to call a performance database for that.


I have not tried what you have done, so may I ask how exactly the AI traffic performance database manifests as a problem when replaying a previously recorded flight as AI traffic ? Is the aircraft slowing obviously using wrong speeds in between sampled waypoints?

In my simple mind of a non-developer, a boolean value set to true (+ more code...) could permit to force the "AI engine" to follow waypoints without care of performance data base, just in interpolating between "very near" values (= flight data recorded every X seconds or at X Hz, criteria to define).


That should actually work and in theory it should actually be less code, because these interpolations would not need to refer to the "performance database".

One of the easiest ways to implement this would probably be to simply use a "raw" performance class, that is directly based on sampled GPS waypoints, instead of certain performance numbers. Then, the AI traffic system could ignore the performance db and merely interpolate.
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: "Sophisticated AI aircraft" ... ?

Postby sharrif » Wed Feb 24, 2010 1:52 pm

Be careful :wink: : in my first post i said it doesn't work (loading of this flightplan), sadly. So at this stage, i can fly to record in an flightplan format thx to my custom protocol. But when i reinject it to "replay" (= create an AI scenario with this flightplan loaded), it doesn't work, i don't know why. We'll discuss later about that when i'll give you the files, maybe together we'll understand why.

I can't say more about performance database because i don't know more :oops: : i've just read in doing research on forum (and maybe your links to old topics :wink: ) that now the AI uses a performance database (contained in a file i believe) beetween waypoints. (i didn't verify if it is just on FG CVS)
Maybe durk will say us more ...


Little precision : i'm using fg 1.9.1 ... :oops:
sharrif
 
Posts: 39
Joined: Thu Jan 28, 2010 10:50 am
Location: France

Re: "Sophisticated AI aircraft" ... ?

Postby Hooray » Wed Feb 24, 2010 2:19 pm

For me the performance database is a problem because : either it interpolates with dummy(= not related to original aircraft fdm) values between real data "too spaced" in time


Okay, I think I see what your problem is - but suitable performance numbers should be possible to derive from the waypoint data (which is 3D:lat/lon + altitude), even without knowing what type of aircraft it is:

The difference in between two timestamps (or waypoints) should actually provide all the numbers to determine valid velocities for groundspeed ,turn rate and vertical speed.

So, a corresponding "raw" mode could derive suitable performance numbers just by looking at the waypoints/timestamps of the data it has.

either we raise sampling rate to avoid that and we have huge size file for flightplan.


This is in part due to the fact that the generic protocol is largely used for networking purposes, it is not really optimized for writing efficient memory dumps.

So on the one hand, all that property list XML stuff is obviously very verbose, and on the other hand, the generic protocol system will write out each sample at the configured rate, regardless of whether the data set has changed or not in the meantime.

Regardless of the AI traffic system being used or not, such data dumps will be a problem to be loaded at runtime (if not done in a separate loader thread).

One simple way of selectively writing only modified properties out, would be to simply ommit unmodified properties in the dump so that a reader would need to refer to the last set that was transmitted/written completely. For instance saying something like "Position is lat/lon, and altitude and airspeed are unchanged".

Another way to achieve even greater size reduction, would be to use an extra attribute for referring to properties in a previous timestamp/waypoint, so that unchanged properties can simply be referenced instead of repeating redundant markup.

This would work like a lookup table, so that whenever an unmodified property is about to be written/transmitted, the output would refer back to a previously used timestamp that contains the valid data, instead of repeating all the markup.

That should also work for network protocols, e.g. something like:

1) lat/lon/alt/airspeed complete data set (climbing to cruise altitude at 250 kts)
2) lat/lon/alt/airspeed changed data set (reaching cruise altitude and maintaining 250 kts)
3) -> refer to data set 2 for altitude and airspeed

From a network programming point of view, the generic protocol would need a way to allow packets to "expire" (i.e. after a configurable amount of say 5-20 seconds), so that they will not be referenced after a couple of seconds of not being used anymore.

This would also help reduce memory requirements for both, client and server sides because the "lookup table" would be purged and refreshed regularly.

But all this is more related to making the generic protocol system more space efficient for working with files, and I am not sure if these extensions fit together with the overall plan for the generic protocol system or if there is currently somone maintaining that component of FlightGear at all.
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: "Sophisticated AI aircraft" ... ?

Postby sharrif » Wed Feb 24, 2010 2:38 pm

2 remarks from me :

- what about just a linear interpolation between real points for your "raw" performance idea ?
- think that for a "high dynamic" flight, data are almost always different between two points ...

For the implementation or reflexion about lookup table, nothing to add :D
sharrif
 
Posts: 39
Joined: Thu Jan 28, 2010 10:50 am
Location: France

Re: "Sophisticated AI aircraft" ... ?

Postby Hooray » Wed Feb 24, 2010 3:06 pm

sharrif wrote:what about just a linear interpolation between real points for your "raw" performance idea ?

Yes, I agree - and that's what I said and meant when I wrote previously:

Hooray wrote:That should actually work and in theory it should actually be less code, because these interpolations would not need to refer to the "performance database".


sharrif wrote:think that for a "high dynamic" flight, data are almost always different between two points ...

That's true, at least for positional and orientational information (aerobatic flight), other relevant properties may however remain unchanged (such as external animations).

However, you are right: Highly dynamic flight is likely to require a relatively high sampling rate and will not benefit as much from just referencing any previously written properties.

Another possibility would be to "delta encode" a bunch of nodes instead of writing them fully out.
For example, instead of having something along the lines of the following for each sample:

Code: Select all
<propertylist>
  <timestamp>
    <lat-deg>...</lat-deg>
   <lon-deg>...</lon-deg>
   <altitude-ft>...</altitude-ft>   
  </timestamp>
</propertylist>


One could instead emit timestamp deltas that just encode the difference to the previously written data set:

Code: Select all
 <timestamp delta="+0.01" delta="-0.03" delta="+300" .../>


That would be much shorter and whenever there is a delta attribute encountered, it could be applied (in given order) to the corresponding properties of the full set.
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: "Sophisticated AI aircraft" ... ?

Postby sharrif » Wed Feb 24, 2010 3:30 pm

Sorry but i don't understand the benefit of delta method :oops:
The goal would be to modify value instead of adding value to increase performance ?
sharrif
 
Posts: 39
Joined: Thu Jan 28, 2010 10:50 am
Location: France

Re: "Sophisticated AI aircraft" ... ?

Postby Hooray » Wed Feb 24, 2010 3:44 pm

sharrif wrote:Sorry but i don't understand the benefit of delta method :oops:
The goal would be to modify value instead of adding value to increase performance ?


Well, the idea is to just apply an offset to a previously used value instead of writing/transmitting the complete value.

Just imagine you are told to record a list of positions (x,y), completely writing down a list of each position would be more verbose than just noting down the offset to the previous position:
Code: Select all
x:100.00, y:200.00
x:100.10, y:200,10
x:100.20, y:200,20
x:100.30, y:200,30
x:100.40, y:200,40


Instead, delta encoding would mean to do something like this:
Code: Select all
x:100.00, y:200.00
x:+0.1, y:+0.1
x:+0.1, y:+0.1
x:+0.1, y:+0.1
x:+0.1, y:+0.1


Which is much shorter (less space or traffic consumed) than writing out full data sets, especially when you have many different variables (properties) and work with the verbose XML syntax used in FG, specifying these delta offsets in the form of attributes, would just be a way not to use more space than necessry.

Our computers (and fg) capacity doesn't permit 2 instances of fdm to run so we have to provide pre-recorded data, but for me pre-recorded data is not a pb.


Actually, that's not really true:

Several people have tried running standard aircraft from FlightGear in jsbsim or yasim standalone mode (external fdm) and it usually didn't account for more than 1-2% of CPU usage per instance, so from a purely computational point of view, you could easily run multiple FDMs, even one (or more!) for AI traffic purposes.

The FDM engines in FlightGear really aren't that much of a problem.

You can try it for yourself by running jsbsim or yasim (standalone, in a shell window), you will probably not be able to saturate your CPU even by starting dozens of processes.
This applies in particular on modern multi-ghz and SMP/multi-core CPUs.

So, even though each FDM will run in its own process space, any modern computer and OS will be able to easily run 100+ FDM processes. And that is at the default rate of 120hz I may add.

When you then take into account that you will probably not need to run the AI traffic FDM at a rate of 120 hz (the FlightGear default), but much more likely at 1-5 hz (at most), you should be able to multiplex at least 20-30 different aircraft onto one dedicated FDM thread (or process).

Thus, the problem lies in the integration part and not the lack of computing power: AI traffic is already the component that accounts for many reported performance bottlenecks and unfortunately the "solution" has often be to disable AI traffic or at least reduce traffic complexity.
Before these issues are resolved, we are unlikely to see real FDMs being supported to simulate AI traffic, even though that would simplify many things in one go (e.g. any aircraft could be used as an AI aircraft and so AI aircraft could also benefit from other systems such as the autopilot or route manager).

Somewhere on the wiki (I think in the multiplayer section?), there is talk about running the AI traffic system as a separate process that works over multiplayer instead of running in the main loop.

This is apparently understood to be the best approach in the long run, as it would also synchronize AI traffic across all multiplayer clients but would also allow to run more computations (like e.g. a dedicated FDM for AI) inside the AI traffic system.
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: "Sophisticated AI aircraft" ... ?

Postby sharrif » Wed Feb 24, 2010 5:16 pm

For those interested, here is the custom protocol to record in a "flightplan format" :
http://www.mediafire.com/?w4mjxzzzydj
Place this file in your data/Protocol/ folder.

Use it with the following option :
--generic=file,out,5,data.out,xmltest2

data.out is the file with results after the flight, 5 is the sample rate (5 Hz)
sharrif
 
Posts: 39
Joined: Thu Jan 28, 2010 10:50 am
Location: France

Re: "Sophisticated AI aircraft" ... ?

Postby BrianVanSpeybroeck » Wed Feb 24, 2010 6:48 pm

deleted
Last edited by BrianVanSpeybroeck on Thu Feb 25, 2010 4:10 am, edited 1 time in total.
Done!
BrianVanSpeybroeck
 
Posts: 496
Joined: Tue Dec 02, 2008 1:36 pm

Re: "Sophisticated AI aircraft" ... ?

Postby Canseco » Wed Feb 24, 2010 11:31 pm

I like the idea of dogfight training, compatible with DogFight Project.
If you need someone to test, pm me, ;)
System specs:
AMD Ahtlon 64 X2 Dual Core 2.2 GHz, ASUS M2N4-SLI,3 GB DDR2 800 MHz
Nvidia GT240 1GB 1440x900, 25-30 fps
Canseco
 
Posts: 194
Joined: Wed Jan 06, 2010 1:53 pm
Callsign: Canseco
Version: Git
OS: GNU/Linux

PreviousNext

Return to AI Traffic

Who is online

Users browsing this forum: No registered users and 1 guest