FACOLTA DI INGEGNERIA` CORSO DI LAUREA IN …control.disp.uniroma2.it/.../Tesi/davidebossi/TesiDavideBossi.pdf · Capitolo 4 viene proposto il primo progetto, in riferimento alla

UNIVERSITA DEGLI STUDI DI ROMA

TOR VERGATA

FACOLTA DI INGEGNERIA

CORSO DI LAUREA IN INGEGNERIA

DELL’AUTOMAZIONE

Tesi di Laurea

SVILUPPO DI UN SISTEMA 3D TRACKING AD

INFRAROSSI E MODELLIZZAZIONE DELLA DINAMICA

DI VOLO DI UN QUADROTOR

RELATORE CANDIDATO

Ing. Daniele Carnevale Davide Bossi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CORRELATORE

Ing. Giulia Franchi

. . . . . . . . . . . . . . . . . . . . . . . .

A.A. 2010/2011

A chi resta

A chi se ne va’

Indice

Ringraziamenti 1

Introduzione 2

1 AR.DRONE Parrot 6

1.1 Presentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Descrizione meccanica ed elettronica . . . . . . . . . . . . . . . . . . 9

1.3 Applicazioni attuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Acquisizione dati 13

2.1 Stereovisione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 Wiimote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.2 Struttura del sistema . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.3 Acquisizione Calibrazione e Triangolazione . . . . . . . . . . . 21

2.2 Software Development Kit . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.1 Comando tramite Joystick . . . . . . . . . . . . . . . . . . . . 26

2.2.2 Strutture dati e salvataggio . . . . . . . . . . . . . . . . . . . 27

2.3 Prime analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Identificazione 30

3.1 Sistemi e modelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

INDICE I

INDICE

3.1.1 Principali funzioni . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Osservazioni ed Elaborazione dati . . . . . . . . . . . . . . . . . . . . 33

3.3 Identificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.1 Dinamica del Throttle . . . . . . . . . . . . . . . . . . . . . . 37

3.3.2 Dinamica dello Yaw . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3.3 Dinamica del Roll e del Pitch . . . . . . . . . . . . . . . . . . 41

4 Progetto di Controllore 45

4.1 Dinamica da controllare . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Processo e Controllore . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Conclusioni e sviluppi futuri 52

Elenco delle figure 54

Elenco delle tabelle 55

Elenco dei codici 56

Bibliografia 57

INDICE II

Ringraziamenti

Desidero innanzitutto ringraziare l’Ing. Daniele Carnevale per la sua disponibilita,

per il prezioso supporto sia didattico che morale, per la sua instancabile voglia di

fare per raggiungere i migliori risultati possibili e soprattutto per la sua simpatia e

semplicita.

Ringrazio inoltre la Endes Innovation S.r.l. e l’Ing. Giulia Franchi per avermi offerto

l’occasione di effettuare questo lavoro di tesi.

Tutti gli amici dell’Universita, in particolare “Nando” con il quale ho passato gli ul-

timi due anni a studiare e non e per il quale ormai sono il “MisterGoogle”.

Il mio coinquilino nerd ed i residenti del CampusX, Alan, Emiliano, Giuseppe e Lam-

berto.... che mi hanno ospitato quando avevo il frigorifero vuoto.

I fantastici riders e skiers con i quali ho passato delle bellissime giornate di neve.

Per ultimi ma piu importanti di tutti, ringrazio la mia famiglia per il sostegno e

per tutto l’aiuto che mi hanno dato fino ad oggi, mio fratello, il CA...rissimo ormai

lontano (solo di residenza) e Francesca, punto di riferimento che riesce ogni giorno a

sopportarmi.

Ringraziamenti 1

Introduzione

“Trovo, se questo strumento a vite sara ben fatto, cioe fatto di tela lina,stopata i suoi pori con amido, e svoltata con prestezza, che detta vite sifa la femmina nell’aria e montera in alto”

Leonardo Da Vinci, Manoscritto B, foglio 83 v., 1483-1486

Figura 1: Foglio d’appunti e schizzo dell’invenzione.

La prima idea di una macchina che potesse librarsi in volo e stata del celebre

Leonardo Da Vinci. Il grande inventore infatti aveva compreso come un congegno

potesse reperire la portanza necessaria per mantenersi in volo grazie ad una spirale,

chiamata vite aerea, che doveva essere tenuta in moto circolare continuo. Con tale

progetto Leonardo arrivava ad ipotizzare e formulare in anticipo di secoli l’efficacia

dell’elica[1].

Circa 400 anni dopo, E. Forlanini, Ingegnere aeronautico italiano, riuscı, tramite

un piccolo motore a vapore, a sollevare il primo elicottero a 13 metri di altezza.

Successivamente, con l’evoluzione della tecnologia e con l’impegno di vari studiosi dalle

Introduzione 2

Introduzione

notevoli capacita, i numerosi perfezionamenti apportati hanno fatto dell’elicottero un

aeromobile di grande versatilita.

“L’elicottero e una macchina volante originale e straordinaria. . . . I vo-latili, ad esempio, hanno suggerito all’uomo l’aeroplano. L’elica da cuie nato l’elicottero puo ritenersi, come la ruota, una pura creazione del-l’ingegno umano. E una macchina straordinaria per le sue prestazioni divolo: e capace infatti non soltanto di atterrare e decollare verticalmente,e di traslare con moto rettilineo, ma di librarsi, di galleggiare sur place inalta quota come a pochi palmi dal suolo; e capace di ruotare in aria, suse stesso, di oscillare con moto pendolare, di volare di lato e all’indietro.Nemmeno gli eroi e i semi-dei della mitologia erano in grado di compieretante prodezze.”

Igino Mencarelli, I Padri dell’ala rotante, Aeronautica Militare UfficioStorico 1969

Lo sviluppo tecnologico ha portato alla nascita di velivoli dalle notevoli capacita

in grado di gestire autonomamente il volo. Tale categoria, nota come UAV1 (Un-

manned Aerial Vehicle, veicoli che volano senza pilota), porta con se i vantaggi della

drastica riduzione dei costi operativi rispetto a velivoli convenzionali con pilota, della

possibilita di operare in ambienti inadatti alla presenza umana e di essere impiegati

tempestivamente per il rilevamento dall’alto, ad esempio, di calamita naturali. Inizial-

mente utilizzati esclusivamente in ambito militare, in missioni dull (di sorveglianza e

ricognizione monotone e di lunga durata), in missioni dirty (pericolose per l’incolu-

mita dei piloti) e in missioni dangerous (rischiose per la vita dei piloti) rappresentano

oggi il futuro dell’aereonautica moderna.

Esempio recente di utilizzo degli UAV e quello degli aeromobili americani Global

Hawk che hanno sorvolato la Centrale nucleare di Fukushima Dai-ichi, in Giappone,

addentrandosi nella zona vietata (“no go zone”), col fine di monitorare i reattori a

seguito delle esplosioni causate dal terremoto del Tohoku del 2011, fotografando la

zona con sensori a infrarossi.

1Talvolta viene usato impropriamente il termine “droni”, italianizzando la parola inglese droneche significa “ronzio” per via del rumore prodotto.

Introduzione 3

Introduzione

Le enormi potenzialita, i successi avuti nelle missioni militari ed i progressi fatti nel

campo delle micro e nano-tecnologie stanno spingendo sia le industrie sia le universita

a sviluppare numerosi sistemi UAS (Unmanned Aerial System) sempre piu moderni,

affidabili e in grado di essere utilizzati in un ampio spettro di missioni civili e militari.

In questo contesto, il presente lavoro di tesi concentra l’attenzione sull’uso della

tecnologia e dei metodi matematici per ottenere la “modellazione del sistema”, di

fondamentale importanza per sviluppare un controllo stabile ed efficiente del velivolo

garantendone cosı affidabilita e buone prestazioni. A tal fine si ricorre all’utilizzo di

due sistemi per l’acquisizione di differenti tipi di dati: un sistema di stereovisione

rapida, capace di determinare le coordinate spaziali e la posa di un oggetto, ed un

software sviluppato tramite l’SDK (Software Development Kit) in grado di scambiare

informazioni con l’aerogiro considerato. In ultima analisi viene proposto il progetto

di un controllore atto a migliorare e rendere piu affidabile la dinamica riferita al moto

di Yaw.

Per una lettura piu agevole viene riportata la struttura della tesi.

Capitolo 1 viene presentato l’AR.Drone, descrivendo la struttura dell’aerogiro e le

possibilita di utilizzo. Sono descritte inoltre alcune convenzioni aeronautiche

per sistemi multirotore, applicate poi nel presente progetto.

Capitolo 2 vengono definiti i metodi utilizzati per l’acquisizione dei dati. In par-

ticolare viene descritto lo sviluppo del sistema di tracking 3D ad infrarosso e

la scrittura, tramite il Software Development Kit, di un software in grado di

acquisire i comandi imposti dal joystick ed i dati di volo dell’aerogiro.

Capitolo 3 viene inizialmente descritta l’importanza generale del processo di identi-

ficazione e concentrando successivamente l’attenzione sulle funzioni e sui metodi

Introduzione 4

Introduzione

usati per l’esecuzione del processo di identificazione.

Capitolo 4 viene proposto il primo progetto, in riferimento alla sola dinamica di

Yaw, di un possibile controllore per migliorare le prestazioni di volo ed analizzati,

tramite un software di simulazione 3D, i risultati ottenuti del sistema controllato.

Introduzione 5

CAPITOLO 1

AR.DRONE Parrot

AR.Drone rappresenta la punta di diamante di una azienda leader nel settoredella tecnologia senza fili, la Parrot, che lavora da quindici anni nella ricercae sviluppo di nuovi dispositivi.

1.1 Presentazione

L’AR.DRONE e un quadricottero, ossia un aerogiro costituito da piu rotori, in grado

di essere pilotato con dispositivi Apple quali Iphone, IPod Touch o IPad.

Figura 1.1: AR.Drone Parrot.

Un aeromobile monorotore, l’elicottero, e costituito da un unico apparato (insieme

di rotore e pale), che ne consentono il volo. La caratteristica principale di una pala

6

Cap. 1 AR.DRONE Parrot §1.1 Presentazione

del rotore (a in Figura 1.2(a)) e quella di poter ruotare attorno al proprio asse longi-

tudinale b, variando in tal modo l’angolo di calettamento o angolo di passo (angolo α

tra la corda del profilo della pala e il piano ortogonale all’asse del rotore) allo scopo

di aumentare o diminuire l’incidenza della pala stessa. Ad ogni variazione dell’angolo

di passo corrisponde una variazione di portanza1: se la portanza aumenta, l’elicottero

sale di quota; l’inverso se diminuisce.

La trazione necessaria all’elicottero per spostarsi orizzontalmente viene ottenuta

inclinando il rotore nella direzione desiderata. In tal modo la forza aerodinamica

sostentatrice, che nel volo stazionario e diretta verticalmente (−→P in Figura 1.2(b),

che equilibra il peso−→Q dell’elicottero), si inclina nella stessa direzione dando origine

a una componente disposta nel piano orizzontale (−→T ; Figura 1.2(c)) che permette la

traslazione dell’elicottero equilibrando la resistenza aerodinamica−→R [2].

(a)

(b)

(c)

Figura 1.2: Sistema rotore-pale elicottero.

Un aerogiro caratterizzato da piu sistemi rotore-pala viene definito multirotore.

1Spesso abbreviata con la lettera L, dalla lingua inglese lift, e la componente perpendicolare almoto della forza aerodinamica che agisce su un corpo immerso in un fluido (come ad esempio unaeromobile in volo nell’aria).

7

Cap. 1 AR.DRONE Parrot §1.1 Presentazione

Ognuno di questi e caratterizzato da un proprio verso e da una propria velocita di

rotazione e le diverse combinazioni di moto relativo consentono determinati sposta-

menti. In particolare, rotori opposti ruotano nello stesso verso (una coppia in senso

orario e l’altra in senso antiorario); la definizione degli assi spaziali X, Y e Z e indicata

in Figura 1.1[3].

Figura 1.3: Modi di rotazione ed assi cartesiani di riferimento.

Le possibili relazioni fra le velocita di ogni rotore definiscono quattro movimenti

fondamentali, corrispondenti ai quattro “angoli di comando” (Figura 1.4) cosı che,

ad esempio, la rotazione alla stessa velocita di tutti i rotori comporti un movimento

ascensionale uniforme.

(a) Throttle. (b) Roll.

(c) Pitch. (d) Yaw.

Figura 1.4: Convenzione movimenti modello a 4 rotori.

La scelta della Parrot di utilizzare quattro rotori, anziche tre o un numero superio-

re, rappresenta un giusto compromesso tra peso e potenza ed e una buona soluzione

8

Cap. 1 AR.DRONE Parrot §1.2 Descrizione meccanica ed elettronica

per garantire facilita nel controllo e una forte stabilita.

1.2 Descrizione meccanica ed elettronica

Il Drone presenta una struttura a croce in fibra di carbonio e plastica PA66 ad alta

resistenza, 4 motori brushless ed un corpo centrale che racchiude la telecamera an-

teriore, la scheda di navigazione e la scheda madre e che costituisce il “cuore” ed il

“cervello” dell’aerogiro.

I motori hanno una potenza di 15 W ciascuno lavorano a 28.000 rpm in volo

stazionario, corrispondenti a 3.300 rpm dell’elica. Ognuno di questi e fissato al proprio

regolatore elettronico e la velocita, che puo variare da 10.350 rpm a 41.400 rpm, viene

controllata da un microcontroller a bassa potenza a 8 bit e da un ADC (Analog to

Digital Converter) a 10 bit.

Figura 1.5: Componenti del Drone.

Il corpo del drone e realizzato con un particolare tipo di polimero, denominato

PPE (Polifeniletere), molto leggero ed altamente resistente; al suo interno e incluso il

9

Cap. 1 AR.DRONE Parrot §1.2 Descrizione meccanica ed elettronica

vano batteria fissato alla struttura per mezzo di una schiuma in grado di assorbire le

vibrazioni dei motori.

L’alimentazione e fornita da una batteria LiPo ricaricabile 3 celle, nota come ac-

cumulatore litio-polimero o piu raramente litio-ione-polimero, che fornendo 11,1 V

e 1000 mAh, garantisce circa 12 minuti di volo. La batteria e posta verso il re-

tro dell’apparecchio in modo da mantenere il baricentro dell’AR.Drone nel centro

geometrico.

La telecamera anteriore grandangolare con una risoluzione di 640 x 480 pixel

(VGA, Video Graphics Array) e 15 fps, viene usata per lo streaming in diretta delle

immagini sul dispositivo di comando.

La scheda di navigazione e costituita da un sensore ad ultrasuoni con frequenza di

emissione di 40 kHz ed un raggio di azione di circa 6 metri, un accelerometro MEMS2

a 3 assi, un giroscopio MEMS a 2 assi ed un giroscopio piezoelettrico di precisione ad

1 asse.

La scheda madre presenta il processore basato su chip P6 che include una CPU

ARM926EJ Risc da 468 MHz, il chipset Wi-Fi Atheros per la creazione e la comuni-

cazione tramite rete ad-hoc ed una telecamera verticale 60 fps con risoluzione video

di 176 x 144 pixel che, combinata agli accelerometri, fornisce la velocita orizzontale

del dispositivo.

Nel corso di tale lavoro sono stati pero individuati alcuni “punti deboli”, sia dal

punto di vista strutturale, come ad esempio la posizione dei motori troppo esposti ad

urti, sia elettronico: la ridotta capacita della batteria ed il poco range di comando

limitano le potenzialita del dispositivo. Ulteriore problematica software, che ha co-

2Micro Electro-Mechanical Systems. Viene usato per indicare quello che la tecnologia delmicroscopico ha prodotto.

10

Cap. 1 AR.DRONE Parrot §1.3 Applicazioni attuali

stretto la ripetuta sostituzione del drone, e stata la difficolta di comunicazione con il

dispositivo causata dai limiti della scheda madre.

1.3 Applicazioni attuali

L’AR.Drone rappresenta un “ibrido” tra un elicottero da modellismo a 4 eliche (qua-

dricottero) ed un semplice giocattolo. L’interfaccia grafica del software di control-

lo, riportata in Figura 1.6, mostra all’utente le immagini riprese dalla videocamera,

due joystick per il pilotaggio (o in alternativa un joystick ed un pulsante per atti-

vare l’uso degli accelerometri del dispositivo di comando), l’informazione sulla carica

rimanente della batteria, un pulsante per l’atterraggio/decollo, un pulsante per l’in-

terruzione dei motori in caso di emergenza e due icone: una per l’accesso nel menu di

personalizzazione e una per l’aggiornamento/cambio di visuale della videocamera.

Figura 1.6: AR.Freeflight.

Grazie all’utilizzo della Realta Aumentata, cioe la sovrapposizione di livelli in-

formativi che permette di aggiungere dati multimediali alla realta, e possibile, ol-

11

Cap. 1 AR.DRONE Parrot §1.3 Applicazioni attuali

tre al semplice pilotaggio, eseguire dei “combattimenti” tra utenti (Figura 1.7(a)) o

gareggiare attraverso un percorso (Figura 1.7(b)).

(a) AR.Pursuit (b) AR.Race

Figura 1.7: Applicazioni disponibili.

Gli utilizzi attuali quindi, vista la natura ed il prezzo del dispositivo, consistono

nel semplice svago ed intrattenimento con la possibilita pero, grazie alla distribuzione

gratuita da parte della Parrot del pacchetto di sviluppo (SDK), di sviluppare nuove

applicazioni da parte dell’utente.

In questo contesto, al fine di creare un modello di base che possa rappresentare

il punto di partenza per lo sviluppo di sistemi UAV piu complessi e utili a scopi

civili e militari, il presente lavoro propone metodi di acquisizione dati, i cui risultati

sono poi utilizzati in uno studio di modellizzazione attraverso il software MATLAB.

Il progetto e stato portato avanti lavorando sul quadricottero fornito dalla “Endes

Innovation SRL”, Azienda che ha lo scopo di promuovere e diffondere tecnologie ed

applicazioni innovative attraverso i suoi servizi integrati su sistemi complessi.

12

CAPITOLO 2

Acquisizione dati

In un progetto sperimentale, l’importanza dell’acquisizione dati e la loro ve-ridicita e fondamentale per lo svolgimento del lavoro. Mediante la visionestereoscopica, che permette di fondere insieme l’informazione proveniente dadue “telecamere” per ricostruire le coordinate spaziali del target e attraversol’utilizzo del Software Development Kit, per lo sviluppo di applicazioni in gradodi interfacciare l’utente con un dispositivo, e possibile ottenere un set di datiutilizzabili nella successiva modellizzazione del sistema.

Il sistema analizzato, rappresentato in Figura 2.1, e studiato come un modello con in

ingresso il dispositivo di comando, la black-box rappresentata dal drone e in uscita il

movimento nello spazio.

Figura 2.1: Schema Iphone - AR.Drone.

13

Cap. 2 Acquisizione dati §2.1 Stereovisione

Per l’identificazione del sistema e stata modificata la struttura in modo da avere

a disposizione da un lato, i dati relativi ai comandi inviati al dispositivo e dall’altro i

valori di uscita. Riguardo quest’ultimi, si identificano due rami (Figura 2.2) principali

corrispondenti ai due metodi di acquisizione delle caratteristiche del velivolo durante

il volo: ramo 1 - calcolo delle coordinate spaziali di 4 punti posti solidalmente al drone

tramite stereovisione; ramo 2 - acquisizione di alcuni dati di volo tramite l’uso del Software Develop-

ment Kit.

Figura 2.2: Schema collegamento PC-AR.Drone.

2.1 Stereovisione

La stereopsi (da stereo che significa solido e opsis che significa sguardo) e la capacita

naturale di molti animali di percepire la distanza e la struttura tridimensionale di un

oggetto a partire dalla disparita di posizione che quest’ultimo ha nelle due immagini

acquisite dai due occhi. E proprio grazie a questa capacita che l’occhio umano e in

14


grado di avere una visione tridimensionale del mondo esterno. Nonostante il principio

di funzionamento della stereopsi sia conosciuto da tempo, solo negli ultimi quindici

anni si e potuto iniziare a sfruttare la visione stereoscopica anche nella tecnologia a

causa della grandissima quantita di calcoli real-time necessari.

La caratterizzazione di un sistema di visione stereoscopica, come per il caso della

vista umana, viene effettuata in funzione di differenti elementi. In riferimento alla

Figura 2.3, osservando la similitudine esistente dei triangoliOsFOd, e FsFFd e tenendo

Figura 2.3: Parametri caratteristici di un sistema di visione stereoscopica.

conto che la lunghezza dei segmenti deve essere sempre positiva, si ottiene:

xs − xd

zs − zobs=

b/2− (−b/2)

zobs(2.1.1)

15


che, risolta evidenziando la distanza zobs tra punto ed osservatore, da la seguente

espressione:

zobs = zsb

b+ xs + xd

(2.1.2)

avendo indicato con: zobs la distanza tra osservatore e punto di fissazione percepito F, coincidente con

la coordinata Z del punto stesso; zs la distanza tra osservatore e le immagini posizionate sul piano S; xs e xd le ascisse dei punti proiettati Fs,d; b la distanza tra i centri di rotazione degli assi ottici che non differisce sostan-

zialmente dalla distanza interpupillare.

La distanza percepita zobs del punto apparente dall’osservatore e proporzionale alla

distanza zs tra osservatore e immagini ed e quindi circa inversamente proporzionale

alla distanza tra i punti proiettati xs e xd e dipende in modo piu complesso dalla

distanza interpupillare b.

Nel presente lavoro, come in generale per tutti i processi che utilizzano la stereo-

visione, risulta possibile ricostruire le coordinate tridimensionali del target rispetto a

un sistema di riferimento definito, attraverso l’acquisizione delle informazioni di due

“telecamere” e la loro fusione. Tale operazione non e stata effettuata tramite l’uso di

videocamere e image processing, ma utilizzando un sistema piu veloce e abbastanza

preciso che ricorre all’uso di LED ad infrarossi individuabili con dispositivi di uso

comune come il Wiimote.

16


2.1.1 Wiimote

Il Wii Remote Controller, abbreviato in Wiimote, e il dispositivo di input della con-

sole Nintendo Wii usato come interfaccia principale per l’interazione tra l’uomo e il

sistema, grazie alla capacita di rilevare punti e movimenti attraverso sensori ottici e

accelerometrici.

I Wiimotes comunicano con la console Wii via Bluetooth attraverso l’interfaccia

HID (Human Interface Device); i dati inviati non sono criptati ed e quindi possi-

bile sfruttare appieno le funzionalita su ogni computer che disponga dell’interfaccia

bluetooth, tramite la semplice installazione di alcune librerie (LibCwiid in Linux).

(a) (b)

Figura 2.4: Wii Controller e particolare della camera IR.

Nel controller il sensore camera IR, prodotto dalla PixArt Imaging (Figura 2.4(b)),

contiene un chip con un motore integrato per il multiobject tracking (MOT), che

offre alta risoluzione e alta velocita di monitoraggio di sorgenti luminose IR (fino ad

massimo di 4 contemporaneamente).

Le specifiche del sensore, non ufficialmente pubblicate, sembrano fornire dati di

posizionamento con una risoluzione di 128 x 96 pixel che, sfruttando l’analisi subpixel

8x, raggiungono una risoluzione di 1024 x 768 pixel virtuali. Un refresh rate di 100

17


Hz offre un’altissima velocita di risposta mentre il campo di vista orizzontale di circa

41 e quello verticale di circa 31 forniscono un discreto spazio operativo.

Queste caratteristiche superano le normali webcam, che generalmente fornisco-

no una risoluzione di 640 x 480 pixel con un refresh rate di 30 Hz, ma non le piu

specializzate fotocamera IR, che pero hanno un prezzo significativamente piu alto[4].

Le prime prove effettuate per stabilire l’accuratezza della camera IR del Wiimote,

hanno evidenziato come la precisione di tale sensore abbia una forte correlazione con

la distanza e di come la luce solare, diretta o riflessa, influenzi fortemente la rilevazione

di un LED IR.

2.1.2 Struttura del sistema

La necessita di realizzare un sistema di acquisizione stereoscopico dal costo contenuto

e dalle buone prestazioni, sia in accuratezza che in velocita di risposta, ha portato

allo sviluppo di un metodo composto da due Controller della Wii e da un pattern con

4 LED ad infrarosso (IR).

La scelta nel posizionamento delle due camere (Wiimotes) e stata condizionata dal

problema della limitata diffusione luminosa dei LED utilizzati. Questi infatti, essendo

quasi direzionali (l’angolo di emissione della luce molto basso), non permettono la loro

rilevazione nel caso di inclinazione eccessiva rispetto all’asse passante per i centri delle

camere (Figura 2.5).

Effettuando numerose prove per determinare la piu corretta configurazione del si-

stema, e stato deciso di posizionare il primo controller perpendicolarmente al suolo e

il secondo controller inclinato di qualche grado in direzione del primo (Figura 2.6(d)).

Utilizzando una struttura a braccio, disponibile nel Laboratorio di Robotica Pesante

dell’Universita di Tor Vergata, e cercando di ottenere un maggiore spazio di lavoro pos-

18


(a) (b)

Figura 2.5: Inclinazione del LED rilevabile (a) e non (b) da parte del controller.

(a) (b)

(c) (d)

Figura 2.6: Possibili posizionamenti delle camera e area di lavoro disponibile.

sibile senza allontanarsi troppo dalle condizioni ottimali di operativita dei controller,

questi sono stati posizionati ad un’altezza di circa 3 metri rispetto al suolo.

19


Il pattern utilizzato inizialmente, costituito dal parallelo di 4 LED IR alimentati

da una batteria da 1,2 V (tensione reale di 1,3 V), presentava un grande problema

nella rilevazione dei LED a causa, come gia detto, del limitato angolo di diffusione

della luce.

Per ovviare a tale problematica e stata modificata la struttura del pattern ag-

giungendo una batteria ed un resistore (Figura 2.7(a)) cosi da fornire, mantenendo la

quantita di corrente su ogni LED pari a 20 mA, al parallelo dei LED una tensione di

alimentazione maggiore e pari a:

tensioneLED = tensionebatterie − resistenza · corrente4LED =

= 2, 6V − R · 0, 080A = 2, 6− 10Ω · 0, 080A = 1, 8V(2.1.3)

Ulteriore modifica apportata ad ogni LED e stato aggiungere una componente che

permettesse di aumentare il cono di diffusione della luce. Questa semplice struttura

(Figura 2.7(b)) ha portato un guadagno di qualche grado nella massima inclinazione

possibile dei LED rispetto alle camere, permettendo quindi di aumentare la robustezza

del sistema di acquisizione.

(a) Schema elettrico. (b) Led.

Figura 2.7: Particolari del pattern.

La struttura cosi ottenuta, della quale e mostrata in Figura 2.8 il modello 3D,

presenta i LED posti agli estremi di una croce con una distanza fra diodi adiacenti

pari a 18 cm.

20


Figura 2.8: Soluzione finale del pattern.

2.1.3 Acquisizione Calibrazione e Triangolazione

Per concludere lo sviluppo di un sistema 3D tracking ad infrarosso e stata utilizzata la

libreria Wiiuse e il pacchetto WmGui, disponibile per Ubuntu, che permette il colle-

gamento e la lettura dei dati dei controller Wii restituendo direttamente le coordinate

2D dei punti visibili con ciascuna camera. Questi valori sono stati salvati, grazie ad

una procedura scritta in linguaggio C, per poi essere utilizzati nella triangolazione.

void* s t ampa f i l e ( void* msg)

FILE * coord inate = fopen ( "../ toolbox /coordinate .txt " , "a+" ) ;t imeval s tar t , i n te rmed iate , end ;gett imeofday (&star t , &end , &intermed iate ) ;whi l e (1)

coord * coord 1 = ( ( par t *) msg )−>point1 ;coord * coord 2 = ( ( par t *) msg )−>point2 ;gett imeofday (&intermed iate , NULL) ;us l eep (20000 − ( i ntermed iate . t v u s e c − end . tv u s e c ) ;gett imeofday (&star t , NULL) ;f p r i n t f ( coordinate , "%ld .%03ld -[%d %d %d %d %d %d %d %d %d %d %d %d %d %d

%d %d]\n" , ( s t a r t . t v s e c ) , ( s t a r t . t v u s e c ) /1000 , (* coord 1 ) . x , (*coord 1 ) . y , (* coord 2 ) . x , (* coord 2 ) . y , (* ( coord 1 + 1) ) . x , (* (coord 1 + 1) ) . y , (* ( coord 2 + 1) ) . x , (* ( coord 2 + 1) ) . y , (* ( coord 1+ 2) ) . x , (* ( coord 1 + 2) ) . y , (* ( coord 2 + 2) ) . x , (* ( coord 2 + 2) ) .

y , (* ( coord 1 + 3) ) . x , (* ( coord 1 + 3) ) . y , (* ( coord 2 + 3) ) . x , (* (coord 2 + 3) ) . y ) ;

gett imeofday (&end , NULL) ;

Codice 2.1: Procedura di salvataggio coordinate.

21


Prima di procedere con la registrazione delle coordinate si prepara l’allineamento:

si assegnano delle etichette (colori) ad ogni LED IR del pattern, cosı da garantire un

riscontro visivo chiaro sull’interfaccia grafica come visibile in Figura 2.9.

Come visibile nel Codice 2.1 l’output di questo passaggio e un file, coordinate.txt,

che, con un tempo di campionamento di 20 ms, riporta le coordinate dei LED per

entrambi i controller.

1310392915.018 −[165 422 190 389 200 309 229 277 314 342 343 317 278 455 306 426 ]1310392915.038 −[166 421 190 389 200 309 229 277 315 341 343 317 279 455 305 426 ]1310392915.058 −[168 420 189 388 200 309 229 277 315 341 343 317 280 455 304 425 ]1310392915.078 −[168 420 188 388 200 308 228 277 315 341 343 317 280 454 303 425 ]1310392915.098 −[168 420 188 387 200 307 227 276 315 341 342 315 281 453 303 424 ]1310392915.118 −[169 420 187 387 200 306 227 276 316 340 339 314 280 452 302 424 ]1310392915.138 −[169 420 186 387 200 306 227 276 316 340 339 315 280 452 301 424 ]1310392915.158 −[169 419 186 387 201 306 226 275 315 340 338 315 280 452 300 423 ]1310392915.178 −[169 418 184 385 202 306 224 274 315 340 337 315 281 451 299 423 ]1310392915.198 −[169 417 183 385 202 306 223 273 315 340 335 314 280 450 298 422 ]1310392915.218 −[169 417 182 385 202 306 222 274 315 340 334 314 280 450 296 421 ]1310392915.238 −[169 417 181 385 202 306 222 274 315 340 333 315 280 450 296 421 ]

Codice 2.2: Esempio file di uscita del sistema di acquisizione.

Nel Codice 2.2 e possibile osservare il metodo di salvataggio e la disposizione delle

variabili: il primo numero rappresenta il tempo assoluto1 (utilizzato per comodita di

elaborazione); le 16 variabili successive (8 per ogni Wiimote) rappresentano invece le coordinate

di ogni LED prima viste dal controller di sinistra (x1left y1left) e poi da quello

di destra (x1right y1right).

Successivamente, il processo di calibrazione, utile per la determinazione di parame-

tri caratterizzanti le camere e necessario per la triangolazione, e stato effettuato utiliz-

zando il Camera Calibration Toolbox di MATLAB. L’utilizzo del software con sistemi

1La funzione gettimeofday() in C restituisce il tempo in secondi dal 1 Gennaio 1970.

22


stereoscopici costituiti da webcam risulta molto preciso ma alquanto lento, infatti, la

procedura per la singola calibrazione di una webcam e la successiva stereo-calibrazione

richiedono la ripetizione di molti step, da svolgere manualmente.

Il processo di calibrazione per il sistema sviluppato invece, e descrivibile tramite i

seguenti passi:

1. si collegano i due Wiimote (sinistro e destro) definendo i file di uscita (per

comodita nominati remoteleft.m e remoteright.m);

2. si effettua per ogni controller l’operazione di align che identifica i punti omologhi

tra le due camere;

(a) Corretta. (b) Errata.

Figura 2.9: Interfaccia grafica e visualizzazione punti.

3. muovendo il pattern da una posizione ad un’altra non complanare ed effettuando

la registrazione si salvano le coordinate dei 4 punti in entrambi i file;

4. completate le registrazioni (20-30 misure) si avviano in MATLAB i due file .m

ottenuti (di cui si riporta un esempio nel Codice 2.3) cosı da permettere il calcolo

automatico dei dati caratteristici delle due camere;

5. richiamando la funzione stereo gui() e caricando i due file .mat ottenuti dallo

step precedente, si ottiene la matrice caratterizzante l’intero sistema.

23


c l e a r ;nx = 1024;ny = 768 ;

Np = 4 ;e s t a l pha = 0 ;

X 1 = [ 0 180 180 0 ; 0 0 180 180;0 0 0 0 ] ;x 1 = [204 346 276 134;288 356 503 4 3 4 ] ;X 2 = [ 0 180 180 0 ; 0 0 180 180;0 0 0 0 ] ;x 2 = [220 353 281 151;279 360 492 4 1 3 ] ;X 3 = [ 0 180 180 0 ; 0 0 180 180;0 0 0 0 ] ;. . .X 44 = [ 0 180 180 0 ; 0 0 180 180;0 0 0 0 ] ;x 44 = [246 398 384 224;230 207 382 4 0 0 ] ;

n ima = 44

% Avvia l a procedura d i c a l i b r a z i o n e p r i n c i p a l ego ca l i b op t im ;

% Mostra i parametr i e s t r i n s e c h ie x t c a l i b ;

% Salva i l r i s u l t a t o in un f i l e nominato Ca l i b Resu l t s . mat :s a v i n g c a l i b ;

Codice 2.3: Esempio file remoteleft.m.

Il risultato della corretta stereo-calibrazione effettuata e mostrato in Figura 2.10 dove

e possibile controllare la distanza tra i due Wiimote e la posizione spaziale degli stessi.

Figura 2.10: Risultato della stereo calibrazione.

24

Cap. 2 Acquisizione dati §2.2 Software Development Kit

Il sistema quindi, vista la capacita di acquisire correttamente le coordinate 2D

e grazie alla disponibilita della matrice caratterizzante il sistema di stereovisione,

permette di ottenere le coordinate 3D dei punti semplicemente richiamando la funzione

stereo triangulation.m, inclusa nel toolbox di MATLAB, definita come:

f unc t i on [XL,XR] = s t e r e o t r i a n g u l a t i o n (xL , xR, om, T,

f c l e f t , c c l e f t , k c l e f t , a l p h a c l e f t ,f c r i g h t , c c r i gh t , k c r i gh t , a l p h a c r i g h t )

Codice 2.4: Definizione della funzione stereo triangulation.

Come visibile nel Codice 2.4 i risultati della funzione di triangolazione sono le coor-

dinate spaziali assolute riferite alle due camere. La scelta di utilizzare il riferimento

rispetto al controller di sinistra, e dovuto alla piu comoda posizione del controller

stesso essendo questo perpendicolare al pavimento.

2.2 Software Development Kit

In tale lavoro e stato necessario l’uso del Software Development Kit, o SDK, rilasciato

ufficialmente dalla casa produttrice dell’AR.Drone per riuscire a determinare varie

caratteristiche sia di ingresso che di uscita, utili ai fini dell’identificazione dell’oggetto.

Il pacchetto scaricabile dalla rete contiene al suo interno sia librerie per l’acquisizione

e la traduzione dei comandi, sia alcuni esempi, per varie piattaforme, di software di

comando.

La scelta di Linux come ambiente di sviluppo, ha permesso la programmazione di

un software che permettesse di soddisfare due requisiti fondamentali: pilotare il “Drone” tramite un joystick collegato al pc; analizzare e salvare dati di volo restituiti direttamente dall’AR.Drone.

25


2.2.1 Comando tramite Joystick

Successivamente al collegamento dell’AR.Drone con il software, e stata concentrata

l’attenzione sulle caratteristiche di comando tramite joystick (USB Thrustmaster,

Cloche a 4 assi e 12 pulsanti).

Figura 2.11: Schema collegamento PC - AR.Drone.

Il sistema operativo interpreta i movimenti assiali del joystick come un numero

intero compreso in un dato intervallo che viene, per comodita, rappportato come

riportato nell’Equazione 2.2.1.

−32767 ≤ x ≤ 32767 ⇐⇒ −1 ≤ x ≤ 1 (2.2.1)

E stata poi eseguita una mappatura (Tabella 2.1) che sfruttando 4 assi e 3 pulsanti

permette un pieno controllo del dispositivo.

Tabella 2.1: Mappatura Joystick.

ASSE/PULSANTE MOVIMENTO

asse 1 rollasse 2 pitchasse 3 yawasse 4 throttle

pulsante 1 decollo/atterraggiopulsante 2 emergenza blocco motori

26


Alcuni movimenti dell’AR.Drone (per esempio il decollo o l’atterraggio) non cor-

rispondono ad una variazione degli “angoli” di comando (ad esempio variazione del

Throttle) ma a moti prestabiliti che portano la variazione di una struttura dati, pre-

sente nel SDK, nominata “Control State” (verra trattata piu specificatamente nel

Capitolo 2.2.2).

2.2.2 Strutture dati e salvataggio

Delle varie strutture dati disponibili, presenti nell’SDK, si e deciso di utilizzare quelle

piu caratteristiche, che fossero cioe piu descrittive dello stato del sistema. La scelta

quindi, sia per gli ingressi (comandi del joystick) sia per le uscite (strutture dati

presenti nell’SDK), ha portato alla scrittura di software multithread che, rispettando

il tempo di campionamento scelto pari a 20 ms, salvasse in un file di uscita .txt i

comandi imposti dal movimento del joystick ed i dati utili.

1310134049.546 CS=196608 29 83 cm Gy=[+3.97 +3.82 −1.81] Ac=[−0.01 +0.00 −0.97] PWM=[159 188

152 214] Rol l =0.0 Pi tch=0.0 Yaw=0.0 Throt t l e=0.01310134049.566 CS=196608 29 83 cm Gy=[+9.01 +4.22 −0.35] Ac=[−0.00 +0.02 −0.96] PWM=[157 187

155 209] Rol l =−0.206 Pitch=0.0 Yaw=0.0 Throt t l e=0.01310134049.586 CS=196608 29 83 cm Gy=[+7.42 +9.46 +0.92] Ac=[−0.00 +0.03 −0.98] PWM=[144 200

176 194] Rol l =−0.206 Pitch=0.0 Yaw=0.0 Throt t l e=0.01310134049.606 CS=196608 29 83 cm Gy=[+7.42 +9.46 +0.92] Ac=[−0.00 +0.03 −0.95] PWM=[144 200

176 194] Rol l =−0.227 Pitch=0.0 Yaw=0.0 Throt t l e=0.01310134049.626 CS=196608 29 83 cm Gy=[−33.92 +5.22 +0.78] Ac=[−0.01 +0.08 −0.97] PWM=[155 190

165 204] Rol l =−0.227 Pitch=0.0 Yaw=0.0 Throt t l e=0.01310134049.646 CS=196608 29 83 cm Gy=[−33.92 +5.22 +0.78] Ac=[−0.01 +0.08 −0.98] PWM=[155 190

165 204] Rol l =0.0 Pi tch=0.0 Yaw=0.0 Throt t l e=0.01310134049.666 CS=196608 29 84 cm Gy=[−0.93 −5.59 +0.68] Ac=[−0.01 −0.02 −0.96] PWM=[168 176

148 209] Rol l =0.0 Pi tch=0.0 Yaw=0.0 Throt t l e=0.01310134049.686 CS=196608 29 83 cm Gy=[−0.66 +1.27 −1.96] Ac=[−0.01 −0.01 −0.95] PWM=[163 180

145 217] Rol l =0.0 Pi tch=0.0 Yaw=0.0 Throt t l e=0.0

Codice 2.5: Esempio file di uscita dei dati di volo.txt

Nel file in uscita dal processo, di cui e mostrato in Codice 2.5 un esempio, e

possibile vedere la struttura dei dati utili ai fini dell’identificazione del modello: il tempo indicato per comodita in maniera assoluta (come gia indicato nel

Capitolo 2.1.3);

27

Cap. 2 Acquisizione dati §2.3 Prime analisi un numero “Control State” rappresentante lo stato del Drone (Hovering, Lan-

ding, Emergency...); la carica rimanente della batteria; l’altezza misurata dal sensore ad ultrasuoni2; i valori del giroscopio biassiale e del giroscopio a 1 asse; i valori dell’accelerometro triassiale; i segnali PWM dei quattro motori; il valore dei comandi imposti (Roll, Pitch, Yaw e Throttle).

2.3 Prime analisi

Terminata la procedura di preparazione all’acquisizione dei dati, sono state condotte

alcune prove per la verifica di correttezza e di determinazione delle prestazioni del-

l’intero sistema (stereovisione + sensoristica AR.Drone). Dalle prime stime si sono

osservate alcune importanti caratteristiche: la scelta del tempo di campionamento corretta (abbassando di troppo il tempo

di campionamento si otterrebbe una piu ampia quantita di dati, ma ripetuti); una buona risposta del sistema a piccole variazioni; i dati acquisiti, sottoposti ad errori in quanto sistemi reali, necessitano di una

operazione di pre-filtraggio prima di essere utilizzati.

2Il range di funzionamento del sensore e compreso tra 21 cm e 6 m.

28

Cap. 2 Acquisizione dati §2.3 Prime analisi

Riguardo il sistema di stereovisione ad infrarosso si e riscontrato qualche problema

nel calcolo delle coordinate Z tramite la triangolazione. Infatti, impostando un inter-

vallo possibile di lavoro, compreso tra 0 cm (pavimento) e 180 cm (altezza massima

dove i LED sono osservabili da entrambi i controller) si e notato come le altezze Z

ricavate presentino una precisione variabile e dipendente dall’altezza. In particolare si

ottiene maggiore precisione lavorando nel range in cui sono state effettuate il maggior

numero di prove in fase di calibrazione e per questo quindi lo svolgimento dei test

viene eseguito cercando di limitare l’altezza nell’intervallo migliore.

29

CAPITOLO 3

Identificazione

Nell’ambito dei controlli automatici, il processo di identificazione consiste nelricavare i parametri che definiscono un modello matematico del sistema dina-mico in esame. I dati sono solitamente ottenuti tramite un campionamento delsegnale (o segnali) di ingresso ed uscita dell’impianto e l’elaborazione avvienetramite determinati algoritmi numerici.

3.1 Sistemi e modelli

Un sistema e un oggetto in cui le variabili di diverso tipo interagiscono fra loro e

producono dei segnali osservabili, da cui parte il processo di identificazione. Il sistema

inoltre e influenzato da alcuni stimoli esterni: quelli che possono essere manipolati, ovvero gli ingressi; quelli fuori controllo dello sperimentatore (comunemente etichettato come “ru-

more”), che possono essere misurati o individuati solo valutando l’influenza che

hanno sul sistema.

30

Cap. 3 Identificazione §3.1 Sistemi e modelli

Conoscere la funzione di trasferimento di un sistema da controllare risulta importante

ed alquanto complesso. I metodi di identificazione, ossia le procedure che determinano

i parametri caratterizzanti il comportamento del sistema stesso, risultano di grande

interesse per la risoluzione di tale obiettivo.

Un problema di identificazione inizia dopo aver progettato un set significativo di

prove sperimentali ed aver raccolto una serie di dati dal sistema in esame. L’importan-

za del processo risulta elevata nei piu diversi ambiti, infatti, conoscendo le dinamiche

di un fenomeno indipendentemente dalle sue caratteristiche fisiche, si ha la possibilita

di: comprendere meglio la qualita del processo, effettuando il confronto delle pre-

dizioni con la realta e quindi valutando in quali aspetti il modello sia sbagliato

o incompleto e come sia possibile migliorarlo; progettare esperimenti validi, cioe realmente influenti; predire in differenti situazioni le dinamiche del sistema sottoposto a varie solle-

citazioni; ottimizzare un processo effettuando un numero ridotto di esperimenti riducendo

quindi il tempo necessario ed il costo.

Al fine di scegliere il modello piu adatto, cioe che meglio approssimi l’andamen-

to del fenomeno osservato, si puo definire un “algoritmo” che regola il processo di

identificazione nelle sue diverse fasi, schematizzabile come in Figura 3.1.

Per lo svolgimento di tale lavoro e risultato di fondamentale importanza la di-

sponibilita e la capacita di utilizzo del software MATLAB, ambiente per il calcolo

numerico e l’analisi statistica. Per il processo di identificazione infatti, il software

31

Cap. 3 Identificazione §3.1 Sistemi e modelli

Figura 3.1: Algoritmo generico di identificazione[8].

prodotto dalla MathWorks mette a disposizione un toolbox, il System Identification

Toolbox, in grado di stimare modelli matematici di sistemi dinamici partendo da mi-

sure di ingresso e di uscita, validando tramite un sottoinsieme di dati non utilizzato

nel processo di identificazione, il modello ottenuto.

3.1.1 Principali funzioni

Durante i primi tentativi di identificazione, usando il toolbox grafico offerto da MA-

TLAB, si e notato come i modelli ricavati raggiungessero fitting elevati. La successiva

verifica pero non ha confermato la bonta di tali modelli.

Per questo motivo si e deciso di ricorrere alle stesse funzioni utilizzate dal System

Identification Toolbox ma richiamandole all’interno di un file MATLAB, potendo cosı

specificare in maniera adeguata i diversi parametri richiesti.

32

Cap. 3 Identificazione §3.2 Osservazioni ed Elaborazione dati

Le due principali funzioni utilizzate sono: pem (Prediction Error Method) metodo di stima parametrica di un modello che

suppone nota la struttura e cerca di identificare i parametri partendo da dati

sperimentali (misurati) sulle uscite ottenute a partire dagli ingressi scelti per

eccitare il sistema. Il PEM stima i parametri cercati minimizzando gli errori

di predizione, ovvero minimizzando un funzionale di costo dipendente da questi

errori che a loro volta sono funzione dei parametri incogniti e delle misure; n4sid metodo di stima dei modelli nella forma di spazio di stato restituendo un

oggetto IDSS, ossia nella struttura di spazio di stato comprendente l’ingresso di

errore.

3.2 Osservazioni ed Elaborazione dati

Per il raggiungimento di un modello affidabile e accurato, e stata necessaria una

prima elaborazione dei dati, cercando di filtrare rumori e disturbi presenti nei segnali

acquisiti. In Figura 3.2 e riportato un esempio in cui, sul segnale acquisito (l’altezza

del baricentro misurata tramite la stereovisione) e riportato in rosso, viene applicato

un filtro

FILTRO =1

as+ 1(3.2.1)

ed effettuata una interpolazione per renderlo pulito e valido (segnale in blu). Il proble-

ma della momentanea assenza di uno (o piu) LED da una delle due camere comporta

un calcolo errato della triangolazione e quindi alla determinazione di coordinate spa-

ziali non corrette. La presenza di picchi rispetto all’andamento “normale” del segnale

misurato evidenzia proprio l’occorrenza di tale fenomeno che viene risolto tramite le

operazioni di filtraggio e interpolazione.

33


0 5 10 15 20 25 300

50

100

150

200

250

300

TIME

Z−

FIN

AL

Z−FINAL − TIME

Segnale Filtrato

Segnale Acquisito

Figura 3.2: Operazione di filtraggio e pulizia dell’altezza del baricentro IR.

Ogni test svolto, che comprende due file principali (ottenuti tramite il processo di

stereovisione e il software sviluppato tramite l’SDK, Capitolo 2), e stato analizzato per

osservare la bonta dei dati e la loro distribuzione. Da tale analisi infatti, come si vede

dal plot dei valori acquisiti in due differenti prove (Figura 3.3 e Figura 3.4), e possibile

determinare i comandi imposti ed il comportamento dell’AR.Drone. Successivamente

si decide se tale prova puo risultare utile ai fini della determinazione di una dinamica

del sistema.

34


Figura

3.3:

Esempio

digrafi

ciottenutidaunaprimaprova.

35


Figura

3.4:

Esempio

digrafi

ciottenutidaunasecondaprova.

36

Cap. 3 Identificazione §3.3 Identificazione

3.3 Identificazione

La grande quantita di dati disponibili e alcuni problemi riguardanti l’acquisizione delle

coordinate dei LED tramite stereovisione, causati dallo spazio di lavoro troppo ridotto

per un oggetto a 6 gradi di liberta, ha reso necessario effettuare delle stime del modello

in prove di lunghezza ridotta. Inoltre, per comodita, il processo di identificazione e

stato frammentato in quattro differenti dinamiche caratterizzanti i moti del drone: Throttle; Yaw; Roll; Pitch.

La caratterizzazione e stata eseguita cercando di impostare, per ogni singola prova,

il solo comando di interesse. Per i moti di Throttle e Yaw non sono stati incontrati

importanti problemi e la modellizzazione ottenuta e risultata alquanto accurata. Al

contrario, per i moti di Roll e Pitch, si e deciso di effettuare un unico test a causa

delle difficolta incontrate nell’effettuare prove valide cercando di mantenere il drone

nel cono di visibilita dei controllers Wii.

3.3.1 Dinamica del Throttle

La prima analisi eseguita riguarda la dinamica del Throttle. La relazione tra elevatore

(ingresso) e altezza dell’AR.Drone (uscita), calcolata come la media delle altezze dei

quattro LED, e osservabile in Figura 3.5.

Le difficolta incontrate nell’ottenere prove valide sono state causate principalmente

dal comportamento non ideale dell’AR.Drone che, ad un comando imposto, non ri-

37


sponde solamente effettuando il moto stabilito. Questo infatti, nel caso in esame, non

eseguendo il solo movimento di salita/discesa ideale porta ad un’uscita dallo spazio

di lavoro con conseguente annullamento della prova.

0 2 4 6 8 10 12 14 16 18 20−80

−60

−40

−20

0

20

40

60

80

IngressoUscita

Figura 3.5: Relazione tra throttle e altezza misurata.

Il modello tempo discreto ottenuto utilizzando la funzione pem, riportato in forma

di IDPOLY, ossia:

A(q) · y(t) = B(q) · u(t) +K(q) · e(t) t ∈ N (3.3.1)

con il termine rappresentante l’errore (e(t)) imposto pari a zero, risulta essere pari a:

y(t) =0.005225 · q−22

1− q−1· u(t) (3.3.2)

Simulando linearmente il modello ottenuto mediante la funzione lsim si puo osser-

vare come l’uscita simulata ben approssimi i dati misurati (Figura 3.6).

38


0 2 4 6 8 10 12 14 16 18 20−80

−60

−40

−20

0

20

40

60

80

Ingresso

Uscita

Uscita simulata

Ingresso filtrato

Figura 3.6: Fitting tra uscita simulata e uscita reale.

Discretizzando il filtro e riscrivendo il sistema filtro-modello si ottiene il modello

finale, espresso come funzione di trasferimento:

THROTTLEmodel =0.0004975

z23 − 1.905 · z22 + 0.905 · z21(3.3.3)

dove il massimo esponente del denominatore e dovuto al ritardo imposto nella fase di

modellizzazione che tiene conto dello sfasamento esistente tra l’invio del comando e

l’effettiva risposta dell’AR.Drone.

3.3.2 Dinamica dello Yaw

In riferimento all’analisi della dinamica di rotazione intorno all’asse verticale, ossia il

movimento di Yaw, e stata eseguita una prova considerando come uscita gli angoli dei

quattro LED riferiti al baricentro. Il procedimento per il calcolo di tali angoli, espresso

per maggiore semplicita su un piano bidimensionale, e stato condotto considerando:

39

Cap. 3 Identificazione §3.3 Identificazione le coordinate dei 4 LED (x1, y1, x2, y2, . . . ); le coordinate del baricentro (xb, yb)

dalle quali e possibile determinare la distanza di ogni LED dal baricentro

distLED−b =√

(xb − xLED)2 + (yb − yLED)2 (3.3.4)

Quindi, note le coordinate di ogni LED, del baricentro e le distanze di ogni LED

dal baricentro, attraverso la trigonometria, e facilmente calcolabile l’angolo ϑ come:

ϑ = arccos

(

xLED − xb

distLED−b

)

(3.3.5)

La simmetria del movimento angolare dei quattro LED, osservabile in Figura 3.7,

consente di trattare l’uscita come il moto di un solo LED. La periodicita delle funzioni

0 2 4 6 8 10 120

50

100

150

200

TIME

AN

GLE

4 LED ANGLE − TIME

0 2 4 6 8 10 120

100

200

300

400

TIME

AN

GLE

1 LED ANGLE − TIME

Figura 3.7: Andamento dei 4 LED e del singolo adattato.

arcsin e arccos consente di modificare l’andamento capovolgendo il segnale rispetto a

180 per ottenere quindi la misura di un angolo assoluto.

40


La modellizzazione ottenuta, filtrando il segnale di ingresso con un integratore

(FILTRO = 1/s) ed utilizzando la funzione pem presenta un ottimo fitting.

0 2 4 6 8 10 12−50

0

50

100

150

200

250

300

350

400

IngressoIngresso filtratoUscitaUscita simulata

Figura 3.8: Risultato simulazione modello.

Il modello tempo discreto cosı ottenuto si esprime nella forma:

Y AWmodel =0.0001807

z11 − 1.994 · z10 + 0.9942 · z9(3.3.6)

Osservando il modello ottenuto, il cui comportamento risulta fortemente non

lineare, il progetto di un controllore e stato eseguito proprio su tale dinamica.

3.3.3 Dinamica del Roll e del Pitch

Come gia accennato nel Capitolo 3.3, i problemi riscontrati nell’acquisizione di dati

validi del solo moto di interesse, ha portato alla decisione di effettuare un’unica mo-

dellizzazione per la dinamica del Roll e del Pitch. Svolgendo il merge di due differenti

test, nei quali vengono imposti entrambi i comandi, e utilizzando un filtro sia per

41


l’ingresso sia per l’uscita per migliorare lo step della modellizzazione, si ottengono i

grafici riportati in Figura 3.9.

0 1 2 3 4 5 6 7−40

−30

−20

−10

0

10

20

30

40Roll

IngressoUscita

0 1 2 3 4 5 6 7−30

−20

−10

0

10

20

30Roll

Ingresso filtratoUscita filtrata

0 1 2 3 4 5 6 7−5

0

5

10

15Pitch

IngressoUscita

0 1 2 3 4 5 6 7−4

−2

0

2

4

6Pitch


(a) Primo test.

0 1 2 3 4 5 6 7 8−20

−10

0

10

20

30

40Roll

IngressoUscita

0 1 2 3 4 5 6 7 8−20

−10

0

10

20

30

40Roll


0 1 2 3 4 5 6 7 8−40

−30

−20

−10

0

10

20

30

40Pitch

IngressoUscita

0 1 2 3 4 5 6 7 8−40

−30

−20

−10

0

10

20

30Pitch


(b) Secondo test.

Figura 3.9: Grafici dei segnali in-out acquisiti e dei segnali in-out filtrati.

42


La funzione pem con ordine del sistema pari a 4, produce il modello espresso in

forma di spazio:

x(t + Ts) = Ax(t) +Bu(t) +Ke(t)

y(t) = Cx(t) +Du(t) + e(t).(3.3.7)

Tale sistema presenta una matrice K che moltiplica il segnale di errore e(t). Risultan-

do tale segnale non noto, viene impostato nullo ottenendo quindi il semplice sistema

in spazio di stato:

x(t+ Ts) = Ax(t) +Bu(t)

y(t) = Cx(t) +Du(t)(3.3.8)

caratterizzato dalle seguenti matrici:

A =

0.97282 −0.025726 −0.13921 0.0846240.042088 0.91982 −0.10778 0.0929090.14806 0.041073 0.91444 0.37019

−0.093362 −0.027825 0.069851 0.73558

(3.3.9a)

B =

−0.00014462 0.00026791−7.6339e−5 −0.00059758−0.0012908 −0.000136460.00085132 6.5491e−5

(3.3.9b)

C =

[

84.677 77.284 −5.3183 3.429766.902 −71.21 −0.52076 3.1836

]

(3.3.9c)

D =

[

0 00 0

]

(3.3.9d)

Il modello cosı ottenuto bene approssima le uscite misurate come e possibile osser-

vare dal compare in Figura 3.10. Il risultato osservabile riferito al primo test, in cui

il fitting ottenuto tra modello e uscite reali e pari ad un valore negativo, puo essere

motivato osservando la scala utilizzata in fase di modellizzazione. Infatti, mentre per

gli altri plot le variazioni dei segnali sono consistenti, il segnale (in Figura 3.10(a)

secondo plot) presenta un andamento compreso nell’intervallo [−2, 2], quindi molto

meno ampio rispetto a quelli per cui il fitting risulta accettabile.

43


1 2 3 4 5 6−10

−5

0

5

10

15

y1. (sim)

y1

data; measuredmymodel; fit: 73.67%

1 2 3 4 5 6

−2

−1

0

1

2

3y2. (sim)

y2

data; measuredmymodel; fit: −20.45%

(a) Primo test.

1 2 3 4 5 6 7

−5

0

5

10

15

y1. (sim)

y1


1 2 3 4 5 6 7−20

−10

0

10

y2. (sim)

y2


(b) Secondo test.

Figura 3.10: Fitting ottenuto tra uscita reale e modello.

44

CAPITOLO 4

Progetto di Controllore

Conclusa la fase di modellizzazione del sistema dinamico viene esegui-to un primo progetto di controllo con il fine di migliorare le prestazionidell’AR.Drone.

4.1 Dinamica da controllare

Osservando gli andamenti tra ingressi ed uscite ed i fitting ottenuti tra le uscite

simulate e le uscite reali, la scelta della dinamica sulla quale eseguire il progetto di

controllore e ricaduta sul moto di Yaw.

In tale test infatti, come e possibile notare dalla Figura 4.1, la dinamica di rotazione

dell’AR.Drone intorno al proprio asse Z non ha un buon comportamento. Osservando

l’ingresso (comando imposto) e l’uscita (variazioni della velocita angolare misurate dal

giroscopio presente sul drone) si nota come al termine del comando non corrisponda

il termine della rotazione.

Sia per il segnale di ingresso che per quello di uscita e stato effettuato un filtraggio,

45

Cap. 4 Progetto di Controllore §4.1 Dinamica da controllare

Figura 4.1: Andamento dell’ingresso e dell’uscita.

essendo presenti rumori e disturbi, tramite un filtro del tipo:

FILTRO =1

0.5s+ 1(4.1.1)

La scelta di impostare il parametro della funzione pem nk = [20], dovuto all’effet-

tivo ritardo nell’esecuzione della rotazione e la scelta dell’ordine del modello pari a 2,

porta il calcolo del modello tempo discreto caratterizzato dalle matrici:

A =

[

0.9984 0.01808−0.01286 0.9385

]

(4.1.2a)

B =

[

2.587E−5

−3.517E−5

]

(4.1.2b)

C =[

496.6 3.15]

(4.1.2c)

D =[

0]

(4.1.2d)

La simulazione di tale modello con l’ingresso definito, osservabile in Figura 4.2,

presenta un fitting non troppo elevato (circa pari al 36%) e questo risultato e stato il

punto di partenza per il progetto del controllore.

46

Cap. 4 Progetto di Controllore §4.2 Processo e Controllore

Figura 4.2: Andamento ingresso-uscita simulata.

4.2 Processo e Controllore

L’analisi del processo da controllare, ottenuto dalla moltiplicazione (della discretizza-

zione) del filtro e del modello ottenuto ed uguale a

P =0.4994z − 0.04808

z3 − 2.898z2 + 2.798z − 0.9005(4.2.1)

ha mostrato come l’aggiunta di un semplice controllore

C = 3 ·(z − 0.85)2

z2(4.2.2)

costituito quindi da due zeri abbastanza lontani dal cerchio unitario, migliora le pre-

stazioni del sistema. Osservando infatti il diagramma di Bode in Figura 4.3 si nota

come si ottiene un buon margine di guadagno (17.5 dB rispetto al 2.26 dB del solo

processo) e margine di fase (86.7 deg rispetto al 3.91 deg del solo processo). Dal luogo

delle radici della catena diretta (C ·P ), in Figura 4.4, si osserva come la presenza dei

poli vicino il cerchio unitario rappresentano la dinamica lenta dell’intero sistema, che

quindi governera l’evoluzione di quest’ultimo.

47


Figura 4.3: Diagrammi di Bode del Processo e della catena Controllore-Processo.

Figura 4.4: Luogo delle radici della catena Controllore-Processo.

Simulando ed osservando il comportamento dell’intero sistema a controreazione uni-

taria sottoposto ad un ingresso a gradino, si puo facilmente osservare (Figura 4.5)

come l’uscita abbia un buon andamento con un tempo di assestamento di circa 1.5 s.

48


0 0.5 1 1.5 2 2.5 30

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Step Response

Time (sec)

Am

plitu

de

Figura 4.5: Uscita del sistema a controreazione unitaria con ingresso a gradino.

Nell’ultima simulazione, sottoponendo quindi l’intero sistema agli ingressi considerati,

si osserva come l’uscita segua bene l’ingresso imposto, discostandosi parecchio dalla

situazione di sistema non controllato.

0 2 4 6 8 10 12−10

0

10

20

30

40

50

60

70

ControlledUncontrolledReference

Figura 4.6: Grafico del sistema non controllato e controllato.

49


Utilizzando il software 3D (del quale viene riportato il diagramma a blocchi in

Figura 4.7(a)), sviluppato da Alessandro Nicolosi in ambiente MATLAB/Simulink,

si e analizzato il comportamento del sistema non controllato ed osservati i reali

miglioramenti apportati con il controllo progettato.

(a) Diagramma a blocchi simulink.

(b) Istantanea. (c) Istantanea.

Figura 4.7: Software 3D di simulazione.

In conclusione e stato osservato il differente comportamento dell’AR.Drone in volo.

Sottoponendo quindi il sistema ad un comando di Yaw si e evidenziato come il sistema

50


controllato presenti netti miglioramenti rispetto a quello non controllato. Infatti,

mentre la dinamica di yaw non controllata viene eseguita nonostante il termine del

comando, con quella controllata, al termine del comando imposto, corrisponde il reale

blocco della rotazione.

Si e cosı mostrato come un semplice controllore progettato per la singola dinamica

di Yaw migliori abbondantemente le prestazioni e l’affidabilita.

51

Conclusioni e sviluppi futuri

Il presente lavoro di tesi ha quindi coperto differenti campi come l’analisi della mo-

dellizzazione di un sistema dinamico, ossia i metodi ed i problemi che si possono

incontrare nel processo, con particolare attenzione all’elaborazione dei segnali e dei

dati disponibili. Sono stati studiati diversi linguaggi di programmazione per lo svi-

luppo della specifica applicazione utilizzando un Software Development Kit per il

codice scritto in linguaggio C. Infine e stato affrontato il problema di progettare un

controllore di processo per il raggiungimento di un sistema stabile ed affidabile.

L’analisi dell’AR.Drone ha permesso di individuarne gli aspetti positivi e nega-

tivi. I possibili miglioramenti dal lato hardware e software sono tanti. Un esempio

riguarda la comunicazione wireless che avviene punto-punto tra l’AR.Drone e il di-

spositivo di comando (sia esso Iphone, Ipod o Personal Computer) ma un possibile

sviluppo potrebbe essere la realizzazione di una rete multi-punto con quindi la possi-

bilita di effettuare voli in remoto. Un’altra ancora in fase di studio presso i laboratori

di robotica e quello di valutare la possibilita di rendere il velivolo energeticamente

autonomo, almeno parzialmente, mediante l’uso di celle solari al silicio policristallino,

estremamente leggero.

E stato realizzato, attraverso l’utilizzo di hardware facilmente reperibile come LED

ad infrarosso e controller della Wii, un sistema di tracking 3D a basso costo e dal-

la buona affidabilita. Nonostante l’utilizzo di tale sistema sia stato utile e adatto

per il fine ultimo di tale lavoro, si e osservato come alcune limitazioni, ad esempio il

52


numero massimo di LED individuabili dal controller della Wii, non sono facilmente

sormontabili se non con l’utilizzo di apparecchiature piu specifiche. Alcune difficolta

incontrate invece, come ad esempio il limitato range di funzionamento o la precisione

nella triangolazione, con un approfondimento del lavoro sono facilmente superabili.

Il possibile utilizzo di LED IR con un cono di emissione della luce piu ampio ed una

analisi piu accurata dei processi di calibrazione e di triangolazione, possono sicura-

mente migliorare l’intero funzionamento del sistema.

Sarebbe altresı possibile usare dei marker riflettenti IR ed un illuminatore estero per

eliminare il problema del cono dei led ed il peso delle batterie.

Riguardo la modellizzazione della dinamica di volo, il modello ottenuto puo risul-

tare utile sia per osservare i controlli gia implementati nell’AR.Drone sia per capire in

che modo agire sul sistema se il comportamento non risulta soddisfacente. L’analisi

dei risultati mostra come il moto di Throttle, cosı come per quelli di Pitch e di Roll

risulta essere eseguito discretamente ed il risultato e alquanto accurato.

Il primo progetto teorico di controllo, effettuato sul moto di Yaw, ha mostrato come

vi siano ampi margini di miglioramento. Un’elaborazione dei dati acquisiti di ulteriore

prove, cercando di legare anche i dati di accelerometri e giroscopi, puo rappresentare

una valida scelta da eseguire per il raggiungimento di un modello completo, valido ed

affidabile. Tale obiettivo e stato raggiunto per la dinamica di Yaw: l’implementazione

di un controllo per la rotazione lungo l’asse Z mostra evidenti miglioramenti nella

dinamica.

53

Elenco delle figure

1 Foglio d’appunti e schizzo dell’invenzione. . . . . . . . . . . . . . . . . 2

1.1 AR.Drone Parrot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Sistema rotore-pale elicottero. . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Modi di rotazione ed assi cartesiani di riferimento. . . . . . . . . . . . 8

1.4 Convenzione movimenti modello a 4 rotori. . . . . . . . . . . . . . . . 8

1.5 Componenti del Drone. . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6 AR.Freeflight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.7 Applicazioni disponibili. . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Schema Iphone - AR.Drone. . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Schema collegamento PC-AR.Drone. . . . . . . . . . . . . . . . . . . 14

2.3 Parametri caratteristici di un sistema di visione stereoscopica. . . . . 15

2.4 Wii Controller e particolare della camera IR. . . . . . . . . . . . . . . 17

2.5 Inclinazione del LED rilevabile (a) e non (b) da parte del controller. . 19

2.6 Possibili posizionamenti delle camera e area di lavoro disponibile. . . 19

2.7 Particolari del pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8 Soluzione finale del pattern. . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 Interfaccia grafica e visualizzazione punti. . . . . . . . . . . . . . . . . 23

2.10 Risultato della stereo calibrazione. . . . . . . . . . . . . . . . . . . . . 24

2.11 Schema collegamento PC - AR.Drone. . . . . . . . . . . . . . . . . . 26

54

ELENCO DELLE FIGURE ELENCO DELLE FIGURE

3.1 Algoritmo generico di identificazione[8]. . . . . . . . . . . . . . . . . . 32

3.2 Operazione di filtraggio e pulizia dell’altezza del baricentro IR. . . . . 34

3.3 Esempio di grafici ottenuti da una prima prova. . . . . . . . . . . . . 35

3.4 Esempio di grafici ottenuti da una seconda prova. . . . . . . . . . . . 36

3.5 Relazione tra throttle e altezza misurata. . . . . . . . . . . . . . . . . 38

3.6 Fitting tra uscita simulata e uscita reale. . . . . . . . . . . . . . . . . 39

3.7 Andamento dei 4 LED e del singolo adattato. . . . . . . . . . . . . . 40

3.8 Risultato simulazione modello. . . . . . . . . . . . . . . . . . . . . . . 41

3.9 Grafici dei segnali in-out acquisiti e dei segnali in-out filtrati. . . . . . 42

3.10 Fitting ottenuto tra uscita reale e modello. . . . . . . . . . . . . . . . 44

4.1 Andamento dell’ingresso e dell’uscita. . . . . . . . . . . . . . . . . . . 46

4.2 Andamento ingresso-uscita simulata. . . . . . . . . . . . . . . . . . . 47

4.3 Diagrammi di Bode del Processo e della catena Controllore-Processo. 48

4.4 Luogo delle radici della catena Controllore-Processo. . . . . . . . . . . 48

4.5 Uscita del sistema a controreazione unitaria con ingresso a gradino. . 49

4.6 Grafico del sistema non controllato e controllato. . . . . . . . . . . . . 49

4.7 Software 3D di simulazione. . . . . . . . . . . . . . . . . . . . . . . . 50

55

Elenco delle tabelle

2.1 Mappatura Joystick. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

56

Elenco dei codici

2.1 Procedura di salvataggio coordinate. . . . . . . . . . . . . . . . . . . 21

2.2 Esempio file di uscita del sistema di acquisizione. . . . . . . . . . . . 22

2.3 Esempio file remoteleft.m. . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Definizione della funzione stereo triangulation. . . . . . . . . . . . . . 25

2.5 Esempio file di uscita dei dati di volo.txt . . . . . . . . . . . . . . . . 27

57

Bibliografia

[1] Museo Nazionale della Scienza e della Tecnologia Leonardo Da Vinci,

http://www.museoscienza.org/, 2011.

[2] Enciclopedia Treccani, Voce “Elicottero”, 2011.

[3] Stephane Piskorski, Nicolas Brulez, “AR.Drone Developer Guide”, Revision 1.6,

Parrot, February 2011.

[4] Johnny Chung Lee, Carnegie Mellon University, “Hacking the Nintendo Wii

Remote”, IEEE Pervasive Computing (vol. 7 no. 3), July-September 2008.

[5] T. Cuypers, T.V. Eede, S. Ligot, Y. Francken, C. Hermans, F. Arickx, P. Bekaert,

“StereoWiision: Stereo Vision with Wiimotes”, International 3D Stereo Film and

Technology Festival (3D Stereo MEDIA), 2009.

[6] Andrea Zoli, “Miglioramento della fase d’acquisizione in un sistema di Fast

Reverse Engineering”, Universita di Bologna, 2010.

[7] S. Hay. “Optical tracking using commodity hardware”, September 2008.

[8] L. Ljung, System Identification – Theory for the User, Prentice Hall, 1999

58

Documents

FACOLTA DI INGEGNERIA` CORSO DI LAUREA IN …control.disp.uniroma2.it/.../Tesi/davidebossi/TesiDavideBossi.pdf · Capitolo 4 viene proposto il primo progetto, in riferimento alla