Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Jeroen Hoppenbrouwers]

Before somebody rushes off and starts implementing procedures and vocabulary
from any one book: take into account that each country (USA is a country in
this respect) has its own specific ATC things. The generic idea is the same
but the implementations are considerably different. If you want to make a
single program that does all ATC world-wide, you are in for a hell of a job.

This is why I chose the ATC-robot's approach, with no generics at all. Just
plain scripts that are triggered by the situation and then follow real-world
procedures. More work, but far more realistic.

I am open to suggestions for improvements to the program. As it is now, it
plays VATSIM server, so you need any SquawkBox to connect to it.


Jeroen

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[SGMINFO]

Ampere K. Hardraade wrote:

 > Introduction to Air Traffic Control

http://cherokee.stanford.edu/~bayen/msande212.html

Might be of some interest?

Also see...for a UK perspective with ATC

http://www.compulink.co.uk/~smctighe/EGSS/EGSS_files.html

-|steve|-


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Ampere K. Hardraade]

While I was in my university's library this morning, I saw a book with a title 
along the line of "Introduction to Air Traffic Control".  The book seems to 
go into great details regarding air traffic mangement.  I was doing some 
other research at the time, so I didn't copy down the book's title or its 
ISBN number.

I also saw a book on FMC, as well as Flight Controls.  The latter contains 
many block diagrams, mostly on the 777.

The point is, check your local library first before you go bug the real 
controllers.  It will be better if you can come up with specific questions 
from the book instead of asking the controllers generic questions; it is 
going to save time for both you and the real controllers.

Ampere

On September 25, 2004 03:53 pm, Boris Koenig wrote:
> regarding the experts that would be required: this shouldn't be SUCH
> a problem, as they can probably be easily found in various
> aviation newsgroups/forums, also IVAO/VATSIM themselves provide
> forums, where you can often times find real controllers.
>
> And then there's a lot of freely available documentation
> available...

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Steven Beeckman]

Hi,


I don't know if it's of any use to you guys (and girls), but I've come
across Ivy on the net
(). From this site:



What is Ivy?
Ivy is the software bus that will creep over your network!

Ivy is a simple protocol and a set of open-source (LGPL) libraries and
programs that allows applications to broadcast information through text
messages, with a subscription mechanism based on regular expressions.
Ivy libraries are available in C, C++, Java and Perl, on Windows and
Unix boxes and on Macs. Several Ivy utilities and hardware drivers are
available too.

Ivy is currently used in research projects in the air traffic control
and human-computer interaction research communities as well as in
commercial products. It is also taught to CS students. 



I've not looked deeply in this protocol yet as school is starting out,
but I probably will do it when the first busy weeks have passed ;-).

Greets,

Steven
http://www.student.kuleuven.ac.be/~m0329759/AUAV

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Boris Koenig]

John Wojnaroski wrote:
ATM VATSIM is running an event in SoCal with 24 controllers and 88 
flights as of 08:15Z
to be honest: I would have expected more people  :-)

I'm all for trying it. 
not yet so sure about that ...
And it will take some time to build up a 
following. 
agreed ...

At a minimum we will need a handful of dedicated volunteers 
who have experience as professional pilots and controllers or a working 
knowledge of ATC rules and procedures to act as experts and mentors for 
the rest of us.
I would say, more people would be necessary in order to make it start:
- AT LEAST the "handful" of people who know ATC stuff
- AT LEAST a "handful" developers who have networking experience
- ABOUT half a "handful" ;-) of people who know network security  stuff
- Minimally a handful of people who come up with an interface for MSFS
Think about it: this is not an easy task, this would finally
mean to COMPETE with the major networks - if you want an
NEW (opensource'd) network to be(come) popular, you need to
offer it for OTHER PLATFORMS, too - you must not restrict it
to ANY particular platform or GAME (flight simulator).
This would be about providing a viable alternative to the closed
source networks.
So, after all - if the ultimate GOAL is still to provide virtual
ATC support for FlightGear, one has to take either the full step
or simply drop the whole idea, simply because of the lack of a
really significant user base for FlightGear, so it's unlikely
that such a specific "ATC for FlightGear-only"-network would appeal
to anybody at all.
And then, the whole things gets pointless, because you could simply
stop wasting your time and continue to think about AI ATC, which
would ultimately be a better option, instead of having a
FlightGear-only network, which may be used by 3 dozens clients ...
And possibly 2-3 controllers.

I'll be at the exit; so as you leave, if you would like to leave your 
name and telephone number  we'll be in touch ;-)
regarding the experts that would be required: this shouldn't be SUCH
a problem, as they can probably be easily found in various
aviation newsgroups/forums, also IVAO/VATSIM themselves provide
forums, where you can often times find real controllers.
And then there's a lot of freely available documentation
available...
I don't even think that developing a draft for a  *protocol*
would require much support by professionals, simply because
it would be mainly technical - network related, not so much
really specific to ATC and aviation.
The data that needs to be provided for a protocol can be
determined by looking at the mentioned networks, the user
interface could probably also be resembled - so to some extent,
their 'closed source' software might even help an opensource
effort.
It's more about common-sense, to really determine what needs
to be done - and then also about implementing an efficient
protocol :-/
I think, mainly developers, testers, and security people would
need to be available, as well as developers that can do cross-platform
development using low-level networking libraries.
Of course, one might indeed look for an opensource library that serves
as an abstraction layer for the whole OS specific part.

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[John Wojnaroski]

Arnt Karlsen wrote:
..what do we have right now?  FG can be rigged to run as 
an "ATC World Server" now, right?
We have xatc as a viable client to that "FG ATC World Server", 
we have FG itself, so we need to come up a protocol to help the 
other people squak FlightGearese, what else did I miss here?

.."FlightGear ATC World Animation Server" => "FATWA Server"? ;-)
 

Probably what FG is missing is a critical mass of players/developers...
ATM VATSIM is running an event in SoCal with 24 controllers and 88 
flights as of 08:15Z

I'm all for trying it. And it will take some time to build up a 
following. At a minimum we will need a handful of dedicated volunteers 
who have experience as professional pilots and controllers or a working 
knowledge of ATC rules and procedures to act as experts and mentors for 
the rest of us.

I'll be at the exit; so as you leave, if you would like to leave your 
name and telephone number  we'll be in touch ;-)

Regards
John W.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[John Wojnaroski]

Boris Koenig wrote:
John Wojnaroski wrote:
Will FlightGear provide a pilot entity, controller entity, or both?

This is what I would PERSONALLY consider reasonable:
1) make FG export the necessary data from its property tree
2) interface FG with the network(s) - so that the flights show
   up on *normal* (already available) VATSIM/IVAO clients
3) incorporate a cross-platform VoIP tool, this would not need
   to be compiled by default, but should rather be optional
=> so far this is step #1
Accomplishing step #1 probably  provides all that FG pilots would 
require. The third part (Voice IP) would obviate the need for ASR/TTS 
while working with "carbon-based units".  I'm guessing but would imagine 
that the protocol would entail some sort of initial handshake to 
establish FG on the network, initialization to establish location/state, 
and a set of data structures/classes laying out the number and order of 
data bytes.

At this point we would already be able to use FlightGear with
(one of) the major network(s)
The rest might be optional, dependent on the level of interest regarding 
controllers (either carbon or silicon based)

4) think about implementing a cross-platform ATC client,
   possibly based on 'xatc'
At this point one would also have the possibility to attract
users of other platforms to the whole ATC thing
And then there's of course still the possibility, to
5) think about ways to add TTS/ARS capabilities
With a functional VoIP, this might only be required for AI controllers...
These would not need to be directly linked to any of the
networks, but it would certainly be interesting to be
able to:
6) mix virtual 'real' controllers and AI controllers.
But, I think it's still quite a task ...


The
needs are driven in large part by the scope of operations the individual
wishes to perform -- from a few circuits around the local airfield, a 
short
flight with the family to visit the grandparents, an IFR cross-county, a
commercial 737 from KLAX to KDEN, a 747 flight from KJFK to EGLL...

As you already mentioned, it would indeed be quite attractive to
have an AI available, that can deal with the 'pilots' as they
wish ... so, no need to really have people available who
really do the controlling part in realtime.
And there are portions of the ATC function that might be more amenable 
to automation -- issuing and validating clearance readbacks, ARTCC 
enroute facilities, ground operations, departure control -- while the 
most complex and intensive task, approach control/ tower,  would be 
performed by  live controllers.

I like the idea of AI controllers in that one can also practice 
"off-line", "off-net" ...

Hence, it would probably be a better idea, to run the TTS/ASR
locally on most FG machines, and simply transmit the actual
ATC instructions to the AI part ?
That was the direction I was going... The ASR converts the audio to text 
on the local machine and transmits text. The local machine can be 
"trained"for the individual(s) and with a little error checking for 
phrases and syntax send out a clean. correct text msg. Again this would 
only be required if the receiving entity was an AI type controller or 
was not VoIP capable, in which case either a text msg is displayed or 
synthized into acoustical speech via TTS.

Regards
John W.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Arnt Karlsen]

On Sat, 25 Sep 2004 10:22:06 +0200, Boris wrote in message 
<[EMAIL PROTECTED]>:

> John Wojnaroski wrote:
> > 
> > Will FlightGear provide a pilot entity, controller entity, or both?
> 
> This is what I would PERSONALLY consider reasonable:
> 
>   1) make FG export the necessary data from its property tree
> 
>   2) interface FG with the network(s) - so that the flights show
>  up on *normal* (already available) VATSIM/IVAO clients
> 
>   3) incorporate a cross-platform VoIP tool, this would not need
> to be compiled by default, but should rather be optional
> 
>   => so far this is step #1
> 
> At this point we would already be able to use FlightGear with
> (one of) the major network(s)
> 
>   4) think about implementing a cross-platform ATC client,
> possibly based on 'xatc'
> 
> At this point one would also have the possibility to attract
> users of other platforms to the whole ATC thing
> 
> 
> And then there's of course still the possibility, to
> 
>   5) think about ways to add TTS/ARS capabilities
> 
> These would not need to be directly linked to any of the
> networks, but it would certainly be interesting to be
> able to:
> 
>   6) mix virtual 'real' controllers and AI controllers.
> 
> But, I think it's still quite a task ...

..what do we have right now?  FG can be rigged to run as 
an "ATC World Server" now, right?
We have xatc as a viable client to that "FG ATC World Server", 
we have FG itself, so we need to come up a protocol to help the 
other people squak FlightGearese, what else did I miss here?

.."FlightGear ATC World Animation Server" => "FATWA Server"? ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Boris Koenig]

John Wojnaroski wrote:
Will FlightGear provide a pilot entity, controller entity, or both?
This is what I would PERSONALLY consider reasonable:
1) make FG export the necessary data from its property tree
2) interface FG with the network(s) - so that the flights show
   up on *normal* (already available) VATSIM/IVAO clients
3) incorporate a cross-platform VoIP tool, this would not need
   to be compiled by default, but should rather be optional
=> so far this is step #1
At this point we would already be able to use FlightGear with
(one of) the major network(s)
4) think about implementing a cross-platform ATC client,
   possibly based on 'xatc'
At this point one would also have the possibility to attract
users of other platforms to the whole ATC thing
And then there's of course still the possibility, to
5) think about ways to add TTS/ARS capabilities
These would not need to be directly linked to any of the
networks, but it would certainly be interesting to be
able to:
6) mix virtual 'real' controllers and AI controllers.
But, I think it's still quite a task ...

The
needs are driven in large part by the scope of operations the individual
wishes to perform -- from a few circuits around the local airfield, a short
flight with the family to visit the grandparents, an IFR cross-county, a
commercial 737 from KLAX to KDEN, a 747 flight from KJFK to EGLL...
As you already mentioned, it would indeed be quite attractive to
have an AI available, that can deal with the 'pilots' as they
wish ... so, no need to really have people available who
really do the controlling part in realtime.

That way we can also determine what's acceptable and what's not.
As soon as these things are clear, we'll see their *real* ;-)
attitude.
By all means, keep the dialogue open...

Sure, this morning I received the following short reply from the
author of squawkbox 3:
8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<
My protocol code is already cross-platform ready.  SquawkBox 3
is a Microsoft Flight Simulator plug-in though so it's really
tied to that. Otherwise there is no particular reason why it
needs to be Windows.
X-Plane runs on Mac, as does MacRadarScope, a Mac ATC client.
The server software runs on Linux.  So the protocol is in no way
particularly tied to Windows.
8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<
This was in response to my question whether his protocol/implementation
would be specific to windows, or how feasible it would be to slowly
migrate the protocol, so that it can be used on non-windows platforms.

As to the three points:
1) the protocol has to be open. Security should not be an issue, if it is
then there is something wrong with the design and/or implementation
this is actually exactly what I replied to the IVAO folks, who
seem to be following that route ...
2) the protocol should be platform neutral (although there might be some
issues with # of bytes for data type and big endian/little endian).
right, so the VATSIM reply seems really rather encouraging
3) probably need both "live voice" and an ASR/TTS capability to handle a mix
of live and AI controllers. 
personally, I think this is mainly about an INTEGRATION issue, not so
much about adapting the current implementation - ultimately 'our AI' ;-)
could probably be simply linked to a running ATC client that connects
to (one of) the two network(s).
That way, the whole approach would be kept modular, and if it should
really happen that this is going to be possibly anytime soon, one
could still decide whether to run the AI directly on the same hosts
as FG - for local purposes, or link the AI part to the ATC network
itself ...
Even though, I have some doubts regarding the speech recognition
part in such a scenario,because the ASR would then have to deal
with many people, whose voice profiles aren't available 
Hence, it would probably be a better idea, to run the TTS/ASR
locally on most FG machines, and simply transmit the actual
ATC instructions to the AI part ?
If we ever get to the point that the AI
controllers can pass the Turing test maybe we can "shoot" the live
controllers ;-) or at least provide a more robust expanded controller
population
it's not happening that soon - so, if there is is a simple chance
to get any of the major networks to support FG, this would already
be quite a success - one can still think about the AI part,
I certainly will play around with the ideas that were mentioned
so far - even if it's just for the fun of it ...

 This almost begs to be a separate project under the FlightGear umbrella
(aka JSBSim). It would not be all that hard to write a network module to
output FG parameters -- there is a plethora of protocols defined in
../src/Networks adding one more won't cost that much.
what I know so far: the VATSIM protocol *seems* to be based on some
simple telnet-like protocol, so one m

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[John Wojnaroski]

- Original Message -
From: "Boris Koenig" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Friday, September 24, 2004 2:06 PM
Subject: Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)


> Another thing:
>
> As I seem to be the only one so far, who's got in touch with them,
> I would not mind continuing the exchange to a point where things
> get specific, but I would appreciate some help concerning the
> things that we should get straight with them - I mean, I have already
> asked quite some stuff, but everybody has probably his/her own
> imaginations regarding a possible collaboration, so what I
> brought up so far is certainly far from complete, e.g.:
>
> -> protocol should be open (?)
> -> cross platform software
> -> integration of VoIp software (?)
> ...
> ...
>
> So, why not collect these things and discuss the needs of
> the FlightGear project ?
>
Will FlightGear provide a pilot entity, controller entity, or both? The
needs are driven in large part by the scope of operations the individual
wishes to perform -- from a few circuits around the local airfield, a short
flight with the family to visit the grandparents, an IFR cross-county, a
commercial 737 from KLAX to KDEN, a 747 flight from KJFK to EGLL...

> That way we can also determine what's acceptable and what's not.
>
> As soon as these things are clear, we'll see their *real* ;-)
> attitude.
>
By all means, keep the dialogue open...

As to the three points:

1) the protocol has to be open. Security should not be an issue, if it is
then there is something wrong with the design and/or implementation

2) the protocol should be platform neutral (although there might be some
issues with # of bytes for data type and big endian/little endian).

3) probably need both "live voice" and an ASR/TTS capability to handle a mix
of live and AI controllers. If we ever get to the point that the AI
controllers can pass the Turing test maybe we can "shoot" the live
controllers ;-) or at least provide a more robust expanded controller
population

 This almost begs to be a separate project under the FlightGear umbrella
(aka JSBSim). It would not be all that hard to write a network module to
output FG parameters -- there is a plethora of protocols defined in
../src/Networks adding one more won't cost that much.

The AI/ATC module is another bigger question, and we need to hear from the
author. it would also be interesting to hear how the virtual ATC community
feels about the idea of mixing AI and live controllers. This would also
complicate the protocol to some degree

Regards
John W.








___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Boris Koenig]

Another thing:
As I seem to be the only one so far, who's got in touch with them,
I would not mind continuing the exchange to a point where things
get specific, but I would appreciate some help concerning the
things that we should get straight with them - I mean, I have already
asked quite some stuff, but everybody has probably his/her own
imaginations regarding a possible collaboration, so what I
brought up so far is certainly far from complete, e.g.:
-> protocol should be open (?)
-> cross platform software
-> integration of VoIp software (?)
...
...
So, why not collect these things and discuss the needs of
the FlightGear project ?
That way we can also determine what's acceptable and what's not.
As soon as these things are clear, we'll see their *real* ;-)
attitude.
---
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d