1
Corso di Laurea Magistrale in Informatica
Umanistica
Un ambiente per la personalizzazione del
comportamento di un robot umanoide da parte di
persone senza esperienza in programmazione
Candidato:
Nicola Leonardi
Relatore:
Fabio Paternò
2
Ai miei genitori, Angelo e Giovanna,
alla compagnia della mia vita Silvia
3
Abstract
Dopo un’introduzione al paradigma End-User Development (EUD) e un breve escursus di carattere storico-narrativo sulle tematiche relative ai robot e il loro utilizzo nei diversi ambiti della società nei decenni passati, l’elaborato proseguirà con l’analisi delle motivazioni scientifiche e sociali che determinano il focus e l’interesse su questo tipo di tecnologie ai giorni d’oggi.
Si passerà all’aspetto dell’esperienza comunicativa uomo-robot esponendo le modalità d’interazione “naturali e multimodali” attuabili con questo tipo di tecnologia.
La parte centrale del lavoro sarà incentrata sull’integrazione del robot umanoide Pepper in un ambiente di personalizzazione di regole EUD di tipo triggers-action utilizzabile da persone senza alcuna
competenza di programmazione.
Tale ambiente consentirà inoltre l’uso integrato delle funzionalità del robot in un più vasto ambiente dell’Internet delle cose (IoT) considerando il robot stesso come un insieme di sensori capaci di generare eventi e un insieme di attuatori di azioni.
Infine verranno analizzati e commentati i risultati di un test di utenti effettuato sottoponendo dei tasks di composizione di regole da eseguire direttamente col robot.
4
Tabella dei Contenuti
Abstract ... 2
1 Introduzione ... 6
1.1 Robot e industry 4.0 ... 7
1.2 La storia dei robot: dai robot industriali a quelli sociali ... 9
1.3 Le quattro aree di applicazione dei robot ... 10
1.4 End User Development: motivazioni e caratteristiche ... 11
1.5 Coblox: una soluzione EUD applicata a un robot industriale... 14
1.6 Node Primitives: una soluzione EUD applicata a un robot sociale ... 15
2 L'esperienza comunicativa coi robot ... 17
2.1 La caratteristica di agentività... 18
2.2 La progettazione di un robot sociale ... 18
3 La comunicazione multimodale ... 20
3.1 Il parlato ... 22
3.2 I gesti ... 22
3.3 Le espressioni facciali ... 23
3.4 Il tracciamento dello sguardo ... 24
3.5 Prossemica e cinesica ... 24
3.6 Aptica ... 25
4 I livelli di astrazione nella programmazione di un robot sociale ... 26
5 Pepper ... 29
5.1 Caratteristiche hardware e software ... 30
5.2 Tools e SDK ... 36
5.3 Choregraphe ... 37
5.3.1 Considerazioni. ... 44
6 La piattaforma di personalizzazione IoT TARE: il Background Tecnologico ... 45
6.1 I Requisiti ... 46
6.1.1 Classificazione dei trigger nel modello del contesto ... 47
6.1.2 Classificazione delle azioni ... 48
7 Descrizione dell’architettura ... 49
7.1 EUD e approccio meta-design ... 49
7.2 Authoring Tool, Adaptation Engine, Context Manager ... 51
7.3 Le tecnologie di comunicazione ... 56
8 L’integrazione di Pepper nella piattaforma TARE ... 58
8.1 NAOqi framework ... 60
8.2 L’applicazione Pepper ... 64
5
8.4 WebSocket e Server-Sent Events a confronto ... 70
8.5 Descrizione degli eventi e delle azioni "human friendly" ... 74
8.6 Modifiche alla piattaforma ... 77
9 Test Utente e analisi dei risultati ... 82
9.1 I partecipanti ... 82
9.2 Descrizione della procedura di test ... 84
9.3 Il test ... 85
9.4 Collezione e tecniche di analisi dei dati ... 88
9.4.1 Analisi dei log ... 88
9.4.2 Report del Post Survey ... 90
9.5 Analisi dei risultati ... 96
9.6 Commenti e note dei partecipanti al test ... 97
10 Conclusioni e possibili sviluppi ... 100
Bibliografia e sitografia ... 101
Lista degli acronimi ... 105
Lista degli allegati ... 106
Tabella delle figure ... 107
Scheda A: tabella degli eventi ... 109
Scheda B: tabella delle azioni ... 112
6
1 Introduzione
Come anticipato nell’abstract due sono i temi centrali che verranno affrontati in questo elaborato di tesi. Il primo riguarda lo studio delle capacità e funzionalità del robot umanoide Pepper (cui sarà dedicata una sezione apposita) e il secondo riguarda l’integrazione di questo robot umanoide in un ambiente di End User Development di tipo trigger-action (anche questa tematica avrà una sezione dedicata). Alla fine vedremo come si sono comportati 17 partecipanti a un test che prevedeva la composizione di alcune regole libere e altre prestabilite e cercheremo di fare un’accurata analisi dei risultati e dei loro commenti, per recuperarne informazioni utili per l’evoluzione dell’intera piattaforma.
L’End User Development (EUD) [46] è un approccio alla progettazione e sviluppo che cerca di mettere l’utente finale, anche se privo di competenze di programmazione, in grado di poter gestire e configurare in maniera autonoma il comportamento del software per meglio adattarsi alle sue specifiche esigenze. È una tipologia di approccio che mira principalmente alla soluzione personale e soggettiva piuttosto che a quella generica e globale.
Si punta alla soluzione dello specifico task d’interesse, piuttosto che partire dalla soluzione complessiva per poi stringere sulla particolare.
Per capire invece le implicazioni e i vantaggi dell’utilizzo di un robot umanoide in un’infrastruttura IoT è necessaria un’introduzione che mira a collocare questa tecnologia nel giusto posto nella nostra società attuale.
Il capitolo 1 sarà introduttivo al backgroud tecnologico che vede implicati progettazione EUD, IoT e robot nella società attuale.
Seguirà una parte (capitoli 2 e 3) dedicata all’interazione Uomo-Robot e alla descrizione della comunicazione multimodale tipica dell’interazione uomo-uomo.
Il capitolo 4 sarà specifico sugli approcci utilizzabili nella programmazione di un robot sociale.
Il robot sociale Pepper sarà tema centrale del capitolo 5, mentre i capitoli 6, 7, 8 si focalizzeranno sulla descrizione della piattaforma di personalizzazione IoT TARE e dell’integrazione di Pepper in questa infrastruttura software.
Il capitolo 9 sarà dedicato alla descrizione del test utente e all’analisi dei risultati ottenuti.
L’ultimo capitolo, il 10, si concentrerà sulle considerazioni finali e sull’individuazione di alcuni spunti di sviluppo futuri.
7
1.1 Robot e industry 4.0
L’Interazione Uomo-Robot (HRI, Human-Robot Interaction) è un’area di ricerca multidisciplinare in costante sviluppo che fonda le sue radici sia su aspetti tecnologici che sociali. Essa gioca un ruolo fondamentale nella definizione e analisi di robot che cooperano con gli esseri umani al fine di ottenere risultati migliori in svariati ambiti di utilizzo.
Una volta chiare le motivazioni che spingono all’utilizzo dei robot, si può passare all’implementazione e sviluppo di tecniche che permettano all’uomo di interagire con essi in modo semplice utilizzando modalità intuitive e più naturali possibili.
La collaborazione tra uomo e robot è un tema di grande attualità tanto da essere uno degli elementi centrali dell’Industria 4.0.
Vedremo più avanti come vi siano diverse tipologie di robot (industriali, esoscheletri, robot umanoidi, ecc.) ma per ora rimaniamo sul generale e vediamo come si colloca la “tecnologia robotica” nella società.
La nuova Industria 4.0 si fonda su nove pilastri fondamentali: simulazione, horizontal and vertical system integration, the industrial internet of things, cybersecurity, il cloud, additive manufacturing, realtà aumentata, big data and analytics, robot autonomi.
8
L’ambito della simulazione è quello di impiegare dati ad hoc e scenari prestabiliti per simulare situazioni e comportamenti dinamici al fine previsionale e di training del personale.
L’horizontal and vertical system integration riguarda una maggior coesione tra compagnie, dipartimenti, funzioni e competenze al fine di una maggiore dinamicità e ottimizzazione delle risorse materiali e umane.
Il terzo punto, l’internet of things, riguarda l’integrazione di dispositivi (appliances) e di macchinari a uso industriale a internet, in modo da averne un controllo e una gestione remotizzate, integrate e
centralizzate nonché una diagnostica in tempo reale delle loro attività e del loro stato di salute.
La cybersecurity è un tema che ci coinvolge tutti e riguarda la protezione informatica dei dati presenti su internet ossia l’impiego di sistemi di autenticazione e cifratura sempre più sofisticati che garantiscano la sicurezza informatica sia a livello del singolo sia delle aziende.
Il cloud si concentra sulla remotizzazione di servizi (es. archivi) e applicazioni software collaborative. L’additive manufacturing riguarda le nuove tecniche di produzione in cui il prodotto finito è formato senza la necessità di fonderne il materiale in stampi né di rimuoverlo da una forma grezza. Oggigiorno le stampanti 3D avranno un ruolo fondamentale per produrre componenti e prototipi.
L’analisi delle grandi moli di dati presenti su internet al fine di estrazione di trend predittivi e comportamentali è alla base della big data analytics.
La realtà aumentata, augmented reality AR, oltre ad offrire un’esperienza ludico-attrattiva senza
precedenti (musei, siti archeologici), permetterà agli operatori di usufruire in tempo reale, direttamente sul posto di lavoro, delle informazioni e delle istruzioni gestite da personale esperto localizzato magari in una sede centralizzata. Occhiali, caschetti e particolari guanti faranno da vettore per questa tecnologia. L’ultimo pilastro sono i robot autonomi ovvero l’integrazione delle capacità e conoscenze umane con robot capaci di adottare un comportamento adeguato alla situazione sociale e all’ambiente che li circondano.
Questa tesi coinvolgerà due dei 9 pilastri: l’utilizzo di un robot sociale integrato in una piattaforma di IoT.
Da questo, insieme al fatto che si lavorerà a una soluzione globale di tipo EUD, risulta chiaro come questo lavoro di tesi sia attualizzato e inerente a tematiche di largo interesse sociale e industriale.
9
1.2 La storia dei robot: dai robot industriali a quelli sociali
Il termine “robot”, coniato nel 1921 dal romanziere e commediografo ceco Karel Apek nella sua opera “Rossum’s universal robots”, deriva dal vocabolo ceco “robota” che significa “lavoro forzato”.
Sarà con i racconti e i romanzi di fantascienza di Isaac Asimov che il termine “robotica” diviene popolare. A lui si deve l’idea delle “tre leggi della robotica” (1942).
I primi robot a uso esclusivamente industriale nascono intorno agli anni 50’.
Lo studio e la creazione di robot da parte dell’uomo nasce dalla necessità di avere a disposizione dei mezzi che possano sostituirlo nelle attività più faticose, rischiose o comunque metodiche e ripetitive. Nascono così i “telemanipolatori”, bracci meccanici controllati da un operatore umano e utilizzati per maneggiare sostanze pericolose, come materiali radioattivi all’interno di centrali nucleari. Più avanti, grazie allo sviluppo dell’elettronica e dell’informatica, hanno visto la luce bracci meccanici motorizzati e programmabili tra i quali il PUMA, Programmable Universal Manipulator for Assembly, manipolatore universale programmabile per assemblaggio (1974).
Questi potrebbero essere associati a quelli che oggi chiamiamo “esoscheletri” ovvero strutture hardware-software indossabili che garantiscono assistenza fisica (maggiore forza, maggiore velocità, maggiore precisione, ecc.) e riducono i rischi collegati a sforzi sull’apparato muscolo-scheletrico.
Una distinzione necessaria fin da subito è quella fra robot industriali, sviluppati nel compiere un compito specifico in un ambiente ben delimitato, e robot umanoidi sociali ovvero robot immersi in un ambiente naturale in completa convivenza di esseri umani con i quali devono relazionarsi e scambiare
informazioni.
Uomo e robot umanoidi condivideranno uno spazio di lavoro comune, dove il robot non dovrà sostituire l’uomo, ma lo potrà assistere dando il suo contributo in base alle proprie capacità sensoriali, fisiche e cognitive in modo che il risultato finale sia una sinergia fra facoltà e conoscenze umane e robotiche. Per robot sociali si intende lo sviluppo di robot “compagni del cittadino”: umanoidi che ci aiuteranno nel lavoro, nelle faccende di casa, nella cura di bambini e nell’assistenza di anziani e disabili. Robot che affiancheranno i professionisti negli ospedali, nell’insegnamento, nelle aule di tribunale, nei centri di analisi dati e così via. Robot che interagiranno con noi sia vocalmente che tramite i gesti e tutte le altre modalità tipiche della comunicazione umana.
Progettare robot di questo genere significa progettare alter ego dell’uomo stesso, ovvero qualcosa che esula dai domini dell’ingegneria e della scienza costituendo una delle sfide più grandi e affascinanti della creatività e della caparbietà umana.
10
1.3 Le quattro aree di applicazione dei robot
Oltre ai robot sociali assistenti dell’uomo di cui questa tesi tratterà nello specifico, lo scenario tecnologico si sta sviluppando in altre tre macro aree [36]:
il campo medico che vede protagonisti da un lato nonomacchine (equivalenti ai biologici anticorpi) che, una volta iniettati nel corpo umano, sono in grado di riconoscere cellule malate e di rilasciare
direttamente il medicinale colpendo solo le aree d’interesse, e dall’altro protesi ed esoscheletri in grado di aiutare e sostenere l’uomo dopo incidenti o traumi.
Intervento in caso di disastri ambientali e naturali in cui è il robot a intervenire in zone proibitive per
l’uomo (es. contaminazione radioattiva) agendo in maniera autonoma su terreni anche impervi (es. macerie e detriti) e in grado di fare delle preliminari analisi di dati (es. analisi biochimiche o recuperare i parametri fisici su persone colpite) da inviare al personale umano esperto che avrà le competenze professionali e decisionali adeguate.
La manifattura avanzata dove saranno sempre più necessarie modalità d’interazione collaborative fra uomo e robot, in cui il robot sia in grado per esempio di riconoscere la stanchezza dell’operatore (magari analizzando la velocità dei movimenti o il battito delle palpebre), sia in grado di gestire una
comunicazione multimodale (es. vocale e gesture) al fine di una miglior efficienza e sia correttamente salvaguardata la questione sicurezza; si parla in questi casi di industrial cobots.
Il robot umanoide Pepper che sarà analizzato in questo lavoro fa parte dei robot sociali dalle sembianze umane.
Vedremo cosa significa costruire un sistema software che possa trarre il meglio dalle sue capacità ma che al tempo stesso riesca a rimanere alla portata di una qualunque persona senza particolare formazione o cultura informatica.
Però prima sono necessarie alcune considerazioni al fine di focalizzare al meglio l’attività e
contestualizzare alla fine i risultati che otterremo. La prima parte del lavoro si concentrerà su questo background conoscitivo.
11
1.4 End User Development: motivazioni e caratteristiche
L’End User Development (EUD) è stato introdotto come un approccio di progettazione e sviluppo che vuole garantire la possibilità all’utente finale, con qualunque background informatico, di adattare l’applicazione alle proprie, spesso mutevoli, esigenze e situazioni.
Partendo da questa “definizione operativa”, è necessario scendere più nel dettaglio per capire le caratteristiche peculiari di questa prospettiva metodologica al fine di capire come mai certe soluzioni siano da considerare appartenenti a pieno titolo a questa categoria mentre altre no.
EUD è una metodologia che tende a colmare il gap fra utenti finali che non hanno skills di
programmazione ma che sanno bene di cosa c’è bisogno e sviluppatori professionali (molto meno numerosi dei primi) che sanno programmare ma spesso non hanno una completa visione delle reali esigenze puntuali e specifiche.
Il focus quindi si sposta dunque dall’ “easy to use” all’ “easy to develop” [47].
Le motivazioni che spingono allo studio e alla ricerca di soluzioni di questo tipo sono molteplici: • Il numero e la tipologia di dispositivi informatici (smart phones, tablet, smart watch) e appliances (luci, termostati, attuatori, ecc.) cresce continuamente e con esso la necessità di farli “dialogare” in maniera trasparente.
• In molti domini applicativi (es. sanità, educazione, commercio, musei, ecc.) c’è una necessità di soluzioni software che supportino le attività quotidiane (che possono variare rapidamente) anche da parte di personale non necessariamente con competenze informatiche.
• Acquisire skills informatiche professionali richiede tempo e dedizione e questo male si coniuga con un mercato in costante evoluzione caratterizzato da cicli di prodotto molto ridotti.
Questa metodologia di lavoro nasce dunque per coprire le nuove esigenze della società corrente dove i confini tra uso, progettazione e sviluppo, si fanno sempre meno marcati e rigidi.
Nel corso degli ultimi decenni si è assistito a un’evoluzione delle metodologie di progettazione di soluzione software.
Il metodo classico vede programmatori software professionisti sviluppare prodotti in base a specifiche tecniche e documentazione funzionale, in maniera del tutto indipendente dal vero contesto di utilizzo. Il dialogo sviluppatore-utilizzatore non è contemplato e il risultato è spesso un prodotto estremamente performante dal punto di vista tecnico ma con delle lacune se immerso nella realtà operativa.
Il secondo step è l’user-centered design che si concentra fin da subito sugli utenti e sui loro compiti (personas e scenario). Il cuore di questo approccio è il design iterativo basato su cicli di analisi, progettazione e valutazione [39].
12
Questa metodologia sposta lo sviluppatore software nel mondo dell’utilizzo reale, ovvero fa muovere lo sviluppatore nella direzione dell’utilizzatore.
L’approccio punta alla facilità d’uso e all’usabilità e in ultima istanza a una buona user experience. Il problema di cui soffre è il cosiddetto “one-way communication”; infatti i progettisti estraggono informazioni dagli utenti (tramite interviste, focus group, questionari), li osservano al lavoro e ne recuperano il feedback (test utente e questionari di post survey) ma non succede il viceversa, ovvero l’utente non si avvicina al mondo della progettazione software e non è contemplato il suo contributo o intervento nella fase progettuale.
Il livello successivo è il design partecipativo dove una rappresentanza di utenti (detti esperti del dominio) viene coinvolta nel progetto e diventano a pieno diritto membri della squadra del progetto. Qua s’instaura la cosiddetta “two-way communication” in cui tutti i membri del progetto contribuiscono con le proprie esperienze al miglioramento finale del prodotto. Qua è l’utente che si avvicina al mondo del progettista e diviene parte attiva e integrante del team di sviluppo.
L’ultimo livello è quello meta-design & EUD in cui all’utente finale vengono dati gli strumenti con i quali in maniera autonoma riuscirà a personalizzare e far evolvere il sistema per meglio adattarsi ai suoi bisogni contingenti.
13 La definizione formale di EUD è la seguente:
“End User Development is a set of activities or techniques that allow users of software systems, who are acting as nonprofessional software developers, at some point to create or modify a software artefact” [EUD-Net 2003]
Mentre quella di meta-design è:
“Meta-design characterizes objectives, techniques, and processes for creating new media and
environments allowing ‘owners of problems’ (that is, end users) to act as designers” [Fischer et al. 2004, CACM]
Meta-design ed EUD vanno a braccetto definendo una metodologia che implica sia partecipazione e collaborazione attiva dell’utente finale nel processo di sviluppo software, ma anche la possibilità di quest’ultimo di modificare (con linguaggi e tool appropriati) le strutture del sistema, diventando lui stesso progettista capace di creare o modificare un sistema software.
EUD più che focalizzarsi sulla parametrizzazione e customizzazione e dunque sul fornire all’utente alternative su comportamenti già presenti nel sistema (sia a livello di presentazione che di meccanismi d’interazione), si basa su attività che implicano la modifica, la creazione e l’evoluzione delle strutture presenti nel sistema.
Tornando su una visuale operativa, sono due gli aspetti fondamentali per cui una soluzione software possa essere classificata come “EUD compliant”:
• Semplicità d’uso tale per cui chiunque possa lavorarci e ottenere le medesime qualità di risultati.
• Garantire l’evoluzione del sistema dando la possibilità all’utilizzatore di “generalizzare” la soluzione per raggiungere nuovi obiettivi a partire da componenti già presenti.
Dove naturalmente la seconda non deve precludere la prima.
Per completezza si riportano alcune tecniche che la letteratura [48], [49] annovera fra le EUD compliant: • Database Query Languages
• Visual Programming • Spreadsheet Programming • Programming By Example • Form-based fill-in
• Trigger-action programming • Natural language programming
14
1.5 Coblox: una soluzione EUD applicata a un robot industriale
CoBlox è un ambiente di programmazione a blocchi sviluppato per comandare il robot industriale ABB Roberta [51].
L’utilizzo delle metafore visuali dei blocchetti è una pratica già nota e largamente utilizzata da diversi anni per fare le prime esperienze di programmazione da parte di giovani ragazzi; ne è un esempio emblematico Scratch (http://scratch.mit.edu).
Alcune convenzioni comuni a queste tipologie di soluzioni sono:
• Ogni colore identifica una famiglia di funzionalità (es. verde per gli operatori, arancione per le variabili, ecc.).
• Le strutture di controllo (for, repeat, if) sono caratterizzate da una forma concava a C a indicare che sono delle strutture contenitrici.
• I blocchi hanno una forma a seconda del tipo di output: ovali per i numeri, esagonali per i booleani, ecc.
Lo scopo di CoBlox è quello di utilizzare la stessa soluzione a blocchetti non per scopi ludico-educativi ma industriali, ovvero programmare un braccio robotico a compiere task complessi specifici dell’ambito automazione.
La soluzione proposta entra a pieno titolo fra gli approcci EUD garantendo semplicità e al contempo creatività e adattabilità verso nuove esigenze e potenziali ambiti applicativi.
15
I risultati comparativi (CoBlox, Flex Pendant, Polyscope) esposti in [51] dimostrano come la soluzione scelta sia una possibile strada verso la meta di rendere la programmazione di robot industriali più accessibile a persone con limitata o addirittura inesistente, esperienza di programmazione.
Naturalmente l’esempio riguarda un robot di tipologia completamente diversa da quello oggetto di questa tesi: un robot industriale costituito da un solo braccio, una tipologia di robot che largamente si differenzia da un robot sociale la cui gestione implica complessità e problematiche diverse (capitolo 4 I
livelli di astrazione nella programmazione di un robot sociale).
1.6 Node Primitives: una soluzione EUD applicata a un robot sociale
Mentre CoBlox è un esempio di EUD applicato a robot industriali, Node Primitives (NEP) [4] è un esempio di EUD applicabile a robot sociali della famiglia Aldebaran che include Pepper, utilizzato in questo elaborato. Da questo punto di vista è un software “vicino” a quello sviluppato per questo lavoro perché da una parte ne condivide problematiche (robot sociale) e approcci risolutivi (come ad esempio l’utilizzo delle NAOqi API di livello social primitives (capitolo 4 I livelli di astrazione nella
programmazione di un robot sociale), comunicazione Server-Sent Events, sviluppo in Python e
JavaScript, scambio informativo in formato JSON) ma dall’altro se ne differenzia perché abbraccia una soluzione EUD diversa (block-based invece di triggers-actions rules) e soprattutto perché confinato alla sola gestione del robot senza aprire la strada a eventuali integrazioni con il mondo IoT.
I principi su cui si basa NEP sono l’usabilità e la flessibilità garantendo facilità d’installazione, facilità di utilizzo, e facilità di sviluppo.
La piattaforma è costituita da due corpi principali, la prima è un framework che provvede alla comunicazione interprocesso e allo scambio informativo in un’architettura publisher-subscriber e la seconda è un’interfaccia Web sviluppata per una gestione semplice e intuitiva del comportamento del robot.
16
Figura 4. Schema funzionale a blocchi di NEP [4]
Senza soffermarci sul primo componente più specifico per lo scambio delle informazioni, è interessante porre attenzione all’interfaccia Web di programmazione.
La scelta della modalità block-based è stata anche dettata [4], come visto nel paragrafo precedente, dalla familiarità di tale approccio da parte di novelli programmatori alle loro prime esperienze con le problematiche di sviluppo software.
Nell’interfaccia sono presenti dei bocchi funzionali del tutto analoghi a quelli descritti in precedenza.
Figura 5. NEP modalità di programmazione block-based.
Scegliendo le componenti logiche e le variabili desiderate è possibile organizzare e gestire il comportamento del robot in maniera semplice e intuitiva.
17
Come descritto in [4], tale modalità di programmazione ha ottenuto una valutazione SUS (System Usability Scale) su scala 7 (e non 5 come da standard) pari a 78.6 centesimi, ottenendo dunque un buon risultato [50].
Ciò che manca a questa soluzione è la possibilità di integrare le funzionalità del robot in un più ampio dominio applicativo IoT, dove il robot possa essere utilizzato sia per comunicare con l’uomo sia come un insieme di sensori capaci di generare eventi specifici e un attuatore di azioni capace di modificare l’ambiente in cui si trova.
Questa è la meta di questo lavoro di tesi.
2 L'esperienza comunicativa coi robot
Per i suoi primi 50 anni circa la robotica è stata oggetto di applicazioni industriali che hanno prodotto macchine assai poco attraenti per gli studiosi dell’interazione.
Ma da qualche anno questa parte le cose sono cambiate, e soprattutto con i primi robot umanoidi si è acceso l’interesse verso soluzioni comunicative che siano in grado di rispecchiare, almeno in parte, le aspettative dell’uomo nei riguardi di questi robot.
Una prima costatazione è che l’uomo tende a percepire il robot in maniera diversa dalle altre macchine e una prima ragione è la fisicità stessa di queste macchine.
Anche il solo semplice fatto di non doverci necessariamente interagire tramite mouse e tastiera da una posizione seduta ma potersi avvicinare e toccare con mano perché presenti vicino a noi, fa da
catalizzatore dell’interazione e innesca quel processo di antropomorfizzazione tipico dell’uomo (Friedman, Kahn, & Hagman,2003)[31] anche se il loro aspetto fisico differisce da quello umano. La seconda ragione riguarda la loro mobilità. Il fatto che si spostino nello svolgimento dei loro compiti o se sollecitati da stimoli esterni, danno la sensazione all’uomo che li osserva di essere di fronte l’evolversi di comportamenti dinamici che hanno sì una meta finale, ma che siano comunque in grado di modificare il comportamento in funzione delle condizioni ambientali che gli si pongono davanti.
Il terzo aspetto d’interesse è dato dalla capacità dei robot di prendere decisioni (dal riconoscimento vocale al riconoscimento di un volto o la scelta del percorso più breve) funzionalità già presenti in altre tecnologie (es. smartphone) ma che nel caso del robot vengono esaltate proprio dalla sua fisicità e dalla sua capacità di movimento (per riconoscere un volto dovrà prima mettersi di fronte ad una persona e poi rivolgergli lo “sguardo”, per capire una parola dovrà prima avvicinarsi all’interlocutore) oltre che dalla consapevolezza delle proprie caratteristiche (non prendo quella strada perché non ci passo o la mia batteria è troppo scarica) e dell’ambiente che lo circonda (distanze, pendenze, livello di luminosità, ecc.). Anche la capacità di apprendere dalle proprie esperienze passate (tramite tecniche di machine learning) rientra in questa categoria di aspetti.
Tutto questo pone problemi d’interazione che gli altri agenti software in generale non devono affrontare.
18
2.1 La caratteristica di agentività
La distinzione fra essere animato e non passa dal riconoscere nel soggetto la caratteristica di agentività, ovvero di entità animata dotata d’intenzioni e scopi e in grado di esprimere i propri stati interni in maniera attiva trasformando il contesto in cui è inserito (Bandura 1997).
Quali sono dunque i requisiti minimi individuabili in un robot umanoide per poter essere in grado di interagire al meglio con gli esseri umani?
Marti [31] ne individua 4:
1. La morfologia, ovvero delle caratteristiche fisiche che richiamino all’uomo (es. occhi, naso e bocca).
2. L’esperienza tattile è un altro elemento fondamentale di distinzione fra un oggetto animato da uno che non lo è. Il fatto che un oggetto si possa toccare è già qualcosa che “avvicina” l’uomo. 3. La direzione degli occhi e dello sguardo e il movimento della testa: il fatto che il robot sia in
grado di seguire un faccia (face-tracking) sia col movimento degli occhi ma anche, in maniera coordinata, della testa e del corpo aumenta notevolmente il feeling uomo-robot.
4. Interazioni reciproche e contingenti ovvero essere in grado di dimostrare empatia con l’uomo
adattando le sue funzionalità al feedback percettivo umano. Ne è un esempio la modifica del tono della voce o delle gestualità se il robot avverte particolari stati d’animo nell’interlocutore.
Un personale parere riguardo al robot Pepper (analizzato nel capitolo 5 Pepper ) è che da un punto di vista morfologico e della gestione della direzione degli occhi e dei movimenti associati, sia un prodotto ben progettato: in modalità interactive, come vedremo, il robot “segue” il suo interlocutore ed è forte la sensazione della sua presenza.
L’esperienza tattile non è delle migliori in quanto i sensori da premere sono di una lega plastica che certo “non invita” al contatto.
Per l’ultimo punto, la dimostrazione di empatia, il controllo tramite le API dedicate non ha portato ai risultati desiderati (par. 8.5 Descrizione degli eventi e delle azioni "human friendly").
2.2 La progettazione di un robot sociale
Come dovrebbero essere progettati i robot di tipo umanoide per risultare accettabili per l’interlocutore umano?
Un fenomeno ben noto nella cinematografia è il cosiddetto effetto “uncanny valley” anche detto “effetto Zombie”.
19
Questa è un’ipotesi psicologica proposta da Masahiro Mori nel 1970 che può essere sintetizzata così: gli esseri umani hanno reazioni positive davanti a cose riconoscibili e neutre davanti a cose molto diverse, ma non apprezzano le cose leggermente diverse da quelle familiari. Anche se l’ipotesi non è mai stata dimostrata rigorosamente, è sicuramente vero che alcune imitazioni quasi riuscite creano un forte effetto negativo (ad esempio battute ed espressioni divertenti di assistenti vocali come Siri, Cortana, ecc. non incoraggiano [37] )
Figura 6. Uncanny Valley: la relazione non lineare fra somiglianza umana e accettabilità. (https://commons.wikimedia.org/wiki/File:Mori_Uncanny_Valley.svg)
Questa non linearità dell’accettazione nei confronti della similarità umana si applica anche ai robot umanoidi: quanto più verosimile è il robot nel suo aspetto fisico e comportamentale a un essere umano tanto più esso diventa familiare (o credibile) per l’essere umano. Tuttavia l’andamento ha un minimo locale caratterizzato da una brusca caduta della familiarità, associata a sensazioni spiacevoli come repulsione e inquietudine, quando il robot è così simile da poter “essere scambiato” per reale. La troppa ma non totale somiglianza fisica e comportamentale all’uomo viene percepita come un’invasione dell’identità umana e va a minare l’approvazione da parte dell’uomo.
Dato che tali confini sono sfumati e rarefatti è evidente come la fase di progettazione e prototipazione iniziale sia alla base per il futuro successo di un robot umanoide.
20
La somiglianza dei robot sociali agli esseri umani (life-like robots) porta con sé il problema di grandi aspettative dell’interlocutore umano, che se tradite, portano a frustrazione o irritazione.
Da qua il suggerimento di Don Norman (1994) di progettare robot che manifestino il loro “essere sistemi imperfetti” palesando i loro limiti.
A livello linguistico non dovrebbe per esempio usare parole di un registro più alto o produrre frasi più complesse di quelle che è in grado di capire; dovrebbe cioè “regalare predittività” delle sue capacità in base al suo stesso comportamento, come in questo caso dimostrare una limitata conoscenza linguistica. Sempre Norman suggerisce alcuni “consigli pratici” di progettazione di robot umanoidi [38] come del tipo che le telecamere dovrebbero essere posizionate dove sono gli occhi, i microfoni dove sono le orecchie (viene naturale sussurrare alle orecchie), i suoni dovrebbero provenire dalla bocca. Il tutto per favorire quel processo di “antropomorfizzazione” che l’uomo in maniera automatica (a causa del
modello concettuale [44] da cui parte) attuerà nei confronti del robot (vedremo come Pepper viola
alcuni di questi principi elementari).
Un altro consiglio, sempre di Norman [30], viene dal fatto di dare consapevolezza al robot del suo livello di batteria e di adattare il suo comportamento in base a tale conoscenza.
A batteria scarica darà segni di stanchezza abbassando il tono della voce o l’intensità della luce degli occhi oppure muovendosi più lentamente e magari rifiutandosi di fare certe azioni, mentre a batteria carica sarà più veloce, più vivo e più reattivo.
Vedremo (paragrafo 5.1 Caratteristiche hardware e software) come alcuni di questi consigli verranno tenuti conto nella progettazione e realizzazione dell’applicativo software tema di questa tesi.
3 La comunicazione multimodale
Come si può comunicare con un robot umanoide? Limitarsi al controllo tramite mouse e tastiera sarebbe impensabile per quanto descritto fin ora.
Risulta scontata la scelta di modalità più “naturali” ovvero human friendly tipiche dell’interazione fra persone, in grado di coinvolgere tutti i sensi umani e i canali di comunicazione, come il parlato, la visione, la gestualità e il tatto.
Nell’interazione uomo macchina una modalità è un modo di interagire con un sistema che sfrutti uno specifico senso umano [40].
Un atto comunicativo è multimodale se sfrutta più sensi per interagire (vista, udito, gesti, espressioni, ecc.).
Il dialogo fra persone (comunicazione faccia a faccia) è in genere multimodale [41]; nella multimodalità gli elementi non verbali (i segni paralinguistici quali espressioni del volto, gesti, posizioni del corpo, ecc.)
21
sono importantissimi: l’uso frequente dei riferimenti deittici (espressioni come “questo” o “quello” accompagnato o esclusivamente referenziato con un gesto) ne sono un esempio lampante.
Il linguaggio verbale (le parole che usiamo) rappresenta solo una minima parte della nostra capacità di comunicare. La componente non verbale è spesso la componente principale.
Noi esseri umani non ce ne accorgiamo perché per noi è naturale fruire l’informazione da più canali, farne sintesi e operazioni inferenziali e soprattutto “risolvere” le ambiguità in base al contesto. Questo è un esempio di quello che viene definito “simplexity” [42] ovvero “semplice complessità” che nel nostro contesto significa la semplicità con cui noi esseri umani affrontiamo situazioni molto complesse senza rendercene conto; tale problematiche si palesano solamente nel momento in cui vorremmo farle compiere a macchine o software specifici (es. riconoscimento vocale o riconoscimento d’immagini e volti).
In generale, è possibile distinguere sei categorie principali di modalità d’ interazione “naturali”, anche se in alcuni casi i confini tra le diverse modalità appaiono sfumati:
1. il parlato; 2. i gesti;
3. le espressioni facciali;
4. il tracciamento dello sguardo; 5. prossemica e cinesica; 6. aptica;
Per capire l’importanza della multimodalità è sufficiente analizzare i processi comunicativi umani e notare come utilizzino, praticamente insieme e spesso contemporaneamente, tutte le modalità d’interazione.
Nell’ambito di una qualunque conversazione, ad esempio, sono quasi sempre coinvolti:
• la voce, nelle sue variazioni prosodiche e soprasegmentali (tono, intonazione, cadenza, ecc.); • lo sguardo, sia nel momento in cui viene rivolto verso l’interlocutore sia quando viene
distolto da esso;
• i movimenti delle mani, del corpo, la postura e la distanza dall’interlocutore, ovvero la cinesica e la prossemica;
• le espressioni facciali.
Dovrebbe risultare chiara dunque la portata di problematiche che si presentano in un’interazione naturale in un ambiente condiviso fra uomo e robot, tutti problemi studiati e (in gran parte) risolti nelle classiche interfacce a schermo gestite da mouse e tastiera.
22
3.1 Il parlato
Il parlato risulta il metodo preferito dalle persone [khan 1998] nell’interazione uomo macchina e rappresenta dunque l’interfaccia di Linguaggio Naturale (NLI, Natural Language Interfaces) più importante.
A oggi si ottengono buone prestazioni dal punto di vista della sintesi vocale (generazione delle parole) mentre vi è ancora molto da fare per quanto riguarda il riconoscimento vocale (approccio a catene markoviane Hidden Markoviam Model HMM o reti neurali Long Short Term Memory Recurrent Neural Network LSTM RNN che si voglia scegliere) dove gli attuali valori di WER (Word Error Rate) in inglese si aggirano per le migliore tecnologie (Google, Dragon) intorno al 7% dichiarato (in realtà in condizioni standard siamo a valori più alti, senza parlare per le lingue diverse all’inglese come l’italiano dove ci aggiriamo intorno al 10-12%) [37].
Oltre il fatto di essere una modalità “istintiva” [43] di comunicazione è anche sicuramente tra le più rapide e immediate. Inoltre è possibile individuare due categorie di situazioni tipiche nelle quali può sicuramente essere consideratala la modalità ottimale:
• L’utente ha le mani impegnate;
• L’utente ha gli occhi impegnati o comunque non può vedere l’interlocutore.
Non sempre però il parlato è modalità d’interazione migliore. Basti pensare alla sua naturale ambiguità e imprecisione. Credo che per tutti sarebbe difficile pensare di lavorare su una mappa o un disegno CAD con precisone solo attraverso comandi vocali.
3.2 I gesti
La definizione di gesto fornite dalla letteratura sono molteplici.
Alcune sottolineano l’aspetto d’intenzionalità comunicativo. Morris (1990) lo definisce come: “qualunque azione che invii un segnale visivo a uno spettatore ed è rivolta a trasmettere
un’informazione”; altri non ritengono l’intenzionalità come elemento discriminante del gesto perché l’emittente, durante l’interazione, può produrre un comportamento non verbale significativo in maniera indipendente dalla sua intenzione o consapevolezza (Ekman 1969, Poggi 1977, Maricchiolo 2002) [32]. Comunque per ogni teoria elaborata in letteratura, si possono estrarre 4 tipologie di gesti che ricorrono in maniera predominante:
gesti deittici (dal greco dèicnumi=indicare): gesti che sono utili per indicare un oggetto, una
23
tipologia di gesti che più spesso si accompagna al parlato e ai quali si ricorre per risolvere le ambiguità dell’uso di riferimenti deittici (qua, la, questo, laggiù, qui, ecc.). Un comando come “vai là” è ambiguo se non accompagnato da un gesto appropriato che indichi una direzione precisa.
gesti iconici (dal greco èicon=immagine): consistono nel “disegnare” nell’aria la forma di un
oggetto, di un’animale o di una persona o di imitarne i movimenti caratteristici.
gesti simbolici o emblematici: sono movimenti in grado di esprimere un significato facilmente
riconducibile a parole o frase come le dita a “V”per indicare la sigaretta o il classico gesto con le “mani a tulipano” a esprimere “cosa vuoi”.
pantomime: “sono gesti che consistono nella rappresentazione motoria e nell’imitazione di
azioni, scene o situazioni” (Anolli 2002). Ne sono un esempio la simulazione dell’uso delle forbici fatta muovendo indice e medio.
I gesti sono da considerarsi la seconda modalità più naturale di comunicazione tra esseri umani, infatti, ai fini pratici, è spesso sufficiente realizzare interfacce che combinano i gesti col parlato (e in effetti, la maggior parte delle ricerche svolte nell’ambito della multimodalità si muovono in questa direzione). Per quanto riguarda le tecniche utilizzate per il riconoscimento dei gesti, nel corso degli anni sono stati adottati diversi approcci: per mezzo di analisi di sequenze video, mediante tecniche di riconoscimento in tempo reale e attraverso approcci che utilizzano Modelli di Markov Nascosti (HMM, Hidden Markov Models).
3.3 Le espressioni facciali
Per un uomo non è difficile riconoscere una faccia, anche in presenza di notevoli cambiamenti di aspetto derivati da diverse condizioni di visibilità, espressioni, età, acconciature diverse, ecc. Una volta
riconosciuta una faccia è altrettanto facile identificarne i movimenti relativi delle sue parti che sono appunto le espressioni facciali. Si ritrova il concetto di “simplexity” [42] visto in precedenza. Per una macchina non è un processo così semplice. Dovrà esserci una fase preliminare di acquisizione del volto in varie posizioni e condizioni di luminosità e di salvataggio delle caratteristiche facciali, “facial features”, estratte (posizione e dimensioni di occhi, naso e bocca), una seconda fase a runtime di rilevazione del volto noto e grazie ad algoritmi di face-tracking, l’individuazione dei movimenti relativi (posizione assunta da occhi, naso e bocca) per associarle infine a famiglie di espressioni note a priori. Nel
paragrafo 8.5 Descrizione degli eventi e delle azioni "human friendly" vedremo le capacità di Pepper in questa direzione.
A rigore, questa modalità d’interazione sarebbe da includere nella “cinesica” (che vedremo par. 3.5 Prossemica e cinesica) ovvero della disciplina che si occupa, in generale, dei movimenti del corpo,
24
mimica facciale inclusa. Dal momento che le espressioni facciali giocano un ruolo comunicativo estremamente importante sono spesso poste come modalità interattiva distinta.
3.4 Il tracciamento dello sguardo
La direzione dello sguardo gioca un ruolo importante nell’interazione sociale umana e, in particolare, nell’identificazione del “focus” di attenzione di una persona. Durante la comunicazione faccia-a-faccia le persone si guardano, tengono d’occhio i movimenti delle labbra altrui, le espressioni facciali e seguono lo sguardo dell’interlocutore.
Per un robot capire cosa stiamo guardando o a cosa prestiamo attenzione o meno può essere di grande aiuto per cogliere ad esempio l’oggetto cui ci stiamo riferendo parlando, o più semplicemente per capire se ci stiamo rivolgendo a lui o a un’altra persona.
3.5 Prossemica e cinesica
La modalità di comunicazione prossemica concerne la distanza tra gli interlocutori. Essere staticamente a una certa distanza o variarla attraverso il superamento di “soglie” può fornire un utile indizio circa i rapporti fra gli interlocutori e in generale circa la disponibilità o meno alla conversazione.
La letteratura riconduce a 4 soglie di distanza [32]:
• distanza minima: (da 0 a 45 cm) è la distanza dell’intimità come fra partner e tra
figlio-genitore. L’invasione di questa distanza è dunque accettata solo in caso di stretti legami affettivi.
• distanza personale: (da 45 cm a un metro) è la distanza tipica degli amici o della parentela
stretta.
• distanza sociale: (fra 1 e 4 metri) è la distanza delle relazioni formali e impersonali. A questa
distanza non è possibile alcun modo il contatto fisico e gli unici canali attivi sono quelli uditivo e visivo.
• distanza pubblica: (oltre 4 metri) è la distanza delle situazioni pubbliche e ufficiali (es.
oratore sul palco).
Queste distanze sono variabili da cultura a cultura (nord europea, indiana, asiatica sono “culture della distanza”, sudamericane, latine e arabe sono “culture della vicinanza”; la medesima classificazione la possiamo ritrovare negli studi di cultura visuale [45]).
25
La cinesica è la modalità che riguarda il movimento e l’assunzione di posizioni (il linguaggio del corpo): si occupa dei gesti compiuti utilizzando una o più parti del corpo e in particolare dell’uso delle mani, della mimica facciale e della postura, ovvero della posizione dell’intero corpo e degli atteggiamenti motori. La postura può assumere significati interpersonali di dominanza-sottomissione (si pensi al capo chino difronte a un superiore o un atteggiamento “impettito” in senso di controllo e superiorità) o espressione di stati emotivi interni di tipo rilassatezza-tensione (come il tenere le braccia incrociate, puntare i pugni sui fianchi, battere le dita sul tavolino durante una conversazione, passeggiare nervosamente,
accavallare le gambe).
Questo linguaggio del corpo che si produce durante un’interazione, più o meno inconscio che sia, può costituire una preziosa fonte aggiuntiva d’informazione che il robot potrebbe interpretare e in base alla quale adattare il proprio comportamento.
Vedremo, nella parte di programmazione del robot, come da una parte i segnali prossemici siano di “facile gestione” mentre dal punto di vista cinesico il robot non offra tecniche di controllo utili allo scopo (paragrafo 8.5 Descrizione degli eventi e delle azioni "human friendly").
3.6 Aptica
Tutto ciò che concerne il senso del tatto può essere classificato sotto la voce “aptica”, che possiamo definire come lo studio dell’acquisizione dell’informazione attraverso il contatto fisico.
Tale forma comunicativa rappresenta l’espressione più primitiva di azione sociale che nasce dal bisogno innato di rassicurazione e affetto [32].
Abbiamo incontrato nel paragrafo 2.1 La caratteristica di agentività, come l’esperienza tattile sia una delle più importanti nella caratterizzazione di agentività associabile a un robot umanoide.
La lista dei numerosi sensori tattili presenti su Pepper (paragrafo 5.1 Caratteristiche hardware e
26
4 I livelli di astrazione nella programmazione di un robot sociale
La programmazione di un robot sociale necessita accurate scelte in termini di livello di astrazione da adottare in quanto risulta estremamente difficoltoso programmare un agente con capacità interattive umane.
Come descritto in [1], per creare un modello d’interazione basato su livelli di astrazione, le capacità di un robot sociale sono state suddivise in una scala a 5 livelli basandosi sulla sintesi fra caratteristiche
hardware e software del robot stesso.
Figura 7. I livelli di astrazione dell’interazione sociale
Il livello più basso consiste nelle hardware primitives. Queste primitive riguardano il controllo e il recupero dello stato dai dispositivi hardware, come ad esempio il controllo dei LED, degli attuatori motori, il recupero dei dati dai sonar, della videocamera e dei microfoni.
27
Questo livello di astrazione è dove ad esempio si posizionano le specifiche ROS (Robot Operating System) [2].
Il secondo livello di astrazione consiste nelle algorithm primitives. Queste primitive sono relative alle capacità del robot di interagire con l’ambiente e un primo approccio funzionale all’interazione sociale. Esempi di questo livello di primitive sono il riconoscimento/sintesi vocale, l’inseguimento dei volti (face tracking), localizzazione della fonte di rumore.
La piattaforma dei robot umanoidi Aldebaran, NAOqi [3], fornisce molte primitive appartenenti a questo livello di astrazione. I dettagli di questo framework saranno descritti nel dettaglio nel paragrafo 8.1
NAOqi framework.
Il terzo livello consiste nelle social primitives. Queste sono unità atomiche d’interazione sociale implementate tramite primitive algoritmiche e in alcuni casi attraverso primitive hardware.
Ad esempio la capacità di seguire con lo sguardo una persona è una combinazione fra face-tracking e controllo motorio di testa e torso.
Si differenziano dalle primitive hardware e algoritmiche perché sono specifiche del dominio dell’interazione sociale.
Il quarto livello di astrazione sono le emergent primitives, un livello di astrazione che combina due o più social primitives. Pensiamo alla capacità di esprimere emozioni oppure il dialogo uomo-robot dove il robot deve combinare diverse social primitives come il face-tracking, il riconoscimento/sintesi vocale, il movimento del corpo ecc.
Nella piattaforma Aldebaran ne è un esempio ALDialog [16] (e la sua evoluzione QiChat), il dialogo implementato con le API NAOqi, che unisce riconoscimento/sintesi vocale, inseguimento stimolo visivo e sonoro, rilevazione/riconoscimento volto, riconoscimento gesture.
Come descritto in [4], il miglior livello di astrazione da preferire e su cui basarsi per la creazione di un ambiente rivolto alla programmazione di robot sociali è quello delle social primitives in quanto le emergent primitives sono meno riutilizzabili e customizzabili data la loro caratteristica di combinare eterogeneamente diversi contenuti e contesti.
Come vedremo (capitolo 8 L’integrazione di Pepper nella piattaforma TARE) nello sviluppo della nostra applicazione è stato tenuto conto di questo assert, cercando di limitare al minimo l’utilizzo e la
commistura delle diverse tipologie di primitive e focalizzandoci sulle social primitives.
L’ultimo livello di astrazione consiste nelle control primitives, che è lo strato più alto dedicato al controllo dei vari livelli di primitive sottostanti gestendoli in maniera simbiotica e trasparente. Fanno parte di questo livello ad esempio una macchina a stati finiti usata per gestire un dialogo tra uomo-robot combinando primitive di dialogo e ascolto, un sistema basato su regole o una struttura ad azioni
28
Come vedremo, la piattaforma trigger-action soggetto di questa tesi, si colloca di diritto su questo livello di astrazione.
Dall’analisi condotta in [1] e [4] risulta chiaro che a oggi esistono due bipoli opposti allo sviluppo di applicazioni interattive rivolte a robot sociali: il primo è l’utilizzo di framework per programmatori esperti spesso su base GNU/Linux e linguaggi di programmazione con una curva di apprendimento molto ripida C++, LUA; queste condizioni, se da un lato puntano all’ottimizzazione delle performance, dall’altro non sono la strada per chi approccia queste tematiche per la prima volta. Questo rappresenta un ostacolo dato che skills software e design dell’interazione devono andare di pari passo. Fanno parte di questo gruppo il framework Bonsai [5] e il Robot Behaviour Toolkit [6].
Il polo opposto è l’utilizzo di toolkit grafici dall’interfaccia user-friendly che garantiscono sviluppi d’interazioni rapide senza però badare alle performance finali del risultato.
Negli ultimi anni sono stati rilasciati diversi software che vanno in questa direzione, come Choregraph (cui sarà dedicato una sezione specifica) [8], Interaction Composer [7], Interaction Block [9], TiViPE [10]. La tabella che segue sintetizza in maniera schematica i vari tools con le proprietà appena descritte che li contraddistinguono. Tool Utilizzatore target Tipologia Hardware primitives Algorithm primitives Social primitimes Emergent primitimes Control Primitives Riferimenti Choregraph Neofita (previa formazione) visuale e testuale √ √ √ √ √ [8] Interaction Composer Neofita (previa formazione) visuale √ √ √ √ [7] Interaction Block Neofita ed esperto visuale √ √ √ √ [9] TiViPE Neofita ed esperto visuale e testuale √ √ √ √ [10]
Tabella 1. Tools per la programmazione di un robot sociale
A Choregraph, il tool di programmazione dei robot della casa madre Aldebaran, sarà dedicato un paragrafo specifico (5.3 Choregraphe), ma è subito doveroso notare che se da una parte è vero che nella modalità visuale anche un neofita può cominciare a fare esperienza di programmazione del robot con semplici esempi di prova, è altrettanto vero che per funzionalità medie-avanzate è richiesta una certa dimestichezza ed esperienza del tool. Sul sito Aldebaran [8] è presente una sezione specifica alla documentazione nell’utilizzo del software ma per l’esperienza maturata sul robot, tale documentazione è spesso non sufficiente e necessita una grossa componente di prove a diretto contatto col robot.
29
5 Pepper
Pepper è un robot umanoide, il secondo della famiglia Aldebaran. Si posiziona tra Nao, il capostipite e Romeo, l’ultima versione, non ancora in commercio.
Figura 8. Pepper
É composto da una molteplicità di sensori, motori, videocamere controllate da un sistema operativo ad hoc: NAOqi OS.
Il progetto NAO fu lanciato nel 2004 da Bruno Mainsonnier che l’anno successivo fondò l’azienda Aldebaran Robotics con sede a Parigi a oggi confluita per la sua quasi totalità nel gruppo giapponese SoftBank Robotics.
30
5.1 Caratteristiche hardware e software
Come riportato nella pagina ufficiale Aldebaran [11], Pepper è alto 121 cm, largo 48 cm, profondo 42 cm.
Figura 9. dimensioni
Il corpo è realizzato con uno speciale materiale plastico e la batteria a ioni di litio ha una durata stimata di circa 2 ore.
La motherboard è un processore Intel Atom E3845, Quad Core, 1.91 GHz, una RAM a 4GB DDR3.
PROCESSOR Atom E3845
CPU Quad core
Clock speed 1.91 GHz
RAM 4 GB DDR3
FLASH MEMORY 8 GB eMMC
MICRO SDHC 16 GB
GPU Intel HD graphics up to 792 MHz Tabella 2. Caratteristiche Hardware Pepper
31 Come connettività:
Ethernet: 1xRJ45 - 10/100/1000 base T
Wifi: IEEE 802.11 a/b/g/n security: 64/128 bit: WEP, WPA/WPA2
Il sistema operativo è NAOqi (attualmente alla versione 2.4.3) una versione custom di Gentoo Linux [14], una distribuzione source-based di GNU/Linux che prevede la compilazione di programmi tramite codice sorgente piuttosto che mediante pacchetti precompilati. Questo al fine di una massima ottimizzazione delle risorse in funzione delle reali esigenze e dell’harware impiegato.
Come sensori di prossimità può sia avvalersi sia di 3 laser sia dei 2 sonar (anteriore e posteriore) con range massimo di 5 metri.
32 Figura 11. Sonar
Come vedremo in 8.5 Descrizione degli eventi e delle azioni "human friendly", sarà sfruttata proprio l’analisi dei segnali raccolti dai sonar come triggers per l’interpretazione prossemica dell’interlocutore.
Per quanto riguarda i sensori visivi possiede due identiche telecamere RGB 2D posizionate frontalmente che forniscono una risoluzione massima di 2560*1920 a 1 frames al secondo (fps) o 640*480 a 30 fps.
33
Figura 12. Telecamere 2D
Possiede inoltre una telecamera ASUS Xtion di profondità (sensore 3D) posizionata frontalmente di risoluzione massima 320x240 a 20 frames al secondo.
34
Come interfacce HRI (Human-Robot Interaction) dispone di un tablet, 4 microfoni sulla testa (figura 14 sinistra) 2 altoparlanti sulle orecchie (figura 14 destra) “violando” i buoni principi di progettazione di un robot sociale visti in 2.2 La progettazione di un robot sociale: il robot “parla dalle orecchie” e “sente dalla testa”.
Figura 14. Posizione microfoni e altoparlanti.
I led sono posizionati sulle orecchie, sugli occhi e sulle spalle.
35
Possiede inoltre dei sensori d’interazione in tre zone tattili sopra la testa (front/middle/rear), un sensore sulle mani (back) e uno su ogni paraurto (left/right/back).
Figura 16. Sensori tattili su testa, mani e paraurti Infine 2 bottoni collocati sul petto e tra le spalle.
36
Figura 17. Bottoni sul petto e tra le spalle
Come vedremo in 8.5 Descrizione degli eventi e delle azioni "human friendly" ognuno di questi sensori tattili è stato utilizzato al fine di ottenere un trigger scaturito dall’interazione con l’uomo.
Oltre a questi sensori elencati il robot possiede numerosi altri dispositivi tra i quali quelli per il controllo inerziale (giroscopi, accelerometri) di temperatura e di voltaggio.
5.2 Tools e SDK
Dal punto di visto della programmabilità esistono diverse strade;
Il robot viene distribuito con il software di programmazione Choregraphe di cui verrà data una descrizione più dettagliata in 5.3 Choregraphe.
Accanto a questo viene fornita un’interfaccia ROS [2], [12] e degli SDK in C++, Java, Python e JavaScript, quest’ultimo utile per lo sviluppo di pagine web implementate dal web server integrato nel robot e gestibili sia dal touch panel frontale che da browser di dispositivi terzi (8.4 WebSocket e Server-Sent
Events a confronto).
Nell’elaborato è stato scelto di utilizzare Python per il motivo di essere cross platform (il programma sviluppato funziona sia Windows che linux e quindi Pepper) mentre l’approccio C++ richiede una cross compilazione per poter funzionare su Pepper. Inoltre le API Python risultano ben documentate e supportate.
Come simulatore è possibile usare direttamente il robot virtuale offerto dal tool Choregraph
collegandosi in localhost (ip=127.0.0.1). Questo robot virtuale non fornisce però tutte le funzionalità (mancano ad esempio la gestione delle telecamere, dei laser e dei sonar) e risulta quindi una soluzione parziale al fine di uno sviluppo indipendente dal robot.
37
Un’altra strada è l’utilizzo di webots [13] che però, per la famiglia Aldebaran, fornisce solo Nao e non Pepper; quest’ultimo differisce dal primo in diverse funzionalità e caratteristiche hardware/software, per cui anche per questa strada non esiste un ambiente completo per testare i programmi.
Figura 18. Simulatore Webots
La mancanza di un simulatore completo e funzionale per testare Pepper nelle sue complete caratteristiche, rappresenta un concreto limite e un ostacolo nello sviluppo di applicazioni che riguardano il coinvolgimento di questa tecnologia.
5.3 Choregraphe
Choregraphe è l’applicazione desktop multi-piattaforma (Windows, Linux, Mac) di default per la programmazione di Pepper e degli altri robot Aldebaran. Questo permette di:
programmare il robot attraverso l’interconnessione di blocchetti grafici con funzionalità specifiche
creare animazioni, comportamenti e dialoghi
testare il progetto su un robot simulato o direttamente su quello reale
monitorare e controllare il robot attraverso il tool a corredo, Monitor, che permette l’analisi della vista e degli stimoli esterni oltre che dei dati provenienti dai vari sensori del robot.
38
Figura 19. Pagina di avvio di Choregraphe [15]
Come descritto in 4 I livelli di astrazione nella programmazione di un robot sociale questo permette all’utilizzatore di programmare l’interazione sociale attraverso un mix di livelli di astrazione, includendo
hardware, algorithm, social, emergent e controlling primitives.
Come descritto in [8] Choregraphe è la trasposizione grafica delle funzionalità NAOqi.
É possibile controllare i LED e i sonar (hardware primitives), lavorare col riconoscimento vocale e sul face-tracking (algorithm primitives), è possibile fare parlare Pepper e fargli assumere una determinata posizione (social primitives), e lavorare su combinazioni di queste funzionalità (emergent primitives) come col blocco Dialog, implementazione grafica di ALDialog.
Utilizzando due modalità di programmazione visuali, il dataflow diagram e la timeline (control
primitives), è possibile gestire strutturare i blocchi funzionali per creare comportamenti più complessi e funzionalità più evolute.
39
Figura 20. La suddivisione in pannelli di Choregraphe [15]
a) Project Files Panel: descrive le proprietà del progetto e i vari files allegati.
b) Box Libraries Panel: dove sono raggruppati, in base a famiglie di funzionalità, i blocchetti basici di controllo suddivisi nei macro gruppi Animation, Speech, Leds, Multimedia, Movement, Sensoring e Programming.
Selezionato un blocchetto logico è possibile trasportarlo (drag and drop) nel Flow Diagram Panel per interconnetterlo agli altri blocchi d’interesse
c) Flow Diagram Panel: dove si configura il comportamento del robot tramite la composizione dei blocchi funzionali e la loro interconnessione logica nella modalità in/out.
Per descrivere azioni sequenziali l’output di un modulo deve essere l’input per il successivo in un diagramma a catena.
40
Figura 21. Esecuzione seriale
Per descrivere esecuzioni parallele l’output di un blocco deve essere input dei blocchi su cui vogliamo che l’esecuzione venga avviata in parallelo.
41
d) Robot View e Video Monitor Panel: il primo mostra in una vista 3D il robot cui Choregraphe risulta collegato, mentre il secondo mostra ciò che viene visto dalla telecamera del robot in real-time. Quest’ultimo serve inoltre per fase di learning degli oggetti.
e) Inspector Panel and Robot Applications Panel: il primo è un pannello contestuale che mostra i dettagli di ciò che è attualmente selezionato, mentre il secondo mostra le applicazioni disponibili sul robot attualmente connesso.
Come già accennato la modalità di default, la dataflow diagram, segue la filosofia di programmazione di input (trigger), parametri e output.
Figura 23. Programmazione in modalità Data-flow
Nell’altra modalità, la timeline, il tempo fa da padrone; questa modalità è usata per organizzare i blocchi (keyframe) su un asse temporale piuttosto che nell’ottica in/out; questa modalità di gestione è
42
Figura 24. Programmazione in modalità Timeline
Un’importante caratteristica di Choregraphe è il fatto che possono essere creati nuovi blocchi funzionali utilizzando il linguaggio di programmazione Python. Per un programmatore con conoscenza di questo linguaggio risulterà così possibile arricchire le caratteristiche e le funzionalità del tool di management del robot.
43
Figura 25. Creazione di un blocco Python
In aggiunta a questo è possibile anche prendere visione del codice Python NAOqi costituente un singolo blocco così da avere traccia del codice testuale sottostante l’intero progetto.
44
5.3.1 Considerazioni
Il tool Choregraphe è un ottimo strumento per una rapida programmazione del robot in quanto ha dalla sua parte:
la possibilità di configurare semplici comportamenti del robot senza avere alcuna esperienza di programmazione formale ma basta una lettura della documentazione online per poter
cominciare a lavorare.
le due modalità di programmazione visiva, data-flow e timeline, riescono a coprire molte delle funzionalità “essenziali” di comportamento del robot.
la libertà di costruirsi i propri box partendo dal codice Python aggiunge un buon grado di libertà all’intero tool.
Di contro vi sono alcuni aspetti da non sottovalutare:
come accennato nel capitolo 4 I livelli di astrazione nella programmazione di un robot sociale la lettura della documentazione è essenziale per raggiungere una certa dimestichezza e flessibilità nella gestione del robot. Spesso però tale documentazione non è sufficiente e solo l’esperienza col tool può garantire buoni risultati.
la complessità delle interconnessioni e del numero dei singoli moduli può salire in maniera esponenziale per la gestione di comportamenti complessi (magari anche paralleli) rendendo l’applicazione poco gestibile. Si presenta dunque un problema di scalabilità verso l’alto.
manca un’apertura verso il mondo esterno: mancano infatti blocchi funzionali che permettano connessioni TCP/UDP, chiamate Rest, moduli specifici per la gestione di formati XML/JSON, query a database, ecc.
Risulta quindi possibile configurare solamente il robot in maniera “isolata” dal mondo circostante (non è neanche possibile fare dialogare due robot fra loro cosa invece realizzabile tramite le NAOqi API par. 8.1 NAOqi framework) e in particolare per i contenuti WEB (ad eccezione del caricamento di intere pagine web sul tablet), a meno che non si intervenga con la programmazione a codice Python. Naturalmente passando da questa strada la complessità di gestione sale e non ha più senso utilizzare Chroregraphe ma conviene gestire il tutto tramite le native chiamate NAOqi API.
Per come definite in precedenza le caratteristiche EUD (paragrafo 1.4 End User Development:
motivazioni e caratteristiche) Choregraphe non si può annoverare fra questo tipo di soluzioni. Se da un
lato infatti permette a un non programmatore di fare esperienza col robot grazie ad una modalità visuale fatta di elementi parametrizzabili, non permette, nella stessa modalità operativa, di rendere l’utente finale capace di modificare e fare evolvere la soluzione in base alle proprie esigenze. Ad esempio non è vi è alcun blocchetto grafico capace di fare una query a un database per recuperare informazioni da poi mostrare sul tablet o fare chiamate verso un servizio REST online e presentarne l’output in maniera testuale o vocale. Per fare questo è necessario passare dal codice Python precludendo la strada a utilizzatori non programmatori.
