` UNIVERSITA DEGLI STUDI DI TRIESTE

Facolt` di Ingegneria a
Corso di Laurea in Ingegneria dellInformazione

Tesi Di Laurea

Controllo vocale a distanza di un robot in ambiente rumoroso tramite array microfonico

Laureando Fabrizio Roman Matricola 83600025

Relatore Chiar.mo Prof. Ing. Enzo Mumolo Correlatore Prof. Ing. Massimiliano Nolich Anno Accademico 2010/2011

Alla mia famiglia ed ai miei amici, a tutti coloro che mi hanno sostenuto nel grande viaggio che ` la Vita e

Ringraziamenti
Ringrazio il Professor Mumolo per laiuto e per il tempo che mi ` stato dedicato. e I miei pi` sentiti ringraziamenti al Professor Nolich per il supporto datomi u durante lo sviluppo del progetto e della tesi. Un ringraziamento ai miei colleghi per avermi tenuto compagnia per buona parte dello sviluppo del mio progetto mentre lavoravano al loro, in particolare a Paolo per i suoi preziosi consigli. Un grazie sincero a tutti gli amici che mi hanno sostenuto durante la costruzione di questo progetto. Grazie a tutti, davvero.

iii

Indice

Indice Elenco delle gure 1 Introduzione 2 Strumenti utilizzati 2.1 2.2 Introduzione 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lista degli strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . Sistema embedded TS-7250 . . . . . . . . . . . . . . . . . . . . Devantech SRF005 . . . . . . . . . . . . . . . . . . . . . . . . . Driver hardware . . . . . . . . . . . . . . . . . . . . . . . . . . Motori M455M63 . . . . . . . . . . . . . . . . . . . . . . . . . . Batterie da 12 Volt . . . . . . . . . . . . . . . . . . . . . . . . . Modem-router Michelangelo Wave Nas . . . . . . . . . . . . . . Chiavetta USB da 4GB . . . . . . . . . . . . . . . . . . . . . . Array microfonico . . . . . . . . . . . . . . . . . . . . . . . . . Scheda di acquisizione audio EDIROL FA-101 . . . . . . . . . .

iv vii 1 3 3 3 4 4 5 5 5 5 5 5 6 6 6 7 7 8 8 8 9 10

2.2.10 Calcolatore con porta Firewire . . . . . . . . . . . . . . . . . . 2.2.11 Adattatore USB Wireless-G Linksys modello WUSB54GC . . . 2.2.12 Calcolatore con porta seriale . . . . . . . . . . . . . . . . . . . 2.2.13 MacBook Pro 13 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Sviluppo dei driver del robot in Player 3.1 3.2 3.3 3.4 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scelte preliminari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I driver in Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I driver SRF005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iv

v 3.5 I driver motori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 3.5.2 3.6 3.7 Il modulo real-time . . . . . . . . . . . . . . . . . . . . . . . . . Limplementazione dellinterfaccia position2d . . . . . . . . . . 11 11 12 12 13 15 15 15 15 16 16 17 17 18 18 18 19 21 21 21 22 22 22 22 23 23 23 24 24 24 24 25 26 27

Lo script di congurazione . . . . . . . . . . . . . . . . . . . . . . . . . Il software client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Sviluppo del software di ricezione direttiva 4.1 4.2 4.3 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acquisizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Filtraggio audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.4 4.5 Lettura ussi in ingresso da Jack . . . . . . . . . . . . . . . . . Calcolo dei ritardi . . . . . . . . . . . . . . . . . . . . . . . . . Allineamento e media dei segnali . . . . . . . . . . . . . . . . . Filtraggio a sottrazione spettrale a cascata . . . . . . . . . . . Enfatizzazione del usso in output . . . . . . . . . . . . . . . . Streaming verso il VAD . . . . . . . . . . . . . . . . . . . . . .

Voice Activity Recognition . . . . . . . . . . . . . . . . . . . . . . . . . Calcolo della posizione delloperatore . . . . . . . . . . . . . . . . . . .

5 Sviluppo del software di riconoscimento vocale 5.1 5.2 5.3 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Il principio di funzionamento . . . . . . . . . . . . . . . . . . . . . . . Algoritmo per la costruzione dei coecienti cepstrali . . . . . . . . . . 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.4 5.4.1 5.4.2 5.5 5.5.1 5.5.2 5.5.3 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deformazione tramite nestra di Hamming e trasformata FFT Filtraggio tramite Filter Bank . . . . . . . . . . . . . . . . . . . Applicazione di una scala MEL . . . . . . . . . . . . . . . . . . Conversione nel dominio logaritmico . . . . . . . . . . . . . . . Applicazione della trasformata coseno . . . . . . . . . . . . . . Elaborazione di un le CEP . . . . . . . . . . . . . . . . . . . . Creazione del le template . . . . . . . . . . . . . . . . . . . .

Il processo di training . . . . . . . . . . . . . . . . . . . . . . . . . . .

Il processo di riconoscimento tramite DTW . . . . . . . . . . . . . . . Lalgoritmo di confronto tra parole . . . . . . . . . . . . . . . . Vincoli sullorientazione del percorso . . . . . . . . . . . . . . . Normalizzazione del cammino . . . . . . . . . . . . . . . . . . .

vi 5.5.4 5.6 5.7 Implementazione dellalgoritmo di programmazione dinamica . 28 29 30 31 31 32 34 35 35 35 36 37 38 39 39 39 40 41

I falsi positivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I falsi negativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Risultati sperimentali 6.1 6.2 6.3 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Test sperimentali sul sistema di acquisizione, ltraggio e riconoscimento 31 Prove sperimentali sullaccuratezza del movimento . . . . . . . . . . .

Conclusioni e sviluppi futuri Appendice A NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setup e congurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . Accesso in fase di bootup tramite Ethernet . . . . . . . . . . . . . . . Cross-compilazione dei driver . . . . . . . . . . . . . . . . . . . . . . . . . . Congurazione dellavvio automatico del software allaccensione del robot . Appendice B Real-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compilazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avvio del robot e del software . . . . . . . . . . . . . . . . . . . . . . . Bibliograa

Elenco delle gure

2.1 2.2 3.1 3.2 3.3 4.1 4.2 4.3 5.1 5.2 5.3 5.4 6.1 6.2

Sistema embedded TS-7250 . . . . . . . . . . . . . . . . . . . . . . . . . . Array microfonico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Il robot utilizzato in questo progetto . . . . . . . . . . . . . . . . . . . . . Sensore ad ultrasuoni SRF005 . . . . . . . . . . . . . . . . . . . . . . . . . Motore M455M63 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 6 9 10 11 18 19 20 23 25 27 29 32 33

Schema di funzionamento del controller . . . . . . . . . . . . . . . . . . . Waveforms e spettri dei segnali in input, dopo il beamforming e in output Angoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scala MEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Esempio di funzione di deformazione temporale . . . . . . . . . . . . . . . Vincoli sullorientazione delle funzioni di deformazione . . . . . . . . . . . Il DTW procede spostando la nestra base sullo spazio bidimensionale . . Tassi percentuali di riconoscimento dei comandi impartiti . . . . . . . . . Traiettorie seguite dal robot durante le prove sperimentali . . . . . . . . .

vii

Capitolo 1

Introduzione
Il riconoscimento automatico di comandi vocali consente linterazione naturale fra esseri umani e macchine intelligenti. La relativa tecnologia ` stata sviluppata nelle e ultime decine di anni in settori quali la dettatura automatica di documenti e sistemi interattivi di risposta vocale al punto che ` normale incontrare sistemi automatizzati e per gestire almeno la parte iniziale dellinterazione con lutente in sistemi di supporto tecnico, servizi di biglietteria e molto altro. Tuttavia, le prestazioni del riconoscimento automatico sono ancora limitate ad ambienti controllati e degradano drasticamente non appena il microfono viene allontanato dalla bocca di chi parla. Ci` ` dovuto o e ad unampia variet` di eetti come il rumore di fondo, la sovrapposizione della voce a di altri parlatori, leco e il riverbero dellambiente. La ricerca volta alla soluzione di questi problemi ` attiva da pi` di tre decenni, a partire dal lavoro pionieristico risalente e u alla ne del 1970 di Steven Boll sulla sottrazione del rumore. Il rumore additivo nasce naturalmente dalle altre sorgenti sonore presenti nellambiente. Inoltre, limpatto del rumore sul riconoscimento vocale dipende anche dal tipo di sorgente sonora, oltre che dalla sua intensit`. Un grande numero di tecniche statistiche ` stato introdotto per a e lanalisi degli eetti del rumore additivo quasi-stazionario. Naturalmente il problema diventa molto pi` dicile quando il rumore ` non stazionario, come lo ` il caso di u e e molti tipi di rumore impulsivo o delle interferenze da musica di sottofondo. Il riverbero ` un fenomeno naturale di quasi tutti gli ambienti acustici interni, ed ` presente in e e molti ambienti esterni con superci che riettono il segnale acustico. La presenza del riverbero distrugge la struttura temporale delle forme donda, cosa che ha un impatto molto negativo sulla precisione del riconoscimento vocale. Negli ultimi anni sono state introdotte delle tecniche basate sulluso di schiere di microfoni che, compensando il tempo di ritardo tra i vari microfoni, riescono a migliorare il segnale acustico acquisito. 1

CAPITOLO 1. INTRODUZIONE

Le migliorie dovute a questa tecnica chiamata Beamforming tuttavia non sono sucienti a garantire una qualit` del sonoro adatta ad un tasso di riconoscimento a ottimale: si ` quindi deciso di aancare tale tecnologia ad unaltra tecnologia, denoe minata ltraggio a sottrazione spettrale, che ben si presta ad un uso di questo genere, mantenendo una complessit` computazionale abbastanza bassa da poter essere utiliza zata per applicazioni in tempo reale, come ad esempio ` lobiettivo di questo elaborato, e cio` la realizzazione di un software real-time che permetta ad un robot di eseguire dei e task semplici ordinati tramite comando vocale.

Capitolo 2

Strumenti utilizzati
2.1 Introduzione

In questo capitolo listeremo e descriveremo la strumentazione utilizzata durante tutte le fasi di sviluppo del progetto documentato in questa tesi. Tutto il materiale elencato in questo capitolo ` stato utilizzato in quanto immediatamente presente in laboratorio e ed utilizzabile.

2.2

Lista degli strumenti utilizzati

Dotazione di bordo del robot: Sistema embedded TS-7250 4 sensori ad ultrasuoni Devantech SRF005 Driver hardware per alimentazione dei motori tramite PWM 2 motori M455M63 2 batterie da 12 Volt Modem-router Michelangelo Wave Nas Chiavetta USB da 4GB Materiale non residente sul robot: Array microfonico Scheda di acquisizione audio EDIROL FA-101 3

CAPITOLO 2. STRUMENTI UTILIZZATI Calcolatore con porta Firewire Adattatore USB Wireless-G Linksys modello WUSB54GC Strumentazione per lo sviluppo software: Calcolatore con porta seriale MacBook Pro

2.2.1

Sistema embedded TS-7250

` E una scheda basata su un chip Cirrus Logic con core ARM9 funzionante ad una frequenza di 200MHz. Presenta connettori di vario genere, tra cui spiccano 2 porte ` USB, un connettore Ethernet, una porta parallela e linee di I/O digitale. E stata equipaggiata con un sistema operativo Linux con estensione real-time.

Figura 2.1: Sistema embedded TS-7250

2.2.2

Devantech SRF005

Sono dei sensori ad ultrasuoni prodotti da Devantech. Presentano una portata massima di 4 metri per una precisione nellordine del centimetro. Sono direttamente collegabili alle porte DIO del TS-7250.

CAPITOLO 2. STRUMENTI UTILIZZATI

2.2.3

Driver hardware

Si tratta di una scheda progettata e costruita in laboratorio da Marco Matessi [2]. Permette il controllo della velocit` dei due motori tramite Pulse Width Modulation, a nonch della loro direzione. Essa ` pilotata tramite le porte DIO. e e

2.2.4

Motori M455M63

Sono i due motori a corrente continua utilizzati per muovere le due ruote motrici del robot. Sono pilotati dal sopracitato driver hardware.

2.2.5

Batterie da 12 Volt

Si tratta di tre batterie ricaricabili (due da 7000mAh e una da 2000mAh) le quali provvedono a fornire lenergia necessaria al funzionamento del robot. Una di esse ` e dedicata allalimentazione esclusiva dei due motori, allo scopo di isolarli elettricamente evitando cos` eventuali problemi derivanti da cadute di tensione durante il loro funzionamento.

2.2.6

Modem-router Michelangelo Wave Nas

Si tratta di un modem-router con funzionalit` di access-point wireless. Montato dia rettamente sul robot, ne rende possibile la comunicazione wi senza la necessit` di aga ` ganciarsi ad una rete wireless esterna. E alimentato da una delle batterie equipaggiate dal robot stesso.

2.2.7

Chiavetta USB da 4GB

` E collegata sicamente ad uno dei due host USB della scheda TS-7250. Formattata in formato FAT32, contiene i software necessari al funzionamento dei sensori e degli attuatori (drivers e moduli real-time). Ne viene eettuato il mounting automatico allaccensione del robot.

2.2.8

Array microfonico

Larray microfonico utilizzato ` composto da 8 microfoni, equamente distanziati di 5 e cm luno dallaltro.

CAPITOLO 2. STRUMENTI UTILIZZATI

Figura 2.2: Array microfonico

2.2.9

Scheda di acquisizione audio EDIROL FA-101

Questa scheda di acquisizione ` un campionatore dotato di 8 ingressi TSR e porta e Firewire. Le frequenze di campionamento possibili per tutti i canali sono 44.1KHz, 48KHz, 88.2KHz e 96KHz.

2.2.10

Calcolatore con porta Firewire

Questo calcolatore ` sicamente connesso tramite Firewire alla scheda di acquisizione e audio. La presenza di una CPU potente ` un requisito essenziale per raggiungere e la capacit` di calcolo necessaria allelaborazione audio real-time e al riconoscimento a ` vocale. E equipaggiato con una distribuzione Linux Studio. Equipaggia una scheda graca CUDATM compliant, per la quale, se necessario, pu` essere sviluppato softo ware ad alto livello di parallelizzazione utile al ne di incrementarne le prestazioni. Caratteristiche tecniche: CPU Intel R CoreTM i7 950 @ 3.07 GHz, TurboBoost @ 3.33GHz GPU NVidia R GeForceTM GTX 580, 1536MB RAM GDDR5 24GB RAM DDR3 Ingresso Firewire

2.2.11

Adattatore USB Wireless-G Linksys modello WUSB54GC

Questa chiavetta USB Wi ` utilizzata per permettere la connessione wireless tra il cale colatore sul quale risiede il software di controllo del robot e laccess-point equipaggiato sullo stesso.

CAPITOLO 2. STRUMENTI UTILIZZATI

2.2.12

Calcolatore con porta seriale

La presenza della porta seriale si ` dimostrata essenziale durante lo sviluppo del e software driver per il robot: per tale motivo questo calcolatore ` stato utilizzato per e gran parte dello sviluppo. Monta il sistema operativo Ubuntu 10.04 Lucid Lynx LTE.

2.2.13

MacBook Pro 13

Ospita il sistema operativo Ubuntu 10.04 Lucid Lynx LTE presente in macchina ` virtuale. E stato utilizzato per buona parte dello sviluppo del progetto, nonch per e la stesura della tesi.

Capitolo 3

Sviluppo dei driver del robot in Player

3.1 Introduzione

Il robot che verr` utilizzato durante il lavoro documentato da questa tesi ` un sema e plice robot a base circolare dotato di 4 ruote, due motrici e due di pivot, necessarie per la stabilit`. Esso ` caratterizzato dalla presenza di pi` sensori ed attuatori. Quea e u sto capitolo si riferisce alla messa in funzionamento, alla riscrittura dei driver e al debugging dei seguenti sensori ed attuatori: sonar SRF005 motori M455M63 Si ` ritenuto necessario standardizzare quanto pi` possibile i driver dei sonar e dei e u motori per favorire il porting di software di controllo pensato per funzionare ad un livello di astrazione maggiore. A tale scopo si ` pensato di renderli compatibili con lo e standard Player 2.1.2, molto diuso nel mondo della programmazione di robot.

3.2

Scelte preliminari

Per quanto riguarda la programmazione dei driver dei sensori SRF005, buona parte del lavoro ` stato svolto nella tesi di Vittor [1] pertanto si ` proceduto alla modica e e di tali driver per rendere possibile la presenza di pi` istanze degli stessi. La scelta u pi` rapida e comoda ` stata quella di creare un le sorgente (e quindi un modulo) u e per ogni sensore, anzich di utilizzarne uno solo per tutti i sensori. Tale scelta ci e 8

CAPITOLO 3. SVILUPPO DEI DRIVER DEL ROBOT IN PLAYER 9 aiuta poi nel caso si volesse operare con uno o pi` sensori disattivati, possibilit` che u a ci sarebbe stata preclusa nel caso in cui fosse stato deciso di utilizzare un modulo singolo per tutto linsieme dei sensori. Per i due motori, invece, si ` dovuto procedere e ad una riscrittura from scratch dei driver. A dierenza dei sensori, qui si ` deciso di e utilizzare un solo modulo per la gestione di entrambi gli attuatori. Non si ` elaborata e la porzione di driver dedicata agli odometri, essendo gli stessi non funzionanti.

Figura 3.1: Il robot utilizzato in questo progetto

3.3

I driver in Player

I driver in Player presentano uninterfaccia avente tre metodi principali: Setup() Shutdown() ProcessMessage(QueuePointer &resp q, player msghdr * hdr, void * data) Setup() viene utilizzato durante linserimento del modulo, mentre Shutdown() viene utilizzato durante la sua rimozione. Il metodo ProcessMessage(...), invece, viene eseguito non appena il driver ` pronto a ricevere messaggi da elaborare in arrivo da e altri driver. Allinterno di Setup() viene invocato il metodo StartThread() il quale generer` un thread che eseguir` la funzione Main(). Analogamente a ci`, il metodo a a o Shutdown() invocher` il metodo StopThread() che provveder` alla chiusura del thread a a stesso. Il metodo ProcessMessage(...) invocher` al suo interno la funzione Publish(...) a

CAPITOLO 3. SVILUPPO DEI DRIVER DEL ROBOT IN PLAYER10 per inviare i messaggi di risposta dopo lelaborazione. Il driver implementer` anche a i metodi Name::Name Init(CongFile* cong, int section) e Name::Name Register(driver name, init function) per registrare il driver nella tabella dei driver di Player e per istruirlo su come generarne unistanza. Il driver si occupa, durante le fasi di startup e shutdown, anche dellinserimento e della rimozione dei moduli real-time secondo la sintassi: Setup() { system("insmod rt_driver_module_name.o"); // inserimento modulo real-time ... } Shutdown() { StopThread(); system("rmmod rt_driver_module_name.o"); // rimozione modulo real-time ... }

Figura 3.2: Sensore ad ultrasuoni SRF005

3.4

I driver SRF005

Si ` provveduto, come specicato precedentemente, a modicare il driver del sene sore ad ultrasuoni SRF005 documentato nella tesi di Vittor [1] per permetterne

CAPITOLO 3. SVILUPPO DEI DRIVER DEL ROBOT IN PLAYER11 lesecuzione di unistanza per ciascun sensore sicamente presente sul robot. Tale driver, che viene gestito tramite linterfaccia sonar, permette di essere interrogato sulla disposizione geometrica di ogni sensore sul robot e di attivare e disattivare a richiesta ogni sensore per migliorare lautonomia dal punto di vista energetico del robot. Questa seconda funzione non ` per` supportata dallhardware utilizzato. Le e o informazioni riguardanti le letture delle distanze vengono elaborate e poi inviate direttamente allapplicazione client dal Main() tramite la funzione Publish(device addr, PLAYER MSGTYPE DATA, PLAYER SONAR DATA RANGES, (unsigned char*) &sonarData, sizeof(player sonar data t), NULL), richiamata in un ciclo innito. Il driver comunica con il proprio modulo real-time tramite delle FIFO unidirezionali aperte con la funzione open(device, O RDONLY).

3.5

I driver motori

Per quanto riguarda il driver dei due motori si ` sviluppato sia il modulo real-time e che la porzione di driver che implementa linterfaccia position2d di Player.

Figura 3.3: Motore M455M63

3.5.1

Il modulo real-time

Il modulo real-time del driver dei motori presenta una struttura standard nella quale si possono facilmente riconoscere le funzioni principali: init module() cleanup module() rt motion control()

CAPITOLO 3. SVILUPPO DEI DRIVER DEL ROBOT IN PLAYER12 Il metodo init module() viene richiamato durante linserimento del modulo motori: tale metodo prevede lavvio del task rt motion control() che possiamo denire come il cuore logico del comando a basso livello dei motori. Il metodo cleanup module() si occupa invece della chiusura dei task attivi per il disinserimento del modulo. Il metodo rt motion control() si occupa di avviare e bloccare i task rt pwm A() e rt pwm B() dopo aver assegnato del valori adeguati alla direzione di rotazione e al duty cycle dei due motori. Le funzioni rt pwm A() e rt pwm B() si occupano di fornire rispettivamente alle porte della scheda connesse al driver sico del motore A e del motore B (sviluppato da Matessi [2]) i segnali PWM e le due direzioni necessarie al movimento. Come il modulo real-time dei sonar, esso comunica con il driver attraverso unapposita FIFO unidirezionale.

3.5.2

Limplementazione dellinterfaccia position2d

Lo scopo di questo driver ` principalmente quello di fornire informazioni sulla geoe metria del robot (tramite la chiamata alla funzione Publish(device addr, resp queue, PLAYER MSGTYPE RESP ACK, PLAYER SONAR REQ GET GEOM, &robot geometry, sizeof(robot geometry),NULL);) e regolare le velocit` dei motori in a base alle richieste ricevute dallapplicazione client.

3.6

Lo script di congurazione

Il robot devessere avviato tramite lutilizzo di un le di congurazione, nel nostro caso chiamato imhotep.cfg, nel quale saranno presenti le denizioni di ciascun driver utilizzato (nel nostro caso 4 driver per i sonar e 1 per i motori). Per avviarlo baster` a digitare il comando ./runimhotep.sh. Un esempio del contenuto di imhotep.cfg ` il e seguente: driver ( name "srf005driver1" plugin "libsrf005driver1" provides ["sonar:0"] fifo "/dev/rtf/0" ) ... driver

CAPITOLO 3. SVILUPPO DEI DRIVER DEL ROBOT IN PLAYER13 ( name "srf005driver4" plugin "libsrf005driver4" provides ["sonar:3"] fifo "/dev/rtf/3" ) driver ( name "motoridriver" plugin "libmotoridriver" provides ["position2d:0"] fifo "/dev/rtf/4" ) mentre lo script runimhotep.sh contiene solamente il seguente codice: #!/bin/sh . ./exportplayer.sh player imhotep.cfg

3.7

Il software client

Per garantire linterfacciamento del robot con il calcolatore al quale sono sicamente connessi i microfoni, ` stato elaborato un software client rispondente alle speciche e di Player che, tramite TCP-IP, riceve le letture dei sonar e provvede allinvio delle direttive al software residente sul robot. A titolo esemplicativo ne riportiamo le porzioni di codice pi` importanti: u int main(int argc, char *argv[]) { ... // connessione al server player del robot alla porta 6665 PlayerClient robot(ROBOT_IP, 6665); // creazione proxy dei sonar SonarProxy sonar1(&robot,0); SonarProxy sonar2(&robot,1); SonarProxy sonar3(&robot,2); SonarProxy sonar4(&robot,3); // creazione proxy position2d per i motori

CAPITOLO 3. SVILUPPO DEI DRIVER DEL ROBOT IN PLAYER14 Position2dProxy motori(&robot,0); ... // creazione pthread per la ricezione dei comandi pthread_create(&get_cmd,NULL, get_commands, NULL); ... while(1) { // legge i dati dei sonar dai proxy ad ogni ciclo robot.Read(); ... // setta il movimento dei motori dopo lelaborazione motori.SetSpeed(speed, turnrate); } ... } ...

Capitolo 4

Sviluppo del software di ricezione direttiva

4.1 Introduzione

In questo capitolo si tratter` il processo di acquisizione, ltraggio e VAD (Voice Actia vity Detection), nonch qualche accenno a ci` che riguarda la localizzazione spaziale e o del parlatore.

4.2

Acquisizione

Il processo di acquisizione di segnali campionati provenienti dai microfoni viene gestito da Jack, un software freeware comunemente utilizzato in ambiente Linux per la gestione dei ussi audio. Lacquisizione avviene ad una frequenza di 96kHz, la massima frequenza supportata dalla scheda EDIROL FA-101. Tale software si occuper` a poi di fornire tali dati (forniti in modalit` interlaced ) ad un software client, nel nostro a caso il ltro audio.

4.3

Filtraggio audio

I segnali raccolti da ciascuno dei microfoni sono, come facilmente ipotizzabile, aetti da un rumore di fondo, dovuto a rumori ambientali, echi e riverberi, che non pu` o essere trascurato. Lobiettivo del software di ltraggio ` dunque quello di aumentare il e valore del SNR (Signal Noise Ratio) del canale in uscita elaborando opportunamente ciascuno degli 8 ussi audio provenienti da Jack, il tutto in real-time. Il software

15

CAPITOLO 4. SVILUPPO DEL SOFTWARE DI RICEZIONE DIRETTIVA

16

elaborato per tale scopo ` chiamato cascademerger. Il principio di funzionamento del e ltro ` il seguente: e Lettura ussi in ingresso da Jack Calcolo dei ritardi Allineamento e media dei segnali Filtraggio a sottrazione spettrale a cascata Enfatizzazione del usso in output Streaming verso il VAD Successivamente al calcolo dei ritardi, esso avvier` anche una funzione per il calcolo a della posizione delloperatore. Si era inizialmente pensato ad una soluzione diversa, la quale prevedeva che il ltraggio a sottrazione spettrale avvenisse prima del beamforming e una volta per ciascun canale. Tuttavia, si ` visto che la complessit` di e a calcolo dovuta al numero di ltri (8, uno per ogni canale) ` quasi il quadruplo della e complessit` del ltro a cascata qui descritto. Inoltre la qualit` del segnale elaboa a rato ` decisamente peggiore rispetto a quella ottenibile con il ltraggio a valle del e beamforming da noi utilizzato. Di conseguenza la scelta ` ricaduta su questo tipo di e ltraggio.

4.3.1

Lettura ussi in ingresso da Jack

Il software si occupa di prelevare il usso audio degli 8 microfoni inviatogli da Jack in modalit` interlaced attraverso un buer circolare e di salvarlo temporaneamente su a un altro buer, il quale, una volta riempito, verr` elaborato con lo scopo di diminuire a lammontare del rumore di fondo.

4.3.2

Calcolo dei ritardi

Questa porzione di codice provvede, attraverso il calcolo della cross-correlazione, a calcolare il tempi di ritardo (valutati in numero di campioni) tra i diversi ingressi dei microfoni. I dati risultanti da tale elaborazione verranno sia utilizzati dal ltro stesso per la corretta sovrapposizione dei canali per migliorarne il ltraggio tramite beamforming, sia da una funzione che da tali ritardi calcola la posizione del parlatore.

CAPITOLO 4. SVILUPPO DEL SOFTWARE DI RICEZIONE DIRETTIVA

17

4.3.3

Allineamento e media dei segnali

I segnali provenienti dai microfoni vengono traslati di una quantit` pari ai ritardi a prima elaborati e successivamente mediati tra loro. Il risultato di tale elaborazione, unitamente al ltraggio a sottrazione spettrale, ` un segnale con un SNR visibilmente e migliorato rispetto a ciascuno dei segnali provenienti dai singoli microfoni.

4.3.4

Filtraggio a sottrazione spettrale a cascata

Lalgoritmo alla base del ltro si occupa di creare un prolo del rumore (addestramento), da utilizzare per le operazioni di ltraggio vero e proprio. Tale addestramento ` e dinamico e ripetuto nel tempo e, nel caso il rumore dovesse cambiare (durante laccensione del robot, ad esempio), esso apporta delle correzioni automatiche atte alla sua eliminazione. Il ltro ` composto di tre componenti essenziali: il controller, le e funzioni di addestramento e le funzioni di ltraggio. Il controller ha il compito di valutare come e quando fare laddestramento e/o il ltraggio: la logica alla base del suo funzionamento ` illustrata in gura 4.1. Le funzioni di addestramento si occupano e di acquisire il rumore ambientale e di calcolarne il logaritmo della potenza spettrale. Le funzioni adibite al ltraggio eseguono dei task che possono essere riassunti nel seguente modo: Acquisire in real-time il usso audio da ltrare Eettuare la scomposizione in frames parzialmente sovrapposti Calcolare la trasformata di Fourier di ciascun frame Applicare un ltro passa alto Applicare la nestra di Hamming Calcolare la potenza spettrale del segnale risultante e calcolarne il logaritmo naturale per ogni campione Comparare tale segnale a quello elaborato durante la fase di addestramento iniziale ed eettuare lo smoothing vero e proprio Antitrasformare Applicare nuovamente la nestra di Hamming Risovrapporre i frames

CAPITOLO 4. SVILUPPO DEL SOFTWARE DI RICEZIONE DIRETTIVA

18

Figura 4.1: Schema di funzionamento del controller Il ltraggio a cascata prevede una sequenza di ltri a sottrazione spettrale applicati luno alluscita dellaltro. Dalle varie sperimentazioni condotte si ` giunti alla cone clusione che il numero ottimale di ltri da usare sia 2. La motivazione ` che un solo e ltro non garantisce la qualit` del segnale necessaria al VAD (e quindi al riconoa scitore vocale) per operare in maniera accettabile, mentre lutilizzo di 3 o pi` ltri u introduce delle attenuazioni e delle distorsioni del segnale troppo elevate e, a tutti gli eetti, forse pi` dannose del rumore stesso. Queste operazioni vengono eseguite u in real-time con un ritardo massimo che, se sommato a quello dovuto alle funzioni adibite al riconoscimento vocale e al robot, risulta inferiore al secondo.

4.3.5

Enfatizzazione del usso in output

Il segnale viene moltiplicato per una costante per riportarlo ad una potenza rapportabile con il segnale ricevuto in input (il ltraggio ne attenua il valore). Tale operazione migliora le prestazioni del VAD.

4.3.6

Streaming verso il VAD

Il usso audio appena elaborato viene inviato on the y tramite FIFO al VAD, per le operazioni di estrazione del parlato e del riconoscimento vocale. Lo stream avviene a 96kHz con campioni oating point a 32 bit.

4.4

Voice Activity Recognition

` E stato sviluppato un software chiamato VAD che si occupa dellestrazione dei comandi vocali. Lanalisi VAD avviene tramite il controllo in tempo reale del usso audio: viene eettuato il crop-out delle parti riconosciute come silenzio mentre i comandi vocali veri e propri vengono estratti, normalizzati ed inviati ad un riconoscitore apposito. Tale riconoscitore vocale si occuper` poi di inviare tramite FIFO il comando a riconosciuto al software che gestisce la logica del robot.

CAPITOLO 4. SVILUPPO DEL SOFTWARE DI RICEZIONE DIRETTIVA

19

Figura 4.2: Waveforms e spettri dei segnali in input, dopo il beamforming e in output

4.5

Calcolo della posizione delloperatore

La funzione adibita allelaborazione della posizione delloperatore si occupa di calcolare, dati i tempi di ritardo, le direzioni di incidenza del suono rispetto ad ogni coppia di microfoni. Da quelle, intersecandone i risultati ottenuti da ciascuna coppia, triangola le coordinate del parlatore con unapprossimazione ragionevole (qualche decina di centimetri). Tutto ci` si traduce nel calcolo dei punti di intersezione tra pi` coppie o u di rette che verranno utilizzati per la localizzazione. I coecienti angolari (m) delle rette passanti per il punto mediano (lintercetta q) di ciascuna coppia di microfoni, sono direttamente ottenibili: infatti, osservando la gura 4.3, ` facile dimostrare che e i coecienti angolari m sono calcolabili tramite la funzione m tg(asin( delay )) maxdelay (4.1)

con delay il ritardo tra i segnali dei due microfoni, e maxdelay il massimo ritardo tra i microfoni. Per esempio, nel caso di due microfoni posti ad una distanza di 5cm luno

CAPITOLO 4. SVILUPPO DEL SOFTWARE DI RICEZIONE DIRETTIVA

20

Figura 4.3: Angoli dallaltro il massimo ritardo `: e maxdelay = 96000 0.05 f dist = 14 s 343 (4.2)

con f la frequenza di campionamento, dist la distanza in metri tra i due microfoni e s la velocit` del suono nellaria in metri al secondo. Si tratter` poi di risolvere la a a seguente equazione per ogni coppia di rette i,j e di fare la media aritmetica tra le coordinate trovate: y = mi x + q i

(4.3)

NB. Non vanno prese in considerazione le coppie di rette con coeciente angolare uguale, poich essendo parallele non presentano punti di intersezione. e ` E bene sapere, per`, che questa funzione di localizzazione presenta dei limiti che o si riettono sulla precisione del calcolo, dovuti principalmente alla frequenza di campionamento che, nonostante sia di 96kHz, ` ancora troppo bassa per ottenere dei e risultati veramente apprezzabili utilizzando dei microfoni tra loro distanti solo 5 cm. Le possibili soluzioni ai limiti citati sono aumentare la frequenza di campionamento (impossibile con lhardware in nostro possesso) o, per quanto possibile, distanziare maggiormente tra loro i microfoni.

y = mj x + q j

Capitolo 5

Sviluppo del software di riconoscimento vocale

5.1 Introduzione

In questo capitolo si esaminer` tutto ci` che riguarda il software di riconoscimento a o vocale, cio` il principio di funzionamento e quindi lalgoritmo che ne ` alla base, e e ` nonch il processo di training e riconoscimento. E stato elaborato un software di e riconoscimento vocale basato sul confronto della potenza spettrale dei segnali, ma poich tale approccio porta a margini di errore nel riconoscimento pi` elevati rispetto e u ad un altro software in nostro possesso si ` deciso di utilizzare questultimo software, e sviluppato dal Professor Enzo Mumolo.

5.2

Il principio di funzionamento

Il software si occupa di trasformare il segnale vocale, gi` ltrato e tagliato, in un a insieme di coecenti numerici chiamati cepstrali. Tali coecienti, nel tempo, si sono dimostrati utili al processo di riconoscimento vocale e riconoscimento del parlatore. In questo elaborato si discuter` solamente del loro utilizzo nellambito del riconoa scimento vocale, tralasciando quasi completamente ci` che riguarda lidenticazione o dellutilizzatore e il controllo delle autorizzazioni, essendo esse oltre lo scopo di questa tesi. Il riconoscimento vero e proprio si basa sul confronto dei coecienti cepstrali della parola da riconoscere con una lista di coecienti precalcolati da parole note tramite un addestramento.

21

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 22

5.3

Algoritmo per la costruzione dei coecienti cepstrali

A partire dal segnale in ingresso, si eettuano operazioni successive che possono essere riassunte come segue: Framing Deformazione tramite nestra di Hamming e trasformata FFT Filtraggio tramite Filter Bank Applicazione di una scala MEL Conversione nel dominio logaritmico Applicazione della trasformata coseno

5.3.1

Framing

Il segnale vocale viene diviso in nestre di lunghezza ssa parzialmente sovrapposte di lunghezza pari ad una potenza di 2 per facilitare le operazioni di trasformazione.

5.3.2

Deformazione tramite nestra di Hamming e trasformata FFT

A ciascuno dei frames prima individuati viene applicata la nestra di Hamming con lo scopo di enfatizzare maggiormente le componenti centrali di ciascun frame. La formula della nestra di Hamming ` la seguente: e w(n) = 0.54 + 0.46 cos 2n N 1 (5.1)

con N lampiezza di tale nestra. Si noti che la nestra di Hamming non ` lunica e tipologia di nestra esistente, ma ne esistono molte altre, quali ad esempio la nestra rettangolare, le nestre di Hann, di Bartlett, di Gauss, di Hanning, aventi propriet` a dierenti. Il risultato di tale operazione viene poi elaborato tramite FFT.

5.3.3

Filtraggio tramite Filter Bank

Nonostante questo sia un passaggio opzionale, esso apporta delle migliorie alla qualit` a complessiva del riconoscimento. Consiste nellapplicare una serie di ltri passa-banda triangolari parzialmente sovrapposti allo spettro calcolato tramite FFT.

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 23

5.3.4

Applicazione di una scala MEL

Luscita del banco di ltri viene deformata secondo una scala non lineare denominata scala MEL. Tale scala ` correlata alla percezione dellampiezza sonora dellorecchio e umano. Inizialmente lineare, assume un andamento logaritmico al superamento della frequenza di 1kHz. La formula non ` univoca, in quanto di natura empirica. Una e possibile formula utilizzabile ` la seguente: e f, mel(f ) = 1127 ln (1 +

0 < f <= 1000

f 700 ),

(5.2)

f > 1000

Figura 5.1: Scala MEL

5.3.5

Conversione nel dominio logaritmico

Lapplicazione del logaritmo si utilizza prevalentemente con lo scopo di separare i suoni vocali di natura gutturale (da scartare) da quelli di natura palatale. La vibrazione dovuta alle corde vocali (di tipo gutturale) non viene utilizzata durante il processo di riconoscimento vocale e, anzi, va eliminata poich risulta nociva per il riconoscitore. e

5.3.6

Applicazione della trasformata coseno

Viene utilizzata al posto della trasformata FFT inversa, in virt` del fatto che la u trasformata FFT iniziale, essendo eettuata su un segnale reale, ` simmetrica. e

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 24

5.4

Il processo di training

Il training consiste nella registrazione ripetuta delle parole che andranno poi riconosciute e nella loro elaborazione, risultante poi in una lista di le contenenti i coecienti cepstrali di ciascuna parola. La lista dei le cepstrali, abbinati a due a due con le ` parole (stringhe) a cui fanno riferimento, prende il nome di template. E consigliabile, per motivi di robustezza allerrore, fare pi` registrazioni per ogni parola. Nel nostro u caso si ` deciso di eettuare pi` registrazioni da pi` zone della stanza, per diminuire e u u il margine di errore durante il riconoscimento.

5.4.1

Elaborazione di un le CEP

Il programma eseguibile adibito allelaborazione dei coecienti cepstrali (o pi` preciu samente, mel-cepstrali) ` chiamato newmelcep. Il comando necessario alla costruzione e di un singolo le .cep, contenente i coecienti cepstrali di una sola parola, ` il seguente: e ./newmelcep parola.raw con parola.raw il le audio in formato raw ricampionato a 8kHz con samples di tipo short a 16 bit. Il le generato in output sar` chiamato parola.cep. a

5.4.2

Creazione del le template

I le .cep calcolati durante il processo di training vanno listati in un le detto template per essere poi correttamente utilizzati durante il riconoscimento vero e proprio. Tale le segue la seguente sintassi: nomefile1.cep parola1 nomefile2.cep parola2 ... dove nomele1.cep e nomele2.cep sono dei nomi di le contenenti coecienti cepstrali a cui sono rispettivamente assegnate le stringhe parola1 e parola2.

5.5

Il processo di riconoscimento tramite DTW

Il riconoscimento di una parola consiste nel calcolo dei coecienti cepstrali della stessa parola ignota e al loro confronto (distanza) con i cepstrali precalcolati per ogni parola durante il training. La distanza pi` piccola tra quelle calcolate indicher` la parola u a che con pi` probabilit` si avvicina a quella ignota, di fatto riconoscendola. u a

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 25

Figura 5.2: Esempio di funzione di deformazione temporale

5.5.1

Lalgoritmo di confronto tra parole

Un comando vocale pu` essere espresso mediante opportuni parametri estratti dal o segnale, ciascuno avente una certa dimensione. I comandi A e B vengono cos` descritti mediante una sequenza di vettori: A = a1 , a2 , ..., ai , ..., aI B = b1 , b2 , ..., bi , ..., bJ dove ciascun vettore ha una dimensione pari a N coecienti per frame (per esempio 12 coecienti). Le lunghezze dei comandi A e B, espressi in numero di frame, sono rispettivamente I e J. Si consideri il problema di eliminare le dierenze temporali tra le parole di questi due comandi: al ne di chiarire la natura delle dierenze temporali, consideriamo una mappatura tra A e B come mostrato in gura 5.2. In questa gura, le dierenze temporali sono rappresentate da una sequenza di punti c=(i, j): F = c(1), c(2), ..., c(k), ..., c(K) dove c(k) = (i(k), j(k)). (5.5) (5.4) (5.3)

Questi punti rappresentano una funzione che realizza una mappatura dallasse temporale della sequenza corrispondente al comando A a quella del comando B. Questa funzione viene chiamata funzione di deformazione temporale Warping Function. Quando non c` dierenza temporale tra queste sequenze, la funzione di deformazione e

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 26 coincide con la diagonale j=i ed ` tanto pi` distante dalla linea diagonale quanto pi` e u u aumentano le dierenze temporali. La misura della dierenza tra due vettori ai e bj , ` data dalla distanza euclidea tra i vettori stessi: e d(i, j) = d(c). (5.6)

La distanza totale tra le due sequenza ` data dalla somma pesata delle singole distanze e accumulata su tutto il percorso F :
K

D(F ) =
k=1

d(c(k))w(k)

(5.7)

dove w(k) ` un coeciente positivo introdotto per migliorare le caratteristiche di E(F). e La misura diventa minima quando la funzione di warping F ` tale da aggiustare in e maniera ottimale le dierenze temporali tra i due comandi vocali. Questo valore di distanza minima pu` essere considerata una distanza tra le sequenze A e B. In o denitiva la distanza tra due sequenze A e B ` denita come: e D(A, B) = minF dove il denominatore
K k=1 K k=1

d(c(k))w(k)
K k=1

w(k)

(5.8)

w(k) compensa leetto della lunghezza K (numero di

punti della funzione di warping F ).

5.5.2

Vincoli sullorientazione del percorso

La variazione dellorientazione della funzione di warping non deve essere troppo ripida o troppo dolce poich altrimenti si introducono deformazioni indesiderate dal punto e di vista della realt` di produzione sica dei comandi da parte di operatori umani. Per a esempio, se la deformazione fosse troppo ripida si genererebbe una corrispondenza non realistica tra un brevissimo intervallo della sequenza corrispondente al comando A e un lungo intervallo della sequenza corrispondente al comando B. Per ovviare a queste possibili situazioni non realistiche viene applicato un vincolo sulla pendenza, realizzato imponendo un limite sulla possibile congurazione di diversi punti consecutivi sulla funzione di deformazione. Due tipi di vincoli comunemente utilizzati sono illustrati in gura 5.3. In generale, tuttavia, se il vincolo sulla pendenza ` troppo e forte, la normalizzazione temporale pu` non funzionare correttamente, mentre se ` o e troppo debole si rischia di compromettere la discriminazione tra i diversi comandi vocali. Il programma realizzato in questa tesi usa il vincolo rappresentato dalla forma simmetrica della g.5.3.

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 27

Figura 5.3: Vincoli sullorientazione delle funzioni di deformazione

5.5.3

Normalizzazione del cammino

Il coeciente di normalizzazione dovrebbe essere accumulato sul cammino:

K

N=
i=1

w(i).

(5.9)

Si pu` tuttavia dimostrare che le forme di vincoli simmetrico e asimmetrico portano o a un calcolo semplicato del coeciente di normalizzazione. forma simmetrica: In questo caso w(k)=(i(k)-i(k-1))+(j(k)-i(k-l)). Il fattore di normalizzazione N diventa N=I+J dove I e J sono le lunghezze delle sequenze A e B. Lalgoritmo ` descritto col seguente pseudocodice: e //condizione iniziale: g(1,1)=2d(1,1). //equazione ricorsiva della programmazione dinamica: g(i,j)=min[g(i,j-1)+d(i,j), g(i-1, j-1)+2d(i,j), g(i-1,j)+d(i,j)] //distanza normalizzata: D(A,B)=g(I,J)/(I+J)

forma asimmetrica: In questo caso w(k)=(i(k)-i(k-l)). Il coecente di normalizzazione N diventa N=I o, equivalentemente, se w(k)=(j(k)-j(k-l)), N=J. Lalgoritmo ` il seguente: e

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 28 //condizione iniziale: g(1,1)=d(1,1). //equazione ricorsiva della programmazione dinamica: g(i,j)=min[g(i,j-1), g(i-1,j-1)+d(i,j), g(i-1,j)+d(i,j)] //distanza normalizzata: D(A,B)=g(I,J)/I

5.5.4

Implementazione dellalgoritmo di programmazione dinamica

Lalgoritmo di base per il calcolo dellalgoritmo DTW ` stato implementato nella e forma simmetrica come rappresentato nel seguente pseudo-codice: aval=0; bval=grande; bfree=falso; for(i=0;i<I;i++){ for(j=0;j<J;j++){ if (((cval+dij)<(aval+2*dij)) AND cfree) if ((cval<=bval) OR (NOT bfree)) { scegli C; bfree=falso; } else { scegli B; bfree=falso; } else { if(((bval+dij)<(aval+2*dij)) AND bfree){ scegli B; bfree=falso; } else { scegli A; bfree=vero;

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 29 } } aval=cval; } dove i nodi A, B e C sono descritti in gura 5.4.

Figura 5.4: Il DTW procede spostando la nestra base sullo spazio bidimensionale Nellimplementazione qui utilizzata, il programma eseguibile adibito al riconoscimento di una parola singola ` chiamato SWR (Simple Word Recognizer ) ed il comando e per utilizzarlo tramite bash ` il seguente: e ./swr template parola.raw con template il le template contenente i riferimenti ai le cepstrali elaborati durante laddestramento e parola.raw il le audio in formato raw ricampionato a 8kHz con samples di tipo short a 16 bit.

5.6

I falsi positivi

Un problema comune nellambito del riconoscimento vocale ` rappresentato dai falsi e positivi: rumori improvvisi o parole non presenti nel vocabolario possono essere interpretati dal riconoscitore come parole valide ed essere erroneamente utilizzate per il comando del robot. Si ` quindi pensato allutilizzo di due diversi stratagemmi per are ginare, quanto possibile, questo tipo di comportamento indesiderato. Un metodo pu` o essere la semplice apposizione di un limite massimo alla distanza calcolata durante il confronto con i coecienti cepstrali, di fatto ignorando le parole la cui distanza supera tale limite. Un altro approccio, utilizzabile anche contemporaneamente al primo,

CAPITOLO 5. SVILUPPO DEL SOFTWARE DI RICONOSCIMENTO VOCALE 30 consiste nel fare un training comprensivo di parole casuali che se riconosciute verranno ignorate, le quali porteranno ad una possibilit` pi` alta di scartare eventuali falsi a u positivi.

5.7

I falsi negativi

In questo progetto non ci si ` preoccupati di ci` che riguarda il problema dei falsi e o negativi, cio` quando un comando legittimo viene riconosciuto come rumore e quindi e ignorato. Il principale motivo di questa scelta ` che ` suciente che loperatore ripeta e e il comando in caso di mancato riconoscimento.

Capitolo 6

Risultati sperimentali
6.1 Introduzione

In questo capitolo verranno presentati i risultati di alcune prove sperimentali sul software di ltraggio e riconoscimento vocale, nonch sullintero sistema, eettuate e con lo scopo di valutare il tasso di riconoscimento dei comandi vocali in un ambiente caratterizzato da rumorosit` variabile e laccuratezza del movimento in presenza di a istruzioni prestabilite.

6.2

Test sperimentali sul sistema di acquisizione, ltraggio e riconoscimento

La valutazione quantitativa del tasso di errore durante il processo di acquisizione, ltraggio e riconoscimento ` stata eettuata per due congurazioni del sistema: e A microfono singolo ravvicinato Con array microfonico a distanza Lo scopo di tale scelta risiede principalmente nella possibilit` di valutare il grado a di degenerazione del tasso di riconoscimento dovuto alla distanza del parlatore dal sistema di acquisizione. Si ` eseguito il riconoscimento per un totale di 200 parole, e suddivise tra le due congurazioni testate. Per le due congurazioni si ` eseguito e un addestramento consistente nel ripetere 8 volte ciascuna delle parole necessarie al comando del robot (avanti, indietro, destra, sinistra e stop). Le fasi di addestramento e di verica sono state eettuate nel laboratorio in cui ` stato sviluppato il progetto, e in presenza di rumore ambientale consistente e variabile: le fonti principali di rumore 31

CAPITOLO 6. RISULTATI SPERIMENTALI

32

Figura 6.1: Tassi percentuali di riconoscimento dei comandi impartiti sono limpianto di climatizzazione (volutamente mantenuto acceso durante le prove) e gli stessi attuatori del robot. I risultati ottenuti dalla sperimentazione sono illustrati in gura 6.1. Il tasso totale di successo durante lutilizzo di un microfono vicino al parlatore si ` attestato sul 78%, mentre quello durante lutilizzo dellarray microfonico a distanza e si ` attestato sul 76%. Il degrado delle prestazioni, quanticato in una diminuzione e del 2% dei successi, si ` quindi rivelato minore di quanto stimato allinizio del proe getto (nellordine del 10-20%). Da notare il fatto che la qualit` del riconoscimento a dipende fortemente dalla qualit` delladdestramento: un addestramento eettuato su a un numero maggiore di campioni per parola pu` certamente portare a tassi derrore o minori.

6.3

Prove sperimentali sullaccuratezza del movimento

La valutazione qualitativa della precisione del movimento del robot ` stata eettuata e sottoponendo il robot ad una sequenza predenita di comandi, andando a valutarne la traiettoria percorsa durante le varie prove. Si ` provveduto alla registrazione della e

CAPITOLO 6. RISULTATI SPERIMENTALI

33

Figura 6.2: Traiettorie seguite dal robot durante le prove sperimentali sequenza su disco e al riaddestramento del sistema con i comandi emessi direttamente dalle casse di uno dei computer. Sono state eettuate quindi 10 prove separate utilizzando la stessa sequenza di comandi vocali preregistrati, con lo scopo di rendere il pi` possibile simile linput dato al sistema durante le varie prove. La sequenza u di comandi utilizzata per il test ` la seguente: avanti, stop, sinistra, avanti, stop, e sinistra, avanti, stop. I risultati delle prove sperimentali sono visibili in gura 6.2: come intuibile, la mancanza di odometri non permette di raggiungere una precisione elevata nel movimento del robot, stimata nellordine di qualche decina di centimetri per la sequenza di comandi da noi testati. Tale precisione ` ulteriormente degradata e dal tipo di motori utilizzati: una scelta migliore dal punto di vista del controllo della traiettoria sarebbe potuta essere quella di utilizzare dei motori passo-passo al posto dei motori in corrente continua di cui disponiamo, essendo i primi molto pi` precisi u dei secondi in mancanza di retroazione. Non ultimo il problema dovuto al ssaggio non ottimale delle ruote allasse dei motori, causa di un gioco indesiderato che porta a dei movimenti a vuoto iniziali dei motori stessi. Questultimo problema, unito alla notevole inerzia dovuta al peso del robot stesso, contribuisce a diminuire la precisione complessiva nel movimento.

Conclusioni e sviluppi futuri

In questa tesi ` stato sviluppato un robot in grado di eseguire comandi impartiti a voe ce in un ambiente rumoroso, con la capacit` di localizzare la posizione dellutente che a d` lordine, seppur con una precisione ridotta a causa delle limitazioni della strumena tazione utilizzata. La logica di funzionamento ` stata resa il pi` possibile esportabile e u a robot con principi di funzionamento anche diversi da quello in nostro possesso. Una sostanziale miglioria ` sicuramente la dotazione di odometri per la misura della veloe cit` di rotazione dei motori, al ne di migliorare la precisione e diminuire lerrore di a posizione durante il movimento del robot. Dai vari test intermedi eettuati ` stato e appurato che il riconoscimento fornisce prestazioni migliori se eettuato ad personam, garantendo risultati pi` che soddisfacenti. In denitiva gli obiettivi deniti nellinu troduzione sono stati raggiunti con ampio successo. A conclusione di questo lavoro abbiamo quindi un sistema di elaborazione audio, riconoscimento vocale e gestione di un robot pronto per ulteriori modiche e miglioramenti. Si ritiene che vi sia la possibilit` in futuro di implementare completamente la logica di gestione direttamente sul a robot tramite unopera di ingegnerizzazione, rendendo di fatto il robot indipendente, oltre che dal punto di vista dellenergia, anche dal punto di vista computazionale. Questa tecnologia ore spunti per diverse applicazioni nei campi pi` disparati: u un possibile sviluppo potrebbe essere in campo sanitario-assistenziale, in cui uno o pi` robot possono essere daiuto ad anziani o disabili. Altri sviluppi possono essere u riguardanti il lavoro in cooperativa tra uomini e robot oppure lavori ad alto rischio in cui i robot eseguono compiti sotto il diretto controllo vocale di un operatore umano. Un altro esempio di sviluppo pu` essere la composizione di un team di robot che, o facendo un lavoro di squadra, assolvono compiti pi` complessi. u

34

Appendice A
NFS
Durante lo sviluppo dei driver del robot si ` fatto largo uso di NFS, per facilitare e e velocizzare enormemente i lavori di stesura e debugging del codice. NFS ` un le e system remoto al quale un calcolatore pu` connettersi per utilizzarlo come disco locale. o Tramite questa tecnologia ` stato possibile scrivere, compilare, eseguire e testare al e volo ogni parte del codice dei driver del robot.

Setup e congurazione
La congurazione del server NFS non richiede molto tempo ed ` attuabile modicando e ` il le /etc/exports ed avviando i servizi portmap e nfs. E importante tener presente che per modicare il le exports bisogna avere i diritti di root. Una via rapida per eseguire tale modica ` eseguire il comando e sudo gedit /etc/exports Sar` a questo punto suciente aggiungere una riga (ed eventualmente commentarne a unaltra, se gi` presente) secondo la sintassi: a /root_directory_path network_number subnet_mask (rw, no_root_squash, insecure_locks) Nel nostro caso si ` usata la seguente congurazione: e /home/robot/Desktop/ROMAN/armroot 192.168.0.0 255.255.255.0 (rw, no_root_squash, insecure_locks) La fase di congurazione di NFS sar` ultimata con i comandi a /etc/rc.d/init.d/portmap start /etc/rc.d/init.d/nfs start 35

APPENDICE A o, se i servizi sono gi` attivi, con il comando a exportfs -a

36

Successivamente bisogna istruire il robot su come caricare il le system appena congurato: occorre dunque modicare il le /etc/fstab presente in memoria aggiungendo quanto segue: <nfs_server_ip_address>:<path_to_nfs_root /> nfs exec,dev,suid 1 1 con nfs server ip address lindirizzo IP del server NFS e path to nfs root la stessa path prima specicata allinterno del le /etc/exports. Una congurazione possibile pu` essere la seguente: o 192.168.0.16:/home/robot/Desktop/ROMAN/armroot/ nfs exec,dev,suid 1 1 Inne occorre togliere o commentare la riga /dev/hda1 / ext2 defaults 1 1

Accesso in fase di bootup tramite Ethernet

Com` intuibile dai le di congurazione appena modicati, il robot si connette al le e system NFS tramite Ethernet. Si ` quindi proceduto, durante le fasi di avvio del robot, e a bloccare il caricamento del le system locale tramite linvio (via porta seriale) del comando di escape CTRL+C a RedBoot. Per caricare NFS baster` digitare i comandi a fis load linuxrtai exec -c "console=ttyAM0,115200 ip=<nfs_client_ip_address> nfsroot=<nfs_server_ip_address>:<path_to_nfs_root />" con nfs client ip address e nfs server ip address rispettivamente lindirizzo IP del client e del server NFS e path to nfs root la path specicata allinterno del le /etc/exports durante la fase di congurazione di NFS. Una congurazione adeguata pu` essere la o seguente: fis load linuxrtai exec -c "console=ttyAM0,115200 ip=192.168.0.50 nfsroot=192.168.0.16:/home/robot/Desktop/ROMAN/armroot/"

APPENDICE A

37

Cross-compilazione dei driver

Per quanto riguarda la compilazione dei driver si ` per prima cosa scelta la crosse platform toolchain, in quanto il codice deve essere compilato per funzionare su piat` taforma ARM. E stato fatto uso di una toolchain fornita dal produttore della scheda TS-7250, la crosstool-linux-gcc-3.3.4-glibc-2.3.2-0.28rc39. Si ` provveduto quindi alla e stesura di un makele di cui ne riportiamo qualche riga a titolo di esempio: ... all: $(ROOTPREFIX)libsrf005driver1.so $(ROOTPREFIX)rt_sonar1.o $(ROOTPREFIX)libsrf005driver2.so $(ROOTPREFIX)rt_sonar2.o $(ROOTPREFIX)libsrf005driver3.so $(ROOTPREFIX)rt_sonar3.o $(ROOTPREFIX)libsrf005driver4.so $(ROOTPREFIX)rt_sonar4.o $(ROOTPREFIX)libmotoridriver.so $(ROOTPREFIX)rt_motori.o ... $(ROOTPREFIX)rt_sonar1.o: rt_sonar1.c $(CC) $(INCLUDE) $(CFLAGS) $(CFLAGSTASKS) -c rt_sonar1.c -o $(ROOTPREFIX)rt_sonar1.o ... %.o: %.cpp $(CC) $(INCLUDE) $(CFLAGS) $(CFLAGSDRIVERS) -c $< ... $(ROOTPREFIX)libsrf005driver1.so: srf005-1.o $(CC) -shared -nostartfiles -o $@ $^ ... Nel nostro caso le variabili utilizzate nel makele assumono i seguenti valori: CC=/home/robot/crosstool/arm-9tdmi-linux-gnu/gcc-3.3.4glibc-2.3.2/bin/arm-9tdmi-linux-gnu-gcc CFLAGS= -O2 -Wall -DMODULE -DLINUX -ffast-math CFLAGSDRIVERS= -fpic -g3 pkg-config --cflags playercore CFLAGSTASKS= -D__KERNEL__ INCLUDE= -I $(PREFIX)usr/local/include/player-2.1 -I$(PREFIX)usr/realtime/include -I$(PREFIX)lib/modules/$(NAME)/build/include NAME= 2.4.26-ts11-rt ROOTPREFIX= /home/robot/Desktop/ROMAN/armroot/root/

APPENDICE A PREFIX= /home/robot/Desktop/ROMAN/armroot/

38

Congurazione dellavvio automatico del software allaccensione del robot

Si ` sviluppato uno script che garantisce lavvio automatico del software allaccensione e del robot. Tale script prevede il mounting del le system presente sulla chiavetta connessa ad una delle porte USB del sistema embedded TS-7250 e il conseguente ` avvio vero e proprio del server di Player. E stato creato il le imhotep nella directory /etc/init.d contenente le seguenti righe di codice: PATH=$PATH:/root echo -n "starting imhotep" insmod usbcore insmod pcipool insmod usb-ohci insmod usb-ohci-ep93xx insmod scsi_mod insmod sd_mod insmod usb-storage sleep 1 mount /dev/scsi/host0/bus0/target0/lun0/part1 /mnt/cf mount -t vfat /mnt/cf export LD_LIBRARY_PATH=/mnt/cf/lib cd /root ./runimhotep.sh Successivamente si ` creato un link simbolico nella directory /etc/rc3.d con il comando e ln -s ../../init.d/imhotep S91imhotep

Ci` garantisce lavvio in fase di boot-up dello script runimhotep.sh presente nella o directory /root come servizio.

Appendice B
Real-time
Di seguito viene riportata la lista dei programmi (eseguibili e script) necessari al pieno funzionamento in real-time. Gli eseguibili necessari sono: Jack cascademerger VAD oat96khz-to-short8khz newmelcep SWR robot-client mentre gli script sono: vadtest.sh train.sh

Compilazione
Per quanto riguarda la compilazione, dal momento che si ` fatto uso di un makele, e il comando necessario `: e make Per una corretta compilazione sono necessarie le librerie boost-signals e boost-thread, installabili con i comandi:

39

APPENDICE B sudo apt-get install libboost-signals-dev sudo apt-get install libboost-thread-dev

40

Nel caso la compilazione di robot-client non dovesse andare a buon ne, sar` necessario a modicare la variabile dambiente PKG CONFIG PATH con il comando: export PKG_CONFIG_PATH=/path_to_directory/lib/pkgconfig:$PKG_CONFIG_PATH

Avvio del robot e del software

Per prima cosa occorre accendere il robot e laccess-point alloggiatovi sopra, avendo cura di controllare che la chiavetta USB contenente il lesystem da caricare sia gi` a connessa ad una delle due porte USB della scheda TS-7250: il mounting avverr` in a automatico. Successivamente, dopo il login nella rete wi appena creata, occorrer` a avviare in sequenza i seguenti software in bash separate: jackd -R -dfirewire -r96000 -v & ./robot-client ./cascademerger ./VAD Nel caso si volesse invece utilizzare un microfono singolo ravvicinato (quello di default riconosciuto dal sistema operativo), avviare in sequenza questi comandi in bash separate: ./robot-client ./cascademerger -singlemic ./VAD NB. Nel caso si volesse procedere ad un addestramento, sostituire il comando ./VAD con ./VAD -training e seguire le istruzioni a video.

Bibliograa
[1] Damiano Vittor. Sviluppo di un Driver per il Controllo di un Robot Mobile in Ambiente Multipiattaforma. PhD thesis, Universit` degli studi di Trieste, 2008. a [2] Marco Matessi. Realizzazione hardware e software di un robot mobile di servizio. PhD thesis, Universit` degli studi di Trieste, 2010. a [3] Enzo Mumolo. Implementazione di un riconoscitore di parole isolate in ambiente Microvax. Alcatel Face Research Center, 1990. [4] Manuale scheda TS-7250 http://www.embeddedarm.com/documentation/ts-7250-manual.pdf [5] The Audacity Team. Audacity source code http://audacity.sourceforge.net/download/source [6] Wikipedia. Discrete cosine transform - Wikipedia, the free encyclopedia. http://en.wikipedia.org/w/index.php?title=Discrete_cosine_transform [7] Wikipedia. Cepstrum - Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Cepstrum [8] Wikipedia. Mel Scale - Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Mel_scale [9] Wikipedia. Dynamic time warping - Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Dynamic_time_warping

41