politecnico di milano · pdf file · 2016-02-25fig. 13: kuka youbot ... tabella 1:...
TRANSCRIPT
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.