POLITECNICO DI MILANO

Scuola di Ingegneria Industriale e dell’Informazione

Corso di Laurea Magistrale in

Ingegneria Meccanica

CONTROLLO VISUALE DI UN SISTEMA ROBOTICO PER LA RACCOLTA

DELLA FRUTTA

Relatore: Prof. Gianni Ferretti

Tesi di Laurea di:

Persico Stefano Numero di matricola: 817582

Anno Accademico 2014 – 2015

I

Indice

1 Approccio al problema: la raccolta automatica di frutta............................................................................ 1

1.1 Esperienze passate e stato dell’arte ................................................................................................... 1

1.1.1 Mechanical harvesting ............................................................................................................... 2

1.1.2 Automatic harvesting ................................................................................................................. 6

1.1.3 Tecniche di visione macchina diffuse ........................................................................................ 9

1.1.4 Tecniche di analisi dell’immagine ........................................................................................... 13

1.2 Il sistema di asservimento visuale ................................................................................................... 15

1.2.1 Punto di vista della telecamera ................................................................................................ 15

1.2.2 Processamento d’immagine ..................................................................................................... 16

1.2.3 Schemi di asservimento visuale ............................................................................................... 17

1.3 Scelte e premesse per l’algoritmo proposto ..................................................................................... 19

2 Descrizione algoritmo.............................................................................................................................. 21

2.1 Descrizione dell’algoritmo .............................................................................................................. 21

2.2 Sistemi di riferimento ...................................................................................................................... 23

2.3 Ispezione Preliminare ...................................................................................................................... 28

2.3.1 Routine di osservazione ........................................................................................................... 28

2.3.2 Image processing ..................................................................................................................... 29

2.3.3 Arresto e criteri di uscita dall’osservazione ............................................................................. 29

2.4 Triangolazione ................................................................................................................................. 31

2.4.1 Stima della profondità ............................................................................................................. 33

2.4.2 Stima dei asse maggiore e minore ........................................................................................... 34

2.5 Controllo in avvicinamento ............................................................................................................. 36

2.5.1 Controllo rotazionale ............................................................................................................... 36

2.5.2 Controllo traslazionale ............................................................................................................. 47

2.5.3 Attuazione del robot ................................................................................................................ 49

2.5.4 Arresto e criteri di uscita dal controllo .................................................................................... 50

3 Simulazione in Matlab ............................................................................................................................. 51

3.1 Modellazione del sistema ................................................................................................................ 51

3.1.1 Modellazione del Robot in convenzione Denavit Hartenberg ................................................. 52

3.1.2 Costruzione dell’oggetto obiettivo .......................................................................................... 58

3.1.3 Modellazione della telecamera ................................................................................................ 59

3.2 Ispezione preliminare ...................................................................................................................... 60

3.3 Triangolazione ................................................................................................................................. 63

3.4 Avvicinamento in controllo ............................................................................................................. 66

3.5 Risultato delle simulazioni .............................................................................................................. 70

II

3.5.1 Risultati ed effetti del tempo di integrazione ........................................................................... 70

3.5.2 Manovrabilità ed effetti della posizione obiettivo ................................................................... 76

4 Simulazione in Simulink ......................................................................................................................... 84

4.1 Importazione dei dati ....................................................................................................................... 84

4.2 Modellazione del robot .................................................................................................................... 85

4.3 Telecamera e processamento delle immagini .................................................................................. 87

4.4 Asservimento visuale e chiusura del ciclo ....................................................................................... 88

4.5 Risultati delle simulaioni ................................................................................................................. 89

5 Simulazione in V-REP............................................................................................................................. 91

5.1 Modellazione della scena................................................................................................................. 92

5.1.1 Sfondo ...................................................................................................................................... 92

5.1.2 Robot ....................................................................................................................................... 92

5.1.3 Obiettivo .................................................................................................................................. 93

5.1.4 Telecamera............................................................................................................................... 94

5.1.5 Preparazione dei ROS topic ..................................................................................................... 96

5.2 Configurazione lato Matlab ............................................................................................................. 97

5.2.1 Sintassi ROS in Matlab ............................................................................................................ 98

5.2.2 Gestione dell’offset di origine dei giunti ............................................................................... 100

5.2.3 Controllo in velocità della base ............................................................................................. 100

5.3 Risultati della simulazione............................................................................................................. 101

6 Sperimentazione .................................................................................................................................... 106

6.1 Materiale e preparazione ............................................................................................................... 106

6.1.1 Strumentazione ...................................................................................................................... 106

6.1.2 Preparazione software ............................................................................................................ 107

6.1.3 Calibrazione e registrazione degli offset ............................................................................... 107

6.1.4 Preparazione dell’area di lavoro ............................................................................................ 108

6.2 Validazione dell’algoritmo ............................................................................................................ 109

6.2.1 Strategie di controllo ............................................................................................................. 110

6.2.2 Prova del metodo ................................................................................................................... 111

6.3 Effetto del posizionamento ............................................................................................................ 113

6.4 Effetto dell’occultamento .............................................................................................................. 115

7 Conclusioni ............................................................................................................................................ 117

7.1 Cosa è stato ottenuto ...................................................................................................................... 117

7.2 Sviluppi futuri ................................................................................................................................ 117

8 Appendice A .......................................................................................................................................... 119

8.1 Panoramica sull’ambiente ROS ..................................................................................................... 119

8.1.1 Cos’è ROS ............................................................................................................................. 119

8.1.2 Storia e scopo di ROS ............................................................................................................ 120

III

8.1.3 Struttura concettuale di ROS ................................................................................................. 121

8.2 Percorso di implementazione della rete ROS ................................................................................ 124

8.2.1 Premesse all’implementazione .............................................................................................. 124

8.2.2 Ububtu 14.04 Lts (Trusty) 64bit ............................................................................................ 125

8.2.3 ROS Indigo Igloo................................................................................................................... 130

8.2.4 V-REP .................................................................................................................................... 133

8.2.5 YouBot ROS wrapper per Indigo .......................................................................................... 135

8.2.6 Matlab R20015a .................................................................................................................... 139

9 Appendice B .......................................................................................................................................... 144

9.1 Image processing in simulazione Matlab-Simulink (su punti) ...................................................... 145

9.2 Image processing in Vrep e su telecamera reale (su macchie di colore) ....................................... 148

10 Bibliografia ........................................................................................................................................ 150

IV

Indice delle figure

Fig. 1: Raccolta manuale negli anni 50 ............................................................................................................. 2 Fig. 2: Limb shaker di prima generazione e successivo modello a doppia ganascia ......................................... 3 Fig. 3: Raccoglitore a getto d'aria del 1962 e successivo modello a getto ottimizzato ..................................... 4 Fig. 4: Canopy shaker verticale e moderno shaker rotativo continuo ............................................................... 4 Fig. 5: Moderno trunk shaker a riposo ed in afferraggio ................................................................................... 5 Fig. 6: Schema stereoscopico presentato in [20] ............................................................................................. 11 Fig. 7: Esempio in scala di grigi di stima laser della profondità (si notano errori di stima su superfici molto

inclinate) .......................................................................................................................................................... 11 Fig. 8: Struttura di un'immagine iperspettrale ................................................................................................. 12 Fig. 9: Configurazione "eye-in-hand" (A) e "eye-to-hand" (B) ....................................................................... 15 Fig. 10: Rappresentazione dei dati post image processing per il riconoscimento di una singola mela ........... 16 Fig. 11: Schema del controllo visuale nello spazio operativo ......................................................................... 17 Fig. 12: Schema del controllo visuale nello spazio delle immagini ................................................................ 18 Fig. 13: Kuka YouBot ..................................................................................................................................... 19 Fig. 14: Modello cinematico del braccio del robot, si nota la presenza dell’oggetto obiettivo in rosso ......... 20 Fig. 15: Ellissoide che modellizza il frutto da raccogliere .............................................................................. 22 Fig. 16: Vista della proiezione nel piano immagine ........................................................................................ 22 Fig. 17: Kuka YouBot e sistemi di riferimento ............................................................................................... 23 Fig. 18: Prodotto vettoriale tra e .......................................................................................................... 25

Fig. 19: Immagine esplicativa di e ............................................................................................................ 26 Fig. 20: Distanza tra telecamera e centroide .................................................................................................... 26 Fig. 21: Schema della relazione prospettica .................................................................................................... 27 Fig. 22: Esempio di triangolazione standard ................................................................................................... 31 Fig. 23: Punti di triangolazione ....................................................................................................................... 32 Fig. 24: Schema di triangolazione ................................................................................................................... 33 Fig. 25: Punti per la stima degli assi ................................................................................................................ 34 Fig. 26: Attivazione Machine vision e Robotics toolbox ................................................................................ 51 Fig. 27: Rappresentazione dei parametri D-H ................................................................................................. 52 Fig. 28: Quote del braccio e relative escursioni .............................................................................................. 54 Fig. 29: Definizione Matlab del braccio .......................................................................................................... 55 Fig. 30: Rappresentazione del braccio in coordinate (0;0;0;0;0) dei giunti..................................................... 56 Fig. 31: Dati sulla base (non ci sono chiaramente limiti di escursione) .......................................................... 56 Fig. 32: Implementqazione Matlab della piattaforma ...................................................................................... 57 Fig. 33: Rappresentazione della base in coordinate (0;0) del piano (giunti prismatici) .................................. 57 Fig. 34: Implementazione Matlab dell’intero robot ......................................................................................... 57 Fig. 35: Rappresentazione del robot in coordinate dei giunti (0;0;0;0;0;0;0) ................................................. 58 Fig. 36: Creazione obiettivo ............................................................................................................................ 58 Fig. 37: Robot ed obiettivo .............................................................................................................................. 59 Fig. 38: Caratterizzazione telecamera e parametri intrinseci ........................................................................... 60 Fig. 39: Proiezione dei punti sul piano immagine ........................................................................................... 60 Fig. 40: Routine di ispezione ........................................................................................................................... 61 Fig. 41: Esempio di traiettoria di ispezione (a destra la vista dall’alto) .......................................................... 62 Fig. 42: Risultato dell'ispezione sul piano immagine ...................................................................................... 62 Fig. 43: Features sovrapposte alle immagini nei rispettivi punti di triangolazione ........................................ 64 Fig. 44: Stima della profondità ........................................................................................................................ 65 Fig. 45: Calcolo delle dimensioni stimate dell'obiettivo ................................................................................. 65 Fig. 46: Inizio ciclo .......................................................................................................................................... 67 Fig. 47: Controllo rotazionale .......................................................................................................................... 68

V

Fig. 48: Controllo traslazionale ....................................................................................................................... 68 Fig. 49: Controllo del numero di condizionamento di J .................................................................................. 69 Fig. 50: Profondità stimata in controllo ........................................................................................................... 71 Fig. 51: Posizioni del centroide sul piano immagine in controllo ................................................................... 72 Fig. 52: Errori sul piano immagine in controllo .............................................................................................. 72 Fig. 53: Movimento nello spazio dei giunti ..................................................................................................... 73 Fig. 54: Profondità stimata in controllo ........................................................................................................... 74 Fig. 55: Errori sul piano immagine in controllo .............................................................................................. 75 Fig. 56: Movimento nello spazio dei giunti ..................................................................................................... 76 Fig. 57: Numero di condizionamento per Tint=0.001 s .................................................................................. 78 Fig. 58: Numero di condizionamento per Tint=0.5 s ...................................................................................... 79 Fig. 59: Numero di condizionamento certamente non accettabile, caso in singolarità di gomito ................... 80 Fig. 60: Ellissoidi della velocità in posizione iniziale e finale ........................................................................ 81 Fig. 61: Ellissoidi della velocità in un punto di manipolabilità ridotta ........................................................... 81 Fig. 62: Singolarità cinematica e relativo ellissoide di manipolabilità degenere ............................................ 82 Fig. 63: Prese del frutto in (0,6;0,4;0,3) e (0,6;0,4;0,4) ................................................................................... 82 Fig. 64: Prese del frutto in (0,6;0,4;0,5) e (0,6;0,4;0,6) ................................................................................... 83 Fig. 65: Passaggio di parametri dal workspace Matlab a Simulink ................................................................. 85 Fig. 66: Blocco fkine per il calcolo della matrice Tcam .................................................................................. 86 Fig. 67: Blocco jacobn per il calcolo dello Jacobiano ..................................................................................... 86 Fig. 68: Blocco pinvJac per determinare le velocità ai giunti ......................................................................... 86 Fig. 69: Blocco plot ......................................................................................................................................... 86 Fig. 70: Blocco camera per l'acquisizione d'immagine ................................................................................... 87 Fig. 71: Blocco di image processing ............................................................................................................... 87 Fig. 72: Inizio dello script per il blocco image processing .............................................................................. 88 Fig. 73: Blocco di asservimento visuale e relativi ingressi ............................................................................. 89 Fig. 74: Blocco integratore .............................................................................................................................. 89 Fig. 75: Schema a blocchi del controllo completo .......................................................................................... 90 Fig. 76: Barriera visuale verso il vuoto ........................................................................................................... 92 Fig. 77: Importazione del modello di YouBot ................................................................................................. 92 Fig. 78: Creazione della sfera obiettivo ........................................................................................................... 93 Fig. 79: Impostazione del colore dell'obiettivo ............................................................................................... 93 Fig. 80: Impostazione della posizione e visibilità ........................................................................................... 94 Fig. 81: Definizione parametri del Vision Sensor ........................................................................................... 95 Fig. 82: Montaggio della videocamera "figlia" e floating view ...................................................................... 95 Fig. 83: Preparazione dei ROS subscriber ....................................................................................................... 96 Fig. 84: Verifica dell'apertura dei topic Vrep da terminal ............................................................................... 97 Fig. 85: Stato della rete ROS dopo la configurazione Matlab-Vrep ................................................................ 98 Fig. 86: Sintassi per i topic in Matlab .............................................................................................................. 98 Fig. 87: Sintassi per servizi ROS in Matlab .................................................................................................... 99 Fig. 88: Inizializzazione subscriber immagini e relative conversioni ............................................................. 99 Fig. 89: Coordinate di origine in Vrep e corrispettivo Matlab ...................................................................... 100 Fig. 90: Ripartizione della velocità di base sulle singole ruote ..................................................................... 101 Fig. 91: Risultati di image processing dal primo punto di triangolazione ..................................................... 102 Fig. 92: Spostamento al secondo punto di triangolazione ............................................................................. 102 Fig. 93: Profondità stimata in controllo su Vrep a sinistra, a destra immagine in avvicinamento ................ 103 Fig. 94: Errori sul piano immagine in controllo su Vrep ............................................................................... 103 Fig. 95: Profondità dopo l'implementazione del secondo controllo a sinistra, estensione del braccio a destra

....................................................................................................................................................................... 104 Fig. 96: Errori sul piano immagine con la seconfa fase di controllo ............................................................. 105 Fig. 97: Condizionamento di J nei due casi di controllo ............................................................................... 105 Fig. 98: Passaggio delle coordinate dei giunti Matlab-ROS .......................................................................... 108

VI

Fig. 99: Robot in avvicinamento al frutto obiettivo vincolato al pannello .................................................... 109 Fig. 100: Profondità in avvicinamento .......................................................................................................... 111 Fig. 101: Errori rispetto al centro del piano immagine .................................................................................. 112 Fig. 102: Andamenti nel piano dell'immagine............................................................................................... 112 Fig. 103: Riquadri per le prove di posizionamento del frutto ........................................................................ 114 Fig. 104: Andamento accettabile del numero di condizionamento e caso interrotto ..................................... 115 Fig. 105: Profondità stimata ed immagine pre-triangolazione ad occultamento <10% ................................. 115 Fig. 106: Andamento sul piano dell'immagine ad occultamento < 10% ....................................................... 116 Fig. 107: Profondità stimata ed immagine pre-triangolazione ad occultamento tra 50% e 70% ................... 116 Fig. 108: Comunicazione via Topic .............................................................................................................. 122 Fig. 109: Download di Ubuntu ...................................................................................................................... 125 Fig. 110: Immagine .iso su disco ................................................................................................................... 126 Fig. 111: Creazione di una “live bootable usb” ............................................................................................. 126 Fig. 112: Configurazione repositories ........................................................................................................... 130 Fig. 113: Verifica di interfaccia ROS-Vrep ................................................................................................... 135 Fig. 114: Configurazione delle porte di rete del computer ............................................................................ 137 Fig. 115: Modifica al file "youbot-ethercat.cfg" ........................................................................................... 138 Fig. 116: Modifica delle dependencies in "package.xml" ............................................................................. 141 Fig. 117: inizio generazione dei messaggi ROS custom ............................................................................... 142 Fig. 118: Risultati compilazione e passaggi richiesti .................................................................................... 142 Fig. 119: Errore con collegamento al Support Package Installer .................................................................. 143 Fig. 120: Features da identificare grazie all’image processing ..................................................................... 144 Fig. 121: Image processing standard per punti in Matlab ............................................................................. 146 Fig. 122: ellisse con assi ricavati dagli autovalori ......................................................................................... 147 Fig. 123: Ottenimento di asse maggiore e minore nel nuovo metodo ........................................................... 147 Fig. 124: Funzione Im_Processing ................................................................................................................ 149 Fig. 125: Sequenza di processamento di un'immagine RGB ......................................................................... 149

Indice delle tabelle

Tabella 1: Caratterizzazione DH del braccio ................................................................................................... 55 Tabella 2: caratterizzazione DH della piattaforma .......................................................................................... 57 Tabella 3: Esempio di risultati triangolazione ................................................................................................. 66 Tabella 4:Costanti di controllo ........................................................................................................................ 67 Tabella 5: Specifiche del calcolatore ............................................................................................................. 106 Tabella 6: Configurazione webcam da Matlab .............................................................................................. 107 Tabella 7: Risultati prove di posizionamento ................................................................................................ 114 Tabella 8: Avvicinamento ad una posizione obiettivo .................................................................................. 114

VII

Sommario

La presente tesi ha avuto lo scopo di proporre e testare sperimentalmente un algoritmo per sistemi robotici

atto alla raccolta della frutta.

Nella prima sezione vengono introdotte le più comuni tecniche presenti in letteratura con particolare

attenzione per pregi e difetti delle stesse. Riconosciute le potenzialità dei sistemi di raccolta automatici ad

asservimento visuale, vengono definite le caratteristiche desiderate per la successiva progettazione.

La descrizione dell’algoritmo tratta nel dettaglio della tecnica qui proposta per un robot manipolatore mobile

nelle fasi di: ispezione preliminare, triangolazione ed avvicinamento in controllo disaccoppiato (traslazionale

e rotazionale).

Le fasi di simulazione Matlab/Simulink hanno permesso di trarre importanti conclusioni circa cinematica di

esecuzione, manovrabilità del robot ed implementazione logica della sequenza di raccolta.

L’ambiente di simulazione Vrep ha permesso una modellazione più aderente alla realtà e, di conseguenza, di

ottenere le prime conferme circa il buon funzionamento dell’algoritmo in congiunzione con le realistiche

tecniche proposte per il processamento delle immagini. Questo passaggio è stato oltretutto fondamentale

poiché è servito a testare con successo il funzionamento del ponte ad interfaccia ROS tra Matlab ed una

utenza esterna.

La sperimentazione finale ha permesso di valutare reali tempistiche di avvicinamento e di verificare con

successo che l’implementazione effettuata risultasse robusta rispetto a diverse condizioni di posizionamento

ed occultamento degli obiettivi.

Dimostrata nelle condizioni sperimentali la validità di quanto proposto, la tesi si conclude con una breve

valutazione delle sfide da affrontare in futuro per applicazioni ottimizzate.

1

1 Approccio al problema: la raccolta automatica di frutta

Nel quadro delle sfide per fronteggiare la crescita globale di domanda alimentare, una delle chiavi per il

successo è, sicuramente, lo sviluppo di tecniche agricole intensive ma al contempo sostenibili.

L’automazione costituisce al giorno d’oggi un efficace modo per migliorare la produttività in molti settori

industriali ed è quindi naturale che, più volte, si sia tentato di estendere questi pregi anche al settore di

produzione del primario; la raccolta di frutta è tuttavia, in particolare, una problematica che ancora viene

principalmente affrontata con tecniche manuali scarsamente ottimizzate.

Uno dei motivi del mancato sviluppo in questo ambito è determinato dal fatto che, se è vero che

l’automazione offre interessanti prospettive di miglioramento, resta comunque necessario considerare che la

procedura di raccolta frutta presenta diverse complicazioni dal punto di vista della programmazione e

progettazione. Non è infatti banale gestire in contemporanea tutte le variabili riscontrabili in serre o frutteti

tradizionali quali, solo per fare alcuni esempi:

le irregolarità di terreno e piante

l’impossibilità di conoscere a priori dati precisi sui singoli frutti da raccogliere

la difficoltà nel discriminare frutta matura da quella che ancora non lo è

le condizioni di casuale posizionamento, occultamento ed eventuale velocità di movimento degli

obiettivi per effetto di vento o spostamento delle fronde.

Negli ultimi anni sono stati tentati diversi approcci per risolvere queste problematiche ma una scelta comune

ai metodi utilizzati è quella di prevedere sistemi di controllo basati sull’impiego congiunto di sensori multipli

per risolvere problemi specifici (e.g. sensori sonar per stimare la profondità, sensori cromatici per stimare la

bontà del frutto, accelerometri e giroscopi per ricavare dalla dinamica la posa del robot).

Questa tesi si propone di esplorare, per il problema in esame, le potenzialità offerte da tecniche di controllo e

gestione dei robot relativamente nuove (ROS network e visual servoing) in congiunzione con quanto è

permesso dalle prestazioni computazionali dei calcolatori di recente diffusione.

Prima di affrontare la problematica è buona cosa fare un riepilogo delle esperienze fatte da altri nello stesso

ambito; per questo, nei prossimi paragrafi, si tenterà di ricapitolare brevemente le tappe fondamentali della

ricerca svolta circa i sistemi meccanizzati per la raccolta di frutta.

1.1 Esperienze passate e stato dell’arte Già sul finire degli anni 50, principalmente a seguito dello sviluppo industriale statunitense del periodo,

cominciò ad apparire evidente che i tradizionali metodi manuali di raccolta fossero largamente inefficienti

sia sotto il profilo economico sia in termini di tempo. Anche secondo recenti stime [1] , allo stato attuale, il

2

costo totale di produzione nel caso degli agrumi è costituito per il 35-45% dai soli costi di raccolta e questo è

un fattore importante per giustificare l’impegno nella ricerca di metodologie ottimizzate di raccolta.

Come sottolineato in [2], sono due i principali filoni di ricerca che, a partire dagli anni 60, sono stati

intrapresi per l’approccio alla raccolta:

I sistemi di raccolta di massa o massiva spesso indicati semplicemente come “Mechanical

harvesting” sono stati i primi ad essere proposti e valutati. Si tratta, indipendentemente dal mezzo

specifico, di procedure tese alla rimozione massiva e contemporanea del maggior numero possibile

di frutti dalle piante negli opportuni periodi di maturazione. A prescindere dalla scelta dei metodi

particolari che verranno descritti a breve, a fronte di una buona produttività, questi sistemi sono

approssimativi ed operano in modo “cieco” potenzialmente danneggiando piante e frutta, che

peraltro non può essere direttamente selezionata in questa fase.

I sistemi di raccolta automatica o “Automatic harvesting” proposti solo dal punto di vista

concettuale nella seconda metà degli anni 60 [3]. Si tratta di procedure che si propongono di guidare

manipolatori automatici nella posizione adeguata alla raccolta di frutti singoli sulla base delle

informazioni ricavate da set di sensori appositamente predisposti. In questo caso i problemi

principali sono legati a difficoltà di identificazione degli obiettivi nell’ambiente di lavoro, robustezza

degli algoritmi e produttività.

Nessuno dei due filoni è mai stato propriamente abbandonato e la ricerca è proseguita in parallelo fino ad

oggi; di seguito vengono brevemente indicate le principali tappe di sviluppo per l’uno e per l’altro con

particolare attenzione per pregi e difetti di ogni tecnica.

Fig. 1: Raccolta manuale negli anni 50

1.1.1 Mechanical harvesting

Nel 1961 Coppock [4] dimostrò che gli agrumi possono essere raccolti in massa per scuotimento di rami

singoli attraverso mezzi meccanici non distruttivi per l’albero.

3

Le principali tecnologie collegate alla raccolta massiva sviluppate da allora sono le seguenti:

Limb shaker: scuotimento dei singoli rami.

Air blast: a getto d’aria

Canopy shaking: scuotimento della chioma

Trunk shaking: con vibrazione del tronco

Absission chemicals: irrorazione delle piante con agenti chimici in grado di facilitare il distacco dei

piccioli dai rami.

Post-harvesting: dispositivi collettori post raccolta

Limb shaker

Un primo metodo inerziale di raccolta per scuotimento rami è stato introdotto da Coppock e Jutras in [5]

Fig. 2: Limb shaker di prima generazione e successivo modello a doppia ganascia

Per ottenere l’eccitazione necessaria sul ramo vennero testati due metodi: uno shaker a massa eccentrica

(vibrodina) di circa 40 kg da vincolare al ramo ed attuatori ad impatto diretto. Il sistema vibrante si è

dimostrato da subito il metodo più efficace e meno distruttivo.

Nel corso degli anni sono state affinate le tecniche di ancoraggio ai rami con sistemi a doppia ganascia [6]

con o senza alimentazione propria ma non è stato possibile superare le difficoltà che caratterizzano questo

tipo di raccolta: danni di afferraggio alla corteccia, danno ai frutti ed al fogliame, tendenza a cogliere frutti

immaturi.

Air blast

A partire dal 1962 sono stati tentati approcci a getto d’aria oscillante come quello proposto da Jutras e

Patterson in [7] . La velocità di oscillazione del getto d’aria era sperimentalmente ottimizzata per la

rimozione di frutta.

4

Fig. 3: Raccoglitore a getto d'aria del 1962 e successivo modello a getto ottimizzato

Le performance di questo tipo di raccolta sono largamente dipendenti da dimensione degli alberi e

dimensione/peso dei frutti. Sono stati in seguito sviluppati metodi per mitigare le eccessive perdite e la

conseguente alta potenza [8] ma non è stato possibile risolvere il problema dei danni arrecati a frutta e

soprattutto foglie.

Canopy shaking

Questo tipo di scuotitore è stato introdotto per interagire con i rami secondari, imprimendo oscillazioni che

movimentassero la chioma solitamente in senso verticale. Nel caso di studio di Summer per le arance [9] un

sistema a pantografo si protrude nella chioma sollecitandola quindi interamente, sempre in direzione

verticale. Alcuni macchinari moderni tentano approcci misti con continui movimenti circolari degli

eccitatori, talvolta orizzontali.

Fig. 4: Canopy shaker verticale e moderno shaker rotativo continuo

5

Tra i metodi di raccolta degli agrumi questo è forse quello più utilizzato per efficienza di economia e

tempistica. Occorre considerare che la frequenza di eccitazione e lo specifico tipo di macchina rivestono un

ruolo molto importante per l’ottimizzazione e rimangono ineliminabili i problemi di danno a rami e

fogliame.

Trunk shaking

La movimentazione del tronco si presta in particolar modo per noci e frutta decidua, può evitare danni a rami

e foglie ma è difficilmente applicabile a tutte le tipologie di frutta. Hedden e Whitney [10] hanno esteso

questi risultati alla raccolta delle arance ottimizzando la banda di basse frequenze ed ampie oscillazioni

necessarie ad una appropriata sollecitazione. L’efficienza della raccolta era superiore a quella dei canopy

shaker contemporanei con risultati di 67% di frutti raccolti su grossi alberi e 98% su piccoli.

Fig. 5: Moderno trunk shaker a riposo ed in afferraggio

La bassa frequenza di oscillazione è in grado di limitare molto i danni a rami e foglie ma non risolve i

problemi dei danni di contatto con la corteccia del tronco.

Absission chemicals

L’impiego di sostanze chimiche che favorissero il distacco dei frutti maturi è stato molto presto integrato ai

metodi di raccolta meccanica a getto d’aria e vibrazionali.

Metodo ed intensità di irrorazione variano in base alla particolare sostanza chimica utilizzata ed a molteplici

altri fattori quali stagione e tipo di frutta da raccogliere ma, in linea di massima, il processo prevede

l’applicazione del composto per nebulizzazione dai 3 ai 6 giorni prima del raccolto.

Gli agenti chimici più utilizzati sono quelli che, commercialmente, ricadono nelle classi di “regolatori di

crescita vegetale” e defolianti. Ethephon, Prosulfuron e MJ (Methyl Jasmonate) sono i più diffusi ma molti

altri composti e relativi usi misti sono stati introdotti per ottenere i migliori compromessi tra potere di

rilascio dei frutti e limitazione degli effetti defolianti.

6

In [11] sono stati testati gli effetti di diverse sostanze applicate a casi di raccolta con trunk shaker. È emerso

che la massa complessiva raccolta risulta incrementata fino al 30% nelle condizioni climatiche e stagionali

ottimali. Accanto ai risultati positivi occorre tuttavia evidenziare alcuni problemi riscontrati: il

miglioramento apportato è largamente determinato da fattori difficilmente controllabili quali clima, stato di

salute dell’albero e strumenti specifici di diffusione.

Lo stesso articolo citato conclude che c’è l’evidenza di risultati positivi ma, a causa dei costi delle sostanze e

della non costanza dei risultati, è tuttora opinabile la scelta di utilizzare su vasta scala tali agenti chimici. A

ciò si aggiungono le problematiche legate alla sostenibilità ecologica della raccolta e gli effetti collaterali del

defogliante che, anche in assenza di specifici studi a riguardo, può potenzialmente danneggiare piante e

successivi raccolti. Alcuni frutticoltori hanno testimoniato che le sostanze hanno spesso forzato la caduta di

frutta non matura e quindi inutilizzabile anche a diversi giorni dalla prima raccolta.

Post harvesting

Anche se non è stato discusso nel dettaglio in precedenza è evidente che, di pari passo con lo sviluppo di

tecniche di distacco massivo di frutta, occorre predisporre adeguati sistemi di raccolta. Lo scopo di tali

sistemi non è soltanto quello di riunire tutta la frutta ma anche quello di evitarne il danneggiamento e

facilitarne lo stoccaggio evitando, per quanto possibile, la contaminazione microbiologica della stessa.

Nel corso degli anni si è passati da semplici strutture reticolari su cui venivano tesi teloni impermeabili

(visibili in Fig. 2) a complesse strutture semirigide con nastri collettori che si adeguano progressivamente

alla movimentazione. Ciò che sicuramente emerge dall’osservazione di questi dispositivi è che la loro

progettazione è strettamente legata alla natura dei frutteti su cui dovranno operare ed il loro costo di

investimento è tutt’atro che trascurabile nell’economia globale della raccolta.

1.1.2 Automatic harvesting

I sistemi di raccolta di massa dimostrano una buona produttività e si prestano per la raccolta di tipi di frutta

che, come gli agrumi, non necessitano di particolare delicatezza o attenzioni.

Ciò che è evidente è che tutti i metodi appena descritti lavorano alla cieca e, per questo, non possono

competere con raccoglitori umani per precisione ed abilità di cernita. Tali capacità sono fondamentali per la

raccolta di frutta più facilmente danneggiabile (come le mele) o dall’alto valore aggiunto.

Per i suddetti motivi e per gestire le irregolarità dei frutteti, già a partire dal 1962 si teorizzavano effettivi

sistemi di raccolta automatica come quelli proposti da Schertz and Brown [3]. In questo caso due tipi di end-

effector raccoglitore (uno per il distacco per torsione ed uno con un dispositivo di taglio rotante) sono stati

7

progettati perché, grazie a tecnologie future, potesse essere possibile sfruttare una mappa fotometrica in

riflettenza per evidenziare i frutti tra altri possibili obiettivi. Lavori più concreti nella direzione di un sistema

di raccolta autonomo sono stati fatti solo a partire dagli anni 80 grazie alle nuove potenzialità

dell’informatica conseguite in quel periodo.

Di seguito verranno indicate alcune tappe fondamentali per l’ottenimento delle tecnologie che costituiscono

lo stato dell’arte in ambito di raccolta automatica per il generico tipo di frutta:

MAGALI Project

Florida Citrus Picking Robot

Eureka Projects

Agribot Project

CRAM Citrus Picking Robot

Sono stati condotti altri progetti, soprattutto negli anni 90, ma costituiscono essenzialmente varianti di quelli

indicati sopra, con alcuni perfezionamenti delle soglie dei sistemi di processamento immagini e

l’introduzione di innovativi gripper flessibili, la cui discussione non è strettamente pertinente a questa tesi.

MAGALI Project

Una prima modellazione di sistema di raccolta automatica è stato sviluppato nel 1985 a Monpellier, in

Francia [12]. Nel caso di sperimentazione proposto una telecamera fissa in bianco e nero (B/W) era posta ad

osservare un intero filare per determinare le sole coordinare orizzontali a cui inviare un robot per la raccolta,

in grado di spostarsi autonomamente lungo il filare ma senza alcun tipo di controllo in retroazione.

Pochi anni più tardi lo stesso istituto di ricerca [13] ha sostituito la telecamera in bianco e nero con una a

colori montata direttamente sul robot in modo che le coordinate d’immagine ed il versore caratterizzante il

piano d’immagine fossero diretti esattamente come le coordinate di movimentazione del robot; in questo

caso per migliorare la stima della profondità in presa è stato introdotto anche un sensore di prossimità ed il

prototipo è stato testato per la raccolta di mele gialle. I risultati osservati sono stati un’identificazione del

50% dei frutti dei quali il 75% è stato raccolto correttamente (con picciolo) in un tempo medio di poco

superiore ai 4 secondi.

Florida Citrus Picking Robot

Il problema del sistema di linea visuale utilizzato nel MAGALI project era il fatto che, tra le fasi di visione e

quella di raccolta, il sistema fosse cieco e quindi in nessun modo guidato nella fase di avvicinamento (di

conseguenza estremamente vulnerabile a spostamenti del frutto per vento o movimento delle fronde).

In [14] viene proposto l’utilizzo, insieme ad una telecamera a colori (per valutare il contrasto cromatico) sul

giunto sferico dell’end-effector, di un trasduttore ultrasonico per mitigare questi effetti nel corso

8

dell’avvicinamento. L’identificazione riscontrata è stata di circa il 75%, con un tempo medio di presa attorno

ai 7 secondi a causa della complicazione aggiuntiva rispetto al modello precedente.

Eureka Projects

Team di ricerca spagnoli e francesi hanno collaborato in [15] all’implementazione di un innovativo sistema a

gripper idraulico per la raccolta di agrumi. La telecamera, in questo caso, era posizionata al centro del

manipolatore ma il vero sviluppo è stata l’introduzione di un nuovo sistema di identificazione d’immagine.

Una singola telecamera in bianco e nero è stata testata con interposizione di filtri ottici tali da permettere il

passaggio della sola luce a lunghezze d’onda tra 635nm e 560 nm. È stato utilizzato anche un sistema di flash

ad intermittenza per garantire un’illuminazione analoga nei diversi casi.

Lo studio ha evidenziato che utilizzare bande cromatiche specifiche porta ad identificazioni più precise

(90%) rispetto a quelle ottenute per semplice contrasto di colore. Non sono stati affrontati né risolti problemi

di occlusione della visuale e gli effetti negativi del mancato controllo nel percorso.

Agribot Project

Una equipe spagnola si è occupò di sviluppare in [16] una macchina raccoglitrice ibrida con meccanismi

automatici combinati al contributo umano. In particolare due bracci raccoglitori con gripper ad aspirazione

pneumatica furono montati su di un veicolo guidato da un operatore.

Ogni manipolatore si muoveva su 3 gradi di libertà: un giunto prismatico verticale e due rotativi ad asse

verticale (a questi si aggiungevano i due assi di rotazione propri dell’end-effector).

L’algoritmo di presa sfruttava sensori a telemetria laser per la stima delle coordinate sferiche del frutto e

sensori di profondità ad infrarossi per gestire la presa.

Il tempo medio di presa, una volta posizionata la macchina in un punto opportuno dei filari, era di circa 2

secondi ma sono stati riscontrati non pochi problemi di interazione del sensore laser con elementi riflettenti

ed illuminazione. La necessità del contributo umano si è dimostrata ineliminabile in quanto, ancora in

assenza di un sistema di controllo, l’avvicinamento ai rami della pianta era principalmente manuale.

CRAM Citrus Picking Robot

Un progetto di raccolta degli agrumi è stato proposto anche in Italia dall’Università di Catania [17]. Un

semplice manipolatore Cartesiano montato su di una piccola ruspa veniva movimentato con azionamenti

pneumatici per addentrarsi nelle chiome degli alberi. Un interessante passo avanti è stato fatto per quanto

riguarda il sistema di visione, in questo caso un modello RGB di cui veniva sfruttata la gamma RG per

l’identificazione dei frutti dallo sfondo. La stima della distanza del frutto avveniva attraverso la conoscenza

di valori stimati del diametro e, durante la fase di avvicinamento, corretta sulla base della sequenza di

immagini scattate (attraverso un filtro di Kalman a tempo continuo).

9

Il tempo totale di raccolta medio era, in simulazione, di circa 6 secondi ed il metodo era decisamente più

robusto dei precedenti rispetto a piccole variazioni di posizione del frutto. La realizzazione pratica ha

imposto tempistiche decisamente meno sostenibili a causa del tempo di elaborazione delle immagini scattate.

1.1.3 Tecniche di visione macchina diffuse

Nella breve panoramica dei progetti di raccoglitori automatici appena proposti sono state accennate, oltre alle

differenze dei sistemi di presa, anche diversi approcci al problema della stessa visione macchina.

Con visione macchina o machine vision si intende il sistema hardware di sensori utilizzato per fornire alla

macchina i dati da inviare ai software di processamento immagini per l’ottenimento di parametri utili

all’algoritmo di raccolta.

Le performance dei principali tipi di sensori impiegati in machine vision sono state valutate e confrontate da

Jimenez in [18]. Per una prima classificazione del tipo di immagini digitali raccolte ci si può riferire alle

seguenti categorie:

Segnali in intensità luminosa: in termine di modulo dell’emissione elettromagnetica osservata,

indipendentemente dal colore.

Segnali di spettro: in coordinate colore RGB (rosso verde blu) o, analogamente in segnali basati

sulla saturazione in coordinate HSL (tonalità, saturazione, intensità). Particolari casi di segnali in

spettro concettualmente analoghi a quelli cromatici ma non esprimibili nel campo del visibile sono

quelli ricavati dal thermal imaging ad infrarossi.

Segnali di telemetria laser: laser range finder a tempo di volo o, più raramente, a phase shift ed

interferometria.

A partire da queste categorie fondamentali si vanno ora a discutere particolari configurazioni hardware che

hanno trovato ampio utilizzo in letteratura e nei progetti di raccolta frutta citati in 1.1.2.

Schema monoculare

In [18] è ampiamente descritto l’utilizzo di schemi monoculari per la raccolta di agrumi; si tratta di un

sistema poco costoso sia dal punto di vista economico sia dal punto di vista del tempo computazionale.

L’immagine singola non è in grado di restituire la stima della profondità e per questo è stato spesso

affiancato ad altri tipi di sensori che ne integrassero le mancanze.

Nel MAGALI project [12,13] è stata dapprima implementata una telecamera fissa singola in bianco e nero

per la stima della posa basata sulla intensità della riflettenza luminosa del frutto nel solo piano immagine

(senza trattare la profondità). In seguito è stata utilizzata una telecamera a colori per migliorare la percezione

10

in casi di illuminazione variabile ed un sensore di prossimità per la sola fase di presa (si noti che nel percorso

non era comunque stimata la profondità).

Alle ricerche Florida Citrus Picking Robot [14] ed Eureka projects [15] si devono rispettivamente

l’introduzione di sensorizzazione infrarossa per la stima della profondità e l’introduzione di filtri passa banda

per effettuare un controllo colore, sfruttando la sola intensità da una telecamera in bianco e nero.

Il progetto CRAM Citrus Picking Robot [17] inroduce il sistema monoculare più sofisticato tra quelli

proposti, e sfrutta un’analisi spettrale del campo RG per impostare un vero e proprio controllo in

avvicinamento basato sulla dimensione stimata del diametro dei frutti.

Il sistema monoculare si è dimostrato versatile e di compatta ed efficiente implementazione, a patto di

risolvere i problemi di profondità e di scegliere un tipo di sensore o filtro opportuno per il tipo di raccolta.

Schema stereoscopico binoculare

Un metodo computazionalmente ed economicamente oneroso ma più preciso per la stima della profondità è

l’utilizzo di due differenti videocamere per sfruttare metodi di triangolazione tra le due immagini osservate

dai diversi punti di vista.

Un primo approccio a questo tipo di problemi, con avvicinamento non controllato, è stato proposto da

Kassay [19] nel progetto di raccolta ungherese AUFO. La triangolazione portava all’identificazione delle

coordinate spaziali grazie a due fotografie scattate in contemporanea dai diversi punti di vista. La diversità

delle condizioni di occultamento e forma dai diversi punti di vista costituì un problema di difficile soluzione,

tanto che gli esperimenti hanno portato alla corretta identificazione nel solo 41% dei casi.

Approcci binoculari più sofisticati, come quelli utilizzati nel recente [20] sfruttano la triangolazione dei due

punti di vista per una stima solo iniziale della profondità, ma la aggiornano in continuazione grazie ad

algoritmi di controllo basati sulla vista della telecamera in-hand in avvicinamento.

Gli approcci binoculari si sono dimostrati in grado di sostituire efficacemente gli analoghi approcci sensor

fusion monoculari ma, a causa della complessità computazionale, non esistono per ora casi applicativi di

sistemi di controllo in avvicinamento integralmente stereoscopici.

11

Fig. 6: Schema stereoscopico presentato in [20]

Schema a telemetria laser

In [18] viene anche presentato un metodo a telemetria laser per l’ottenimento in coordinate sferiche della

posizione degli obiettivi.

Questo tipo di metodi riconosce gli oggetti sulla base delle scansioni superficiali e della relativa attenuazione

della risposta luminosa; sulla base di avanzati sistemi di riconoscimento di posa spaziale è stato possibile

anche distinguere frutti maturi da quelli acerbi con una complessiva accuratezza di riconoscimento del 70%.

Il sistema implementato in Agribot project [16] dimostra una eccellente velocità di presa, anche se il

contributo umano è indispensabile per correggere alcuni difetti caratterizzanti questo metodo.

I laser range finder in condizioni di esercizio realistiche hanno dimostrato una certa vulnerabilità a problemi

di occlusione e riflessione su superfici particolarmente inclinate rispetto all’origine del fascio.

Fig. 7: Esempio in scala di grigi di stima laser della profondità (si notano errori di stima su superfici molto inclinate)

Possibili soluzioni implementabili prevedono la sovrapposizione delle letture da sensori laser multipli ma i

modelli di riconoscimento spaziale per sovrapporre i dati risultano al giorno d’oggi particolarmente onerosi.

12

Schema iperspettrale

Con il termine immagine iperspettrale si intende un’immagine digitale nella quale ogni elemento

dell’immagine (pixel) è costituito non da un solo numero o da una terna di numeri, come avviene per le

usuali immagini a colori (RGB), ma da un intero spettro associato a quel punto del bersaglio osservato.

L’insieme dei dati raccolti può dunque essere pensato come il cubo di dati contenente tante immagini

monocromatiche nelle quali, ad ogni pixel corrisponda l’intensità di emissione alla data lunghezza d’onda

Fig. 8: Struttura di un'immagine iperspettrale

L’utilizzo particolarmente dispendioso di questo tipo di dati permette di ottenere informazioni difficilmente

ottenibili altrimenti su difetti superficiali dei frutti e preciso stato di maturazione.

In Okamoto [21] sono state svolte sperimentazioni con discretizzazione monocromatica tra 369nm e 1042nm

con buoni risultati di riconoscimento ma tempi di calcolo insostenibilmente lunghi (si consideri che una sola

acquisizione d’immagine varia tra 22 e 65 secondi a seconda della risoluzione).

Visione termica

Ci sono stati tentativi [22] di determinare numero e diametro delle mele sugli alberi di un frutteto sfruttando

l’emissione di calore delle piante dopo una prolungata esposizione alla luce solare. Si è osservato che la

massima escursione di temperatura tra singoli frutti e chiome degli alberi era osservabile attorno alle ore

16:00 dei mesi opportuni alla raccolta.

Questo tipo di metodologia si è dimostrata, nelle finestre di tempo indicate, soddisfacente per la

localizzazione dei frutti ma, a causa degli incontrollabili effetti di ombre e scambi termici, non è stato

possibile ottenere una chiara stima dei diametri.

13

Sono promettenti eventuali sviluppi con sensor fusion di sensori temici e telecamere a colori, chiaramente i

costi di investimento crescerebbero di conseguenza.

1.1.4 Tecniche di analisi dell’immagine

Le tecniche di machine vision introdotte in 1.1.3 restituiscono immagini che è ancora necessario processare

per ricavare le informazioni che saranno utili all’algoritmo di raccolta.

In 9 sono descritte nel dettaglio le procedure di image processing necessarie all’ottenimento delle features

necessarie all’algoritmo proposto nel capitolo 2; in questa sezione si propongono le tecnologie più utilizzate

per identificare le zone del piano immagine corrispondenti ai frutti da utilizzare come obiettivo:

Analisi di colore (Color based): in questo caso vengono proposti valori di soglia ed indici per

segmentare rapidamente le immagini in aree utili. È comune anche l’utilizzo di filtri ottici fisici per

migliorare l’isolamento delle aree di interesse, questo metodo è stato per esempio utilizzato in

[15,22] dapprima con una telecamera in bianco e nero e poi a colori vantando il riconoscimento di

circa l’80% dei frutti.

Un metodo simile può essere applicato alle immagini iperspettrali ottenibili con metodi simili a

quelli descritti in [21], con opportune limitazioni alle lunghezze d’onda di interesse e alle

temperature specifiche per acquisizione di tipo termico.

Naturalmente, per approcci di tipo sensor fusion, occorrerà anche definire “pesi” per mediare le zone

sovrapposte nei diversi tipi di identificazione.

Analisi di forma (Shape based): esistono algoritmi adattativi per il riconoscimento di geometrie

definite a priori all’interno dell’immagine, uno dei più utilizzati è la trasformata di Hough (CHT)

che, per la raccolta di frutta, è conveniente utilizzare per forme circolari.

Il metodo sfrutta caratteristiche geometriche riconoscibili tra pixel che condividono caratteristiche

simili. In particolare curvature ed aree monocrome possono essere facilmente ricondotte a forme

interpretabili come ellissi o cerchi obiettivo.

Questo tipo di analisi, piuttosto dispendioso dal punto di vista computazionale, può essere ben

implementato anche su sistemi a telemetria laser come quello di Agribot project [16] anziché per

valutazioni fatte sui gradienti di profondità.

Approcci statistici: il problema del riconoscimento di oggetti obiettivo dall’immagine può essere

reinterpretato come un problema multivariato di ordine statistico per l’identificazione di pattern o

“cause” che qualifichino una particolare zona del piano immagine come area di interesse.

Sulla base di set di dati (raccolte di immagini) per le quali è nota a posteriori la presenza e le

coordinate degli oggetti obiettivo possono essere sfruttate le regole di classificatori ottimali di

14

parametri come quelli di Bayes per costruire regole probabilistiche in grado di identificare su nuove

immagini le zone di interesse con un determinato livello di confidenza.

I gruppi di ricerca degli Eureka projects [23] hanno utilizzato proprio questo tipo di tecnica con un

criterio discriminante di Bayes, in grado ottenere riconoscimenti corretti nel 90% dei casi sulla base

di una preliminare fase di apprendimento.

Approccio alle reti neurali: in modo analogo a quanto sperimentato in termini statistici sono stati

fatti tentativi per risalire alle cause del riconoscimento di pattern nell’immagine con la tecnica delle

reti neurali.

Nel progetto italiano AID, Grasso [24] ha sondato per esempio la possibilità di utilizzare un

algoritmo di retro propagazione (backpropagation) dell’errore in una rete neurale multilivello (con

più di 2 layer di neuroni nascosti tra gli strati di input ed output) per la segmentazione di immagini di

alberi d’arancio. I risultati sono stati positivi considerando l’88% dei riconoscimenti corretti ma, allo

stato attuale, gli stessi autori riconoscono che il metodo sia troppo oneroso dal punto di vista

computazionale per un utilizzo pratico.

15

1.2 Il sistema di asservimento visuale

Nella precedente sezione 1.1 sono stati discussi, oltre ai pregi, anche i difetti delle principali tecniche

meccanizzate per la raccolta di frutta. Si è visto in sostanza che i sistemi di mechanical harvesting non

consentono di effettuare una raccolta precisa e spesso danneggiano le piante in modo più o meno grave.

I principali problemi dei metodi di automatic harvesting per frutti singoli sono invece: la mancanza di

produttività nel caso delle tecnologie dai più elevati costi computazionali e la “cecità” con conseguente

mancanza di robustezza nel caso di quelle che non prevedono sistemi di controllo in retroazione.

Il tentativo fatto in questa tesi è stato quello di sviluppare un metodo di automatic harvesting che fosse un

compromesso tra robustezza ed efficienza. Ciò ha portato all’utilizzo di un sistema in retroazione che

sfruttasse in modo versatile il minimo quantitativo di sensori. Per la sua ricchezza di contenuti, il segnale di

una videocamera è quello che si presta maggiormente al controllo di tutte le diverse operazioni.

Questo approccio è noto in letteratura come asservimento visuale o visual servoing, l’obiettivo di un sistema

di asservimento visuale è infatti quello di sfruttare le immagini acquisite da una (visione monoculare) o più

(visione stereo) telecamere per controllare il movimento del robot a cui esse sono associate. In questa sezione

verranno motivate le scelte fatte per il particolare schema di controllo utilizzato.

1.2.1 Punto di vista della telecamera

L’utilizzo di una sola telecamera è più economico e di più semplice implementazione, per questo si è scelto

tale tipo di soluzione. Per i robot manipolatori esistono due soluzioni per quanto riguarda la configurazione

fisica del sistema [25]:

configurazione con telecamera mobile (“eye-in-hand”), in cui la telecamera è fissata sul robot (Fig.

9.a);

configurazione con telecamera fissa (“eye-to-hand”), in cui la telecamera è installata su di una base

fissa rispetto alla posizione di montaggio del manipolatore (Fig. 9.b).

Fig. 9: Configurazione "eye-in-hand" (A) e "eye-to-hand" (B)

(a) (b) Telecamera

Braccio manipolatore

Obiettivo

16

La configurazione “eye-to-hand” permette alla telecamera di avere un campo visivo costante durante

l’esecuzione del compito da parte del manipolatore, tuttavia è possibile che esso, muovendosi, si ponga tra la

telecamera e l’obiettivo, facendo sì che la telecamera non possa più fornire indicazioni adeguate a

movimentare il robot. Nella configurazione “eye-in-hand” invece, il campo visivo della telecamera varia

durante il moto con la possibilità che l’oggetto obiettivo esca dal campo visivo, tuttavia questo layout

consente di evitare che l’oggetto venga nascosto alla telecamera dal manipolatore, e permette ,in generale,

un’accuratezza migliore del controllo. Per questo motivo, la configurazione “eye-in-hand” è stata ritenuta la

più adatta al problema in questione.

1.2.2 Processamento d’immagine

Le foto scattate dalla telecamera devono essere opportunamente processate al fine di individuare ed estrarre

le caratteristiche (“features”) di interesse: tale procedimento è detto processamento d’immagine (image

processing). Solitamente le caratteristiche che si vogliono identificare dalle immagini sono grandezze

semplici, come coordinate di punti e parametri caratteristici di quadrati, rettangoli o ellissi; tutte grandezze

le cui informazioni possono essere riassunte in pochi valori.

Nel caso in esame, ad esempio, si è scelto di individuare dall’immagine le macchie di colore direttamente

associabili ai frutti da raccogliere. Una volta isolate queste aree, è stato possibile sceglierne una come

obiettivo da raggiungere e, mediante procedure descritte in Appendice 9, approssimarla ad un’ellisse che ne

sintetizzasse così i parametri spaziali.

Considerando la natura degli obiettivi sarebbe anche stato possibile scegliere una sfera come in [20] ma,

come discusso nel capitolo 6 relativo alla sperimentazione ciò avrebbe reso il metodo più vulnerabile a

problemi di occultamento.

Fig. 10: Rappresentazione dei dati post image processing per il riconoscimento di una singola mela

17

L’ellisse raffigurata in Fig. 10 rappresenta l’oggetto obiettivo per l’algoritmo ed i suoi parametri (centroide,

asse maggiore, asse minore, angolo di inclinazione dell’asse maggiore rispetto all’orizzontale) costituiscono

le features stimate dall’immagine (le dimensioni sono ovviamente espresse in pixel).

Il processamento dell’immagine descritto in Appendice 9 prevede anche un “filtro” in grado di escludere

regioni troppo piccole (rappresentanti disturbi o oggetti troppo lontani) e, potenzialmente, non sarebbe

eccessivamente complicato aggiungere un sistema di categorizzazione in una lista di priorità per obiettivi

multipli da raccogliere. Dato che questa tesi riguarda principalmente l’implementazione e la sperimentazione

in ROS dell’algoritmo che controlla il robot, si è deciso di trascurare quest’ultimo aspetto, semplificando il

problema con l’ipotesi di fondo che vi sia un unico frutto da raccogliere per volta.

1.2.3 Schemi di asservimento visuale

Vi sono tre approcci differenti al problema di asservimento visuale:

Controllo visuale nello spazio operativo (Position-Based-Visual-Servo, PVBS )

Controllo visuale nello spazo delle immagini (Image-Based-Visual Servo, IBVS)

Controllo ibrido

Position-Based-Visual-Servo, PVBS

Il primo schema di controllo (Fig. 11) utilizza le features estratte dalle immagini acquisite per stimare la posa

dell’oggetto rispetto alla telecamera ( , il robot quindi, si muove in modo da raggiungere la posa

desiderata ( della telecamera rispetto all’oggetto. Il controllo viene eseguito in coordinate cartesiane

(spazio di lavoro tridimensionale). Questo schema, agendo nello spazio operativo, consente alla telecamera

di eseguire una traiettoria teoricamente ideale.

Un passaggio importante in questo caso sarebbe dunque la stima dell’errore di posa rispetto ad una ideale

configurazione obiettivo precedente all’attuazione del robot.

È importante sottolineare che ciò che avviene in questo caso sul piano immagine non ha influenza diretta sul

moto ed è quindi possibile che la telecamera perda di vista l’obiettivo.

Fig. 11: Schema del controllo visuale nello spazio operativo

-

+

CONTROLLORE MANIPOLATORE TELECAMERA

STIMA

POSA

18

Image-Based-Visual Servo, IBVS

Il secondo schema (Fig. 12) utilizza direttamente le features immagine ( ) senza stimare la posa della

telecamera rispetto all’oggetto per movimentare il robot. La posa relativa di telecamera ed obiettivo è

definita implicitamente tramite i valori delle features immagine nella posa desiderata ( ). Il controllo è

effettuato nello spazio delle coordinate immagine (spazio bidimensionale).

Il vantaggio di questo secondo schema di controllo è che, agendo direttamente nel piano immagine, è

possibile fare in modo che l’oggetto non esca mai dal campo visivo della telecamera. D’altra parte lo

svantaggio è che la traiettoria richiesta alla telecamera potrebbe risultare non ottimale o addirittura non

attuabile dal robot a causa della presenza di singolarità o superamento dei limiti di giunto.

Fig. 12: Schema del controllo visuale nello spazio delle immagini

Controllo ibrido

Esiste un terzo approccio, che permette di unire i vantaggi dei due schemi appena presentati e viene definito

controllo visuale ibrido. Questo schema si basa su un errore che viene definito in parte nello spazio operativo

ed in parte nello spazio dell’immagine, ciò permette di avere un maggiore controllo sulla traiettoria seguita

dalla telecamera. Tuttavia, la presenza di componenti di errore definiti dello spazio delle immagini, aiuta ad

evitare che l’oggetto obiettivo esca dal campo visivo della telecamera. Proprio per queste sue caratteristiche,

è questo il tipo di schema di controllo scelto per la risoluzione del problema affrontato.

Tramite analisi dello stato dell’arte dei sistemi di asservimento visuale presenti in letteratura, si è scelto di

implementare un sistema di controllo visuale ibrido di tipo disaccoppiato [20], che unisce i vantaggi dei due

schemi elementari di asservimento visuale [26].

-

+

CONTROLLORE MANIPOLATORE TELECAMERA

MISURA

FEATURES

19

1.3 Scelte e premesse per l’algoritmo proposto

Nelle sezioni precedenti sono stati introdotti alcuni concetti di base che hanno portato a scelte

particolarmente importanti per lo sviluppo dell’algoritmo.

Perché l’algoritmo ottenuto sia accurato, non dannoso per le piante ed innovativo si sceglie di

implementare un sistema di raccolta per frutti singoli (Automatic harvesting 1.1.2).

Perché il robot sia autonomo nelle fasi di raccolta dovrà essere dotato di piattaforma mobile.

Perché l’algoritmo sia robusto rispetto alle difficili condizioni riscontrabili in un frutteto reale è

indispensabile che la fase di avvicinamento avvenga in controllo.

Per mantenere bassi i costi economici e computazionali, dovendo scegliere un unico sensore per il

controllo, risulta ottimale la scelta di una telecamera a colori (con segnale in RGB 1.1.3).

Tra tutti i metodi di acquisizione e processamento immagine, per tempo di elaborazione e reale

attuabilità, viene scelta una analisi di colore da segnali di spettro 1.1.4

Per motivi di costo e semplicità di implementazione si sceglie un sistema a telecamera monoculare.

Per minimizzare le possibilità di coprire e perdere l’obiettivo si sceglie un sistema di montaggio

della telecamera (Fig. 9.a) di tipo in-hand 1.2.1.

Il sistema di processamento immagini deve ricavare ad ogni iterazione un’ellisse associata

all’obiettivo e caratterizzata dalle seguenti features :centroide, asse maggiore, asse minore, angolo

di inclinazione dell’asse maggiore rispetto all’orizzontale 1.2.2.

Si sceglie uno schema con sistema di controllo visuale ibrido di tipo disaccoppiato per rotazione e

traslazione 1.2.3.

Ulteriori specifiche per l’utilizzo pratico di un robot con i requisiti di sopra nel mondo reale verranno

discusse nell’ultima sezione della trattazione sperimentale, capitolo 6.

Per l’implementazione dell’algoritmo si è considerato il robot KUKA YouBot (Fig. 13), dotato di piattaforma

mobile omnidirezionale e di braccio manipolatore a cinque gradi di libertà. Combinandolo con una semplice

webcam vincolata all’ultimo giunto si riescono a realizzare pienamente le condizioni sperimentali scelte.

Fig. 13: Kuka YouBot

20

Chiaramente, nelle fasi di simulazione Matlab (capitolo 3), Simulink e Vrep (capitolo 5) occorrerà costruire

elementi fittizi in grado di rappresentare correttamente telecamera ed obiettivo sul robot la cui struttura verrà

modellata in modo solo schematico come descritto in 3.1.1.

Fig. 14: Modello cinematico del braccio del robot, si nota la presenza dell’oggetto obiettivo in rosso

21

2 Descrizione algoritmo

Utilizzando le informazioni raccolte dalla sola videocamera, porti il robot a raggiungere un oggetto

bersaglio (il frutto) rappresentato in questa fase preliminare da un ellissoide dal colore (rosso) facilmente

riconoscibile rispetto allo sfondo.

2.1 Descrizione dell’algoritmo

L’approccio scelto si compone di tre fasi principali, a loro volta suddivise in tappe descritte in seguito nel

dettaglio:

1. Ispezione preliminare: lo scopo è quello di portare l’oggetto arbitrariamente disposto nello spazio

all’interno del campo visivo del robot. Le tappe relative sono:

Routine di osservazione.

Image processing.

Arresto della routine secondo opportuni criteri.

2. Triangolazione: lo scopo è quello di stimare, rispetto alla telecamera, la profondità dell’oggetto e le

relative dimensioni (utili nella fase di controllo).

3. Avvicinamento controllato: il raggiungimento dell’obiettivo vero e proprio prevede il controllo

del movimento sulla base delle informazioni ricevute ad ogni istante dalla telecamera nel modo

seguente:

Controllo della velocità angolare desiderata per la videocamera

Controllo della velocità traslazionale

Applicazione nello spazio dei giunti di velocità che portino ad ottenere per telecamera ed

end-effector le velocità desiderate in precedenza.

L’oggetto obiettivo è dotato di caratteristiche geometriche di posa e di dimensioni proprie (non note a

priori), ai fini della soluzione che approssima l’obiettivo ad un ellissoide i dati che qualificano la dimensione

sono i seguenti, raffigurati in Fig. 15:

: lunghezza reale in metri dell’asse maggiore dell’ellissoide;

: lunghezza reale in metri dell’asse minore dell’ellissoide;

22

Fig. 15: Ellissoide che modellizza il frutto da raccogliere

I sistemi di controllo visuale necessitano di informazioni estrapolate dalle immagini, le cosiddette features

dell’immagine, che si ottengono tramite procedimenti di image processing. I dettagli sul processamento delle

immagini sono esposti in seguito, per ora si si ipotizza di conoscere ad ogni istante le seguenti grandezze:

che rappresenta la lunghezza in pixel dell’asse maggiore dell’ellisse nel piano immagine;

che rappresenta la lunghezza in pixel dell’asse minore dell’ellisse nel piano immagine;

che rappresenta il vettore delle coordinate nel piano immagine (in pixel) del centro

dell’ellisse, cioè il centroide.

Fig. 16: Vista della proiezione nel piano immagine

Piano immagine

23

L’algoritmo di controllo scelto sulla base di quanto descritto in [20] ha come variabili di controllo le velocità

angolari e traslazionali della terna di riferimento solidale alla telecamera. Il metodo di implementazione

usato è di tipo disaccoppiato, infatti sono separate le procedure di controllo per le 2 parti:

1. controllo rotazionale;

2. controllo traslazionale.

2.2 Sistemi di riferimento

Prima di descrivere le fasi elencate in 2.1 è opportuno fare una panoramica dei sistemi di riferimento che

verranno utilizzati nel corso dell’algoritmo ed alcuni legami tra di essi.

Sono due i principali sistemi di riferimento utilizzati: uno nel piano immagine della videocamera ed uno

nello spazio tridimensionale nel quale il robot si muove.

Disponendo dell’immagine scattata dalla videocamera, si possono conoscere, mediante le tecniche di image

processing descritte in appendice, le coordinate nel piano immagine del centroide (in Fig. 17 l’intersezione

degli assi dell’ellissoide in rosso) lungo e :

( 1 )

Si considera ora un sistema di riferimento tridimensionale solidale alla videocamera in hand ( ),

come mostrato in Fig. 17:

Fig. 17: Kuka YouBot e sistemi di riferimento

24

I vettori sono versori indicanti il sistema di riferimento fisso, la terna ( ) indica il

sistema di riferimento della telecamera in hand, e rappresentano gli assi nel piano immagine (che ha

come unità di misura i pixel) rispettivamente lungo e , infine il vettore rappresenta la posizione

stimata del centroide rispetto alla terna di riferimento della telecamera:

Si ricaverà ora il legame prospettico tra la posizione dell’oggetto sul piano dell’immagine e quella nel

sistema di riferimento solidale alla videocamera.

Ciò che si vuole esprimere è il legame tra e in modo da ricavare a partire da immagini scattate

dalla videocamera. È evidente che nel piano immagine le coordinate sono solamente 2, quindi occorre

innanzitutto espandere il vettore associando un valore, corrispondente alla profondità, unitario:

Occorre normalizzare anche in modo che abbia e quindi si possa confrontare prospetticamente

con . Il vettore viene indicato con e viene scritto nel seguente modo:

Non rimane che sfruttare la relazione tra coordinate nel piano immagine (u,v) e coordinate nel sistema di

riferimento della telecamera ( ) tale per cui:

( 2 )

Dove rappresenta la matrice dei parametri intrinseci della telecamera ottenibili mediante calibrazione della

stessa:

25

In cui e rappresentano le dimensioni dei pixel rispettivamente lungo e lungo ; e

rappresentano rispettivamente le coordinate sul piano immagine (in pixel) del centro della telecamera; infine

indica la distanza focale della telecamera.

Si ricava ora dalla ( 2 ):

Il vettore rappresenta dunque le coordinate normalizzate sulla profondità del centroide rispetto alla terna

solidale alla telecamera.

Ai fini del controllo rotazionale, non è tanto importante il modulo di , quanto la sua direzione; è lecito

dunque procedere ad un’ulteriore normalizzazione di tale da renderlo unitario (il che sarà particolarmente

utile per definire la grandezza descritta in seguito):

In cui rappresenta il modulo di .

Si definiscono ora 3 grandezze propedeutiche al controllo in rotazione descritto in seguito:

come il prodotto vettoriale (indicato dall’operatore ’ ’) tra ed il versore lungo

(Fig. 19):

Il vettore ha modulo uguale al seno dell’angolo compreso tra i due vettori in quanto entrambi di

modulo unitario.

Geometricamente questo prodotto può essere visualizzato come l’area del parallelogramma costruito

sui due vettori unitari; più tenderà ad essere allineato alla direzione minore sarà il modulo di

, sempre uscente dal piano su cui giacciono gli altri due vettori (Fig. 18).

Fig. 18: Prodotto vettoriale tra e

26

come versore dell’asse di rotazione (Fig. 19):

come angolo di rotazione attorno a che porterebbe il versore di a coincidere con (angolo

compreso tra e ):

Fig. 19: Immagine esplicativa di e

Come si è detto è perpendicolare al piano identificato dai vettori e e rappresenta l’asse di rotazione

per : l’obiettivo del controllo rotazionale è quello di annullare l’angolo , il che porterebbe a coincidere

con , cioè avere la telecamera che punta perfettamente il centroide (Fig. 19).

Per il controllo in traslazione, una grandezza importante da definire è che è la stima di

, l’effettiva

distanza dalla telecamera al centroide lungo quando (Fig. 20).

Fig. 20: Distanza tra telecamera e centroide

27

Per determinare la formula di si ricorre alla relazione prospettica schematizzata in Fig. 21

Fig. 21: Schema della relazione prospettica

Il segmento di lunghezza [m], viene proiettato sul piano immagine come il segmento [pixel].

Moltiplicando per (dimensione caratteristica dei pixel), si ottiene la lunghezza della proiezione in metri.

Si nota che i triangoli e sono simili, avendo l’angolo in comune; si può quindi scrivere:

( 3 )

Dalla ( 3 ) si ricava :

( 4 )

Questa relazione prospettica vale per entrambi i diametri dell’ellisse:

( 5 )

( 6 )

Se la telecamera fosse posta esattamente davanti all’ellissoide con il piano immagine parallelo al piano

formato dagli asse maggiore e minore dell’ellissoide e ne puntasse il centroide, basterebbe utilizzare una sola

di queste due relazioni per stimare adeguatamente la profondità. Tuttavia, queste condizioni potrebbero non

Piano

immagine

B

C

D

E

28

essere rispettate durante il movimento. Per ridurre l’errore sulla stima della profondità che si avrebbe

utilizzando solo una delle due relazioni, quindi, si decide di eseguire una media tra le due stime definite nella

( 5 ) e nella ( 6 ), ottenendo la seguente relazione:

( 7 )

2.3 Ispezione Preliminare

Come è stato accennato la prima fase dell’algoritmo consiste nel portare l’oggetto di interesse nel

campo visivo dell’immagine. In particolare, per necessità legate a fasi successive, occorrerà portare

il centroide dell’oggetto già nella vicinanza del centro dell’immagine (entro una certa zona di

tolleranza).

2.3.1 Routine di osservazione

Nella fase iniziale il robot e la telecamera (solidale all’ultimo giunto) si trovano in una posizione di “riposo”

e, nella maggioranza dei casi, non è immediatamente possibile visualizzare l’oggetto obiettivo sul piano

immagine. Per questo motivo occorre definire una routine di movimentazione tale da rendere possibili le fasi

successive dell’algoritmo.

I requisiti per una buona routine di osservazione sono i seguenti:

deve permettere al campo visivo della telecamera di spaziare in tutte le possibili direzioni di raccolta

attorno al robot (è importante non avere punti ciechi per non mancare l’obiettivo)

deve essere veloce nel raggiungere la posizione desiderata (evitando movimenti inutili e senza

ripercorrere zone di ricerca già sondate)

deve rispettare i vincoli di massima escursione dei giunti del robot

deve essere possibilmente di facile implementazione (comandi in cinematica diretta sono

computazionalmente più economici di complesse traiettorie per punti in cinematica inversa)

A fronte delle necessità di cui sopra è stata proposta una procedura che sfrutta in cinematica diretta due soli

gradi di libertà dello specifico robot utilizzato (YouBot): il primo giunto di rotazione attorno all’asse

29

verticale ed il quarto giunto, che ha la funzione di alzare progressivamente il campo visivo una volta

completata ogni escursione tra i limiti estremi del primo grado di libertà (Fig. 41).

Il robot procede in pratica ruotando (per tutta l’escursione possibile o per un angolo imposto) ripetutamente

attorno alla base, alzando ad ogni nuova rotazione il campo visivo della telecamera grazie al quarto giunto.

Per permettere di esplorare ogni posizione visibile è stata impostata, per gli altri gradi di libertà, una posa che

permettesse di avere l’end-effector (e quindi la telecamera) approssimativamente centrato sull’asse di

rotazione del primo giunto (è stato dimostrato empiricamente che, come ragionevole aspettarsi, ciò

minimizza possibili punti ciechi).

I dettagli concernenti movimentazione angolare delle successive iterazioni sarà descritta nel dettaglio nella

sezione di implementazione Matlab dell’algoritmo.

2.3.2 Image processing

I dettagli dell’algoritmo di processamento immagine sono chiariti in Appendice 9, per il momento è

importante chiarire quali siano i parametri di interesse per il ciclo di osservazione:

Viene introdotta una variabile booleana che indica semplicemente il fatto che vi sia o

meno un certo numero di pixel nell’immagine associabili per colore all’oggetto obiettivo (se almeno

una certa parte dell’oggetto è nel campo visivo viene restituito 1).

Se è soddisfatta la condizione sulla presenza di una porzione sufficiente dell’oggetto nell’immagine

scattata vengono calcolate le coordinate del centroide .

Le immagini vengono scattate periodicamente durante le rotazioni del primo giunto, con spaziatura tale da

non sondare in modo eccessivo zone già visionate. Si è verificato che, al fine di minimizzare i passaggi di

rotazione del quarto giunto (di innalzamento) è buona cosa ruotare di 90° la telecamera (utilizzando il quinto

giunto) in modo da avere in campo visivo più ampio in direzione verticale.

2.3.3 Arresto e criteri di uscita dall’osservazione

Volendo impostare la fase di osservazione come un ciclo da interrompere appena ottenuta una condizione

accettabile per la continuazione dell’algoritmo è necessario progettare opportune condizioni di uscita dalla

routine.

30

Sulla base delle necessità applicative sono stati scelte le seguenti regole per le iterazioni (devono valere

contemporaneamente altrimenti l’ispezione termina):

L’ispezione può continuare finché l’angolo di inclinazione dell’end-effector rispetto al suolo è

minore di 90° (finché la telecamera non ha ripreso tutto dal terreno fino allo zenit)

L’ispezione può continuare finché la variabile booleana è diversa da 1 oppure finchè la

distanza del centroide dal punto di centro immagine O è maggiore di una determinata tolleranza in

pixel ;

Sono essenzialmente possibili due uscite dalla ricerca in questo modo: la prima uscita nel caso di oggetto non

osservato (perché non presente, troppo piccolo o lontano) e la seconda che termina con il robot nella

posizione tale da soddisfare le condizioni desiderate sul piano dell’immagine.

31

2.4 Triangolazione

Per estrapolare informazioni sulla distanza lungo l’asse z a cui si trova un oggetto tramite foto provenienti da

una videocamera è necessaria l’acquisizione di almeno due immagini scattate da punti di osservazione

differenti dei quali si conoscono le posizioni relative.

Tale metodo, detto triangolazione, ha trovato storicamente ampio utilizzo in ambito navale e civile ed è ben

noto in letteratura.

Fig. 22: Esempio di triangolazione standard

Per conoscere la distanza della barca (Fig. 22), noti gli angoli e e la distanza l che unisce i punti da cui

sono stati misurati gli angoli, si utilizza la seguente formula:

Nel caso del problema di raccolta frutta, deve essere calcolata la profondità relativa al centroide in modo

analogo. Solo successivamente, sulla base di considerazioni prospettiche, sarà possibile stimare le

dimensioni reali dell’oggetto osservato per capire se e, in caso affermativo, come, procedere alla fase di

raccolta.

Dalla formulazione classica della triangolazione si evidenzia la necessità di scattare due fotografie del

centroide spostando la telecamera di una distanza nota ( ) ma, a causa della fase di ispezione che ha

portato il frutto all’interno del campo visivo si presenta una complicazione: non è possibile conoscere a

priori la posizione in cui si è arrestato l’end-effector (e quindi la telecamera), per questo risulta non banale

impostare in cinematica inversa una traiettoria che si presti alla triangolazione in un caso qualsiasi.

32

Si propone ora un metodo geometrico che ridefinisce la classica triangolazione per risolvere questo

problema: anziché operare uno spostamento lineare se ne sceglie uno angolare di rotazione ottenuto

movimentando il quarto giunto del robot in cinematica diretta.

Il valore di spostamento imposto è indipendente dalla posizione di arresto della fase di ispezione e risulta

sicuramente possibile, a causa della condizione di vicinanza al centro immagine implementata in precedenza

(per spostamenti angolari piccoli l’oggetto non lascia sicuramente il campo visivo e non è possibile

raggiungere i limiti di escursione dei giunti per come è stata impostata la posizione di ispezione).

Prima di procedere è doveroso chiarire le ipotesi alla base di alcune approssimazioni nell’applicazione

pratica del modello:

1. L’angolo di rotazione imposto deve essere piccolo: ciò non è solo necessario a mantenere

l’oggetto nel campo visivo ma serve anche a non commettere errori di stima sulla profondità in

quanto il secondo punto risulterebbe in realtà spostato in direzione z di

; si

assume questo errore trascurabile (Fig. 23).

Fig. 23: Punti di triangolazione

2. Lo stesso deve essere di dimensione sufficiente perché non ci siano problemi imputabili alla

dimensione finita dei pixel (per oggetti lontani e pixel grandi si corre il rischio di non poter

apprezzare correttamente lo spostamento sul piano immagine)

Una serie di prove in svariate condizioni operative ha portato a risultati sempre soddisfacenti con un angolo

che quindi verrà utilizzato per le analisi.

Punto 2

Punto 1

33

L’angolo scelto, circa 6°, porta a spostamenti di circa 22 mm considerando la lunghezza del giunto

movimentato, il che costituisce un buon compromesso per precisione di stima della profondità (

; si ricorda peraltro che la parte di controllo finale correggerà gli errori di profondità nel corso della

movimentazione.

2.4.1 Stima della profondità

Sulla base dello schema in Fig. 24 si riporta ora il percorso di ottenimento degli angoli e per poter

ricavare sfruttando i concetti alla base della formula di triangolazione precedentemente scritta:

Fig. 24: Schema di triangolazione

Si procede al calcolo degli angoli utilizzando le seguenti formule (considerando positivi angoli antiorari

rispetto all’asse congiungente Punto_1 e Punto_2):

z

Punto 2

Punto 1

34

In cui le lunghezze e sono state ottenute moltiplicando per le distanze in numero di pixel tra la

coordinate in pixel lungo delle proiezioni dei punti di interesse e il centro dell’immagine. Gli angoli e

non sono riportati in Fig. 24 ma sono gli angoli formati dal giunto rispetto alla verticale nelle due posizioni

corrispondenti alla triangolazione standard in Fig. 22. Si osserva che l’angolo entra correggendo per

compensare la rotazione subita dalla telecamera e quindi dal campo visivo.

Dalla Fig. 23 si aveva inoltre:

La distanza viene infine calcolata con la seguente formula:

2.4.2 Stima dei asse maggiore e minore

Per la stima degli assi maggiore ( ) e minore ( ) dell’ellissoide si deve disporre delle coordinate dei

vettori che identificano la posizione dei punti estremi degli assi (discusso in appendice insieme al processa

mento d’immagine). Si mostra in Fig. 25 la posizione di tali punti nelle coordinate pixel e :

Fig. 25: Punti per la stima degli assi

Si utilizza ora la relazione prospettica precedentemente scritta per passare alle coordinate normalizzate sulla

profondità dei quattro punti sopra raffigurati:

35

Disponendo della distanza dei punti ottenuta con la triangolazione (si assume che i quattro estremi siano alla

stessa profondità del centroide rispetto all’end-effector) si ottengono le coordinate rispetto alla terna di

riferimento ( ) come segue:

Si ricavano ora gli assi maggiore e minore stimati dell’ellissoide utilizzando la formula per trovare la

distanza tra due punti in uno spazio tridimensionale:

Dato che il frutto in esame non presenta eccentricità particolarmente pronunciate si trascura per questa fase

l’ottenimento dell’angolo di posa dell’ellissoide nello spazio e ci si limita a valutare le dimensioni che

saranno utilizzate per la prosecuzione.

36

2.5 Controllo in avvicinamento

Si procede ora ad impostare l’algoritmo di controllo sulla base del disaccoppiamento dei gradi di libertà

rotazionali e traslazionali; è importante osservare che questa parte di algoritmo si occupa prettamente del

raggiungimento dell’obiettivo da parte della sola telecamera indipendentemente da ciò che la movimenta.

Solo nell’ultima fase di attuazione i risultati ricavati per la telecamera avranno influenza sullo specifico

robot.

2.5.1 Controllo rotazionale

Tenendo a mente le grandezze definite nella sezione “Sistemi di riferimento” si definisce l’errore in rotazione

come segue:

( 8 )

Volendo utilizzare come variabili di controllo le velocità angolari della videocamera definite dal vettore

con un controllore PD, si può scrivere:

( 9 )

Dove è la derivata dell’errore rispetto al tempo:

( 10 )

mentre e sono rispettivamente le costanti di controllo dell’azione proporzionale e derivativa del

controllo rotazionale.

Esiste un legame tra e [27], ma per ricavarlo ai fini di utilizzarlo nella ( 9 ) è necessario introdurre

alcune grandezze e definire le seguenti proprietà.

Matrice di Rodrigues:

La rotazione attorno al versore dell’angolo può essere espressa attraverso la matrice di rotazione

mediante la matrice di Rodrigues [28]:

37

( 11 )

In cui rappresenta una matrice identità

Proprietà 1:

L’asse di rotazione

è un versore, pertanto:

( 12 )

( 13 )

Matrice antisimmetrica:

La scrittura indica la matrice antisimmetrica relativa a quel vettore; ad esempio:

Proprietà 2:

Si introduce un vettore ; il prodotto è definito come segue:

( 14 )

Ne consegue che:

Se

per la ( 12 ) ( 15 )

Se

per la ( 12 ) ( 16 )

38

Proprietà 3:

si definisce la seguente proprietà:

( 17 )

Proprietà 4:

Moltiplicando a destra per ambo i membri della ( 14 ) si ottiene per la ( 17 ):

Ne consegue che rispettivamente per la ( 12 ) e la ( 13 ):

se

( 18 )

pertanto vale anche:

( 19 )

se

ora, per la ( 16 ):

infine, per la ( 17 ):

( 20 )

Proprietà 5:

Un’ulteriore proprietà da introdurre per la trattazione è la seguente:

( 21 )

Proprietà 6:

L’ultima relazione da definire si ottiene moltiplicando a destra per ambo i membri della ( 15 ):

39

che diventa per la ( 13 )

( 22 )

infine, cambiando di segno la ( 22 ) si ottiene:

( 23 )

Tensore di velocità angolare:

Occorre inoltre tener presente che qualsiasi vettore

(di modulo costante) che ruota con

velocità angolare

, soddisfa la seguente relazione:

( 24 )

Si introduce ora , inteso come il tensore di velocità angolare associato ad , rappresentato dalla matrice

antisimmetrica dello stesso.

Questo tensore agisce come se fosse un operatore del tipo ‘ ’, infatti vale la relazione:

( 25 )

Sostituendo la ( 25 ) nella ( 24 ), si può quindi scrivere la seguente formula:

Estendendo l’equazione sopra scritta si può sostituire ad la matrice di rotazione definita nella ( 11 ),

considerando che la velocità angolare dei tre vettori colonna che costituiscono deve essere la medesima. Si

ricava quindi la seguente formula:

( 26 )

Esplicitando dalla ( 26 ) si può dunque scrivere:

40

( 27

La matrice è una matrice di rotazione, si tratta quindi di una matrice ortogonale speciale, che gode di

alcune proprietà, tra cui:

( 28 )

Sostituendo la ( 28 ) nella ( 27 si giunge alla seguente scrittura:

( 29 )

Occorre ora passare dalla matrice antisimmetrica al relativo vettore che la determina; per far ciò si

esplicita il membro di destra della ( 29 ) tenendo conto della formula di Rodrigues ( 11 ):

( 30 )

( 31 )

Andando a sostituire la ( 30 ) e la ( 31 ) nella ( 29 ) si ottiene:

41

( 32 )

Grazie alla ( 18 ), ( 19 ), ( 20 ) e alla relazione fondamentale della trigonometria tale per cui:

si può riscrivere la ( 32 ) come segue:

( 33 )

infine grazie alla ( 21 ) si riscrive la ( 33 ) nel seguente modo:

A questo punto il passaggio da a è immediato; basta infatti sostituire al posto delle matrici

antisimmetriche e i rispettivi vettori che le determinano, ricavando la seguente formula:

( 34 )

Occorre manipolare ulteriormente la ( 34 ) per riuscire a determinarne il legame con . Per far ciò si

devono riscrivere e nel seguente modo:

( 35 )

( 36 )

facilmente dimostrabile utilizzando la formula di bisezione del seno (per ).

Andando a sostituire la ( 35 ) e la ( 36 ) nella ( 34 ) si ottiene:

( 37 )

42

Per ricavare il legame che esiste tra e occorre scrivere la ( 10 ) nel seguente modo:

( 38 )

moltiplicando per a sinistra ambo i membri dell’equazione ( 38 ) si ottiene:

( 39 )

da cui:

( 40 )

Si dimostra ora che , innanzitutto si consideri che, per la ( 23 ):

quindi:

ora, per la ( 15 ):

infine, per la ( 12 )

Ne consegue che la ( 40 ) può essere scritta come:

( 41 )

Moltiplicando per a sinistra ambo i membri dell’equazione ( 38 ) si ottiene:

43

Per la ( 15 ):

Infine, per la ( 12 ):

( 42 )

Cambiando di segno l’equazione ( 42 ) si ottiene:

( 43 )

Grazie alla ( 15 ) e alla ( 12 ) il membro di sinistra della ( 43 ) può essere scritto come segue:

( 44 )

Cambiando di segno la ( 44 ) si arriva a scrivere:

( 45 )

Si può ora andare a sostituire la ( 41 ) e la ( 45 ) nell’equazione ( 37 ), ottenendo:

e per la ( 18 )

( 46 )

Andando a sostituire l’equazione ( 10 ) nella ( 46 ) si ottiene l’espressione seguente, che mette in relazione

con :

44

( 47 )

Per semplicità si riscrive l’equazione ( 47 ) come segue:

( 48 )

con

Dalla formula ( 48 ) si ricava :

( 49 )

Rimane ora da determinare la forma analitica di . Per far ciò si procede andando a definire la struttura

della matrice :

( 50 )

con

( 51 )

Il determinante della matrice risulta essere:

( 52 )

Per proseguire la procedura che porta a determinare in modo analitico , occorre introdurre la matrice

, definita come l’inversa della matrice , ipotizzando che abbia la seguente forma:

( 53 )

Si può scrivere quindi che:

45

Si sa che moltiplicando una matrice per la sua inversa si ottiene un’identità; si scrive dunque:

( 54 )

Sfruttando le proprietà definite in ( 18 ) e ( 19 ) si può riscrivere la ( 54 ) come segue:

( 55 )

Affinché il membro di destra dell’equazione ( 55 ) rappresenti un’identità, devono valere le seguenti

condizioni:

Ciò porta alla scrittura matriciale del seguente sistema:

Di conseguenza si possono ricavare e nel seguente modo:

46

( 56 )

Andando ad inserire la ( 51 ) e la ( 52 ) nella ( 56 ) si ricava:

( 57 )

Andando a sostituire i valori della ( 57 ) nella ( 53 ) si conclude dunque che la matrice assume il seguente

valore:

Avendo ricavato il legame esistente tra e , si inserisce la ( 49 ) nella ( 9 ) per ottenere:

( 58 )

Finalmente si possono ricavare le velocità angolari da imporre alla telecamera dalla ( 58 ):

47

( 59 )

2.5.2 Controllo traslazionale

Si definiscono gli errori del controllo traslazionale come segue:

( 60 )

( 61 )

Dove rappresenta l’errore tra profondità desiderata ( ) e profondità stimata del centroide (

) lungo ,

mentre rappresenta il vettore composto dagli errori in pixel tra posizione desiderata e

posizione del centroide nelle direzioni e .

Le tre velocità traslazionali della telecamera lungo la terna che identificano le variabili di

controllo traslazionali sono rappresentate dal seguente vettore :

Volendo controllare la velocità lungo con un controllore PD, si scrive:

( 62 )

Dove e

sono rispettivamente le costanti di controllo dell’azione proporzionale e derivativa.

Derivando la ( 60 ) rispetto al tempo si ottiene:

( 63 )

Si sostituisce così la ( 63 ) nella ( 62 ) e si ottiene:

( 64 )

48

Ricavando dalla ( 64 ) si scrive:

( 65 )

Volendo controllare le velocità traslazionali e

lungo e (definite nel vettore ) con

un controllore PD, si scrive:

( 66 )

Derivando la ( 61 ) rispetto al tempo si ottiene:

( 67 )

Per ricavare la formula di , si deriva la ( 1 ) rispetto al tempo, ottenendo:

( 68 )

In cui e sono gli Jacobiani immagine che legano le velocità lineari e angolari della telecamera in hand

con le velocità del centroide; mentre indica l’effettiva profondità lungo del centroide. Dal momento

che traslazioni e rotazioni sono state disaccoppiate, si può eliminare in questa fase la velocità angolare ,

semplificando la ( 68 ) come segue:

( 69 )

Andando a sostituire la ( 69 ) e la ( 67 ) nella ( 66 ) si ricava:

( 70 )

49

Occorre precisare che (distanza lungo tra telecamera e centroide) non è nota, ma si dispone solo della

sua stima attraverso ; si riscrive quindi la formula ( 70 ) andando a sostituire la profondità

con ,

compensando l’errore introdotto sostituendo il guadagno derivativo con

:

( 71 )

Andando a ricavare dall’equazione ( 71 ) si ottiene la seguente scrittura:

( 72 )

2.5.3 Attuazione del robot

È stata ottenuta la velocità richiesta in termini rotazionali e traslazionali per la telecamera in hand, è ora

necessario sfruttare tali informazioni per controllare l’end-effector del robot fino al raggiungimento

dell’obiettivo.

Occorre innanzitutto considerare che la telecamera non deve necessariamente trovarsi in corrispondenza

dell’end-effector e anzi, a meno di particolari tipi di configurazione, è comune l’introduzione di una matrice

di rototraslazione che ne raccolga i cosiddetti parametri estrinseci (quelli della trasformazione che porta

l’end-effector a coincidere con la videocamera). La differenza di posizione potrebbe essere ininfluente per

pure velocità traslazionali ma comporta importanti conseguenze qualora, come nel caso in esame, vi siano

anche velocità rotazionali.

In particolare, per le velocità e calcolate, vale la seguente relazione:

( 73 )

Dove e rappresentano le velocità traslazionali e rotazionali dell’end-effector;

rappresenta la matrice di rotazione costante tra end-effector e videocamera; infine rappresenta

la matrice antisimmetrica del vettore che denota il vettore di traslazione costante sempre tra end-

effector e videocamera.

Tenendo conto della ( 73 ), ( 59 ), ( 65 ) e ( 72 ) si possono così esplicitare e nel seguente modo:

50

Per ottenere sul robot le specifiche velocità all’end-effector calcolate è necessario attuare velocità nello

spazio dei giunti che sono ricavabili sulla base dello jacobiano della macchina (definito sulla base del

posizionamento dei giunti al dato istante):

Dato che il solo braccio risulta sottoattuato rispetto ai 6 gdl complessivi il problema non può essere risolto

direttamente ed occorrerà limitarsi ai gradi di libertà consentiti operando un partizionamento della matrice

che verrà spiegato in dettaglio nel seguente capitolo 3.

2.5.4 Arresto e criteri di uscita dal controllo

Anche se in questa fase la trattazione dell’algoritmo è solo teorica è importante accennare al fatto che, al

momento di realizzazione simulata e sperimentale, occorrerà fissare criteri di arresto.

In particolare quattro saranno le possibili condizioni di uscita dal ciclo:

Errore di profondità minore di una predeterminata soglia: obiettivo raggiunto.

Superamento del numero massimo di iterazioni consentite al particolare tempo di iterazione:

superato il tempo massimo per la presa.

Uscita dell’oggetto dal campo visivo: obiettivo perso.

Raggiungimento di una singolarità cinematica che impedisca la presa o obiettivo fuori portata:

obiettivo irraggiungibile.

51

3 Simulazione in Matlab

L’ambiente di calcolo Matlab si presta particolarmente all’implementazione di sistemi di controllo che, come

quello proposto nel precedente capitolo 2, sfruttano ampiamente il calcolo matriciale.

Nel capitolo corrente verrà dunque utilizzato proprio il workspace della Mathworks per l’implementazione di

tutta la procedura di raccolta; questa non costituirà solo una prima simulazione fine a se stessa ma avrà,

oltretutto, ruolo propedeutico per le successive simulazioni e la sperimentazione finale sul robot reale.

Prima di procedere a descrivere la programmazione del codice è buona cosa indicare le tre componenti

software utilizzate per questo capitolo (la configurazione hardware utilizzata è descritta all’inizio del capitolo

6 di sperimentazione):

Matlab 2015R: l’ambiente di simulazione (i dettagli sono chiariti in Appendice A)

Robotics Toolbox 9.10: toolbox per modellazione e simulazione robotica scaricabile gratuitamente

dal sito ufficiale delle pubblicazioni di Peter Corke.

Machine Vision Toolbox 3.4: toolbox per la simulazione di dispositivi di visione per il controllo dei

robot; anche questo rilasciato gratuitamente da Peter Corke.

All’inizio di ogni simulazione è stato necessario attivare i toolbox eseguendo lo script “startup_rvc.m”

fornito insieme ai pacchetti di sopra; l’attivazione restituisce a schermo i messaggi in Fig. 26:

Fig. 26: Attivazione Machine vision e Robotics toolbox

A questo punto è stato possibile procedere alla modellazione vera e propria.

3.1 Modellazione del sistema

Occorre modellare tre oggetti: il robot, l’oggetto obiettivo (che rappresenta il frutto) e la telecamera.

A questo livello di implementazione ci si limita a trattare definizione e costruzione delle singole componenti

che parteciperanno alla simulazione, solo successivamente se ne descriverà l’interazione.

52

3.1.1 Modellazione del Robot in convenzione Denavit Hartenberg

Il Robotics toolbox offre ottimi strumenti per la modellazione cinematica di robot: in particolare, per definire

in modo univoco la configurazione spaziale dei giunti mobili del robot, sono state sfruttate funzioni basate

sulla convenzione di Denavit-Hartenberg.

La convenzione D-H è in sintesi una notazione compatta che, con la definizione di soli 4 valori, permette di

descrivere in modo univoco la posizione e l’orientamento relativo di un giunto all’interno della catena

cinematica costituente un robot.

Il problema della caratterizzazione viene ricondotto, secondo la convenzione, alle matrici di rototraslazione

che portano il sistema di riferimento associato all’i-esimo giunto a coincidere con quello relativo al giunto

successivo.

In Fig. 27 sono evidenziati i parametri necessari alla caratterizzazione dell’i-esimo link secondo i parametri

D-H.

Fig. 27: Rappresentazione dei parametri D-H

La procedura di caratterizzazione è descritta in [25] e si compone dei seguenti passaggi:

Selezione dell’asse coincidente con l’asse del giunto ;

Individuazione di , all’intersezione dell’asse , con la normale comune agli assi e

(a tale retta appartiene il segmento di minima distanza tra due rette). Con si indica

l’intersezione della normale comune con ;

Definizione dell’asse diretto lungo la normale comune agli assi e con verso

positivo dal giunto al giunto ;

Giunto i

Giunto i-1 Giunto i+1

53

Definizione dell’asse in modo da completare una terna levogira (secondo la “regola della

mano destra”).

Oss: la convenzione di sopra non risulta univoca per alcuni casi: per la terna 0 e la n+1 (primo ed ultimo

giunto) non sono definite rispettivamente le coordinate e l’la direzione di per questo possono essere

scelte arbitrariamente. Anche per assi consecutivi paralleli e prismatici si hanno problemi di univocità

dell’orientamento di . Queste informazioni arbitrarie possono essere utilizzate per semplificare la

caratterizzazione del robot su end-effector e assi consecutivi (sempre controllando il rispetto concettuale

del modello fisico).

Definite le terne, posizione ed orientamento della terna rispetto alla terna sono completamente

specificati dai seguenti parametri:

distanza di da ;

coordinata di su ;

angolo intorno a tra l’asse e l’asse , positivo in senso antiorario;

angolo intorno all’asse tra asse e l’asse , positivo in senso antiorario.

A seconda del tipo di giunto resta una diversa variabile di movimentazione non imposta dal metodo:

in caso di giunto prismatico, la varabile è ;

se il giunto è rotoidale, la variabile è .

Con i parametri inseriti sui link tra i giunti è possibile, in modo univoco, definire la matrice di

trasformazione tra giunti consecutivi (traslazione di lungo e rotazione attorno allo stesso asse)

come segue:

Dopo la prima rototraslazione è necessario applicarne una seconda (traslazione di lungo e rotazione

attorno allo stesso asse):

Sulla base delle due trasformazioni fatte si può, in modo compatto, scrivere la trasformazione complessiva

associata ad un singolo link. La variabile del giunto j viene nominata .

54

Dopo aver definito i parametri da utilizzare è stato possibile caratterizzare completamente braccio e

piattaforma di base dello YouBot che, per semplicità di gestione delle fasi successive verranno trattati

inizialmente in modo separato.

Caratterizzazione del braccio

Il braccio si compone di cinque giunti rotoidali e delle relative connessioni. I parametri definiti sopra per il

generico robot sono stati estrapolati per il caso specifico grazie alle quote rese disponibili dalla casa

produttrice (Fig. 28):

Fig. 28: Quote del braccio e relative escursioni

55

È stato possibile ricavare i parametri in Tabella 1:

d a

1 0.147 0.033

2 0 0.155 0

3 0 0.135 0

4 0 0

5 0.113 0 0

Tabella 1: Caratterizzazione DH del braccio

Il Robotics toolbox permette di comporre i legami tra giunti per mezzo del comando “Link” e di combinare

più link per costruire un intero robot grazie al comando “SerialLink”.

In Fig. 29 e Fig. 30 sono visibili metodo ed effetto dell’implementazione del braccio (si noti che, oltre ad i

parametri DH vengono anche definiti i limiti di escursione relativi ai giunti).

Fig. 29: Definizione Matlab del braccio

Oss: come si può notare, gli ultimi valori assegnati alla funzione “Link” sono sempre nulli; ciò corrisponde

nella sintassi del comando alla definizione di un giunto rotoidale (il valore 1 è invece caratteristico dei giunti

prismatici come si potrà osservare in Fig. 32) .

56

Fig. 30: Rappresentazione del braccio in coordinate (0;0;0;0;0) dei giunti

Caratterizzazione della piattaforma

Per la piattaforma di base si procede in modo essenzialmente analogo con la differenza che i giunti in esame

saranno di tipo

Fig. 31: Dati sulla base (non ci sono chiaramente limiti di escursione)

57

La tabella corrispondente ai movimenti della base nelle due direzioni; si trascura la rotazione che risulta

ridondante con la rotazione del braccio e, in esercizio, sarà limitata dallo stretto passaggio tra filari.

d a

X

0

Y

0

Tabella 2: caratterizzazione DH della piattaforma

Analogamente a prima si avranno Fig. 32 e Fig. 33.

Fig. 32: Implementqazione Matlab della piattaforma

Fig. 33: Rappresentazione della base in coordinate (0;0) del piano (giunti prismatici)

Configurazione completa

Volendo considerare, come nella fase finale di controllo, tutto il braccio, occorrerà semplicemente comporre

i due sottosistemi creati con il comando “SerialLink”.

Fig. 34: Implementazione Matlab dell’intero robot

58

Fig. 35: Rappresentazione del robot in coordinate dei giunti (0;0;0;0;0;0;0)

3.1.2 Costruzione dell’oggetto obiettivo

Per rappresentare l’oggetto obiettivo si utilizza un ellissoide la cui superficie è associata nello spazio ai punti

generati dalla funzione “ellipsoid” la quale restituisce tre matrici contenenti,

rispettivamente, le coordinate in direzioni ( ) dei punti costitutivi noti dimensioni e posizione del

centro secondo la sintassi:

Perché i punti siano utilizzabili per le proiezioni prospettiche è stato necessario ordinare gli elementi delle tre

matrici in una singola come in Fig. 36:

Fig. 36: Creazione obiettivo

Considerando che i frutti reali non saranno caratterizzati da assi di dimensioni particolarmente prevalenti

rispetto alle altre, si è assunta trascurabile l’importanza dell’orientamento dell’ellissoide nello spazio che, per

59

questo, non è stato ruotato nelle successive simulazioni; l’unico angolo di inclinazione degli assi considerato

è stato quello percepito sul piano dell’immagine.

In Fig. 37 è raffigurato in 3D l’intero schema modellato.

Fig. 37: Robot ed obiettivo

Il complessivo sistema di coordinate associato al manipolatore mobile è stato strutturato come segue:

3.1.3 Modellazione della telecamera

Ora che è completamente implementata la struttura del robot non resta che aggiungere la telecamera

vincolata all’end-effector.

Per questa fase di simulazione Matlab ancora priva di un vero e proprio segnale video è stato necessario

utilizzare uno strumento che simulasse gli effetti prospettici dovuti alla proiezione sul piano immagine

dell’oggetto obiettivo.

Per la creazione della telecamera è stata utilizzata la funzione “CentralCamera” per la quale è stato

necessario definire i parametri intrinseci (le caratteristiche della telecamera fisicamente utilizzata sono

60

indicate nel capitolo 6 di sperimentazione), in Fig. 38 si riporta la sintassi con i valori utilizzati (distanza

focale, dimensione pixel, risoluzione, coordinate pixel del centro immagine).

Fig. 38: Caratterizzazione telecamera e parametri intrinseci

Perché vengano restituiti in pixel del piano immagine le coordinate associate alle proiezioni dei punti

dell’obiettivo è necessario effettuare la trasformazione prospettica solo dopo aver portato la

telecamera nella posizione corrispondente al punto di montaggio in-hand.

La funzione “cam.project” ha proprio lo scopo di ottenere le immagini proiettate dei punti e contiene in

input i dati della telecamera precedentemente definita, i punti che devono essere osservati ed una matrice

la quale incorpora tutte le trasformazioni da terna di base del robot alla

posizione in hand ( ).

Di seguito sono riportati i passaggi per la proiezione, si noti l’utilizzo di “fkine”, comando di cinematica

diretta, che permette in un solo passaggio di ottenere la matrice (la funzione utilizza semplicemente le

in modo automatico il prodotto delle matrici indicate in 3.1.1 e delle istantanee).

Fig. 39: Proiezione dei punti sul piano immagine

Sui punti proiettati nel piano immagine è stato possibile applicare il primo metodo di estrapolazione delle

features indicati nella prima sezione dell’Appendice B.

3.2 Ispezione preliminare

Coerentemente con quanto descritto dal punto di vista teorico in 2.3, una volta modellati gli elementi

necessari alla simulazione, è stato il momento di programmare una opportuna routine di osservazione per

portare il robot nelle condizioni di possibile avvicinamento.

In questa prima fase è comodo sfruttare la modellazione separata fatta sulle componenti dello YouBot, infatti

nella fase di osservazione è importante il solo utilizzo del braccio.

Come accennato in teoria occorre impostare un ciclo in cinematica diretta per la rotazione alternata del primo

giunto (ciclo while interno) con il progressivo innalzamento del quarto (ciclo while esterno).

Si scelgono i seguenti parametri per l’incremento della posizione:

61

Vengono anche inizializzati i valori di posizione iniziale nello spazio dei giunti del solo braccio del robot e

di tolleranza in pixel per l’arresto (verrà utilizzato nel ciclo di ispezione come valore di confronto della

distanza cel centroide dal centro immagine per il criterio d’uscita).

Il ciclo impostato è mostrato in Fig. 40; si notino le condizioni logiche d’uscita all’inizio che riguardano

escursione massima, vicinanza al centro dell’immagine e osservazione dell’oggetto (in pratica il parametro

logico col compito di notificare la non osservazione dell’oggetto è implementato con il

comando “isnan” dato che, per oggetti dietro al campo visivo Matlab restituisce valori “Not a number”).

La posizione del centroide è stata identificata mediante il metodo dei momenti di prim’ordine in Appendice

B.

Fig. 40: Routine di ispezione

62

In Fig. 41 è tracciato il percorso oscillante che il braccio ha coperto in una delle fasi di ispezione (si può

osservare dall’alto l’oscillazione , non è stato raggiunto il limite su ):

Fig. 41: Esempio di traiettoria di ispezione (a destra la vista dall’alto)

L’immagine che ha soddisfatto le condizioni di uscita è in Fig. 42; è facile notare che il centroide

dell’oggetto si trova, rispetto al limite di tolleranza di 200 pixel, vicino al centro dell’immagine il che è

sufficiente per il proseguimento dell’algoritmo.

Fig. 42: Risultato dell'ispezione sul piano immagine

63

A questo punto sarà possibile procedere alla fase di triangolazione sulla base delle coordinate che il braccio

ha dovuto assumere per ottenere l’uscita dal ciclo.

3.3 Triangolazione

Dalla posizione del braccio ottenuta al passaggio precedente occorrerà procedere alla stima di distanza e

dimensioni in metri dell’obiettivo; nella sezione teorica 2.4 è stato descritto l’utilizzo delle features estratte

dalle immagini nei due punti al fine di ottenere una efficace triangolazione.

Il primo passo è la definizione dell’angolo per ottenere lo spostamento voluto:

A questo punto occorre acquisire le features d’immagine nel primo punto come in Fig. 42 secondo i criteri

indicati in Appendice B; dopo uno spostamento di del quarto giunto si registrano anche le

features del secondo punto di osservazione in modo analogo (in Fig. 43 le due immagini scattate nelle

rispettive posizioni).

64

Fig. 43: Features sovrapposte alle immagini nei rispettivi punti di triangolazione

Oss: L’angolo è stato preso anche considerando che, dalla fase di ispezione si ha una

posizione di partenza sul piano dell’immagine tale che sia impossibile che oggetti a distanze compatibili con

quelle di raccolta escano dal cono visuale (si ricorda che la telecamera è stata preventivamente posizionata in

modo che lo spostamento angolare del quarto giunto si traducesse in uno spostamento sulla coordinata u dei

pixel in modo da diminuire ulteriormente la possibilità di perdita dell’immagine dal campo visivo.

Come da teoria la stima della profondità avviene come segue (Fig. 44):

65

Fig. 44: Stima della profondità

Oss: i segni per la costruzione degli angoli e sono invertiti a causa delle convenzioni su e

In Fig. 45 è proposta la procedura per l’ottenimento dei diametri del frutto stimati sulla base delle fotografie

scattate; come visto in 2.4.2 occorre sfruttare quattro punti estremi sul piano dell’immagine e ricostruirne

prospetticamente i corrispettivi nello spazio tridimensionale così da poter calcolare gli assi stimati come

distanze.

Fig. 45: Calcolo delle dimensioni stimate dell'obiettivo

I risultati nel caso di questa implementazione sono particolarmente accurati in quanto non esistono errori di

illuminazione e riconoscimento di immagine ridotta ai soli punti. In Tabella 3: Esempio di risultati

triangolazione si riportano indicativamente, per un caso di triangolazione, i valori veri e quelli stimati.

66

Valori reali (m) Valori stimati (m)

Profondità 0.632 0.626

Asse maggiore 0.05 0.0499

Asse minore 0.05 0.0498

Tabella 3: Esempio di risultati triangolazione

Il livello di accuratezza riscontrato su diverse simulazioni è più che accettabile per le seguenti tappe

dell’algoritmo (specialmente per quanto riguarda la profondità che verrà corretta dal controllo).

3.4 Avvicinamento in controllo

Per completare la fase di avvicinamento non resta che implementare il sistema di controllo che avrà bisogno

innanzitutto dei requisiti di posizionamento finale per la telecamera in profondità e per il centroide sul piano

immagine:

Occorre verificare ora che siano stati allocati i seguenti risultati:

I valori dei diametri stimati dalla triangolazione in metri: e

Il valore iniziale di profondità stimata dalla triangolazione:

Il posizionamento del braccio dello YouBot ottenuto dall’ultimo punto di triangolazione associato

alle coordinate nulle della piattaforma.

Il tempo di integrazione idealmente associato ad ogni iterazione del ciclo di controllo .

Limitatamente a questa particolare simulazione il tempo di integrazione minimo è limitato solo dal

tempo di calcolo delle varie funzioni

Il valore delle costanti proporzionali ed integrative necessarie per il metodo (l’ottimizzazione per il

controllo è strettamente dipendente dal tempo di integrazione utilizzato ed è stata ottenuta mediante

approccio “trial and error” su diversi tentativi).

67

Tabella 4:Costanti di controllo

Devono essere impostate le condizioni di uscita dal ciclo; in particolare si sceglie sia un tempo

massimo di 60 secondi (che determina, noto , il numero massimo di iterazioni) sia una

condizione di soddisfacimento della profondità desiderata dall’obiettivo; non sono state imposte

condizioni sugli altri errori in quanto, sperimentalmente, si è verificato che sono molto più rapidi a

convergere e sarebbe stato quindi un’inutile appesantimento delle iterazioni.

L’implementazione di queste due condizioni di uscita non fa altro che rendere ammissibili al ciclo

solo due conclusioni: “obiettivo raggiunto” ovvero portato alla giusta profondità e “raccolta non

completata” a causa del tempo scaduto il che copre sia casi di non convergenza che di convergenza

lenta.

Ora che sono state fatte le dovute premesse si può riassumere, sulla base di quanto detto in 2.5, il contenuto

di ogni iterazione del sistema di controllo.

1. Controllo del soddisfacimento delle due condizioni su e ed incremento del contatore:

Fig. 46: Inizio ciclo

2. Movimento della telecamera per seguire l’end-effector.

;

3. Ottenimento dell’immagine.

4. Image processing per estrapolare come in Appendice B.

5. Stima della distanza dalla telecamera al centroide, cioè grazie alle dimensioni reali stimate nella

triangolazione preliminare.

6. Valutazione degli errori, cioè e calcolo dei vettori velocità e attraverso i

passaggi dell’algoritmo.

Si riportano in Fig. 47 e Fig. 48 le fasi salienti del controllo disaccoppiato.

68

Fig. 47: Controllo rotazionale

Fig. 48: Controllo traslazionale

7. Determinazione delle velocità dei giunti del robot da quelle totali dell’end-effector;

Le velocità , devono essere garantite da un’opportuna velocità dei giunti del robot; a tal

proposito occorre conoscere i legami cinematici presenti. La matrice che riassume tale relazione è

detta Jacobiano. Vale la relazione vista in teoria anche in [27]:

Essendo sette i gradi di libertà del robot, si deduce che e non è normalmente invertibile.

Per proseguire all’inversione della ( 74 ) in modo da esplicitare , occorre procedere come segue:

( 74 )

69

In cui indica la matrice pseudo inversa detta di Moore-Penrose, definita nel seguente modo:

Questa scrittura è implementata in Matlab mediante la funzione ‘pinv’, il cui argomento è la matrice

di cui si vuole la pseudo inversa ( nel caso in esame).

La matrice è, a sua volta, restituita dalla funzione ‘jacobn’, che ha come argomenti il nome

del’oggetto robot e . Qualora il robot fosse sotto attuato (come nel caso del solo braccio con i suoi

5 giunti) è possibile risolvere solo un numero limitato dei gradi di libertà ed occorrerà pertanto

procedere partizionando il vettore delle velocità; questo procedimento sarà utilizzato a partire dal

capitolo 5 ma non è stato necessario utilizzarlo per la sperimentazione corrente.

8. Verifica delle condizioni di singolarità cinematica per un eventuale arresto immediato del ciclo.

Quando il robot raggiunge condizioni di massima estensione del braccio o particolari pose dalla

limitata manovrabilità è possibile che sia negato in normale funzionamento del controllo con

difficilmente prevedibili effetti sulle velocità comandate; queste limitazioni si traducono

matematicamente nel repentino aumento del numero di condizionamento dello Jacobiano calcolato al

punto precedente che viene quindi testato ad ogni iterazione per evitare malfunzionamenti.

Fig. 49: Controllo del numero di condizionamento di J

9. Una volta ottenute le velocità dei giunti ad ogni iterazione si procede integrandole rispetto al

tempo :

10. A questo punto avviene una fase di salvataggio dei dati all’iterazione corrente semplicemente perché

possano essere utilizzati in seguito per la lettura e la visualizzazione grafica dei risultati. Il ciclo può

passare di nuovo al punto 1.

70

3.5 Risultato delle simulazioni

Dato che le effettive condizioni di esercizio sono difficilmente prospettabili in questa fase e, al momento di

questa modellazione non erano noti tempistiche e ritardi associati alla configurazione reale, sono state

effettuate simulazioni in diverse condizioni.

Queste prime raccolte di dati, benché distanti dalle condizioni applicative reali, saranno soprattutto

propedeutiche per la comprensione dei comportamenti del robot nei capitoli 5 e 6.

In seguito, si faranno considerazioni sugli effetti delle diverse posizioni di presa del frutto; si riportano ora

due casi di studio a pari condizioni ma diversi .

3.5.1 Risultati ed effetti del tempo di integrazione

Prima simulazione ( )

Per il confronto a pari condizioni viene posizionato un obiettivo ad una altezza facilmente raggiungibile dal

robot in modo che le differenze non siano da imputare al modo diverso di affrontare singolarità cinematiche

ai diversi tempi di integrazione.

Dimensioni e posizionamento del frutto e parametri obiettivo:

centro ellissoide in coordinate [0,6 -0,4 0,3] m

dimensione diametri ellissoide [0,05 0,05 0,05] m

base dello YouBot in coordinate [0 0 0]

Risultati triangolazione:

Distanza reale tra telecamera e centroide lungo :

71

Costanti di controllo:

Si riportano in Fig. 50 e Fig. 51 gli andamenti, nel tempo della raccolta, di profondità stimata del centroide e

delle relative coordinate sul piano dell’immagine.

Fig. 50: Profondità stimata in controllo

L’andamento della profondità è quello, almeno approssimativamente esponenziale, atteso e si osserva che la

condizione di uscita sulla profondità avviene appena prima degli 8 secondi, in particolare a 7.93 secondi per

la profondità di 0.207 metri.

72

Fig. 51: Posizioni del centroide sul piano immagine in controllo

Come era stato anticipato a proposito della scelta delle condizioni di uscita, è facile notare che la

convergenza sul piano dell’immagine avviene molto più rapidamente di quanto non accada per la profondità;

ciò è effettivamente coerente con la necessità di portare subito l’obiettivo al centro del campo visivo per non

perderlo di vista in avvicinamento.

Ai fini di avere una visualizzazione migliore di quanto avviene sul piano immagine nel tempo è dunque

preferibile utilizzare il solo errore come mostrato in Fig. 52:

Fig. 52: Errori sul piano immagine in controllo

73

Anche in questo caso l’andamento è del tipo atteso e certamente consente una buona inquadratura

dell’obiettivo in tutta la fase di avvicinamento. Solo per motivi di completezza è possibile visualizzare

separatamente anche le posizioni istantanee nelle coordinate dei giunti come in Fig. 53:

Fig. 53: Movimento nello spazio dei giunti

Alcune cose che è possibile notare in Fig. 53 sono, per esempio, che:

il giunto 7 (rotazione dell’end-effector) non viene mai utilizzato

Il giunto 3 (rotazione del braccio sulla base) è utilizzato molto poco in quanto l’ispezione lo ha già

portato approssimativamente al corretto allineamento.

I giunti 4 e 6 sono sicuramente interessati da un punto di flesso nella prima parte del grafico e ciò

corrisponde, in simulazione, ad un “superamento del gomito” che il braccio deve eseguire partendo

dalla rannicchiata posizione di ispezione.

Nel complesso la simulazione è giunta rapidamente a convergenza, non sono stati attivati i controlli di

emergenza sul numero di condizionamento dello Jacobiano.

Seconda simulazione ( )

Si vuole ora riproporre l’esperimento precedente nelle identiche condizioni di partenza (con gli stessi risultati

dalla triangolazione) ma tempo di integrazione cinquanta volte superiore perché si possano trarre conclusioni

applicabili alle più limitanti condizioni reali.

74

Verranno commentate le sole differenze da quanto avvenuto in precedenza.

La modifica del tempo di integrazione ha reso necessaria, per l’ottenimento di risultati simili ai precedenti,

una notevole modifica delle costanti di controllo, soprattutto le proporzionali:

Come è stato necessario l’utilizzo di costanti di controllo diverse a causa dei diversi tempi di integrazione,

così sarà necessario effettuare di nuovo la taratura del controllo per simulazione Vrep e sistema sperimentale

reale.

Come nel caso precedente si riportano in Fig. 50 e Fig. 51 gli andamenti, nel tempo della raccolta, di

profondità stimata del centroide e delle relative coordinate sul piano dell’immagine.

Fig. 54: Profondità stimata in controllo

L’andamento della curva di profondità stimata Fig. 54 non è molto diverso dal caso precedente, si mantiene

l’abbattimento indicativamente esponenziale dell’errore; la differenza importante è tuttavia registrata nel

tempo totale di convergenza che risulta aumentato di più del 30%.

75

La convergenza avviene a 0,206 metri in 13,5 secondi e, in confronto col caso precedente, porta a dedurre

che tempi di integrazione alti (associabili a lunghi tempi di acquisizione immagine o calcolo) abbiano un

ruolo importante nel determinare il minimo tempo per un ciclo.

Fig. 55: Errori sul piano immagine in controllo

In Fig. 55 si notano importanti variazioni nella parte iniziale del grafico: l’andamento, pur seguendo in linea

di massima quello di Fig. 52 si presenta come una linea marcatamente spezzata caratterizzata nei primi

secondi da un errore maggiore (oltre 50 pixel attorno ai 2 secondi) e da un piccolo ma evidente picco (in

direzione ovvero quella associata la movimento dei gradi di libertà 4 5 e 6) che, come si vedrà a breve può

essere associato con i diversi modi di affrontare il passaggio del braccio oltre un gomito a tempo di

integrazione diverso.

76

Fig. 56: Movimento nello spazio dei giunti

Anche gli andamenti nello spazio dei giunti (Fig. 56) sono similari a quelli visti in precedenza anche se in

questo caso si può notare che la prima parte è evidentemente caratterizzata da inversioni di moto più

repentine a causa del diverso tempo fra i campionamenti dell’immagine.

3.5.2 Manovrabilità ed effetti della posizione obiettivo

Manovrabilità e singolarità cinematiche

Nelle simulazioni trattate in precedenza, la posizione del frutto è sempre stata presa in modo “comodo”

ovvero non si sono mai presentate condizioni per le quali fosse impossibile proseguire nella presa.

Dalla teoria riguardante in generale le catene cinematiche e, più nello specifico, i robot antropomorfi, sono

invece ben note le cosiddette condizioni di singolarità cinematica [25]: particolari condizioni di posa che

rendono impossibile la continuazione della presa o, in ogni caso, la rendono pericolosamente instabile.

Sono due le macrocategorie di singolarità cinematiche:

Singolarità cinematiche ai confini dello spazio di lavoro: si presentano quando il manipolatore è

tutto steso o tutto ripiegato su se stesso (per esempio le cosiddette singolarità di gomito).

Singolarità cinematiche interne allo spazio di lavoro: si generano tipicamente con l’allineamento

di due o più assi di moto od in corrispondenza di particolari posture.

Per definizione le singolarità cinematiche si hanno in circostanze tali per cui al manipolatore non è possibile

il movimento lungo una generica traiettoria in quanto almeno una direzione risulta ostacolata.

77

Questa tesi non mira ad una trattazione rigorosa ed approfondita di tutte le condizioni di singolarità per il

robot utilizzato, è tuttavia importante per giustificare alcune scelte di implementazione affrontare almento in

parte il problema.

Come discusso in 3.4 la matrice Jacobiano ha la funzione di mappare i legami cinematici tra le velocità

all’organo terminale del braccio e quelle nello spazio dei giunti; si è visto come per imporre le velocità

desiderate sia necessario invertire questa matrice.

È proprio nell’inversione dello Jacobiano in particolari pose che si possono avere le cosiddette singolarità

ovvero casi nei quali ; si assume per ora che la matrice sia quadrata.

L’annullarsi del determinante si traduce, in pratica, col fatto che a grandi variazioni della velocità nello

spazio dei giunti corrispondano variazioni di velocità all’end-effector particolarmente esigue; ciò costringe

spesso il controllo a non raggiungere una condizione stabile.

In termini alternativi, per avere un indice anche nell’intorno di una singolarità di quanto possa essere difficile

l’inversione di si può ricorrere al calcolo del suo numero di condizionamento ; si potrebbe obiettare che

l’utilizzo della funzione pseudo inversa renda a rigore meno stringente la validità dell’uso del numero di

condizionamento per studiare le singolarità ma, seppur in modo approssimato, i risultati circa la stabilità

concordano).

In generale una matrice si può dire malcondizionata se il suo numero di condizionamento supera un

predeterminato valore di soglia la cui definizione è tuttavia arbitraria e dipendente dal problema in esame; a

seguito di diverse prove svolte sono state definite le seguenti fasce di valori:

Numero di condizionamento tra 0 e 50: il robot può muoversi in condizioni normali ed il sistema

di controllo non dovrebbe trovarsi in difficoltà a causa di singolarità cinematiche.

Numero di condizionamento tra 50 e 1000: il robot viene a trovarsi in condizioni che ne limitano

la mobilità ma ciò non necessariamente coincide con l’impossibilità di completare il ciclo di

controllo poiché, in termini pratici, i gradi di libertà che hanno problemi non sono quelli che il

sistema di controllo deve attuare [25]; essenzialmente il robot attraverserà una zona di scarsa

manovrabilità ma andrà oltre.

Numero di condizionamento oltre i 1000: se ci si trova in questa condizione è ormai molto

probabilmente perché lo stesso sistema di controllo tende a portarsi nella posizione di singolarità

cinematica; questo è stato sperimentato in simulazione nei casi di singolarità di gomito per obiettivi

posti a quota più alta della completa estensione del manipolatore.

78

Di seguito si riportano, in riferimento alle simulazioni a diversi tempi di integrazione visti in precedenza, i

grafici dei valori assunti dai numeri di condizionamento dei rispettivi Jacobiani. In Fig. 57 il caso con tempo

di integrazione piccolo ( ):

Fig. 57: Numero di condizionamento per Tint=0.001 s

Si può osservare che, in genere, la curva tende a rimanere nella zona di comportamento a manipolabilità

“normale” ma, nel primo secondo, avviene qualcosa che innalza notevolmente il numero di

condizionamento. Osservando la simulazione si può capire che ciò corrisponde al momento in cui si passa

dalla zona rannicchiata del braccio a quella estesa.

Dato che l’algoritmo arriva correttamente a convergenza e, dai grafici in Fig. 53 non emerge niente di

particolarmente anomalo nello spazio dei giunti si può concludere che in questa fase venga effettivamente

affrontata una zona in cui la generica manipolazione è ostacolata ma quella imposta dal controllo non sembra

risentirne.

Occorrerà fare ulteriori considerazioni sulle direzioni di movimento ammissibili per capire esattamente

quello che sta succedendo.

79

Fig. 58: Numero di condizionamento per Tint=0.5 s

In Fig. 58 con si ripropone un andamento che, seppur con puti più diradati, rispecchia quanto

visto nel caso precedente; anche da quanto emerge in Fig. 56 non ci sono evidenti anomalie.

Ciò che può sorprendere da questo secondo grafico è il fatto che il picco del numero di condizionamento sia

in realtà considerevolmente più basso del corrispondente picco a baso tempo di integrazione; la

giustificazione che è stata data a questo fenomeno è stata che, nel fornire movimenti più ampi associati a

lunghi intervalli temporali, il robot possa andare oltre la zona a manipolabilità ridotta effettuando pochi

(pare solo uno) cicli di controllo nell’intorno dell’eventuale singolarità. La “cecità” tra iterazioni consecutive

consentirebbe dunque al manipolatore di spostarsi senza che i problemi siano osservati completamente (il

che non è grave se, come in questo caso, l’allarme sul condizionamento non porta effettivamente ad

impedimenti del ciclo di controllo).

A titolo di confronto si mostra in l’andamento del numero di condizionamento in un caso di obiettivo

irraggiungibile a quota 0.9 m, maggiore dell’estensione completa del braccio. Naturalmente perché fesse

possibile visualizzare i picchi è stato spento il sistema di interruzione del ciclo proposto in 3.4.

80

Fig. 59: Numero di condizionamento certamente non accettabile, caso in singolarità di gomito

Come si è visto il numero di condizionamento costituisce solo un’informazione parziale per lo studio del

controllo in condizioni di singolarità; in letteratura [25] si ricorre infatti spesso a metodi che consentono una

visualizzazione grafica della manovrabilità.

Il metodo più diffuso per osservare le potenzialità di moto nello spazio è quello dei cosiddetti ellissoidi della

velocità o di manipolabilità. Anche in questo caso non si fa una trattazione dettagliata ma, in sintesi si

rappresenta graficamente il luogo geometrico di tutti i vettori di velocità che possono essere generati dallo

Jacobiano del robot a partire dai possibili ingressi in coordinate dei giunti di modulo complessivo unitario:

Sostituendo la ( 74 )

Si può dimostrare che, alla data posizione del robot, il luogo geometrico delle le generate a partire

dall’equazione appena fornita restituiranno un ellissoide.

Se si posiziona l’ellissoide trovato in corrispondenza dell’end-effector si può avere un’idea delle velocità

generate dallo Jacobiano con input unitario e, di conseguenza visualizzare la manovrabilità della macchina.

La funzione “plot_ellipse“ del Robotics Systems toolbox permette di ottenere direttamente il grafico a

partire da Jacobiano e posizione dell’end-effector (facilmente valutabile dalla matrice in cinematica diretta

81

ottenuta tramite il comando “fkine”). La sintassi utilizzata è stata la seguente (con imposizione del colore

della griglia):

Tornando al problema di partenza è ora possibile osservare nelle varie configurazioni la manipolabilità

concessa al braccio. In Fig. 60 i casi non problematici rispettivamente di inizio e fine ciclo ( ):

Fig. 60: Ellissoidi della velocità in posizione iniziale e finale

È effettivamente possibile osservare (soprattutto dall’alto) come, già in parte all’inizio ma soprattutto

all’istante (poco successivo) di tempo corrispondente ai picchi di condizionamento sia molto limitato il

movimento laterale; in Fig. 61 si evidenzia la criticità:

Fig. 61: Ellissoidi della velocità in un punto di manipolabilità ridotta

Anche se, naturalmente, non si è mai operato in condizioni di completa singolarità, a titolo di riscontro si

propone in Fig. 62 un esempio dell’ellissoide delle velocità generabili a completa estensione del braccio.

82

Fig. 62: Singolarità cinematica e relativo ellissoide di manipolabilità degenere

Come si può osservare l’ellissoide è degenere e vi sarebbe una unica direzione ammissibile (in questo caso

parallela a della telecamera); il numero di condizionamento in questo caso è effettivamente enorme (in

Matlab 1.4508e+17).

Ora che sono stati discussi i problemi legati alle singolarità si espone di seguito una breve panoramica delle

posizioni finali di presa alle stesse coordinate lungo ma diverse quote da terra (si sono ottenuti

risultati analoghi anche per altre coordinate):

Fig. 63: Prese del frutto in (0,6;-0,4;0,3) e (0,6;-0,4;0,4)

83

Fig. 64: Prese del frutto in (0,6;-0,4;0,5) e (0,6;-0,4;0,6)

Riassumendo quanto ottenuto in questa simulazione si può dire che l’algoritmo proposto funziona bene nelle

condizioni di esercizio proposte ma, nei prossimi capitoli, occorrerà:

Tenere conto che le costanti di controllo devono essere scelte considerando il tempo di integrazione

È opportuno tenere sotto controllo il numero di condizionamento per identificare eventuali

condizioni di singolarità cinematica considerando ad ogni modo che l’informazione ad esso associata

va contestualizzata per identificare le cause di singolarità.

Gli obiettivi devono essere posti a quota non superiore a circa 0.6 metri in quanto per il robot la

completa estensione porta a non godere della opportuna manovrabilità.

84

4 Simulazione in Simulink

Nel capitolo precedente è stato dimostrato, in diverse condizioni di simulazione, che l’algoritmo teorico

proposto porta a risultati soddisfacenti; l’implementazione svolta in precedenza è tuttavia, in pratica, solo

leggibile come un lungo script Matlab e sarebbe invece interessante, come consuetudine per i sistemi di

controllo, visualizzare il sistema per l’avvicinamento mediante schemi a blocchi.

L’ambiente Simulink è collegato al workspace di Matlab e costituisce un versatile strumento di modellazione

di sistemi di controllo in tempo continuo e discreto. In questo capitolo si discuterà il percorso di

implementazione delle medesime

4.1 Importazione dei dati

Come per il ciclo di controllo in Matlab è necessario assegnare in anticipo alcuni dati caratterizzanti gli

oggetti modellati e gli output delle precedenti fasi di ispezione e triangolazione.

Per quanto riguarda gli oggetti modellati si hanno:

Caratteristiche della telecamera, in particolare: lunghezza focale, dimensione pixel e matrice ;

Caratterizzazione dell’oggetto robot costruita con il comando ‘SerialLink’;

Oggetto telecamera, ottenuto mediante ‘CentralCamera’;

Dimensioni e posizione del centro dell’ellissoide e coordinate dei punti che lo compongono, .

Gli altri dati necessari, compresi quelli dettati dalle fasi precedenti 3.3 al controllo sono:

Profondità stimata del centroide in triangolazione per la prima iterazione

La posizione dei giunti alla partenza del controllo (indicata qui come q0)

Dimensioni di asse maggiore ed asse minore come ottenuti dopo la triangolazione

Costanti di controllo proporzionali e derivative del sistema di controllo;

Perché questi dati possano essere letti in Simulink è necessario innanzitutto che sia eseguito script Matlab

che completi tutte le operazioni precedenti al controllo come discusso in 3.

Quando i dati sono presenti nel Workspace base di Matlab è sufficiente, per ogni blocco contenente funzioni

che usano i parametri da importare, aggiungere tra gli input dello script associato le costanti di interesse.

85

Il blocco della funzione in questo modo ammette un nuovo ingresso come quelli utilizzati per le altre

connessioni dello schema a blocchi; non resta che imporre all’opzione explore del blocco l’utilizzo di una

variabile parametrica (Parameter) per l’input desiderato.

In Fig. 65 è mostrato il procedimento di lettura da Matlab della matrice A per il blocco di visual servoing, in

modo analogo sono stati trattati gli altri parametri.

Fig. 65: Passaggio di parametri dal workspace Matlab a Simulink

Si può ora procedere a spiegare dettagliatamente il contenuto dello schema a blocchi utilizzato.

4.2 Modellazione del robot

Come per l’implementazione in 3, anche in Simulink si sfruttano blocchi che fanno parte del Robotics

Toolbox e quindi sicuramente compatibili con le strutture dati importate per i relativi oggetti.

I blocchi direttamente inerenti al funzionamento del robot (e che ne utilizzano la struttura ‘SerialLink’) sono

i seguenti:

Il blocco fkine in Fig. 66 che esegue la funzione di cinematica diretta del robot (YouBot) avendo in

ingresso il vettore e restituendo la matrice di rototraslazione che sarà in seguito input

necessario al posizionamento del punto di vista della telecamera.

86

Fig. 66: Blocco fkine per il calcolo della matrice Tcam

Il blocco jacobn in Fig. 67 che restituisce lo Jacobiano alle date coordinate dei giunti

Fig. 67: Blocco jacobn per il calcolo dello Jacobiano

Il blocco pinvJac in Fig. 68 che, a partire dalle velocità desiderate per l’end-effector ( )

consente di ottenere quelle da dare ai giunti per mezzo dell’inversione (propriamente la pseudo

inversa come visto in 3) dello Jacobiano.

Fig. 68: Blocco pinvJac per determinare le velocità ai giunti

Il blocco plot (opzionale) in Fig. 69 è stato utilizzato per mostrare, durante la simulazione, il

posizionamento del robot nello spazio sulla base delle coordinate correnti nello spazio dei giunti.

Fig. 69: Blocco plot

87

4.3 Telecamera e processamento delle immagini

Analogamente a quanto avviene per il robot, il Robotics Toolbox mette a disposizione strumenti per sfruttare

anche in Simulink la modellazione degli oggetti telecamera.

Il blocco camera in utilizza l’oggetto “cam” per restituire le proiezioni sul piano immagine dei

punti dell’ellissoide ( ) tenendo conto del posizionamento dell’end-effector (grazie a ).

Fig. 70: Blocco camera per l'acquisizione d'immagine

È stato necessario agire in modo diverso nel caso del processamento d’immagini: la specifica natra del

problema ha imposto la necessità di costruire un blocco personalizzato.

Blocco di image processing: Simulink mette a disposizione uno strumento per la costruzione di

blocchi con sintassi analoga a quella delle funzioni in Matlab. Proprio questo strumento è stato

utilizzato per implementare, contemporaneamente, le procedure di processamento immagini in

Appendice B con ottenimento delle features (posizione centroide, assi in pixel e angolo di

inclinazione dell’ellisse sul piano immagine) assieme alla profondità stimata ( ) ed a uno dei due

Jacobiani dell’immagine (J_2v) contenente le coordinate del centroide.

Fig. 71: Blocco di image processing

88

In Fig. 71 si evidenziano ingressi ed uscite, in Fig. 72 la sintassi iniziale della funzione Matlab che viene

utilizzata per il blocco; si noti, per la compilazione del blocco, l’inserimento di “%#codegen” alla fine della

riga nella quale si dichiarano ingressi ed uscite.

Fig. 72: Inizio dello script per il blocco image processing

Si osserva che, le stime degli assi dell’obiettivo ottenute in triangolazione sono ingressi di fondamentale

importanza per la stima della profondità, per questo motivo non sono stati passati come parametro ma è stato

preferito l’utilizzo di un vero e proprio blocco di input (verde in Fig. 71).

4.4 Asservimento visuale e chiusura del ciclo

Dal processamento delle immagini è ora necessario ottenere quanto serve per ottenere le velocità desiderate

ed effettuare l’integrazione per ottenere la nuova posizione del manipolatore e quindi poter cominciare

l’iterazione successiva; sono stati dunque implementati:

Blocco di visual servoing. In modo analogo a quanto fatto per il blocco di image processing

occorre, per compattezza dello schema, utilizzare un blocco che contenga l’intera porzione di script

Matlab che porta dalle features d’immagine alle velocità desiderate all’end-effector.

In Fig. 73 è mostrata la parte dello schema che riguarda gli ingressi alla funzione di asservimento

visuale: si possono notare le uscite del precedente blocco di processamento immagini (posizione

centroide, assi in pixel, profondità stimata ( ) e J_2v) oltre a due ingressi parametrici che

costituiscono i valori desiderati del posizionamento del centroide sul piano dell’immagine ed in

profondità.

Riassumendo quanto detto in 3.4 all’interno del blocco avvengono nell’ordine calcolo dei tre errori

(rotazionale, sul piano immagine ed in profondità), utilizzo delle costanti di controllo per

determinare velocità rotazionale e traslazionali ed assemblaggio del vettore in uscita.

89

Fig. 73: Blocco di asservimento visuale e relativi ingressi

Blocco integrativo: come descritto in teoria, una volta ottenute, per mezzo dello Jacobiano del

robot, le velocità da fornire nello spazio dei giunti, occorre che esse siano attuate per il

riposizionamento del robot (e con esso della telecamera).

Il blocco in Fig. 74 ha proprio il compito di ottenere da (si noti che al blocco è necessario

fornire il vettore di posizioni iniziali dei giunti provenienti dal workspace Matlab)

4.5 Risultati delle simulaioni

Grazie al blocco “plot” è stato possibile visualizzare in tempo reale i risultati del posizionamento del robot

ma, ai fini del salvataggio dei dati è stato necessario disporre opportuni blocchi “to workspace” di

salvataggio dei dati per la visualizzazione dei risultati.

A parità di condizioni i risultati Simulink si sono dimostrati sostanzialmente analoghi a quanto visto in

Matlab si rimanda dunque alle considerazioni in 3.5. In Fig. 75 lo schema completo:

Fig. 74: Blocco integratore

90

Fig. 75: Schema a blocchi del controllo completo

91

5 Simulazione in V-REP

L’ultimo passo che si è deciso di intraprendere prima della vera e propria sperimentazione su robot reale è

stata la simulazione in un ambiente di animazione realistico.

Il modello costruito finora in Matlab e Simulink mancava di alcune importanti caratteristiche che qualificano

il comportamento di sistemi reali: l’effettivo tempo di processamento di immagini di oggetti non puntiformi,

il movimento reale delle ruote non semplificato come in precedenza a giunti prismatici e gli effetti di inerzie

ed ingombri legati allo specifico modello fisico del robot.

Vrep è proprio un ambiente di simulazione che gode di strumenti interni per la simulazione della fisica per le

interazioni degli oggetti modellati; fortunatamente per lo svolgimento di questa simulazione il modello del

manipolatore mobile YouBot è già fra le librerie di default e non occorrerà effettuare manualmente la

costruzione di giunti e bracci costitutivi con relativi orientamenti.

Anche in questo caso il cuore dell’algoritmo di controllo verrà elaborato in Matlab mentre Vrep avrà il solo

compito di comunicare ad esso le letture di sensori simulati (corrispettivi di quelli che si avrebbero nel

mondo reale) e di attuare la movimentazione del robot sulla scena corrente. Una scena Vrep non è altro che il

file nel quale sono raccolti tutti gli oggetti, interazioni e script modellati per una sessione di simulazione da

effettuare.

Come è stato accennato prima, per questa simulazione, è stato necessario instaurare un protocollo di

comunicazione con Matlab; da questo punto di vista Vrep è particolarmente versatile in quanto, benché

internamente sfrutti script in programmazione Lua, è strutturato in modo da poter comunicare in diversi modi

con utenze che utilizzano i più svariati linguaggi di programmazione.

Il metodo più veloce per interfacciare Matlab a Vrep è sicuramente l’utilizzo delle remote API (Application

Programming Interfaces) già implementate, in alternativa è possibile scrivere o utilizzare un plug-in Vrep in

grado di effettuare l’allacciamento o, infine, sfruttare l’interfaccia di comunicazione di un sistema ROS.

L’ultima tecnica è stata scelta per questa simulazione per il semplice motivo che sarà lo stesso tipo di

tecnologia utilizzato per la sperimentazione e quindi rende possibile già in fase di simulazione di trarre

importanti conclusioni utili alla realizzazione pratica su robot fisico.

Questo capitolo si comporrà di tre parti:

modellazione della scena nella quale verrà anche affrontato l’allacciamento a ROS lato Vrep

modifica dell’algoritmo Matlab ed interfaccia dello stesson conn la rete ROS

Simulazioni e risultati

92

5.1 Modellazione della scena

All’apertura di una nuova scena di Vrep lo spazio operativo è vuoto eccezion fatta per la pavimentazione a

scacchi e l’indicazione del sistema di riferimento.

5.1.1 Sfondo

Il primo oggetto da introdurre al fine di evitare eventuali problemi di osservazione alla telecamera non

affrontati in simulazione è stata una barriera (tre oggetti muro trovati in models > infrastructures > walls)

verso la parte di spazio vuoto oltre la zona di lavoro (Fig. 76).

Fig. 76: Barriera visuale verso il vuoto

5.1.2 Robot

Come si è detto il modello dello YouBot è già stato implementato e può essere trovato seguendo il percorso

models >robots >mobile > KUKA youbot.

Il manipolatore è stato posizionato nell’origine corrispondente al centro della scacchiera come in Fig. 77.

Fig. 77: Importazione del modello di YouBot

93

5.1.3 Obiettivo

Per il frutto obiettivo è stata scelta, in questa fase di simulazione, una semplice sfera rossa il cui colore fosse

dunque sicuramente riconoscibile dal sistema di processamento immagini in Appendice B.

È stato sufficiente, cliccando nello spazio di lavoro, seguire add > Primitive > shape > Sphere e ciò apre la

finestra di dialogo in Fig. 78.

Fig. 78: Creazione della sfera obiettivo

Il comando appena utilizzato ha costruito una sfera nel punto di origine della scena, dopo averlo spostato

nella posizione desiderata con l’apposito comando object/item shift nella toolbar in alto è stato necessario

impostare due delle caratteristiche necessarie alla simulazione: il colore (è stato scelto il rosso come in Fig.

79) e l’osservabilità dell’oggetto da parte dei Vision sensor (Fig. 80).

Fig. 79: Impostazione del colore dell'obiettivo

94

Fig. 80: Impostazione della posizione e visibilità

Si notino nella finestra di destra le spunte alle proprietà Measurable, Renderable e Detectable: saranno

importanti per il controllo visuale da telecamera.

5.1.4 Telecamera

In Vrep sono definiti due tipi di oggetto per quelle che, in realtà sono le telecamere: Cameras e Vision

sensors . Le prime hanno la sola funzione di definire un punto di osservazione per la sessione di simulazione

corrente e non devono essere confuse con i secondi i quali possono effettivamente acquisire immagini per il

controllo visuale.

Per modellare il sensore desiderato si procede dunque cliccando add > Vision sensor > Perspective type;

successivamente con un doppio click sul sensore appena creato dall’albero delle features sono stati impostati

risoluzione della telecamera (1280x720) e angolo associato al campo visivo (73°) come in Fig. 81.

Il sensore viene di default posizionato nell’origine ma non basta spostarlo come fatto per l’oggetto obiettivo

in quanto dovrà rimanere vincolato all’end-effector del robot per tutto il corso della simulazione. Per questo

genere di necessità Vrep offre un metodo ingegnoso ma di semplice implementazione noto come “child

featuring” che consiste nell’associare direttamente nell’albero delle features oggetti vincolati ad altri di

riferimento perché ne diventino, in questo modo, “figli” e ne seguano pertanto i movimenti.

95

È stato anche utilizzato un sistema di osservazione della vista corrente ottenuto selezionando add>floating

view per aprire una finestra e, dopo aver cliccato in seguito su di essa, scegliendo view > associate view

with selected vision sensor per associarla al sensore creato (Fig. 82).

Fig. 81: Definizione parametri del Vision Sensor

Fig. 82: Montaggio della videocamera "figlia" e floating view

Si noti che la vista nella floating window sarà disponibile soltanto nelle fasi di simulazione attiva poiché,

come si vedrà interfacciando il sistema ROS, i sensori ed i relativi topic vengono attivati solo con l’inizio

delle simulazioni.

Il posizionamento vero e proprio della telecamera è stato effettuato selezionando quote dall’end-effector

compatibili con quelle che verranno utilizzate nella sperimentazione reale e i valori di riferimento sono stati

salvati per la costruzione della matrice dei parametri estrinseci della telecamera più avanti in questo capitolo.

96

5.1.5 Preparazione dei ROS topic

Come è stato anticipato Vrep ha bisogno di essere configurato prima di godere di tutte le funzionalità ROS

che saranno necessarie.

In Appendice A si spiega che, all’avvio, Vrep controlla sempre l’esistenza di un ROS master attivo sul

computer corrente, in caso affermativo genera automaticamente un nodo “/vrep” con il quale interfacciarsi.

Il nodo creato dal programma consente immediatamente di utilizzare i service offerti da Vrep (visualizzabili

da terminal mediante il comando “rosservice list”) ma, perché sia contemplata anche la messaggistica via

topic è necessario che specifiche linee di comunicazioni vengano aperte in publishing e subscribing; a ciò si

aggiunge il fatto che, come visto per la floating window, sensori ed attuatori del robot funzionano solo a

simulazione attivata.

Per l’attivazione dei topic occorre utilizzare lo script principale del robot (vi si può accedere cliccando

l’icona a fianco della radice YouBot nell’albero delle features) ed inserire le opportune righe di codice Lua.

Per la simulazione in questo capitolo sarà necessario impostare tre tipi di comunicazione: i subscriber che

ricevono da Matlab le posizioni dei giunti, i subscriber che ricevono da Matlab le velocità della base (che

come si vedrà in seguito sono associate alle singole ruote) ed infine il publisher per l’invio delle immagini da

sensore visuale (è stato aggiunto anche il publisher per i giunti ma solo per fini di controllo).

La sintassi per l’apertura dei topic prevede, tra gli ingressi in Fig. 83, i seguenti tipi di input importanti: il

nome del topic cui ci si riferisce, il tipo di messaggio che verrà ricevuto (compatibile con l’attuazione dei

comandi Vrep corrispondenti) e la cosiddetta object handle ovvero l’identificativo numerico che Vrep

associa ad ogni entità della scena per l’interazione senza conflitti.

Fig. 83: Preparazione dei ROS subscriber

97

In modo analogo a quanto visto si agisce sul publisher della videocamera:

A questo punto non basta che attivare una sessione di simulazione premendo il pulsante start perché i topic

introdotti in precedenza siano visibili da terminal come in Fig. 84, come si è detto sono anche disponibili da

subito i servizi che sono riportati in Appendice A

Fig. 84: Verifica dell'apertura dei topic Vrep da terminal

La scena è ora pronta per la simulazione e lo streaming dei dati.

5.2 Configurazione lato Matlab

Dopo i passaggi precedenti il ROS network è già attivo, il passaggio successivo è la connessione lato Matlab

che avviene lanciando direttamente nel workspace il comando “rosinit(‘ROS master URI’)” nel quale

l’argomento è l’identificatore locale del master restituito a schermo con il lancio di “roscore” sul primo

terminal.

Anche da Matlab è possibile utilizzare i comandi “rosnode list”, “rostopic list” e “rosservice list” per avere

informazioni sullo stato della rete che a questo punto comprende tre nodi (Fig. 85).

98

Fig. 85: Stato della rete ROS dopo la configurazione Matlab-Vrep

Prima di proseguire è ora necessario affrontare alcune tematiche che differenziano la simulazione corrente da

quelle svolte negli ambienti di lavoro precedenti: la sintassi ROS in Matlab, la presenza di due diverse

origini nello spazio dei giunti ed in quello di Vrep ed il diverso tipo di controllo della base.

5.2.1 Sintassi ROS in Matlab

Per quanto Matlab sia interfacciabile con la rete ROS è importante ricordare che, perché non si creassero

conflitti con il linguaggio di programmazione del workspace, gli sviluppatori sono stati costretti ad

implementare una sintassi diversa per l’utilizzo del network.

Il concetto di base che differenzia l’utilizzo di Matlab dall’inserimento manuale di comandi da terminal è la

necessità di costruire strutture dati locali con la funzione di client/server o subscriber/publisher associate ad

invio e ricezione di messaggi. Una volta create queste strutture associate ed assegnato il tipo di messaggio da

trattare, il protocollo di comunicazione è decisamente snellito in quanto basta effettuare l’ordine di ricezione

o invio associandolo alle strutture delle quali Matlab già conosce le caratteristiche.

In Fig. 86 si ha la tipica sintassi per pubblicazione e ricezione su topic (in questo caso per il giunto numero1

dello YouBot .Si può osservare che i topic cui Matlab si associa sono già stati dichiarati in entrambi i casi da

Vrep il quale richiede specifici tipi di messaggio che Matlab riconosce grazie alla creazione di messaggi

custom ricavati da vrep_commons come spiegato in Appendice A nella sezione 8.2.6.2.

Fig. 86: Sintassi per i topic in Matlab

99

Considerazioni analoghe vanno fatte per i servizi che, tuttavia si distinguono per la presenza di servizi di sola

chiamata (a messaggio vuoto) come per esempio la richiesta di inizio simulazione.

in alcuni esempi tra i quali anche il service per il posizionamento dei giunti, molto utile per predisporre

permanentemente posizioni del robot nella scena prima che essa sia attiva e quindi a topic non ancora aperti.

Fig. 87: Sintassi per servizi ROS in Matlab

In questo caso le object handles dei giunti sono state impostate manualmente sulla base di una chiamata

dell’opportuno service “rosservice call /vrep/simRosGetObjectHandle X” da terminal (dove X è il nome

dell’oggetto di cui occorre determinale l’handle in Vrep).

Particolare attenzione va rivolta alle immagini ricevute da Vrep; occorre infatti effettuare due conversioni

per poterle efficacemente utilizzare tramite il sistema di processamento immagini.

Bisogna considerare in primis il fatto che i messaggi ROS per l’invio di immagini sono compressi ed

occorrerà quindi trasformarli in un formato utilizzabile (funzione “readImage”) a questo punto occorrerà

affrontare il fatto che le immagini importate dalla telecamera di V-REP sono del tipo “uint-8” ovvero

rappresentativo dei valori tristimolo con numeri a 8-byte e doppia precisione nel range [0 255]; occorre

trasformare ,’immagine in pixel nella tradizionale formulazione a doppia precizione nel range [0 1] mediante

la funzione “idouble” facente parte del machine vision toolbox.

Fig. 88: Inizializzazione subscriber immagini e relative conversioni

Ogni successiva elaborazione per l’ottenimento delle features di immagine è affrontata in Appendice B.

100

5.2.2 Gestione dell’offset di origine dei giunti

Come è stato accennato, coloro che hanno implementato il modello dello YouBot in Vrep hanno riferito i

giunti ad una posizione di origine diversa da quella utilizzata in Matlab (Fig. 30). Questa differenza arbitraria

in implementazione avrebbe reso impossibile controllare con successo il robot in Vrep con l’algoritmo

Matlab se non fosse stato introdotto un rapido sistema di conversione per portare avanti in parallelo le due

convenzioni.

La posizione nulla in Vrep è costituita dal braccio completamente disteso in verticale, posizione molto facile

da replicare anche in Matlab con la sola movimentazione dei giunti 2 e 4.

Fig. 89: Coordinate di origine in Vrep e corrispettivo Matlab

Si è verificato che per ottenere le configurazioni in Fig. 89 è necessario fornire in Matlab rotazioni di

a fronte delle coordinate nulle in Vrep. È facile utilizzare questa informazione per passare

agevolmente da una convenzione all’altra nel ciclo di controllo ad ogni iterazione per calcolo ed attuazione.

5.2.3 Controllo in velocità della base

Come accennato, per le simulazioni in Vrep è stato scelto il controllo in velocità per la piattaforma. ciò è

dovuto a due fattori principali: il primo è che, in un ambiente di simulazione è difficile avere una

101

rappresentazione realistica di attriti ed interazioni col suolo (il che risulterebbe in inevitabili slittamenti per

rotazioni impulsive) ma il secondo e più importante è la peculiare modellazione che è stata fatta per la base.

Se per la simulazione Matlab ci si è accontentati di una semplificazione dei gradi di libertà a giunti

prismatici, il maggior realismo di Vrep porta alla rappresentazione indipendente delle quattro ruote come

mosse da altrettanti giunti rotoidali. Il particolare tipo di ruote omnidirezionali ha comportato che i gradi di

libertà della base potessero essere riscritti come combinazioni dei contributi delle singole ruote in senso

concorde e non.

Per semplicità sono state introdotte le velocità di avanzamento e di movimento laterale (oltre alla rotazione

non utilizzata) e, ad ogni iterazione, il movimento complessivo alle singole ruote è stato valutato come in

Fig. 90 (i dati vengono passati secondo lo stesso sistema di publishing visto per i giunti).

Fig. 90: Ripartizione della velocità di base sulle singole ruote

Oss: occorre fare attenzione poiché l’ordine dei contributi nei vettori che moltiplicano le velocità è

dipendente da quello con cui sono state importate da ROS le velocità delle ruote; per evitare confusione si è

scelto di mantenere una nomenclatura che rendesse facile identificare la singola ruota: i publisher agiscono

su oggetti caratterizzati da una prima lettera “r” o “f” per retro e fronte (rear e front) ed una seconda per

destra e sinistra “r” o “l” (right e left) .

5.3 Risultati della simulazione

Dopo aver adattato con le modifiche indicate sopra l’algoritmo Matlab al nuovo ambiente di simulazione e,

dopo considerevoli cambiamenti del sistema di processamento immagini (per gestire un reale segnale RGB a

macchie di colore, Appendice B) è finalmente stato possibile passare alle simulazioni vere e proprie.

Per evitare di appesantire la trattazione con troppe informazioni ridondanti ci si riferisce agli stessi parametri

del caso di studio con affrontato in Matlab in 3.5.1 con alcune modifiche elencate di seguito:

102

Posizione dell’obiettivo [-0.7 0.15 0.4] m nel sistema di riferimento di Vrep

Robot disposto di lato con esplorazione sul fianco

Risultati triangolazione:

Fig. 91: Risultati di image processing dal primo punto di triangolazione

In Fig. 91 due fasi dell’ispezione e, a destra, l’immagine col centroide del frutto sufficientemente vicino al

centro immagine per l’inizio della triangolazione; in Fig. 92 il secondo punto della procedura.

Fig. 92: Spostamento al secondo punto di triangolazione

103

Si è riscontrata, come in questo caso, una buona precisione della tecnica di triangolazione per distanze di

raccolta “convenzionali” ma, al contrario di quanto avviene in Matlab, si può osservare un notevole

peggioramento in caso di oggetti troppo vicini o troppo lontani al sensore ottico; si è ipotizzato che questo

possa essere dovuto all’influsso di illuminazione simulata e del tipo reale di immagine non ottenuta per

punti.

È ora possibile passare alla fase di controllo che, in quanto modificata a causa del controllo in velocità, è

stata affrontata con costanti di controllo più blande ( e

dimezzati). A causa di una possibile lentezza

anche dovuta al più oneroso processamento di immagini si è scelta una condizione di uscita sulla profondità

meno severa e fissata a 0.01m . Un centimetro di errore sarà sicuramente accettabile in casi reali per i quali,

come si vedrà in seguito, la stessa fase di “grasping” dell’end-effector gode di una certa tolleranza.

In Fig. 93 i risultati in termini di profondità stimata ed in Fig. 94 quelli dell’errore sul piano immagine.

Fig. 93: Profondità stimata in controllo su Vrep a sinistra, a destra immagine in avvicinamento

Fig. 94: Errori sul piano immagine in controllo su Vrep

104

Si può osservare che l’abbattimento degli errori segue gli andamenti previsti anche se è presente in direzione

una piccola sovra elongazione negativa; si è deciso di non diminuire le costanti proporzionali né aumentare

le derivative in quanto l’escursione è contenuta e, soprattutto, la simulazione risulta già considerevolmente

rallentata rispetto a quanto visto precedentemente senza un realistico processamento delle immagini.

Ciò che non è stato previsto è il modo in cui il manipolatore si è avvicinato all’obiettivo: la nuova

configurazione delle ruote sembra aver reso particolarmente conveniente, nell’inversione dello Jacobiano,

l’utilizzo della sola base per l’avanzamento mentre il braccio è relegato al mantenimento dell’oggetto nel

campo visivo. A priori questo non è necessariamente un male ma, in un possibile frutteto reale, è

impensabile che il raccoglitore possa rischiare di collidere con gli alberi.

La soluzione a questo problema è stata l’implementazione di una seconda fase di controllo che viene attivata

non appena si supera una soglia di profondità (in questo caso fissata a 0.3m). Nella seconda parte

dell’avvicinamento le velocità della base saranno azzerate ed il problema sarà risolto in modo ipovincolato

dal solo braccio per i gradi di libertà che è possibile controllare; cogliendo l’occasione del nuovo sistema di

controllo si scelgono a questo punto costanti e

triplicate rispetto alle precedenti per continuare un

rapido avanzamento nonostante i piccoli errori (le altre condizioni sono invariate a fini di confronto).

Fig. 95: Profondità dopo l'implementazione del secondo controllo a sinistra, estensione del braccio a destra

In Fig. 95 si nota il cambio di tendenza e, dall’imagine del robot è evidente un’estensione molto maggiore

del braccio; in Fig. 96 si può notare che la direzione beneficia di una diminuzione dell’errore mentre la

pare inalterata. Ciò che è evidente è comunque la considerevole riduzione del tempo impiegato grazie alla

variazione delle costanti.

105

Fig. 96: Errori sul piano immagine con la seconfa fase di controllo

In questa simulazione il manipolatore è, volutamente, stato studiato ben lontano dalle condizioni di

singolarità cinematica ma, anche in questo caso, il numero di condizionamento può essere utile a

comprendere meglio le dinamiche dell’avvicinamento.

Sopra sono state commentate zone di variazione degli errori ma non è facile identificare, senza conoscere la

condizione imposta sulla profondità, il momento di attivazione del secondo controllo; come si è visto in

Matlab, anche lontano dalla singolarità la distensione del braccio ha importanti effetti sul numero di

condizionamento e , confrontando i casi è facile notare l’istante di attivazione attorno a 27 secondi (Fig. 97).

Fig. 97: Condizionamento di J nei due casi di controllo

In queste ultime simulazioni sono state apprese molte cose su effetti del’elaborazione d’immagine,

separazione dei regimi di controllo, implementazione ROS e tempistica delle stesse: si è ora pronti per la

sperimentazione.

106

6 Sperimentazione

Tutti i livelli di simulazione affrontati finora sono stati propedeutici a quest’ultima parte del lavoro di tesi; è

infatti solo con la sperimentazione sulla macchina reale che è possibile essere certi del buon funzionamento

di un algoritmo o, in caso contrario, di toccare con mano le difficoltà per comprenderle ed eventualmente

superarle.

Questo capitolo si comporrà di quattro sezioni:

Una descrizione di materiale e setup sperimentale

Il test per validare l’algoritmo vero e proprio

Una sperimentazione sugli effetti del posizionamento dell’obiettivo

Una sperimentazione sugli effetti dell’occultamento del frutto

6.1 Materiale e preparazione

6.1.1 Strumentazione

Il robot KUKA YouBot è stato messo a disposizione per le sperimentazioni presso il laboratorio “Merlin”del

Dipartimento di Elettronica, Informazione e Bioingeneria del Politecnico di Milano (DEIB); in laboratorio

sono stati effettuati esperimenti con il seguente tipo di strumentazione:

Computer portatile, le cui specifiche sono riportate in Tabella 5:

Hard-disk esterno con la partizione Ubuntu 14.04 ottenuta come in Appendice A;

Webcam Microsoft LifeCam HD;

Frutto obiettivo: è stato utilizzato un gomitolo di lana rossa di dimensioni [0.08-0.075]m

Pannello di colore neutro da usare come sfondo per evitare eventuali disturbi visivi al robot;

Cavo Ethernet per collegare il laptop al robot;

Tabella 5: Specifiche del calcolatore

Processore Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz

Memoria 8.00 GB DDR3 1.6MHz

Grafica NVIDIA GeForce GTX 860M

Harddrive 1 TB con 7200rpm

107

6.1.2 Preparazione software

Per quanto riguarda la preparazione software si sono adottate le seguenti procedure:

Lancio del ROS Master (roscore)

Lancio del ROS Wrapper a robot connesso

Configurazione ROS-Matlab con attivazione dei publisher e subscriber (uno per giunto,

comunicanti grazie a messaggi di tipo brics_actuator)

Attivazione della webcam

Tutte le operazioni elencate sono descritte nel dettaglio in Appendice A quindi si procede solo ad esaminare

quanto si differenzia da ciò che è stato già trattato.

È importante notare che, durante l’inizializzazione della telecamera viene automaticamente settata una

risoluzione di 1280x800 pixel anziché la consueta 1280x720, occorrerà agire di conseguenza.

Tabella 6: Configurazione webcam da Matlab

6.1.3 Calibrazione e registrazione degli offset

Con il lancio del ROS wrapper, lo YouBot effettua automaticamente la calibrazione dei finecorsa in modo da

impostare poi il resto della sua movimentazione sulla base di uno specifico sistema di coordinate assolute.

Questa conoscenza automatica della posa rispetto ai finecorsa permette al robot di restituire messaggi di

errore anziché andare a sbattere contro i limiti.

Se è vero che il sistema di coordinate dei giunti del wrapper offre dei benefici è anche importante

considerare che lato Matlab occorrerà di nuovo implementare misure per la coerenza del controllo a

computer e l’attuazione.

108

La posizione di riferimento per valutare gli offset delle escursioni è stata di nuovo quella con il braccio

disteso in modo completamente verticale; dopo precise regolazioni lato Matlab per portare in posizione

adeguata ogni giunto è stato possibile mappare le corrispondenze.

Per comodità di utilizzo sono state scritte le funzioni Matlab “MatJoint2ROS” e “ROSJoint2Mat” con i

rispettivi compiti di traduzione dei posizionamenti. A titolo di esempio si mostra una delle funzioni:

Fig. 98: Passaggio delle coordinate dei giunti Matlab-ROS

Un’altra differenza introdotta dal wrapper a proposito del controllo è il fatto che le velocità della base

vengono di nuovo date come se fossero giunti prismatici quindi non occorre più convertire le rotazioni delle

ruote.

Accanto al fondamentale tipo di offset appena visto non bisogna dimenticare la presenza dei parametri

estrinseci legati al montaggio della videocamera; da altre sperimentazioni è stato trovato un alloggiamento

per la webcam direttamente in-hand ed è stato mantenuto con le relative quote per l’implementazione

dell’algoritmo.

6.1.4 Preparazione dell’area di lavoro

Prima di effettuare i test con l’osservazione ambientale nella fase di ispezione si è cercato, per quanto

possibile, di nascondere tutti gli oggetti dal colore che potesse dare problemi al robot; la soluzione migliore

che è stata trovata è consistita nell’impiego di un pannello per occultare gli oggetti più grandi ed un sistema

di processamento immagini in grado di scartare gli oggetti del colore opportuno ma troppo piccoli.

109

Per questo motivo è stato introdotto il parametro “soglia_pixel” nella funzione “Im_Processing” in

Appendice B che esclude le macchie di colore di taglia non accettabile sulla base della sola immagine

ricevuta. A rigore questo approccio nega il raggiungimento di frutti troppo lontani ma si suppone che la

raccolta avvenga tra i filari di un frutteto e quindi a distanze dell’ordine di pochi metri.

Per il resto si è cercato di garantire la migliore illuminazione possibile all’area di lavoro appositamente

liberata dal materiale presente in precedenza; si è quindi potuto procedere al posizionamento dell’obiettivo

fissandolo mediante nastro adesivo al pannello introdotto in precedenza.

Fig. 99: Robot in avvicinamento al frutto obiettivo vincolato al pannello

6.2 Validazione dell’algoritmo

La fase di sperimentazione è stata fondamentale in quanto ha spinto ad interrogarsi su tematiche che in

simulazione non erano state considerate:

L’utilizzo in publishing dei topic di ROS non è “sincrono” con il resto dello script: con Vrep questo

era poco visibile in quanto i tempi di transito dei dati sullo stesso computer erano esigui ma, dopo la

pubblicazione sul topic, lo script prosegue immediatamente ed indipendentemente dal fatto che

magari l’utenza subscriber del topic non abbia ancora reagito. Un caso evidente di questo fenomeno

110

si è sperimentato in ispezione verificando che, in assenza di opportune pause, la telecamera scattava

immagini mentre il braccio era ancora in movimento.

Le informazioni pubblicate sui topic permangono a meno che il publisher non le modifichi: se si

raggiunge l’uscita dall’algoritmo con una velocità ancora assegnata è necessario azzerarla o il robot

continuerà a tenerla fuori dal controllo.

Il processamento dell’immagine ed il tempo di attuazione del robot non sono per niente trascurabili

nella determinazione del tempo di iterazione.

L’imposizione di condizioni di uscita troppo rigide al ciclo può portare ad esecuzione molto più lente

che in teoria e, talvolta, inattuabili. Ci si limita a:

Queste ed altre considerazioni hanno portato all’adozione di diversi sistemi di sicurezza ed allarmi tra i quali

i più importanti sono:

L’obbligato azzeramento delle velocità a qualunque uscita dal ciclo

L’uscita immediata dal ciclo in caso di perdita dell’obiettivo : per percepire la perdita dell’immagine

la funzione “Im_Processing” restituisce valori “Nan” (not a number) che attivano i sistemi di arresto.

Più severi limiti sul numero di condizionamento dello Jacobiano

Limitatori di velocità alle ruote.

6.2.1 Strategie di controllo

La presenza dei problemi presentati ha portato a due strategie per il controllo:

L’impiego di costanti di controllo simili a quelle usate in precedenza ma esercitate per tempi di

integrazione brevissimi ed inframmezzati da pause per permettere calcolo e lettura dei topic.

Ciò equivale ad effettuare un controllo senza limitazioni sul tempo minimo ma dilatato da intermezzi

di attesa.

L’impiego di. adeguatamente più alti (coerenti con tempi di calcolo e processamento immagine)

ma applicati con costanti di controllo molto piccole per minimizzare la gravità degli effetti di

sovrapposizione o mancato invio tra messaggi nuovi dei topic.

Entrambi i metodi sono stati testati ed arrivano a convergenza ma, l’introduzione delle pause nel primo, lo

rende meno fluido nei movimenti ed è quindi preferito il secondo per il resto della sperimentazione.

Si è scelto un , circa il doppio del tempo di processamento immagine; si usano le seguenti

costanti:

111

Come per l’ultima simulazione in Vrep è stato implementato un diverso ciclo di controllo per la zona

terminale dell’avvicinamento; in questa fase la costante per l’avvicinamento in z è tripla.

6.2.2 Prova del metodo

Si riportano ora i dati di una sperimentazione di successo perché possano essere commentate le differenze

dai modelli simulati:

Dimensioni e posizionamento ellissoide e parametri obiettivo:

Dimensioni m

Risultati triangolazione:

In Fig. 100 l’andamento in profondità ed in quello degli errori sul piano immagine:

Fig. 100: Profondità in avvicinamento

112

Fig. 101: Errori rispetto al centro del piano immagine

L’andamento degli errori sul piano immagine presenta notevoli irregolarità, soprattutto nella prima parte; per

avere una visione di questi scostamenti contestualizzati rispetto ai valori cui si riferiscono è preferibile

sovrapporre gli andamenti desiderati a quelli registrati come in Fig. 102:

Fig. 102: Andamenti nel piano dell'immagine

113

Dal confronto con i valori di riferimento del centro immagine si può dedurre che il sistema di controllo sta

comunque funzionando perché nel tempo tende a riportare attorno ai valori desiderati le coordinate del

centroide. Esisteranno evidentemente elementi di disturbo che mettono alla prova il controllore nella prima

fase ma, da 20 o 25 secondi in poi diventano trascurabili.

La giustificazione che si è data a questi fenomeni è da attribuirsi al comportamento irregolare delle ruote che,

come si nota dal grafico della profondità stimata, si disattivano attorno al secondo 25 (in corrispondenza con

la profondità a 0.3 m).

Il suddetto comportamento delle ruote può essere dovuto principalmente a:

Gli effetti dell’irregolarità del “terreno” in laboratorio e la non linearità del contatto con le ruote

omnidirezionali le quali sono progettate per pavimentazioni lisce.

Gli effetti di inversione di moto e di “lost motion” per componenti elettromeccaniche di rigidezza

non infinita. Non si hanno contributi di errori di inversione in profondità in quanto, naturalmente,

l’avvicinamento avviene sempre nella medesima direzione.

Gli effetti degli attriti secchi e le problematiche di stick-slip connesse al controllo in basse velocità.

Tutto sommato il comportamento è da ritenersi accettabile e la convergenza ottenuta è avvenuta con stima

accurata del punto di arresto reale (circa 21 centimetri).

L’algoritmo si è dimostrato in grado di guidare efficacemente il controllo e la fase di triangolazione si è

dimostrata molto accurata.

6.3 Effetto del posizionamento

Come si è visto fin dalle simulazioni Matlab nel capitolo 3 la posizione dell’oggetto obiettivo riveste un

ruolo importante per la sua raggiungibilità e la stessa capacità di raggiungere posizioni diverse è una dote

importante per valutare la robustezza del sistema.

Si è deciso di effettuare una serie di prove proprio per stimare questa tolleranza del sistema a varie

condizioni di lavoro; l’interesse è particolare perché non solo si hanno le condizioni di fallimento dovute alle

singolarità cinematiche ma compaiono anche gli effetti ci cattiva illuminazione ed irregolarità nel mondo

reale.

Per condurre la prova si è deciso di suddividere il pannello sul quale viene abitualmente fissato il frutto in

una serie di riquadri, ognuno da associare ad una specifica prova di raccolta con il robot in partenza ad ogni

prova da un medesimo punto marcato da nastro isolante sul terreno.

114

In Fig. 103 l’impostazione per le prove su una larghezza di circa 1 m tra 20 ed 80 cm dal pavimento.

Fig. 103: Riquadri per le prove di posizionamento del frutto

Sono state svolte 4 prove per ogni quadrante per avere un’idea del numero di successi ottenibili:

Successo raccolta Colonna 1 Colonna 2 Colonna 3

Riga 1 100% 100% 75%

Riga 2 75% 100% 50%

Tabella 7: Risultati prove di posizionamento

Di seguito una sequenza di fotografie scattate in una fase di avvicinamento.

Tabella 8: Avvicinamento ad una posizione obiettivo

Si sono evidenziati problemi di illuminazione nella parte bassa, soprattutto a destra.

115

È stato fatto anche un tentativo di raccolta più in alto degli 80 cm di altezza dei riquadri, l’avvicinamento si è

interrotto a causa dell’attivazione dell’allarme più restrittivo (200) sul numero di condizionamento; in Fig.

104 si possono confrontare l’andamento “sano” di un caso lontano dalla singolarità e quello appena descritto.

Fig. 104: Andamento accettabile del numero di condizionamento e caso interrotto

6.4 Effetto dell’occultamento

Come per il caso del posizionamento, anche qui sono state svolte diverse raccolte ad occultamento parziale

crescente; sono state affrontate fasce dal 10 al 70% di occultamento, si riportano di seguito i casi estremi:

Occultamento minore del 10% (comportamento indistinguibile da quello normale)

Fig. 105: Profondità stimata ed immagine pre-triangolazione ad occultamento <10%

116

Fig. 106: Andamento sul piano dell'immagine ad occultamento < 10%

Occultamento tra 50% e 70% ( da triangolazione )

Fig. 107: Profondità stimata ed immagine pre-triangolazione ad occultamento tra 50% e 70%

L’algoritmo è andato a convergenza per quanto, nel mondo reale, si abbia un errore di posizionamento in

profondità di circa 5 cm; questo è sicuramente dovuto al fatto che, in avvicinamento, il robot si è trovato

costretto ad affrontare ellissi dai diametri di proporzioni diverse da quelle triangolate causa del cambio di

occultamento. In sostanza non basta l’occultamento in sé a fermare l’algoritmo ma è il cambio di

proporzione dell’oggetto che si ha in movimento a falsare le distanze stimate. Entro il 50% non si sono

riscontrati problemi di alcun genere perché vi era sempre una sufficiente area esposta.

117

7 Conclusioni

Il lavoro svolto per questa tesi si conclude con una riflessione su quanto è stato svolto e su quello che resta

ancora necessariamente aperto a sviluppi futuri.

7.1 Cosa è stato ottenuto

Dall’analisi dello stato dell’arte in tema di ottimizzazione tecnologica della raccolta di frutta è emerso che le

procedure, per ora più produttive, basate su approcci massivi sono affette da ineliminabili difetti per impatto

ambientale e capacità di controllo del processo. Un tipo di raccolta alternativa, l’automatic harvesting,

consentirebbe di superare questi problemi ma i primi sistemi efficienti ed adeguatamente controllati hanno

visto uno sviluppo vicino alla maturità solo negli ultimi anni e con costi di investimento proibitivi.

In questo quadro si colloca la ricerca fatta in questa tesi e volta allo sviluppo di un algoritmo funzionante, di

economica realizzazione pratica (schema a sola videocamera monoculare), facilmente adattabile a

macchinari diversi dal robot di simulazione e riutilizzabili (di qui anche la scelta della versatile

implementazione su meta sistema operativo ROS).

Dopo lo sviluppo di tecniche personalizzate di acquisizione immagine e triangolazione è stato possibile

lavorare ad un ciclo di controllo a rotazione e traslazione disaccoppiate in grado di portare a termine le

operazioni di avvicinamento per la raccolta sia in ambienti software di pura modellistica quali Matlab e

Simulink, sia in Scene Vrep utilizzatrici di simulatori fisici dal comportamento del tutto analogo a quello

ottenibile nella realtà.

Le prove di laboratorio sul robot fisico sono servite, oltre a valutare robustezza e limitazioni del sistema

utilizzato, anche a prendere coscienza di problemi che sarebbero stati difficili da prevedere solo in teoria.

La realizzazione del ponte ROS tra Matlab ed il wrapper del robot di simulazione in modo analogo a quanto

fatto virtualmente in ambiente Vrep ha oltretutto velocizzato di molto la trasposizione da simulazione a

mondo reale. L’architettura ROS impostata ha anche il pregio di costituire un ottimo punto di partenza per

esperienze additive in grado di aggiungere contenuti e complessità a quanto proposto in questa tesi.

7.2 Sviluppi futuri

Questa tesi ha coperto molti aspetti importanti per l’implementazione di un sistema di raccolta automatizzato

ma è ben lontana dall’ avere esaurito le tematiche su cui è necessario indagare per una applicazione realistica

ed ottimizzata.

118

Prima di concludere sembra dunque opportuno nonché doveroso almeno nominare i principali filoni di

ricerca sui quali è ancora necessario lavorare:

Per l’applicazione di un algoritmo come quello proposto in un frutteto reale è indispensabile

elaborare un adeguato sistema di obstacle avoydance per evitare collisioni ed incidenti.

Occorre strutturare un a routine generica con pianificazione dei percorsi ed un sistema di scelta tra

obiettivi multipli, possibilmente ottimizzato per lo schema di raccolta più efficiente.

Se si pensa ad un tipo di raccolta come quello proposto ma su vasta scala sono interessanti le

possibilità offerte da robot multipli e coordinati in remoto tramite l’interfaccia ROS.

Possono essere implementati metodi sofisticati per l’aggiramento delle singolarità del robot e per

gestirne la dinamica nell’interazione con l’ambiente.

Accanto ai filoni di ricerca concettuali si può parlare di cosa manca a livello di una macchina fisica si

possono prendere in esame questi punti:

Lo studio di un manipolatore con un organo terminale in grado di raccogliere in modo ottimale la

frutta: ampie ricerche sono state fatte in questi anni nelle direzioni di aspiratori a tubo flessibile,

gripper flessibili e più o meno complessi sistemi per la separazione del frutto dal ramo.

Messa a punto di una base mobile in grado di affrontare terreni sconnessi mantenendo gradi di

libertà ed equilibrio.

La scelta di filtri ottici ad opportuna lunghezza d’onda per semplificare e quindi velocizzare

notevolmente il tempo di processamento immagine che oggi è uno dei limiti più stringenti per

l’aumento delle prestazioni.

Naturalmente, in futuro, nuovi sviluppi scientifici e l’abbassamento del costo della potenza di calcolo

renderanno più competitivo questo tipo di tecnologia che già oggi comincia ad interessare investitori in

ambiti agricoli e non; quello che è certo è che la ricerca proseguirà e, con essa, l’interesse per ciò che, pur ad

uno stadio non definitivo, si presenta come innovazione.

119

8 Appendice A

8.1 Panoramica sull’ambiente ROS

8.1.1 Cos’è ROS

Il Robot Operating System è definito sul sito ufficiale “ROS.org” come un meta sistema operativo open

source con le seguenti caratteristiche:

“ROS (Robot Operating System) fornisce librerie e tools per aiutare gli sviluppatori a creare applicazioni

robot. Esso fornisce astrazione dell'hardware, driver dei dispositivi, librerie, strumenti di visualizzazione,

comunicazione e scambio di messaggi tra processi (message passing), gestione dei pacchetti e molto altro.

ROS è rilasciato sotto una licenza open source, BSD license”

In pratica ciò si traduce nel fornire agli sviluppatori i mezzi per la costruzione e la gestione di un sistema di

transito per informazioni e procedure potenzialmente distribuito su una rete di macchine.

Si tratta di un meta sistema operativo nel senso che, come i più diffusi sistemi operativi, include astrazione

dell’hardware e controllo delle periferiche a basso livello ma, oltre a ciò, fornisce strumenti e librerie per

scrivere, compilare ed eseguire codice su più calcolatori in tempo reale; una prima differenziazione da altre

piattaforme software per la gestione dei robot può essere dunque l’enorme flessibilità offerta da

un’architettura dei processi in corso (ROS Graph) sviluppata come una rete peer-to-peer le cui regole di

comunicazione vengono coordinate dall’infrastruttura ROS; la struttura peer-to-peer ha il pregio di rendere

più snello il transito dei dati tra le utenze in rete poiché esse possono scambiare dati vicendevolmente senza

farli passare attraverso l’utenza server della rete stessa che ha così solo il ruolo di risolvere indirizzi e nomi.

Al momento le distribuzioni ufficiali di ROS sono state testate e rilasciate solo per sistemi operativi basati su

Unix (i.e. Linux e OS X); ci sono stati in passato tentativi di sviluppo di una versione sperimentale per

Windows (con ROS Hydro) ma, di fatto, la compatibilità è stata lasciata alle possibilità di sviluppo di terze

parti.

La versione R2015a di Mathworks Matlab è la prima a supportare in modo nativo un toolbox in grado di

comunicare (almeno limitatamente) con un network ROS; questa stessa tesi si propone di sondare le

possibilità offerte da questo nuovo toolbox per il controllo dei robot.

120

8.1.2 Storia e scopo di ROS

ROS è un progetto di ampio spettro nato a partire dal 2007 grazie alla combinazione di molteplici sforzi: in

primis dei gruppi di ricerca dello Stanford Artificial Intelligence Laboratory nell’ambito della robotica

(STAIR) e, in seguito, del laboratorio Willow Garage che ha aperto nel 2013 una campagna di ricerca estesa

all’Open Source (ci sono ora in tutto il mondo migliaia di utenti che lavorano autonomamente contribuendo

al progetto).

A partire dal 2010 si sono susseguite, con funzionalità progressivamente rivedute ed ampliate, le seguenti

distribuzioni: ROS 1.0, Box Turtle, C Turtle, Diamondback, Electric Emys, Fuerte, Groovy Galapagos,

Hydro Medusa, Indigo Igloo (dal 2014 noto per la sua stabilità ed utilizzato in questa tesi) ed il più recente

Jade Turtle.

Uno dei fattori che hanno portato allo sviluppo di ROS è stato il livello di complessità raggiunto nei primi

anni 2000 dai settori di robotica ed automazione in generale; erano infatti già stati scritti per moltissime

macchine set di driver e programmi dedicati ad applicazioni specifiche.

Il problema di questo approccio single purpose per la programmazione limitata ad ambiti particolari era la

necessità di riscrivere il codice pressoché integralmente ad ogni cambiamento di macchine ed applicazioni.

Da quando, nel 2013, ROS si è aperto all’open source , il suo scopo è stato invece proprio quello di creare

una community in grado di non ripetere inutilmente esperienze già fatte e di supportarsi autonomamente, a

livello globale, grazie alla condivisione ed all’accumulo dei contributi di team di lavoro diversi, dai gruppi di

hobbisti locali ai grandi sistemi industriali che basano la loro automazione sull’architettura ROS.

Ai fini di soddisfare i bisogni di collaborazione per una sempre crescente comunità di sviluppatori autonomi

diversi, ROS è stato, fin dal suo concepimento, dotato delle particolarità che tuttora lo caratterizzano:

Design modulare e distribuito: non è necessario imparare ogni dettaglio dei pacchetti di sistema

per costruire modelli funzionanti. In ogni istante è possibile scegliere se utilizzare funzioni

sviluppate da altri o creare le proprie per interagire con i sistemi di interesse.

Estrema flessibilità per tipo e numero di macchine gestite contemporaneamente. La stessa sintassi

può essere facilmente riadattata per i robot più disparati e la natura della rete permette di coordinare

implementazioni multi macchina come quelle su scala industriale.

Indipendenza dal linguaggio di programmazione specifico: perché la programmazione a più mani

fosse agevole ed i packages riutilizzabili era necessaria un’interfaccia comune sulla quale fosse

possibile compilare correttamente librerie scritte in tutti i più diffusi linguaggi di programmazione

(tra i tanti supportati Python, C, C++, Lisp, Java e Lua).

Standardizzazione del codice: è possibile applicare approcci di programmazione simili a robot

diversi (come robot industriali e quadcotteri) proprio perché ROS permette di astrarre la

121

messaggistica di controllo dai driver locali; ciò apre molte possibilità per condivisione e riutilizzo di

software anche per scopi nemmeno previsti inizialmente.

Licenza BSD: per un progetto del tipo descritto era necessario garantire agli utenti una adeguata

libertà di manipolazione il che, espresso in termini legali, corrisponde ai quattro punti che

caratterizzano la licenza ROS:

1. Libertà di eseguire il programma per qualsiasi scopo

2. Libertà di studiare il programma e modificarlo.

3. Libertà di ridistribuire gratuitamente copie del programma in modo da aiutare il prossimo.

4. Libertà di migliorare il programma e di distribuirne pubblicamente i miglioramenti, in modo

tale che tutta la comunità ne tragga beneficio.

8.1.3 Struttura concettuale di ROS

Si è finora discusso in termini qualitativi delle potenzialità di questo meta sistema operativo ma non è ancora

stata esaminata in senso pratico l’architettura vera e propria del progetto; non è semplice riassumere ogni

aspetto del framework ROS ma nei prossimi paragrafi si tenterà comunque di fornirne una mappa

concettuale.

Strutturalmente ROS si sviluppa su 3 livelli: Filesystem Level, Computational Level e Community Level.

(Spiegazioni dettagliate si trovano all’indirizzo: http://wiki.ros.org/ROS/Concepts )

8.1.3.1 Filesystem Level

Il Filesistem Level non è altro che l’organizzazione in cartelle delle risorse utilizzate in ROS, in particolare

Packages, Metapackages, Package Manifests, Stacks e Repositories, MessageTypes( msg ) e ServiceTypes

(srv).

Packages: sono moduli che possono contenere il lancio di un nodo ROS, un file di configurazione,

una libreria, software di terze parti ed altre componenti eseguibili; è la più piccola unità funzionale

compatta direttamente condivisibile per l’utilizzo in ROS.

Metapackages: particolari Packages “vuoti” contenenti solo informazioni circa il legame per

l’interazione tra altri moduli.

Package Manifests: singoli file di intestazione con i metadati (nome, versione, licenza ed altro) dei

singoli Packages

Stacks e Repositories: sono in ROS il meccanismo primario per la distribuzione del software e sono

raccolte di Packages con il comune scopo di partecipare allo svolgimento di un determinato compito

(includono dipendenze dal altri Stacks )

MessageTypes( msg ) e ServiceTypes (srv): rispettivamente definiscono le strutture dati con le quali

possono essere scritti messaggi in ROS e le strutture di chiamata e risposta associate a servizi.

122

8.1.3.2 Computational Level

ROS è basato su di un’architettura a grafo (ROSGraph) nella quale il processamento avviene in nodi (nodes)

che comunicano tra loro in modo asincrono attraverso l’uso di topic ai quali possono sottoscrivere e/o sui

quali possono pubblicare ed in maniera sincrona mediante la chiamata di servizi (services).

Nodes: i nodi sono le entità della rete ROS che effettuano le computazioni ed interagiscono fra loro

(possono essere programmate con opportune librerie su diversi linguaggi di programmazione)

Master: è un nodo con la funzione di server centralizzato che offre agli altri nodi un servizio di

registrazione e di naming, similmente all’informazione data da un server DNS. Permette infatti al

singolo nodo di contattarne un secondo e tiene traccia, per ogni singolo topic, dei relativi pubblisher

e subscriber (allo stesso modo gestisce i servizi tra server e client). È sempre il Master ad offrire il

Parameter Server.

Messages: i messaggi sono l’unità di scambio di informazione tra nodi e possono variare in

complessità da semplici numeri interi ad elaborate strutture dati.

Topic: strumento di comunicazione asincrono ed unidirezionale tra nodi che pubblicano e quelli che

sottoscrivono (sono tracciati dal master e vi possono essere scritti messaggi la cui sintassi sia tra

quelle previste al momento della creazione)

Fig. 108: Comunicazione via Topic

In Fig. 108 si può osservare che, perché avvenga la comunicazione via topic, deve essere avvenuta

una fase di “advertising” lato Publisher e la corrispondente “subscription” sotto il monitoraggio del

nodo Master che funge da server di tipo XML-RPC per le chiamate alle procedure della rete. I

processi di comunicazione già instaurati scambiano invece messaggi secondo protocolli TCP di

trasporto unidirezionale peer to peer senza più coinvolgere il Master.

123

Service: i servizi rappresentano il mezzo di comunicazione sincrono secondo una semantica di tipo

domanda/risposta; permettono, dopo aver definito i ruoli del server e del client, di richiedere

puntualmente l’esecuzione di procedure specifiche.

Parameter server: consente l’allocazione di parametri e dati presso il Master in modo che siano

accessibili da tutta la rete.

Bags: strumenti di raccolta dati in un determinato formato rosmessage per lo stoccaggio in locale

(rende possibile salvare ed inviare l’intera raccolta anziché il solo dato corrente).

8.1.3.3 Community Level

L’ultimo livello del progetto non è propriamente legato al funzionamento della rete ROS ma è propedeutico

ad esso in quanto costituisce il livello della comunicazione con l’utente per l’ottenimento di script ed

informazioni necessarie all’utilizzo della piattaforma;

Distributions: raccolte di stacks direttamente scaricabili ed installabili per ottenere facilmente

un’interfaccia completa delle funzioni di base (è per esempio il caso degli stacks associati

all’installazione di Indigo Igloo discussa in seguito).

Repositories: Codici sviluppati e pubblicati da enti esterni e condivisione di packages da parte di

sviluppatori autonomi (è il caso dei file scaricati in seguito per lo YouBot wrapper)

ROS wiki: l’ufficiale fonte di informazione e documentazioni per quanto riguarda tutorial e pacchetti

del progetto.

Tutti i livelli del progetto ROS contribuiscono a rendere questo meta sistema operativo un valido strumento

per l’implementazione flessibile di applicazioni robotiche

124

8.2 Percorso di implementazione della rete ROS

8.2.1 Premesse all’implementazione

Per prima cosa è stato necessario scegliere un sistema operativo in grado di far funzionare tutte le

componenti necessarie al controllo. È importante precisare che, grazie alla natura distribuita del ROS

network, non sarebbe in teoria assolutamente necessario che tutto il software di cui ora si discuterà sia

installato sulla stessa macchina. Solo al fine di minimizzare il tempo di esecuzione e per compattezza si è

deciso di assegnare tutti i nodi della rete sul medesimo calcolatore.

Di seguito vengono motivate le scelte che hanno portato al setup software definitivo.

Il primo requisito del sistema è la possibilità di supportare una versione ROS compatibile con il software del

ROS wrapper (il cui funzionamento sarà descritto nel corso di questo capitolo) per lo YouBot; ciò impone la

scelta di un sistema Linux Ubuntu ed una distribuzione di ROS scelta tra: Fuerte Turtle, Groovy Galapagos,

Hydro Medusa ed Indigo Igloo.

Per l’implementazione dell’algoritmo è stato scelto Matlab a causa delle sue ottime potenzialità di gestione

dei calcoli matriciali e della rapidità della programmazione manuale senza necessità di pre-compilazione. In

particolare la versione R2015a è la prima a supportare in modo nativo un toolbox in grado di interfacciarsi

con ROS. In un secondo momento sono stati oltretutto aggiunti dei toolbox per la generazione di messaggi

custom ROS e per l’utilizzo della webcam da Matlab.

La scelta di Matlab R2015a ha comportato la necessità di un sistema a 64 bit (da dopo R2012a non sono

disponibili distribuzioni Linux di Matlab in 32 bit) e, compatibilmente con le necessità di prima, del sistema

operativo Ububtu 14.04 Lts (essendo una versione long term support si tratta oltretutto di un prodotto

particolarmente adatto per utilizzi futuri); ciò ha comportato a sua volta che la versione ROS supportata fosse

Indigo igloo (tra l’altro raccomandato da ROS.org per la sua stabilità).

Come spiegato in seguito sarà necessario ottenere una versione del ROS wrapper per lo YouBot compatibile

non da Debian ma come sorgente da un catkin workspace, ciò permetterà a Matlab di avere accesso alle

relative librerie di servizi e messaggistica ROS.

Per la parte di simulazione è stato utilizzato Vrep nella versione compatibile con le necessità di sopra.

Ricapitolando, il setup software utilizzato per tutta l’implementazione è composto come segue:

Sistema operativo: Ububtu 14.04 Lts (Trusty) 64bit

Distribuzione ROS Indigo Igloo

V-REP PRO EDU V3.2.2 distribuzione Linux 64 bit

125

YouBot ROS wrapper per Indigo (installation by source)

Matlab R2015a 64 bit per Linux

Espansione Matlab: “Robotics System Toolbox Interface for ROS Custom Messages”

Supporto hardware Matlab: “USB Webcam Support”

Nelle prossime pagine saranno discusse nel dettaglio le procedure di installazione utilizzate per le varie

componenti con istruzioni passo passo nei passaggi cruciali. Verranno anche riportati i più basilari comandi

per l’utilizzo dei programmi ma una più dettagliata analisi del codice impiegato è di pertinenza della vera e

propria implementazione sperimentale descritta in 6.

8.2.2 Ububtu 14.04 Lts (Trusty) 64bit

Ci sono diverse possibilità per utilizzare un generico sistema operativo Linux su di una macchina: nell’ordine

di “invasività” crescente per il calcolatore si ha per esempio Live launch, macchina virtuale all’interno di un

altro sistema operativo, installazione su partizione di un disco fisso ed installazione globale sulla macchina.

Le prime due sono le più semplici ma comportano rispettivamente l’impossibilità di salvare o installare file

per utilizzi futuri e rallentamenti dovuti all’esecuzione in background del sistema operativo nativo. Questi

fattori le rendono inadatte all’implementazione di sistemi di controllo in tempo reale come quello qua

utilizzato.

È stata scelta la via di una installazione su partizione di un disco rigido esterno di tipo flash in modo da

garantire alta velocità di esecuzione senza modificare l’assetto del computer su cui si lavora.

La procedura utilizzata non è vincolante ai fini del buon funzionamento della rete ROS ma verranno ora

brevemente accennati i passaggi fondamentali per completezza descrittiva del setup sperimentale.

Per sicurezza occorre prima di tutto fare un backup dei file utili contenuti nel disco esterno.

I passaggi seguiti per l’installazione sono stati i seguenti (il computer di partenza monta windows 7):

1. Scaricamento del file .iso della versione di Ubuntu desiderata:

si può effettuare il download direttamente o da download alternativi indicati sempre sul sito ufficiale

all’indirizzo http://www.ubuntu.com/download/desktop .

Fig. 109: Download di Ubuntu

126

2. Una volta ottenuto il file occorre utilizzarlo per creare una versione Live di Ubuntu.

È possibile farlo semplicemente masterizzando su dvd il file come immagine di disco e seguendo le

istruzioni successive; in Nero Express Essentials si ha l’opzione in Fig. 110.

Fig. 110: Immagine .iso su disco

In alternativa si può utilizzare una chiavetta usb (diversa dall’hard disk che verrà utilizzato per le

partizioni) e creare una versione Live del sistema operativo grazie ad un programma come

l’applicazione scaricabile all’indirizzo http://www.pendrivelinux.com/universal-usb-installer-easy-

as-1-2-3/ . Se si sceglie questa opzione anche qui occorre fare il backup dei dati da non perdere.

Sono indicate in Fig. 111 le informazioni da inserire: tipo di distribuzione Linux (Ubuntu), percorso

di riferimento per il file “.iso” scaricato in precedenza e memoria usb di destinazione per il file del

boot che verrà creato.

Fig. 111: Creazione di una “live bootable usb”

127

3. Si può procedere a spegnere il computer ed effettuare, dal dispositivo preparato nel passaggio

precedente (disco o usb), il boot della sessione Live di Ubuntu.

Il metodo di boot è diverso da computer a computer dato che dipende dalle impostazioni determinate

dalla tipologia di bios; in ogni caso solitamente vi si può accedere premendo ripetutamente all’avvio

il tasto F12 (più raramente Esc o F2) . È possibile che, brevemente, appaiano a schermo anche

indicazioni vere e proprie su come accedere al menu di bios dove è possibile settare direttamente le

impostazioni di boot.

A questo punto occorre selezionare dalla lista di dispositivi per il boot quello che è stato preparato al

punto precedente; qualora ciò non fosse possibile potrebbe essere necessario disattivare impostazioni

di “fast boot” o “secure boot” che su alcune macchine impediscono la scelta per velocizzare

l’avviamento.

4. Se tutto è stato svolto correttamente ci si dovrebbe trovare di fronte all’interfaccia iniziale della

Distro di Linux. Le opzioni che vengono offerte sono l’installazione di Ubuntu e la prova come

versione Live.

NB: è importante scegliere l’opzione “try Ubuntu” di prova invece dell’installazione immediata

perché non sono ancora state definite le partizioni in cui l’installazione dovrà essere confinata (si

rischia di installare Ubuntu sul disco fisso del computer stesso, magari a discapito di altri dati, e non

sul disco esterno).

5. Una volta cominciata la sessione di prova si può procedere ad utilizzare lo strumento di gestione

delle partizioni già presente; lo si può trovare cliccando l’icona più in alto della barra a sinistra ed

inserendo quindi nello spazio di ricerca “GParted” (il nome del partition editor).

All’interno del programma è possibile osservare la distribuzione della memoria allocata su tutte le

unità partizionabili; di default è visibile quanto contenuto nell’hard disk del computer su cui si sta

lavorando (con il nome “/dev/sda”).

In alto a destra c’è un pulsante che permette si passare agli altri dispositivi di memoria, in particolare

adesso occorre arrivare al disco su cui si vuole effettuare l’installazione di Ubuntu.

Una volta sicuri che il dispositivo da partizionare è quello giusto basta procedere con i seguenti

passi:

Smontare la zona o le zone di memoria montate (affiancate dal simbolo di una chiave)

premendo il tasto destro del mouse e selezionando smonta o “unmount”.

Ridimensionare la zona di memoria occupata (tasto “resize/move” in alto) in modo da

lasciare un sufficiente spazio alla partizione da fare (considerando i programmi da installare

per questo progetto almeno 50 Gigabyte ma è meglio abbondare). Nello schema della

memoria dovrebbe essere apparso un rettangolo associato alla memoria non allocata

(“unallocated”)

128

Selezionare la memoria non allocata e creare una nuova partizione (pulsante “nuova” o

“new” in alto) selezionando l’opzione partizione estesa o “extended”: ciò creerà una

partizione fisica di tipo generico in grado di contenere diverse partizioni logiche anche

dotate di file system diversi tra loro.

Si utilizza una sola partizione fisica con all’interno altre logiche per due motivi: per

questioni di ordine è comodo avere sulla stessa partizione fisica tutta l’installazione di un

sistema operativo e, soprattutto, il numero di partizioni fisiche è limitato e quindi sarebbe

impossibile creare liberamente altre partizioni in futuro.

All’interno della partizione estesa appena fatta bisogna creare allo stesso modo di prima

(selezionando la memoria non allocata nella nuova partizione) le tre partizioni logiche che

verranno poi usate per l’installazione: la prima di circa 500 Megabyte con file system ext4

(verrà utilizzata per il boot), la seconda con file system tipo “swap” o “linux-swap” di un

numero di Gigabyte circa uguale a quello della RAM della macchina che si utilizza (verrà

utilizzata dal sistema come area di calcolo riscrivibile) e la terza di nuovo ext4 contenente la

restante maggior parte della memoria (questa accoglierà l’installazione vera e propria).

Finite tutte le operazioni, se si è sicuri di quanto fatto (dopo aver controllato di non aver per

sbaglio modificato parti di memoria da non toccare negli altri dischi) basta premere il

pulsante applica o apply in alto per completare il partizionamento.

6. Dalla schermata di Gparted è possibile vedere i nuovi nomi che sono stati dati alle partizioni create,

una buona norma è scriverli a parte in modo da riconoscerli in fase di installazione. Una volta fatto si

può chiudere il programma.

7. Sul desktop è visibile l’icona di installazione, se sono stati fatti i passaggi precedenti si può

proseguire cliccando sopra di essa.

(Se si decide di scaricare i pacchetti per una installazione completa da internet occorrerà verificare di

avere accesso alla rete configurandola cliccando i simboli di rete in alto a destra.)

8. Quando viene chiesto se smontare le porzioni di memoria montate è importante garantire il permesso

di farlo al programma di installazione premendo si, altrimenti non verranno lette le partizioni operate

in precedenza.

9. Si arriverà ad una schermata che offre una scelta tra installazione, installazione affiancata o altro.

Si scelga “altro” per accedere all’installazione su partizioni.

10. Nella nuova schermata sono disponibili tutte le partizioni associate ai vari dischi rigidi leggibili dal

computer in quel momento; conoscendo i nomi che sono stati attribuiti alle partizioni precedenti si

può assegnare con “modifica” il ruolo di riferimento alle tre partizioni create (formattandole se

necessario): alla partizione da 500 Megabyte bisogna associare file system ext4 ed etichetta “/boot”

dal menu a tendina, alla seconda partizione basta assegnare il ruolo di swap allo stesso modo (non è

129

necessario definire il file system) mentre alla terza si usi l’etichetta “/” con file system ext4.

Attendere prima di proseguire.

11. Si controlli attentamente che le partizioni scelte per l’assegnazione siano quelle create con Gparted e

poi si modifichi la periferica di riferimento per il boot (tendina sotto le partizioni) dando il percorso

dell’hard disk utilizzato.

NB: bisogna selezionare esattamente il disco, non una sua partizione interna né un'altra periferica

altrimenti Grub, il bootloader di Linux, non troverà la directory dove cercare i file per l’avviamento

della sessione.

12. A questo punto si può proseguire senza ulteriori problemi all’installazione, verranno chiesti dettagli

su fuso orario, tipo di nazionalità della tastiera desiderato, nome computer, nome utente e password

oltre a preferenze di avvio. Alla fine dell’installazione sarà lo stesso sistema a richiedere di spegnere

il computer, prima di riavviare assicurarsi di aver rimosso la periferica di lancio Live.

Se l’installazione è stata effettuata correttamente è possibile lanciare il sistema operativo Ubuntu dal boot

iniziale, dopo aver selezionato il dispositivo (usb) su cui è presente l’installazione.

Una volta accesa una sessione funzionante del sistema operativo è buona cosa aggiornare le sue parti che

possono risultare datate (questo non vuol dire passare alla versione di Ubuntu successiva come viene

suggerito nella barra di sinistra); occorre procedere da terminale dopo aver assicurato una connessione ad

internet funzionante.

Il terminale di linux è un importante strumento che verrà diffusamente utilizzato nel seguito di queste pagine

ed ha, in breve, la funzione di impartire comandi direttamente al sistema operativo senza passare per un

interfaccia grafica di supporto. Per aprire una nuova finestra del terminale lo si può cliccare dopo averlo

trovato con l’icona di ricerca in alto a sinistra oppure si può semplicemente sfruttare la scorciatoia da tastiera

Ctrl+Alt+t . Si può osservare che nella finestra c’è una linea di inserimento comandi con il nome che è stato

assegnato in installazione al computer; per installare gli ultimi update del sistema si inseriscano le seguenti

linee di codice:

sudo apt-get update

Occorrerà a questo punto digitare la password dell’utente definita in installazione perché la dicitura “sudo”

implica che il comando sia eseguito con privilegi di amministratore; si prosegua con:

sudo apt-get upgrade

Brevemente dovrebbero essere effettuati tutti gli aggiornamenti trovati col primo comando.

Il sistema è ora completamente configurato e pronto a ricevere le installazioni previste per l’utilizzo

dell’algoritmo proposto.

130

8.2.3 ROS Indigo Igloo

Il sistema operativo Ubuntu 14.04 supporta la versione Indigo Igloo di ROS; il percorso di installazione si

può trovare online sul sito dell’organizzazione open source all’indirizzo:

http://wiki.ros.org/indigo/Installation

Si è scelta in questo caso l’installazione mediante Debian packages anziché da codice sorgente.

1. Il primo passo di installazione consiste nella verifica che i repositories di Linux siano configurati per

consentire le opzioni "restricted," "universe," e "multiverse"; queste opzioni non sono altro che

permessi di accesso a contenuti scaricabili e possono essere visualizzati e concessi dal software

center come in Fig. 112:

Fig. 112: Configurazione repositories

2. Si apra un terminal (Ctrl+Alt+T) e si inseriscano i seguenti comandi fornendo, quando richiesto la

password per utilizzare i privilegi di amministratore:

Impostazione delle fonti Debian :

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-

latest.list'

Chiavi di installazione:

sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv-key 0xB01FA116

Aggiornamento dei pacchetti:

131

sudo apt-get update

Installazione completa della versione desktop:

sudo apt-get install ros-indigo-desktop-full

Inizializzazione di “rosdep” (gestore di dipendenze ROS)

sudo rosdep init

rosdep update

Impostazione dell’ambiente per le nuove sessioni del terminale

echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc

source ~/.bashrc

Installazione dello strumento “rosinstall” per lo scaricamento facilitato di packages

sudo apt-get install python-rosinstall

A questo punto l’installazione di ROS è completata ed è possibile iniziare ad utilizzare, direttamente da

nuovo terminal, tutte le funzioni e le procedure che sono descritte dettagliatamente nei tutorial all’indirizzo

http://wiki.ros.org/ROS/Tutorials,

3. Ai fini delle funzionalità e dei packages utilizzati in questa tesi non è necessario conoscere i dettagli

di tutti i comandi, quanto necessario verrà introdotto all’occorrenza; per ora ciò che è fondamentale

per il proseguimento è la creazione di un catkin workspace.

In breve il catkin workspace è un ambiente di compilazione che può essere utilizzato per rendere

utilizzabili pacchetti ROS scaricati o scritti nei linguaggi di programmazione che ROS accetta.

L’installazione completa nella versione desktop contiene già il pacchetto precompilato “ros-indigo-

catkin” quindi si può procedere direttamente alla creazione del workspace come segue:

Aprire un nuovo terminal ed inserire in sorgente l’ambiente ROS come segue:

source /opt/ros/indigo/setup.bash

Creazione delle cartelle (tilde dirige direttamente alla home dell’utente) :

132

mkdir -p ~/catkin_ws/src

Cambio directory:

cd ~/catkin_ws/src

Effettiva creazione del workspace:

catkin_init_workspace

A questo punto il workspace risulta creato ed è possibile compilare i packages presenti nella cartella

“~/catkin_ws/src”; anche se al momento è vuota è possibile effettuare la compilazione, questo passaggio

determinerà la creazione di nuovi file nella cartella “~/catkin_ws”: appariranno le cartelle “devel” e “build”.

Cambio directory:

cd ~/catkin_ws/

Compilazione:

catkin_make

Prima di continuare occorre rendere sorgente un file interno a “devel”:

source devel/setup.bash

Se tutto è stato svolto correttamente le pile (stacks) di packages in ROS dovrebbero ora poter accedere ai

packages in “~/catkin_ws/src”. Ciò può essere verificato mediante le seguenti operazioni:

(Opzionale) Verifica di condivisione

echo

ROS_PACKAGE_PATH

Il workspace creato verrà d’ora i poi arricchito dei nuovi packages ROS necessari che verranno ogni volta

compilati in modo analogo a quanto appena fatto.

133

8.2.4 V-REP

8.2.4.1 Installazione

Come è stato detto, il sistema operativo che si sta utilizzando è a 64 bit; la versione di Vrep da scaricare

all’indirizzo http://www.coppeliarobotics.com/downloads.html è la versione V-REP PRO EDU V3.2.2

distribuita per Linux 64 bit.

Il file scaricato è zippato e può essere semplicemente estratto grazie all’automatico strumento di unzip Linux

perché sia subito utilizzabile. La cartella ottenuta deve essere posizionata in una directory facilmente

accessibile in modo da poter agevolmente cambiare la directory a quella desiderata per l’avvio (è stata scelta

la cartella documenti all’interno della home dell’utente corrente).

I comandi da utilizzare per l’avviamento sono semplicemente il cambio directory (fino all’interno della

cartella copiata in precedenza) e l’esecuzione:

cd /home/NOMEUTENTE/Documenti/V-REP_PRO_EDU_V3_2_2_64_Linux

./vrep.sh

Vrep dovrebbe essere fin dall’inizio in grado di supportare la comunicazione con ROS ma, perché sia

configurata correttamente occorre compilare alcuni packages nel catkin workspace (questi passaggi saranno

oltretutto utili per abilitare Matlab a comunicazioni ROS secondo le tipologie di messaggi native di Vrep).

Il procedimento comprende si compone di alcuni passi da seguire (descritti nel dettaglio all’indirizzo:

http://www.coppeliarobotics.com/helpFiles/en/rosTutorialIndigo.htm) che vengono descritti in seguito:

All’interno della cartella di installazione di Vrep deve essere raggiunta la cartella

“programming/ros_packages” contenente 6 packages ROS:

“ros_bubble_rob”, “vrep_common”, “vrep_plugin”, “vrep_joy”, “vrep_skeleton_msg_and_srv”,

” vrep_plugin_skeleton”.

(Queste cartelle corrispondono rispettivamente a: un semplice tutorial di controllo Vrep

tramite ROS, la sintassi dei messaggi ed i riferimenti a relativi topics e services Vrep

interpretabili da ROS, il file da cui verrà generato il Plugin ROS per Vrep, materiale per

gestire periferiche aggiuntive e joystick via ROS, gli ultimi due offrono gli strumenti per

generare i propri messaggi/servizi ed il relativo plugin er renderli comprensibili a Vrep).

I 6 packages appena individuati devono essere copiati nella cartella “~/catkin_ws/src”

Generalmente non sono preinstallate alcune componenti necessarie a “vrep_joy”, per

ottenerle si apra un nuovo terminal e si dia il seguente comando:

134

sudo apt-get install ros-indigo-pr2-controllers ros-indigo-joystick-drivers

È ora possibile effettuare la compilazione aprendo un nuovo terminal ed inserendo:

cd ~/catkin_ws/

catkin_make

Sono stati creati i plugin che Vrep deve utilizzare per la comunicazione con ROS; occorre

copiare a questo punto i file generati (tra cui le librerie “libv_repExtRos.so” e

“libv_repExtRosSkeleton.so”) dalla cartella dei plugin in “~/catkin_ws/devel” direttamente

nella cartella di installazione di Vrep.

Se e il percorso indicato è stato seguito con successo è ora possibile utilizzare, dopo aver inizializzato il nodo

master di ROS, i servizi di Vrep direttamente da terminal (i topic dovranno invece essere inizializzati

internamente alla scena di Vrep come è stato discusso in 5).

Per effettuare una prova dell’accessibilità ai servizi da parte del master si proceda nel seguente modo:

Per sicurezza si chiudano eventuali terminal aperti; se ne apra uno nuovo e si inserisca:

roscore

In questo modo è stato inizializzato il nodo master della rete ROS in costruzione. I dati stampati

a schermo, tra cui l’URI propria del nodo, permetteranno a nuove applicazioni di interfacciarsi

con la rete, per questo il terminal corrente può essere minimizzato ma non deve essere mai

chiuso nel corso dell’uso di programmi che utilizzano ROS.

Si chiudano eventuali sessioni aperte di Vrep e si lanci una nuova sessione da un secondo

terminal:

cd /home/NOMEUTENTE/Documenti/V-REP_PRO_EDU_V3_2_2_64_Linux

./vrep.sh

Si verifichi che tra le voci caricate nel terminal di apertura di Vrep le voci inerenti a ROS siano

state caricate con successo (Fig. 113); in caso affermativo si proceda a minimizzare anche questo

terminal e se ne apra uno nuovo.

135

Fig. 113: Verifica di interfaccia ROS-Vrep

8.2.4.2 Utilizzo

Nel terzo terminal è finalmente possibile utilizzare i servizi offerti da Vrep.

NB: è importante, se non è stato condiviso in sorgente il file setup.bash, renderlo sorgente per il terminal

corrente o ROS non troverà il percorso ai tipi di messaggio supportati da vrep e non sarà pertanto in grado di

interagire con servizi o topics.

cd

source ~/catkin_ws/devel/setup.bash

I seguenti comandi sono di tipo informativo e permettono di capire se nodi e servizi sono stati correttamente

configurati:

rosnode list

rosservice list

Anche se la scena in Vrep è vuota si può verificare che I servizi di inizio e fine simulazione funzionino

inserendo:

rosservice call /vrep/simRosStartSimulation

rosservice call /vrep/simRosStopSimulation

8.2.5 YouBot ROS wrapper per Indigo

Il ROS wrapper per kuka YouBot consiste in una serie di script che, complessivamente, sono in grado di fare

da tramite tra comandi impartiti attraverso una rete ROS e l’implementazione di basso livello dei driver

136

nativi della macchina; se il sistema è correttamente configurato esso offre la possibilità di controllare il robot

semplicemente interagendo con il nodo ROS corrispondente ai driver.

8.2.5.1 Installazione

Per la versione Indigo Igloo di ROS non sono disponibili installazioni Debian del wrapper per il robot, è

stato dunque necessario procedere con un installazione da sorgente con compilazione nel catkin workspace.

Sul sito ufficiale del wrapper non è presente una versione canonica per Indigo (http://www.youbot-

store.com/wiki/index.php?title=ROS_Wrapper) e l’installazione in sorgente proposta prevede lo

scaricamento di un pacchetto di messaggistica (“brics_actuator”) non più disponibile. Per ovviare a questi

problemi è stata utilizzata una versione custom trovata tra i Repositories alla pagina seguente:

https://github.com/wnowak .

Il procedimento seguito da terminal è:

cd ~/catkin_ws/src

git clone https://github.com/wnowak/brics_actuator

git clone http://github.com/wnowak/youbot_driver.git -b hydro-devel

git clone https://github.com/wnowak/youbot_driver_ros_interface.git -b hydro-devel

cd ..

catkin_make

Si osserva che l’ultimo commando compila tutti I pacchetti inseriti per mezzo dei comandi di scaricamento

“git clone” all’interno della cartella “~/catkin_ws/src”; il file di riferimento per passare la sorgente è sempre

il “setup.bash” sfruttato prima per rendere utilizzabili i servizi Vrep.

Ci sono a questo punto gli strumenti per provare a collegare via etherCat la macchina come indicato

all’indirizzo:

http://www.youbot-store.com/wiki/index.php/Connecting_youBot_to_external_computer .

Per l’utilizzo del wrapper sarà necessario, una volta avviato il nodo master, utilizzare le seguenti istruzioni:

cd

source ~/catkin_ws/devel/setup.bash

roslaunch youbot_driver_ros_interface youbot_driver.launch

In caso tutto funzioni il robot procederà direttamente ad una fase di calibrazione dei finecorsa ed alla

creazione del nodo corrispondente alla macchina in rete (in tal caso è possibile saltare i passaggi in

Risoluzione problemi) .

137

8.2.5.2 Risoluzione problemi

Su molte macchine I comandi scritti sopra non sono sufficienti a causa della mancanza di accesso dati diretto

all’uscita ethernet; il seguente comando permette di configurare i privilegi di accesso:

cd ~/catkin_ws/src

sudo setcap cap_net_raw+ep devel/lib/youbot_driver_ros_interface/youbot_driver_ros_interface

Una ulteriore complicazione riscontrata è stata causata dalla non corretta denominazione della porta Ethernet

sulla macchina (nella configurazione del wrapper si assume che di default la porta sia chiamata “eth0”) .

Per verificare la presenza di un nome diverso per la porta si sfrutti il seguente comando:

ifconfig

In questo modo vengono riportate le disponibili vie di accesso alla rete, la porta ethernet è indicata con la

sigla “eth” seguita da un numero (in genere 0, 1 o 2). In Fig. 114 un caso con eth0.

Fig. 114: Configurazione delle porte di rete del computer

Se il numero della porta è diverso da zero occorrerà agire come segue:

Raggiungere la directory “~/catkin_ws/src” ed entrare nella cartella “youbot”

Aprire il file “ethercat.cfg”

Alla voce “EthernetDevice” sostituire eth0 con il nome della porta visibile con ifconfig

138

Fig. 115: Modifica al file "youbot-ethercat.cfg"

Salvare le modifiche ed aprire un nuovo terminal

Ricompilare il catkin workspace con i seguenti comandi:

cd ~/catkin_ws

catkin_make

Non sono stati riscontrati altri problemi ma soluzioni ad altre eventuali complicazioni sono disponibili sul

sito ufficiale dello YouBot agli indirizzi:

http://www.youbot-store.com/wiki/index.php/Technical_Support_Software

http://www.youbot-store.com/wiki/index.php/Technical_Support_Hardware .

8.2.5.3 Utilizzo

A calibrazione avvenuta è possibile visualizzare il nuovo nodo con relativi topics e servizi in modo analogo a

quanto fatto prima per Vrep.

Prima di passare all’implementazione ROS del controllo per l’algoritmo si è verificato che sia base che

braccio della macchina funzionassero correttamente procedendo come segue:

Apertura di un nuovo terminal con sorgente al catkin workspace:

cd

139

source ~/catkin_ws/devel/setup.bash

Lancio del programma tutorial a tastiera:

rosrun youbot_driver_ros_interface youbot_keyboard_teleop.py

(I comandi da tastiera indicate a schermo sono sufficienti a testare la base, Ctrl+c per terminare)

Esempio di movimentazione nello spazio di uno dei giunti del braccio (via pubblicazione su topic):

rostopic pub /arm_1/arm_controller/position_command brics_actuator/JointPositions '{positions:[ {joint_uri:

arm_joint_1, unit: rad, value: 1.0}]}'

8.2.6 Matlab R20015a

La scelta di una versione di Matlab a partire da quella R2015a è stata necessaria per poter utilizzare tutti gli

strumenti necessari all’implementazione, in primis il supporto ROS del “Robotics System Toolbox”

automaticamente installato.

8.2.6.1 Installazione

Esistono una serie metodi di installazione del software Mathworks ed i dettagli sono ampiamente coperti

nelle apposite sezioni del sito ufficiale ( http://it.mathworks.com/help/install/index.html?s_tid=srchtitle );

le opzioni si diversificano anche in base alla licenza acquistata secondo le metodologie offerte nella sezione

di acquisto ( https://it.mathworks.com/store/default.do?s_cid=store_top_nav&s_tid=gn_store ) oppure al tipo

di concessioni accademiche di cui si gode, come quella offerta dal Politecnico di Milano

(http://www.software.polimi.it/software-download/studenti/matlab/ ).

Eventuali pacchetti aggiuntivi (e lo stesso “Robotics System Toolbox” se non installato in origine) potranno

essere scaricati in un secondo momento se si dispone di un account Mathworks collegato ad una licenza

valida.

Non è scopo di questa tesi descrivere dettagliatamente il procedimento ma, considerando che si sta operando

su Linux, è buona cosa accennare ad alcune peculiarità di installazione non comuni ad altri sistemi operativi:

Su Linux non è necessario disporre di software di terze parti per la gestione delle immagini “.iso”

qualora si decidesse di non installare da dvd; è possibile procedere direttamente da terminal.

Il primo passo consiste nella creazione in una cartella cui poi far corrispondere una periferica

virtuale su cui montare l’immagine, per esempio:

140

sudo mkdir /media/matlab

Per manipolare le immagini è necessario avere privilegi di “root” che è possibile, a meno di

impostazioni personalizzate, ottenere come segue:

sudo su

(Per rendere visibile il cambiamento il simbolo $ al prompt del terminal dovrebbe essersi

trasformato in #)

L’immagine viene montata sfruttando il comando “mount” (che richiede la directory della cartella

deve è presente il file “.iso” e quella di destinazione, sono riportate le scelte fatte per questa

particolare tesi) e poi si può procedere all’installazione:

mount /home/NOMEUTENTE/Documenti/Mathworks_Matlab_R2015a_Linux/R2015a-glnxa64.iso /media/matlab -o

loop

cd /media/matlab

sudo ./install

Durante l’installazione del programma si presti attenzione al fatto che venga installato il “Robotics Systems

toolbox” perché, in caso contrario, occorrerà scaricarlo separatamente in un secondo momento in modo

analogo a quanto si farà per i due pacchetti descritti in seguito.

Anche per il lancio del programma si può procedere da terminale in modo analogo a quanto fatto per Vrep.

8.2.6.2 ROS Custom Messages

Una volta ottenuta una versione funzionante di Matlab R2015a è stato immediatamente possibile stabilire

connessioni tra nodi della rete ed il nodo corrispondente alle capacità computazionali di Matlab; il problema

è stato che, anche se il nodo risultava connesso, non è stato possibile comunicare con services e topics della

stragrande maggioranza delle implementazioni ROS in quanto Matlab supporta in modo nativo solo un

numero limitato di MessageTypes( msg ) e ServiceTypes (srv).

In particolare le parti mancanti per l’uso di ROS che si fa in questa tesi sono stati i messaggi di tipo

“brics_actuator” per lo YouBot wrapper e quelli di tipo “vrep_common” per Vrep oltre ai rispettivi Services.

Per prendere visione dei tipi di messaggio implementati è sufficiente inserire nella command window di

Matlab: “ rosmsg list”

È stato facile notare che, di base, non sono elencati i messaggi desiderati. Per risolvere il problema è stato

necessario installare ed utilizzare un pacchetto di supporto “Robotics System Toolbox Interface for ROS

Custom Messages” scaricabile dopo l’autenticazione Mathworks al seguente indirizzo:

141

http://www.mathworks.com/matlabcentral/fileexchange/49810-robotics-system-toolbox-interface-for-ros-

custom-messages

In alternativa è possibile ottenere il download selezionando il pacchetto dopo aver lanciato il comando:

>> roboticsSupportPackages

Una volta seguite le istruzioni di installazione è stato possibile utilizzare lo strumento di creazione dei

messaggi custom; il percorso è stato il seguente:

1. Copia della cartella “~/catkin_ws” in una nuova directory (in questa tesi “~/catkin_ws2”); questo è

stato fatto per non modificare il comportamento di ROS a causa di eventuali modifiche apportate da

Matlab e di quelle che sarà necessario apportare manualmente.

2. A causa di un problema di compilazione delle dependencies di Matlab riscontrato è stato necessario

procedere all’apertura della cartella “~/catkin_ws2/ catkin_ws /src/vrep_common” ed alla modifica

del file “package.xml” (aperto come semplice file di testo) attraverso l’aggiunta delle dipendenze

mancanti (in questo caso con la linea “<build_depend>geometry_msgs</build_depend>” visibile in

Fig. 116).

Fig. 116: Modifica delle dependencies in "package.xml"

3. Indicazione del percorso per la cartella “src” modificata ed esecuzione del comando di conversione:

>> folderpath=’stringa contenente il percorso alla cartella src’;

>> rosgenmsg(folderpath)

Si sono ottenuti operativamente i risultati in Fig. 117:

142

Fig. 117: inizio generazione dei messaggi ROS custom

4. Dopo la conversione è stata richiesta l’esecuzione delle ultime procedure in Fig. 118:

Fig. 118: Risultati compilazione e passaggi richiesti

Ultimate le procedure i tipi di messaggio desiderati sono diventati visibili nella lista chiamata inizialmente

con: “ rosmsg list”.

L’utilizzo che è stato fatto di topics e services è descritto in modo approfondito nella sezione sperimentale 6.

8.2.6.3 Support Package per Webcam USB

La parte di visual servoing ha reso necessario disporre, da Matlab, delle letture dalla webcam montata

sull’end-effector del robot; il metodo più rapido per ottenere immagini sotto forma di matrici rgb pronte per

l’elaborazione è basato sul pacchetto “MATLAB Support Package for USB Webcams”.

143

L’installazione può essere, come sempre effettuata dal sito Mathworks ma, trattandosi di un pacchetto base la

cui installazione è già prevista è bastato eseguire una delle funzioni del pacchetto perché l’errore restituito

suggerisse il precorso per ottenerla tramite “Support Package Installer” direttamente apribile cliccando sulla

parte sottolineata dell’errore in Fig. 119.

Fig. 119: Errore con collegamento al Support Package Installer

Le funzioni del pacchetto che sono state utilizzate sono quelle tipiche dell’acquisizione di immagine:

Elenco dei nomi dei dispositivi webcam collegati: “webcamlist”

Creazione della struttura che caratterizza un oggetto webcam in Matlab (con i relativi dati):

>>cam=webcam(‘nome della telecamera nell’elenco webcamlist’)

Anteprima in tempo reale della vista dalla videocamera “preview(cam)”

Comando per scattare una fotografia istantanea:

>>img = snapshot(cam)

Una volta acquisite, le immagini sono state processate secondo le metodologie proposte in 9.

144

9 Appendice B

Come indicato in 1.2.2 ed in 2.3.2, per poter impostare sia le fasi preliminari sia l’algoritmo vero e proprio è

importante disporre di un adeguato sistema di processamento delle immagini restituite dal sistema di visione

associato alla telecamera.

Come si è detto l’obiettivo della fase di image processing è l’ottenimento di alcune caratteristiche

d’immagine o features, che per questa tesi si possono identificare con: asse maggiore (in pixel), asse minore

(in pixel), coordinate del centroide (in pixel) e angolo di rotazione nel piano - .

Nei capitoli 3,4,5 e 6 sono stati utilizzati sistemi di visione diversi:

Telecamera fittizia con obiettivo a punti in Matlab e Simulink

Sensore di immagine in Vrep: una immagine simulata ma del tutto simile alla lettura di una vera

periferica di acquisizione video

La vera e propria telecamera Microsoft Lifecam HD la quale restituisce immagini sotto forma di

matrici RGB.

Già a questo punto è possibile fare una distinzione per quanto riguarda l’ottenimento delle features in quanto

i tipi di immagini sono riconducibili a due categorie distinte: immagini di obiettivi a punti ed immagini a

macchie di colore

Fig. 120: Features da identificare grazie all’image processing

145

9.1 Image processing in simulazione Matlab-Simulink (su punti)

Come si è visto nella sezione 3 di simulazione Matlab, la videocamera modellata dall’oggetto “cam” non

restituisce propriamente delle immagini scattate dall’ambiente 3D ma le sole proiezioni sul piano immagine

dei punti che compongono l’ellissoide obiettivo ossia i componenti della matrice .

Il toolbox per la machine vision di Peter Corke offre buoni strumenti per l’analisi di immagini a punti.

L’approccio seguito è quello dell’analogia fisica dell’immagine, o meglio di una regione di essa ad una lastra

di spessore unitario; il problema del riconoscimento dei parametri d’immagine può essere ricondotto grazie a

ciò alla semplice ricerca dei parametri inerziali di un oggetto in termini dei momenti di primo e secondo

ordine.

Per il calcolo del baricentro o, in questo caso, del centroide si agisce come segue:

( 75 )

( 76 )

Dove e sono i momenti del primo ordine. I momenti sono una classe di image feature

computazionalmente economica che permettono di descrivere la posizione e dimensione della regione, così

come la sua forma. Il momento di un’immagine è uno scalare ed è definito come:

In cui è il valore di generica intensità del pixel (in questo caso unitaria nei pixel associati a punti e nulla

altrove) alle coordinate , mentre rappresenta l’insieme dei pixel che compongono la regione di

interesse.

Per ricavare l’ellisse dalla regione racchiusa definita in precedenza, occorre scrivere i momenti centrali

calcolati rispetto al centroide appena individuato, che sono invarianti rispetto alla posizione della regione:

Sfruttando l’analogia con la piastra sottile si può scrivere la matrice d’inerzia legata alla superficie di

interesse come segue:

146

L’ellisse equivalente è quella che ha stessa matrice di inerzia dell’intera zona che si sta prendendo in esame.

Gli autovettori e gli autovalori di sono legati ai parametri geometrici dell’ellisse [29]:

( 77 )

( 78 )

( 79 )

In cui e

sono gli autovettori corrispondenti agli autovalori rispettivamente minore ( ) e

maggiore ( ). In Matlab si ha la seguente scrittura (Fig. 121) che utilizza la funzione “mpq_point” per il

calcolo dei generici momenti “p-qesimi” (per il calcolo dei momenti di second’ordine occorre prima centrare

i punti nella posizione idealmente corrispondente al baricentro trovata appena prima):

Fig. 121: Image processing standard per punti in Matlab

Nel caso in esame non è tuttavia possibile utilizzare le equazioni ( 77 ) e ( 78 ) poiché non si hanno a

disposizione le coordinate di tutti i pixel della regione corrispondente all’oggetto obiettivo; l’ellissoide infatti

è rappresentato da Matlab con il solo wireframe a spicchi, pertanto le proiezioni nel piano immagine

appaiono come un insieme di linee.

147

La proiezione sul piano immagine è comunque simmetrica rispetto al centroide, quindi le equazioni ( 75 ), (

76 ) e ( 79 ) mantengono la loro validità; tuttavia perdono precisione la ( 77 ) e la ( 78 ). Il risultato è

riportato in Fig. 122, in cui è evidente l’errore nella stima degli assi, mentre il centroide e l’angolo sono

indicativamente corretti:

Fig. 122: ellisse con assi ricavati dagli autovalori

Il metodo alternativo proposto sfrutta parte dei legami trovati ma continua con le seguenti tappe:

Traslazione di tutta la proiezione dell’ellissoide fino a fare coincidere col centro immagine

rotazione di angolo – (trovato come da metodo tradizionale) dell’ellisse per allineare l’asse

maggiore ad

Calcolo degli assi maggiore e minore dell’ellisse come distanza tra massimi e minimi (in pixel)

lungo gli assi e della regione costituita dai punti che hanno subito tutte le trasformazioni di cui

sopra. I risultati sono quelli già riportati in Fig. 120.

Fig. 123: Ottenimento di asse maggiore e minore nel nuovo metodo

148

9.2 Image processing in Vrep e su telecamera reale (su macchie di colore)

Sia la telecamera reale in sperimentazione sia al sensore di visione reso disponibile da V-REP (dopo la

conversione da messaggio ROS grazie ad “readImage”) forniscono immagini in formato “RGB”.

Anche in questo caso si procede ad esplicitare il percorso utilizzato per ricavare , , e .

Per riuscire a determinare i parametri sopra riportati occorre elaborare l’immagine attraverso funzioni (rese

disponibili da machine vision toolbox) in modo da visualizzare solo la regione di interesse; è innanzitutto

necessario eseguire qualche passaggio di conversione al formato con cui viene salvata la figura in Matlab

prima di essere processata.

La classe delle immagini importate dalla telecamera di V-REP è del tipo “uint-8”, che rappresenta i valori

tristimolo attraverso numeri a 8-byte con doppia precisione nel range [0 255]: occorre convertire tale classe

con quella “floating point”, nella quale i pixel sono definiti da numeri con doppia precisione nel range [0 1].

L’operazione di conversione si esegue attraverso la funzione ‘idouble’, che ha come argomento la variabile

da convertire.

Nel caso in esame è utile decodificare i valori tristimolo dell’immagine attraverso lo standard RGB (sRGB),

così da poter isolare le zone i cui pixel sono di interesse; a tal scopo si utilizzano in sequenza due funzioni:

‘igamma’, che ha come argomenti il nome della variabile da decodificare e la stringa sRGB;

‘tristim2cc’, che ha come argomento l’output della funzione precedente.

Per isolare la regione di colore scelto, si può dunque creare una nuova immagine in cui, ad esempio, tutti i

pixel il cui valore di Red è minore di 0,35 diventano uno (nero), (bianco) viceversa; si crea così

un’immagine filtrata in bianco e nero.

L’ultima funzione necessaria all’image processing è ‘regionprops’, che restituisce in pixel le coordinate del

centroide, l’asse minore, l’asse maggiore e l’angolo di rotazione di ciascuna regione chiusa ci sia

nell’immagine filtrata. L’utilizzo che si fa della funzione è visibile in Fig. 124; si possono notare in ingresso

l’immagine “mascherata” secondo il filtro colore imposto ed i parametri che vengono richiesti.

L’output di “regionprops” rappresenta un elemento struttura , con che indica il numero di regioni

chiuse presenti nell’immagine.

Considerando che la regione con l’asse maggiore è quella di interesse, si selezionano i parametri ad essa

associati.

149

Fig. 124: Funzione Im_Processing

In Fig. 125 i passaggi principali appena descritti: conversione e lettura, filtraggio ed estrazione features.

Fig. 125: Sequenza di processamento di un'immagine RGB

150

Bibliografia

[1] S. K. F, Orange Harvesting Systems Review, Biosystems Engineering, 2005.

[2] S.-h. L. H.-Y. H. Peilin Li, Review on fruit harvesting method for potential use of, 2011.

[3] S. C. E and B. G. K, Basic considerations in mechanizing citrus harvest, 1968.

[4] C. G. E, Picking citrus fruit by mechanical means, 1961.

[5] C. G. E and J. P. J, Harvesting citrus fruit with an inertia shaker, 1962.

[6] C. G. E and H. S. L, Design and development of a tree-shaker harvest system for citrus fruit, 1968.

[7] J. P. J and P. J. M, Harvesting citrus fruit with an oscillating air blast, 1962.

[8] W. J. D, Design and performance of an air shaker for citrus fruit removal, 1977.

[9] S. H. R, Selective harvesting of Valencia oranges with a vertical canopy shaker, 1973.

[10] W. J. D, Field test results with mechanical citrus fruit removal devices, 1997.

[11] W. J. D, Abscission chemicals affect trunk shaker orange removal, 2000.

[12] D. A. Grand, Robotic Harvesting of Apples, 1985.

[13] e. a. M. D'Esnon A Grand, a Self-Propelled Robot to Pick Apples, 1987.

[14] H. R. C, A. P. D, M. R. D and S. D. C, Robotic picking of citrus, 1990.

[15] R. G, B. A, S. F and J. F, Robotic Harvesting of Citrus: State-Of-Art and Development of the EUREKA

Project, 1995.

[16] e. a. Ceres R, Design and implementation of an aided fruit-harvesting robot(Agribot), 1998.

[17] M. G and P. M, A prototype of an orange picking robot: past history, the new robot and experimental

results, 2005.

[18] J. A. R, C. R and P. J. L, A Survey of Computer Vision Methods for Locating Fruit on Trees, 2000.

[19] K. L, Hungarian robotic apple harvester, 1992.

[20] T. B. S.S. Mehta, "Vision-based control of robotic manipulator for citrus harvesting," 2014.

[21] O. Hiroshi and L. W. Suk, Green citrus detection using hyperspectral imaging, 2009.

[22] S. D, L. M and H. M, Estimation of number and diameter of apple fruits in an orchard during the

growing, 2004.

[23] J. F and S. F, Citrus: An European Project to Study the Robotic Harvesting of Oranges, 1992.

[24] G. G. M and R. Michael, Scene Analysis for an Orange Picking Robot, 1996.

[25] L. S. L. V. G. O. Bruno Siciliano, Robotica, McGraw-Hill, 2008.

151

[26] S. H. Francois Chaumette, "Visual Servo Control Part I: Basic Approaches," 2006.

[27] E. Malis, Traitement du Signal et Tèlècommunications, 1998.

[28] R. Olinde, De l'attraction des sphèroides, Parigi, 1816, pp. 361-385.

[29] P. Corke, Robotics, Vision and Control, Springer, 2011.

[30] S. C. E and B. G. K, Basic considerations in mechanizing citrus harvest, 1968.

[31] Wikipedia, "Triangolazione," [Online]. Available: https://it.wikipedia.org/wiki/Triangolazione.

[32] "Remote API," [Online]. Available: www.coppeliarobotis.com/helpFiles/en/remoteApiOverview.htm.