tesi

UNIVERSITÀ DEGLI STUDI DI CATANIA

FACOLTÀ DI INGEGNERIA

Corso di laurea in ingegneria dell’automazione e controllo dei sistemi complessi

DIPARTIMENTO DI INGEGNERIA ELETTRICA, ELETTRONICA E

DEI SISTEMI

GIUSEPPE PATTI

Sviluppo di un sistema di optical tracking per la navigazione di robot mobili

Tesi di Laurea

Relatore: Chia.mo Prof. Ing. Giovanni Muscato

Correlatori: Ing. Domenico Longo

Ing. Carmelo Donato Melita

Sommario

2

Sommario

Prefazione ................................................................................................... 5

1 Introduzione ...................................................................................... 7

1.1 Architettura del sistema ................................................................ 7

2 Nozioni teoriche ................................................................................ 8

2.1 Computer vision ........................................................................... 8

2.1.2 Il modello della telecamera ........................................................ 8

2.1.2.1 Modello della telecamera: ARToolkit ............................. 11

2.1.3 la matrice di omografia ............................................................. 12

2.1.4 Rilevamento della posizione del target-parametri estrinseci ............................................................................................................... 14

2.2 Image Processing .............................................................................. 16

2.2.1 La segmentazione ...................................................................... 18

2.2.2 Edgedetection ............................................................................. 19

2.2.3 Thresholding ............................................................................... 20

2.2.3.1 Adaptivethresholding : Otsumethod ............................... 21

2.3 Network .............................................................................................. 22

2.3.1 Il protocollo UDP ....................................................................... 22

2.3.2 Socket ........................................................................................... 24

2.4 Le leggi di controllo .......................................................................... 26

Sommario

3

2.4.1 Feedback control ........................................................................ 26

3. Il software ............................................................................................. 29

3.1 Strumenti utilizzati ........................................................................... 29

3.1.1 Le openCV .................................................................................. 29

3.1.2 ARToolkit .................................................................................... 30

3.2 Installazione ................................................................................... 32

3.2.1 OpenCV ................................................................................... 33

3.2.2 Creare un proprio programma ............................................ 35

3.2.3 ARtoolKit .................................................................................... 37

3.2.4 Installazione GLUT ................................................................ 37

3.2.5 Installazione ARTOOLKIT .................................................. 38

3.2.6 Creare un proprio programma ............................................ 39

3.3 Analisi del software .......................................................................... 40

3.3.1 Analisi del software: il funzionamento .................................. 42

3.3.2 Analisi del software: il codice ................................................. 44

3. 4 Risultati ............................................................................................. 51

3.4.1 Le prove di misurazione .......................................................... 51

3.4.2 Le prove di robustezza ........................................................ 59

3.4.2.1 Indoor –luce naturale .................................................. 60

3.4.2.2 Indoor – scarsaluminosità .......................................... 62

3.4.2.3 Outdoor – forte luminosità ................................................ 64

3.4.2.3 Outdoor – scarsaluminosità ....................................... 66

3.4.4 Le prove di inseguimento ................................................... 68

Appendice A : Matrici di rotazione e angoli di Eulero ..................... 71

Appendice B : Calibrazione della telecamera con ARToolKit .......... 80

Sommario

4

Procedura di calibrazione .................................................................. 80

Appendice C: Usare un target differente ............................................ 85

Limitazioni: .......................................................................................... 86

Bibliografia ............................................................................................... 87

Prefazione

Prefazione

Il presente lavoro di tesi è stato incentrato sullo sviluppo di un software, che permettesse ad un robot l’inseguimento di un determinato target.

Tale problema può essere essenzialmente diviso in due parti.

La prima riguardante il riconoscimento e il posizionamento (posa) del target; mentre la seconda, lo sviluppo di una legge di moto, che applicata al robot, ne permetta l’effettivo inseguimento.

Per quanto riguarda il riconoscimento e il tracking del target,si sono utilizzati tool di computer vision come, le OpenCV e l’ARToolKit, adatti allo sviluppo di applicazioni di Realtà aumentata (AR) e quindi, atti a calcolare con precisione la posa del target.

Con realtà aumentata si vuole indicare, a differenza di quanto avviene con la realtà virtuale, dove l’utilizzatore viene immerso in un mondo totalmente artificiale, la possibilità di arricchire o aumentare la realtà (mondo reale), inserendo all’interno di essa oggetti virtuali generati dal computer.

Osservando, invece, quanto fatto per la legge di controllo sul moto del robot, si intuisce che essa è una rivisitazione della ben nota legge di controllo feedback presente in

Prefazione

6

letteratura. Per quanto concerne, poi, l’esplicazione vera e propria delle finalità e della struttura di tale composizione scritta potremmo dire che, quest’ultima ha inizio con un’introduzione, in cui viene mostrata l’architettura del sistema, per passare successivamente ad una parte prettamente teorica, atta a far comprendere al lettore i passaggi e le scelte implementative effettuate;si continua con la sezione dedicata al software, in cui vengono esposte le peculiarità del suddetto, sia attraverso un’analisi delle funzioni implementate, sia attraverso l’esposizione dei risultati ottenuti. In conclusione le appendici, contenenti argomenti teorici marginali, ma che, per completezza, si sono voluti includere.

Capitolo 1 Introduzione

1 Introduzione

1.1 Architettura del sistema

Il robot sul quale verrà utilizzato tale software è l’U-Go, sviluppato dal DIEES dell’Università di Catania e il cui acronimo sta per “Unmanned Ground Outdoor Robot”[1]. Tale macchina, costruita per assolvere a compiti come la navigazione in ambiente esterno, è equipaggiata con due unità elaborative adibite rispettivamente, al controllo del moto e all’elaborazione dei dati provenienti dai vari sensori, che possono interfacciarsi tramite LAN. Ragion per cui, come si vedrà nel prosieguo, a corredo del software principale è stato implemento un socket UDP, per lo scambio di dati tra le due piattaforme computazionali.

Figura 1 Robot U-Go

Capitolo 2 Nozioni teoriche

2 Nozioni teoriche

Al fine di ottenere una comprensione globale del lavoro svolto, è necessario essere a conoscenza degli argomenti teorici basilari, riguardanti la computer vision e la teoria del controllo.

2.1 Computer vision

La computer vision (CV), è la disciplina che si occupa dell’analisi di immagini numeriche al calcolatore e il cui scopo ultimo è l’estrazione automatica di informazioni dalla stessa[2].

I capisaldi di tale disciplina risiedono, essenzialmente, nel modello della telecamera, di seguito analizzato.

2.1.2 Il modello della telecamera

Tale modello geometrico permette di capire la corrispondenza tra la posizione di un punto nella scena (mondo reale) e la posizione del punto corrispondente nell’immagine. Esistono diversi modelli di telecamera, ma il più comune è il cosiddetto pinhole o prospettico.


9

Figura 2.1 modello di proiezione della telecamera

Il sistema di riferimento della camera [ 𝑋𝑐𝑌𝑐𝑍𝑐 ], con origine sul centro ottico e asse 𝑍𝑐 lungo l’asse ottico, ha unità di misura espresse in metri. Posto parallelamente al piano 𝑋𝑐𝑌𝑐 si ha il piano immagine 𝑋𝑖𝑚𝑌𝑖𝑚 , il cui sistema di riferimento [ 𝑋𝑖𝑚𝑌𝑖𝑚 𝑍𝑖𝑚]ha origine giacente lungo l’asse 𝑍𝑐. Gli assi 𝑋𝑐 e 𝑌𝑐 sono paralleli e concordi con quelli della camera e l’asse𝑍𝑐 = 𝑍𝑖𝑚 + 𝑓 , dove 𝑓indica la distanza focale. Oltre a questi, si individua un altro sistema [ 𝑈𝑉 ], il quale, è centrato nell’angolo in alto a sinistra del piano immagine. A differenza dei precedenti, tale sistema rappresenta un punto 𝑃𝑜𝑏𝑗𝑐 , di coordinate [ 𝑥𝑐 𝑦𝑐𝑧𝑐 1 ]𝑇, nella sua proiezione omogenea 𝑞sul piano dell’immagine di coordinate [ 𝑢 𝑣 1 ]𝑇. Per laconversione da pixel a metri, si usano le seguenti leggi:

𝑢 = �𝑢0 + 𝑦𝑖𝑚𝑆𝑥� , 𝑣 = �𝑣0 −

𝑥𝑖𝑚𝑆𝑦� (2.1)


10

Invece, il passaggio da pixel in metri è consentito dalla seguente relazione:

𝑥𝑖𝑚 = (−𝑣 + 𝑣0)𝑆𝑦, 𝑦𝑖𝑚 = (𝑢 − 𝑢0)𝑆𝑥. (2.2)

dove 𝑢0ed 𝑣0rappresentano l’offset in pixel dell’origine del sistema di riferimento [𝑈;𝑉], rispetto all’origine del sistema di riferimento immagine, mentre 𝑆𝑥 ed 𝑆𝑦 indicano l’effettiva corrispondenza tra pixel e metri. Questi parametri, fanno parte dei cosiddetti parametri intrinseci della camera e vengono ricavati mediante la calibrazione della camera1

𝑥𝑖𝑚𝑓

= −𝑦𝐶𝑧𝐶

, 𝑦𝑖𝑚𝑓

= 𝑥𝐶𝑧𝐶

, (2.2)

. Considerando le relazioni di similitudine di figura 2.1, è possibile pervenire alle seguenti relazioni:

Da cui applicando la (2.2):

(v−v0)Syf

= yCzC

, (u−u0)Sxf

= xCzC

(2.3)

ponendo𝑓𝑥 = 𝑓𝑆𝑥

ed 𝑓𝑦 = 𝑓𝑆𝑦, si può scrivere:

Λ ≡ �Λ1Λ2Λ3� =

�𝑓𝑥 0 𝑢0 00 𝑓𝑦 𝑣0 00 0 1 0

��

𝛱

∙ �

𝑥𝐶𝑦𝐶𝑧𝑐1

� (2.4)

𝛱 è la matrice di calibrazione che raccoglie i parametri intrinseci1

1 Consultare l’ Appendice B: Calibrazione della telecamera con l’ARToolKit

e permette di passare dal sistema di riferimento della camera a quello dell’immagine digitale [3]. Si ricava, infine:


11

q ≡ �

Λ1Λ2Λ31

� (2.5)

2.1.2.1 Modello della telecamera: ARToolkit

Introdotto il modello di telecamera presente in letteratura, passiamo ad analizzare quello dell’ARToolkit, che come si avrà modo di vedere successivamente, costituisce uno degli strumenti su cui si fonda il lavoro. Esso, adoperando le OpenGL, impiegherà il sistema di coordinate di quest’ultimo, che è un sistema destrorso con l’asse Z rivolto verso la telecamera.

Figura 2.2 Modello di telecamera usato da ARToolKit


12

Figura 2.3 Relazione camera-target

Definito tale modello, si può passare a illustrare i concetti di trasformazione prospettica - omografia e rilevamento posizione(pose estimation).

2.1.3 la matrice di omografia

Nell’ambito della computer vision, si definisce omografia planare, una proiezione da un piano ad un altro. Volendo fare un esempio di omografia planare, potremmo parlare del mapping tra un punto di un piano bidimensionale al piano immagine della telecamera.

Tutto ciò è possibile esprimerlo in termini di matrici, a condizione di usare le coordinate omogenee per definire sia


13

il punto mondo Q che il punto q sull’immagine in cui Q è mappato.

Se definiamo:

𝑄~ = [𝑋 𝑌 𝑍 1]𝑇

𝑞~ = [𝑥 𝑦 1]𝑇 (2.6)

si può esprimere l’omografia semplicemente come:

𝑞~ = 𝑠𝐻𝑄~ (2.7)

il parametro s è il fattore di scala. Utilizzando alcuni concetti geometri misti ad algebra delle matrici si ottiene che H può essere divisa in due parti: quella che rappresenta la roto-traslazione dei sistemi di riferimento mondo-camera e quella dei parametri intrinseci, introdotti precedentemente.

Figura 2.4 visione di un oggetto a cui viene applicata la matrice omografia

La roto-traslazione tra i sistemi di riferimento può essere a sua volta suddivisa in altre due parti: quella relativa alla rotazione R e quella alla traslazione t, le quali relazionano il


14

piano nel sistema di riferimento mondo a quello dell’immagine; lavorando con coordinate omogenee, si possono combinare queste ultime in un’unica matrice di roto-traslazione.

𝑊 = [𝑅 𝑡] (2.8)

La matrice П viene moltiplicata per WQ, ottenendo:

𝑞~ = 𝑠П𝑊𝑄~dove П =�𝑓𝑥 0 𝑐𝑥0 𝑓𝑦 𝑐𝑦0 0 1

� (2.9)

Inoltre, senza perdere in generalità possiamo considerare l’oggetto sul piano mondo in modo da porre Z=0. Tutto ciò ci permette, se rappresentiamo la matrice in 3x1 colonne, di sopprimere una di queste.

Possiamo così definire la matrice omografia, che mappa i punti di un oggetto planare nel piano dell’immagine, come H=sП[𝑟1𝑟2𝑡] [5]

�𝑥𝑦1�= sП[𝑟1𝑟2𝑟3 𝑡] �

𝑋𝑌01

� = 𝑠П[𝑟1𝑟2 𝑡] �𝑋𝑌1� (2.10)

2.1.4 Rilevamento della posizione del target-parametri estrinseci

Accanto ai parametri intrinseci, a cui si è già avuto modo di far riferimento precedentemente, esistono quelli estrinseci. Questi parametri, rappresentati da tre angoli di rotazione


15

ψ φ e θ2

Questi parametri possono essere ricavati dalla matrice omografia, attraverso il seguente algoritmo.

più tre traslazioni𝑇𝑥𝑇𝑦𝑇𝑧, diventano, si intuisce, molto importanti nel momento in cui si vuole effettuare la posa, ovvero determinare la posizione rispetto alla telecamera, del target.

Per ogni frame, come è ovvio, si avrà una matrice omografica che potrà essere rappresentata attraverso 3x1 vettori colonna

𝐻 = [ℎ1ℎ2ℎ3] = 𝑠П[𝑟1𝑟2 𝑡] (2.11)

da cui si ottiene semplicemente

ℎ1 = 𝑠П𝑟1 𝑜 𝑟1 = 𝜆П−1ℎ1

ℎ2 = 𝑠П𝑟2 𝑜 𝑟2 = 𝜆П−1ℎ2

ℎ3 = 𝑠П𝑡 𝑜 𝑡 = 𝜆Пℎ3

con 𝜆 = 1 𝑠� . (2.12)

Essendo i vettori rotazione𝑟1 e 𝑟2tra loro ortonormali, si ha che il prodotto scalare è pari a 0

𝑟1𝑇𝑟2 = 0 (2.13)

E che

ℎ1𝑇П−𝑇П−1ℎ2 = 0 (2.14)

Noi, però, sappiamo anche che i vettori sono uguali in modulo

�|𝑟1|� = �|𝑟2|�oppure𝑟1𝑡𝑟1 = 𝑟2𝑡𝑟2 (2.15) 2 Per maggiori informazioni consultare l’Appendice A


16

da cui sostituendo

ℎ1𝑇П−𝑇П−1ℎ1 = ℎ2𝑇П−𝑇П−1ℎ2 (2.16)

per arrivare a

𝑟1 = 𝜆П−1ℎ1

𝑟2 = 𝜆П−1ℎ2

𝑟3 = 𝑟1 × 𝑟2

𝑡 = 𝜆П−1ℎ3

con 𝜆 = 1‖П−1��ℎ1‖� (2.17)

Utilizzando la procedura illustrata pocanzi, può accadere che non venga verificata la condizione

𝑅𝑇𝑅 = 𝑅𝑅𝑇 = 𝐼 (2.18)

Per ovviare a tale problema, si utilizza la scomposizione a valori singolari (SVD) di R, che come sappiamo, fattorizza una matrice in due ortonormali U e V e in una diagonale (D)[5].

2.2 Image Processing

Dal momento che l’ARTollkit fornisce già, attraverso le sue primitive, quelle che sono le informazioni necessarie alla posa del target, l’obbiettivo è stato quello di donare al sistema di percezione una maggiore robustezza, a fronte di diverse condizioni di luminosità.

Ciò è stato possibile utilizzando delle tecniche di image processing. Infatti, poiché il tool basa il suo funzionamento


17

sul corner detection, prendendo spunto dal diagramma di flusso di fig. 2.5, il quale esplica i passi principali eseguiti dal software, si è deciso di operare a monte, cioè nella fase di binarizzazione dell'immagine, attraverso l'utilizzo di un opportuno algoritmo di thresholding.

Figura 2.5 fasi di image processing dell'ARToolKit


18

Figura 2.6 diagramma di flusso del processo di image processing effettuato da ARToolKit

Prima di illustrare tale algoritmo si esporranno, senza scendere eccessivamente in dettaglio, alcuni concetti basilari di image processing.

2.2.1 La segmentazione

Si riferisce al processo di partizionamento di un’immagine in segmenti(composti da set di pixels), i quali si ottengono assegnando ad ogni pixel una label, a seconda di


19

determinate caratteristiche; ciò permette di raggruppare i pixels che hanno qualità comuni. L’obbiettivo di tale tecnica, è quello di semplificare e trasformare l’immagine di partenza in qualcosa che sia più facile da analizzare.[6]

Questa tecnica, pertanto, si presta bene ad essere la base di partenza per tutte quelle operazioni che, come il riconoscimento dei contorni (edgedetection), sono essenziali per la futura identificazione di qualsiasi oggetto.

2.2.2 Edgedetection

L’ edgedetection permette d’identificare i punti di un’ immagine, in cui l'intensità luminosa cambia bruscamente e con discontinuità, diventando così fondamentale per il cosiddetto feature-detection, ovvero la capacità di estrapolare quelli che sono i tratti distintivi di ogni immagine. La funzione in analisi, elimina la maggior parte dei dettagli non rilevanti, al fine dell'individuazione dei contorni, conservando, invece, le informazioni essenziali per descrivere la forma e le caratteristiche strutturali e geometriche degli oggetti rappresentati.

Esistono molti metodi per riconoscere i contorni, ma la maggior parte può essere raggruppata in due categorie: metodi basati sulla ricerca (search-based) e metodi basati sull'attraversamento dello zero (zero-crossing). I metodi basati sulla ricerca, riconoscono i contorni cercando i massimi ed i minimi della derivata del primo ordine dell'immagine, di solito cercando la direzione in cui si ha il massimo gradiente locale. I metodi zero-crossing, cercano i punti in cui la derivata del secondo ordine passa per lo zero,

http://it.wikipedia.org/wiki/Intensit%C3%A0_luminosa�

http://it.wikipedia.org/wiki/Derivata�


20

solitamente la funzione laplaciana o un'espressione differenziale di una funzione non-lineare.[7]

2.2.3 Thresholding

Dopo aver calcolato la derivata, il passo successivo è applicare una soglia (threshold), per valutare i punti dell'immagine in cui potrebbe essere presente un contorno. Più bassa è la soglia, più linee verranno individuate, ed i risultati diverranno sempre più affetti da disturbi, causati dal rumore di fondo, con conseguenti maggiori possibilità di falsi riconoscimenti. Più alta è la soglia e più ci sarà il rischio di non rilevare contorni formati da linee sottili o segmentate. Per cercare di ovviare a questi due opposti inconvenienti si usa spesso il metodo della sogliatura adattiva o thresholding adattativo. Nel processo di thresholding, quindi, ogni pixel viene marcato o come pixel dell’oggetto, se il suo valore è più grande del threshold (assumendo che l’oggetto debba essere più luminoso dello sfondo) o come pixel dello sfondo. Tutto ciò, nel momento in cui si attribuisce 1 al pixel dell’oggetto e 0 a quello dello sfondo, porta alla creazione di un’immagine binaria, che si basa, quindi, sulla “label” identificativa di ogni pixel.

Le tecniche che possono essere impiegate per il calcolo del threshold sono molteplici. Si passa, infatti, dalla semplice impostazione manuale del valore, al calcolo della media o della mediana del valore dei pixel oggetto-sfondo, oppure all’utilizzo di algoritmi più complessi che confluiscono, come si avrà modo di vedere, in quello che viene definito thresholding dinamico adattativo.[8]


21

2.2.3.1 Adaptivethresholding : Otsumethod

Il thresholding viene chiamato adattativo quando viene applicato un threshold differente per ogni immagine[8].

In tal senso, un’ottima soluzione, considerando sia il tipo di target con cui abbiamo a che fare sia le performance che vengono fornite, è rappresentata dal threshold di Otsu.

L’algoritmo assume che l’immagine contenga due classi di pixels (target e sfondo); in una condizione del genere, vale a dire quando lo sfondo è separato dagli oggetti in primo piano, l’istogramma dei livelli di grigio ha un andamento bimodale, ciò si può interpretare come una sovrapposizione di due gaussiane.

Figura 2.7 esempio di immagine che produce un istogramma bimodale

In tal caso la soglia (threshold) ottimale che separa le due gaussiane viene trovata con l’algoritmo di Otsu, il quale trova il valore che massimizza la varianza tra classi e minimizza la varianza all’interno delle classi.


22

Si può dimostrare che il valore del livello di grigio è quello per cui il valore della seguente espressione, detta between variance, è massimo

𝜎𝐵2 = 𝑞1(𝑡)[1 − 𝑞1(𝑡)][𝜇1(𝑡)− 𝜇2(𝑡)]2 (2.19)

• 𝑞1(𝑡) = ∑ 𝑝(𝑘)𝑡

𝑘=1 è la probabilità della prima classe

• 𝜇1(𝑡) = ∑ 𝑝(𝑘)𝑘𝑡𝑘=1 è la media dei valori della

prima classe • 𝜇2(𝑡) = ∑ 𝑝(𝑘)𝑘𝑁

𝑘=𝑡+1 è la media dei valori nella seconda classe (N è il numero di livelli di grigio).

2.3 Network

Ricordando che, l’architettura delrobotU-Go consta di due computer, di cui uno adibito alla visione ed uno alla navigazione, si è pensato di implementare, al fine di garantire la comunicazione tra queste parti, un socket, sfruttando il protocollo di comunicazione UDP.

2.3.1 Il protocollo UDP

L’UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è contenuta dell'RFC 768, ma in sostanza esso è una semplice interfaccia a IP dal livello di trasporto. Quando un'applicazione usa UDP, essa scrive un pacchetto di dati (il cosiddetto datagram, che dà il nome al protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice), e poi viene passato al livello superiore, (IPv4 o IPv6 che sia) che lo spedisce verso la

http://www.ietf.org/rfc/rfc0768.txt�


23

destinazione. Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso ordine in cui sono stati spediti.

Pertanto, il problema principale che si affronta quando si usa UDP è la mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a destinazione occorrerà provvedere con l'applicazione, all'interno della quale si dovrà inserire tutto quanto necessario a gestire la notifica di ricevimento, la ritrasmissione, il timeout.

Si tenga conto poi che, in UDP niente garantisce che i pacchetti arrivino nello stesso ordine in cui sono stati trasmessi, e può anche accadere che i pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto questo di nuovo deve tenere conto l'applicazione.

Un altro aspetto di UDP è che, se un pacchetto raggiunge correttamente la destinazione esso viene passato all'applicazione ricevente in tutta la sua lunghezza, la trasmissione avviene perciò per record

Infine, UDP è un protocollo che opera senza connessione (

la cui lunghezza viene anch’ essa trasmessa all'applicazione all'atto del ricevimento.

connectionless), in quanto non è necessario stabilire nessun tipo di relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni in cui un client può scrivere su uno stesso socket pacchetti destinati a server diversi, o un server ricevere su un socket pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi il funzionamento di


24

UDP è quello della radio, in cui si può trasmettere e ricevere

Nonostante gli evidenti svantaggi comportati dall'inaffidabilità, UDP ha il grande pregio della velocità, che in certi casi è essenziale; inoltre, si presta bene per le applicazioni in cui la connessione non è necessaria, e costituirebbe solo un peso in termini di prestazioni, mentre una perdita di pacchetti può essere tollerata, ad esempio le nelle applicazioni di streaming e quelle che usano il multicasting.

da più stazioni usando la stessa frequenza.

2.3.2 Socket Un socket è un canale di comunicazione tra due processi che possono risiedere anche su host diversi. I due processi comunicheranno fra loro leggendo e/o scrivendo i dati nel socket. Come illustrato precedentemente, UDP è un protocollo molto semplice che non supporta le connessioni e non è affidabile; ciò però consente di avere un guadagno prestazionale in termini di velocità di trasmissione rispetto al TCP.

Questo significa che, a differenza dei socket TCP, i socket UDP non supportano una comunicazione di tipo stream in cui si ha a disposizione un flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto una comunicazione di tipo datagram, in cui i dati arrivano in singoli blocchi che devono essere letti integralmente.


25

Questo diverso comportamento significa anche che i socket UDP, pur appartenendo alla famiglia PF_INET, devono essere aperti quando si usa la funzione socie, utilizzando per il tipo di socket il valore SOCK_DGRAM

Questa differenza comporta ovviamente che, anche le modalità con cui si usano i socket UDP siano completamente diverse rispetto ai socket TCP, ed in particolare non esistendo il concetto di connessione, non esiste il meccanismo del

.

three way handshake, né quello degli stati del protocollo. In realtà tutto quello che avviene nella comunicazione attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un server o viceversa, secondo lo schema illustrato in fig2.73

[4]

Figura 2.8 schema di trasmissione di un pacchetto attraverso un socket UDP

3 Per conoscere passaggi che di norma vengono effettuati per ottenere la comunicazione client/server consultare il paragrafo 3.3.2 analisi del codice


26

2.4 Le leggi di controllo

Trovate le informazioni riguardanti la posa del target, il passo finale è stato quello di implementare una legge di controllo sul moto che permettesse al robot di seguire effettivamente la traiettoria che il target aveva compiuto.

2.4.1 Feedback control

Considerando un robot di tipo differential drive

Figura 2.9 esempio robot

possiamo definire tre sistemi di riferimento 𝑋𝑟R𝑌𝑟 , 𝑋𝑖I𝑌𝑖 e 𝑋𝑔G𝑌𝑔, rispettivamente del robot, del sistema inerziale e del target (goal), e l’errore


27

𝑒 = �𝑥𝑦𝜃� (2.20)

La cui evoluzione, in accordo a quelle che sono le leggi che governano un differential drive è

�𝑥𝑦�� = �

cos 𝜃 0sin𝜃 0

0 1� (2.21)

Passando ora per convenienza, alle coordinate polari si ha che:

nell’intervallo α ∈ 𝐼1; 𝐼1 = �− π2� , �𝜋2� (2.22)

ponendo

ρ=�∆𝑥2 + ∆𝑦2

𝛼=-𝜃 + 𝐴𝑇𝐴𝑁2(∆𝑦,∆𝑥)

𝛽 = −𝜃 − 𝛼 (2.23)

il sistema errore diventa

�𝜌��

� =

⎣⎢⎢⎡−cos𝛼 0sin𝛼𝜌

−1

− sin𝛼𝜌

0 ⎦⎥⎥⎤�𝑣𝜔� (2.24)

Mentre nell’intervallo

α ∈ 𝐼2; 𝐼2 = (−π �,− �𝜋2� ∪ �𝜋

2� , �𝜋] (2.22)

si ha


28

�𝜌��

� =

⎣⎢⎢⎡

cos𝛼 0−sin𝛼

𝜌−1

sin𝛼𝜌

0 ⎦⎥⎥⎤�𝑣𝜔� (2.25)

Ciò ci fa capire che per α ∈ 𝐼1 il robot va avanti, mentre per α ∈ 𝐼2 va indietro.

Definendo, però opportunamente, la direzione avanti nella configurazione iniziale, è sempre possibile avere per t=0 (non è detto che lo rimanga per tutti i valori di t). Per evitare cambiamenti di direzione durante l’avvicinamento all’obiettivo è meglio che per tutti i valori di t. A questo punto definendo una legge di moto siffatta:

�𝑣 = 𝑘𝜌𝜌

𝜔 = 𝑘𝛼𝛼 + 𝑘𝛽𝛽� (2.26)

si ottiene

�𝜌��

� = �

−𝑘𝜌𝜌 cos𝛼𝑘𝜌 sin𝛼 − 𝑘𝛼𝛼 − 𝑘𝛽𝛽

−𝑘𝜌 sin𝛼� (2.27)

che ha come unico punto di equilibrio

�𝜌𝛼𝛽� = �00

0� (2.28)

ed è localmente ed esponenzialmente stabile se

𝑘𝜌 > 0; 𝑘𝛽 < 0; 𝑘𝛼 − 𝑘𝜌 > 0 (2.29) [9]

Capitolo 3 Il software

3. Il software

In questa sezione verrà descritto in dettaglio tutto ciò che riguarda il funzionamento, le scelte implementative e i risultati del software sviluppato.

3.1 Strumenti utilizzati

Il software è stato realizzato in C++, mediante la suite di programmazione Microsoft Visual studio 2005, integrando le librerie grafiche OpenCV e ARToolKit.

3.1.1 Le openCV

LeOpenCv sono delle librerie grafiche, multipiattaforma Open source, sviluppate da Intel.

Scritte in linguaggio C e C++, contengono più di 500 funzioni C, le quali forniscono un’interfaccia di programmazione di medio-alto livello, oltre a numerose strutture dati, utili ai fini della gestione di immagini e della manipolazione di matrici. Tutte le funzioni sono accomunate dal prefisso “cv”, mentre i nomi delle classi hanno il prefisso “Cv”, ad eccezione della IplImage, ereditata evidentemente dalla libreria IPL. Tra le più importanti classi disponibili, oltre alla già citata struttura IplImage (che restituisce un buffer immagine), vi sono le strutture: CvArr (che restituisce come “oggetto” un array), CvMat (che restituisce come “oggetto”una matrice numerica), CvRect ( che restituisce come “oggetto” un


30

rettangolo), le strutture dinamiche per l’allocazione di buffer di memoria, come CvMemStorage, o perla creazione di sequenze, come CvSeq. Ovviamente vi sono, tra gli altri, anche gli oggetti: CvPoint ( che restituisce un punto) e CvSize ( che restituisce una dimensione).La libreria è divisa in alcuni file binari distinti (“dll” o “so” a seconda dei sistemi). Le librerie OpenCV sono tre: cv, cxcore ed highgui[10]. La libreria cv include praticamente tutte le funzioni di trattamento ed analisi delle immagini (conversione in scala di grigi, in binario, segmentazione, analisi sui contorni, object tracking, calibrazione della camera ecc.). La libreria cxcore è: l’oggetto principale che include tutte le funzioni di inizializzazione delle strutture utilizzate, l’algebra lineare e le altre funzioni di base. La libreria highgui (include CvCam nella versione 1.1) contiene alcune comode funzioni GUI, come caricare o salvare immagini, creare finestre, ha anche, funzioni di acquisizione video e di gestione delle telecamere. Inoltre, è inclusa una libreria dedicata alla machine learning (MLL), che è focalizzata nel riconoscimento e nel raggruppamento di pattern, e contiene funzioni sui classificatori, sulle reti neurali ecc. [10]

3.1.2 ARToolkit

L’ARToolKit sviluppato dal Dr. Hirokazu Kato dell’università di Osaka, consiste in un set di librerie multipiattaforma scritte in linguaggio C/C++, che permettono all’utilizzatore di sviluppare agevolmente applicazioni di “Realtà Aumentata” (AR). Tale realtà, come


31

detto precedentemente, consiste nel sovrapporre a oggetti reali, oggetti o immagini virtuali.

Osservando la figura sottostante, si nota come tale tool si appoggi alle OpenGL, per quanto riguarda la parte di rendering, ed alle video library e le standard API dell’Hardware ospitante.

Figure 3.1 relazione tra le applicazioni e le librerie di ARToolKit

Scendendo in dettaglio, l’ARToolKt può essere ancora suddiviso nei seguenti moduli:

• Modulo AR: modulo che contiene le routines adibite al tracking del target e alla calibrazione.

• Modulo video: contenente le routines per la cattura del video.

• Modulo Gsub: contenente le librerie GLUT e una serie di routines basate su OpenGL.

• Modulo Gsub_Lite:modulo che può rimpiazzare il Gsub, apportando routines grafiche più performanti, ma che forniscono dei risultati meno accurati.


32

Figura 3.2 The strutture gerarchica delle librerie ARToolkit.

Tutto ciò in un’ipotetica pipeline metaphor

(video->tracking->display), potrebbe essere rappresentato dalla figura 3.3. [11]

Figura 3.3 pipeline di attivazione

3.2 Installazione

Per poter installare le librerie OpenCV e l’ARToolkit, su Microsoft Visual Studio 05, sono state effettuate le seguenti operazioni.


33

3.2.1 OpenCV

I passaggi da seguire per poter integrare le OpenCV sono i seguenti:

• Installare l’eseguibile OpenCV_1.1pre1a.exe. • Controllare che nella variabile d’ambiente “path” vi sia

C:\OpenCV\bin, altrimenti aggiungerlo. • Cliccare su “OpenCV workspace .NET 2005 2008” da

START->PROGRAMMI->OPENCV.

Figura 3.4 installazione OpenCv 3° passaggio

• Apertosi l’IDE, selezionare “Tools” e poi “Options”.


34


• In “Project and Solution”, scegliere “VC++ Directory”, quindi selezionare “Library File” e aggiungere il path di installazione\lib.


• Tornare nella schermata principale di VS 05 e scegliere “Build” e “Configuration Manager”cambiando “Active solution configuration” da “Debug” in “Active” o viceversa.


35


• Fatto questo, selezionando dal menu”Build” “Build solution” si può compilare il tutto.

3.2.2 Creare un proprio programma

Per creare un proprio programma, capace di sfruttare le librerie OpenCV, dopo aver creato tramite VS 05 un’ applicazione di qualsivoglia tipologia, bisogna:

• cliccare con il tasto destro sul progetto selezionando “proprietà” scegliere poi da “configuration properties” la sezione C/C++ e inserire come directory di inclusione aggiuntive C:\OpenCV\cvaux\include\; C:\OpenCV\cxcore\include\; C:\OpenCV\cv\include\; C:\OpenCV\otherlibs\highgui\; C:\OpenCV\bin\;.


36

Figura 3.8 creazione di un’applicazione OpenCv 1° passo

• Andare su “Linker”-> “Input” e in “Dipendenze aggiuntive aggiungere:

"C:\OpenCV\lib\cv.lib" "C:\OpenCV\lib\cvaux.lib" "C:\OpenCV\lib\cxcore.lib" "C:\OpenCV\lib\highgui.lib".

Figura 3.9 creazione di un’applicazione OpenCv 2° passo


37

• Se dopo aver scritto il programma e mandato in run, dovessero esserci degli errori dovuti a dll mancanti, copiare le suddette in system32.

3.2.3 ARtoolKit

3.2.4 Installazione GLUT

Se si vuole mantenere l’utile funzionalità di visualizzare oggetti 3D, è necessario installare prima del tool vero e proprio, le OpenGL Utility Toolkit(GLUT). Tali API, scritte in linguaggio C, permettono di sviluppare ed eseguire programmi OpenGL.

• Scompattare il file “glut-3.7.6-bin.rar”. • Creare in C: una cartella con nome “OGLSDK”e“glut”,

contenenti a sua volta altre due cartelle “include” e “lib”. • Dentro la sottocartella “include” di “glut” crearne un’altra

“GL”. • Smistare i file contenuti in “glut-3.7.6-bin.rar” all’interno

delle cartelle appena create nel seguente modo: o In “glut/include/GL” mettere l’header file “glut.h” o In “glut/lib” mettere: “glut32.dll”, “glut32.lib”,”glut.def” • Aggiungere nella variabile d’ambiente “path”:

C:\OGLSDK\lib;C:\glut\lib;. • Aprire VS05 e in Tools->Options->Projects and Solution-

>VC++ Directories scegliere “Include Files” e aggiungere C:\OGLSDK\include C:\glut\include.

• Scegliere successivamente “Library Files” e aggiungere C:\OGLSDK\lib C:\glut\lib.


38

3.2.5 Installazione ARTOOLKIT

Fatto questo è possibile installare l’ARToolkit affidandosi alla seguente procedura:

• Scompattare il file ARToolKit-2.72.1-bin-win32in C:\ARToolKit.

• Scompattare il file “DSVideoLib” dentro la cartella ARToolKit creando la cartella “DSVL”.

• Copiare i files DSVL.dll e DSVLd.dll da {ARToolKit}\DSVL\bina {ARToolKit}\bin.

• Installare GLUTDLL dentro la cartella di Windows System32.

• Eseguire lo script {ARToolKit}\Configure.win32.bat per creare il file include/AR/config.h.

• Aprirel’ ARToolKit.sln file (VS.NET) o l’ ARToolkit.dsw file (VS6).

• Compilare il tutto.

Figura 3.10 risultato finale dell'operazione di installazione dell'ARToolKit


39

3.2.6 Creare un proprio programma

Per creare un proprio programma capace di sfruttare tali librerie bisogna, dopo aver creato tramite VS 05, un’ applicazione di qualsivoglia tipologia:

• Cliccare con il tasto destro sul progetto selezionando “proprietà”.

• Da “configuration properties” selezionare C/C++ e inserire come directory di inclusione aggiuntive C:\ARToolKit\include\;

Figura 3.11 risultato creazione di un’applicazione 2° passaggio

• Andare su “Linker”-> “Input” e in “Dipendenze aggiuntive aggiungere:


40

"C:\ARToolKit\lib\libARd.lib" "C:\ARToolKit\lib\libARgsub.lib" "C:\ARToolKit\lib\libAvvideo.lib" “opengl32.lib” “glu32.lib”.

Figura 3.12 risultato creazione di un’applicazione 3° passaggio

3.3 Analisi del software

L’interfaccia utente del software, come si evince dalla figura sottostante (fig. 3.13), ritrae i tratti distintivi di una tipica “applicazione console”, in cui si distinguono le finestre di input e di output.


41

Figura 3.13 interfaccia utente del software

Per quanto concerne l’input, è possibile, attraverso la pressione dei tasti indicati, attivare o disattivare le seguenti funzioni

• O ottimizzazione: usato per forzare l’uso di un threshold di tipo statico oppure dinamico adattativo4

• S salvataggio dati: permette la creazione di un file log in cui vengono riportati assieme ad un timestamp le variabili di output di maggiore interesse.

.

• N abilita server: abilita la porzione di codice che attende alla creazione di un server socket UDP, al fine di inviare i dati a qualunque unità elaborativa ne faccia richiesta.

• V visualization mode: mostra a video i passaggi di image processing effettuati, come: la conversioni in scala di grigi, l’equalizzazione e il thresholding.

• ESC uscita. 4 Per maggiori informazioni consultare il paragrafo relativo al Thresholdig


42

Diversamente, sono demandate alla finestra di output, la visualizzazione del target e delle informazioni come: matrice di rotazione, distanza sui tre assi, angoli di rotazione del target e i valori di velocità lineare (V) e angolare (W) estratti dalla legge di controllo.

3.3.1 Analisi del software: il funzionamento

Poiché il fulcro del software è rappresentato dall’ARToolKit, esso segue gli stessi flussi di elaborazione di ogni altro programma sviluppato utilizzando tale tool.

Si comincia con la fase di “Inizializzazione”, in cui si prepara il dispositivo di input e si caricano allo stesso tempo in memoria i dati relativi al target e ai parametri intrinseci della telecamera.

Si passa poi, alla fase chiamata “Mainloop”, fase che verrà ripetuta consecutivamente fino al termine del programma, e in cui il software si occuperà di catturare il frame di input, cercare all’interno di esso il target, calcolare i parametri di interesse e mostrare a video il tutto.

La fase finale è quella di“Shoutdown”, in cui viene chiusa la procedura di cattura video e rilasciate le variabili.[11]


43

Initialization

1. Inizializzazione della webcam e caricamento in memoria dei files del target e dei parametri intrinseci.

MainLoop

2. Cattura dei frame video.

3. Individuazione e riconoscimento del target nel frame acquisito.

4. Calcolo dei parametri di interesse.

5. Rappresentazione a video dei parametri tramite OpenGl.

Shutdown 6. Chiusura del flusso video e rilascio della memoria.

Figura 3.14 Flusso di elaborazione di un programma sviluppato con ARToolKit

Per riuscire però nel suo intento, cioè poter sovrapporre l’immagine virtuale al target, l’ARToolKit svolge i seguenti passi:

• Dopo aver acquisito il frame dalla telecamera, il software cerca all’interno di essa le figure quadrangolari corrispondenti al target.

• Nel momento in cui il target viene rilevato, vengono calcolate le informazioni relative alla sua posizione.

• Viene, a questo punto, passato il tutto alle OpenGl, che si occuperanno di sovrapporre nella giusta posizione l’oggetto 3D.[11]


44

Figura 3.15 flusso di lavoro del tool

3.3.2 Analisi del software: il codice

In questo paragrafo ci si occuperà di dare una descrizione quanto più dettagliata del codice sviluppato. Esso sostanzialmente prende spunto dall’esempio di ARToolKit exview in quanto, tale esempio, fornendo i dati relativi alla posa del target, costituisce un’ottima base su cui sviluppare il lavoro.

Aprendo la solution relativa all’ elaborato ci si troverà di fronte a due file .cpp. Draw_object, in cui risiedono esclusivamente le funzioni OpenGl atte a rappresentare l’output, e il file exview, che invece contiene il codice vero e proprio. Introdotta brevemente la struttura, si può iniziare a descrivere quest’ultimo file.


45

Come di norma, la prima cosa che si trova in qualunque file C sono le inclusioni e le definizioni di variabili, in questo caso, necessarie al corretto funzionamento di OpenCV, OpenGl, ARToolKit e del socket UDP. #ifdef _WIN32 #include<windows.h> #endif #include<stdio.h> #include<winsock.h> #include<math.h> #include<stdlib.h> #include<string.h> // inclusioni OpenCV #include<cv.h> #include<highgui.h> //inclusioni OpenGl #ifndef __APPLE__ #include<GL/gl.h> #include<GL/glut.h> #else #include <OpenGL/gl.h> #include <GLUT/glut.h> #endif //inclusioni ARToolkit #include<AR/gsub.h> #include<AR/video.h> #include<AR/param.h> #include<AR/ar.h> #include"draw_object.h" #define pi 3.14159265358979323846 #define TODEGREES(x) ((x)*180.0/pi)

…

nt xsize; int ysize; int thresh,Otsu_thresh ; int static_thresh; ARParam cparam; int outputMode = 1;…

int target_id,target_id1,targetid_2; double target_center[2] = {0.0, 0.0}; double target_width = 210.0; // dimensione del target /* OPENCV*/ CvImage *image; CvSize size; int channels, maxlength; IplImage *img; IplImage* normal_Thresh; …

/* SOCKET structure definition*/ SOCKET miosock,client; struct sockaddr_in miosock_addr,client_addr; WSADATA data; WORD p;


46

HWND hwnd;…

Si continua poi, con la funzione main int main(int argc, char **argv)

in cui si troverà:

• L’inizializzazione delle strutture necessarie alla creazione del socket p=MAKEWORD(2,0); err=WSAStartup(p,&data); miosock=socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP); memset((void *)&miosock_addr, 0, sizeof(miosock_addr)); miosock_addr.sin_family=AF_INET; miosock_addr.sin_port=htons(1111);//(atoi("1111")); miosock_addr.sin_addr.s_addr=INADDR_ANY; err=bind(miosock,(struct sockaddr*)&miosock_addr,sizeof( miosock_addr)); u_long iMode=1; ioctlsocket(miosock,FIONBIO,&iMode);//socket non bloccante

• Il richiamo delle funzioni init e MainLoop5

glutInit(&argc, argv);

di ARToolkit

if( init() < 0 ) exit(0); printf("OPTION\n\n V-> visualizzazione dati\n O-> ottimizzazione\n S-> salvataggio dati\n N ->Abilita Server\n ESC-> esci\n\n\n Log comandi \n\n "); arVideoCapStart(); argMainLoop( NULL, keyEvent, mainLoop );

in particolare la funzione mainLoop viene richiamata all’interno di argMainLoop, funzione di OpenGl, che si occupa sia del keyEvent, cioè di gestire l’input da tastiera, sia di eseguire in un loop continuo la funzione mainLoop.

Considerando l’ordine di attivazione delle funzioni, subito dopo il main verrà invocata la funzione init staticint init(void)

in cui la prima fase di inizializzazione prevede il caricamento in memoria di due file molto importanti, uno

5Per ulteriori informazioni consultare il paragrafo 3.2.1 Analisi del software


47

relativo ai parametri intrinseci della telecamera e l’altro riguardante il target da riconoscere6

strcpy( cparaname, "Data/Trust_para2.dat"); // parametri intrinseci

strcpy( pattname, "Data/patt.hiro" );//dati relativi al target Hiro

si passa poi a determinare i parametri quali :dimensione della finestra video e numero di frame al secondo. open the video path */ if( arVideoOpen( vconf ) < 0 ) exit(0); /* find the size of the window */ if( arVideoInqSize(&xsize, &ysize) < 0 ) exit(0); printf("Image size (x,y) = (%d,%d)\n", xsize, ysize); /* set the initial camera parameters */ if( arParamLoad(cparaname, 1, &wparam) < 0 ) { printf("Camera parameter load error !!\n"); // exit(0); }

L’ultima inizializzazione riguarda le OpenCV e nella fattispecie la creazione di un’IplImage necessaria alle succesive elaborazioni

/**openCV**/ size.width = xsize; size.height = ysize; img = cvCreateImage(size, IPL_DEPTH_8U, 4);

Prima di analizzare la funzione mainLoop si precisa che, al fine di ottenere una migliore fluidità espositiva, tutte le sotto funzioni che di volta in volta si incontreranno veranno debitamente illustrate successivamente considerando, però sempre, l’ordine di invocazione. La funzione mainLoop, invocata continuamente all’interno di argmainLoop, comprende tutte le funzioni necessarie al corretto funzionamento del softaware come:

• La cattura di frame dal video *cattura di frame video */ if( (dataPtr = (ARUint8 *)arVideoGetImage()) == NULL ) {

6 Consultare le Appendici B e C


48

arUtilSleep(2); return; }

E la sua elaborazione tramite le OpenCV

img->imageData = (char *)dataPtr; //conversione da ARUint8 a IplImage /*procedura per applicare il threshold*/ gray = cvCreateImage( cvSize(img->width, img->height), IPL_DEPTH_8U, 1 );// creo L’IplImage che conterrà l' immagine in scala di grigi normal_Thresh = cvCloneImage( gray ); //duplico l'immagine gray -> creando l'immagine che farà vedere il normal_thresh cvCvtColor( img, gray, CV_BGR2GRAY ); … …

• L’individuazione o meno del target all’interno del frame

analizzato avviene utilizzando prima la funzione arDetectMarker, la quale prende in ingresso il frame e il threshold e ritorna:

o marker_num, numero di marker trovati o marker_info, puntatore ad una lista di strutture di marker

contenete infrmazioni quali coordinate, id e recognition confidence value (cf). Quest’ultimo valore permette di assegnare al presunto target un grado di affidabilità. if((r= arDetectMarker(dataPtr2, thresh, &marker_info, &marker_num)) < 0 ) {// riattivare // if((r= arDetectMarkerLite(dataPtr2, thresh, &marker_info, &marker_num)) < 0 ) { cleanup(); exit(0); } arVideoCapNext(); …

Successivamente per tutti i presunti target identificati, viene confrontato l’id con quello derivato dal file e, al fine di evitare falsi riconoscimenti, operata una sogliatura tramite il campo cf k = -1; for( j = 0; j < marker_num; j++ ) {


49

if((marker_info[j].id == target_id)&& (marker_info[j].cf>0.7)) {//autmento della robustezza a fronte di falsi target if( k == -1 ) k = j; else { if( marker_info[k].cf < marker_info[j].cf ) k = j; } } } if( k != -1 ) {//viene riconosciuto il target glDisable(GL_DEPTH_TEST); switch(1){ //case 0: //break; case 1:

e calcolo dell’output getResultQuat( &marker_info[k]);// calcolo dell'output

La prima delle “sottofunzioni” richiamate all’interno di mainLoop è int OtsuThreshold2(IplImage *image)

questa funzione si occupa di calcolare il threshold adattativo di Otsu7

{ IplImage *dst = cvCreateImage(cvGetSize(image),8,image->nChannels); int minMax[2] = { 0, 0 }; double mean[2] = { 0, 0}; MinMax(image, minMax); if(minMax[0] == minMax[1]) { cvZero(dst); return 100; //valore inalterato } int T = 0.5 * (minMax[0] + minMax[1]); bool done = false; while (!done) { MeanLowHigh(image, mean, T); int Tnext = 0.5 * (mean[0] + mean[1]); done = (abs(T-Tnext) < 0.5); T = Tnext; } cvReleaseImage( &dst ); return T; }

7 Vedere il paragrafo 1.2.3.1 Adaptivethresholding: Otsumethod


50

la seconda funzione invece è staticvoid getResultQuat( ARMarkerInfo *marker_info)

al suo interno ci saranno funzioni adibite al: • Calcolo della matrice di rototraslazione, con la successiva

conversione prima in quaternioni e poi in angoli di Eulero8

arGetTransMat(marker_info, target_center, target_width, target_trans); if( arUtilMatInv(target_trans, cam_trans) < 0 ) return; if( arUtilMat2QuatPos(cam_trans, quat, pos) < 0 ) return; … GetEulerAngles(quat[0],quat[1],quat[2], quat[3], yaw,pitch,roll);

• rappresentazione a viedo dei risultati strcat( string6,string4); sprintf(string5,"%g %g %g \n",cam_trans[2][0],cam_trans[2][1],cam_trans[2][2],cam_trans[2][3]); strcat( string6,string5); strcat( string6,"\n"); sprintf(string1," QUAT: Pos x: %3.1f y: %3.1f z: %3.1f\n",pos0, pos1, pos2);

• calcolare la velocità lineare ed angolare tramite la legge di controllo9

Feedb_control(pos0,pos2); • e nel caso in cui venisse richiesto aprire un socket UDP per

l’invio di dati if(net_mode) {//se il net_mode è abilitato viene inviato il pacchetto con i dati int len_cli=sizeof(client_addr);

client=miosock; char mex2[2000];//buffer di char usati per la comunicazione char buffer[35];

int rec=recvfrom(client,mex2,sizeof(mex2),0,(struct sockaddr*)&client_addr,&len_cli);

//funzione che permette di ricevere informazioni da un client if( rec>0){// se si riceve qualcosa sendto(client,string1, sizeof(string1), 0, (struct sockaddr *)&client_addr,len_cli); //funzione usata per mandare informazioni ad un client }

8 Vedere Appendice A: Matrici di rotazione e angoli di Eulero 9 Per maggiori informazioni consultare il paragrafo relativo alla legge di controllo


51

3. 4 Risultati

Le prove effettuate al fine di appurare il corretto funzionamento del software sono classificabili in tre categorie.

La prima tipologia che, potremmo definire come “prove di misurazione”, nasce dall’esigenza di verificare che le informazioni necessarie alla posa del target, intese come distanza webcam target, siano esatte.

La seconda, definibile come “prova di robustezza” si occupa invece di constatare, a fronte di diverse condizioni di luminosità, gli effettivi benefici in termini di robustezza del sistema di percezione del target, adoperando il cosiddetto threshold adattativo 10

Con la terza, catalogabile come “prove di inseguimento”, si vuole accertare che la legge di moto utilizzata sia effettivamente in grado di condurre il robot nella posizione occupata dal target.

al posto di quello statico.

3.4.1 Le prove di misurazione

Dal momento che l’ARTollkit fornisce già, attraverso le sue primitive, quelle che sono le informazioni necessarie alla posa del target, il nostro primo obbiettivo è stato quello di appurare che l’output, inteso come distanza webcam target fosse esatto.

Queste prove sono state effettuate semplicemente valutando la distanza e il rispettivo errore percentuale

10 Vedere il paragrafo Threshold adattativo: Il metodo di Otsu


52

presente tra webcam e target lungo gli assi X e Z; assi necessari per la determinazione della legge di controllo 11

.

Figura 3.16 metodo di misurazione lungo l’asse Z

Figura 3.17 metodo di misurazione lungo l’asse X

11Per maggiori chiarimenti consultare il paragrafo 2.4.1 Feedback control


53

1m

EFFETTIVI RILEVATI ERR % ASSE Z(cm) 100 99.6 +0.3732 ASSE X(cm) -20 -19.5 -2.5

-10 -9.7 -3 0 0.2 +0.2 10 9.7 +3 20 20.7 +3.5

Figura 3.17 dati rilevati alla distanza di un metro

2 m EFFETTIVI RILEVATI ERR %

ASSE Z(cm) 200 199.1 0.8993 ASSE X(cm) -50 -55.1015 -10.2029

-40 -42.1985 -5.4963 -30 -31.7110 -5.7034 -20 -20.5107 -2.5533 -10 -10.8981 -8.9811 0 0.1642 0.16 10 9.5854 4.1459 20 20.80 4 30 30.5787 1.9291


54

40 42.0367 5.0918 50 52.0379 4.0758

Figura 3.18 dati rilevati alla distanza di due metri

3 m EFFETTIVI RILEVATI ERR %

ASSE Z(cm) 300 295.2912 1.5696 ASSE X(cm) -50 -54.5124 -9.0247

-40 -43.1711 -7.9277 -30 -31.3020 -4.3400 -20 -20.7970 -3.9849 -10 -10.6 -6 0 0.2979 0.29 10 10.6001 6.0011 20 22.3223 11.6117 30 32.9631 9.8771 40 42.9655 7.4138 50 54.3228 8.6475


55

Figura 3.19 dati rilevati alla distanza di tre metri

ASSE Z

EFFETTIVI RILEVATI ERR % ASSE Z(cm) 100 99.6268 0.3732

150 148.3304 1.1131 200 199.1007 0.4497 250 250.7786 0.3338 300 295.2912 1.5696

Come si evince dalle tabelle, le misurazione sull’asse Z risultano essere più stabili e più precise di quelle sull’asse X.


56

Figura 2.20 andamento dell'errore percentuale delle misurazioni sull'asse X

Figura 3.21 andamento dell'errore percentuale delle misurazioni sull'asse Z

L’andamento dei grafici soprastanti ci indica che, gli errori di misurazione, non sono tali da inficiare l’obbiettivo


57

prefissato; ma allo stesso tempo sono inevitabili in quanto si opera in ambiente esterno, e si attestano rispettivamente in un intorno del ± 10%, per quanto riguarda l’asse X, e dell’ 1.6% per quanto riguarda l’asse Z.

Figura 3.22 diagramma di taratura riguardante l'asse X a 3 metri

Figura 3.23 diagramma di taratura riguardante l'asse X a 2 metri


58

Figura 3.24 diagramma di taratura riguardante l'asse X a 1 metro

Figura 3.25 diagramma di taratura riguardante tutte le misurazioni sull'asse X


59

Figura 3.26 diagramma di taratura riguardante tutte le misurazioni sull'asse Z

Anche osservando i grafici relativi alle distribuzioni delle misure, si perviene alle stesse conclusioni, ossia che il discostamento tra i dati rilevati e quelli effettivi è più che accettabile per il tipo di applicazione per cui è stato pensato tale software.

3.4.2 Le prove di robustezza

Per lo svolgimento tali prove, si è tentato di effettuare il riconoscimento del target, utilizzando i due tipi di threshold, in condizioni di luce riconducibili ai seguenti scenari:

• Indoor - luce naturale. • Indoor - scarsa luminosità.


60

• Outdoor - forte luminosità. • Outdoor - scarsa luminosità.

Ed impostando ai valori di 30 50 100 150 e 200 il threshold statico.

3.4.2.1 Indoor –luce naturale

Otsu Threshold 130 Static Threshold 30

Figura 3.27 percezione del target con threshold di Otsu (sinistra) e statico(destra )


Figura 3.28 percezione del target con threshold di Otsu (sinistra) e statico (destra)


61








62

Effettuando le prove in interno, con luce naturale, si nota che l’algoritmo di Otsu fa oscillare il valore di threshold in un intorno di 119; mentre, operando manualmente si ottiene un riconoscimento del target solo per valori che vanno da 100 a 150.

3.4.2.2 Indoor – scarsaluminosità






63








64

Operando ora in condizioni di scarsa luminosità, l’algoritmo adattativo imposta il thresold sul valore di 27, ciò si riflette nel range di utilizzo del threshold statico che, per valori superiori a 30 non riesce a garantire al software l’individuazione del target.

3.4.2.3 Outdoor – forte luminosità


Figura 3.37 percezione del target con threshol di Otsu (sinistra) e statico (destra)




65








66

Osservando quanto avviene in ambiente esterno con molta luminosità, si appura la necessità di avere un alto valore di thresold che, come visto nel caso del threshold statico, non può scendere al di sotto di 150.

3.4.2.3 Outdoor – scarsaluminosità






67






68



Posizionandosi, invece, in una zona con minore luminosità il raggiungimento del valore massimo di threshold diventa deleterio, ma bisogna attestarsi tra 100 e 150.

Constatato che il threshold adattativo riesce a irrobustire il sistema di percezione a fronte di una variazione di luminosità, i successivi test si sono invece incentrati sulla verifica della bontà della legge di moto.

3.4.4 Le prove di inseguimento

Con l’ultima tipologia di prove si è integrato il software da me sviluppato, con quello presente nel robot U-Go e si è tentato di inseguire il target prefissato.


69

Figure 3.47 sequenza fotografica prova di inseguimento


70

Da come si evince dalle figure soprastanti, il robot riesce a seguire abbastanza fedelmente il target in movimento. Segno che, gli errori di misurazione, inevitabili quando si opera in ambiente esterno, non sono tali da compromettere l’obbiettivo prefissato.

Appendice A

Appendice A : Matrici di rotazione e angoli di Eulero

Data una terna di assi cartesiani [X Y Z] di origine O, detta terna di riferimento, da essa è possibile ottenere nuovi sistemi mediante rotazioni attorno agli assi coordinati.

Figura A1 Terne ottenute dalla terna di riferimento mediante rotazioni:(a) attorno all’asse Z, (b) attorno

all’asse Y, (c) attorno all’asse X

Introducendo, a questo punto, la matrice di rotazione, si può affermare che essa fornisce l’orientamento di una terna di coordinate rispetto ad un’altra.

I versori degli assi della nuova terna, [𝑥′ 𝑦′ 𝑧′]𝑇 , possono essere identificati mediante le loro componenti rispetto agli assi della terna di riferimento, che nel caso di rotazione attorno all’asse Z sono:

Appendice A

72

(A.1.1) 𝑥′ = �cos𝛼sin𝛼

0� , 𝑦′ = �

−sin𝛼cos𝛼

0� , 𝑧′ = �

001� ,

da cui si ottiene la matrice di rotazione della terna[𝑋′ 𝑌′ 𝑍′]:

(A.1.2) 𝑹𝑍(𝛼) = �cos𝛼 −sin𝛼 0sin𝛼 cos𝛼 0

0 0 1�

Ruotando rispetto agli altri due assi invece, si ottiene:

(A.1.3) 𝑹𝑌(𝛽) = �cos𝛽 0 sin𝛽

0 1 0−sin𝛽 0 cos𝛽

�

e

(A.1.4) 𝑹𝑋(𝛾) = �1 0 00 cos𝛾 −sin𝛾0 sin 𝛾 cos𝛾

�.

La matrice di rotazione gode della proprietà si ortogonalità, ovvero:

(A.1.5) 𝐑𝐓𝐑 = 𝐈,

dove I è la matrice identità.

Appendice A

73

Moltiplicando da destra ambo i membri della (A.1.5) per la matrice inversa R−1, si ha il seguente importante risultato:

(A.1.6) 𝐑𝐓 = 𝐑−𝟏,

cioè la trasposta della matrice di rotazione coincide con la sua inversa.

Un’altra proprietà è:

(A.1.7) 𝑹𝑘(−𝜃) = 𝑹𝑘𝑇(𝜃),

con k = x, y, z.

La matrice di rotazione è anche definita matrice dei coseni direttori (DCM), dato che le sue colonne costituiscono i coseni direttori degli assi della terna ruotata rispetto a quelle iniziale.

Una volta note le matrici di rotazione elementari, si possono ottenere rotazioni generiche nello spazio euclideo attraverso composizioni di esse.

E’ convenzione quella di indicare con 𝑹𝑖𝑗 e 𝒅𝑖

𝑗 , rispettivamente, la matrice di rotazione e di traslazione dal sistema 𝑖 al sistema 𝑗.

Siano assegnate tre terne qualsiasi [𝑋0 𝑌0 𝑍0] , [𝑋1 𝑌1 𝑍1] e[𝑋2 𝑌2 𝑍2], aventi origine comune O ed un vettore 𝒖 espresso nelle tre terne con 𝒖0 , 𝒖1 , 𝒖2 , dove il pedice indica il legame con la terna considerata.

Appendice A

74

La relazione tra la rappresentazione del vettore 𝒖0 ed il vettore 𝒖1è espressa dalla seguente equazione:

(A.1.8) 𝒖0 = 𝑹10 ∙ 𝒖1

tra il vettore 𝒖1 ed il vettore 𝒖2 si ha:

(A.1.9) 𝒖1 = 𝑹21 ∙ 𝒖2

tra il vettore 𝒖0 ed il vettore 𝒖2 si ha:

(A.1.10) 𝒖0 = 𝑹20 ∙ 𝒖2

Se si sostituisce l’equazione (A.1.9) nella (A.1.8), si ottiene:

(A.1.11) 𝒖0 = 𝑹10 ∙ 𝑹21 ∙ 𝒖2

Confrontando con la (A.1.10) si ottiene:

(A.1.12) 𝑹20 = 𝑹10 ∙ 𝑹21

Dalla formula (A.1.12), si evince chela matrice di rotazione, ottenuta mediante composizione di rotazioni successive, si ottiene moltiplicando da sinistra verso destra le matrici di rotazione coinvolte, nell’ordine imposto dalla loro sequenza.

Appendice A

75

La rotazione complessiva è espressa come successione di rotazioni parziali, ciascuna delle quali viene definita rispetto all’esito della rotazione precedente. La terna rispetto alla quale avviene la rotazione in atto viene definita terna corrente.

L’ordine in cui vengono moltiplicate non può essere cambiato, poiché il prodotto matriciale non gode della proprietà commutativa.

In virtù dell’ortogonalità delle matrici di rotazione, la matrice inversa è uguale a quella trasposta perciò si ha:

(A.1.13) 𝑹𝑖𝑗 = (𝑹𝑗𝑖 )−1 = (𝑹𝑗𝑖 )𝑇 .

Se ci si riferisce ad una terna fissa, invece, si ottiene che la matrice di rotazione complessiva è data dal prodotto da destra verso sinistra delle singole matrici di rotazione, secondo l’ordine imposto dalla sequenza delle rotazioni.

Le matrici di rotazione forniscono una descrizione ridondante dell’orientamento di una terna, dovuta al fatto che i 9 elementi che le compongono sono legati da 6 vincoli dati dalla (A.1.5) .

Di conseguenza, i parametri per ottenere una rappresentazione minima dell’orientamento sono 3. Una di queste rappresentazioni può essere ottenuta utilizzando gli angoli di Eulero, ovvero gli angoli necessari a definire rotazioni attorno ai tre assi coordinati ( [ φθψ ] ) .

Tali angoli, usati in ambito aeronautico, si riferiscono al moto di rollio (Roll), di beccheggio (Pitch) e di imbardata (Yaw) attorno a tre assi di rotazione.

Appendice A

76

Figura A2 Angoli di Eulero usati in aeronautica

In virtù di tale scelta, le matrici di rotazione assumono la seguente forma:

(A.1.14) 𝑹𝑋(𝜙) = �1 0 00 cos𝜙 −sin𝜙0 sin𝜙 cos𝜙

�

(A1.15) 𝑹𝑌(𝜃) = �cos𝜃 0 sin 𝜃

0 1 0−sin𝜃 0 cos𝜃

�

Appendice A

77

(A.1.16) 𝑹𝑍(𝜓) = �cos𝜓 −sin𝜓 0sin𝜓 cos𝜓 0

0 0 1�.

Ciò posto, la matrice complessiva che si ottiene dalla composizione delle tre rotazioni è:

(A.1.17) 𝑹 = 𝑹𝑋(𝜙) ∙ 𝑹𝑌(𝜃) ∙ 𝑹𝑍(𝜓)

Esplicitando si ha che:

(A.1.18)

𝑅 = �cos 𝜃 cos𝜓 cos 𝜃 sin𝜓 −sin𝜃

sin𝜙 sin𝜃 cos𝜓 − cos𝜙 sin𝜓 sin𝜙 sin 𝜃 sin𝜓 + cos𝜙 cos𝜓 sin𝜙 cos 𝜃cos𝜙 sin 𝜃 cos𝜓 + sin𝜙 sin𝜓 cos𝜙 sin𝜃 sin𝜓 − sin𝜙 cos𝜓 cos𝜙 cos 𝜃

�

Oltre alle rotazioni bisogna considerare, in generale, le traslazioni presenti tra le origini di due sistemi di riferimento.

Dato un punto nello spazio, si indichino con 𝒖�1 =[𝑥1 𝑦1 𝑧1 1]𝑇 e con 𝒖�2 = [𝑥2 𝑦2 𝑧2 1]𝑇 i vettoriin forma omogenea rispetto a due sistemi di riferimento, [𝑋1 𝑌1 𝑍1] e[𝑋2 𝑌2 𝑍2].

Sia 𝒅�21ilvettore che individua l’origine della terna 2 rispetto alla terna 1.

Si ha che:

Appendice A

78

(A.1.19) 𝒖�1 = 𝑹�21 ∙ 𝒖�2 + 𝒅�21,

dove

(A.1.20) 𝑹�21 = �

𝑟11 𝑟12 𝑟13 0𝑟21 𝑟22 𝑟23 0𝑟31 𝑟32 𝑟33 00 0 0 1

�

e

(A.1.21) 𝒅�21 = �

𝑑𝑥𝑑𝑦𝑑𝑧1

�

Grazie alla rappresentazione omogenea si definisce la matrice di trasformazione omogenea:

(A.1.22) 𝑻21 = �𝑹21 𝒅21𝟎 𝟏

�

In questo modo è possibile compattare la relazione (A.1.19), che diventa:

(A.1.23) 𝒖�𝟏 = 𝑨𝟐𝟏 ∙ 𝒖�𝟐

Appendice A

79

Per ottenere la relazione inversa della (A.1.19) basta moltiplicare da sinistra per la matrice 𝑹�12, e sfruttando la (A.1.13), si ottiene:

(A.1.24) (𝑹�21)−1 ∙ 𝒖�1 = (𝑹�21)−1 ∙ 𝑹�21 ∙ 𝒖�2 + (𝑹�21)−1 ∙ 𝒅�21,

ricavando 𝒖�2 in funzione di 𝒖�1:

(A.1.25) 𝒖�2 = (𝑹�21)−1 ∙ 𝒖�1 − (𝑹�21)−1 ∙ 𝒅�21

= 𝑹�12 ∙ 𝒖�1 − 𝑹�12 ∙ 𝒅�21,

raggruppando nuovamente in 𝑻12:

(A.1.26) 𝒖�2 = 𝑨12 ∙ 𝒖�1 = �𝑹12 −𝑹12𝒅21𝟎 𝟏

� ∙ 𝒖�1.

In generale, la matrice omogenea di roto-traslazione 𝑨 non gode della proprietà di ortogonalità, perciò 𝑨−1 ≠ 𝑨𝑇.

La composizione di matrici di roto-traslazione in forma omogenea segue le stesse regole viste per le matrici di rotazione in forma non omogenea:

(A.1.27) 𝒖�0 = 𝑨10 ∙ 𝑨21 ∙… ∙ 𝑨𝑛𝑛−1 ∙ 𝒖�𝑛

Questa relazione esprime, in modo generale, la conversione tra due sistemi di riferimento, mediante roto-traslazioni rispetto alla terna corrente.

Appendice B

Appendice B : Calibrazione della telecamera con ARToolKit

Operazione necessaria per ogni applicazione di computer vision è quella della calibrazione della telecamera.

Questa operazione permette di poter risalire a quelli che sono i parametri intrinseci di una telecamera, vale a dire parametri che riguardano sia la geometria della telecamera, come la distanza focale e il centro dell’immagine, sia il modello di distorsione delle lenti. Molti dei software che si occupano di computer vision, hanno delle funzioni specifiche che riguardano le operazioni di calibrazione e l’ARToolKit non è da meno.

Infatti, per adempiere alle suddette operazioni, sono presenti nella cartella \bin, due programmi: calib_dist.exe e calib_cparam.exe, il cui utilizzo, opportunamente combinato, porta alla creazione di un file .dat in cui saranno immagazzinati tutti i parametri necessari.

Procedura di calibrazione

La procedura di calibrazione è suddivisa in due step.

Prima di cominciare, occorre stampare il contenuto dei file calib_cparm.pdfe calib_dist.pdf ed attaccarlo su di un supporto rigido.

Fatto ciò, bisogna mandare in esecuzione il programma calib_dist.exe. Con tale programma, dopo aver immesso le

Appendice B

81

informazioni relative alla dimensione dell’ immagine ed anteposto davanti alla webcam la stampa di calib_dist (immagine con puntini neri), bisogna evidenziare utilizzando il tasto sinistro del mouse i puntini, secondo il seguente ordine

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

In modo da decretarne il centro

Figura B1 operazione di evidenzia tura dei puntini

Una volta finita l’operazione, cliccare con il tasto destro e ripeterla per 5-10 volte, avendo cura di cambiare l’angolazione dell’immagine.

Alla fine di questo primo step, il programma calcolerà i valori di distorsione e il centro dell’immagine

Appendice B

82

Mostrando a video il risultato

Figura B2 risultato finale del primo step di calibrazione

Per il secondo step, invece, si fa uso del programma calib_cparam.exe in concomitanza con la stampa del file calib_cparma.pdf. Dopo aver mandato in run il programma ed aver inserito i dati di distorsione e centro dell’ immagine prima ottenuti, si acquisisce l’immagine relativa alla board, badando che essa sia disposta perpendicolarmente alla camera. Fatto questo bisogna, allineare alla griglia, andando dall’alto verso il basso e da sinistra verso destra, le righe che di volta in volta appariranno a video.

Appendice B

83

Figura B3 operazioni di allineamento delle linee

Questa operazione deve essere fatta 5 volte, muovendo la board di 100mm dopo ogni sessione

Figura B4 modalità di allontanamento della board

Appendice B

84

Alla fine, il software mostrerà quelli che sono i parametri intrinseci sotto forma di matrice di omografia e chiederà di indicare il nome del file .dat, che verrà utilizzato in seguito.

È tuttavia possibile semplificare tali operazioni, infatti, usando il programma calib_camera2.exe a posto di calib_dist.exe si potrà omettere il secondo step di calibrazione ed ottenere ugualmente il file .dat necessario.

Appendice C

Appendice C: Usare un target differente

Il sistema di riconoscimento dei pattern in ARToolKit, basa il suo funzionamento su di un file, caricato a run time dal software, che contiene tutto il necessario alla individuazione del target.

Pertanto, nel momento in cui si vuole cambiare il pattern “Hiro” di default, bisogna seguire una procedura ben precisa. Tale procedura, che permette di creare il file informativo attraverso un training del nuovo pattern, si articola nel seguente modo.

Per prima cosa, appoggiandosi al file blankPatt.gif creare e stampare il proprio pattern considerando che, esso dovrebbe essere asimmetrico e non molto dettagliato. Successivamente, lanciare il programma mk_patt.exe e dopo aver inserito il file .dat relativo ai parametri intrinseci, posizionare il pattern in modo da ottenere una disposizione dei bordi rossi e verdi, come quelli in figura C1.

Appendice C

86

Figura C1 disposizione dei bordi da seguire per il corretto training del target

Fatto ciò, premere il tasto destro del mouse ed inserire il nome del file che conterrà le informazioni relative al nuovo target.

Limitazioni:

Esistono comunque delle limitazioni in quelle che sono le dimensioni dei pattern e le distanze in cui essi possono essere riconosciuti.

Tali limitazioni sono riassunte dalla seguente tabella

Pattern Size (inches) UsableRange (inches) 2.75 16 3.50 25 4.25 34 7.37 50

Tabella C1 relazione tra le dimensioni dei pattern e la distanza di riconoscimento

Influiscono inoltre, la complessità del pattern e le condizioni di luminosità.

Bibliografia

Bibliografia

[1]http://www.robotic.diees.unict.it/

[2] G.Iannizzotto: Slide lezioni http://visilab.unime.it/~ianni/teaching.html

[3] A. Fusiello: “Visione Computazionale: appunti delle lezioni” http://profs.sci.univr.it/~fusiello/teaching/visione/appunti/

[4] http://www.lilik.it/~mirko/gapil/gapilpa2.html#gapilch17.html

[5]OReilly.Learning.OpenCV.Computer.Vision.with.the.OpenCV.Library.Oct.2008

[6] Linda G. Shapiro and George C. Stockman (2001): “Computer Vision”, pp 279-325, New Jersey, Prentice-Hall, ISBN 0-13-030796-3

[7] wikipedia Edge detection

[8] Shapiro, Linda G. & Stockman, George C. (2002). "Computer Vision". Prentice Hall. ISBN 0-13-030796-3

[9] Lezioni di robotica industriale Prof G. Muscato

[10] OpenCV Documentation: OpenCV\docs\index.htm [11]http://www.hitl.washington.edu/artoolkit/documentation/index.html

http://en.wikipedia.org/wiki/Special:BookSources/0130307963�

http://en.wikipedia.org/wiki/Special:BookSources/0130307963�

tesi

Documents

Transcript of tesi