Board index FlightGear Development AI Traffic

New ATC / AI interactions  Topic is solved

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

Re: New ATC / AI interactions

Postby Hooray » Wed Aug 31, 2011 6:20 pm

durk wrote in Wed Aug 24, 2011 8:11 am:the first few milestones would be something like:

1). Enabling controllers for all stages of flight, and making sure the transistions between them work.


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.

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.

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?

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.

Some time ago we already talked about what it'd take to implement scripted pilots and scripted controllers in Nasal:
viewtopic.php?f=23&t=6807&p=66463#p66463

durk wrote:2). Honour data that is in the user aircraft's flight plan (currently I'm just using defaults).
3). Adding additional stages of flight: (go around, holding patterns, etc).
4). Enable the user to change his or her flight plans dynamically (choose alternate runways for departure / approach), change destination, change from VfR to IfR, etc etc.


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.

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.

I think zakalawe mentioned plans along those lines some time ago, so it'd be good to keep those things in mind:

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?
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: New ATC / AI interactions

Postby durk » Wed Aug 31, 2011 10:11 pm

Hooray wrote in Wed Aug 31, 2011 6:20 pm: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.


I've been thinking about this, and while I do believe that there is some room for nasal, I'm not thrilled about moving core components out of the C++ code base. I adhere to the principle that where generic algorithms can do the job, it should be done in C++, while a nasal script is more useful for handling local local exceptions to the rule. Things that come to mind for the latter are runway assignments, where rules and their complexity may vary considerably from airport to airport. But, code for checking for traffic separation on a groundnet, lining up aircraft for arrival, waypoint handling, etc etc, etc. simply belongs in the C++ code base and not in Nasal space in my opinion.

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. But, I'm currently not really excited about writing anything in Nasal myself.



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.

I think zakalawe mentioned plans along those lines some time ago, so it'd be good to keep those things in mind:

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?



Yep 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
durk
 
Posts: 354
Joined: Mon Nov 17, 2008 2:01 pm
Location: Ghent, Belgium
Callsign: PH-DRK
Version: git
OS: linux

Re: New ATC / AI interactions

Postby legoboyvdlp » Tue Oct 27, 2015 7:53 pm

Tested with 3.7, works perfectly at Schipol.
I'd love it to be expanded!
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: New ATC / AI interactions

Postby pommesschranke » Thu Mar 03, 2016 11:17 am

legoboyvdlp wrote in Tue Oct 27, 2015 7:53 pm:Tested with 3.7, works perfectly at Schipol.


I see a small "ATC communication" dialog with only a "Cancel" button.
the "v" key works like always but nothing happens when I type "2"

what I also tried:
press "-" then 3 then 6 then 2

I see "NavCache: aborting transaction" in the log
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: New ATC / AI interactions

Postby legoboyvdlp » Thu Mar 03, 2016 2:17 pm

So, it must have broken between 3.6RC and San Fransisco in that case?
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Previous

Return to AI Traffic

Who is online

Users browsing this forum: No registered users and 0 guests