Stand Alone ATC Control Development

From FlightGear wiki
Revision as of 10:26, 22 September 2010 by Zakharov (talk | contribs)
Jump to navigation Jump to search

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 client for FlightGear Multiplayer Network.

Minimum set of required features

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

Other features and ideas

Beginning of an idea from zakharov

A project has been started some years ago, named AutoATC. Indeed it is in a really alpha 0.0.0.1 version :-D.

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.


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.

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)


Related content

Open source

Freeware

Proprietary