C++ and XML...

[Kit Plummer]

Thanks for the feedback David.  More below...

On 18 Jul 2001 07:06:29 -0700, David A. Sinck wrote:
> 
> 
> \_ SMTP quoth Kit Plummer on 7/17/2001 08:30 as having spake thusly:
> \_
> \_ Hello folks.
> \_ 
> \_ Over the past year or so myself and a couple other people have been
> \_ pondering a project.  
> 
> A few points having scanned most of the discussion to date on this:
> 
> 1) Why have a voice recognition system?  You could just wire a button
>    onto the joystick to squeeze when complete.  That saves a
>    microphone from a potentially hostile and possibly noisy
>    environment.
> 
>    Oh yeah...you don't want to confuse the pilot with a switch that
>    isn't the machine gun.  Nevermind.
> 

Definitely, this is a concern.  Wiring in of a second button is an
option.  However, one of the things we are trying to avoid is more
clutter in the cockpit...and automation.  There is a relatively set
dictionary of "in-flight" words or communication between pilot, pilot
and ATC.  So, utilizing a set of commands that is far enough away from
the possibility of being picked up in flight are good.  Also, the speech
system would have to be trained and our local dictionary set is small
enough that we could eliminate any outside noises or comminque easy
enough - a simple filter if you will.

> 2) You mention "providing an in-cockpit expert system".  It's been a
>    while since I studied expert systems, but the dominance was
>    favoring Lisp, Prolog, or similar languages that were more rule
>    based.  
> 

Well, when I say expert system, it isn't really.  We have a finite set
of elements.  However, the number of aircraft supported could grow
infinitely, the data is seperate from the mechanism here.

> 3) See 'festival' and 'mbrola' for linux Text to speech.  They work
>    well and have amusements like a 'plugin' for xchat.  Has voices
>    predefined and all that.
>

I have done some basic testing with various TTS tools.  Obviously, we
need both the TTS engine and the voice-recognition engine.  
 
> 4) If you go consumer goods why not add a velcrod on computer/handheld
>    where the main button was "check"?  You could probably come up with
>    an attactive plastic enclosure, a USB/Serial port for
>    refreshing....   
> 

What we are thinking here is a small box, about the size of a hard drive
which is plugged in between the headset and the radio.  That way we can
seperate local comm and ATC comm.  As I mentioned above filtering out of
ATC comm or even Pilot/Passenger comm is pretty important.  There are
similar mechanisms for using cell phones in the comm loop that work
pretty good.

Once we get past the initial pilot-feedback sessions I am going to buy
an Linux embedding kit and start working towards a H/W prototype.  This
is more where my KSAs come into the project.  I am not as much of a
developer as the other people currently involved in the project.

> David
> 

Again, thanks for the input.

Kit
> 
> 
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>