here - Rosario Santoro

Transcript

POLITECNICO DI BARI
DIPARTIMENTO DI INGEGNERIA
ELETTRICA E DELL'INFORMAZIONE
CORSO DI LAUREA MAGISTRALE IN
INGEGNERIA INFORMATICA
TESI DI LAUREA IN
ELABORAZIONE DI IMMAGINI E VIS IONE ARTIFIC IALE
STUDIO, PROGETTAZIONE E SVILUPPO DI
UN PROTOTIPO DI UN SISTEMA DI REALTA' VIRTUALE
PER LA RIQUALIFICAZIONE DEGLI AMBIENTI VITALI
Relatore:
prof. ing. Vitoantonio BEVILACQUA
Laureando:
Rosario SANTORO
Correlatori:
dott. Michele PANTALEO
prof.ssa Marina DE TOMMASO
ANNO ACCADEMICO 2012/13
SOMMARIO
1 INTRODUZIONE E CONTESTO ........................ 1
1.1
LA REALTÀ AUMENTATA E LA REALTÀ VIRTUALE................................ 1
1.2
STATO DELL'ARTE ............................................................................... 4
1.3
IL CONTESTO ....................................................................................... 5
1.3.1
1.3.2
1.3.3
1.4
SENSORISTICA ..................................................................................... 8
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.5
Prima fase .................................................................................................... 6
Seconda fase................................................................................................. 7
Terza fase ..................................................................................................... 7
Elettrocardiogramma (ECG) ....................................................................... 8
Elettroencefalogramma (EEG) .................................................................... 9
Elettromiogramma (EMG) ......................................................................... 12
FIT.............................................................................................................. 13
La condizione di stress e suo rilevamento ................................................. 13
L'INTERVENTO DEL CANDIDATO NEL PROGETTO ................................ 14
2 PANORAMICA DEL SISTEMA ........................ 15
2.1
PANORAMICA DI ALTO LIVELLO ......................................................... 15
2.2
CICLO ESEMPLARE DI FUNZIONAMENTO ............................................ 16
2.2.1
2.2.2
2.3
La macrofase offline .................................................................................. 17
La macrofase online................................................................................... 19
ARCHITETTURA DEL SISTEMA ............................................................ 20
3 MODULO OFFLINE: MODELLAZIONE 3D ........ 23
3.1
L'ACQUISIZIONE ................................................................................ 23
3.1.1
3.1.2
Teoria sull'acquisizione ............................................................................. 23
Le alternative ............................................................................................. 30
i
3.1.3
3.2
La soluzione di acquisizione ...................................................................... 47
VISORI DI REALTÀ VIRTUALE ............................................................. 51
3.2.1
3.2.2
Meta AR ..................................................................................................... 51
Oculus Rift ................................................................................................. 54
3.3
LEAP MOTION ................................................................................... 57
3.4
CREAZIONE DELL'AMBIENTE VIRTUALE ............................................. 60
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
Unity 3D ..................................................................................................... 60
Le classi ..................................................................................................... 62
L'architettura event-oriented ..................................................................... 64
La descrizione XML della scena ................................................................ 66
La doppia visualizzazione .......................................................................... 68
3.5
I TIPI DI OGGETTO MODIFICABILI........................................................ 70
3.6
PROTOTIPO DELL'AMBIENTE VIRTUALE ............................................. 71
4 MODULO ONLINE: CONTROLLO DELLA REALTÀ
VIRTUALE ........................................................ 74
4.1
L'INTERFACCIA OPERATORE .............................................................. 74
4.1.1
4.1.2
4.1.3
4.1.4
4.2
Il Qt Creator .............................................................................................. 74
Il design pattern MVC e la sua variante .................................................... 76
Il diagramma delle classi ........................................................................... 79
L'aspetto della GUI .................................................................................... 82
LA COMUNICAZIONE .......................................................................... 83
4.2.1
4.2.2
4.2.3
4.2.4
Il formato JSON ......................................................................................... 83
Integrazione in Qt Creator......................................................................... 85
Integrazione in Unity 3D e C# ................................................................... 86
Il protocollo di comunicazione in JSON .................................................... 86
5 SVILUPPI FUTURI ....................................... 89
5.1
ALTRI STIMOLI .................................................................................. 89
5.2
MAGGIORE ATTIVITÀ DA PARTE DEL PAZIENTE.................................. 89
5.3
INGOMBRO DELL'OCULUS VR ........................................................... 91
5.4
IL SISTEMA COME WEB SERVICE ....................................................... 91
ii
5.5
DESCRIZIONE DELLE SCENE 3D MEDIANTE X3D ............................... 91
5.6
ALTRI UTILIZZI DEL SISTEMA ............................................................. 92
5.7
CRONOLOGIA DELLE MODIFICHE ALL'AMBIENTE ............................... 93
6 CONCLUSIONI ........................................... 94
7 APPENDICE ............................................... 95
7.1
CONTENUTO X3D D'ESEMPIO ............................................................ 95
8 BIBLIOGRAFIA ........................................... 97
iii
All'equilibrio.
iv
Introduzione e contesto
Rosario Santoro
1 INTRODUZIONE E
CONTESTO
1.1 La realtà aumentata e la realtà virtuale
Negli ultimi anni, la disciplina della Visione Artificiale ed Elaborazione di Immagini ha
apportato una serie di enormi contributi in ambito medico, sia in fatto di diagnosi sia di
mezzi.
Per quanto riguarda le diagnosi, basta citare le numerose tecniche di image processing
mediante le quali l'immagine ottenuta attraverso una lastra, un'endoscopia o una TAC, può
essere migliorata al fine di facilitare la rilevazione di occorrenze di certi artefatti.
In questa disciplina vi è una branca in particolare il cui sviluppo in questi tempi sta
subendo una forte spinta: la realtà aumentata e la realtà virtuale.
Figura 1.1 - Relazione tra l'ambiente reale, la realtà aumentata e la realtà virtuale [1]
Questi due ambiti sono in correlazione l'uno con l'altro. Come illustrato in Figura 1.1, non
si tratta di una distinzione netta ma di una misura di quanto la realtà osservata si fonde con
1
Rosario Santoro
informazioni e scenari prodotti esclusivamente da una macchina. A seconda di quanto una di
queste due componenti prevale sull'altra si ottiene la definizione per la scena osservata.
Ad esempio considerando un paio di occhiali sulle cui lenti vengono proiettate
informazioni come una scritta recante data e ora, si è di fronte ad un sistema di realtà
aumentata in quanto la provenienza della maggior parte dell'immagine percepita
dall'osservatore è naturale, a fronte delle poche informazioni prodotte sinteticamente (Figura
1.2).
Aggiungendo una quantità sempre maggiore di informazione digitale sulle lenti ci si
avvicina ad una configurazione di "virtualità aumentata"; portando questo procedimento agli
estremi e dunque rimuovendo tutta la scena naturale e visualizzando il 100% di informazioni
digitali si giunge alla definizione di realtà virtuale (Figura 1.3).
Questi dispositivi ricreano l'illusione della tridimensionalità proiettando contenuti
stereoscopici sulle lenti e imitando il funzionamento naturale del sistema visivo umano
(vedere 3.1.1).
Figura 1.2- La scena complessivamente percepita in un sistema di realtà aumentata1
1
http://www.ilbloggatore.com/2011-07-12/live-view-realta-aumentata-anche-sui-symbian/
2
Rosario Santoro
Figura 1.3 - Il visore di realtà virtuale impiegato in fase di test (Oculus Rift)
Tali dispositivi hanno applicazioni che spaziano dall'ambito videoludico (realtà virtuale)
ad attività quotidiane come la guida di un'automobile (realtà aumentata).
Un altro settore che beneficia dei progressi della tecnologia VR è quello
medico/riabilitativo. Recenti innovazioni permettono infatti ad un medico chirurgo di
operare un paziente nel modo meno invasivo possibile, servendosi di un visore a realtà
aumentata che mostra e aggiorna in tempo reale il modello tridimensionale di un organo del
paziente, guidando il bisturi del chirurgo lungo il tratto di incisione migliore (Figura 1.4).
Figura 1.4 - Applicazioni di realtà aumentata in ambito medico chirurgico2
2
http://www.medgadget.com/2013/08/augmented-reality-ipad-app-guides-surgeons-during-tumor-
removal.html
3
Rosario Santoro
Figura 1.5 - Un dispositivo di realtà aumentata mentre viene usato per alleviare il dolore e l'ansia durante
la sostituzione del bendaggio di un'ustione3
Esistono anche una serie di giochi con webcam4 sviluppati dall'Università dello Ulster il
cui scopo è la riabilitazione in seguito ad infarto. Questi giochi sono stati creati per
incoraggiare movimenti marcati del tronco del corpo usando una tecnologia webcam a basso
costo e un comune PC. I giochi conservano un profilo del giocatore in modo tale che il gioco
stesso possa adattarsi dinamicamente per fornire un livello appropriato di sfida per l'abilità
motoria del paziente.
Risulta di particolare efficacia l'utilizzo di giochi poichè il paziente durante la
riabilitazione ha una tendenza allo scoraggiamento. Essendo la riabilitazione un processo
intensivo, frequente e impegnativo bisogna motivarlo permettendogli di riabilitarsi mentre
gioca [2].
Nel caso in cui si tratti di un bambino, egli può trarre beneficio dalla distrazione dalla
particolare operazione che sta subendo giocando servendosi di sistemi di realtà virtuale [3].
1.2 Stato dell'arte
La realtà virtuale è ben conosciuta per i suoi impieghi nei simulatori di volo e nei giochi.
Comunque, questi sono solo due dei molti modi in cui essa è impiegata oggigiorno.
3
4
http://cirrie.buffalo.edu/encyclopedia/en/article/119/
Un esempio è "Coleraine" (http://www.youtube.com/watch?v=1_QH1a0AziA)
4
Rosario Santoro
Un utilizzo diverso è la rilevazione finalizzata all'eliminazione delle situazioni di stress.
Sono già state in parte esplorate le tecniche di realtà virtuale finalizzate al rilevamento di
condizioni di stress. Nel bando ALBO5 della Regione Toscana, veniva previsto l'utilizzo
della realtà virtuale non immersiva per la valutazione delle situazioni di stress in ambiente
lavorativo [4].
Il progetto ALBO si proponeva di verificare l'applicabilità delle tecnologie ICT per la
costruzione di ambienti di lavoro virtuali e "immersivi" finalizzati alla rilevazione, al
monitoraggio e al miglioramento continuo del benessere organizzativo nelle imprese
industriali e non della Toscana. Il concetto di benessere oggetto della ricerca è strettamente
correlato alla prevenzione dello stress e dei rischi psico-sociali emergenti o latenti sui luoghi
di lavoro.
1.3 Il contesto
Il progetto propone metodologie e strumenti per definire nuovi approcci nella
progettazione di ambienti di vita dedicati a soggetti con capacità residua nelle fasi iniziali
della perdita di autonomia.
Il progetto, nel suo insieme, prevede la realizzazione di un sistema per la misura
oggettiva della capacità residua che permetterà di determinare in modo oggettivo il deficit
cognitivo e/o sensoriale. La misura della capacità residua costituirà un requisito in input per
la configurazione di un ambiente di vita sostenibile che potrà essere adeguato per
assecondare l’evoluzione del deficit. Ciascun ambiente di vita deve essere analizzato e
riqualificato, con particolari accorgimenti architettonici e di design, per ottenere un sistema
adattabile in funzione del deficit misurato. Sarà dotato di strumenti attivi (domotica e ausili)
e passivi (elementi strutturali e accessori di ambiente) che miglioreranno le capacità del
soggetto di sopperire al deficit. Il progetto prevede la realizzazione di un laboratorio
dimostrativo nel quale eseguire i test necessari per la validazione direttamente sugli utenti
finali, valutando così la qualità della progettazione.
5
Ambienti di Lavoro virtuali per la rilevazione del Benessere Organizzativo
5
Rosario Santoro
Il progetto ha come principale obiettivo quello di mettere in atto una procedura di
progettazione/riqualificazione di ambienti domestici e assistenziali al fine di consentire un
adattamento dinamico e personalizzato degli stessi a seconda del contesto e delle capacità
cognitive/motorie residue del paziente in questione.
Il termine “riqualificazione” porta con sé l’enorme vantaggio di non richiedere
necessariamente la costruzione ad-hoc di strutture, bensì di modificare quelle esistenti con
opportuni interventi a costi non troppo elevati. L’adattamento dell’ambiente avviene sia
mediante accorgimenti architettonici (arredi, infissi, ….) sia attraverso la definizione di una
sequenza di scenari ambientali multisensoriali preimpostati, costruiti sulle particolari
esigenze del paziente: l’idea è quindi quella di seguire nel tempo l'evoluzione della patologia
del paziente stesso intervenendo attraverso la modifica di alcuni dei principali parametri
inerenti il comfort ambientale.
A fronte di questa premessa, il progetto può essere realizzato in tre fasi principali:
1. Progettazione e generazione delle specifiche progettuali e di configurazione
ambientale (paragrafo 1.3.1);
2. Progettazione, attuazione e realizzazione dell’ambiente domotico multisensoriale
(paragrafo 1.3.2);
3. Realizzazione di una piattaforma tramite la quale monitorare e controllare gli alert
generati volontariamente attraverso un meccanismo di feedback basato su ADL6;
questi alert possono in alternativa essere generati automaticamente attraverso la
piattaforma domotica (paragrafo 1.3.3).
1.3.1 Prima fase
La prima fase di progettazione e generazione delle specifiche progettuali, anche a valle di
campagne di acquisizione di geometrie tridimensionali degli ambienti oggetto di
modellazione, prevede l’utilizzo di tecniche di realtà virtuale/aumentata mediante la quale è
possibile immergere il paziente in scenari virtuali dando allo stesso la percezione di trovarsi
nella realtà: in questo contesto viene valutata la percezione emotiva, di piacevolezza
6
Activities of Daily Living
6
Rosario Santoro
mediante l’utilizzo di sensori tipo EEG e della risposta simpatico-cutanea provata durante
l’esplorazione dell’ambiente virtuale mediante l’utilizzo di sensori e tracciati ECG e EMG.
In questo modo è possibile percepire in maniera oggettiva e quantificata la gradevolezza o
sgradevolezza/fastidio che un paziente sperimenta per esempio in un ambiente più o meno
luminoso o rumoroso, o dinanzi ad una porta colorata, o ad una vetrata che cambia colore.
L'output di questa fase è la produzione di una serie di specifiche progettuali necessarie
alla fase di attuazione e realizzazione dell’ambiente domotico: si tratta dunque di sistemi di
fonoassorbenza,
servomeccanismi
per
operazioni
di
sollevamento,
abbassamento,
orientazione, regolazione delle tende, apertura/chiusura/modulazione dell'angolazione di
finestre, serrande e porte.
1.3.2 Seconda fase
L'output della prima fase costituisce la base per l’implementazione di un adeguato
sistema di domotica avanzata. Questo sistema di domotica avanzata sarà in grado di
applicare le caratteristiche dello scenario prescelto all’ambiente controllato mediante i
classici meccanismi di retroazione e di inseguimento delle variabili di controllo tipici
dell’automazione. Questo tipo di domotica consentirà pertanto, in aggiunta alla domotica
classica, di adeguarsi in maniera automatica e proattiva nel tempo alle esigenze psicofisiche
del soggetto fragile.
1.3.3 Terza fase
L’ultima fase prevede la realizzazione di una piattaforma che svolga le tipiche funzioni di
una centrale operativa e che si occupi della gestione di sistemi per il calcolo dell’indice di
ADL e per la memorizzazione delle informazioni veicolate mediante l’utilizzo di
applicazioni mobile. Il paziente/soggetto target potrà pertanto quotidianamente effettuare
segnalazioni ad un sistema centrale che prenderà decisioni supportate da esperti medici.
Inoltre l'utilizzo della piattaforma consentirà l'offerta di un ulteriore servizio che tenendo
conto della condizione contingente del soggetto (risposta al piano farmacologico, impreviste
complicanze del decorso della condizione patologica, effetti collaterali cronicizzanti delle
terapie continuative) sarà in grado di fornire meccanismi di alert, ovvero modificare le
condizioni di regolazione automatica proposte dal sistema domotico, sulla base delle
indicazioni di specialisti medici in grado di comprendere la condizione del soggetto target.
7
Rosario Santoro
1.4 Sensoristica
1.4.1 Elettrocardiogramma (ECG)
Al contrario delle contrazioni dei muscoli scheletrici volontari che sono comandate
direttamente dal sistema nervoso, le contrazioni del muscolo del cuore iniziano
internamente, nelle fibre muscolari stesse e sono soltanto accelerate o rallentate dal sistema
nervoso (e da una varietà di fattori chimici). Il processo coinvolge movimenti di ioni entranti
e uscenti dalle cellule muscolari e la polarizzazione e depolarizzazione cellulare [5].
Posizionando una serie di sensori in determinate posizioni sulla superficie del corpo (Figura
1.6), è possibile tracciare nel tempo l'andamento delle differenze di potenziale da un sensore
ad un altro: il tracciato risultante è un elettrocardiogramma (ECG, anche noto come EKG,
Figura 1.8).
Figura 1.6 - Posizione degli elettrodi sul tronco del
paziente (non sono raffigurati quelli sulle gambe)
Figura 1.7 - Differenze di potenziale delle tracce I,
II e III in un ECG (in senso antiorario, partendo da
quella disposta orizzontalmente)
8
Rosario Santoro
Figura 1.8 - Esempio di tracciato di un ECG a 12 tracce (12-lead).
1.4.2 Elettroencefalogramma (EEG)
L'identificazione di un EEG normale si deduce sul riconoscimento di un EEG anormale,
sulla conoscenza delle normali variazioni delle forme d'onda e sulla loro evoluzione dalla
gioventù alla vecchiaia.
L'encefalogramma è una misura unica e valutabile della funzione elettrica del cervello. È
un mezzo grafico delle differenze di potenziale tra due parti del cervello registrata nel
tempo. L' EEG riguarda lo studio di questi segnali elettrici che sono generati dal cervello. L'
EEG extracraniale fornisce un sunto ampio dell'attività elettrocerebrale attraverso entrambi
gli emisferi del cervello. L'EEG intracraniale fornisce invece un EEG specifico registrando
direttamente dal cervello attraverso elettrodi impiantati chirurgicamente in specifiche regioni
del cervello. Può essere così rivelata informazione su una disfunzione diffusa o locale
cerebrale, come la presenza di scariche epilettiformi interictali (Interictal Epileptiform
Dischagers, IEDs), o sequenze di particolare importanza.
Per l'interpretazione di un EEG anormale bisogna prima comprendere i criteri necessari
per la definizione dei pattern normali. Mentre un normale EEG non esclude una diagnosi
clinica (come l'epilessia), un'occorrenza insolita su un EEG può essere a supporto di una
9
Rosario Santoro
diagnosi, può indicare una disfunzione cerebrale o può non avere niente a che fare con la
ragione dello studio (per esempio, un mal di testa).
I segnali elettrici si creano infatti quando cariche elettriche si muovono nel sistema
nervoso centrale. Tali segnali sono nell'ordine dei µV. [6].
Figura 1.9 - Il casco con elettrodi attraverso il quale viene misurata l'attività cerebrale (EEG)
Figura 1.10 - Posizionamento degli elettrodi nel sistema 10-20 (punti neri) e nel sistema 10-10 (punti neri e
bianchi) in un EEG. Le sigle su ciascun punto identificano univocamente una regione del cranio.
10
Rosario Santoro
Le registrazioni EEG dal cuoio capelluto mostrano la differenza di potenziale tra due
differenti siti sulla testa sopra la corteccia cerebrale che è più vicina all'elettrodo che sta
registrando. Durante l'uso normale, i potenziali elettrici sono acquisiti indirettamente dalla
superficie del cuoio capelluto e incorporano l'analisi delle forme d'onda, delle frequenze, dei
voltaggi, della morfologia e topografia. Questi potenziali vengono acquisiti per via digitale
attraverso un certo numero di elettrodi disposti tra loro in accordo allo standard
internazionale 10-20 che prevede una suddivisione in regioni ampie dal 10% al 20%, in
ciascuna delle quali verrà posizionato un elettrodo. Una misura clinicamente accettabile
prevede almeno 21 elettrodi. Recentemente è stato messo a punto il nuovo standard 10-10
che prevede un maggior numero di elettrodi e dunque più vicini tra loro, tuttavia il più
diffuso resta il 10-20.
Per la corretta lettura di un tracciato EEG come quello in Figura 1.11, quando stimolato
da interventi esterni come il progetto di questa tesi si propone di realizzare, è necessaria una
sincronizzazione fine (al microsecondo) tra la lettura e le variazioni degli input forniti al
paziente a mezzo della realtà virtuale. È possibile soddisfare questo requisito tramite
realizzazione di un sistema real-time (soft realtime) oppure tramite la registrazione di
marche temporali rispetto ad un riferimento comune (per esempio l'orario di un server NTP)
e in fase di studio dei tracciati tenere presente l'eventuale sfasamento.
Figura 1.11 - Tracciato d'esempio di un EEG
11
Rosario Santoro
1.4.3 Elettromiogramma (EMG)
L'elettromiografia è il test che verifica lo stato di salute dei muscoli e dei nervi che
controllano quei muscoli. Il test è condotto inserendo dei sottili aghi nei muscoli: questi aghi
registrano l'attività elettrica prodotta dai muscoli. Dopo il posizionamento degli elettrodi può
venir chiesto al soggetto osservato di flettere il braccio e l'attività elettrica visualizzata su
monitor fornisce informazioni circa l'abilità del muscolo di rispondere quando i nervi dei
muscoli sono stimolati [7].
Figura 1.12 - Esempio di elettromiografia (EMG) ad un braccio.
Dunque un EMG produce una lettura nel momento in cui il muscolo cui gli elettrodi sono
collegati compie un movimento e tale segnale è direttamente proporzionale allo sforzo
compiuto.
Una volta chiarito lo scenario di un EMG ci si imbatte purtroppo in un'incompatibilità
con il progetto. Un EMG misura lo sforzo dei muscoli ai quali è collegato, ma il soggetto
osservato durante la somministrazione dell'ambiente virtuale tramite il visore non compie
alcun movimento sotto sforzo. Nella configurazione attuale, infatti, il paziente è considerato
come entità statica nella realtà e il movimento più evidente che può compiere è la rotazione
della testa per esplorare il mondo virtuale in cui è immerso. Date queste premesse, un EMG
risulta del tutto inutile ed è stato dunque escluso.
Eventualmente in configurazioni future, considerando l'inclusione di dispositivi quali il
Leap Motion (si rimanda ai paragrafi 3.3 e 5.2), sarà possibile incrementare l'attività del
12
Rosario Santoro
paziente permettendogli, per gradi, un livello di interazione sempre maggiore con il mondo
virtuale che gli viene presentato.
Esempi di interazioni sono: la possibilità di indicare un oggetto con un dito, proiettando
una linea che permetta all'operatore medico di capire rapidamente a quale oggetto il paziente
si riferisca; la possibilità di muoversi nell'ambiente virtuale (al momento è possibile solo
osservare in ogni direzione); la possibilità di interagire con degli oggetti presenti nella scena,
come tende, porte e finestre.
1.4.4 FIT
Il Laboratorio di Informatica Industriale del Politecnico di Bari in collaborazione con
AMT Services S.r.l. nell'ambito del PON “Sviluppo di un Sistema di Rilevazione della
Risonanza (SS-RR)” (contesto FIT, Fondo rotativo per l'Innovazione Tecnologica) ha
recentemente sviluppato un sistema il cui scopo è il riconoscimento degli stati d'animo di
una persona osservando e studiando l'espressione del volto, il tono della voce e la gestualità,
servendosi di webcam e microfoni.
Ai fini del progetto oggetto di questa tesi è stato considerato il riutilizzo di due di questi
tre moduli: il rilevamento dell'espressione facciale è stato tralasciato poiché non è possibile
inquadrare il volto del soggetto, completamente ostruito dalla presenza del visore virtuale
Oculus Rift.
Gli output di questi moduli software andranno ad affiancare la sensoristica medica EEG
ed ECG precedentemente considerata.
1.4.5 La condizione di stress e suo rilevamento
La condizione di stress psicofisico di un soggetto può trovare riscontro nelle letture dei
tracciati EEG ed ECG.
In un'ottica generale, è stata già dimostrata la possibilità di rilevare una certa quantità di
emozioni attraverso la lettura e l'interpretazione di un elettroencefalogramma e tali stati
d'animo includono la sensazione di disagio e stress [8].
Recentemente, è stata coinvolta in queste indagini anche l'elettrocardiografia: infatti, è
stata studiata la dipendenza tra caratteristiche oggettive di un ECG e la presenza di stress
mentale nel soggetto osservato [9]. Esempi di queste caratteristiche sono le variazioni a
breve termine delle misurazioni della variabilità del ritmo cardiaco (Heart Rate Variability,
HRV) e la variabilità morfologica (MV), analizzate sia nel dominio del tempo sia della
13
Rosario Santoro
frequenza. I risultati dello studio di Costin, Rotariu & Pasarica hanno rivelato infatti che le
misure HRV denominate mHR e mRR, le VLF/LF/HF normalizzate, differenze tra la LF
normalizzata e la HF normalizzata e il valore SVI sono metriche effettive per il rilevamento
dello stress mentale [9]. Risultati migliori sono stati ottenuti usando l'analisi MV e un
modulo per il supporto alle decisioni basato su entrambi i metodi, HRV ed MV.
Un'altra caratteristica che può fornire una misura del grado di stress di un soggetto è la
risposta simpatico cutanea (Sympathetic Skin Response, SSR).
1.5 L'intervento del candidato nel progetto
Nel presente lavoro di tesi, il candidato ha affrontato lo studio, la progettazione e lo
sviluppo del prototipo del sistema di realtà virtuale ipotizzato nel paragrafo 1.3, mediante il
quale somministrare ad un soggetto affetto da deficit cognitivi e/o motori nello stadio
iniziale, una replica virtuale e fedele dei suoi ambienti quotidiani e permettergli di interagire
con un operatore che in tempo reale possa apportare cambiamenti a tali ambienti.
Questi cambiamenti sono volti a facilitare le operazioni più comuni la cui possibilità per
il soggetto affetto da certi tipi di disturbi va man mano riducendosi: si parla dunque di
tracciamento di percorsi luminosi verso stanze della casa con un'importanza particolare
(come i sanitari o la cucina o la stanza da letto), di aggiunta di meccanismi di oscuramento
automatici alle finestre per regolare nell'arco della giornata la quantità di luce che entra
nell'appartamento o ancora la riproduzione di suoni particolari in alcuni punti della casa.
L'obiettivo di queste modifiche è, in ultima analisi, ridurre la quantità di stress nel
soggetto quando vive i propri spazi vitali. La ricerca di questa condizione di minor stress è
guidata dall'interpretazione degli output di sensori quali elettroencefalogramma (EEG) ed
elettrocardiogramma (ECG). Una volta individuata la configurazione migliore, le modifiche
introdotte nell'ambiente sintetico vengono realizzate con dispositivi domotici nella realtà.
Considerando il contesto descritto in questo capitolo, l'intervento del candidato riguarda
la prima fase del progetto (paragrafo 1.3.1), cioè il modulo dell'acquisizione e ricostruzione
del mondo virtuale e il sistema di immersione e somministrazione della realtà virtuale.
14
Panoramica del sistema
Rosario Santoro
2 PANORAMICA DEL
SISTEMA
2.1 Panoramica di alto livello
Figura 2.1 - Schematizzazione del progetto come sistema a retroazione
La somministrazione dell'ambiente virtuale al paziente, l'analisi dei suoi parametri vitali e
la conseguente modifica della configurazione del mondo sono operazioni cicliche ed
effettuate in sequenza, a partire da una configurazione iniziale (la configurazione reale
dell'appartamento) con l'obiettivo di raggiungere una certa condizione d'equilibrio a regime.
Tali caratteristiche riportano alla mente le caratteristiche salienti di un sistema
retroazionato, ottica attraverso la quale è stato progettato il sistema (Figura 2.1).
15
Rosario Santoro
2.2 Ciclo esemplare di funzionamento
Viene ora esposto un ciclo completo di funzionamento del sistema dal punto di vista del
livello applicativo: nei capitoli 3 e 4 entrambi i moduli verranno analizzati con maggior
dettaglio.
Figura 2.2 - Diagramma delle componenti e delle loro interazioni.
È possibile notare le due macrofasi ("offline" e "online") separate da una linea verde.
I blocchi con i bordi rossi sono le componenti singole che saranno in esecuzione
16
Rosario Santoro
Tenendo presente la Figura 2.2, il funzionamento dell'intero sistema è suddiviso in due
macrofasi: la parte offline e la parte online, eseguite temporalmente in questo ordine. Nella
macrofase offline si effettuano acquisizioni dell'ambiente reale e costruzione dell'ambiente
virtuale, mentre nella macrofase online avviene la somministrazione dell'ambiente virtuale al
soggetto osservato sotto la supervisione dell'operatore medico.
È importante notare che in entrambe tali fasi, è prevista la presenza di un operatore
umano. Nella macrofase offline questa figura sarà un operatore/programmatore specializzato
nella costruzione di ambienti virtuali, che abbia particolare familiarità con il motore di gioco
Unity 3D e gli strumenti di acquisizione, così come previsto nel paragrafo 3.1.3. Nella
macrofase online, tale operatore afferisce invece al settore medico (in particolare
neurologico), in quanto è suo compito la modifica in tempo reale della configurazione
dell'ambiente somministrato al soggetto sulla base dei valori forniti dalla sensoristica medica
EEG ed ECG e moduli FIT (vedere rispettivamente i paragrafi 1.4 e 1.4.4).
2.2.1 La macrofase offline
La prima fase tratta dell'acquisizione dell'ambiente vitale del paziente, sia esso il suo
appartamento o la struttura ricettiva specializzata che lo accoglie.
Le acquisizioni effettuate sono di due tipi: la distinzione giace nel ruolo che gli oggetti
acquisiti rivestiranno nella macrofase online. Infatti, tenendo a mente che lo scopo del
sistema e stimolare il paziente apportando modifiche al suo ambiente, alcuni oggetti presenti
al suo interno dovranno poter subire tali modifiche e altri oggetti invece rimarranno invariati
nel tempo.
Gli oggetti che non subiranno variazioni sono ovviamente la pianta dell'appartamento, la
posizione delle finestre e tutte quelle modifiche che un sistema domotico non è per sua
natura in grado di attuare. Tutti questi oggetti potranno essere dunque acquisiti assieme alla
stanza intera, andando a formare un'unica nuvola di punti immutabile, che tra l'altro andrà a
costituire i confini invalicabili dell'ambiente virtuale. Ad ogni modo, ciò non preclude
affatto la possibilità di acquisire in due momenti distinti stanza e oggetti immutabili al suo
interno: una delle ragioni a favore di quest'ultimo approccio è la maggior qualità di
un'acquisizione singola di un oggetto.
La seconda tipologia di acquisizioni riguarda quegli oggetti di cui si intende permettere la
modifica a runtime, durante la somministrazione dell'ambiente al paziente. Questi oggetti,
17
Rosario Santoro
detti anche "stimoli", è opportuno che vengano acquisiti separatamente dal resto
dell'ambiente poichè nel motore grafico dovranno costituire una mesh distinta alla quale i
metodi di modifica invocati a runtime devono potersi riferire in maniera univoca.
Una volta concluso il sopralluogo per l'acquisizione, si prosegue alla fase di creazione
dell'ambiente virtuale. Mediante il software Unity 3D si importano le nuvole di punti
dell'ambiente, degli oggetti e degli stimoli, disponendole nelle stesse posizioni dei rispettivi
oggetti reali. Alcuni degli oggetti potrebbero richiedere un raffinamento grafico, come per
esempio una riduzione delle irregolarità della superficie di una parete.
Il risultato è un surrogato dell'ambiente reale, pronto per la navigazione virtuale.
Bisogna ora considerare i dispositivi fisici di output che verranno impiegati poichè questa
scelta influisce sul tipo di esportazione dell'ambiente virtuale in Unity 3D. Nel caso di
output su un dispositivo di realtà virtuale infatti la schermata sarà suddivisa in due parti
ciascuna contenente immagini per i rispettivi occhi; impiegando un normale monitor invece
l'esportazione sarà quella comune, con un unico riquadro.
Il candidato ha previsto la possibilità per l'operatore medico di visualizzare in anteprima
le modifiche da lui proposte sul mondo virtuale prima che queste vengano somministrate al
paziente. Considerato ciò, risulta che gli output visivi del sistema debbano essere
necessariamente due: l'output su visore virtuale stereoscopico (paziente) e l'output su
schermo in una finestra normale (l'operatore medico).
Dal punto di vista dell'implementazione, ciò richiede una doppia esportazione
dell'ambiente virtuale in Unity 3D ciascuna delle quali sarà basata su un modello comune
del mondo reale.
L'ultimo passo della macrofase offline è la creazione di una descrizione degli stimoli
presenti nel mondo virtuale da comunicare all'interfaccia grafica di cui disporrà l'operatore
medico (vedere paragrafo 3.4.4).
18
Rosario Santoro
2.2.2 La macrofase online
Figura 2.3 - Funzionamento di alto livello della macrofase online
La macrofase online ha luogo nel momento della somministrazione dell'ambiente virtuale
al paziente, sotto la supervisione di un operatore medico che ha la facoltà di modificare
alcune caratteristiche degli stimoli disponibili sulla base delle letture della sensoristica
medica collegata al paziente.
La prima operazione di questa macrofase è il caricamento della descrizione degli stimoli
nell'interfaccia grafica in modo tale che tutti i componenti del sistema ora lavorino e si
scambino messaggi tenendo presente il medesimo modello e la medesima configurazione del
mondo.
Successivamente l'operatore medico disporrà di un elenco di stimoli con le rispettive
proprietà modificabili; si potranno variare alcuni di questi parametri e scegliere se renderli
effettivi sul modello, visualizzandoli su tutte le viste disponibili, o se saggiarne solo
un'anteprima sulla propria macchina.
Man mano che gli stimoli variano, il paziente risponderà in modo diverso e i suoi
parametri vitali varieranno in accordo. Si suppone che dopo una certa quantità di modifiche
dell'ambiente virtuale venga raggiunta una situazione di equilibrio in cui si è individuato una
configurazione del mondo tale che produca la quantità minore di stress nel soggetto
19
Rosario Santoro
osservato. In questa sede si dà per certa l'esistenza almeno di un minimo locale nella
quantità totale di stress nel paziente.
In seguito, la configurazione dell'ambiente verrà analizzata da esperti nel settore
domotico che indicheranno il modo più efficiente di rendere effettive le modifiche a cui si è
pervenuti.
2.3 Architettura del sistema
Presentato il sistema da un punto di vista applicativo, viene ora affrontata una
presentazione dello stesso dal punto di vista del livello implementativo e progettuale.
In Figura 2.4 è rappresentata l'architettura del sistema, la struttura a stack di ciascuna
delle componenti e le interazioni tra queste. Di questi quattro stack, lo stack disegnato in
basso si riferisce alla macrofase offline, mentre i tre superiori rappresentano la macrofase
online del progetto.
Figura 2.4 - Vista globale degli stack delle componenti e delle loro interazioni
Una vista della struttura di un sistema come una pila (stack) è un artificio di progettazione
e rappresentazione molto comune nell'ambito dell'Information Technology. Esso si presenta
come una sequenza di moduli interconnessi e indipendenti fra loro: ciascuno di questi strati
(layer) ha una funzione ben specifica che non si sovrappone a nessuno degli altri layer.
Solitamente, procedendo dal basso verso l'alto in uno stack, il livello di astrazione dei dati si
eleva: prendendo come esempio la pila ISO/OSI (Figura 2.5), si passa dai byte (o bit) del
20
Rosario Santoro
livello fisico in basso, fino ad un file audio o pagina web al livello applicativo, strato che si
occupa di interagire con l'utente, passando attraverso una serie di rappresentazioni
intermedie come frame, pacchetti e stream.
Figura 2.5 - La pila International Organization for Standardization Open Systems Interconnection model
(stack ISO/OSI)7
In maniera simile, gli stack progettati dal candidato in Figura 2.4, individuano la
sequenza di moduli indipendenti che svolgono il compito assegnato.
Il primo dettaglio implementativo da descrivere è l'architettura scelta per il sistema nella
macrofase online.
Come spiegato nel paragrafo 4.1.2, la modifica apportata dal candidato al design pattern
Model-View-Controller (MVC), ovvero la trasformazione della componente View in un
gateway per più di una View, permette l'aggiunta e la rimozione di visualizzatori durante
l'esecuzione, a prescindere che si tratti di un'anteprima in una finestra normale su schermo o
di un visore di realtà virtuale.
La comunicazione tra visualizzatori e l'interfaccia operatore avviene tramite protocollo
TCP (Transmission Control Protocol). La libertà d'impostazione degli indirizzi IP non pone
vincoli sulla configurazione dal punto di vista dei tier, ovvero le macchine fisiche che
compongono l'architettura dell'intero sistema.
7
Fonte: Wikipedia
21
Rosario Santoro
Figura 2.6 - Modalità di connessione tra un visualizzatore (sia anteprima sia stereoscopico) e l'interfaccia
dell'operatore
La Figura 2.6 indica le tre possibili configurazioni per una connessione tra l'interfaccia
operatore e un visualizzatore.

localhost: il visualizzatore e l'interfaccia operatore sono in esecuzione sulla stessa
macchina, costituendo così un'architettura monolitica (one-tier);

Local Area Network: il visualizzatore è collegato nella stessa rete locale della GUI
operatore, dunque le macchine coinvolte diventano due (two-tier);

Rete esterna: estendendo la connessione oltre i confini di una rete locale, è possibile
collegare in remoto un visualizzatore all'interfaccia grafica (sempre two-tier). Questa
configurazione presenta un ulteriore beneficio, poichè non obbliga paziente e
operatore ad essere presenti nella stessa stanza.
A prescindere da questo grado di libertà, il sistema rimane in una chiara configurazione
client-server, dove a fungere da server è l'interfaccia operatore in Qt mentre i client sono
qualsiasi visualizzatore che si connetta ad esso, a prescindere se stereoscopico o meno.
22
Rosario Santoro
Modulo offline: modellazione 3D
3 MODULO OFFLINE:
MODELLAZIONE 3D
3.1 L'acquisizione
3.1.1 Teoria sull'acquisizione
3.1.1.1 La stereoscopia
Il sistema percettivo umano riesce a ricostruire la tridimensionalità attraverso un processo
chiamato stereopsi, mediante il quale si interpretano i cosiddetti indizi monoculari e
binoculari [10] (anche noti rispettivamente come pittorici e fisiologici) riuscendo a
ricostruire la tridimensionalità. Indizi monoculari sono l'interposizione, la grandezza relativa
e familiare, gli indizi prospettici, l'ombreggiatura e il movimento relativo. Indizi binoculari
sono invece la convergenza dei due globi oculari e la disparità oculare.
La creazione di contenuti multimediali tridimensionali si basa sull'imitazione del
funzionamento della vista umana: in fase di acquisizione ci si serve di due telecamere
orientate e distanziate opportunamente, una delle quali catturerà immagini da mostrare
all'occhio sinistro e l'altra le immagini da mostrare all'occhio destro. In fase di riproduzione,
si dovrà fare uso di un sistema che permetta di far ricevere l'immagine sinistra all'occhio
sinistro e l'immagine destra all'occhio destro: tale tecnica è chiamata parallasse [10].
Il cervello mediante la stereopsi ricaverà l'informazione sulla profondità dei diversi
oggetti nella scena. Le tecniche di rappresentazione e di separazione in fase di fruizione
sono diverse. Il metodo più semplice è quello dell'anaglifia [11], che consiste nel separare i
due canali (flusso sinistro e flusso destro) filtrandoli mediante due colori complementari fra
di loro (come rosso e ciano, ma non solo): lo spettatore dovrà indossare occhialini con lenti
dello stesso colore dei filtri. Tale metodo è semplice ma penalizza di molto la percezione
cromatica e l'esperienza utente. Successivamente è stata sperimentata una tecnica basata
23
Rosario Santoro
sulla polarizzazione. I due flussi venivano proiettati con filtri polarizzatori con direzioni di
polarizzazione perpendicolari [10] fra loro. L'utente avrebbe dovuto indossare occhiali con
lenti polarizzate in modo adeguato. Siccome la separazione dei canali, in accordo con la
legge di Malus, dipendeva dall'orientamento degli occhialini rispetto allo schermo, si è
pensato di impiegare la tecnica della polarizzazione circolare [10], assegnando quella
sinistrorsa ad un occhio e quella destrorsa all'altro. In entrambe le modalità di
polarizzazione, è necessario un monitor con due pannelli distinti e sovrapposti la cui
emissione è polarizzata in modo adeguato, oppure in caso di proiezione è necessario un tipo
speciale di schermo, detto silverscreen, in grado di conservare la polarizzazione dell'onda
che lo colpisce. Si è passati poi alle tecniche di separazione attiva [12]. Impiegando monitor
con frequenza di proiezione raddoppiata vengono proiettati in modo alternato il frame
sinistro e il frame destro. Gli occhialini dello spettatore sono dotati in questo caso di filtri
otturatori finemente sincronizzati con il monitor. Questo metodo sfrutta la persistenza
retinica dell'occhio umano. Il costo però sale.
Un'innovazione interessante è stata il monitor autostereoscopico [10] capace di fornire
l'illusione della profondità senza che lo spettatore indossi alcun paio di occhiali ma
sfruttando la barriera di parallasse o una rete lenticolare. L'attuale frontiera della
sperimentazione è il multiview [13] che prevede l'acquisizione di più di due flussi della
stessa scena in modo tale da permettere una percezione del 3D in modo autostereoscopico da
più di una posizione (che è uno svantaggio della tecnica precedente).
Una tecnica di natura diversa è l'utilizzo di una sola vista, quindi un solo flusso di
acquisizione, a cui viene associata un'immagine in scala di grigi solitamente acquisita con
una profondità in bit minore (8 bit, per esempio), in cui ciascun pixel è tanto più scuro
quanto più vicino è un certo punto della scena [14]. Queste immagini possono essere create
in due modi diversi:

si estrapola l'informazione della profondità dalla singola vista già acquisita con il
normale sensore RGB;

si utilizzano speciali telecamere in grado di produrre le cosiddette mappe di
profondità (vedere 3.1.1.2).
3.1.1.2 Mappe di profondità
Una mappa di profondità (Figura 3.1) è un'immagine monocromatica (o un canale di
un'immagine a più canali) in cui ogni pixel non è, come in una normale acquisizione, la
24
Rosario Santoro
somma dei contributi di raggi luminosi incidenti sullo stesso elemento della matrice di
transistor del sensore, ma fornisce una misura della distanza dal sensore fino all'oggetto cui i
punti catturati da quel pixel appartengono.
Figura 3.1 - Un esempio di mappa di profondità in cui è possibile individuare
un oggetto in primo piano (foreground) e uno sfondo (background). L'intensità del pixel e la distanza
possono essere direttamente o inversamente proporzionali, a seconda del sensore.
L'informazione sulla distanza può essere ottenuta con due diverse tecniche.
La prima si serve di un cluster di emettitori infrarosso che emettono una certa quantità di
raggi IR secondo un pattern uniforme: i raggi proiettati vengono riflessi dagli oggetti che
colpiscono e vengono catturati da un sensore infrarosso (Figura 3.3). A seconda della
distanza dell'oggetto sul quale i punti incidono, la densità dei punti catturati in ricezione
cambierà. Nel dettaglio, la densità dei punti riflessi su una superficie e la distanza della
superficie stessa dal sensore sono direttamente proporzionali.
La seconda tecnica continua ad utilizzare emettitori IR ma si basa sul concetto di tempo
di volo (Time Of Flight, TOF). Nella cattura di un singolo frame, un illuminatore infrarosso
emette un singolo impulso infrarosso e questi raggi vengono riflessi dagli oggetti su cui
incidono. Il sensore infrarosso in ricezione è dotato di un otturatore controllato molto rapido.
L'impulso IR riflesso è modificato dalla struttura della scena e quest'informazione può essere
estratta combinando il segnale riflesso con l'otturatore rapido. Dopo la normalizzazione, i
valori misurati di intensità possono essere interpretati come valori di profondità [15].
25
Rosario Santoro
(a)
(b)
Figura 3.2 - L'ASUS Xtion (a) e l' ASUS PrimeSense (b)
Figura 3.38 - Il pattern di fasci luminosi infrarossi proiettati dall'emettitore IR.
Si noti la differenza di densità di punti a seconda della distanza dell'oggetto sul quale incidono.
3.1.1.3 3D laser scanning
La scansione laser 3D può essere realizzata con approcci basati su differenti principi di
cattura, alcuni ideali per una scansione a corto raggio, altri più indicate per raggi mediolunghi.
Rientrano nella categoria dei laser scanner a corto raggio (distanza focale minore di un
metro) i laser scanner 3D a triangolazione e laser scanner 3D a luce strutturata; le tecnologie
per i laser scanner a medio-lungo raggio sono impulsi laser a tempo di volo e a spostamento
di fase.
8
Foto di Mattew Fisher (http://graphics.stanford.edu/~mdfisher/Kinect.html)
26
Rosario Santoro
Figura 3.4 - Percorso del fascio di luce in un laser scanner triangolatore
Figura 3.5 - Calcolo della distanza in un laser scanner 3D a triangolazione
I laser scanner a triangolazione (Figura 3.5) usano un raggio laser o un punto laser per
scansionare un oggetto. Un sensore riceve la luce del laser riflessa dall'oggetto e mediante la
triangolazione trigonometrica il sistema calcola la distanza dell'oggetto dallo scanner.
La distanza tra la sorgente laser e il sensore e l'angolo tra il laser e il sensore sono rilevate
con grande precisione. Quando il raggio laser si riflette sull'oggetto scansionato, il sistema
può risalire all'angolo con il quale esso incide sul sensore e da lì alla distanza dalla sorgente
laser alla superficie dell'oggetto.
27
Rosario Santoro
Figura 3.6 - Laser scanner a luce strutturata
Anche gli scanner a luce strutturata (solitamente bianca o blu) usano la triangolazione
trigonometrica ma invece di misurare la luce del laser questi sistemi proiettano una serie di
pattern lineari sull'oggetto (per esempio, una serie di righe parallele). Successivamente,
esaminando i bordi di ciascuna linea del pattern riflesso e catturato, viene calcolata la
distanza dello scanner dalla superficie dell'oggetto. Essenzialmente la telecamera invece di
osservare una linea laser, osserva il bordo di un pattern proiettato e ne calcola la distanza in
modo simile.
Figura 3.7 - Laser scanner a tempo di volo di un impulso laser
Gli scanner a impulsi laser, anche noti come scanner a tempo di volo, sono basati sul
concetto che la velocità della luce è nota con estrema precisione9, quindi se si conosce il
tempo impiegato dal raggio laser a raggiungere un oggetto e a tornare indietro al sensore, si
può dedurre la distanza di quell'oggetto. Questi sistemi usano elettronica accurata in grado di
misurare tempi nell'ordine dei picosecondi (ps) e misurano il tempo impiegato da milioni di
impulsi laser riflessi al sensore, calcolandone la distanza. Ruotando lo scanner a 360° su se
stesso (di solito servendosi di uno specchio) lo scanner può acquisire tutta una stanza.
9
Velocità della luce nel vuoto: c = 299 792 458 m/s
28
Rosario Santoro
Figura 3.8 - Laser scanner a spostamento di fase
I laser scanner a spostamento di fase (phase shift) sono anch'essi basati sul tempo di volo,
con all'aggiunta della modulazione della potenza del fascio laser. Lo scanner, una volta
ricevuto il fascio, confronta le fasi dei raggi emessi e poi riflessi. La misurazione dello
spostamento di fase è più accurata. Si veda la Tabella 3.1 per un confronto tra i metodi.
Tabella 3.1 - Confronto tra le tecniche di laser scanning
Raggio
Tecnica di laser scanning
Vantaggi
Svantaggi
Triangolazione singolo raggio
 Disponibile in molte
forme (scanner di
aree, handheld,
braccio portatile)
 Spesso è più
portabile
 Minor preparazione
delle parti
 Minore sensibilità
alla luce ambientale
 Generalmente meno
accurati
 Generalmente a
minor risoluzione
 Rumore maggiore
Corto
Triangolazione di pattern di
laser
Basato su impulsi
Medio-lungo
Spostamento di fase
 Solitamente più
accurata
 Spesso maggior
risoluzione
 Minor rumore
 Da 2 a 1000m
 Più accurato
 Acquisizione più
veloce
 Minor rumore
 Solo scansioni di
area
 Generalmente non
molto portabili
 Più sensibile alla
finitura della
superficie (richiede
preparazione)
 Può richiedere
un'illuminazione
particolare
 Meno accurato
 Acquisizione più
lenta
 Maggior rumore
 Solo distanze medie
29
Rosario Santoro
3.1.2 Le alternative
Un approccio alternativo prevede l'aggiunta di tecniche di intelligenza artificiale come i
problemi a vincoli (Constrained Satisfaction Problems, CSP) per l'individuazione della
struttura di una stanza indipendentemente dalla presenza di oggetti, i quali vengono
approssimati a box [16].
3.1.2.1 Acquisizione a mano
L'acquisizione manuale è il metodo di acquisizione più flessibile ma anche più lungo e
complicato. Un addetto rileva le misure degli ambienti e degli oggetti per poi riportarli
manualmente nel software di creazione del mondo virtuale.
Pur lasciando libertà e flessibilità sotto tutti gli aspetti dell'acquisizione e modellazione,
questa tecnica richiede molto tempo sia durante il sopralluogo per la raccolta delle misure
sia in fase di modellazione e inserimento dei dati essendo interamente demandata alla
manodopera umana.
3.1.2.2 I laser scanner CAM2
Figura 3.9 - I loghi della FARO e della CAM2
Figura 3.10 - Il laser scanner Focus 3D X-330 prodotto dalla FARO
I laser scanner della CAM2 (azienda del gruppo FARO Technologies Inc.) utilizzano la
tecnologia di laser scanning a triangolazione e sono quindi dotati di uno specchio che ruota
30
Rosario Santoro
attorno all'asse orizzontale e che riflette di 90° il raggio laser proiettato. Oltre a ciò, il
dispositivo intero ruota lentamente intorno all'asse verticale: in questo modo il laser può
raggiungere punti in ogni direzione nell'ambiente. Le dimensioni di questo dispositivo sono
compatte (24cm x 20cm x10cm) e il peso è di 450g. Ha una fotocamera a colori da 70 Mpx
integrata e la batteria dura fino a 5 ore. I dati acquisiti sono memorizzati su una scheda SD.
È dotato di una bussola elettronica per associare dati direzionali alle scansioni, facilitando
quindi il processo di auto-registrazione (ambito GIS10). Possiede anche un altimetro che
permette di distinguere le altezze delle diverse acquisizioni (per esempio nei piani di un
edificio). Il controllo del dispositivo è via wireless LAN oppure tramite touch screen.
Un pregio di questo tipo di laser scanner e in particolare del modello X330 in Figura 3.10
è l'intervallo di distanze che può acquisire, da 60 cm a 330 m e con grande precisione.
Questi pregi sono bilanciati dallo svantaggio dell'elevato costo (nell'ordine delle decine di
migliaia di €).
Il laser scanner FARO è impiegato nel settore forense per la conservazione delle scene
del crimine e per sopralluoghi (Figura 3.11): infatti, il software SCENE della FARO che
carica le scansioni è in grado si effettuare misure precise di distanza tra due punti. Il
software è anche in grado di fondere tra loro acquisizioni in diversi punti dello stesso
ambiente.
Figura 3.11 - Un autoveicolo incidentato catturato mediante un laser scanner.
Sono indicate le posizioni in cui sono avvenute le diverse scansioni, dalla cui fusione questa immagine è
stata generata.
10
Geographic information system
31
Rosario Santoro
L'acquisizione con laser scanner è costosa ma più precisa.
Figura 3.12 - Una nuvola di punti catturata mediante laser scanner rappresentante un'intersezione
stradale a livelli sfalsati
Figura 3.13 - Il risultato della fusione delle nuvole di punti catturate mediante
diverse acquisizioni con laser scanner e visualizzato nel software SCENE della FARO
32
Rosario Santoro
3.1.2.3 Kinect
(a)
(b)
Figura 3.14 - Il Kinect per Windows (a) e i sensori al suo interno(b)
Il Kinect è una gamma di dispositivi prodotti dalla Microsoft per il riconoscimento del
movimento dell'utente e si prefigge lo scopo di permettere agli utenti di interagire in modo
naturale con i computer attraverso i gesti e il parlato. Il Kinect for Windows impiegato dal
candidato assieme al software di ricostruzione Skanect (paragrafo 3.1.2.4) appartiene a
questa gamma e ha al suo interno sensori audio e video (Figura 3.14b).
Per la parte audio, i sensori sono quattro microfoni disposti lungo il corpo del Kinect a
formare il cosiddetto array di microfoni: la quantità di microfoni permette sia di registrare
audio da una direzione ben precisa sia di individuare la provenienza di un suono.
La parte video prevede un sensore RGB che memorizza dati a tre canali con una
risoluzione di 1280x960 a 12 FPS11 oppure a 640x480 a 30 FPS, un emettitore di infrarossi
(IR) e un sensore IR. L'emettitore IR proietta dei raggi a luce infrarossa e il sensore IR
riceve i raggi riflessi: questi raggi vengono convertiti e la distanza con l'oggetto che li ha
riflessi interpretata. In questo modo si acquisisce un'immagine di profondità (per i dettagli si
rimanda al paragrafo 3.1.1.2).
È possibile attivare la funzione "Near Mode" che permette ai sensori luminosi di vedere
oggetti vicini anche 40 centimetri senza perdere accuratezza o precisione, con un
peggioramento graduale per distanze superiori ai tre metri.
L'SDK del Kinect for Windows, aggiornato con una buona frequenza, contiene driver,
strumenti, API, interfacce per dispositivi, ed esempi di codice per semplificare lo sviluppo
delle applicazioni per il deploy commerciale.
11
Frames Per Second
33
Rosario Santoro
Questo SDK è inoltre in grado di riconoscere alcune caratteristiche umane come il
tracciamento dello scheletro (posizione e postura dell'utente), il tracciamento del volto e il
riconoscimento dei gesti e della voce. Le librerie Kinect Fusion (3.1.2.4) acquisiscono dati
del colore e della profondità di una scena durante una scansione e ricostruiscono i dati in un
modello tridimensionale. L'SDK espone i dati dell'array di sensori e fornisce agli
sviluppatori strumenti per accedere a questi dati: per esempio, è possibile accedere in
maniera estesa ai dati di profondità e all'emettitore infrarosso. L'SDK offre infine la
possibilità di integrazione con le librerie OpenCV e MATLAB.
3.1.2.4 Kinect Fusion
Le Kinect Fusion sono librerie che compongono l'SDK del Kinect for Windows: si
occupano dell'acquisizione di nuvole di punti e la loro fusione è mirata alla ricostruzione
tridimensionale di ambienti o oggetti. Ne esiste un'implementazione anche nelle librerie
PCL12 denominata KinFu (pcl.kinfu).
Il candidato ha ritenuto opportuno studiare anche questa libreria poichè è stata creata su
misura del Kinect e dunque è lo strumento ideale per sviluppare un sistema ad-hoc per
l'acquisizione di oggetti e/o ambienti, aspetto importante dell'ottica del presente lavoro di
tesi. Segue quindi l'esposizione della processing pipeline delle Kinect Fusion (con
riferimento alla Figura 3.15).
Figura 3.15 - Processing pipeline della ricostruzione tridimensionale effettuata dalle librerie Kinect
Fusion
12
Point Cloud Library
34
Rosario Santoro
a) Conversione della mappa di profondità. Si converte la profondità raw dei sensori del
Kinect in profondità in virgola mobile in metri, seguita da una conversione opzionale in una
nuvola di punti orientata che consiste di punti/vertici 3D nel sistema di coordinate della
telecamera e le normali alla superficie in questi punti da utilizzare con la funzione
AlignPointClouds.
b) Calcolo della posizione della telecamera. Si calcola la posizione e l'orientamento della
telecamera rispetto ad un riferimento globale e ne si tiene traccia durante gli spostamenti del
sensore in ciascun frame servendosi di un algoritmo di allineamento iterativo, che permette
di conoscere sempre la posizione corrente del sensore relativa al frame iniziale. A tal
proposito esistono due alternative nelle Kinect Fusion. La prima è l'algoritmo
NuiFusionAlignPointClouds che può essere usato sia per allineare la nuvola di punti
calcolata dalla ricostruzione con quella della telecamera di profondità del Kinect, sia in
modalità standalone (per esempio per allineare due telecamere separate che osservano la
stessa scena). L'altro algoritmo è AlignDepthToReconstruction che fornisce risultati più
accurati di tracciamento della telecamera ma può risultare meno robusto per oggetti in
movimento nella scena. Se il tracciamento dovesse subire interruzioni è sufficiente
riallineare la telecamera con l'ultima posa tracciata.
c) Fusione dei dati di profondità. I dati provenienti dalla posizione corrente del sensore
vengono integrati in una singola rappresentazione volumetrica dello spazio. Questa
integrazione dei dati di profondità è eseguita per ciascun frame applicando una media
durante l'esecuzione per ridurre il rumore; allo stesso tempo riesce a gestire qualche
cambiamento dinamico nella scena come l'aggiunta o la rimozione di alcuni oggetti.
Osservare una superficie da punti di vista nuovi contribuisce a riempire una porzione vuota
o buco e alla continua ridefinizione con nuovi dati delle stesse superfici.
35
Rosario Santoro
Figura 3.16 - La fase di raycasting13: l'intersezione delle tre frecce indica il punto di vista dell'osservatore
mentre il reticolo rappresenta i pixel del monitor.
d) Raycasting. Il volume ricostruito può subire il procedimento di raycast (Figura 3.16)
da un punto di vista e la nuvola di punti risultante può subire un processo di shading per
produrre un'immagine visibile renderizzata del volume 3D ricostruito.
Il tracciamento effettuato dalle Fusion usa solo i dati del sensore di profondità e si basa
sulla sufficiente presenza di variazioni di profondità tra un frame e il successivo in modo
tale da far corrispondere i dettagli robusti nei due frame e calcolare la differenza di
posizione. Per questa ragione il tracciamento e la ricostruzione risulteranno difficoltosi se
effettuati in ambienti spogli o privi di dettagli (come per esempio un muro completamente
bianco). Le scene ideali presentano oggetti sparsi a diverse distanze. Per mantenere un buon
tracciamento è necessario effettuare spostare o ruotare con lentezza il Kinect.
Nelle
Kinect
Fusion
sono
implementati
due
algoritmi
di
tracciamento:
AlignDepthFloatToReconstruction e AlignPointClouds. Se si sta creando un volume
di ricostruzione, la funzione AlignDepthFloatToReconstruction probabilmente eseguirà
un tracciamento migliore. D'altra parte, la funzione AlignPointClouds può essere anche
usata da sola, senza un volume di ricostruzione per allineare due nuvole di punti. È bene
notare che l'interfaccia INuiFusionReconstruction usa al suo interno la funzione
AlignDepthFloatToReconstruction .
L'algoritmo AlignPointClouds invece può fornire in output un'immagine ARGB
visibile del risultato dell'algoritmo di allineamento che può essere riutilizzata come input per
altri algoritmi di visione come segmentazione degli oggetti. I pixel in ciascuna vista durante
13
http://www.cs.berkeley.edu/~sequin/CS184/IMGS/RayCasting.JPG
36
Rosario Santoro
la ricostruzione possono rientrare nella categoria degli inlier o degli outlier, in relazione al
tracciamento positivo nelle diverse scene oppure no: entrambe le categorie evidenziano i
pixel in questione con dei colori particolari.
Anche il secondo algoritmo di tracciamento AlignDepthFloatToReconstruction può
fornire in uscita un'immagine di tipo NUI_FUSION_IMAGE_TYPE_FLOAT come risultato
dell'allineamento dell'algoritmo di tracciamento della camera e che può essere processata per
creare un rendering a colori o può essere usata come input per altri algoritmi di visione come
la segmentazione degli oggetti. Questa immagine descrive quanto bene un pixel di
profondità descrive il modello di ricostruzione. Questi valori residui sono normalizzati tra -1
e 1 e rappresentano il costo/energia di allineamento per ciascun pixel. Valori di intensità
maggiori (sia positivi sia negativi) rappresentano maggiore discrepanza e valori minori
rappresentano minore discrepanza o meno informazione su quel pixel.
Il volume di ricostruzione è composto da piccoli cubi nello spazio, denominati "Voxel". I
volumi che possono essere scansionati arrivano fino a 8m3. Le risoluzioni tipiche del voxel
di un mondo reale sono 1-2mm/voxel. Una peculiarità della ricostruzione e fusione 3D è il
legame che sussiste tra la dimensione del voxel e l'estensione dell'ambiente acquisito. È
possibile
specificare
il
volume
di
ricostruzione
NUI_FUSION_RECONSTRUCTION_PARAMETERS
passando
alla
una
struttura
funzione
NuiFusionCreateReconstruction . Il numero di voxel che possono essere creati dipende
dalla quantità di memoria disponibile all'allocazione sulla macchina di esecuzione e
tipicamente si arriva a 640x640x640= 262144000 voxel creabili su un dispositivo con
1.5GB di memoria o più. L'aspect ratio di questo volume può essere arbitrario ma è
opportuno far corrispondere le dimensioni del volume del voxel a quelle della forma
dell'area nel mondo reale che si intende scansionare.
Il membro voxelsPerMeter scala la dimensione reale a cui corrisponde un voxel: per
esempio, in presenza di un volume cubico 384x384x384 vx, si può rappresentare un cubo di
3m di lato nel mondo reale se si imposta voxelsPerMeter a 128vpm14, dato che 384/128=3,
dove ciascun voxel è 3m/384=7.8mm3, oppure un cubo di 1.5m di lato se si è impostato
256vpm (384/256=1.5 e ciascun voxel occupa un volume di 1.5m/384=3.9mm3). Tale
14
Voxels Per Meter
37
Rosario Santoro
combinazione di voxel nello spazio e i voxel per metro permettono di specificare
dimensione e risoluzione del volume da acquisire, ma si noti che si tratta di un tradeoff: in
altre parole, non è possibile acquisire un volume di grandi dimensioni ad alta risoluzione,
ma bisogna scegliere il punto di equilibrio più adeguato tra risoluzione e dimensione.
Questo tradeoff è generato dalle caratteristiche della macchina che esegue il processo di
ricostruzione. In particolare sulle GPU15 il massimo blocco di memoria contiguo che si può
tipicamente allocare è circa 1GB, e questo limita la risoluzione della ricostruzione
approssimativamente a 640x640x640 = 262144000vx. Similmente, sebbene le CPU abbiano
una quantità di memoria maggiore delle GPU, non viene aggirato il problema in quanto la
frammentazione della memoria heap potrebbe impedire l'allocazione di blocchi di memoria
dell'ordine del GB. Il tradeoff è quindi obbligatorio; se dovessero essere richieste sia alta
risoluzione sia dimensioni elevate, una soluzione potrebbe essere volumi multipli o
dispositivi multipli.
3.1.2.5 Skanect
Figura 3.17 - Logo dell'applicativo Skanect (ManCTL)
Skanect16 è un software creato dalla ManCTL e rilasciato il 27 gennaio 2014 sia sotto
licenza commerciale a pagamento sia in versione gratuita di prova: in quest'ultimo caso
viene limitato il numero delle facce nell'esportazione della mesh (massimo 5000 facce).
Skanect permette di collegare un dispositivo di acquisizione come il Kinect della
Microsoft (ma funziona anche con l'ASUS PrimeSense, Figura 3.2b) attraverso le OpenNI e
opera la fusione tra le nuvole di punti acquisite dalle diverse viste in tempo reale, basandosi
sulle geometrie in due acquisizioni consecutive.
La ricostruzione della mesh tridimensionale è possibile grazie alla natura dei due flussi
video acquisiti, cioè quello del visibile e una mappa di profondità a 16 bit.
15
16
Graphical Processing Unit
http://skanect.manctl.com/
38
Rosario Santoro
Figura 3.18 - Skanect durante un'acquisizione in modalità "body"
La Figura 3.18 mostra un'acquisizione in atto: nella parte sinistra è mostrata la nuvola di
punti ricostruita; sulla destra i singoli output del sensore RGB e la mappa di profondità (a
colori modificati). In basso a destra invece, vengono mostrate contemporaneamente la
nuvola di punti ricostruita e la scena correntemente inquadrata: in fase di acquisizione è
opportuno fare riferimento a questa finestra in quanto comunica all'utente se le nuove
acquisizioni sono state aggiunte correttamente al modello già ricostruito oppure se Skanect
non è riuscito a seguire lo spostamento degli oggetti nella scena da un frame al successivo.
In quest'ultimo caso, la zona verde scompare e rimane in trasparenza l'ultima vista della
nuvola di punti ricostruita: sarà compito dell'utente riposizionare il dispositivo di
acquisizione in modo tale da riprendere la ricostruzione da dove si era interrotta.
È opportuno segnalare che l'interruzione della ricostruzione è tutt'altro che rara durante
un'acquisizione: infatti, lo spostamento del dispositivo è un'operazione delicata e richiede
assenza di scossoni evitando di avvicinarsi troppo agli oggetti da acquisire, poichè il sensore
di profondità ha un limite inferiore di distanza al di sotto del quale non riesce a dedurre la
posizione di un punto.
Inoltre, quando viene effettuata una ricostruzione (fusione) ad alta qualità l'attesa è molto
lunga.
39
Rosario Santoro
Figura 3.19 - Le impostazioni iniziali di Skanect
Skanect permette di settare due importanti caratteristiche prima di iniziare l'acquisizione.
Con riferimento alle prime due opzioni mostrate in Figura 3.19, la prima è la modalità della
scena e la seconda la cosiddetta bounding box.
La bounding box, ovvero scatola di contenimento, è il volume del cubo che costituirà il
limite per lo spazio acquisito e il modello ricostruito: il lato di questo cubo può variare da
0.1 fino a 9 metri. Opzionalmente, è possibile raddoppiare l'altezza di questo cubo, scelta
consigliata nel caso dell'acquisizione del corpo di una persona.
Sono previste quattro diverse modalità di scena: body (corpo umano), object (singolo
oggetto), room (stanza completa) e half room (parte di una stanza). Sostanzialmente,
sussistono differenze solo tra body/object e room/half room, in quanto acquisendo un
oggetto o un corpo umano il Kinect si muove intorno all'oggetto da acquisire mentre nel
caso di una stanza il dispositivo dovrà inquadrare verso l'esterno.
Il candidato ha effettuato diverse acquisizioni di prova servendosi della combinazione
Kinect+Skanect ed è pervenuto alle seguenti conclusioni.
L'impostazione iniziale della tipologia della scena influisce molto sia sulla procedura di
acquisizione in sè per sè sia sui risultati finali della ricostruzione. Infatti, la modalità
migliore di funzionamento di Skanect è "body" (esempio nella Figura 3.25 e Figura 3.26)
40
Rosario Santoro
oppure "object" in quanto riduce di molto il volume da acquisire e quindi a parità di tempo è
possibile tornare su scene già acquisite e perfezionarle aumentandone il livello di dettaglio.
Nel caso di acquisizioni di ambienti interi, il candidato ha riscontrato diversi casi in cui la
ricostruzione offline (in seguito alle acquisizioni) portava a risultati completamente estranei
alla realtà acquisita; tali occorrenze si verificavano solo con le modalità room/half room
(esempio in Figura 3.24).
Un altro aspetto da non sottovalutare è la mole di dati acquisiti. Supponendo per assurdo
che l'acquisizione di un'intera stanza venga portata a termine senza errori e con una buona
qualità, si dovrebbe gestire un modello tridimensionale di dimensioni elevate che
allungherebbe i tempi di risposta e di utilizzo di qualsiasi software di modellazione
impiegato in fase di post-processing.
Con adeguati accorgimenti la dimensione di un modello esportato con le modalità
"body"/"object" è medio-bassa.
Il candidato ha acquisito con Skanect una lampada da comodino (Figura 3.21) e un
mobile di piccole dimensioni (Figura 3.23): i modelli tridimensionali risultanti (inclusi come
game object in Unity) sono rispettivamente in Figura 3.20 (con una fonte luminosa accesa) e
Figura 3.22 ed entrambi sono stati ricostruiti selezionando il massimo della fedeltà.
A valle delle ricostruzioni si è rivelato necessario operare un post-processing sulle
rispettive mesh, il cui motivo giace nell'eccessiva dimensione dei modelli esportati che
comporta elevati tempi di attesa di generazione del modello e un notevole rallentamento di
qualsiasi programma sia nell'importazione del modello sia nell'interazione con lo stesso.
Skanect offre un'intera sezione di strumenti di post-processing che includono l'esclusione
di porzioni del modello (mediante intersezione di un piano), la semplificazione della mesh,
la chiusura delle porzioni non acquisite mediante watertighting, open e closed hull,
l'aggiunta di colore alla mesh in accordo alle viste RGB acquisite e interpolando le zone
sprovviste di colore. Queste semplificazioni hanno provveduto a ridurre drasticamente la
dimensione del modello esportato. Nella Tabella 3.2 e Tabella 3.3 sono elencate le
41
Rosario Santoro
operazioni di post-processing subite dai due modelli acquisiti, la variazione della
complessità della mesh e del peso del modello .obj esportato (con texture UV17 a parte).
Tabella 3.2 - Variazione del numero di facce del modello del mobile in seguito alle operazioni di postprocessing
Operazione di post-processing
Numero di facce del
modello
Dimensione modello
.obj esportato
(ricostruzione ultimata)
5 442 230
277 MB
Simplify <8%
5 441 512
-
Fill holes - closed hull - smoothing <6cm
240 000
16 MB
La drastica riduzione del numero delle facce tra la seconda e la terza riga è dovuta ai 6cm
di limite di smussamento della mesh.
Tabella 3.3 - Variazione del numero di facce del modello della lampada in seguito alle operazioni di postprocessing
Operazione di post-processing
Numero di facce del
modello
Dimensione modello
.obj esportato
(ricostruzione ultimata)
194 547
116 MB
Sagomatura del modello con il piano
141 231
-
Simplify < 3%
100 000
-
Fill holes - opened hull - smoothing <2cm
28 719
1.8 MB
Skanect offre quattro formati di esportazione del modello acquisito: .obj, .ply, .stl, .vrml.
Per l'esportazione dei due modelli acquisiti con Skanect si è utilizzato il formato .obj con
texture UV (l'alternativa per la texture è "per-vertex").
17
Mappatura UV della texture: il procedimento mediante il quale la texture 2D viene proiettata su una
forma 3D. Si chiama UV per via delle coordinate di un punto della texture (u,v) dato che (x,y,z) sono già
utilizzati nel modello tridimensionale.
42
Rosario Santoro
Figura 3.20 - Una lampada da comodino acquisita e
inclusa nel mondo virtuale
Figura 3.22 - Il modello 3D di un mobile di piccole
dimensioni acquisito e incluso nella scena
Figura 3.21 - L'oggetto
dell'acquisizione di Figura 3.20
Figura 3.23 - L'oggetto reale acquisito in
Figura 3.22
Figura 3.24 - Nuvola di punti registrata risultante dall'acquisizione in modalità "room" (visualizzata con
Blender)
43
Rosario Santoro
Figura 3.25 - Nuvola di punti senza texture
risultante dall'acquisizione di un volto (Skanect in
modalità "body", visualizzata in Blender)
Figura 3.26 - Nuvola di punti in
Figura 3.25 con texture per-vertex associata
(visualizzazione in Blender)
3.1.2.6 Reconstruct Me
Figura 3.27 - Il logo dell'applicativo ReconstructMe
Reconstruct me18 è un software simile a Skanect che utilizza Kinect o Asus PrimeSense
per ricostruire ambienti 3D da nuvole di punti. L'interfaccia di quest'applicazione è molto
più semplice e non offre le stesse opzioni di Skanect sia per quanto riguarda il postprocessing sia per le opzioni di esportazione (solo .ply ed .stl). La bounding box massima è
inoltre minore di quella di Skanect, quindi un'eventuale acquisizione di una stanza sarebbe
ulteriormente penalizzata. Esistono due licenze, una commerciale a pagamento e l'altra di
prova gratuita senza limite nella mesh di esportazione ma con l'aggiunta di artefatti come
sfere colorate e il nome del software.
18
http://reconstructme.net/pricing/
44
Rosario Santoro
3.1.2.7 Il progetto Matterport
Figura 3.28 - Il dispositivo di acquisizione messo
a punto dalla Matterport (prima versione)
Figura 3.29 - La seconda versione19
Il progetto Matterport prevede sia software sia hardware. La parte software consiste in
un'applicazione di fusione e ricostruzione 3D (come Skanect) da nuvole di punti acquisite
con la parte hardware, costituita quest'ultima da tre ASUS PrimeSense ognuno dotato di
sensore di profondità e sensore RGB e disposti reciprocamente ad un angolo di 120° (Figura
3.28). Questi tre dispositivi sono racchiusi in una scatola che, montata su un treppiedi, ruota
lentamente e acquisisce i dettagli dell'ambiente in cui è posizionata, in modo simile al laser
scanner FARO, con la differenza che non si tratta di laser scanning, ma di RGB+depth. È
controllabile a distanza via bluetooth e iPad con un'app dedicata e costa 4500$ (più una
quota mensile). In tempi brevi e soprattutto in modo semplice è possibile avere un modello
3D di qualità accettabile (Figura 3.30).
19
http://www.3ders.org/articles/20130202-startup-matterports-low-cost-3d-scanner-project-raises-nearly$4m.html
45
Rosario Santoro
Figura 3.30 - Esempio di ricostruzione di una stanza mediante Matterport
Spostando il dispositivo in altre posizioni nello stesso ambiente è possibile acquisire
dettagli mancanti nelle precedenti acquisizioni: considerando questi spostamenti,
l'acquisizione dura venti minuti circa [17]. La ricostruzione è effettuata dal cloud Matterport
dopo l'upload dell'acquisizione.
3.1.2.8 Google Tango project
Google Tango20 è un progetto iniziato nel febbraio 2014 il cui scopo è la messa a punto di
uno smartphone Android con hardware e software dedicato alla visione artificiale ed
elaborazione delle immagini, in particolare al tracciamento della posizione del dispositivo
nello spazio tridimensionale, alla ricostruzione di una mappa dell'ambiente e, più in
generale, cerca di digitalizzare in 3D tutto quello che circonda l'utente. I suoi sensori
permettono di effettuare più di 250mila misurazioni 3D al secondo.
Questo smartphone non è attualmente in vendita ma è ancora in fase di "early
prototyping" (primo prototipo) e solo alcuni pezzi sono stati distribuiti a sviluppatori di
Università ed Enti di ricerca per studiarne applicazioni, trovare bug e contribuire alla sua
messa a punto. Il software di ricostruzione di Matterport esposto poc'anzi rientra in questi
gruppi.
Il Google Tango possiede quattro fotocamere. La fotocamera principale è da 4Mpx RGB,
dotata di flash laterale. Subito in baso è situata una camera con ottica fisheye in grado di
catturare immagini con un angolo di 180° e un altro obbiettivo che viene utilizzato per
catturare la profondità degli ambienti e oggetti. Il quarto sensore è una fotocamera frontale
20
https://www.google.com/atap/projecttango/
46
Rosario Santoro
che ha un angolo di visione di 120° che ha circa lo stesso campo visivo dell’occhio umano
[18].
Figura 3.31 - Project TANGO, un prototipo di
smartphone costruito da Google per la ricostruzione
3D su dispositivi mobile
Figura 3.32 - Elaborazione artistica di
un'acquisizione con lo smartphone Google TANGO
3.1.3 La soluzione di acquisizione
3.1.3.1 Confronto fra le tecniche
Tabella 3.4 - Confronto fra le tecniche di acquisizione esposte in precedenza.
Per ciascuna cella viene espresso un giudizio sulla caratteristica basato sul colore (rosso: scarso, giallo:
accettabile, verde: ottimo) e, a seconda di quante caselle sono colorate, viene quantificata la caratteristica
(1:poco, 2:nella media, 3:molto). Per esempio, il costo delle Fusion è basso (una tacca) e questo è un bene
(verde), mentre gli strumenti di postprocessing offerti da Reconstruct me sono pochi (sempre una tacca) ma
questo è un male (rosso)
Metodo di
acquisizione
Tempo
Precisione
Costo
Distanze
Complessità
PostEsportazione
di utilizzo processing
Manuale
Skanect
Reconstruct
me
Kinect
Fusion
Matterport
Laser
scanner
47
Rosario Santoro
Il confronto tra le tecniche di acquisizione presentate nel capitolo 3.1.2 è stato condotto
valutando sette diversi aspetti, ciascuno dei quali viene di seguito spiegato includendo un
commento su ciascuna delle sei tecniche candidate.

Tempo: durata del processo di acquisizione, post-processing escluso. Tutti i
dispositivi comportano un tempo di attesa praticamente simile, intorno ai venti
minuti per acquisizione dettagliata, che nel caso di dispositivi automatizzati come il
laser scanner e Matterport vengono impiegati per una rotazione completa, mentre per
gli altri metodi in cui è previsto lo spostamento del Kinect il tempo è impiegato
nell'inquadratura lenta di ogni prospettiva degli oggetti/stanze. Il metodo manuale
impiega un tempo maggiore rispetto agli altri poichè la raccolta delle misure a mano
porta via molto tempo.

Precisione: qualità del modello ricostruito a processo ultimato (post-processing
escluso). Tutti i metodi garantiscono una buona qualità di ricostruzione del modello
3D fatta eccezione per Reconstruct me e le Fusion che sono sempre accettabili ma di
qualità peggiore.

Costo: prezzo del dispositivo. Il laser scanner e Matterport svettano per l'elevato
costo mentre il metodo manuale e le Fusion non hanno un costo in quanto il primo
non prevede attrezzatura particolare e le seconde si possono scaricare gratuitamente.
Skanect e Reconstruct me si assestano a metà in quanto per l'utilizzo completo
richiedono l'acquisto di una licenza commerciale.

Distanze: massima distanza alla quale è possibile rilevare un punto (e quindi un
oggetto). Con un range che va da qualche decina di centimetro alle centinaia di metri,
la tecnica del laser scanning copre le distanze maggiori. Le stesse distanze
potrebbero essere coperte con il mero intervento umano ma è ovviamente più
difficoltoso. Il metodo Matterport ha una portata massima inferiore ma riesce con
facilità ad acquisire una stanza, anche servendosi di acquisizioni multiple fuse tra di
loro. I metodi che sfruttano il Kinect invece mostrano un basso profilo per un
problema comune alla base, vale a dire il compromesso tra la risoluzione del voxel e
la dimensione massima di un'acquisizione (come esposto in 3.1.2.4). Per questa
ragione l'estensione massima non può superare una stanza di piccole dimensioni.
48
Rosario Santoro

Complessità di utilizzo: difficoltà nell'utilizzo dell'intero metodo, dall'acquisizione
all'esportazione del modello. L'acquisizione manuale dell'ambiente e degli oggetti è
un procedimento tanto lungo e faticoso quanto più complessi e vasti sono gli
ambienti e gli oggetti da acquisire. La procedura si semplifica con l'utilizzo del
Kinect e di software (Skanect/Reconstruct me/API Fusion) per la sua gestione fino a
diventare semplice come la pressione di un tasto "Avvia" nei metodi Matterport e
laser scanner.

Post-processing: quantità e utilità degli strumenti messi a disposizione dal metodo
stesso per la rifinitura del modello appena acquisito. Reconstruct me non offre alcuno
strumento di post-processing al contrario di Skanect che offre watertighting,
semplificazione della mesh con diversi metodi, colorizzazione, sagomatura del
modello e altri. Essendo librerie di programmazione, le Fusion possono
implementare e includere qualsiasi procedura di post-processing. Il laser scanning
offre sì qualche strumento ma solo nel software fornito a parte. Per il metodo
manuale, il postprocessing è tanto più facile quanto più semplice è il modello
(idealmente, un solido geometrico basilare) ma come per il laser scanner della CAM2
è necessario servirsi (ovviamente) di tool esterni.

Esportazione: quantità di formati in cui è possibile esportare il modello ricostruito.
Fatta eccezione per Matterport e il laser scanner a proposito dei quali non si dispone
di informazioni e di Reconstruct me che offre un solo formato di esportazione, gli
altri metodi offrono una buona gamma di formati. Le Fusion, trattandosi di librerie di
programmazione, offrono il massimo della libertà in quanto è possibile includere le
librerie più adatte all'esportazione e conversione dei formati (per esempio le PCL).
A valle del confronto e forte dello spirito di equilibrio pesato che caratterizza il lavoro di
un ingegnere, il candidato ritiene che la soluzione di acquisizione migliore sia composta
dalla combinazione Microsoft Kinect e Skanect e dell'acquisizione manuale. Nel dettaglio,
considerate le buone prestazioni dello Skanect in modalità "object", il Kinect verrebbe
impiegato nel progetto per acquisire ogni oggetto presente nella stanza, sia esso uno stimolo
oppure no. D'altra parte, visti i pessimi risultati di ricostruzione del Kinect quando si tratta di
acquisire un ambiente, il candidato ritiene opportuno demandare la modellazione
dell'ambiente ad un operatore umano: ciò è altresì permesso dalla semplicità geometrica
49
Rosario Santoro
della modellazione di una stanza che è assimilabile ad un parallelepipedo e la cui
costruzione la si può effettuare direttamente in Unity 3D, usandolo come un programma
CAD21, a seguito di una sessione di raccolta delle misure degli ambienti. L'operatore
incaricato della costruzione della scena si occuperà, laddove necessario, della rifinitura dei
modelli 3D degli oggetti acquisiti e dell'aggiunta delle texture alle pareti (nel caso in cui per
esempio sia presente della carta da parati).
3.1.3.2 Formati di esportazione dei modelli 3D
Tenendo presente che nel progetto è previsto l'utilizzo di più applicazioni di modellazione
e motori di gioco, è opportuno valutare quali formati garantiscono la portabilità dei modelli
3D tra queste applicazioni. Vengono perciò di seguito elencati i formati di esportazione
incontrati nel corso dello studio del candidato.

OBJ: formato ASCII open, contiene il semplice elenco delle coordinate dei vertici e
la posizione UV di ciascun vertice della texture. È solitamente affiancato da altri due
file: l'.mtl che contiene informazioni sul materiale della mesh e il .png che contiene
la texture.

PLY: Polygon File Format, contiene una lista di triple (x,y,z) per i vertici e una lista
di facce descritte da indici nella lista dei vertici.

STL: formato senza unità utilizzato per la prototipazione rapida e la stampa
tridimensionale (richiede che le mesh siano chiuse e abbiano subito il watertighting).
È da preferire quando la scansione è ad alta risoluzione dato che la dimensione del
file è minore di OBJ. Definisce una superficie triangolata grezza e non strutturata
descrivendo il versore della superficie triangolare e i tre vertici secondo la regola
della mano destra.

FBX: FilmBoX, formato proprietario di Autodesk, non documentato.

3DS, MAX: formati proprietari di 3DStudio Max, è lo standard industriale de facto
(assieme a OBJ) per il trasferimento di modelli tra programmi 3D.
21
Computer Aided Design
50
Rosario Santoro
Per la modellazione e rifinitura delle mesh acquisite ma anche per la conversione tra un
formato e l'altro è possibile utilizzare tool gratuiti come Blender 22 e MeshLab23 o proprietari
come 3DStudio Max e Revit (entrambi sviluppati da Autodesk).
Considerata la soluzione di acquisizione scelta (Kinect & Skanect) e il motore di gioco
Unity 3D, il formato per i modelli 3D più adatto risulta dunque essere l'OBJ con texture UV
(modalità con la quale sono stati importati i modelli della lampada e del mobile in Unity):
esso è infatti esportabile da Skanect, leggibile dai programmi di modellazione sopracitati e
importabile in Unity3D.
Per quanto attiene ai modelli a parte presenti nell'ambiente virtuale prototipale di Figura
3.51, il formato con il quale sono stati scaricati alcuni di essi è stato l'FBX.
3.2 Visori di realtà virtuale
Il candidato ha valutato diverse soluzioni per quanto riguarda la parte di output
stereoscopico per il paziente. Questo è un settore fervente e sta riscuotendo un notevole
successo sul mercato poichè ha applicazioni non solo in ambito medico, come nel presente
lavoro di tesi, ma anche nel mondo videoludico. Nuovi e migliori dispositivi sono in fase di
messa a punto, ma il candidato ne ha individuati due in particolare, i Meta AR e gli Oculus
Rift, entrambi nati come progetti sulla piattaforma di crowdfunding Kickstarter24.
3.2.1 Meta AR
Nascono come diretti concorrenti dei Google Glass e permettono di creare sia realtà
virtuale sia realtà aumentata. Sono progettati per interfacciarsi con il motore di gioco Unity
3D attraverso un apposito framework incluso nell'SDK (Software Development Kit). I Meta
AR sono in grado di riconoscere mani e di tracciare la posizione delle dita e offrono
un'interfaccia di controllo precisa basata sui gesti.
22
http://www.blender.org/
http://meshlab.sourceforge.net/
24
http://www.kickstarter.com/
23
51
Rosario Santoro
Figura 3.33 - La prima versione del visore
"Meta 1"
Figura 3.34 - La seconda versione
"Meta SpaceGlasses"
Figura 3.35 - La versione più recente "Meta Pro"
Figura 3.36 - Confronto della superficie utilizzabile per la realtà aumentata
tra MetaPro e Google Glass (in alto a destra)
52
Rosario Santoro
Figura 3.37 - Composizione hardware degli occhiali MetaPro
La risoluzione del display see-through in ciascuna lente è di 1280x720 pixel e garantisce
un FOV (Field Of View) di 40°. Le connessioni disponibili sono via Wireless LAN
(modalità b/g/n), Bluetooth 4.0 e USB 3.0. La tecnologia che impiegano gli occhiali Meta si
basa su sensori di profondità 3D a tempo di volo, due telecamere RGB, una IMU (Integrated
Motion Unit) a 9 assi, accelerometro, giroscopio e bussola. Il peso dei soli occhiali è di
180g. Il Meta Pro è corredato di un pocket computer con processore Intel i5 da 1,5GHz,
4GB di RAM, un SSD da 128GB e una batteria da 32Wh. Queste caratteristiche motivano il
prezzo particolarmente alto di questo dispositivo (3650$).
Va infine citato il Meta App Store25 dove vengono pubblicate le applicazioni create
appositamente per questi occhiali: degna di nota è l'applicazione di realtà aumentata in
ambito medico26, la preferita dal pubblico.
A conti fatti, i Meta sono stati progettati principalmente per la realtà aumentata e per
l'interazione con gli oggetti virtuali.
In relazione agli scopi del progetto, i Meta presentano il vantaggio del basso ingombro
una volta indossati dal paziente, aspetto assolutamente da non sottovalutare. Inoltre,
l'interazione con il mondo virtuale è facilitata sia dal punto di vista hardware sia software,
25
26
https://www.spaceglasses.com/killer_apps
https://www.spaceglasses.com/applicants/131
53
Rosario Santoro
poichè esiste già un'API (Application Programming Interface) per il riconoscimento dei gesti
dell'utente: ciò permetterebbe di fare a meno di hardware esterno come il Leap Motion
(paragrafo 3.3). La presenza di un piccolo sistema audio solleva dall'obbligo di procurarsi
delle cuffiette.
Gli svantaggi, tralasciando il costo, sono invece la scarsa immersività e minore praticità
di implementazione di una soluzione di realtà aumentata: infatti, una realtà completamente
virtuale dà maggiore libertà e semplicità d'implementazione al programmatore di quel
mondo rispetto alla soluzione aumentata poiché non vi è bisogno di interfacciarsi in tempo
reale con il mondo esterno. Un altro punto a sfavore è la regolazione della luce: se nel
mondo virtuale si volesse simulare una riduzione della quantità di luce in una stanza, con un
dispositivo come i Meta risulterebbe impossibile, poiché la luminosità dell'ambiente
continuerebbe ad essere percepita dal paziente interferendo con la misurazione dei parametri
vitali. Infine, trattandosi di realtà aumentata, c'è bisogno che il paziente si trovi fisicamente
nell'ambiente che si intende riqualificare.
3.2.2 Oculus Rift
Figura 3.38 - Prima versione del development kit dell'Oculus Rift, il visore di realtà virtuale
impiegato dal candidato per il test
L'Oculus Rift è un visore di realtà virtuale prodotto dalla Oculus VR, compagnia
californiana fondata da Palmer Luckey, nata da un crowdfunding su Kickstarter, mediante il
quale raccolse 2.4 milioni di dollari a fronte dei 250mila richiesti. Ebbe da subito l'appoggio
di compagnie di sviluppo di videogiochi come Valve, Epic Games e Unity.
L'Oculus Rift permette l'head tracking a 360° con una latenza sufficientemente bassa
usando una tecnologia di tracking proprietaria, permettendo così di guardarsi intorno come
54
Rosario Santoro
nella vita reale. Ogni minimo movimento della testa è tracciato in tempo reale creando
un'esperienza naturale e intuitiva.
In maniera dissimile dalla stereoscopia su un televisore o in un film, ciò è ottenuto
presentando immagini uniche e parallele a ciascun occhio. Questo è lo stesso modo
mediante il quale gli occhi umani percepiscono le immagini del mondo, creando
un'esperienza molto più naturale e confortevole. L'Oculus Rift permette un'esperienza di
realtà virtuale di alto livello ad un prezzo accessibile: è stato infatti progettato anche per
essere quanto più possibile confortevole e leggero per lunghe sessioni di gioco. Il suo peso è
di 370 grammi circa, simili ad un paio di occhiali da sci pesanti. Il campo visivo è ampio
approssimativamente 110°, valore raggiunto deformando allungamento il mondo virtuale
oltre la visione periferica. La combinazione di un campo visuale ampio, dell'head tracking e
della stereoscopia 3D crea un'esperienza di realtà virtuale immersiva.
L'SDK27 dell'Oculus include integrazioni out-of-the-box per l'Unreal Development Kit
(link), Unreal Engine 4 e Unity 4 che facilitano lo sviluppo di applicazioni di realtà virtuale.
Al momento i sistemi operativi supportati sono Windows, Mac OS X e Linux.
Il visore del Development Kit 1 (Figura 3.38), del costo di 300€, è dotato di tre diverse
paia di capsule lenticolari intercambiabili a seconda del grado di miopia del giocatore (A, B,
C, rispettivamente per miopia nulla, leggera e avanzata).
Il visore necessita di alimentazione esterna a 5V CC e sulla scheda sono presenti ingressi
DVI, HDMI e USB mini. Per i primi due collegamenti, è come aver collegato alla propria
macchina un proiettore o un secondo monitor; il collegamento USB invece è necessario per
interfacciare il proprio ambiente di sviluppo VR con il dispositivo e poterne fruire senza
dover necessariamente esportare.
Uno svantaggio dell'Oculus Rift è la risoluzione non particolarmente elevata del display a
cristalli liquidi (LCD), dettaglio di cui ci si accorge una volta indossato il visore, considerata
la distanza dei piccoli schermi dagli occhi (si riescono a distinguere i singoli pixel). Inoltre,
la frequenza di aggiornamento degli schermi è sì buona ma purtroppo non elevatissima e ciò,
dopo un utilizzo più o meno lungo a seconda dell'utente che lo indossa, può provocare
fastidio.
27
Software Development Kit
55
Rosario Santoro
Ad ogni modo non ne risentono l'immersività e l'esperienza di realtà virtuale che
rimangono buone, considerata la precisione e responsività dell'head tracking.
Il terzo e ultimo modello in fase di studio e sviluppo è il prototipo Crystal Cove (Figura
3.39), presentato al CES 2014 di Las Vegas, che garantisce di eliminare i difetti di cui
sopra[19]. Infatti, la latenza è stata ridotta di molto e la risoluzione e definizione dei display
OLED da 5,6 pollici con risoluzione 1920x1080 (16:9) aumentano ancora di più l'esperienza
di realtà virtuale. Inoltre, è stato aggiunto anche il tracciamento della posizione della testa
dell'utente: questo particolare permette di rilevare piccoli spostamenti della testa (come
sporgersi da un balcone).
Figura 3.39 - La seconda versione, il prototipo
Crystal Cove, presentato al CES di Las Vegas 201428
Figura 3.40 - Un particolare della Figura 3.39
I punti bianchi sul visore in Figura 3.39 servono a individuare con maggiore precisione i
movimenti dell'utente considerando non solo la testa ma anche tutto il corpo, mediante una
piccola telecamera ("EyeToy") disposta di fronte.
Figura 3.41 - Output su schermo delle due immagini
28
Foto: Maurizio Pesce - wired.it
56
Rosario Santoro
stereoscopiche proiettate all'interno dell'Oculus Rift
A marzo 2014 l'intera compagnia è stata acquisita da Facebook Inc. al prezzo di 2
miliardi di dollari [20].
3.3 Leap Motion
Il Leap Motion traccia entrambe le mani e tutte e dieci le dita con precisione al punto e ad
alta velocità.
Figura 3.42 - Il Leap Motion
Figura 3.43 - L'interno del Leap Motion: in rosso sono cerchiati i due sensori infrarosso,
in azzurro i tre emettitori infrarosso
57
Rosario Santoro
Figura 3.44 - Volume visibile e utilizzabile del Leap Motion
Il dispositivo ha un raggio d'azione come in figura: 120° (avanti e indietro) intorno alla
normale al dispositivo e 150° lateralmente, sempre rispetto alla normale. Lungo tali
direzioni la distanza massima alla quale è rilevabile una mano è 61 cm.
Il Leap Motion permette una nuova dimensione di gioco ma può anche essere utilizzato
per interagire in modo innovativo con applicazioni come Google Earth e di disegno in
generale. In alternativa è possibile ricercare un'applicazione in particolare nel negozio online
dedicato al Leap Motion, l'App Leap29. Il costo del dispositivo è di 80 $ (marzo 2014).
Tale rilevamento è permesso attraverso tre illuminatori infrarossi e ciò presenta vantaggi
come l'alimentazione via USB (basso assorbimento di potenza)
ma anche svantaggi:
trattandosi di luce emessa e riflessa non può occorrere riflessione se le due mani sono
disposte in modo allineato rispetto al Leap perchè quella più in basso schermerebbe dalla
luce infrarossa la mano più lontana.
29
https://airspace.leapmotion.com/
58
Rosario Santoro
Figura 3.45 - La modellazione delle mani e delle dita mediante Leap Motion.
Nel progetto il Leap Motion può essere utilizzato in due modalità diverse. La prima
prevede che il dispositivo sia adagiato su un ripiano di fronte all'utente e ne rilevi il
movimento delle mani sopra di esso (utilizzo canonico). La seconda invece è più audace e
interattiva in quanto prevede che il Leap Motion sia attaccato solidalmente alla parte
anteriore dell'Oculus Rift (Figura 3.46).
Figura 3.46 - Il Leap Motion montato sulla parte anteriore dell'Oculus Rift
In questa configurazione, c'è l'importante vantaggio di avere le proprie mani sempre nel
campo visivo del Leap Motion e quindi non si è vincolati ad una certa posizione ma le
proprie mani saranno visibili finchè l'utente effettua movimenti con le mani di fronte al
visore (e al Leap).
59
Rosario Santoro
3.4 Creazione dell'ambiente virtuale
3.4.1 Unity 3D
Lo sviluppo di giochi per computer e, più in generale, di ambienti virtuali interattivi e
navigabili è passato nel tempo dall'essere un'esclusiva delle grandi aziende di sviluppo alla
disponibilità per l'utente comune che può ora disporre di piattaforme di sviluppo di giochi
come Unity 3D.
Figura 3.47 - Il logo del motore di gioco Unity 3D
Figura 3.48 - L'interfaccia utente di Unity 3D durante lo sviluppo di un ambiente
Unity 3D è uno strumento di authoring integrato per la creazione di videogiochi 3D.
Attualmente supporta lo sviluppo solo su Windows e iOS ma le opzioni di esportazione sono
60
Rosario Santoro
numerose e includono Windows, Linux, Iphone, Google Android, Nintendo Xbox 360, Sony
Playstation 3 e anche un semplice browser dotato del plugin Unity 3D player.
Unity 3D è rilasciato con due tipi di licenze: una licenza pro a pagamento (mensile) che si
può provare gratuitamente per un mese e una licenza free senza limiti di tempo ma con
l'inibizione di alcune funzionalità come la proiezione delle ombre, l'importazione dei
pacchetti per le superfici d'acqua e l'interfacciamento con l'Oculus Rift.
Gli script che è possibile associare ad un game object possono essere scritti in JavaScript,
C# e Boo30.
Un game object in Unity è una qualsiasi entità rappresentabile nella scena: un cubo, una
luce, un piano, un modello 3D importato sono tutti esempi di game object. Ad un game
object può essere associata una mesh, una texture, un materiale e, più in generale, una
componente. Qualsiasi game object ha la componente "transform" che conserva
informazioni sulla posizione nello spazio rispetto ad un riferimento fisso della scena, sulla
rotazione e sulla scala (dimensione).
Una componente agganciabile può essere anche uno script scritto in uno dei linguaggi
indicati poc'anzi.
Figura 3.49 - La componente dello script StimulusCommon
di un gameObject trattato come stimolo.
Per esempio nel progetto ogni game object che rappresenta uno stimolo ha uno script
"StimulusCommon" associato (Figura 3.49).
Per quanto riguarda l'interfacciamento con il visore virtuale Oculus Rift, è necessario
scaricare un plugin gratuito dal sito degli sviluppatori di Oculus Rift (dopo essersi
registrati31): questo plugin sarà un file ".unitypackage" che verrà importato in Unity 3D e
metterà a disposizione i game object appropriati per la modellazione ed esportazione con il
visore Oculus (come per esempio la doppia telecamera per la stereoscopia). Ad importazione
30
Boo è un linguaggio di programmazione orientato agli oggetti, a tipi statici, general-purpose che cerca di
fare uso del supporto della Common Language Infrastructure per Unicode, l'internazionalizzazione e le web
application. Utilizza una sintassi ispirata a Python e tiene in considerazione l'estensibilità del linguaggio e del
compilatore.
31
https://developer.oculusvr.com/?action=dl
61
Rosario Santoro
avvenuta, si aggiungerà un menu "Oculus" nell'editor Unity attraverso il quale gestire le
build del progetto e aggiungere i prefab giusti.
Il prefab da aggiungere è OVRPlayerController composto da una forward direction (la
direzione in cui è rivolto il personaggio) e da un OVRCameraController che contiene le due
telecamere per la visione stereoscopica (leftCamera e rightCamera).
3.4.2 Le classi
Alcune delle classi codificate dal candidato sono derivate da una classe di Unity
denominata MonoBehaviour (nel package UnityEngine, di cui va segnalato l'utilizzo in ogni
file sorgente C#). Tutti gli script che divengono componenti di un game object dovrebbero
essere derivati da MonoBehaviour, poichè offre un'interfaccia per accedere all'esecuzione
della scena, ai suoi elementi e ai game object. Per fare un esempio, i metodi più
frequentemente reimplementati di quest'interfaccia sono Awake(), Start(), Update(),
onDestroy() e vengono richiamati in precise circostanze durante l'esecuzione: Awake viene
eseguita all'avvio dell'eseguibile della scena, Start all'istanziamento del game object cui è
associato lo script, Update è richiamato ad ogni frame e onDestroy alla distruzione del game
object.
3.4.2.1 Commpack
La classe CommPack svolge le stesse funzioni della sua omonima lato Qt. Si rimanda
dunque al paragrafo 4.1.3.4. L'unica differenza è nella lista degli stimoli, che è una List di
StimulusCommon.
3.4.2.2 EventManager
La libreria riutilizzata per la gestione del sistema event-oriented: contiene metodi per il
dispatching degli eventi e per l'aggiunta e rimozione dei listeners.
3.4.2.3 Gui
Il file gui.cs contiene la classe Gui che si occupa dell'interfaccia grafica e
dell'inizializzazione dell'ambiente virtuale istanziando la classe che gestisce la connessione
TCP, passandole l'indirizzo IP del server e la porta. Va notato che, per ora, questi parametri
sono hard-coded nel programma (in quanto assegnate nel codice): in realtà questi parametri
andrebbero specificati all'avvio dell'eseguibile già esportato, per esempio passandoli
62
Rosario Santoro
attraverso la CLI32 oppure scrivendoli in appositi campi mostrati all'avvio della scena
virtuale in una maschera, proprio come un menu di gioco.
L'oggetto di classe Gui rimane poi in un ciclo infinito che prevede la ricezione di dati dal
server e il loro dispatching sottoforma di eventi attraverso il metodo TriggerEvent()33.
Questo ciclo infinito è eseguito in un altro thread attraverso la chiamata a RunAsync della
libreria Loom, altrimenti la scena di gioco sarebbe stata inservibile in quanto sempre
bloccata con la ricezione sincrona di dati su socket TCP.
3.4.2.4 NetManager
Si occupa della connessione e disconnessione del client al server e della trasmissione e
ricezione dei dati. La ricezione dei dati è effettuata con un metodo sincrono poichè il
chiamante di questo metodo è già in un thread secondario: diversamente dal Qt che offre un
metodo sul socket TCP per la ricezione di un'intera riga di caratteri, in C# l'unico metodo
per la lettura di dati da stream TCP richiede un parametro in ingresso che specifichi quanti
byte leggere dal socket. Non disponendo a priori di quest'informazione, il candidato ha
scelto di acquisire un byte (un char) alla volta finchè non venga incontrato il carattere di line
feed "\n" e aggiungere man mano questi byte ad una lista dinamica: alla ricezione del line
feed, la lista viene copiata in un vettore di byte e poi convertita in stringa ASCII. Sarà
ovviamente premura del server evitare che nella stringa JSON inviata siano presenti dei
caratteri di line feed all'infuori di quello finale.
3.4.2.5 RVEventObj
Contiene le stringhe statiche di tutti gli eventi possibili, come "audio" e "solid".
3.4.2.6 StimulusCommon
La differenza principale nella progettazione delle classi lato Unity e lato Qt giace
nell'assenza della derivazione dei singoli stimoli da un'unica classe Stimulus (come descritto
in 4.1.3.6) poichè i linguaggi C++ e C# non lasciano al programmatore le stesse libertà. In
particolare, la differenza è nel polimorfismo a runtime, limitato al solo downcast in C#.
Si consideri il seguente codice.
32
Command Line Interface
In C# i nomi dei metodi iniziano per convenzione con la lettera maiuscola come per le classi,
contrariamente a quanto ci si aspetterebbe.
33
63
Rosario Santoro
Stimulus* stimolo;
Solid* solido = new Solido("cubo");
stimolo = solido;
L'ultima riga non costituisce errore in C++ poichè Solid è una classe derivata da Stimulus
e il C++ supporta il polimorfismo a runtime in entrambe le direzioni.
Solid* solid = (Solid*) (getStimuli()[i]);
Il metodo "getStimuli()" restituisce la QList (gergo Qt) di tutti gli stimoli. Tale lista è
stata dichiarata come "QList<Stimulus*>" e può contenere riferimenti a Solid, Light e
Audio senza che ciò costituisca un errore, trattandosi di classi derivate da Stimulus stesso.
In C# invece il polimorfismo a runtime è supportato solo nella direzione di
generalizzazione e non in quella di specializzazione: in altre parole è possibile trattare un
oggetto Solid come se fosse uno Stimulus, ma il cast di uno Stimulus in Solid o altra classe
derivata genera un eccezione a runtime di tipo "unsafe cast".
Di conseguenza, nella struttura delle classi lato Unity il candidato ha dovuto eliminare la
differenza tra uno stimolo generale e gli stimoli concreti implementando una sola classe
(StimulusCommon) che abbia al suo interno l'unione degli insiemi delle proprietà (e dei
metodi di accesso) di tutti gli stimoli previsti.
3.4.3 L'architettura event-oriented
Affinchè i valori delle nuove proprietà specificate via JSON arrivino ai rispettivi stimoli,
il candidato ha scelto l'adozione di un'architettura orientata agli eventi che prevede un
singolo dispatcher degli eventi ed n listener, ovvero tutti i game object corrispondenti agli
stimoli. I listener sono raggruppati per tipo di evento, corrispondente al tipo di stimolo
(solid, audio, light, ...).
Le classi afferenti a quest'architettura event-oriented sono state create da Dustin
Andrew34 nel 2012 e rilasciate sotto licenza GNU GPL, nel rispetto della quale vengono
riutilizzate in questo contesto.
Il funzionamento di quest'architettura è suddiviso in cinque diverse fasi.
1. Inizializzazione dell'architettura. In Unity si crea un game object vuoto e gli si
aggiunge come componente lo script C# "EventListener". Si estende la classe
34
http://www.dustinandrew.me/
64
Rosario Santoro
"CustomEvent" personalizzandola con le stringhe identificative dei diversi tipi di
evento previsti (nel progetto, "RVEventObj").
2. Ricezione del messaggio. Si riceve il messaggio JSON con il metodo
NetManager.rx() e ne si crea un oggetto di classe CommPack da passare al
metodo TriggerEvent(CommPack).
3.
Generazione dell'evento. All'interno del metodo TriggerEvent si crea l'evento
come oggetto di classe RVEventObj e ne si avvalorano il tipo e le proprietà.
Quest'oggetto viene poi inviato a tutti i game object già in ascolto tramite il
metodo EventManager.instance.dispatchEvent(RVEventObj) .
4.
Iscrizione del listener. Nel metodo Start() della classe StimulusCommon ogni
game object si mette in ascolto del tipo di evento appropriato servendosi del
metodo
EventManager.instance.addEventListener(string,
gameObject, callBack): il primo parametro è il tipo di evento (in accordo al
punto 1), il secondo è il game object in questione (una sorta di "this") e il terzo è
la funzione di callback da chiamare alla ricezione dell'evento. La funzione di
callback
dovrà
avere
la
seguente
firma:
public
void
CallBackFunc(RVEventObj) .
5.
Esecuzione delle modifiche. All'interno della suddetta funzione si effettuerà un
controllo sull'id a cui l'evento si riferisce: se coincide con l'id del game object
che ha ricevuto l'evento allora si assegnano le varie proprietà.
La struttura di Unity, inoltre, impedisce che thread secondari abbiano permessi di
modifica dei game object, operazione a disposizione solo del thread principale del gioco.
Ciò rappresenterebbe un problema in quanto la ricezione dei dati JSON in rete avviene in un
thread separato da quello principale per ovvi motivi di continuità dell'esecuzione e
disponibilità dell'interfaccia utente.
Il candidato ha ovviato a questo problema servendosi della libreria Loom35 suggerita
nella documentazione ufficiale di Unity. Loom è tornata utile sostanzialmente in due
evenienze nel contesto del presente progetto: per eseguire operazioni in modo asincrono e
35
http://unitygems.com/threads/
65
Rosario Santoro
per accodare operazioni sul thread principale. Rispettivamente questi due compiti sono
svolti dalle chiamate
Loom.RunAsync(() => {...});
Loom.QueueOnMainThread( () => {...});
La notazione tra parentesi degli argomenti è detta funzione lambda. Sulla destra
dell'operatore lambda ("=>") c'è il corpo della funzione che si riferisce ai parametri passati in
ingresso sulla parte sinistra dell'operatore lambda (in questo caso sono assenti).
3.4.4 La descrizione XML della scena
L' eXtensible Markup Language è un linguaggio di markup creato nel 1998 il cui scopo è
lo scambio e l'interusabilità di documenti strutturati e l'estendibilità. È basato su Unicode ed
è platform independent. I principali vantaggi derivanti dall'utilizzo di questo formato sono
nell'interscambiabilità dei documenti, la struttura ad albero navigabile e la leggibilità sia da
macchine sia da umani. Le sue alternative sono JSON e YAML. XML è un linguaggio di
markup da estendere creando adeguati elementi, attributi e valori. Nel contesto del progetto
è stato utilizzato come mezzo per descrivere la composizione della scena e in particolare gli
stimoli e le rispettive proprietà modificabili.
La GUI Qt e il mondo virtuale sono applicativi indipendenti che comunicano solo durante
l'esecuzione via TCP. Concettualmente però il mondo modellato al quale entrambi si
riferiscono è lo stesso: questo mondo viene creato in Unity 3D e dunque la componente
Unity lo conosce a priori ma lo stesso non avviene per l'interfaccia grafica Qt di modifica.
Per questo motivo si è rivelato necessario un modo per descrivere la composizione del
mondo virtuale al Qt.
Le alternative prevedevano una descrizione comunicata tramite un handshake applicativo
via TCP oppure tramite file caricato manualmente nell'interfaccia Qt dall'operatore. I formati
candidati erano l'XML o sempre il JSON.
Il candidato ha preferito usare entrambi questi formati nello sviluppo del sistema in modo
tale da non precludersi alcuna strada negli sviluppi futuri: il formato JSON è stato adottato
per la formattazione della comunicazione tra GUI Qt e viste Unity a runtime (si rimanda al
paragrafo 4.2.4) mentre l'XML è stato scelto per questa fase prettamente descrittiva.
66
Rosario Santoro
Bisogna tener presente che questa descrizione non riguarda l'intera composizione del
mondo virtuale ma soltanto gli oggetti che possono essere modificati e che possono aver
ripercussioni sui parametri vitali del paziente: a questi oggetti ci si riferirà con il termine
"stimolo". Dunque, questo file XML è sostanzialmente un elenco di entità modificabili
corredate ciascuna dell'elenco di proprietà modificabili, come dimensione, posizione,
rotazione, colore e così via. Il Listato 3.1 ne è un esempio.
Listato 3.1 - Esempio di descrizione XML degli stimoli di una scena
<stimuli>
<stimulus>
<id>cubo01</id>
<type>solid</type>
<editable property="pos">
<x>3</x> <y>2</y> <z>3</z>
</editable>
<editable property="rot">
<x>0</x> <y>0</y> <z>0</z>
</editable>
<editable property="siz">
<x>1</x> <y>1</y> <z>1</z>
</editable>
<editable property="col">
<r>200</r> <g>0</g> <b>0</b> <a>1</a>
</editable>
</stimulus>
<stimulus>
<id>comodino01</id>
<type>light</type>
<editable property="pow">
150
</editable>
<editable property="pos">
<x>4</x> <y>1</y> <z>5.4</z>
</editable>
<editable property="col">
<r>150</r> <g>150</g> <b>0</b> <a>1</a>
</editable>
<editable property="isIn">
1
</editable>
</stimulus>
...
</stimuli>
La struttura ad albero utilizza un nodo radice di nome "stimuli" i cui diretti discendenti
sono tutti e soli "stimulus". Ciascuno degli "stimulus" rappresenta uno stimolo e ha almeno
67
Rosario Santoro
un identificativo "id", un tipo "type" e una proprietà modificabile "editable" non vuota. Il
contenuto di ciascun "editable" varia a seconda del valore del campo "property" del tag
editable.
Considerando il Listato 3.1, vengono descritti due stimoli. Il primo è un solido
identificato dall'etichetta "cube01" di cui è permessa la modifica di posizione, rotazione,
dimensione e colore. Inizialmente questo solido ha posizione (3,2,3), rotazione (0°,0°,0°),
dimensione 1x1x1 e colore (200,0,0,1) nel formato RGBA36. Il secondo stimolo è una luce
di nome "comodino01" ed espone la modifica della sua potenza luminosa (l'unità di misura
sottintesa è Watt), posizione, colore e se si tratta di una luce artificiale o naturale (isInner):
inizialmente la luce è nella posizione (4,1,5.4), ha un colore sulle tonalità medie del giallo
(150,150,0,1) ed è una luce artificiale con potenza 150W.
Non è necessario esporre tutte le possibili proprietà per ciascuno stimolo. Può infatti
essere descritta una configurazione particolare in cui un solido è compreso tra due mobili e
in questo caso rotazione e dimensione potrebbero essere disattivate e mantenute costanti ai
valori imposti dall'operatore in fase offline, per evitare collisioni tra i diversi corpi rigidi;
oppure, nel caso di una luce, può essere modificabile esclusivamente il colore trattandosi per
esempio di un lampadario.
Questo file così formattato, viene caricato nell'interfaccia grafica Qt (si rimanda al
paragrafo 4.1.4).
3.4.5 La doppia visualizzazione
Data l'architettura del sistema, il candidato ha ritenuto opportuno fornire una visuale del
mondo anche all'operatore. Infatti la vista dell'Oculus Rift durante l'esecuzione occupa uno
schermo intero e comunque prevede la visualizzazione di entrambe le viste (sinistra e destra)
nella stessa schermata: questo è ovviamente scomodo per l'operatore.
Per questo motivo oltre alla normale visualizzazione stereoscopica per Oculus Rift, il
candidato ha previsto un ulteriore tipo di esportazione dell'ambiente virtuale in una finestra
normale, senza visualizzazioni stereoscopiche. Questa vista alternativa è stata creata per
fornire all'operatore dell'interfaccia di controllo del mondo virtuale un'anteprima della
configurazione del mondo prima di sottoporla al visore del paziente.
36
Red, Green, Blue, Alpha
68
Rosario Santoro
Durante la progettazione si era pensato di sfruttare l'esportazione su browser della scena
Unity 3D e ciò avrebbe permesso l'inclusione e visualizzazione della scena RV
nell'interfaccia di controllo stessa attraverso l'utilizzo di una classe particolare offerta dal Qt,
la QWebView. Questa ipotesi è stata scartata poichè Unity 3D impedisce di aprire, chiudere
e gestire socket TCP quando si sceglie l'esportazione della scena per browser: l'unico
meccanismo di comunicazione di rete permesso in questo caso è la Remote Procedure Call
(RPC). Ciò giustifica la scelta di esportare l'anteprima per l'operatore come eseguibile
standalone che mostrasse la scena in una finestra a parte.
Considerando inoltre che lo scopo di questa visualizzazione alternativa è di fornire
un'anteprima, il candidato ha pensato di lasciare a discrezione dell'operatore di commutare
tra lo stesso punto di vista del paziente, aggiornato in tempo reale da uno stream dati TCP
dalla vista con il visore, e un punto di vista completamente mobile che permetta all'operatore
di cambiare posizione e osservare il mondo da altre posizioni oltre a quella correntemente
occupata dal paziente.
Ad ogni modo le differenze tra le due tipologie di esportazioni sono poche e riguardano
principalmente due aspetti: i dettagli delle connessioni di rete e l'assetto delle telecamere. A
seconda del tipo di visualizzazione la connessione di controllo degli stimoli va stabilita su
porte diverse (6001/6002, cfr. Figura 2.2) e per la connessione dello stream della posizione
del paziente la vista stereoscopica produrrà il flusso TCP mentre la vista anteprima lo
consumerà (in alternativa può essere usato il meccanismo delle RPC). Per quanto riguarda la
telecamera, per la natura della visione stereoscopica (si veda paragrafo 3.1.1.1) devono
esserci due viste differenti e distanziate e orientate in modo opportuno piuttosto che una
singola telecamera che inquadri in prospettiva la scena. In Unity 3D ciò comporta l'aggiunta
di una seconda telecamera per l'inquadratura, costituendo così una left-camera e una rightcamera, una per ciascun occhio; inoltre per l'interfacciamento con l'Oculus Rift, si importa
un plugin dedicato che aggiunge non solo il game object della suddetta telecamera
composita ma anche degli script di controllo del movimento della testa del giocatore
attraverso accelerometri, bussola e giroscopio.
Dal lato dell'implementazione è sia possibile scegliere a compile-time che tipo di scena
esportare sia a run-time, aggiungendo un parametro booleano passato via shell che indica se
costruire una scena stereoscopica o meno. In fase di inizializzazione verranno costruiti gli
oggetti adatti.
69
Rosario Santoro
3.5 I tipi di oggetto modificabili
Gli oggetti inclusi nella scena virtuale che hanno una o più proprietà esposte a modifica
da parte dell'operatore sono definiti "stimoli". Correntemente, il candidato ha implementato
tre tipi diversi di stimoli: la luce, un corpo solido e una fonte sonora.
Le proprietà modificabili di una fonte luminosa (Light) sono la posizione nello spazio, il
colore della luce emanata (utile per fini cromoterapeutici), se si tratta di una fonte luminosa
interna o esterna (cioè, una lampadina o l'illuminazione pubblica) e l'intensità luminosa
espressa in Watt.
Un corpo solido (Solid) è sostanzialmente qualsiasi oggetto con una mesh all'interno della
scena tridimensionale. Nell'ottica del progetto, potrebbe trattarsi di un quadro, una porta, una
poltrona. Di tale oggetto è possibile modificare posizione, rotazione, dimensioni e la tinta
della texture37.
Una fonte sonora (Audio) permette di modificare la propria posizione, intensità del suono
riprodotto e l'indicazione di quale file riprodurre. Inizialmente si era pensato di specificare
direttamente dall'interfaccia operatore in Qt (attraverso un messaggio di commit delle
modifiche) il percorso del file audio da riprodurre, ma ciò avrebbe obbligato l'operatore a
conoscere la struttura delle directory nel file system dei rispettivi client (a parte ovviamente
la configurazione in cui un visualizzatore è in esecuzione sul localhost), accoppiando in
modo eccessivo ed inopportuno client e server. La soluzione scelta e implementata è stata
invece una combo box (menù a tendina) nell'interfaccia operatore attraverso la quale
scegliere un suono tra quelli disponibili: questo elenco verrà popolato in fase di lettura del
file XML di configurazione del mondo, in cui si conosceranno a priori i suoni disponibili.
Per i nuovi stimoli e per le nuove proprietà di stimoli esistenti in fase di progettazione, si
rimanda alla sezione 5.1.
37
Texture: i dettagli, un'immagine di superficie o un colore associato a superfici generate al computer o ad
un modello 3D.
70
Rosario Santoro
3.6 Prototipo dell'ambiente virtuale
Figura 3.50 - Il primo prototipo di ambiente di test. Si noti in basso a destra l'interfaccia operatore in
funzione, mentre nel riquadro in alto a sinistra è riportato (per ragioni di debug) il messaggio JSON ricevuto.
In Figura 3.50 è rappresentato il primo ambiente di test creato dal candidato. L'obiettivo
era evidentemente la semplicità e gli unici due stimoli controllabili erano un cubo e una
fonte luminosa di tipo puntuale38. Nella stessa scena, per ragioni di debugging, viene
visualizzato in una textbox l'intero messaggio JSON ricevuto.
Dopo aver affinato le conoscenze del motore Unity 3D ed essersi procurato una certa
quantità di modelli tridimensionali da includere nella scena, il candidato ha elaborato la
versione migliorata dell'ambiente di test (Figura 3.51).
38
Il tipo "Point" è una fonte luminosa isotropa.
71
Rosario Santoro
Figura 3.51 - La versione ufficiale dell'ambiente di prova
Questo ambiente virtuale è stato composto servendosi di modelli 3D scaricati
gratuitamente da alcuni negozi online39 e di due oggetti acquisiti dal candidato, trattati nel
paragrafo 3.1.2.4 (Figura 3.20 e Figura 3.22).
Gli stimoli presenti in questa scena sono otto:

Tre cubi colorati in blu, rosso e nero (tipologia di stimolo: "solid").

Tre fonti luminose di tipo "spotlight" che proiettano cioè un cono di luce, posizionate
nella lampada azzurra sul tavolo a sinistra, nella lampada da soffitto centrale e nello
schermo del computer portatile sulla scrivania dall'altra parte della stanza (tipologia
di stimolo: "light").

Due fonti sonore: una canzone proveniente dal computer e il ticchettio delle lancette
dall'orologio a parete (visibile in Figura 3.52) (tipologia di stimolo: "audio").
39
Come http://3dexport.com/ .
72
Rosario Santoro
Figura 3.52 - Particolari dell'ambiente virtuale in Figura 3.51
73
Modulo online: controllo della realtà virtuale
Rosario Santoro
4 MODULO ONLINE:
CONTROLLO DELLA
REALTÀ VIRTUALE
4.1 L'interfaccia operatore
4.1.1 Il Qt Creator
Figura 4.1 - Il logo delle librerie Qt
Figura 4.2 - Il logo della Nokia, contesto nel
quale sono state sviluppate le librerie Qt
Figura 4.3 - Il logo della Digia, attuale
proprietaria del progetto Qt
Il framework Qt permette uno sviluppo multi piattaforma, è principalmente utilizzato per
la creazione di interfacce grafiche ed è scritto in C++.
74
Rosario Santoro
Lo sviluppo del framework iniziò nel 1991 ad opera della Quasar Technologies in
Norvegia. Successivamente fu rinominata in Trolltech e acquisita dalla Nokia che ne
sponsorizzò lo sviluppo. Nel 2012 la Digia acquistò il progetto.
Attualmente il Qt è disponibile sia in forma closed source con una licenza commerciale,
sia con una licenza open-source sviluppatore scaricabile liberamente.
Il Qt Creator è un IDE (Integrated Development Environment) che si basa sulle librerie
Qt e permette la creazione di interfacce grafiche mediante drag&drop (in modo simile
all'interfaccia di Autocad) e l'implementazione del loro funzionamento.
I vantaggi principali derivanti dall'impiego delle librerie Qt sono due.
Multipiattaforma. I sorgenti in Qt possono essere compilati per i maggiori sistemi quali
Windows, iOS, Linux, Embedded Linux e, quando era in auge, anche il sistema operativo
Symbian dei primi smartphone caduto ormai in disuso.
Ciò è possibile grazie al tool QMake che interpreta il file principale di un progetto Qt, il
.pro che contiene l'elenco dei file coinvolti, delle librerie esterne e dei moduli del Qt da
caricare come ad esempio la rete, l'XML, la grafica OpenGL. Il Qmake eseguito sul file .pro
produce in uscita i MakeFile configurati per il sistema in uso (equivale all'esecuzione del
comando configure nei sistemi Unix) che guideranno nella compilazione dei sorgenti.
Il meccanismo signal/slot. In maniera simile al funzionamento in ambito Microsoft
Windows Presentation Foundation con gli hook.
Il Qt è fortemente orientato agli oggetti intendendo con ciò che esistono molte classi
ciascuna specializzata per uno scopo: ad esempio c'è la QString, la QJsonDocument, la
QTcpSocket, QThread e così via. Ognuna di queste classi ha dei metodi che automatizzano
operazioni comuni come la scrittura di byte in rete, la conversione di un intero in stringa, la
gestione di un file ecc...
Ciascuna di queste classi è derivata da un'unica classe genitrice di nome QObject che
offre tra le altre cose il metodo connect(..)
QObject::connect(QObject *sender, SIGNAL(..), QObject *receiver,
SLOT(..));
che permette di legare l'emissione di un segnale all'esecuzione di un metodo (slot). Un
segnale è emesso attraverso la parola chiave emit e ha una firma come se fosse una funzione.
75
Rosario Santoro
In questo modo è possibile costruire il comportamento dell'interfaccia grafica (GUI,
Graphical User Interface) in modo più semplice e inoltre permette la comunicazione tra
componenti che richiederebbero un cablaggio complesso se si usassero solamente le regole
del C++.
È possibile anche servirsi delle librerie Qt senza dover necessariamente scaricare anche il
Qt Creator.
Figura 4.4 - L'interfaccia operatore durante lo sviluppo (nel Qt Designer)
4.1.2 Il design pattern MVC e la sua variante
Per design pattern si intende un insieme di accorgimenti, metodologie e architetture di
progettazione software volte alla prevenzione di problemi comuni nel ciclo di vita del
software. Un design pattern non è un concetto limitato al solo ambito dell'ingegneria del
software ma trova applicazione anche in qualsiasi altra branca dove sia necessaria della
progettazione. Un design pattern può essere visto come una raccolta di soluzioni di alto
livello che vanno implementate in modo sempre diverso a seconda del caso particolare in
esame. Queste soluzioni sono frutto dell'esperienza progettuale comune di cui si garantisce
così il riutilizzo e sollevano dal compito di trovare soluzioni a problemi comuni e noti alla
comunità dei progettisti.
Nello specifico, un design pattern in ingegneria del software fornisce soluzioni a
problemi di programmazione noti: per esempio ci si può servire di un design pattern che
risolve un problema di visibilità e comunicazione tra componenti che vanno mantenute
separate, oppure può servire per la corretta progettazione di una componente il cui solo
76
Rosario Santoro
scopo è l'osservazione di altre, oppure ancora garantisce un'elevata manutenibilità del codice
nell'ottica di futuri aggiornamenti e fix. In altre parole, l'adozione di un design pattern è una
caratteristica necessaria in un software di qualità, dove per qualità si intendono anche aspetti
che riguardano tutto il ciclo di vita del software.
Figura 4.5 - Semplice schema del design pattern MVC (puro)
Figura 4.6 - Il design pattern MVC (puro) con interazioni e compiti per ciascuna delle tre componenti40
Nel progetto dell'interfaccia operatore in Qt, il candidato ha scelto di implementare il
design pattern architetturale Model-View-Controller (Figura 4.5) il cui scopo è la
40
http://lkubaski.files.wordpress.com/2012/12/mvc1.gif
77
Rosario Santoro
separazione e comunicazione tra i tre livelli tipici di un'applicazione: livello dati, livello
della logica applicativa e il livello di presentazione. La logica dell'applicazione è
implementata nel "controller", il livello dei dati nel "model" mentre la "view" si occupa della
presentazione.
Nell'ottica del progetto il candidato ha ritenuto opportuno apportare alcune modifiche a
questo pattern. L'ostacolo maggiore da superare è stata la gestione di più di una vista nel
sistema: infatti, all'interfaccia operatore possono essere collegati diversi visualizzatori, siano
essi a realtà virtuale o in una normale finestra, mentre il design pattern MVC puro prevede la
gestione di una sola interfaccia utente.
Figura 4.7 - Il design pattern MVC modificato dal candidato.
La componente View diventa un aggregatore e gateway di viste.
La soluzione è stata la modifica della componente "view" in una sorta di gateway per le
view (da cui "vieway", Figura 4.7) a cui un visualizzatore esterno si connette via TCP e ne
inizia a ricevere i dati. Internamente, il nuovo componente "vieway" si comporta
esattamente come una view classica evitando così che il controller o il model subiscano
modifiche nel loro comportamento e nella comunicazione.
In teoria non sono posti limiti al numero di visualizzatori della scena simulata a patto
però che siano in grado di operare con il protocollo discusso al paragrafo 4.2.4. Dal lato
implementativo, allo stato delle cose, il sistema accetta solo due connessioni TCP alla volta,
sulle porte 6001 e 6002, dove rispettivamente si attende la connessione della scena esportata
per Oculus Rift e la connessione dell'anteprima operatore (cfr. Figura 2.2).
78
Rosario Santoro
4.1.3 Il diagramma delle classi
Figura 4.8 - Diagramma delle classi UML dell'interfaccia operatore Qt
79
Rosario Santoro
In riferimento al diagramma delle classi in Figura 4.8, verrà ora spiegato il contenuto
delle classi più importanti.
4.1.3.1 RV_controller
La classe RV_controller svolge il ruolo di controller nell'ottica MVC ed è l'interfaccia
grafica dell'applicazione scritta con il Qt Creator: essa dunque contiene anche i segnali e gli
slot necessari al funzionamento della stessa (segnali quali la pressione di un pulsante della
GUI).
Questa classe conserva i riferimenti agli eseguibili delle scene Unity 3D dell'ambiente
virtuale e ne gestisce l'intero processo, dall'avvio fino al termine (attraverso la classe
QProcess). Inoltre, ci sono due timer (istanze della classe QTimer) che si occupano di
inviare ogni minuto dei messaggi di controllo della connessione alle viste collegate
(messaggio "check", vedere 4.2.4).
4.1.3.2 RV_model
Implementa il model dell'MVC e di conseguenza è responsabile della conservazione,
aggiornamento e comunicazione dello stato corrente del mondo. Essa conserva una lista di
riferimenti ad oggetti derivati dalla classe "Stimulus", in questo caso "Solid", "Light",
"Audio" (QList<Stimulus*>), di cui ne permette l'aggiunta; inoltre memorizza il percorso e
il nome del file xml contenente la configurazione iniziale del mondo (xmlPath).
In fase d'inizializzazione dell'intera interfaccia operatore, un riferimento a questa classe è
passato dal controller alla componente "vieway" in modo tale che quest'ultimo possa
richiedere, in fase di commit delle modifiche, la configurazione corrente degli stimoli in
formato JSON e includerla nel messaggio in fase di invio. Di conseguenza, è la componente
dove avviene la conversione dell'array degli stimoli in JSON (si rimanda a per i dettagli
4.2.2).
Istanziata dal controller, durante l'esecuzione del programma ne è sempre presente una e
una sola istanza.
4.1.3.3 RV_vieway
È l'aggregatore delle viste e riveste il ruolo di "view" nel contesto del design pattern
MVC. Si occupa dei server e socket TCP (QTcpServer e QTcpSocket) gestendone la
variazione di stato e la connessione/disconnessione dei client visualizzatori. Riceve il
80
Rosario Santoro
comando di commit delle modifiche dall'interfaccia operatore e si occupa di inviare i
messaggi JSON a ciascuna vista connessa.
Conserva un riferimento all'unica istanza del model e un riferimento ad un oggetto di
classe CommPack.
4.1.3.4 CommPack
La classe Communication Packet (abbreviata in CommPack) rappresenta un messaggio
nel formato previsto in 4.2.4 e contiene i campi "method", "error" e "content" il cui
significato è spiegato nel paragrafo 4.2.4, oltre ai comuni metodi get/set. Contiene il metodo
di conversione del messaggio in formato JSON che viene invocato durante l'invio fisico dei
dati in rete; dualmente, è in grado di convertire un messaggio JSON in un'istanza della
classe CommPack permettendo così l'accesso ai campi method ed error del messaggio di
risposta di uno dei client.
4.1.3.5 Stimulus
La classe Stimulus non viene mai istanziata direttamente ma è la classe base da cui
vengono derivate le classi che implementano gli stimoli reali. Essa contiene due campi di
fondamentale importanza, l'identificativo ("id") e la tipologia di stimolo ("type"): tali campi
vengono avvalorati nel costruttore delle classi e in seguito possono solo essere letti.
4.1.3.6 Le classi derivate da Stimulus
Le classi che implementano gli stimoli reali corrispondono agli stimoli previsti
attualmente dal progetto (cfr. paragrafo 3.5).
struct _pos{
float x;
float y;
float z;
};
struct _rot{
float x;
float y;
float z;
};
struct _col{
unsigned char r;
unsigned char g;
unsigned char b;
float a;
};
struct _size{
float dx;
float dy;
float dz;
};
Listato 4.1 - Le strutture impiegate nel progetto (sia Qt sia Unity3D):
rispettivamente posizione, colore, rotazione e dimensione.
81
Rosario Santoro
4.1.4 L'aspetto della GUI
Figura 4.9 - L'interfaccia Qt di controllo del mondo virtuale
In Figura 4.9 è rappresentata la GUI dell'operatore. Essa è composta da tre parti
principali: l'elenco degli stimoli, la configurazione di uno stimolo e i comandi.
La parte dei comandi offre all'operatore la possibilità di caricare un file XML contenente
la configurazione degli stimoli nel mondo virtuale (in qualsiasi momento dell'esecuzione)
mediante il pulsante "Load XML description": a lettura completata, la lista degli stimoli
viene svuotata e ripopolata.
I pulsanti "Start OVR" e "Start Preview" avviano (e osservano lo stato) l'eseguibile della
scena, rispettivamente stereoscopica e normale, nel caso in cui si utilizzi la configurazione in
localhost dei visualizzatori (si rimanda al paragrafo 2.3).
Per il controllo della scena virtuale e per il suo eventuale roll-back si utilizzano i pulsanti
"Revert..", "Preview.." e "Commit". La funzione della preview permette di mostrare le
modifiche al mondo solo nella scena di anteprima dell'operatore (la scena del paziente non
subisce modifiche); i pulsanti "Commit" e "Revert" rispettivamente rendono effettive o
comandano il roll-back delle modifiche anche al visore virtuale del paziente.
Per configurare uno stimolo è sufficiente che l'operatore ne selezioni uno dall'elenco e la
schermata accanto verrà popolata con gli adeguati comandi, a seconda della tipologia dello
stimolo (Figura 4.10).
È bene notare che la GUI deve essere in esecuzione prima delle scene virtuali in quanto
funge da server: inoltre, è opportuno conoscere le regole del firewall della macchina su cui è
in esecuzione e modificarle in modo tale che le porte 6001 e 6002 risultino aperte.
82
Rosario Santoro
Figura 4.10 - La GUI dopo aver letto il file XML descrittivo del prototipo della scena in Figura 3.51
4.2 La comunicazione
4.2.1 Il formato JSON
JavaScript Object Notation41 è un formato di descrizione e di interscambio di dati
standardizzato nel 1999 che si basa su Unicode e sulla sintassi di descrizione degli oggetti in
JavaScript (linguaggio di client-side scripting nelle pagine web). È inoltre di facile
comprensione per gli umani (human-readable).
Si consideri il seguente codice javascript.
var num = 4;
var arr = ["lun","mar","mer","gio","ven"];
var obj = {"qty": 5};
arr.push("sab");
obj.what = "days";
obj.content = arr;
obj.qty++;
console.log(obj);
41
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
83
Rosario Santoro
L'output in console dell'oggetto "obj" sarebbe il seguente:
obj = {
"qty": 12,
"what": "days",
"arr": ["lun","mar","mer","gio","ven"]
};
Questa notazione propria di Javascript è lo standard di notazione degli oggetti JSON.
Nonostante la sintassi semplice permette di rappresentare oggetti di qualsivoglia complessità
e permette la gestione di diversi tipi di dato quali numeri (interi e decimali), array di oggetti,
oggetti, stringhe e valori booleani.
Un altro vantaggio di JSON è la possibilità di essere trasformato in stringa, eliminando
spazi e line feed e preparandolo quindi all'invio in rete o alla semplice memorizzazione.
JSON rappresenta un'alternativa ad XML e i linguaggi per la sua manipolazione come
l'XSLT ed è molto usato come formato di interscambio dati.
Citando un'applicazione, JSON è il formato con il quale vengono restituiti i risultati delle
richieste di geocodifica inverse di Google Maps: è possibile impiegare anche XML ma
Google stesso suggerisce l'uso di JSON [21].
var jsonString = JSON.stringify(obj);
In Javascript è possibile convertire un oggetto arbitrario in una stringa JSON mediante il
metodo "stringify" e il processo intero prende il nome di serializzazione. L'operazione
inversa è detta deserializzazione e la si esegue con il metodo "parse".
Negli altri linguaggi è necessario ricorrere a librerie esterne per interpretare e convertire
correttamente dati in formato JSON: ne esistono diverse per ogni linguaggio (C, C++, Qt,
Java, Objective C, C#, ...). Si rimanda alle fonti per una lista completa [22].
Figura 4.11 - Sintassi JSON di un oggetto
Figura 4.12 - Sintassi JSON di un array
84
Rosario Santoro
Figura 4.13 - Sintassi JSON di un numero
Figura 4.14 - Sintassi JSON di un valore
Figura 4.15 - Sintassi JSON di una stringa
4.2.2 Integrazione in Qt Creator
Il Qt 5 offre già delle classi in grado di gestire il formato JSON e le sue conversioni:
QJsonDocument, QJsonObject, QJsonArray, QJsonValue.
QJsonDocument ingloba l'intera struttura dati da convertire in JSON o appena convertita
da JSON. Questa struttura comincia sempre con un QJsonObject (oggetto JSON) che
costituisce l'oggetto radice e al suo interno può avere un qualsiasi numero di oggetti
85
Rosario Santoro
(QJsonObject), array (QJsonArray) e valori semplici (QJsonValue) siano essi stringhe o
numeri.
4.2.3 Integrazione in Unity 3D e C#
Il C# non dispone di un supporto nativo al JSON e dunque si è dovuto fare ricorso ad una
libreria esterna di nome JSON.NET42 (versione 6.0.2) in formato ".dll" e dunque chiusa.
Questa libreria permette di effettuare la conversione JSON con una sola riga di codice, al
contrario di quanto avviene in Qt in cui bisogna servirsi di qualche struttura di controllo in
più.
CommPack comm = JsonConvert.DeserializeObject<CommPack> (jsonrx);
String json = JsonConvert.SerializeObject(comm);
Queste due linee di codice si occupano rispettivamente della conversione di una stringa
JSON in una struttura interna C# e della conversione di un oggetto in stringa JSON. Si badi
che gli attributi della classe da scrivere nella deserializzazione devono essere tutti dotati dei
comuni metodi di accesso get e set.
I vettori scritti e letti in C# sono dichiarati con le "List" come segue:
public List<StimulusCommon> stimuli { get; set; }
4.2.4 Il protocollo di comunicazione in JSON
Listato 4.2 - Esempio di messaggio scambiato tra server e client durante la macrofase online
msg = {
"method" : "edit" | "reply" | "check",
"error": null | "error_reason",
"content" : [
{"id": "obj_id",
"type": "<obj_type_as_listed_in_XML>",
"col" : {"r": 255, "g": 0, "b":100, "a": 1},
"pos" : {"x": 0, "y": 0, "z":0},
"rot" : {"x": 0, "y": 90, "z":0},
"size" : {"dx": 2, "dy": 2, "dz":2},
},
...
]
};
42
http://james.newtonking.com/json
86
Rosario Santoro
Una volta scelto JSON come formattazione dei messaggi scambiati, sono stati messi a
punto una serie di comandi comprensibili da tutti gli attori che partecipano alla
comunicazione. A tal proposito il candidato ha sviluppato un semplice protocollo di
comunicazione tra il server e i client nello scenario del progetto.
Il protocollo prevede che un messaggio scambiato abbia sempre i tre seguenti campi:

"method": è una stringa che indica lo scopo del messaggio ed è sempre presente. Può
assumere tre valori:
 "edit": il messaggio comporta una modifica alla configurazione dell'ambiente
virtuale. Il campo "content" non potrà essere vuoto e conterrà i dettagli di tale
modifica.
 "reply": il messaggio che temporalmente segue sempre un messaggio con
method "edit". Il suo scopo è di dare conferma dell'avvenuta modifica dei
parametri del mondo come indicato nell'ultimo comando di modifica.
 "check": serve a verificare la presenza di connessione ed è periodicamente
(~1min) inviato dal server a tutti i client. La risposta a tale messaggio ha
anch'essa method "check". Una sequenza di due check, il primo in un verso e il
secondo nell'altro, asserisce il corretto funzionamento della connessione tra il
server e uno dei client.

"error": stringa che indica l'eventuale presenza di un errore. Tipicamente, un errore
può aver luogo in risposta ad un messaggio "edit" con indicazioni di modifica che
portano il mondo in una configurazione errata, come per esempio la sovrapposizione
di due solidi o lo spostamento di una fonte luminosa al di fuori dei confini della casa.
In un messaggio di "reply" senza errori, tale campo non ha valore (null).

"content": è un vettore di oggetti istanze delle classi degli stimoli implementati,
come solido, audio o luce (si rimanda a 3.5 per l'elenco completo degli stimoli e
4.1.3 per le rispettive classi). È avvalorato solo in un messaggio di tipo "edit" e
contiene l'elenco degli stimoli da modificare: per ciascuno di questi, sono elencate
solo le proprietà da variare e il relativo nuovo valore. Quest'approccio permette
quindi di avere messaggi concisi, intendendo con ciò la non necessità di ritrasmettere
tutte quelle proprietà che durante una commit non cambiano valore e, in modo
simile, si evita anche di ritrasmettere i dettagli di quegli oggetti non coinvolti nella
modifica. Ciascun oggetto eventualmente presente in questo vettore dovrà avere al
87
Rosario Santoro
suo interno obbligatoriamente l'identificativo univoco dell'oggetto nel mondo virtuale
("id"), il tipo di oggetto di cui è istanza43 ("type") e almeno una delle proprietà
dell'oggetto con un valore associato, sempre in accordo alle associazioni oggettoproprietà modificabili elencate nel file .xml di configurazione (paragrafo 3.4.4).
43
In questo contesto, oggetto e istanza non sono usati nello slang della programmazione, ma in riferimento
ad oggetti rappresentati in Unity 3D.
88
Sviluppi futuri
Rosario Santoro
5 SVILUPPI FUTURI
5.1 Altri stimoli
Gli stimoli correntemente implementati nel sistema, cioè solido, audio e luce, non
rappresentano ovviamente l'intera gamma di oggetti su cui realmente si può agire per
osservare i cambiamenti di stati d'animo del paziente.
Potrebbero essere aggiunti stimoli i seguenti stimoli.

Finestra. Posizione fissa, colore e in particolare la trasparenza modificabili, meglio
se in funzione delle ore della giornata, in modo tale da adattarsi ai cambiamenti di
luce esterna.

Animazione. Potrebbe trattarsi del volo di un insetto o di una tenda mossa dal vento.
Se ne potrebbe impostare l'attivazione o meno oppure l'evidenza del movimento.

Percorsi luminosi. Per una certa tipologia di pazienti sarebbe opportuno tracciare
dei percorsi luminosi verso stanze dell'appartamento che rivestono particolare
importanza, come un bagno, la cucina o la camera da letto. Questi percorsi
dovrebbero essere disegnati lungo l'intero corridoio e dovrebbero essere collegati
fino all'infisso della stanza di destinazione; se ne potrebbe impostare la presenza o
meno, il colore e un qualche effetto luminoso come il lampeggio.
5.2 Maggiore attività da parte del paziente
Nella configurazione corrente del progetto il soggetto osservato assume un ruolo
prevalentemente statico, intendendo con ciò che durante l'esperienza virtuale non gli è
richiesto alcun movimento del corpo all'infuori della rotazione della testa per esplorare
l'ambiente tramite l'Oculus Rift.
89
Sviluppi futuri
Rosario Santoro
A seconda del degrado psico-motorio del paziente, possono essere previsti diversi livelli
di interazione con il mondo, partendo dal semplice movimento in avanti e indietro nel
mondo attraverso le freccette di una tastiera, fino all'interazione specializzata con diversi
oggetti (alzare tapparelle, chiudere porte, ...). Sia il movimento sia l'interazione possono
essere gestite attraverso il Leap Motion, quindi con movimenti o gesti delle mani.
Figura 5.1 - La piattaforma di movimento Virtuix Omni
Un elevato livello di attività del paziente può essere raggiunto mediante l'uso di apposite
bascule, vere e proprie pedane limitate da un cerchio dove l'utente può muoversi esattamente
come se stesse camminando, con la differenza che è il pavimento (una piccola superficie
mobile) a spostarsi rispetto a lui e non viceversa: queste pedane vanno interfacciate e gestite
in Unity o nel motore di gioco preferito per propagare il movimento al game object
dell'utente. In Figura 5.1 è rappresentata la piattaforma di movimento Virtuix Omni44
sviluppata da Jan Goetgeluk attraverso una raccolta fondi su Kickstarter, presentata al CES
di Las Vegas nel 2014 e attualmente in pre-ordine a 500$ (completa di accessori, come delle
scarpe con la suola ad attrito ridotto per il rilevamento del movimento delle gambe).
44
http://www.virtuix.com/
90
Rosario Santoro
Sviluppi futuri
5.3 Ingombro dell'Oculus VR
Il peso e l'ingombro dell'Oculus Rift non sono eccessivi se usato in maniera standalone,
ma nello scenario del presente progetto, e quindi considerando il caschetto con gli elettrodi
dell'encefalogramma, può risultare difficile la presenza di entrambi questi dispositivi sulla
testa del paziente. Non sono da sottovalutare anche eventuali fastidi o riluttanza da parte dei
pazienti stessi ad indossare un visore di realtà virtuale.
Ulteriore ricerche nell'ambito del progetto dovrebbero perciò portare alla scelta di visori
RV meno ingombranti: il Crystal Cove di Figura 3.39, riducendo le proprie dimensioni, si
candida a successore dell'Oculus Rift.
5.4 Il sistema come Web Service
La possibilità di collegare visualizzatori via TCP, l'architettura client/server e il
caricamento della descrizione degli stimoli per mezzo di un file XML indicano la strada per
un'eventuale evoluzione come web service.
Il candidato avrebbe infatti potuto usare esclusivamente JSON per la descrizione delle
scene, in quanto il formato dei messaggi era già stato progettato con quella notazione, ma
proprio per non precludersi questa strada è stato adottato anche l'XML come descrizione
degli stimoli. Converrebbe inoltre a quel punto che la descrizione XML non fosse limitata
esclusivamente agli stimoli ma coinvolgesse tutta la scena, dalle pareti agli oggetti (stimoli e
non).
Il servizio offerto potrebbe essere inizialmente quello di memorizzazione della
configurazione corrente di un ambiente (non solo in ambito medico, si veda il paragrafo 5.6)
per ciascun cliente registrato su quest'ipotetica piattaforma.
5.5 Descrizione delle scene 3D mediante X3D
Recentemente si è osservato un aumento delle estensioni di XML e, tra queste, ne è in
fase di standardizzazione una il cui compito è la definizione di scene tridimensionali, cioè
l'X3D.
91
Sviluppi futuri
Rosario Santoro
Figura 5.2 - Logo del formato X3D
L'X3D45 è diretto discendente del VRML46 ed è uno standard ISO47 per la
rappresentazione di computer grafica 3D. E' in grado di descrivere poligoni, punti, mesh e
texture UV. Inoltre, permette di specificare le caratteristiche della visuale, permettendo con
apposite proprietà di impostare una visualizzazione stereoscopica, pronta per essere fruita
mediante Oculus Rift.
L'X3D è un formato leggibile con apposite applicazioni (Instant Reality, per citarne una)
o con comuni strumenti di modeling (Blender, MeshLab). Per un file d'esempio si rimanda
all'Appendice 7.1. Questo formato potrebbe essere usato assieme all'architettura web service
esposta in 5.4.
5.6 Altri utilizzi del sistema
Il settore dove questo lavoro di tesi trova applicazione è a metà tra il medico e il
domotico.
Possono
essere
prese
in
considerazione
applicazioni
esclusivamente
architettoniche di questo sistema di realtà virtuale modificabile a runtime: infatti, uno studio
di architettura potrebbe servirsene per presentare ai propri clienti i risultati del proprio
lavoro in termini di strutturazioni e disegno di ambienti. L'esperienza e la soddisfazione del
cliente risulterebbe così aumentata.
45
www.web3d.org/x3d
Virtual Reality Modeling Language
47
ISO/IEC 19775/19776/19777
46
92
Sviluppi futuri
Rosario Santoro
5.7 Cronologia delle modifiche all'ambiente
L'interfaccia operatore del sistema può essere migliorata in termini estetici e in parte
anche
funzionali,
per
esempio
dotandola
dell'annullamento/ripetizione
dell'ultima
operazione e il ripristino di configurazioni del mondo virtuale salvate in precedenza.
93
Conclusioni
Rosario Santoro
6 CONCLUSIONI
In questo lavoro di tesi, il candidato ha progettato un prototipo di un sistema di realtà
virtuale il cui scopo è la modifica dei dettagli architettonici e di arredamento degli ambienti
vitali di un paziente affetto da un disturbo allo stadio iniziale, sulla base dell'individuazione
di una configurazione tale che generi il minor stress.
Questo sistema è dunque volto alla riqualificazione degli ambienti vitali di questa
categoria di soggetti e, data per certa l'esistenza di una configurazione di stress minimo, il
candidato ritiene possibile migliorare le condizioni di vita e di stato d'animo dei pazienti e
assisterli e monitorarli nel corso dell'evoluzione della malattia.
Le caratteristiche di questo sistema permettono l'adozione di altri tipi di architetture e
tecnologie e può altresì essere impiegato in ambiti diversi da quello della riqualificazione
architettonica.
Considerati gli avanzamenti tecnologici nel campo dei visori di realtà virtuale, con il
passare del tempo soluzioni sempre più innovative aumenteranno l'immersività e
l'esperienza utente.
94
Appendice
Rosario Santoro
7 APPENDICE
7.1 Contenuto X3D d'esempio
<X3D profile='Interchange' version='3.0'
xmlns:xsd='http://www.w3.org/2001/XMLSchema-instance'
xsd:noNamespaceSchemaLocation='http://www.web3d.org/specifications/x3d3.0.xsd'>
<head>
...
</head>
<Scene>
<Viewpoint description='Front view, 4 inches above ground'
position='0 4 20'/>
<Viewpoint description='Side view, 6 inches above ground'
orientation='0 1 0 1.57' position='25 6 0'/>
<Viewpoint description='Top-down view, 20 inches above'
orientation='1 0 0 -1.57' position='0 28 0'/>
<Background groundAngle='1.309 1.571' groundColor='0.1 0.1 0 0.4
0.25 0.2 0.6 0.6 0.6' skyAngle='1.309 1.571' skyColor='0 0.2 0.7 0 0.5 1 1
1 1'/>
<Transform translation='0 8 0'>
<Group DEF='Road'>
<Shape>
<Box size='20 0.2 7'/>
<Appearance DEF='GreyAppearance'>
<Material diffuseColor='0.4 0.4 0.4'/>
</Appearance>
</Shape>
<Transform translation='0 0.2 0.3'>
<Shape DEF='WhiteLine'>
<Box size='20 0.01 0.4'/>
<Appearance DEF='WhiteAppearance'>
<Material diffuseColor='1 1 1' emissiveColor='0.5 0.5
0.5'/>
</Appearance>
</Shape>
</Transform>
<Transform translation='0 0.2 -0.3'>
<Shape USE='WhiteLine'/>
</Transform>
</Group>
</Transform>
<Transform rotation='0 1 0 1.57' translation='0 0.1 0'>
<Group USE='Road'/>
</Transform>
95
Rosario Santoro
Appendice
<Transform DEF='ColumnA' translation='-6 4 -2'>
<Shape DEF='Column'>
<Cylinder height='8' radius='1'/>
<Appearance USE='GreyAppearance'/>
</Shape>
</Transform>
<Transform DEF='ColumnB' translation='6 4 -2'>
<Shape USE='Column'/>
</Transform>
<Transform DEF='ColumnC' translation='-6 4 2'>
</Transform>
<Transform DEF='ColumnD' translation='6 4 2'>
</Transform>
</Scene>
</X3D>
96
<Bibliografia
Rosario Santoro
8 BIBLIOGRAFIA
[1]
Wikipedia, «Projection augmented model,» 2014. [Online]. Available:
http://en.wikipedia.org/w/index.php?title=Projection_augmented_model&oldid=59
0140280.
[2]
J. W. Burke, M. J. McNeill, D. K. Charles, P. J. Morrow, J. Crosbie e S. M.
McDonough, «Serious Games for Upper Limb Rehabilitation Following Stroke,»
in Games and Virtual Worlds for Serious Applications, 2009. VS-GAMES '09.
Conference in, Coventry, 2009.
[3]
D. A. Das, K. A. Grimmer, A. L. Sparnon, S. E. McRae e B. H. Thomas, «The
efficacy of playing a virtual reality game in modulating pain for children with acute
burn injuries: A randomized controlled trial,» BMC Pediatrics, 2005.
[4]
A. Innocenti, «La Toscana punta sulla ricerca: 26 progetti per oltre 14 milioni,»
17
Dicembre
2013.
[Online].
Available:
http://www.regione.toscana.it/documents/10180/23830/Regione17122013.pptx/41c
79005-0f6d-490f-bd83-48e7fe7c19a4. [Consultato il giorno 3 Aprile 2014].
[5]
J. W. Grier, «eHeart: an introduction to ECG/EKG (for students, teachers and
other
interested
persons),»
2008.
[Online].
Available:
http://www.ndsu.edu/pubweb/~grier/eheart.html. [Consultato il giorno 3 Aprile
2014].
[6]
W. O. Tatum, A. M. Husain, S. R. Benbadis e P. W. Kaplan, in EEG
interpretation, Demos, 2008.
[7]
J. Luc, «Electromyography: MedlinePlus Medical Encyclopedia,» 10 Settembre
2012.
[Online].
http://www.nlm.nih.gov/medlineplus/ency/article/003929.htm.
Available:
[Consultato
il
giorno 3 Aprile 2014].
97
<Bibliografia
Rosario Santoro
[8]
T. Musha, Y. Terasaki, H. A. Haque e G. A. Ivanitsky, «Feature extraction from
EEGs associated with emotions,» Artificial Life and Robotics, 1996.
[9]
R. Costin, C. Rotariu e A. Pasarica, «Mental stress detection using heart rate
variability and morphologic variability of EeG signals,» in Electrical and Power
Engineering (EPE), 2012 International Conference and Exposition on, Iasi, 2012.
[10]
D. McAllister, «Display technology: Stereo & 3D display technologies,» 2005.
[Online].
Available:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.7.2388&rep=rep1&type
=pdf.
[11]
A. J. Woods e C. R. Harris, «Comparing levels of crosstalk with red/cyan,
blue/yellow, and green/magenta anaglyph 3D glasses,» in Stereoscopic Displays
and Applications XXI , San Jose, California, 2010.
[12]
P. Merkle, K. Muller e T. Wiegand, «3D video: acquisition, coding, and
display,» Consumer Electronics, IEEE Transactions on, 2010.
[13]
A. Smolic, K. Mueller, P. Merkle, C. Fehn, P. Kauff e T. Wiegand, «3D Video
and Free Viewpoint Video - Technologies, Applications and MPEG Standards,»
Multimedia and Expo, 2006 IEEE International Conference on, 2006.
[14]
Z. Liang e W. J. Tam, «Stereoscopic image generation based on depth images
for 3D TV,» Broadcasting, IEEE Transactions on, 2005.
[15]
S. Schuon, C. Theobalt, J. Davis e S. Thrun, «High-Quality Scanning Using
Time-Of-Flight Depth Superresolution,» IEEE Computer Society Conference on
Computer Vision and Pattern Recognition Workshops, 15 Luglio 2008.
[16]
D. C. Lee, A. Gupta, M. Herbert e T. Kanade, «Estimating spatial layout of
rooms using volumetric reasoning about objects and surfaces,» 2010.
[17]
G. Miller, «We Mapped Our Boss’ Office With This Slick New 3-D Camera,»
13 Marzo 2014. [Online]. Available: http://www.wired.com/2014/03/matterportoffice-map/. [Consultato il giorno 2 Aprile 2014].
[18]
N. Roli, «Project Tango: nuovi dettagli sulle 4 fotocamere presenti nel
prototipo,»
15
Marzo
2014.
[Online].
Available:
http://android.hdblog.it/2014/03/15/project-tango-nuovi-dettagli-sulle-4-
98
<Bibliografia
Rosario Santoro
fotocamere-presenti-nel-prototipo/. [Consultato il giorno 8 Aprile 2014].
[19]
M. Pesce, «CES 2014, prima prova di Oculus Rift Crystal Cove,» 13 Gennaio
2014. [Online]. Available: http://www.wired.it/gadget/videogiochi/2014/01/13/ces2014-prova-oculus-rift-crystal-cove/. [Consultato il giorno 11 Febbraio 2014].
[20]
S. Pennacchini, «Facebook ora punta alla realtà virtuale "social": rileva Oculus
per
2
miliardi
di
dollari,»
25
Marzo
2014.
[Online].
Available:
http://www.repubblica.it/tecnologia/2014/03/25/news/facebook_rileva_oculus_per
_2_miliardi_di_dollari-81895590/. [Consultato il giorno 25 Marzo 2014].
[21]
Google, «Richieste di geocodifica, Google Maps,» 2013. [Online]. Available:
https://developers.google.com/maps/documentation/geocoding/#GeocodingRequest
s.
[22]
ECMA, dicembre 1999. [Online]. Available: http://json.org/.
[23]
F. G. Yanowitz, «Introduction to ECG interpretation,» Luglio 2012. [Online].
Available: http://ecg.utah.edu/pdf/. [Consultato il giorno 2 Aprile 2014].
99
Ringraziamenti
In queste pagine con cui concludo la mia tesi e simbolicamente la mia carriera da studente,
desidero rivolgere dei ringraziamenti.
Ringrazio il prof. Vitoantonio Bevilacqua, preziosa e paziente guida nel mio lavoro di tesi e nel
mio periodo universitario finale, per avermi concesso fiducia dandomi l'occasione di mettermi alla
prova. Allo stesso modo ringrazio il dott. Michele Pantaleo per i consigli e le indicazioni che mi ha
pazientemente fornito. Un ringraziamento particolare va anche alla prof.ssa Marina De Tommaso.
Un grazie di cuore lo rivolgo ai miei genitori sempre presenti, alla mia famiglia, alle nonne e
agli zii, con un pensiero particolare per Michela a cui auguro di trovare presto la propria strada e
di seguirla con convinzione e perseveranza.
Ringrazio Gianpaolo con la certezza di non essere in grado di ridurre in poche righe la grande
stima, riconoscenza e affetto che nutro nei suoi confronti. Tra giornate e nottate sui progetti
accademici e non, serate filosofiche a discutere di passato, presente e futuro, viaggi di qualche
centinaio di km e qualche miliardo di anni luce, mi ha aiutato a conoscere me stesso.
Ringrazio Filippo, Stefano, Francesca e Sabrina per le serate e le risate nei weekend foggiani.
Ringrazio le persone con cui ho condiviso un tetto in questi anni in casa Marasha, casa
Pizzigallo e casa Vannella. Grazie a Daniele, Massimo, Danilo e Davide che dopo tanto tempo
trascorso assieme, tante mangiate, bevute e discussioni mi hanno insegnato, fatto capire molto ed
aiutato a crescere. Grazie a Francesco, Fabrizio, Michele e Benedetto per la loro gentilezza e
disponibilità, a cui auguro che "rimanga sempre un po' di rispetto" e che "le macchine continuino a
fare altre macchine". Grazie a Gabriele, Danilo e Antonello, persone in cui ho scorto in pochi mesi
più educazione e rispetto che molta altra gente in diversi anni.
Ringrazio gli amici e colleghi del laboratorio di informatica industriale, Gianluca, Marco,
Davide, Donato, Domenico P., Domenico C., Nicola N., Gianluca, Vito, Angelo e Carlo persone che
stimo sul lato personale e professionale, dalla cui semplice vicinanza ho imparato e sto imparando
molto. Un ringraziamento particolare lo rivolgo a Dario, disponibile, sempre gentile e prodigo di
consigli. Un grazie a Nicola L. che ha lavorato assieme a me durante lo sviluppo iniziale di questo
progetto. Esprimo gratitudine anche a Silvia che mi ha aiutato e consigliato.
Un grazie speciale va ai colleghi di AMT Giulio, Francesco, Andrea, Gianluca, Duccio, Franco
e Mario sempre allegri e attivi.
Grazie a voi tutti.
Stanotte tira vento e cambia il tempo.

here - Rosario Santoro

Transcript

Documenti analoghi

www.bikecenter.it cinghia trasmissione MICROCAR

Scarica questo file PDF

Blender Corso di software open source per

Presentazione/prefazione

abstract Cameli

Computer Graphics

PDF (solo programma)

Centro di lavoro FANUC Robodrill Alfa T21Fl usato