Università degli Studi di Padova. Progetto Tango: Modellazione 3D

(1)

Università degli Studi di Padova

Dipartimento di Matematica

Corso di Laurea in Informatica

Progetto Tango: Modellazione 3D

Tesi di laurea triennale

Relatore

Prof. Tullio Vardanega

Laureando Antonio Iacobucci

Anno Accademico 2016-2017

(2)

Antonio Iacobucci: Progetto Tango: Modellazione 3D , Tesi di laurea triennale, c Apr 2017.

(3)

Words are flowing out like endless rain into a paper cup, they slither while they pass, they slip away across the universe.

Pools of sorrow, waves of joy are drifting through my opened mind, possessing and caressing me.

— John Lennon

Esprimo tutta la mia gratitudine al prof. Tullio Vardanega, relatore della mia tesi, per il sostegno, i consigli e il tempo dedicatomi durante la stesura della tesi.

Ringrazio infinitamente i miei genitori, mio fratello e mio nonno per la fiducia e la pazienza in questi anni.

Infine ringrazio tutti i miei coinquilini e amici che mi hanno supportato e sopportato per tutto questo tempo, un caloroso abbraccio va a tutti voi.

(4)

(5)

Introduzione

Il presente documento descrive il lavoro svolto durante il periodo di stage dal laureando Antonio Iacobucci presso l’azienda VIC S.r.l. della durata di trecentododici ore.

Il progetto di stage si propone di analizzare lo stato del Progetto Tango di Google e comprenderne i limiti e i punti di forza, al fine di sviluppare l’architettura ed un primo modulo di una applicazione che permetta di ottenere il modello tridimesionale di un oggetto e confrontarlo con un modello predefinito. L’obiettivo ultimo è quello di verificare la presenza di anomalie tra l’oggetto in questione ed il modello dato e valutare la percentuale di discrepanza tra i due. Questa architettura verrà utilizzata nel campo delle ispezioni merceologiche per valutare in tempo reale la conformità della merce a quanto richiesto dal cliente.

I capitoli saranno così suddivisi:

Il primo capitolo descrive il contesto aziendale all’interno del quale è stato effettuato lo stage, le finalità del progetto di stage, obiettivi, pianificazione e vincoli.

Il secondo capitolo descrive lo svolgimento effettivo del progetto affrontando lo studio dello stato dell’arte del dispositivo, analisi dei requisiti e progettazione del software.

Il terzo capitolo conterrà le conclusioni relative all’esperienza di stage svolta, trat- tando il raggiungimento degli obiettivi, le conoscenze acquisite e valutazioni retrospettive sulle attività svolte.

Organizzazione del testo

Riguardo la stesura del testo, relativamente al documento sono state adottate le seguenti convenzioni tipografiche:

• gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzio- nati vengono definiti nel glossario, situato alla fine del presente documento;

• per la prima occorrenza dei termini riportati nel glossario viene utilizzata la seguente nomenclatura: parola^[g];

• i termini in lingua straniera o facenti parti del gergo tecnico sono evidenziati con il carattere corsivo;

v

(6)

vi

• le parole per le quali è presente una voce bibliografica sono caratterizzate da un apice numerico con riferimento in fondo alla pagina in cui sono menzionate.

(7)

Indice

1 Descrizione dello stage 1

1.1 Contesto aziendale . . . 1

1.1.1 Principali servizi e prodotti . . . 1

1.1.2 Processi aziendali . . . 2

1.1.3 Rapporto con l’innovazione . . . 3

1.1.4 Stage per studenti laureandi . . . 4

1.2 Rischi di progetto . . . 5

1.3 Obiettivi dello stage . . . 5

1.3.1 Obiettivi aziendali . . . 5

1.3.2 Obiettivi personali . . . 6

1.4 Pianificazione e vincoli . . . 7

2 Svolgimento del progetto 11 2.1 Studio progetto . . . 11

2.1.1 Studio API . . . 17

2.1.2 Test e prototipi . . . 19

2.1.3 Periodo di formazione . . . 21

2.2 Ricerca e analisi librerie open source utilizzabili . . . 22

2.2.1 Librerie Grafiche . . . 22

2.2.2 Librerie Ausiliarie . . . 23

2.2.3 Analisi Strumenti Individuati . . . 29

2.3 Analisi dei requisiti . . . 31

2.3.1 Descrizione generale . . . 31

2.3.2 Casi d’uso . . . 32

2.3.3 Tracciamento dei requisiti . . . 36

2.4 Progettazione . . . 37

2.4.1 Tecnologie utilizzabili . . . 37

2.4.2 Descrizione architettura . . . 41

2.4.3 Progettazione modulo . . . 46

2.4.4 Software e documenti prodotti . . . 48

2.5 Verifica e validazione . . . 50

3 Conclusioni 53 3.1 Raggiungimento degli obiettivi . . . 53

3.1.1 Obiettivi aziendali . . . 53

3.1.2 Obiettivi personali . . . 55

3.2 Conoscenze acquisite . . . 56 vii

(8)

viii INDICE 3.3 Valutazione personale . . . 57

Glossario 59

Acronimi 61

Bibliografia 63

(9)

Elenco delle figure

1.1 Logo VIC S.r.l. . . 1

1.2 Sedi VIC nel mondo . . . 2

1.3 On the job training . . . 4

1.4 Pianificazione GANTT . . . 7

2.1 Dispositivo Project Tango . . . 12

2.2 Stati della posa (fonte: documentazione Project Tango) . . . 13

2.3 Frame di riferimento (fonte: documentazione Project Tango) . . . 13

2.4 Motion tracking (fonte: documentazione Project Tango) . . . 14

2.5 Drift correction (fonte: documentazione Project Tango) . . . 15

2.6 Localizzazione (fonte: documentazione Project Tango) . . . 15

2.7 Nuvola di punti (fonte: documentazione Project Tango) . . . 16

2.8 Mappa di profondità (fonte: documentazione Project Tango) . . . 16

2.9 TangoService e API (fonte: documentazione API dispositivo) . . . . 17

2.10 Esempio prototipo Unity . . . 18

2.11 Esempio prototipo Java . . . 18

2.12 Esempio prototipo C . . . 19

2.13 Test Unity . . . 20

2.14 Test realtà aumentata . . . 20

2.15 Test profondità . . . 21

2.16 Sistema di coordinate di OpenGL (fonte: documentazione OpenGL) 22 2.17 Creazione superfici da point clouds con PCL (fonte: documentazione PCL) . . . 24

2.18 Modello PCL (fonte: documentazione PCL) . . . 25

2.19 Esempio visualizzazione su KiwiViewer (fonte: documentazione Ki- wiViewer) . . . 25

2.20 Paraview con PCL plugin (fonte: documentazione Paraview) . . . 26

2.21 Paraview con Project Tango (fonte: documentazione Paraview) . . . 26

2.22 Esempio Jzy3d (fonte: documentazione Jzy3d) . . . 27

2.23 Esempi Poly2tri e Clipper (fonte: documentazione Poly2tri e Clipper) 28 2.24 Esempio modello con 3D Utilities (fonte: documentazione ISDA) . . 29

2.25 UC2.1.1 avvio sessione di ispezione . . . 33

2.26 UC2.1.1.3 visualizzazione modello . . . 34

2.27 Diagramma architettura generale . . . 41

2.28 Diagramma design pattern MVP . . . 42

2.29 Diagramma della componente app::client . . . 43

2.30 Diagramma della componente app::client::editor . . . 44 ix

(10)

2.31 Diagramma della componente app::server . . . 46 2.32 Diagramma della classe app::client::model::Model . . . 47 2.33 Diagramma della classe app::client::editor::EditorPresenter . 48 2.34 Esempio test di realizzazione modello 3D . . . 51

Elenco delle tabelle

1.1 Descrizione tecnologie sviluppate da VIC . . . 3 1.2 Distribuzione oraria delle attività del progetto . . . 8 2.1 Soddisfacimento requisiti . . . 51

x

(11)

Capitolo 1

Descrizione dello stage

In questo capitolo saranno trattate le tematiche che introducono il progetto di stage.

Verranno discussi il contesto aziendale, gli obiettivi prefissati dall’azienda e quelli personali. Infine saranno presentati la pianificazione delle attività e i vincoli del progetto.

1.1 Contesto aziendale

1.1.1 Principali servizi e prodotti

L’azienda VIC S.r.l. tramite 10 società operative e più di 50 tra uffici e laboratori nei porti di maggior livello globale, si occupa di ispezioni di merci e certificazioni.

VIC mette a disposizione dei suoi clienti risorse innovative per limitare i rischi del business e salvaguardare gli interessi dei suoi clienti.

Figura 1.1: Logo VIC S.r.l.

L’azienda è stata fondata da Alessio Bisutti nel 2006 ed è presente in tutto il mondo con 21 aziende diverse e sede principale a Venezia. Il dipartimento di ricerca e sviluppo di VIC è situato a Padova e conduce un approfondimento continuo su nuove tecnologie, per poter continuare ad aggiungere un grande ed unico valore ai servizi offerti.

L’azienda offre servizi di ispezione merci in tempo reale per tutelare i propri clienti dai rischi dovuti al trasporto e ridurre al minimo le perdite in caso di danneg- giamento. Sono presenti diverse tipologie di servizi ispettivi a seconda delle esigenze del cliente, tra cui certificazioni, ispezioni tecniche o industriali, consulenze o servizi ad hoc costruiti appositamente per il cliente.

1

(12)

2 CAPITOLO 1. DESCRIZIONE DELLO STAGE

Figura 1.2: Sedi VIC nel mondo

Gli ambiti di ispezione sono vari e possono essere richiesti su molti differenti contesti: prodotti siderurgici e agro-alimentari, gas e petrolchimico, settore automo- bilistico o ispezioni industriali e di produzione. Pertanto la tipologia di clientela per l’azienda risulta essere molto varia e sempre più vasta, seppur legata in ogni caso all’imbito delle ispezioni e delle certificazioni.

I servizi sono inoltre supportati da diverse tecnologie che permettono ai clienti di verificare lo stato dell’ispezione della loro merce in tempo reale accedendo al sistema on-line per visualizzare foto dei beni, video delle operazioni e lo stato dell’ispezione.

1.1.2 Processi aziendali

L’azienda presenta un’infrastruttura diInformation Technology (IT)^[g]composta da un gruppo centrale di server basati su GNU / Linux ed una serie di applicazioni mobile che possono essere sincronizzate in qualsiasi luogo, al fine di eseguire l’ispezione.

Queste applicazioni sono utilizzate per raccogliere dati, immagini e video della movimentazione della merce. I dati ricevuti sono poi elaborati dai server centrali e resi accessibili al personale VIC ed ai clienti in qualsiasi momento, accedendo alla propria sezione privata attraverso il portale VIC online. Sempre più spesso nel mercato sono richiesti prodotti o servizi qualitativamente alti in tempi stretti. L’azienda è riuscita ad entrare in un mercato competitivo e moderno con grande impegno, tro- vando un giusto compromesso tra qualità, rapidità e affidabilità dei servizi offerti, attraverso processi interni con metodologie di lavoro ben definite.

VIC è dotata di un sistema di gestione della qualità, in accordo alla norma ISO 9001. Pertanto i processi aziendali devono essere misurabili e monitorabili nel tempo, mediante l’utilizzo di indicatori di prestazione chiave. I processi primari dell’azienda sono ovviamente quelli rivolti ai clienti e rappresentano quindi l’insieme delle attivi- tà che caratterizzano i servizi ispettivi. Ai processi di supporto appartengono invece

(13)

1.1. CONTESTO AZIENDALE 3 tutti i processi interni dell’azienda, che supportano i processi primari e sono quindi rivolti all’azienda stessa per le attività di raccolta dati, archiviazione e gestione delle richieste di ispezione.

VIC ha inoltre sviluppato e brevettato quattro differenti tecnologie utilizzate dai propri ispettori in tutto il mondo che vengono appunto utilizzate per permettere ai clienti di monitorare in tempo reale tutte le operazioni di ispezione. La tabella seguente prestenta una descrizione di queste tecnologie e le finalità per le quali esse vengono utilizzate dall’azienda. Si noti che i quattro ambiti per i quali queste tecnologie vengono utilizzate sono rispettivamente controllo danni, controllo quantitativo, controllo peso e controllo video della merce.

Nome tecnologia Descrizione del suo utilizzo

VDC (Vic Damage Control) Questo sistema aiuta l’operatore a controllare e segnalare i danni presenti nella merce ispezionata, scattare foto dei danni e inviare i dettagli del report al cliente in tempo reale.

VCC (Vic Cargo Control) Questo sistema aiuta l’operatore ad effettuare ispezioni delle merci attraverso una checklist sincroniz- zata nel server. I clienti potranno visualizzare il report durante l’ispezione in tempo reale.

VWC (Vic Weight Control) Questo sistema aiuta l’operatore a controllare il peso delle merci scaricate. I clienti possono monitorare le merci scaricate in tempo reale.

VWO (Vic Watch Online) Questo sistema permette agli ispettori di registra- re video delle operazioni di carico e scarico merci.

In questo modo i proprietari delle merci possono guardare i video in tempo reale e notificare nel caso ci sia qualcosa che non vada, come se fosse lì presente.

Tabella 1.1: Descrizione tecnologie sviluppate da VIC

1.1.3 Rapporto con l’innovazione

VIC crede fortemente nel futuro della propria azienda, nella tecnologia e nei rapporti umani e fa dell’innovazione uno dei valori fondamentali dell’azienda.

Proprio grazie all’innovazione e alla tecnologia, in particolare le quattro sviluppate e brevettate dall’azienda stessa, l’azienda ha modernizzato il controllo qualitativo e quantitativo delle merci ed ha potuto affermarsi e proporsi come una soluzione veloce, semplice ed efficiente nel campo delle ispezioni.

L’azienda considera l’innovazione come una risorsa strategica per il futuro dell’a- zienda. Ha situato a Padova il suo dipartimento di ricerca e sviluppo, dove vengono

(14)

4 CAPITOLO 1. DESCRIZIONE DELLO STAGE sviluppate e approfondite nuove tecnologie che possano migliorare ulteriormente i servizi offerti permettendo all’azienda di rimanere moderna e al passo coi tempi.

In particolare ritengo lo stage effettuato nell’azienda un progetto altamente tecnologico e rivoluzionario, poichè si propone di utilizzare Project Tango, un dispositivo di realtà aumentata realizzato da Google e tuttora in sviluppo/aggiornamento, per verificare la conformità della merce nel campo delle ispezioni merceologiche. Il fine del progetto sarebbe quindi quello di semplificare ulteriormente i controlli ispettivi, rendendoli ancora più rapidi e sicuri.

In questo modo l’azienda non si pone limiti tecnologici e punta al miglioramento e all’innovazione, cimentandosi nello sviluppo di idee che possano rivoluzionare e semplificare la gestione e la distribuzione dei servizi offerti e migliorando sempre più l’esperienza del cliente.

1.1.4 Stage per studenti laureandi

VIC S.r.l. ha più volte collaborato con l’Università degli Studi di Padova e si è sempre interessata a dare agli studenti del corso di Informatica l’opportunità di poter svolgere uno stage aziendale. Lo stage permette allo studente di mettere in pratica quanto appreso durante gli studi universitari ed allo stesso tempo da la possibilità all’azienda di valutare lo studente per le sue capacità e competenze in un constesto di lavoro reale.

Un altro ovvio motivo per cui le aziende offrono stage a studenti è la metodologia che prende il nome di on the job training.

Lo studente viene affiancato da un tutor, una figura di riferimento con ampia esperienza che possa formare la nuova risorsa in tempi brevi, rendendola autonoma allo scopo di inserirla nell’ambito lavorativo dell’azienda.

Figura 1.3: On the job training

L’azienda aveva numerosi progetti di stage disponibili e questo mi è apparso come il più interessante e innovativo. Il progetto di stage si propone di analizzare lo stato dell’arte del Progetto Tango di Google e comprendere totalmente le sue caratteristiche e funzionalità, al fine di sviluppare l’architettura ed un primo modulo di una

(15)

1.2. RISCHI DI PROGETTO 5 applicazione che permetta di ottenere il modello tridimesionale di un oggetto. Que- sto modello dovrà poi essere confrontato con un modello predefinito per verificare la presenza di anomalie tra l’oggetto in questione ed il modello ottenuto, valutando la percentuale di discrepanza tra i due. Questa architettura verrà utilizzata nel campo delle ispezioni merceologiche per valutare in tempo reale la conformità della merce rispetto a quanto richiesto dal cliente.

1.2 Rischi di progetto

L’attività di stage proposta è altamente sperimentale e innovativa. Di conseguenza lo stage è influenzato da diversi fattori di rischio, la maggior parte tecnologici.

L’approccio con tecnologie sconosciute e relativamente recenti rappresentava un grosso fattore di rischio, con una probabilità che il dispositivo Project Tango e le tecnologie ad esso correlato non fossero ancora sufficienti a garantire che il progetto di stage potesse essere portato a termine e rispettare gli obiettivi finali dell’azienda.

Proprio per questo motivo lo stage prevedeva un largo studio dello stato dell’arte del dispositivo, un’attenta analisi delle Application Program Interface (API)^[g]del dispositivo e la ricerca di tecnologie open source^[g]e librerie affiancabili alla progettazione per ottenere i risultati attesi.

I principali fattori di rischio relativi al progetto sono quindi i seguenti:

• lo studio e utilizzo di una tecnologia mai utilizzata prima nell’ambito delle ispezioni merceologiche può rallentare lo sviluppo del progetto, poichè non è presente molto materiale da poter consultare o riutilizzare;

• la bassa conoscenza del dispositivo Project Tango. Non è possibile sapere, prima di un accurato studio del dispositivo, il grado di accuratezza delle tecnologie utilizzate da Project Tango e se esse risultino adeguate e sufficienti ai fini del progetto;

• l’inesperienza dello studente in un ambito lavorativo e tecnologico così innovativo e sconosciuto può creare grosse difficoltà durante la progettazione del software.

1.3 Obiettivi dello stage

1.3.1 Obiettivi aziendali

Sulla base del progetto di stage presentato dall’azienda, ho concordato gli obiettivi dello stage che l’azienda mi ha proposto. L’azienda ha quindi previsto uno studio approfondito del dispositivo Project Tango, per capire i suoi punti di forza e se fosse possibile realizzare un’applicazione che possa risultare utile ai fini ispettivi dell’a- zienda. In seguito allo studio dello stato dell’arte del dispositivo, è stata richiesta una ricerca di librerie di supporto che potessero fornire ausilio agli strumenti utilizzati. In questo modo avrei un quadro complessivo che mostra il punto di partenza

(16)

6 CAPITOLO 1. DESCRIZIONE DELLO STAGE per lo sviluppo dell’applicazione e gli obiettivi raggiungibili con l’utilizzo di Project Tango e le librerie selezionate. Gli obiettivi aziendali dello stage sono i seguenti:

• studio dello stato dell’arte e delle API relative al progetto;

• ricerca e studio di librerie sviluppate da terzi;

• ottenere un quadro complessivo dello stato del progetto da cui partire per sviluppo dell’applicazione;

• analisi dei requisiti;

• progettazione infrastruttura dell’applicazione nella sua interezza;

• progettazione e sviluppo del primo modulo dell’applicazione;

• documentazione per ognuno degli obiettivi sopra elencati.

Gli obiettivi sopra elencati sono stati definiti in modo molto generale, in quanto una vera e propria analisi dei requisiti per definire la fattibilità degli obiettivi è stata possibile soltanto dopo uno studio accurato dello stato attuale del progetto. Pertanto l’azienda ha evitato di includere obiettivi troppo precisi o obiettivi secondari, poichè essi saranno aggiunti in un secondo momento evitando di modificare o rimuovere obiettivi già definiti e che non potessero essere realizzati.

1.3.2 Obiettivi personali

Gli obiettivi definiti dall’azienda coprono tutta la fase di studio del dispositivo Pro- ject Tango, la progettazione dell’intera infrastruttura dell’applicazione e il primo modulo, relativo all’ottenimento del modello 3D scansionato.

Tuttavia ho ritenuto opportuno aggiungere degli obiettivi personali, in buona parte relativi a prototipazione e test, che potessero sia aggiungere valore al progetto e sia aiutarmi a comprenderlo maggiormente:

• creazione di prototipi relativi alleAPI del progetto;

• sviluppo dei test relativi al modulo realizzato;

• realizzazione e test di un prototipo del modulo sviluppato in condizioni reali.

Si noti che nel quadro complessivo degli obiettivi dello stage e successivamente nell’analisi dei requisiti, ho considerato gli obiettivi aziendali come obbligatori e quelli personali come desiderabili, dando quindi priorità agli obiettivi fondamentali per il completamento del progetto di stage. Infine, come detto nella sezione precedente, voglio ricordare che una definizione più precisa degli obiettivi è stata realizzata in seguito allo studio del dispositivo.

(17)

1.4. PIANIFICAZIONE E VINCOLI 7

1.4 Pianificazione e vincoli

La pianificazione del progetto è stata effettuata pochi giorni prima dell’inizio dello stage attraverso un piano di lavoro, che è stato verificato e confermato sia dall’a- zienda che dal relatore.

Ho svolto il progetto di stage quotidianamente, secondo le scadenze settimanali evidenziate nel diagramma di Gantt riportato successivamente. Lo stage è avvenuto all’interno del dipartimento di ricerca e sviluppo dell’azienda VIC S.r.l. situato in via San Crispino, 46, 35129 Padova (PD).

Il diagramma di Gantt relativo al piano di lavoro previsto mostra le varie scadenze settimanali prefissate e le attività da svolgere, dando quindi un’idea delle attività complessive del progetto e la loro organizzazione temporale. L’area evidenziata in rosso rappresenta un periodo festivo (di ampiezza ridotta nell’immagine per facili- tarne la visualizzazione) durante il quale il progetto non è stato incrementato.

Figura 1.4: Pianificazione GANTT

Il lavoro settimanale è stato scadenzato e organizzato in questo modo:

• lunedì briefing di programmazione per la settimana;

• venerdì briefing consuntivo e verifica dell’attività settimanale con stesura di un riassunto del lavoro svolto durante la settimana e della documentazione.

Vengono inoltre concordate le attività da svolgere nella settimana successiva con il tutor aziendale.

(18)

8 CAPITOLO 1. DESCRIZIONE DELLO STAGE La pianificazione, in termini di quantità di ore di lavoro, è stata così distribuita:

Durata Descrizione dell’attività

60 ore Studio del progetto e stato dell’arte, ivi comprese le tre API: C, Java, Unity. Comprensione limiti e vantaggi dei tre approcci.

24 • Studio stato del progetto

30 • StudioAPI: C, Java, Unity. Eventuale creazione di prototipi per prendere confidenza con gli strumenti

6 • Stesura documentazione

40 ore Ricerca di librerie open source sviluppate da terzi e scrittura di un breve rapporto sullo stato del progetto e sugli obiettivi che realisticamente si possono raggiungere

32 • Ricerca librerie utili e test delle stesse

8 • Analisi degli strumenti individuati al fine di poter definire gli obiettivi raggiungibili con essi

100 ore Studio e progettazione del progetto nella propria interezza e selezione della prima unità da sviluppare. Stesura analisi del requisiti e progettazione (generale e di dettaglio)

24 • Stesura analisi dei requisiti (obbligatori, opzionali, desiderabili) in base a quanto emerso nella precedente fase

24 • Progettazione dell’infrastruttura nella propria interezza

6 • Selezione del primo modulo da sviluppare, obiettivo della

"seconda parte" dello stage

46 • Progettazione modulo (generale e di dettaglio).

100 ore Sviluppo del modulo 80 • Sviluppo del modulo 20 • Sviluppo dei test

- • Stesura documentazione (contestuale allo sviluppo) 12 ore Test live

12 • Test del modulo in condizioni reali e verifica sul campo di fattori che possano influenzare i risultati raggiunti in laboratorio (es. luce variabile)

Tabella 1.2: Distribuzione oraria delle attività del progetto

Il progetto, per essere realizzato come pensato, è stato sottoposto a dei vincoli. L’azienda non ha posto alcun vincolo particolare sul progetto; l’unico vincolo aziendale è ovviamente quello temporale definito dall’università, relativo alle circa trecento ore di stage presso l’azienda.

Gli altri vincoli del progetto sono quindi quelli tecnologici.

Il vincolo maggiore è rappresentato dal dispositivo stesso poichè l’applicazione per funzionare correttamente dovrà essere eseguita esclusivamente su un dispositivo Project Tango.

(19)

1.4. PIANIFICAZIONE E VINCOLI 9 Eventuali vincoli ambientali, relativi all’ illuminazione oppure a fattori che possono influenzare i risultati raggiunti con la raccolta del modello 3D sono stati analizzati e verificati in una fase successiva, dopo un’attenta analisi del dispositivo e delle sue potenzialità.

Allo stesso modo le tecnologie di supporto alla progettazione e sviluppo del- l’applicazione non possono essere definite a priori, ma occorre analizzare possibili tecnologie e librerie open source sviluppate da terzi, prima di poter decidere quali tra esse potranno essere utilizzate per il progetto.

Un secondo vincolo è rappresentato dall’APIscelta per lo sviluppo dell’applicazione tra le tre disponibili: Java, C e Unity. Dalla scelta dell’APIcambia radicalmente il modo di sviluppare l’applicazione e in parte il modo in cui le funzionalità del dispositivo vengono utilizzate. Tra le tre opzioni Unity è la scelta che si distaccherebbe maggiormente dalle altre in quanto a modalità di programmazione.

Infine, seppur sia possibile utilizzare il dispositivo per realizzare il modello 3D ispezionato e possibilmente salvare l’ispezione per un successivo confronto, è necessario che esso abbia una connessione ad internet per poter confrontare il modello ispezionato con un modello fittizio di riferimento in tempo reale.

(20)

(21)

Capitolo 2

Svolgimento del progetto

In questo capitolo sarà trattato l’intero svolgimento del progetto, a partire dallo stato dell’arte del dispositivo e delle sue API e dalla ricerca di librerie open source da poter utilizzare per il progetto. A queste attività seguono l’analisi dei requisiti e infine le fasi di progettazione e realizzazione dell’applicazione. Ho progettato l’architettura dell’intera infrastruttura dell’applicazione e successivamente sviluppato, come previsto dallo stage, il primo modulo del software relativo all’elaborazione del modello 3D ispezionato. A conclusione del capitolo sono descritte le attività di verifica e validazione del software, sviluppate e utilizzate durante la realizzazione dell’applicazione e al suo termine.

2.1 Studio progetto

La prima fase prevista dal progetto è stata lo studio del dispositivo Project Tango nelle sue caratteristiche. Pertanto ho avuto in dotazione dall’azienda un tablet Pro- ject Tango per l’intera durata dello stage, sul quale sviluppare l’applicazione. Ho studiato le tecnologie implementate nel dispositivo e le API utilizzabili attraverso l’utilizzo del dispositivo e delle app dimostrative realizzate da Google, osservando la documentazione¹ fornita e realizzando prototipi dimostrativi per chiarire l’utilizzo delle diverse API.

Project Tango è un tablet sperimentale prodotto da Google in grado di scan- dire tridimensionalmente l’ambiente circostante e di tracciare la propria posizione rispetto ad esso. Questa tecnologia consente a un dispositivo di comprendere la sua posizione in relazione al mondo intorno ad esso, navigare al suo interno e memorizzare informazioni su di esso attraverso speciali sensori visivi. L’hardware del dispositivo che permette queste funzionalità è composto da un sensore di profondita IR (infrarossi), una fotocamera Fisheye^[g] , una fotocamera RGB-IR, accelerome- tro e giroscopio. L’idea sfrutta tre caratteristiche principali: motion tracking, area learning e depth perception.

1Documentazione Project Tango. 2017. url: https://developers.google.com/tango/.

11

(22)

12 CAPITOLO 2. SVOLGIMENTO DEL PROGETTO

Figura 2.1: Dispositivo Project Tango

Motion Tracking

Con il termine motion tracking ci si riferisce alla capacità di comprendere la posizione e orientamento del dispositivo in sei gradi di libertà, ovvero la sua pose (posa).

Una posa può trovarsi in quattro differenti stati:

• initializing: il sistema di tracciamento si sta inizializzando o si sta ripristinando da uno stato non valido, pertanto i dati sulla posa non sono ancora disponibili e non possono essere utilizzati;

• valid : il sistema ritiene che la posa sia attendibile e valida e possa essere utilizzata;

• invalid : il sistema ha riscontrato problemi di qualche tipo e le stime sulla posa sono probabilmente non corrette;

• unknown: il sistema è in uno stato sconosciuto.

Project Tango implementa il motion tracking attraverso la VIO (visual-inertial odometry ), che diversamente dal GPS funziona all’interno di edifici o strutture e può fornire una precisione maggiore.

Le API forniscono due metodi per calcolare la posa: uno restituisce gli aggior- namenti più recenti della posa, l’altro fornisce una stima della posa in un momento specifico. Le informazioni sulla posa sono divisi in due parti principali: un vettore in metri e un quaternione per la rotazione. Le pose sono specificate attraverso un sistema di riferimento basato dalla coppia target-base, da cui dipende il sistema di coordinate utilizzato. Per tutti i sistemi di riferimento l’unità di misura è in metri.

(23)

2.1. STUDIO PROGETTO 13

Figura 2.2: Stati della posa (fonte: documentazione Project Tango)

Ad esempio Project Tango usa le strutture di coordinate START_OF_SERVICE e AREA_DESCRIPTION a livello locale, in cui l’asse Z è allineata con la gravità e punta verso l’alto, mentre il piano X-Y è perpendicolare ad essa ed è localizzato sulla base. Diversamente la struttura di coordinate DEVICE è definita allo stesso modo del sistema di coordinate di sensori di Android, in cui l’asse X punta a destra, l’asse Y verso l’alto e l’asse Z punta in avanti a partire dallo schermo (pertanto coordinate dietro lo schermo avranno valori negativi).

Figura 2.3: Frame di riferimento (fonte: documentazione Project Tango)

Tuttavia sistemi grafici come OpenGL o Unity utilizzano sistemi di coordinate differenti e la posa calcolata da Project Tango dovrà essere convertita prima di poter essere utilizzata da una delle suddette librerie grafiche.

Pertanto, il motion tracking permette di tracciare il movimento del dispositivo all’interno del mondo reale, la traiettoria percorsa e la sua attuale posizione e orientamento nello spazio.

(24)

Figura 2.4: Motion tracking (fonte: documentazione Project Tango)

Utilizzando soltanto il motion tracking, la posizione iniziale del dispositivo si resetterebbe ogni volta che viene avviata una nuova sessione. Dunque è qui che entra in gioco la seconda tecnologia: l’area learning, ovvero la capacità di salvare descrizioni dello spazio da poter utilizzare come riferimento.

Area Learning

L’area learning consente al dispositivo di navigare e comprendere il mondo intorno a sé, andando a fornire supporto al motion tracking e alla localizzazione del dispositivo. Tutto ciò avviene memorizzando le caratteristiche visive dell’area attraverso la quale il dispositivo si sta muovendo e riconoscendole quando esse vengono visualiz- zate nuovamente. Queste caratteristiche possono essere memorizzate in dei file ADP (Area Description File), che garantiscono motion tracking e localizzazione migliora- te. Il processo di apprendimento di un’area, tenendo traccia della posizione corrente dell’utente al suo interno è conosciuta come SLAM (Simultaneous Localization and Mapping).

La capacità di memorizzare lo spazio circostante permette al sistema di realizzare drift corrections, ovvero correzioni di percorso, che vanno a correggere piccoli erro- ri e imprecisioni che inevitabilmente vengono raccolti dal dispositivo man mano che il tratto percorso con il motion tracking inizia a diventare ingente. In questo modo quando il dispositivo riconosce un posto già visitato, corregge il percorso tracciato per renderlo consistente con le osservazioni precedenti e ridurre le imprecisioni.

Inoltre attraverso l’area learning il dispositivo può conoscere dove si trova all’interno di un area precedentemente visualizzata, riconoscendo una locazione da un file ADP caricato; tale concetto prende il nome di localizzazione. Questo permette di creare un’esperienza consistente quando si utilizza lo stesso spazio memorizzato, senza perdere le informazioni sulla posizione corrente ogni volta che si termina la sessione.

(25)

Figura 2.5: Drift correction (fonte: documentazione Project Tango)

Figura 2.6: Localizzazione (fonte: documentazione Project Tango)

Depth Perception

La depth perception permette di misurare la distanza dal dispositivo agli oggetti nel mondo reale. Poiché il progetto è stato realizzato per funzionare al meglio in ambienti interni, il calcolo sarà più preciso se ci si trova in un range da 0.5 a 4 metri di distanza dall’oggetto puntato dal sensore. Inoltre questa funzionalità si basa sul- l’utilizzo degli infrarossi e il riflesso della luce, pertanto potrebbe risultare imprecisa in aree illuminate da forti fonti di luce o zone con poca illuminazione.

Combinando depth perception con motion tracking è possibile stabilire le distanze tra i punti in un area appartenente a frame differenti. I dati sulla profondità possono inoltre essere associati al colore percepito dall’immagine visualizzata, in modo da riconoscere il colore e utilizzarlo in un’eventuale fase di texturing o per altri scopi.

I dati sulla profondità vengono restituiti in due formati principali: point clouds

(26)

16 CAPITOLO 2. SVOLGIMENTO DEL PROGETTO e XYZij.

LeAPIforniscono una funzione che restituisce dati sulla profondità attraverso un point cloud (nuvola di punti). Questo formato fornisce coordinate (x,y,z) di tutti i punti della scena che è stato possibile calcolare.

Figura 2.7: Nuvola di punti (fonte: documentazione Project Tango)

Il formato XYZij è la combinazione di un una nuvola di punti XYZ e una tavola di ricerca 2D che permetta di generare una mappa di profondità. La nuvola di punti XYZ è rappresentata con un array 1D di punti con coordinate (x,y,z), mentre la parte IJ, attualmente non ancora implementata in Project Tango, è un array 2D che permette di ottenere una visualizzazione della nuvola di punti più precisa, in cui i valori senza profondità sono denotati da un valore -1.

Figura 2.8: Mappa di profondità (fonte: documentazione Project Tango)

(27)

2.1.1 Studio API

TangoService è il service nativo di Android che esegue tutte le tecnologie principali di Project Tango e supporta applicazioni scritte in C, Java e Unity, le quali possono connettersi a TangoService attraverso le API.

Figura 2.9: TangoService e API (fonte: documentazione API dispositivo)

Ho studiato le API attraverso la documentazione² ufficiale che introduce al loro utilizzo e che mi ha permesso di realizzare dei prototipi dimostrativi. Ho anche avuto la possibilità di modificare semplici prototipi messi a disposizione da Google per prendere confidenza e comprendere maggiormente gli strumenti e le tecnologie di Project Tango. In questo modo ho potuto sperimentare motion tracking, area learning e depth perception per ognuna delle API.

Unity

Il kit di sviluppo software di Unity si presta bene alla creazione di giochi e altri programmi che richiedono la visualizzazione 3D qualora non si possieda un motore di rendering.

Unity fornisce un motore grafico molto efficiente e già dallo sviluppo dei prototipi è stato possibile ottenere dei risultati interessanti e accattivanti.

Project Tango fornisce script, componenti e strutture predefinite che semplificano la programmazione con Unity. Pur non essendo possibile sviluppare in ambiente nativo o con un linguaggio simile a quello di Android, l’API di Unity si presta ad essere ugualmente efficiente, con l’enorme vantaggio grafico fornito da Unity.

Java

L’API di Java è ideale per lavorare direttamente con Android in Java o con altre applicazioni Java, interfacciandosi con TangoService attraverso l’AIDL (Android In-

2Documentazione API. 2017. url: https://developers.google.com/tango/apis/overview.

(28)

Figura 2.10: Esempio prototipo Unity

terface Definition Language).

Il vantaggio maggiore offerto dall’API di Java è la possibilità di lavorare con metodi e classi che funzionino in modo molto simile alle API standard di Android, con funzionalità aggiuntive per ricavare le informazioni dalle telecamere e dai sensori del dispositivo Tango.

Lo sviluppo di applicazioni con l’API di Java avviene attraverso l’utilizzo di Android Studio e risulta essere piuttosto intuitiva e performante.

Figura 2.11: Esempio prototipo Java

(29)

2.1. STUDIO PROGETTO 19 C

L’API di C è consigliata per gli sviluppatori che vogliono avere la possibilità di scrivere applicazioni con il kit di sviluppo nativo di Android, che rende la programmazione più flessibile. Tuttavia è preferibile utilizzare l’API di C qualora si stia sviluppando un applicazione che non richieda parte grafica o se si possieda già un motore grafico 3D.

Figura 2.12: Esempio prototipo C

L’API di C è quella che probabilmente offre le prestazioni migliori e le capacità maggiori a livello di sistema grazie alla possibilità di sviluppare a livello nativo. I prototipi realizzati sono stati soddisfacenti e lo sviluppo nativo permette di realizzare codice a stretto contatto con le feature fornite da Project Tango. Tuttavia la mancanza di un motore grafico per la visualizzazione 3D potrebbe risultare un ostacolo limitante per lo sviluppo del progetto.

Lo sviluppo delle applicazioni avviene, così come per l’API di Java, attraverso Android Studio.

2.1.2 Test e prototipi

Come anticipato nelle sezioni precedenti, la fase di studio del progetto e delle API è stata accompagnata dalla creazione di prototipi che potessero aiutarmi a testare le funzionalità offerte dalle tre differenti APIattraverso Project Tango e a decidere quale delle tre fosse più opportuna per lo sviluppo dell’applicazione.

I primi test sono avvenuti su Unity attraverso l’SDK^[g]scaricabile all’interno della documentazione APIdi Project Tango.

Ho avuto modo di testare diversi prototipi che mettessero alla prova le tecnologie di Project Tango e ho verificato le funzionalità interne di Unity, che mi sono sembrate fin troppo vaste e complicate. Inoltre non tutte le funzionalità del dispositivo sono

(30)

20 CAPITOLO 2. SVOLGIMENTO DEL PROGETTO al momento compatibili con Unity, che risulta essere un passo indietro rispetto a Java e C.

Figura 2.13: Test Unity

Successivamente ho testato C e Java, piuttosto simili tra loro in quanto a utilizzo delle funzionalità del dispositivo, realizzando ancora una volta diversi prototipi. C si è dimostrato senza troppe sorprese l’APIpiù performante, mentre Java mi è apparsa molto più semplice da utilizzare con Project Tango grazie anche alla somiglianza del codice con l’API di Android.

Figura 2.14: Test realtà aumentata

(31)

Figura 2.15: Test profondità

2.1.3 Periodo di formazione

Le varie attività di stage sono state intervallate da diverse ore dedicate alla formazione e all’apprendimento delle tecnologie utilizzate. In primo luogo mi sono concentrato sulla comprensione del dispositivo e delle API, al fine di metterle in pratica attraverso i prototipi dimostrativi.

Successivamente, durante la ricerca di librerie e tecnologie open source sono se- guiti altri brevi periodi di formazione dedicati alla comprensione dell’utilizzo delle librerie e tecnologie più significative. Ho verificato il loro grado di utilità ai fini del progetto e se potessero effettivamente supportare Project Tango ed essere utilizzare durante le fasi di progettazione.

Infine, durante la progettazione effettiva del software, ho dedicato delle ore per imparare il funzionamento di Android Studio per lo sviluppo di applicazioni mobile e analizzato in modo più approfondito l’utilizzo dell’APIscelta per lo sviluppo.

(32)

2.2 Ricerca e analisi librerie open source utilizzabili

2.2.1 Librerie Grafiche

Per poter comparare al meglio le tre API utilizzabili per Project Tango risulta necessario poterle mettere sullo stesso livello. Pertanto, essendo Unity l’unica API a offrire di base un motore grafico di rendering 3D, è stato necessario ricercare valide alternative per C e Java.

Tra queste spicca sicuramente OpenGL, motore 3D che si interfaccia sia con C che con Java ed in particolare il suo sottoinsieme OpenGL ES³ pensato per dispositivi mobili e già fornito dal framework Android. La sua APIè ottimizzata per il rendering grafico 3D permettendo la creazione e modellazione di oggetti geome- trici primitivi (punti, linee/segmenti e poligoni) definiti da un gruppo di uno o più vertici ai quali possono essere associati coordinate posizionali, colori, texture, etc.

modificabili attraverso comandi di rendering (metodi).

La libreria è inoltre accompagnata da un’abbondante documentazione e guide per l’apprendimento.

OpenGL presenta un sistema di coordinate differente da Project Tango. Allo stesso modo di Unity, OpenGL utilizza un sistema di coordinate "reali" (world coordinate frame) che definisce l’origine della scena e un sistema di coordinate della telecamera (camera coordinate frame) collegata al punto di vista della telecamera. In OpenGL, entrambi i sistemi di coordinate sono basati su un sistema di assi cartesiani diretto. Nonostante tutto la conversione della posa tra Tango e OpenGL non risulta difficile, come viene mostrato nella documentazione di Project Tango.

Figura 2.16: Sistema di coordinate di OpenGL (fonte: documentazione OpenGL)

Un’altra libreria considerata è stata Ogre3D⁴. Questo flessibile motore grafico dispone di un design orientato ad oggetti che fornisce una valida opzione per lo

3OpenGL ES. url: https://www.khronos.org/opengles/.

4Ogre3D. url:http://www.ogre3d.org/.

(33)

2.2. RICERCA E ANALISI LIBRERIE OPEN SOURCE UTILIZZABILI 23 sviluppo grafico in linguaggio C++ ed è utilizzabile dal 2015, seppur con qualche limitazione, anche per dispositivi Android. Tuttavia, trattandosi di una libreria ad alto livello e quindi più adatta a rendering 3D più impegnativi ed elaborati, risulta essere piuttosto complicata e sicuramente non la soluzione ottimale per il progetto di stage.

Un’altra libreria esaminata e utilizzabile esclusivamente per Java è jPCT⁵, un piccolo e semplice motore grafico 3D utilizzabile per Java e Android che supporta OpenGL ES fino alla versione 2.0. Presenta una versione mobile dedicata (jPCT-AE) e ottimizzata per piattaforme Android, semplice da imparare e poco complessa, sebbene la documentazione fornita a riguardo risulta essere piuttosto scadente. L’API mostra però poca sinergia con Project Tango, il sistema di coordinate risulta differente (ruotato di 180 gradi attorno all’asse x rispetto a OpenGL) e probabilmente necessiterebbe l’ausilio di OpenGL per una totale integrazione e utilizzo delle informazioni raccolte dai sensori del tablet.

Infine ho testato la libreria Rajawali⁶, un motore grafico 3D per Android e basa- to su OpenGL ES 2.0/3.0 che mostra una buona sinergia con Project Tango (alcuni prototipi dimostrativi realizzati da Google per Project Tango utilizzano questa libreria per la grafica). Presenta inoltre una buona documentazione e alcuni esempi per realizzare alcune funzionalità di base.

Molti degli altri motori grafici valutati, spesso con scarsa documentazione o troppo ad alto livello (e probabilmente più adatti allo sviluppo di videogame 3D o am- bientazioni complesse), presentano caratteristiche simili alle soluzioni precedenti tal- volta basando parte delle loro funzionalità su altre librerie o su OpenGL stesso; di conseguenza non verranno citate, in quanto non sono state considerate opzioni valide per lo sviluppo del progetto.

2.2.2 Librerie Ausiliarie

Oltre alla ricerca di librerie che permettessero alle API di Java e C di competere graficamente con Unity, ho ricercato ulteriori librerie che potessero essere utilizzate all’interno del progetto di stage sia per lo sviluppo dell’applicazione che come ausilio per la modellazione e la comprensione degli strumenti utilizzati. Tuttavia, considerando che la tecnologia trattata è relativamente nuova e ancora poco utilizzata, la ricerca di fonti di riferimento e librerie che potessero interagire bene con Project Tango è stata difficoltosa e il materiale trovato è stato ridotto.

Una delle librerie che si è rivelata più interessante è stata PCL (Point Cloud Library)⁷, progetto C++ per l’elaborazione dei point clouds e immagini 2D/3D.

Risulta quindi essere un utile strumento per filtrare, estrarre e modellare le nuvole

5jPCT. url: http://www.jpct.net/.

6Rajawali. url: https://github.com/Rajawali/Rajawali.

7Point Cloud Library. url: http://pointclouds.org/.

(34)

24 CAPITOLO 2. SVOLGIMENTO DEL PROGETTO di punti catturate dai sensori di Project Tango, per creare e visualizzarne le superfici.

Il problema principale di questa libreria è che può essere utilizzata solo con C++ e non è compatibile con dispositivi mobile.

Figura 2.17: Creazione superfici da point clouds con PCL (fonte: documentazione PCL)

La migliore soluzione mobile per lo sviluppo attraverso PCL viene fornita dall’u- nione di PCL con un altro toolkit open source, VTK, e l’aggiunta delle librerie VES e Kiwi, tuttavia difficili da implementare e non interfacciabile con Android Studio.

VTK⁸ è un software per computer che tratta grafica 3D, elaborazione di immagini e visualizzazione e consiste in una libreria di classi C++ e diversi layer di interfacce (inclusa Java). Tuttavia il modulo di rendering di VTK non è scritto per OpenGL ed è qui che entra in gioco la libreria VES.

VES⁹è una libreria di rendering e visualizzazione in C++ basata su OpenGL 2.0 che si integra con VTK per fornire funzionalità di visualizzazione per i dispositivi mobile. Necessita l’installazione dell’SDK e NDK di Android sul dispositivo.

8Visualization Toolkit. url: http://www.vtk.org/.

9VES. url: http://www.vtk.org/Wiki/VES.

(35)

2.2. RICERCA E ANALISI LIBRERIE OPEN SOURCE UTILIZZABILI 25 Infine abbiamo la libreria Kiwi, una libreria applicativa che fornisce i blocchi per la costruzione di applicazioni avanzate di visualizzazione mobile (sia Android che iOS) facendo leva su VTK e PCL. Anche la piattaforma Kiwi è orientata su classi C++ che che vanno a legare insieme VTK con le capacità di rendering di OpenGL 2.0 offerte da VES. Kiwi offre inoltre una collezione di widget 3D designati per touch screens che permettono di manipolare i dati e interagire con la scena 3D.

Le applicazioni possono essere scritte sia in C++ che Java.

È inoltre disponibile un’applicazione mobile gratuita per la visualizzazione dei modelli 3D chiamata KiwiViewer.

Figura 2.18: Modello PCL (fonte: documentazione PCL)

Figura 2.19: Esempio visualizzazione su KiwiViewer (fonte: documentazione KiwiViewer)

(36)

26 CAPITOLO 2. SVOLGIMENTO DEL PROGETTO PCL è disponibile anche come plugin per programmi esterni. Attraverso il software open source ParaView è possibile filtrare le nuvole di punti ulteriormente, escludere elementi esterni a quelli desiderati e fornire uno stream continuo di point clouds in real-time. Per Paraview è stato sviluppato anche un plugin dedicato a Project Tango, tuttavia essendo Paraview un software utilizzabile solo su computer esso potrà essere adoperato soltanto come strumento esterno e non va considerato ai fini del presente documento.

Figura 2.20: Paraview con PCL plugin (fonte: documentazione Paraview)

Figura 2.21: Paraview con Project Tango (fonte: documentazione Paraview)

(37)

2.2. RICERCA E ANALISI LIBRERIE OPEN SOURCE UTILIZZABILI 27 QuickHull3D¹⁰ è una semplice libreria per Java che rappresenta un algoritmo di creazione di un involucro convesso a partire da un input di punti, calcolandone vertici e superfici per una successiva elaborazione e visualizzazione. La libreria non è molto complessa ed è costituita da poche classi, per le quali viene fornita una modesta documentazione e diversi esempi di utilizzo.

Jzy3d¹¹ è invece una libreria Java open source che permette di disegnare facilmente dati scientifici 3D: superfici, grafici e altre primitive 3D. Sebbene non proprio adatto al disegno di oggetti 3D complessi e/o basati su nuvole di punti e profon- dità, la libreria potrebbe essere utile per la quadratura e misurazione dell’oggetto rappresentato.

Figura 2.22: Esempio Jzy3d (fonte: documentazione Jzy3d)

Poly2tri¹² è una libreria per C++ e Java utilizzabile per la triangolazione e lo sviluppo di semplici poligoni 2D dando in input un insieme di punti. Questa libreria può quindi essere un punto di partenza per la modellazione 3D di un oggetto, ma vanno però considerati i suoi limiti all’aumentare della complessità dell’oggetto da rappresentare.

Utile supporto a questa libreria potrebbe essere Clipper¹³(per C++ e con fun- zionalità ridotte per Java), che permette di effettuare operazioni booleane tra linee e poligoni 2D (unione, intersezione, differenza e disgiunzione esclusiva).

10Documentazione QuickHull3D. url: http://www.cs.ubc.ca/~lloyd/java/doc/quickhull3d/

index.html.

11Jzy3d. url: http://www.jzy3d.org/.

12poly2tri. url: https://github.com/greenm01/poly2tri.

13Clipper. url: http://www.angusj.com/delphi/clipper.php.

(38)

Figura 2.23: Esempi Poly2tri e Clipper (fonte: documentazione Poly2tri e Clipper)

L’ultima libreria considerata è stata 3D Utilities¹⁴ sviluppata da ISDA (In- novative Software and Data Analysis Division), una libreria Java basata su Open- GL per caricare, salvare, visualizzare, manipolare e comparare entità 3D. La libreria supporta diversi differenti formati e lavora su strutture dati contenenti modelli poligonali.

14ISDA 3D Utilities. url: https : / / isda . ncsa . illinois . edu / drupal / software / 3D % 20Utilities.

(39)

2.2. RICERCA E ANALISI LIBRERIE OPEN SOURCE UTILIZZABILI 29

Figura 2.24: Esempio modello con 3D Utilities (fonte: documentazione ISDA)

2.2.3 Analisi Strumenti Individuati

Considerando le API e le librerie esaminate ho potuto definire un quadro complessivo sugli obiettivi raggiungibili durante il corso del progetto di stage.

In primo luogo, par quanto riguarda leAPIdi Project Tango, Unity rappresenta sicuramente una soluzione comoda sia per la grafica che lo sviluppo applicativo, ma limitate dall’ambiente Unity stesso e difficilmente integrabile ed estensibile con altre librerie e funzionalità. Pertanto la scelta dell’APIricade tra C++ e Java, entrambe supportate piuttosto bene dalle librerie sopra citate.

C++ è ovviamente caratterizzato da un maggior controllo del codice grazie alla possibilità di sviluppo in ambiente nativo e da migliori performance grazie alle caratteristiche del linguaggio stesso. Tuttavia Java si è comunque prestato bene dal punto di vista delle prestazioni e dell’adattamento del codice, favorito però dalla sua semplicità, flessibilità, portabilità e somiglianza all’API standard di Android.

Per quanto riguarda le librerie grafiche, OpenGL ES 2.0 o una libreria basata su di essa è senza dubbio la scelta migliore per lo sviluppo del progetto per diversi motivi:

• interfacciabile sia con C che con Java;

• è il motore più adatto per la grafica 3D di Android;

• documentazione abbondante;

(40)

• sistema di coordinate facilmente convertibile con le coordinate di Project Tango;

• la versione 2.0 è compatibile con tutte le librerie ausiliari utilizzabili e citate nel documento e supportato dalla maggior parte dei dispositivi mobile (Android 2.0 e superiori).

Le altre librerie considerate potranno essere utili per l’elaborazione del modello 3D, la sua misurazione e il confronto con un modello predefinito.

Nella fattispecie l’unione delle librerie PCL, VTK, VES e Kiwi sarebbero sulla carta la soluzione migliore fornendo un valido strumento per l’elaborazione del modello 3D lavorando con le nuvole di punti catturate dal sensore di Project Tango.

Tuttavia queste librerie che già faticano ad essere implementate su ambiente mobile, non sono utilizzabili con Android Studio e presentano una documentazione davvero scarsa. Un’alternativa accettabile è probabilmente costituita da QuickHull3D con la limitazione a modelli convessi. Le altre librerie fungeranno da supporto qualora for- niscano valore aggiunto e semplifichino il rendering o la visualizzazione del modello elaborato. Esse potranno inoltre aiutare la misurazione del modello ispezionato e il suo confronto con il modello predefinito al fine di individuare eventuali discrepanze tra i due.

Pertanto, come strumentazione per lo sviluppo del progetto ho scelto l’API di Java di Project Tango, supportata da OpenGL ES 2.0 come libreria grafica 3D per Android e dalle altre librerie ausiliarie, in relazione al valore aggiunto che ognuna di esse fornisce e alle feature di cui necessità l’applicazione.

In conclusione, prendendo atto dello stato dell’arte di Project Tango (e le sue API) con le librerie trovate e analizzate gli obiettivi complessivi del progetto sono i seguenti:

• realizzazione di un modello tridimensionale di un oggetto quanto più verosi- mile possibile, basato sui point clouds catturati dal sensore di profondità di Project Tango. Questo processo potrebbe comportare l’eliminazione dei punti catturati dal sensore e non coerenti con l’oggetto desiderato, eventuale filtra- zione e raffinazione dei punti catturati al fine di renderizzare un modello il più simile possibile con la realtà;

• misurazione dei lati e dell’area delle superfici dell’oggetto 3D ispezionato, con eventuale quadratura o triangolazione di oggetti 2D e 3D;

• confronto del modello ispezionato con un modello predefinito e individuazione in tempo reale di eventuali anomalie del modello elaborato o discrepanze tra esso e il modello campione tramite operazioni di sovrapposizione delle superfici e confronto delle misurazioni sul modello.

Lo stage prevede tuttavia solo lo sviluppo del primo modulo dell’applicazione, corrispondente al primo dei tre punti elencati (ed eventualmente qualche operazione di misurazione del secondo punto), ovvero la realizzazione del modello 3D ispezionato col dispositivo.

(41)

2.3. ANALISI DEI REQUISITI 31

2.3 Analisi dei requisiti

2.3.1 Descrizione generale Obiettivi del prodotto

L’obiettivo che si pone il prodotto è verificare la conformità della merce ispezionata in tempo reale, confrontando l’oggetto ispezionato con un modello predefinito e valutando eventuali anomalie e discrepanze tra i due.

Funzioni del prodotto

Il prodotto sarà composto da un applicativo mobile che offrirà funzioni diverse al- l’utente qualora sia esso autenticato o meno. Qualora l’utente sia offline, egli potrà comunque effettuare l’autenticazione e accedere all’applicazione ma le funzionalità saranno limitate finché l’utente non sarà online e saranno verificate le sue credenziali di login. L’utenza dovrà essere già registrata esternamente al sistema, pertanto non sarà presente una funzionalità di registrazione all’interno dell’applicazione.

Un utente generico disporrà soltanto delle seguenti funzionalità offerte dal sistema:

• autenticazione presso il sistema, che permette all’utente di accedere alle fun- zionalità complete dell’applicazione;

• ispezione e ottenimento modello 3D dell’oggetto ispezionato;

• caricamento e salvataggio modello 3D;

• visualizzazione modello 3D e operazioni basilari su di esso (rotazione/zoom).

Un utente autenticato (e online) potrà invece utilizzare anche le seguenti funziona- lità:

• operazioni di misurazione sul modello 3D;

• invio del modello 3D al server di backend per i calcoli di discrepanza.

Caratteristiche degli utenti

Per il prodotto si individuano due principali categorie di utenti:

• utenti generici;

• utenti autenticati.

Le categoria individuata come utente del prodotto comprende in particolar modo persone che si occupino di ispezioni merceologiche, di età adulta e di ambo i sessi. Il prodotto non richiede particolari abilità agli utenti destinatari. A coloro che vogliono utilizzare il prodotto è soltanto richiesta una minima conoscenza dell’utilizzo di dispositivi mobile (soprattutto ciò che riguarda le funzionalità della fotocamera) e conoscenze nell’ambito dell’ispezione di merci al fine di poter giudicare la validità del modello ispezionato.

(42)

Piattaforme di esecuzione

Il prodotto è stato designato per il funzionamento su Project Tango, dispositivo tablet di Google dotato di sensori in grado di comprendere l’ambiente circostante.

L’applicazione potrà inoltre funzionare su eventuali dispositivi realizzati successivamente purché essi siano muniti dei sensori di Project Tango e siano compatibili con le librerie utilizzate.

Vincoli generali

Per usufruire delle funzionalità dell’applicazione, l’utente dovrà disporre di:

• dispositivo Project Tango.

Tuttavia per poter utilizzare le funzionalità complete dell’applicazione, l’utente dovrà disporre di:

• registrazione all’interno del sistema;

• connessione ad internet.

2.3.2 Casi d’uso

Una volta stabiliti gli obiettivi realizzabili ho realizzato la stesura dei casi d’uso relativi al prodotto. Ogni caso d’uso è univocamente identificato da un codice nel formato UC[codice] dove codice è il codice numerico gerarchico univoco. Per la maggior parte dei casi d’uso ho creato dei diagrammi (Use Case Diagram) di tipo UML^[g]dedicati alla descrizione delle funzioni o servizi offerti dal sistema, così come sono percepiti e utilizzati dagli attori che interagiscono con il sistema stesso.

UC2 Caso d’uso privato

• Attori: Utente autenticato.

• Scenario principale:

1. Avvio nuova ispezione (UC2.1);

2. Accesso alla lista dei modelli salvati (UC2.2);

3. Effettuare il logout (UC2.3).

• Scenari alternativi:

– qualora l’utente fosse autenticato da offline, può richiedere in qualsiasi momento, nel caso fosse in grado di connettere ad internet il proprio dispositivo, di verificare le proprie credenziali di autenticazione e passare online.

• Descrizione: un utente autenticato può iniziare una sessione di ispezione, accedere alla lista dei modelli 3D salvati o effettuare il logout dall’applicazione.

(43)

2.3. ANALISI DEI REQUISITI 33

• Precondizione: l’utente accede all’applicazione tramite dispositivo mobile supportato e si è autenticato.

• Postcondizione: il sistema ha fornito le funzioni richieste.

UC2.1.1 Avvio sessione di ispezione

1. Terminare ispezione (UC2.1.1.1);

2. Annullare ispezione (UC2.1.1.2).

• Descrizione: l’utente autenticato deve poter avviare una sessione di ispezione.

• Precondizione: l’utente autenticato ha richiesto di voler avviare una sessione di ispezione.

• Postcondizione: il sistema ha avviato una sessione di ispezione.

Figura 2.25: UC2.1.1 avvio sessione di ispezione

(44)

34 CAPITOLO 2. SVOLGIMENTO DEL PROGETTO UC2.1.1.3 Visualizzazione modello

Figura 2.26: UC2.1.1.3 visualizzazione modello

1. Rotazione del modello (UC2.1.1.3.1);

2. Zoom del modello (UC2.1.1.3.2);

3. Salvataggio del modello (UC2.1.1.3.3);

4. Uscita dall’ispezione (UC2.1.1.3.4);

(45)

2.3. ANALISI DEI REQUISITI 35 5. Condivisione del modello tramite link (UC2.1.1.3.5);

6. Operazioni di misurazione(UC2.1.1.3.6);

7. Operazioni di confronto(UC2.1.1.3.7).

• Descrizione: l’utente autenticato deve poter visualizzare il modello 3D ottenuto.

• Precondizione: l’utente autenticato ha terminato una sessione di ispezione.

• Postcondizione: il sistema elabora il modello ispezionato e ne permette la visualizzazione.

UC2.2 Accesso alla lista dei modelli salvati

1. Visualizzazione titolo modello (UC2.2.1);

2. Modifica titolo modello (UC2.2.2);

3. Visualizzazione immagine modello (UC2.2.3);

4. Visualizzazione descrizione modello (UC2.2.4);

5. Modifica descrizione modello (UC2.2.5);

6. Caricare modello (UC2.2.6);

7. Caricare modello tramite link (UC2.2.7);

8. Eliminare modello (UC2.2.8).

• Descrizione: l’utente autenticato deve poter accedere alla lista dei modelli salvati.

• Precondizione: l’utente autenticato ha richiesto di voler accedere alla lista dei modelli salvati.

• Postcondizione: il sistema fornisce una schermata dove saranno visualizzati tutti i modelli dell’utente autenticato con titolo, descrizione e immagine.

Saranno inoltre visualizzati i pulsanti per caricare o eliminare il modello.

(46)

2.3.3 Tracciamento dei requisiti

Da un’attenta analisi dei requisiti e dei casi d’uso effettuata sul progetto ho stilato la tabella che traccia i requisiti in rapporto ai casi d’uso. Sono stati individuati diversi tipi di requisiti e ho quindi fatto utilizzo di un codice identificativo per distinguerli.

Ho differenziato i requisiti per categoria del requisito a seconda della sua finalità, definendo inoltre il grado di priorità del requisito.

Tra le categorie dei requisiti sono stati effettuate le seguenti classificazioni:

• requisito funzionale: definisce le funzionalità principali che l’applicazione deve soddisfare;

• requisito qualitativo: definisce i vincoli qualitativi riguardanti l’interfaccia grafica o legati all’esperienza dell’utente. Si noti che per la presente applicazione non sono stati previsti requisiti qualitativi poiché questi aspetti non erano richiesti tra gli obiettivi dello stage e data la natura puramente innovativa del progetto essi non sono stati ritenuti necessari;

• requisito di vincolo: definisce i vincoli di carattere tecnologico dell’applicazione.

I gradi di priorità dei requisiti sono invece stati distinti in:

• obbligatori: definisce i requisiti ritenuti fondamentali ai fini del raggiungimento dello scopo dello stage;

• desiderabili: definisce i requisiti non ritenuti fondamentali, ma che portereb- bero comunque valore aggiunto al prodotto.

• opzionali: definisce quei requisiti di cui ci si occuperà solo dopo aver comple- tato i precedenti e se le risorse a disposizione lo permetteranno.

(47)

2.4. PROGETTAZIONE 37

2.4 Progettazione

2.4.1 Tecnologie utilizzabili

In questa sezione vengono presentate le tecnologie scelte per sviluppare il progetto e quelle che potrebbero fornire un aiuto in alcuni ambiti dello sviluppo dell’applicazione. Per ognuna di esse verrà fornita una breve descrizione ed eventuali punti a favore e sfavore.

- Java

Java verrà utilizzato per la maggior parte dello sviluppo del progetto attraverso l’IDE^[g]Android Studio. La scelta di Java comporterà l’uso dell’API di Java per Project Tango e qualora fosse necessario il suo framework UX in Java per la gestione delle eccezioni e il miglioramento dell’esperienza dell’utente.

Vantaggi:

• semplicità, flessibilità e portabilità;

• buona fornitura di librerie compatibili;

• linguaggio di programmazione molto simile ad Android;

• velocità di sviluppo e ottima compatibilità.

Svantaggi:

• minor controllo del codice e prestazioni minori rispetto a C++.

- OpenGL ES

OpenGL ES è un motore 3D pensato per dispositivi mobile e fornito dal framework Android.

Vantaggi:

• ottimizzato per il rendering 3D;

• interfacciabile con Java e Project Tango;

• compatibilità con molte librerie (nella versione 2.0).

- Rajawali

Basato su OpenGl ES, questo motore grafico offre semplici funzionalità che si adat- tano molto bene sia con Android che Project Tango per la visualizzazione grafica delle attività.

(48)

38 CAPITOLO 2. SVOLGIMENTO DEL PROGETTO Vantaggi:

• buon adattamento con Android e Project Tango;

• semplicità di utilizzo e buone funzionalità.

Svantaggi:

• caratteristiche limitate.

- PCL

PCL è una libreria utile per l’elaborazione 2D e 3D dei point clouds.

Vantaggi:

• libreria più completa e adatta all’elaborazione dei point cloud;

• documentazione dettagliata.

Svantaggi:

• sviluppata esclusivamente per C++;

• non utilizzabile in ambiente mobile.

- VTK

VTK è un software di elaborazione e visualizzazione immagini 3D che consiste in una libreria di classi C++ e interfaccia per Java.

Vantaggi:

• ottima elaborazione 3D;

Svantaggi:

• modulo di rendering non compatibile con OpenGL.

- VES

VES è una libreria di rendering e visualizzazione integrabile con VTK.

Vantaggi:

• basato su OpenGL 2.0;

• garantisce funzionalità di visualizzazione su dispositivi mobile integrandosi con VTK.

Svantaggi:

• documentazione quasi assente.

(49)

2.4. PROGETTAZIONE 39

- Kiwi

Kiwi è una libreria applicativa che fornisce la struttura per lo sviluppo di applicazioni avanzate di visualizzazione mobile.

Vantaggi:

• lega insieme le librerie PCL e VTK;

• offre widget 3D per touch screens;

• permette la scrittura del codice in Java.

Svantaggi:

• documentazione quasi assente.

- QuickHull3D

QuickHull3D è una libreria che fornisce un algoritmo per la creazione di un involucro convesso a partire da un input di punti 3D.

Vantaggi:

• si adatta bene allo scopo del progetto elaborando punti in tre dimensioni;

• realizza un involucro dal quale poter raccogliere vertici e superfici da rappresentare.

Svantaggi:

• funzionalità limitate da poche classi e non semplicissimo da adattare e far coesistere con altre librerie;

• realizza soltanto involucri convessi.

- Jzy3d

Jzy3d è una libreria per disegnare in modo semplice grafici, superfici e primitive 3D poco complesse.

Vantaggi:

• offre strumenti di quadratura e misurazione;

Svantaggi:

• non adatta all’elaborazione di nuvole di punti o modelli complessi.

(50)

- Poly2tri

Poly2tri è una libreria per lo sviluppo e triangolazione di modelli 2D basati su input di insiemi di punti.

Vantaggi:

• permette un’elaborazione molto semplice basata sulle coordinate dei punti;

• offre la triangolazione delle superfici 2D.

Svantaggi:

• modellazione solo 2D;

• libreria limitata e con poche funzionalità.

- Clipper

Clipper è una libreria che permette di effettuare operazioni booleane tra linee e poligoni 2D.

Vantaggi:

• offre un buon supporto per operazioni booleane sui modelli 2D;

Svantaggi:

• calcoli offerti solo su linee e oggetti in due dimensioni;

• funzionalità ridotte per Java.

- 3D Utilities by ISDA

3D Utilities è una libreria utile a caricare, salvare, visualizzare, manipolare e comparare entità 3D.

Vantaggi:

• interamente sviluppata in Java;

• basata su OpenGL;

• supporto per diversi formati;