Board index FlightGear Development AI Traffic

FGTraffic 2020: Road map for a new AI traffic system design

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

FGTraffic 2020: Road map for a new AI traffic system design

Postby durk » Sat Nov 12, 2016 11:13 am

Hi Everybody,

After a long break, much longer than I expected, I'm ready to get back to developing the AI traffic system. Given that the majority of development activities will probably fall under the category of "core development", it's my intention to keep development discussions focused on the mailing list.

See https://sourceforge.net/p/flightgear/mailman/message/35485443/ for my initial post. I just wanted to use this opportunity to state that things are moving again, and use this topic to give occasional updates on my progress.

As you can read in my post to the developers list, I'm inclined to break away from the approach I took for the current AI traffic system. The code has become too clunky too be maintainable. I will try to spend a limited portion of my development time for bug fixing the current code, but please don't expect any major changes any more. The new approach I have in mind should surpass everything we currently have, but it's going to take some time until it's all implemented.

Having said that, it's my explicit intention to make the new system 100% compatible with the current content (traffic database, AI Aircraft, liveries, etc). I also want to state that I am hugely impressed by the amount of good work that has been done to FlightGear's AI traffic in the almost four years that I've been away. This work is one of the major motivations for me to get back to core development.

Finally, although I want to keep the technical side of the discussion focused on the mailing list, as per project policy, I'm open to suggestions for improvement from content developers.

Cheers,
Durk
durk
 
Posts: 354
Joined: Mon Nov 17, 2008 2:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: FGTraffic 2020: Road map for a new AI traffic system des

Postby BecOzIcan » Sat Nov 12, 2016 2:37 pm

Welcome back Durk.

I am looking forward to seeing the AI code.finally getting the TLC it deserves. Also happy to help maybe later down the track, not being a developer myself. Do not hesitate to ask

Cheers
Ian
Current Projects: AI Traffic, Models & Liveries
User avatar
BecOzIcan
 
Posts: 1302
Joined: Tue Oct 04, 2011 11:43 pm
Location: Sydney, NSW, Australia
Version: 2020.4.0
OS: Win10

Re: FGTraffic 2020: Road map for a new AI traffic system des

Postby wlbragg » Sat Nov 12, 2016 6:13 pm

Welcome back Durk.

I am looking forward to seeing the AI code.finally getting the TLC it deserves. Also happy to help maybe later down the track

Same here!

I am also available for testing and help specifically with "general/light aviation" if you need it. One of my favorite parts of FG is seeing the smaller GA airports come to life.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: FGTraffic 2020: Road map for a new AI traffic system des

Postby Hooray » Sun Nov 13, 2016 10:05 am

https://sourceforge.net/p/flightgear/ma ... /35486799/
Durk wrote:I've just added a little module called fgtraffic, which doesn't do anything
except print "Hello World". But, it's an important first step to get some
experience with cmake and helps me to organize my thoughts about how to set
up a modular AI system.


Just briefly, I suggest to check out F-JJTH's original FGAIS code: http://wiki.flightgear.org/FGAIS
That code can already "inject" arbitrary traffic into fgms using the MP protocol, using a tiny subset of the whole protocol.

In addition, if your intention is to maintain compatibility with existing data files, you will sooner or later realize that you will inevitably also need access to certain FG subsystems - IcecodeGL ended up implementing a SimGear based SGApplication framework for his FGRadar client: http://wiki.flightgear.org/FGRadar

This whole thing works by setting up a single SGSubsystemMgr, so that you can directly reuse existing FG Subsystems (think properties, autopilot) without causing additional work.

Ultimately, this approach would mean that even things like tanker.nas or the Bombable addon (both of which are using your AI system) could be running in a standalone fashion if people really wanted to (in fact, SGApplication contains a stripped-down Nasal interpreter, too).

In the light of Mathias' and Stuart's ongoing HLA work, it would make sense to come up with an abstract base class/interface to encapsulate protocol specifics, i.e. something like "MPTransport" so that any new code does not contain hard-coded assumptions about the MP protocol being the only transport mechanism: http://wiki.flightgear.org/High-Level_A ... ent_Status
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: FGTraffic 2020: Road map for a new AI traffic system des

Postby Johan G » Sun Nov 13, 2016 11:11 am

Hooray wrote in Sun Nov 13, 2016 10:05 am:[...] it would make sense to come up with an abstract base class/interface to encapsulate protocol specifics, i.e. something like "MPTransport" so that any new code does not contain hard-coded assumptions about the MP protocol being the only transport mechanism [...]

With the disclaimer that I (more than usual) is a layman when it comes to (at least) the implementation of things like this, I think it indeed would be a good idea to have an abstraction layer allowing more flexibility, at least if it does not come at a performance penalty.

I think that almost anything that makes away with hardcoded assumptions and makes for better flexibility will be a good thing in the end.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: FGTraffic 2020: Road map for a new AI traffic system des

Postby Hooray » Sun Nov 13, 2016 1:04 pm

I think that almost anything that makes away with hardcoded assumptions and makes for better flexibility will be a good thing in the end.


Agreed, that is one of the key points made by a number of contributors over the years, and one also made by Durk and James repeatedly, e.g. referring to the vast room for code reuse (which is currently handled by hard-coded heuristics using custom routines) :

New ATC / AI interactions
durk wrote: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.

Cheers,
Durk


Actually, there is a surprisingly comprehensive amount of feedback and information aggregated in the form of a handful of wiki articles whose creation was inspired by recurring debates on the forum/devel list where people wanted to do certain things with the AI system that simply are/were not possible (at the time).

Now, to be fair, most people may not particularly appreciate the "format" of these articles (these pages largely consisting of quotes gathered from various places), but it is still true that we have tons of pretty high-quality feedback that is merely waiting to be reviewed, filterered and prioritized by someone familiar with the corresponding system/code, its limitations and possible approaches to tackle these challenges.

If in doubt (and given the amount of feedback), my suggestion would be to specifically focus on feedback/statements made by other core developers or those involved in the corresponding AI/MP departments (fgms/MP devs, maintainers and operators), but even then, there is a fairly massive amount of useful feedback available (e.g. look at comments made by Curt, David M or even Durk and Oliver themselves, made over the course of many years).

Many of these discussions took place despite the AI system not having been actively developed/maintained at the time, which is a testimony to its success, i.e. people wanting to use it for all sorts of interesting purposes, despite its maintenance status.

From a maintainer's standpoint, this may admittedly be (pretty) annoying - but it is still true that there is quite a community of potential contributors that could be leveraged if the AI system would be updated (e.g. look at Stuart's work, bugman's FGPythonSys experiments, fgogel etc).

As has been suggested on the devel list, a proper RFC document would probably be a good idea - gathering feedback from different parties/people and weighing that accordingly.

http://wiki.flightgear.org/Decoupling_t ... fic_System
http://wiki.flightgear.org/An_Integrate ... fic_System
http://wiki.flightgear.org/Status_of_AI_in_FlightGear
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: FGTraffic 2020: Road map for a new AI traffic system des

Postby durk » Sun Nov 13, 2016 5:39 pm

Hooray wrote in Sun Nov 13, 2016 10:05 am:https://sourceforge.net/p/flightgear/mailman/message/35486799/

Just briefly, I suggest to check out F-JJTH's original FGAIS code: http://wiki.flightgear.org/FGAIS
That code can already "inject" arbitrary traffic into fgms using the MP protocol, using a tiny subset of the whole protocol.


Thanks for the pointers. It sounds like the FGAIS system is conceptually very similar to what I have in mind. Whether or not I can reuse any of this code needs to be seen, but it's good to know that other people have already started working on this.

Cheers,
Durk
durk
 
Posts: 354
Joined: Mon Nov 17, 2008 2:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: FGTraffic 2020: Road map for a new AI traffic system des

Postby Hooray » Sun Nov 13, 2016 5:46 pm

It's unlikely that you will be able (or want to ...) reuse any of that code "as is" - if you're interested in "code reuse" - the SGApplication/FGRadar pointers I posted are much more likely to be of interest to you, specifically see: https://gitorious.org/fgradar/fgradar?p ... ads/master

Note that int main() really is a one-liner here - which is to say that it could be just as well running via SGThread::run(): https://gitorious.org/fgradar/fgradar?p ... ads/master

The subsystem manager is using the same boilerplate code that you are familiar with from FlightGear: https://gitorious.org/fgradar/fgradar?p ... ads/master

Under the hood, it's merely wrapping SGSubsystemMgr to work for CLI applications: https://gitorious.org/fgradar/fgradar?p ... ads/master
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: FGTraffic 2020: Road map for a new AI traffic system des

Postby wkitty42 » Sun Nov 13, 2016 6:09 pm

FWIW: the main thing i see in the existing AI code is that duplicate call signs need to be eliminated and never let to happen... someone, i forget who, has done this and some additional work in the months (two or three) and i'm pretty sure they posted a merge request in the tracker for that work, too... it was definitely talked about on the dev list and i also commented to them in a topic on these forums about it...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGTraffic 2020: Road map for a new AI traffic system des

Postby Hooray » Sun Nov 13, 2016 6:12 pm

I think Durk has pretty clearly stated his current focus/goals - however, regarding the problem you mentioned, it would seem most natural to simply index identical callsigns, as per property indices: foo[0], foo[1], foo[2] etc
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: FGTraffic 2020: Road map for a new AI traffic system des

Postby wkitty42 » Sun Nov 13, 2016 7:26 pm

i'm sure he has... AFAIK, no one has merged the request because no one understands the code like its creator... getting it in would go a long way to making the use of AI more enjoyable during the development phase of the new stuff...

AFAIK, duplicate call signs can't/don't exist in the real world... at least not when based on airlines and flight numbers like our current AI stuff is... we won't even mention that there is no real need for creating flights that aren't leaving within the next 24 hours... indeed, i'd suggest to not create them and materialize those craft until maybe an hour or two before they are due to fly out...

i and some others watch the AIs all the time... i know that i do regularly play ATC with them when they get stuck and won't move causing others to back up behind them... a swift kick of 15kts a few times and they continue on their way... the worst part is finding their index number in the property tree... i have to resort to using PHI's properties and opening up every AI index so i can use the browser's search function to find the call sign... it is even worse when there are multiples with the same call sign... there have been times that i've booted duplicate call signs with a healthy kick of 150kts just to get them out of the way of other ground traffic... especially when they are duplicate call signs that shouldn't even exist in the first place...

EXAMPLE: just this morning i updated flightgear, fgdata, fgaddon and the scenery to the latest commits in all repos... i started at KATL and the first four craft were all the same call sign and headed to the same destination following the same flight path, one after the other with maybe 1:30 minutes separation since they all took off back-to-back... a few minutes later there was another one with the same call sign as the other four... this one was stuck for some reason and holding up 20+ other AI craft waiting to fly out... this is a common problem that can easily be rectified while the new code is being written...

i'm just saying ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGTraffic 2020: Road map for a new AI traffic system des

Postby Hooray » Sun Nov 13, 2016 7:53 pm

would go a long way to making the use of AI more enjoyable during the development phase of the new stuff...[...]
i and some others watch the AIs all the time... i know that i do regularly play ATC with them when they get stuck and won't move causing others to back up behind them... a swift kick of 15kts a few times and they continue on their way... the worst part is finding their index number in the property tree

That sure sounds like a pretty obvious bug - but as has been stated in the original posting, "troubleshooting" the whole shebang is far from straightforward due to timing dependencies - i.e. traffic schedules, so that certain bugs many only ever show up if you're testing the whole thing long enough, and like you say, you literally need to look behind the scenes by using the property browser to see what is going on under the hood.
That is one of the reasons why the reworked ND code created by Gijs can be configured to show the perspective of any AI/MP target - for debugging purposes, i.e. to check if what another entity is doign is actually consistent with what it is supposed to be doing (the dialog in the upper right hand corner showing the perspective of an actual AI target, i.e different position, heading/routing etc).

http://wiki.flightgear.org/Canvas_ND_Fr ... Properties
Image

It would be straightforward to also show a corresponding PFD or other useful avionics to tell what is going on, possibly even overlapping multiple flight plans in the same dialog/map or showing an ATC perspective.
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: FGTraffic 2020: Road map for a new AI traffic system des

Postby Hooray » Tue Nov 15, 2016 9:29 pm

Referring to the ongoing discussion on the devel list (to which I am not subscribed, just lurking), if you were not a core developer, I would say that it would be a little far-fetched to expect you to become an MP expert anytime soon - if I were interested in this sort of thing, I would much rather review the AIBase code to come up with an interface (abstract base class in C++) to define the common APIs, e.g. set/getAltitude(), set/getLatitude(), set/getLongitude(), set/getOrientation() etc - at that point, you would have a fairly simple interface, which you could then implement (inherit from) by asking the corresponding folks to fill in the implementation specific code (e.g. the fgms/MP folks for the existing MP protocol or Stuart/Mathias for anything involving HLA/RTI or SimKit).

The point being that you simply cannot juggle networking stuff if you have never done this sort of thing, and that the networking folks won't be too interested in learning all the ins and outs of the massive AI code base. Besides, UDP is simple enough, so that you don't even need an actual "connection" necessarily - it's mainly about packet marshalling, i.e. XDR-encoding messages and sending them onto the wire.

Using this sort of approach, you could have a standalone programm/process (or thread) finished within just a single weekend, because you would never do any actual networking programming yourself, but only ever call the child classes provided by other contributors (note that Stuart mentioned specifically being interested in this sort of thing as part of his HLA/RTI effort).

Obviously, YMMV, but if you don't have any experience with/interest in network coding, I would definitely recommend to consider this option, i.e. more bang for the buck.

The corresponding interface could be discussed and refined by all contributors, but would be designed with a focus on the current AI system and its requirements
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 1 guest