Stand Alone ATC Control Development: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 21: Line 21:


=Customizing [[Atlas]] for use as an ATC client =
=Customizing [[Atlas]] for use as an ATC client =
In the scope of the ATC discussion, we have also talked about extending [[Atlas]] to use it as the foundation for a standalone ATC client, concentrating on a maximum degree of code reuse.
In the scope of the ongoing ATC discussion, we have also talked about extending [[Atlas]] to use it as the foundation for a standalone ATC client, concentrating on a maximum degree of code reuse. This is a fairly old idea, which has already been suggested 5 years ago: [].


It seems, that most of the existing atlas features could be used for ATC purposes, too. While only very few new features would be needed that would require changes to the C++ source code. This would make it possible to generalize the atlas code some more, so that using Atlas for ATC purposes would merely be a different "mode".
It seems, that most of the existing atlas features could be used for ATC purposes, too. While only very few new features would be needed that would require changes to the C++ source code. This would make it possible to generalize the atlas code some more, so that using Atlas for ATC purposes would merely be a different "mode".
Line 36: Line 36:
* how about reusing data that is already sent to FlightGear (that would require a running FlightGear instance)
* how about reusing data that is already sent to FlightGear (that would require a running FlightGear instance)


== Atlas features not required for ATC ==
* the terrain view should be probably be made optional?
== Atlas features that should eventually become more configurable ==
* symbols used for navaids, airports and runways?
== Roadmap ==
== Roadmap ==
=== Milestone 1 ===
=== Milestone 1 ===

Revision as of 11:19, 22 September 2010

Last updated: Sept. 2010

Status: Discussion


This wiki is created upon the fired up debate and forum talks to create a centralized idea-bank, so the development proposals/goals can clearly be identified. All users are welcomed to contribute to this entry with their real or virtual world experience and simulator environment requirements for a stand alone ATC GUI client for FlightGear Multiplayer Network (TRACON and ARTCC).

Minimum set of required features

  • multiplayer support
  • display a radar-like screen
  • display data tags (altitude, callsign, course, sqwk code etc)

Features provided by the 'ATC aircraft'

Other features and ideas

Standard features commonly provided by VATSIM and IVAO clients

End user feature requests

Customizing Atlas for use as an ATC client

In the scope of the ongoing ATC discussion, we have also talked about extending Atlas to use it as the foundation for a standalone ATC client, concentrating on a maximum degree of code reuse. This is a fairly old idea, which has already been suggested 5 years ago: [].

It seems, that most of the existing atlas features could be used for ATC purposes, too. While only very few new features would be needed that would require changes to the C++ source code. This would make it possible to generalize the atlas code some more, so that using Atlas for ATC purposes would merely be a different "mode".

For the time being, the most important new feature for atlas would be multiplayer support. Most of the other changes would be about making atlas features either more configurable (i.e. moving hard coded defaults out of the C++ source code into configuration files, plain text or XML based), or about provididing an option to completely disable other features.

Required enhancements

  • multiplayer support
  • possibility to customize appearance for typical ATC use

Open questions

  • should atlas connect to fgms as a server (relay?) or a client (observer), or should it just poll fgms for updates?
  • how about reusing data that is already sent to FlightGear (that would require a running FlightGear instance)

Atlas features not required for ATC

  • the terrain view should be probably be made optional?

Atlas features that should eventually become more configurable

  • symbols used for navaids, airports and runways?

Roadmap

Milestone 1

  • radar-like appearance

Milestone 2

  • multiplayer support (processing XDR messages from fgms)

Milestone 3

  • FGCom integration

Standalone (non GUI) automated ATC

Beginning of an idea Auto-ATC

A project has been started some years ago, named AutoATC. Indeed it is in a really alpha 0.0.0.1 version, not usable at all.

Here are the great lines: the idea was/is to create an lightweight application which fakes its position on Multiplayer Network. This would allow the application to receive/send messages to others connected players, as well knowing their position/bearing/speed/xpdr.

The automated ATC would manage all airports in its area, should have defaults configuration for quite all airports, and can be configured for some specifics airports using XML.

The imagined protocol is this one:

  1. the player send a specific formated message over the multiplayer network (nasal or xml should format the message): it contains multiplayer's callsign and her/his intentions.
  2. the automated ATC grab the message, create an internal instance for this player and gives her/him a transponder code to use
  3. both communicate in a formatted protocol.

The appli was initially written in Perl. Each instance of a multiplayer was a hash table entry (using callsign/transponder couple for authentification), each runway of all managed airports should be hash instances containing the sorted list of users queriing on it. AutoATC could determine a way to enter the final approach of a runway, take care of other players queriing approach or departure, asking them for enter in a waiting-circuit, manage emergencies, etc.

In the case of multiplayer do not follow instructions for any reason for, say, 10 consecutives times, or just asks to leave the system, her/his instance and all her/his queries are wiped.

Why the project has stopped? Because I was unable to send a correctly formatted UDP packet: the position message is different from C++... this was until I discover swig (which is used on FGMap). Swig can be the solution to allow a revival of autoATC, which is next on my TODO list.


Related

Wiki

Talks

Software:Open source

(list taken from atlas/fgms sourceforge trackers)

Software:Freeware

Software:Proprietary