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

Reply via email to