Autonomous vehicles – Genesis II

Genesis I: A speech-based platform for intelligent ambience and/or supportive environ-ment applications is presented.

The platform has a distributed architecture, which enables extended connectivity and support for multiple intelligent ambience services. The mobile unit Genesis is an integral part of the distributed platform, named DATA system, enabling interaction between several users and the environment. Furthermore, its sophisticated client/server platform’s architecture incorporates robust speech recognition and text-to-speech synthesis engines for more natural human-machine interaction between users and the mobile unit Genesis. Both engines are multilingual oriented. Although the whole system is developed for the Slovenian language, it can be quickly adapted for other languages, when appropriate lan- guage resources are available. With high speaker independent speech recognition accuracy and low command-to-operation delay, Genesis proves to have good manoeuvrability and it is easy to operate even by a non-experienced operator.

The platform DATA is composed of one main server, several module servers and one or more clients (local or remote). One module server runs on Genesis, while the others are needed as support for HMI-based interfaces on the clients’ side, running ASR and TTS systems. The clients’ software communicates directly only with the main server. The main server also has the role of the central managing unit (MU), managing all module servers according to the specified users’ scenarios. Furthermore, the main server and module servers can serve several clients simultaneously. The main server takes care of establishing connections between all module servers and clients, and enables data exchange. In the proposed system, it manages only one mobile robotic platform, but it supports the flexible integration of additional mobile robotic platforms selected for use in a specific intelligent ambience. The module server on the Genesis platform is responsible for transferring video, audio, control and sensor data after the connection is established. All DATA modules are finite-state machines (FSM) (based on the UniMOD framework) [13] . Therefore, external XML-based FSM descriptions are used for the desired usage scenario of the whole system.

The module servers are organised in a similar way as the main server. They all contain a pool of threads ( PooledThread object). In this case, however, the threads are used to run several ASR or TTS engines that run simultaneously. After each request from the main server, the available thread is simply picked up from the pool and used for running the dedicated task (e.g., speech recognition/speech synthesis, performing a control command, etc.). TTS or ASR module servers reply with the corresponding output (ASR result/synthesized message). When no more threads are available in the pool, the module servers buffer the incoming data and the responsiveness of the whole system can potentially slow down. The protocol used between the main server and all of the module servers is also a proprietary XML-based protocol, meaning that plain text XML packets are used in a request/confirmation way, containing, for example, features for ASR, text for TTS, or mobile robotic unit data. The BaseServer class is used for communication with the main server. The extended class ServerService (extended from BaseServer ) is used for implementing the data transportation mechanism. The interface FrameTransporter defines methods for sending/receiving packets to/from the main server. This interface is used by the XML- Frame class for the construction/transportation of XML packets to/from the module server. This class is extended from the more general Frame class. The ServerService class takes care of establishing a connection with the main server and oversees the creation of a pool of threads. The TTS module server has the role of the RTP data transmitter. The ASR module server, on the other hand, simply receives features from the main server and returns ASR results. All module servers therefore need an RTP package containing the corresponding objects and methods needed for RTP transceiving. Since ASR and TTS modules are written in the native C/C ++ programming language, the JNI (Java native interface) is also implemented in the module servers.