Università degli Studi di Bologna - LAR-DEIS Home Page · 2002-07-30 · Università degli Studi di Bologna FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica ROBOTICA

Università degli Studi di Bologna

FACOLTÀ DI INGEGNERIACorso di Laurea in Ingegneria Informatica

ROBOTICA INDUSTRIALE

INTEGRAZIONE DI VISIONE ARTIFICIALE E

CONTROLLO REAL TIME PER UN ROBOT

INDUSTRIALE

Tesi di Laurea di:

MARCO GUIDETTI

Relatore:

CHIAR.MO PROF. ING. CLAUDIO MELCHIORRI

Correlatori:

CHIAR.MO PROF. ING. ALBERTO TONIELLIDOTT. ING. ALESSANDRO MACCHELLI

Sessione Estiva

Anno Accademico 2001/2002

Parole chiave:roboticarobot COMAU Smart-3Scontrollo di robotreal time Linuxvisione artificiale

L.A.R., Laboratorio di Automazione e Robotica.D.E.I.S., Dipartimento di Elettronica, Informatica e Sistemistica.Università di Bologna.Le simulazioni sono effettuate in MATLAB e SIMULINK, MATLAB e SIMULINK sonomarchi registrati di THE MATHWORKS, INC.La tesi è scritta in LATEX 2ε, la stampa è in POSTSCRIPT.

a chi mi ha dato la forza per farcela

iv

Ringraziamenti

Bologna, 17 Luglio 2002

Innanzi tutto vorrei ringraziare i miei genitori per tutto quello che hano fattoper me in questi anni e per l’appoggio e la tranquillità che mi hanno donato. Ungarzie particolare a Luisa per essermi stata accanto e per avermi supportato inquest’ultimo periodo. Grazie anche ai miei amici e ai compagni d’appartamento.

Desidero poi ringraziare tutti coloro che mi hanno aiutato a svolgere questa tesi,in particolar modo vorrei ringraziare Prof. Ing. Claudio Melchiorri per avermidato la possibiltà di svolgere la tesi al L.A.R. e per la fiducia concessomi, vorreiringraziare Dott. Ing. Alessandro Macchelli per il costante aiuto e Dott. NicolaDiolaiti per la disponibiltà.

Un grazie particolare anche a tutti i ragazzi del L.A.R. per il magnifico periodotrascorso insieme.

Grazie a tutti,Marco Guidetti

vi

Indice

Introduzione 1

1 Descrizione del sistema 31.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Il robot SMART-3S e il controllore C3G 9000 . . . . . . . . . . . . 31.3 Visione artificiale . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Gripper A.S.I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Il PC IBM-compatibile . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Controllo real time 92.1 I sistemi real time: generalità . . . . . . . . . . . . . . . . . . . . . 92.2 Real Time Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Il kernel di Linux . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 RTAI-Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Controllo del robot SMART-3S con RTAI-Linux . . . . . . . . . . . 142.3.1 Il modulo Bit3init.o . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Il modulo rtai_comau.o . . . . . . . . . . . . . . . . . . . . 15

2.4 Osservazioni pratiche su RTAI-Linux . . . . . . . . . . . . . . . . 23

3 Visione artificiale 253.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Richiami di ottica e manipolazione d’immagini . . . . . . . . . . . 25

3.2.1 Ottica geometrica . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 L’algoritmo di Canny . . . . . . . . . . . . . . . . . . . . . 29

3.3 Distanza fra robot e oggetto: soluzione teorica . . . . . . . . . . . . 303.3.1 Allineamento . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.2 Calcolo della distanza . . . . . . . . . . . . . . . . . . . . 33

3.4 L’algoritmo di visione artificiale . . . . . . . . . . . . . . . . . . . 333.5 Precisazioni sull’algoritmo di visione . . . . . . . . . . . . . . . . 41

3.5.1 Arresto del manipolatore per determinare la dimensione del-l’oggetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

viii Indice

3.5.2 Utilizzo di più fotogrammi nella determinazione della di-mensione dell’oggetto . . . . . . . . . . . . . . . . . . . . 42

3.5.3 Un motivo pratico per utilizzare PITCH e YAW nell’alli-neamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Risulati sperimentali 454.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Come sono state ottenute le misure . . . . . . . . . . . . . . . . . . 454.3 Misura dell’errore di calcolo della distanza . . . . . . . . . . . . . . 464.4 Determinazione della costante pixel2cm . . . . . . . . . . . . . . . 484.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Conclusioni 53

A I moduli del kernel di Linux 55A.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.2 Moduli: funzionamento . . . . . . . . . . . . . . . . . . . . . . . . 55A.3 Caricamento automatico di un modulo . . . . . . . . . . . . . . . . 57

B Il robot COMAU Smart-3S 61B.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61B.2 Accensione del COMAU Smart-3S . . . . . . . . . . . . . . . . . . 61B.3 Comunicazione tra controllore C3G 9000 e PC . . . . . . . . . . . 62

B.3.1 Come cambiare della modalità di funzionamento per il con-trollore C3G 9000 . . . . . . . . . . . . . . . . . . . . . . 62

B.3.2 Come caricare del software nel C3G 9000 . . . . . . . . . . 63B.4 Calibrazione del COMAU Smart-3S . . . . . . . . . . . . . . . . . 65B.5 Possibili cause di errore . . . . . . . . . . . . . . . . . . . . . . . . 66

Bibliografia 67

Elenco delle tabelle

4.1 Tabella errore medio. . . . . . . . . . . . . . . . . . . . . . . . . . 484.2 Tabella distanza media del bordo dal CdGG . . . . . . . . . . . . . 49

x Elenco delle tabelle

Elenco delle figure

1.1 COMAU Smart-3S. . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Gripper A.S.I.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Schema di principio di RTAI . . . . . . . . . . . . . . . . . . . . . 12

3.1 Ottica geometrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Calcolo della distanza con telecamera “monoscopica”. . . . . . . . 273.3 Calcolo della distanza con telecamera stereoscopica. . . . . . . . . 293.4 Esempio di applicazione dell’algoritmo di Canny. . . . . . . . . . . 303.5 Telecamera montata su end effector. . . . . . . . . . . . . . . . . . 313.6 Allineamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7 Screenshot del software di visione. . . . . . . . . . . . . . . . . . . 343.8 Allineamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.9 Risoluzione della telecamera. . . . . . . . . . . . . . . . . . . . . . 39

4.1 Errore medio per differenti approach. . . . . . . . . . . . . . . . . 464.2 Errore massimo per differenti approach. . . . . . . . . . . . . . . . 474.3 Distanza media in pixel. . . . . . . . . . . . . . . . . . . . . . . . 50

xii Elenco delle figure

Introduzione

La presente tesi è stata sviluppata presso il L.A.R., Laboratorio di Automazionee Robotica, della facoltà di Ingegneria dell’Università di Bologna. Lo scopo dellatesi è stato quello di integrare, in un unico PC, un sistema distribuito sviluppato inprecedenti tesi [9].

Al L.A.R. è già stato sviluppato un sistema che permette l’afferraggio di unoggetto collocato nello spazio da parte del gripper A.S.I. montato sul robot CO-MAU Smart-3S. L’afferraggio avviene con l’ausilio delle informazioni provenientida una telecamera posta sul gripper stesso. Questo sistema è distribuito, nel sensoche vi sono tre PC: uno controlla il robot, uno il gripper e l’altro gestisce le infor-mazioni provenienti dalla telecamera e coordina il lavoro svolto dagli altri due. Lacomunicazione fra i PC avviene attraverso la LAN1 presente in laboratorio.

Integrare in un unico PC tutta la gestione offre vantaggi legati all’indipenden-za del sistema dallo stato della rete locale. Inoltre, offre maggiore velocità nelloscambio di informazioni tra task.

In questa tesi si è appunto integrato il sistema precedentemente descritto. Leidee teoriche di base rimangono pressochè invariate, ma la realizzazione softwarecambia profondamente. Infatti, se da un lato la parte di controllo del manipolatoree soprattutto quella di controllo del gripper rimangono pressochè immutate, la partedi visione richiede una profonda rivisitazione. Si deve tener presente che l’integra-zione comporta un carico computazionale molto piú elevato, poichè tutto è svoltoda un’unico processore. Alla luce di ciò non è solo necessario modificare la partedi software legata alla comunicazione fra i task, ma è necessario rivedere tutto ilprogetto al fine di evitare sprechi di risorse di calcolo.

Considerando le tre parti del progetto si ha che: il controllo del manipolatore ègià ridotto al minimo e offre poco margine di miglioramento; il controllo del gripperè eseguito da un processore presente su di una scheda esterna, quindi non sfrutta laCPU del PC; l’unica parte realmente modificabile è quella di visione artificiale.

Il lavoro di questa tesi è riprogettare il software di visione, al fine di renderlocompatibile con il funzionamento del sistema nel suo complesso.

1LAN: Local Area Network

2 Introduzione

In questa trattazione si è cercato di giustificare le scelte fatte durate lo sviluppo,non manca nella dissertazione una parte teorica per comprendere le suddette scelte.In particolare nel capitolo 1 si è voluto fornire una descrizione del sistema nel suocomplesso.Nel capitolo 2 è stato illustrato il concetto di real time in teoria e nel contesto in cuisi pone questo lavoro.Nel capitolo 3 sono illustrate le basi teoriche della visione artificiale in generale, eil software sviluppato.Nel capitolo 4 sono presentati dei dati sperimentali che giustificano scelte fattedurante lo sviluppo del software.

Infine, in appendice A sono illustrati alcuni concetti teorici legati al kernel diLinux; mentre in appendice B viene presentata una guida rapida all’utilizzo delmanipolatore COMAU Smart-3S.

Capitolo 1

Descrizione del sistema

1.1 Introduzione

Una breve introduzione al sistema può essere utile per focalizzare il lavoro svol-to in questa tesi. Il sistema è costituito da un manipolatore industriale della CO-MAU, da una telecamera PULNiX, dal gripper A.S.I. e da un PC che controlla ecoordina tutto.

1.2 Il robot SMART-3S e il controllore C3G 9000

Il manipolatore presente al L.A.R. è costituito dal robot SMART-3S e dal con-trollore C3G900 della COMAU.

Il robot SMART-3S della COMAU è un manipolatore industriale a sei gradi dilibertà, i giunti sono tutti di tipo rotazionale e vengono controllati da attuatori ditipo brushless con resolver calettati sull’albero per la misura di posizione. Il mani-polatore non possiede il polso sferico, vedi figura 1.1, infatti gli assi di rotazione delquarto e del sesto giunto giacciono su piani paralleli. Questa caratteristica non per-mette di disaccoppiare il problema dell’orientamento da quello del posizionamentonel risolvere la cinematica inversa del manipolatore.

Il controllore C3G 9000 è il “cervello” del manipolatore, si occupa dell’intera-zione tra robot e operatore, della lettura delle posizione dei singoli giunti, dell’e-secuzione dei programmi PDL2 e della determinazione delle correnti da fornire aimotori.

All’interno del controllore vi è anche la parte di potenza, la quale serve per potergenerare le correnti necessarie al pilotaggio dei motori presenti sui singoli giunti.

4 Descrizione del sistema

Figura 1.1: COMAU Smart-3S.

L’unita di controllo presente al L.A.R. è basata sul bus Motorola VME e com-prende tre schede:

1. RBC, gestisce l’interfaccia uomo-macchina e traduce ed interpreta i program-mi PDL2;

2. SCC, è responsabile dell’interpretazione della traiettoria, del calcolo dellacinematica inversa, e del controllo di posizione del giunto;

3. Bit3, si occupa della comunicazione e sincronizzazione tra un eventuale PCesterno e il controllore.

La presenza della scheda Bit3 sul bus VME del controllore permette di potercomunicare, attraverso un cavo ad alta velocità, con un’altra scheda Bit3 presentesul bus ISA di un PC IBM-compatibile. Questo offre la possibilità di controllareil manipolatore dal PC, che si sincronizza con il controllore sfruttando l’interruptgenerato dal controllore stesso.

1.3. Visione artificiale 5

Quindi si intuisce che il manipolatore ha più modalità di funzionamento. Questemodalità sono cinque e, escludendo quella normale, si distinguono l’una dall’altraa seconda del punto, nello schema di controllo standard, in cui è aperto il control-lore. La modalità che offre maggior libertà è quella in cui il PC legge le posizionidei sei giunti, esegue i calcoli necessari e scrive direttamente i setpoint di corren-te. In questa modalità il controllore genera un interrupt di sincronizzazione ognimillisecondo. Questa è l’unica modalità utilizzata nello sviluppo di questa tesi.

1.3 Visione artificiale

Il sistema di visione artificiale è composto da una telecamera PULNiX modelloTM-6CN in bianco e nero con uscita analogica e da un framegrabber. Il sistema ècostituito da un unica telecamera e non da un sistema di visione stereoscopica, ciòcomporta secelte particolari nell’algoritmo di visione per determinare la distanza.

Le caratteristiche hardware, sia della telecamere sia del framgrabber, sono statetenute in considerazione in fase di progetto sia per la scelta della risoluzione che perquel che riguarda il numero di frame per secondo (nel caso specifico 30fps).

Il driver per il framegrabber è presente nel kernel ufficiale di Linux, non hacaratteristiche real time. Quest’ultima affermazione modifica l’algoritmo di presa,infatti non è possibile associare un’immagine ad un istante preciso oppure ad unaposizione del robot. Per la gestione del framegrabber sono state utilizzate le librerielibbgrab, questo ha permesso di evitare lo sviluppo delle funzioni di basso livelloper l’accesso alla scheda di acquisizione.

1.4 Gripper A.S.I

Il gripper è una pinza robotica dotata di tre dita identiche e indipendenti. Ognidito ha un grado di libertà che gli consente un movimento radiale. Il gripper è ingrado di afferrare oggetti relativamente grandi, ed operare bene anche con oggettipiccoli, è rappresentato in figura 1.2.

Gli attuatori presenti sulla pinza sono motori di tipo lineare e sono in gradodi sviluppare, considerando le dimensioni ridotte, un’elevata potenza. Inoltre, suciascun dito vi sono più sensori:

� sensore di posizione, indispensabile per conoscere la posizione del dito edeseguire un qualunque controllo;


Falange media

Falange motrice

finger

Attuatore

Figura 1.2: Gripper A.S.I..

� sensore di prossimità, permette di avvicinare il dito all’oggetto senza toccar-lo, quindi è utilizzato per chiudere in maniera sincrona tutte le dita sull’og-getto stesso;

� sensore di forza, necessario per conoscere la forza esercitata sull’oggettopreso, e per evitare che l’oggetto possa scivolare o essere danneggiato.

La presenza di questi sensori permette di creare più schemi di controllo da uti-lizzare nel momento opportuno durante la presa. Lo schema totale del regolatore èformato da più schemi di controllo e seleziona quello da utilizzare in funzione dellostato in cui si trova. I tipi di controllo realizzati sono i seguenti:

� controllo di posizione, viene impiegato nel primo tratto di avvicinamento enell’ultima fase di presa;

� controllo di prossimità, utilizzato per portare le dita a distanza costantedall’oggetto e sincronizzarle per l’afferraggio;

� controllo misto forza-posizione, utilizzato quando vi è il contatto con l’og-getto per garantire la presa.

È opportuno che la transizione da uno schema di controllo ad un altro avvenga senzacomportamenti bruschi e discontinui.

1.5. Il PC IBM-compatibile 7

Da quanto detto si evince che per controllare il gripper vi è la necessità di ungran numero di calcoli. Il controllo della pinza è completamente gestito dalla fast-prot. Questa è una scheda munita di DSP1 che può essere alloggiata su di un nor-male slot ISA di un qualsiasi computer IBM-compatibile. La potenza di calcoloaggiunta dalla fastprot è indipendente dal resto del PC. Il kernel, che viene caricatonella memoria della scheda DSP, esegue i calcoli necessari al controllo del grippere, quindi, svincola il processore del PC da questo lavoro.

Il driver di questa scheda e il software, per caricare il kernel in ambiente Linux,sono stati sviluppati in precedenti tesi [11], entrambi non sono real time. Il carica-mento del kernel nella fastprot avviene prima di eseguire il controllo, quindi non èun’operazione che necessita dei concetti real time.

Il kernel caricato si occupa della gestione e del controllo del gripper. Un soft-ware generico, per utilizzare il gripper, deve solo inviare opportuni comandi al ker-nel, senza occuparsi di tutto il controllo. Un esempio chiarirà il concetto. Un soft-ware generico per far afferrare un oggetto al gripper deve semplicemente mandareil comando di chisura delle dita al kernel, per far ciò deve scrivere un opportunovalore ad un particolare indirizzo della fastprot. Il kernel sulla scheda, ricevuto ilcomando, esegue tutto il necessari per risolvere il problema, cioè campiona i segnaliprovenienti dai sensori del gripper e attua i motori in modo da afferrare l’oggetto.

È importante notare che tutta la gestione del gripper, al livello software, non èa carico del processore del PC, quest’ultimo può dedicare il suo tempo al controllodel robot e alla gestione della parte di visione artificiale.

1.5 Il PC IBM-compatibile

Per coordinare il manipolatore, il gripper e per gestire il sistema di visione artifi-ciale si utilizza un normale PC IBM-compatibile. Il PC deve essere sufficientementepotente e veloce per riuscire a rispondere all’interrupt del C3G 9000, e avere il tem-po per eseguire l’algoritmo di visione artificiale. Deve, inoltre, possedere due slotISA per poter ospitare sia la scheda Bit3 sia la fastprot.

Il PC, utilizzato durante lo sviluppo di questa tesi, è un Pentium3 a 450 Mhzcon 256 MB di RAM. Sebbene la macchina sia abbastanza potente, lavora al limitequando deve gestire tutto insieme.

Il sistema operativo presente sul PC è Linux, in particolare la distribuzione uti-lizzata è la RedHat 7.2. Forse di maggior importanza è il kernel real time utilizzato,questo è il kernel puro di Linux versione 2.4.4 “patchato” con RTAI 24.1.5. Questeversioni non sono più le più aggiornate, ma non sono neanche troppo datate. Si-

1DSP: Digital Signal Processor


curamente il kernel utilizzato offre maggior stabilità rispetto a quello usato in tesiprecedenti [9], il quale era una versione test.

Capitolo 2

Controllo real time

2.1 I sistemi real time: generalità

Un sistema software real time può essere definito come un “sistema che riescea garantire i vincoli temporali dei processi che manda in eseguzione”. I più notisistemi operativi moderni1 garantiscono buone prestazioni medie al sistema, mentrei sistemi operativi real time rispettano i vincoli temporali del sistema in ogni istante,penalizzando le prestazioni medie complessive del sistema stesso.

Le applicazioni real time possono essere distinte in due grandi famiglie:

� Sistemi soft real time, in cui il software deve essere in grado di rispettarenella maggior parte dei casi le temporizzazioni.

� Sistemi hard real time, in cui il software deve essere in grado di garantire inogni caso tempi di risposta massimi.

In altre parole non è possibile basarsi sulla media delle performance per valutareun sistema hard real time.

Queste riflessioni iniziali portano a definire quali sono le caratteristiche che unsistema real time deve possedere:

� Comportamento deterministico. Il sistema deve essere in grado di mettere inesecuzione un task RT2 e concluderlo in modo riproducibile e deterministico,cioè il tempo massimo di esecuzione deve poter essere noto con certezza.

� Prontezza. I task RT devono avere latenza minima, cioè l’esecuzione del taskdeve iniziare il più rapidamente possibile.

1Come ad esempio: UNIX, Linux e vari sistemi operativi di casa Microsoft2RT: real time

10 Controllo real time

� Robustezza. Il sistema deve funzionare sempre: un blocco della macchinanon deve avvenire per ovvie ragioni di sicurezza.

Esistono, attualmente, vari sistemi real time tra cui è doveroso citare QNX eReal Time Linux.

2.2 Real Time Linux

I sistemi real time Linux sfruttano una variante del kernel ufficiale di Linux. Neesistono essenzialmente due: RTLinux e RTAI; entrambe si comportano in modomolto simile e sfruttano le stesse idee di base. Per lo sviluppo delle applicazionilegate a questa tesi si è deciso di usare RTAI, in quanto precedenti progetti sviluppatial L.A.R. hanno utilizzato questa piattaforma. Ovviamente si è scelto di utilizzareil medesimo kernel.

2.2.1 Il kernel di Linux

Il kernel di Linux non nasce per applicazioni hard real time. La struttura internaè a divisione di tempo ed è studiata per ottimizzare le prestazioni medie del siste-ma, quindi alcune sue caratteristiche sono in contraddizione con quelle che sono leesigenze di un kernel real time.

Si può notare che la sincronizzazione a “grana grossa”, utilizzata dai sistemiLinux, implica che ci siano lunghi intervalli di tempo in cui un task ha l’accessoesclusivo ad alcuni dati, questo ritarderà l’esecuzione di un processo RT che richie-da gli stessi dati. D’altra parte una sincronizzazione a “grana fine” porta allo sprecodi molte risorse per gestire il cambio di contesto, a causa di continui passaggi da untask all’altro. Linux utilizza quindi una sincronizzazione a grana grossa per ottimiz-zare la prestazione media. Da non trascurare poi il fatto che Linux concede prima opoi una time-slice al processo con priorità più bassa, anche nel caso in cui ci sia unprocesso più importante pronto ad andare in esecuzione. In un sistema real time unprocesso con priorità maggiore non dovrebbe mai attendere a causa di un task conuna priorità minore. In un sistema generico, come Linux, vale la regola che: “tuttii processi fanno progressi almeno ogni tanto”, questo è inaccettabile per un sistemareal time. Inoltre per ottenere buone prestazioni medie Linux riordina le richiestedi accesso all’hardware da parte dei vari processi al fine di renderne più efficientel’uso della macchina e tenta di riunire varie operazioni insieme per sfruttare megliol’hardware stesso. Si noti che Linux fa attendere i processi ad alta priorità finchéprocessi a priorità minore non abbiano rilasciato le risorse necessarie.

2.2. Real Time Linux 11

Linux, inoltre, ha la caratteristica di avere porzione di codice critico eseguitocon interrupt disabilitati. Disabilitare gli interrupt è il modo più semplice per risol-vere problemi di sincronizzazione tra processi e di regolamentazione di accesso adaree dati comuni. Questa soluzione compromette la possibilità di rispondere imme-diatamente a richieste che vengono da eventi esterni, cosa inammissibile per sistemireal time che devono gestire con prontezza segnali provenienti dal mondo esternoche risultano, per definizione, asincroni.

Molto importanti sono anche le considerazioni su come viene trattata la variabiletemporale dai vari sistemi. Linux offre la possibilità di utilizzare una serie di timerhardware presenti sulle schede dei PC IBM-compatibili. La risoluzione dei timer èbassa e la loro accuratezza inadeguata per utilizzarli in applicazioni hard real time.

Da queste considerazioni si evince che Linux, senza opportune modifiche al ker-nel, è adatto a gestire applicazioni soft real time, ma non è sufficiente per controllareapplicazioni di tipo hard real time

2.2.2 RTAI-Linux

RTAI, acronimo di Real Time Application Interface, non è propriamente un si-stema operativo, ma porta delle modifiche al kernel di Linux per trasformare il siste-ma in modo da poter eseguire applicazioni hard real time. In pratica RTAI funzionautilizzando il kernel del sistema operativo Linux come un normale processo, esegui-to da un piccolo sistema operativo real time. Linux è in realtà un processo in back-ground del sistema operativo real time, e viene eseguito solo quando quest’ultimonon ha processi real time da eseguire. Linux non può mai disabilitare gli interruptso impedire di essere posto in attesa dal sistema operativo real time. L’idea di baseè abbastanza semplice: basta fornire un’emulazione software dell’hardware che ge-stisce gli interrupts. In pratica, quando Linux invia una richiesta di disabilitazionedegli interrupts al hardware, il sistema operativo real time intercetta la richiesta, lamemorizza e la rigira a Linux come accettata. Cosí facendo non si dà la possibilitàa Linux di disabilitare gli interrupts hardware; indipendentemente dallo stato in cuisi trova Linux non potrà mai inserire ritardi nella gestione degli interrupts da partedel sistema operativo real time. Tutte le richieste di interrupts da parte dell’hard-ware vengono intercettate dal sistema real time, che decide casa farne in funzionedell’handler associato. Se il sistema real time possiede un handler specifico, allo-ra questo viene eseguito, altrimenti significa che tale interrupt è destinato a Linux.In tal caso il micro kernel ha due possibilità. Se Linux ha gli interrupt abilitati, larichiesta gli viene passata come emulazione, altrimenti, nel caso in cui Linux ab-bia tentato di mascherare gli interrupt, il sistema real time marca la richiesta comependente, che verrà passata a Linux solo quando riabiliterà gli interrupts.


Interuppts control hard

Real Time kernel

Linux

Real Time task

Linux processes

Real Time FIFOS

Figura 2.1: Schema di principio di RTAI

Per poter realizzare quanto detto in precedenza si sfrutta il concetto di RTHAL3.Questa tecnica consiste nel creare una copia della tabella dei descrittori degli inter-rupts, intrappolare tutte le funzioni che gestiscono gli interrupts, generare una nuovatabella di descrittori contenente le routine real time e prendere il controllo del timerdi sistema. Sotto queste condizioni si può affermare che Linux è un task di un siste-ma real time, un task che verrà eseguito solo quando la parte real time non ha nullada fare. Tutto ciò è ottenibile in modo semplice ed elegante sfruttando i moduli4

del kernel di Linux. Un approccio di questo tipo ha il grande vantaggio che il cam-bio di contesto tra vari processi real time è particolarmente rapido, infatti i processisfruttano lo stesso spazio di indirizzamento. Ha, però, l’inconveniente di portare alblocco di tutto il sistema nel caso in cui un modulo avesse dei problemi legati a unanon corretta programmazione. I task RT devo quindi essere programmati con moltaattenzione.

Questo modello di gestione del sistema operativo porta necessariamente alla

3RTHAL: Real Time Hardware Abstarction Layer.4Un modulo del kernel è un file oggetto che può essere “linkato” dinamicamente al kernel

stesso, con esso condivide lo spazio d’indirizzamento, quindi può utilizzare funzioni del kernel eaggiungerne delle nuove.

2.2. Real Time Linux 13

definizione di un ulteriore scheduler5 per il micro kernel real time. Questo schedulerpuò essere modificato e, essendo un modulo, viene anch’esso caricato nel kerneldinamicamente. Ciò permette di creare più scheduler e di utilizzare il più opportuno,in funzione del tipo di macchina e dell’applicazione che dovrà essere eseguita.

Uno scheduler efficiente per un sistema real time ha bisogno di temporizzazioniprecise ed accurate. RTAI ha risolto questo problema utilizzando un timer program-mabile6 presente su tutte le schede dei PC IBM-compatibili. Questo timer ha duemodalità di lavoro: oneshot mode e periodic mode. In entrambe le modalità, allafine dell’intervallo programmato, vi è la generazione di un interrupt per avvertireil processore del tempo trascorso. La scelta di una o dell’altra modalità dipendedall’applicazione. Il periodic mode è adatto per quei task RT che vengono messiin esecuzione con tempistiche regolari, mentre la modalità oneshot risulta esseremolto più flessibile, ma anche leggermente più gravosa perché il timer deve essereriprogrammato ogni volta.

Come si è visto, la parte real time del kernel è distinta da quella non real time,questo ha permesso di poter sviluppare ed ottimizzare le due parti del sistema inmodo separato con vantaggi sia di ottimizzazione che di semplicità. Questo concet-to di separabilità della parte real time da quella non real time è vero non solo per ilsistema nel suo complesso, ma anche per le applicazioni che vengono sviluppate sulsistema stesso. In pratica ogni progetto può essere diviso nelle due parti precedente-mente accennate. Per come è stato concepito il sistema si ha quindi che la parte realtime è sicuramente un modulo linkato nel kernel, mentre la parte non real time èuna normale applicazione di Linux. Perciò si ha la necessità di poter scambiare datifra il modulo e l’applicazione. RTAI mette a disposizione due modi per scambiaredati fra kernel space e user space7:

� FIFO: è un semplice buffer real time, gestito come se fosse un file di caratteridove il lato real time scrive i dati e il lato Linux li legge o viceversa. Puòessere gestito in due modi: a polling, oppure è possibile associare una fun-zione handler alla FIFO che viene eseguita quando avvengono degli accessiin lettura o scrittura sul buffer.

� Shared memory: è un area di memoria allocata nel kernel space e condivisafra i task real time e i processi di Linux. Questo strumento è molto potente

5Lo scheduler è quella porzione del sistema operativo che gestisce le politiche e i meccanismiinterni che stabiliscono l’ordine con cui vengono eseguiti i vari task

6Ci si riferisce al chip 8254: questo in realtà più che un timer è un contatore, conta, in pratica,gli impulsi che arrivano su un determinato pin. Se a questo pin è applicato il clock del sistema ilcontatore si trasforma in un ottimo timer, che, tenuto conto delle frequenze di lavoro dei moderniprocessori, ha anche un elevata risoluzione.

7Per user space si intende quello spazio di indirizzamento dove vengono eseguite le applicazioniutente, esso è distinto e separato dal kernel space che è lo spazio di indirizzamento dove vieneeseguito il kernel e quindi tutti i task real time.


perché è privo di limitazioni, ma ciò implica che le regole per un correttoaccesso ai dati devono essere create di volta in volta con molta attenzione.

Le applicazioni real time che, per necessità o comodità, vogliono offrire al-l’utente finale un’interfaccia grafica per gestire il micro kernel real time, traggonovantaggio dalla sinergia tra task RT e processi Linux.

2.3 Controllo del robot SMART-3S con RTAI-Linux

Il sistema real time utilizzato al L.A.R. per controllare il robot SMART-3S èRTAI-Linux. Tralasciando dettagli tecnici su come è realizzato il collegamentohardware tra PC e robot8, è sufficente sapere, per comprendere i concetti che stan-no alla base del controllo real time, che sul bus ISA del PC è montata un schedachiamata Bit3, la quale è collegata direttamente al controllore. Leggendo oppor-tune aree di memoria della suddetta scheda, è possibile conoscere la posizione deimotori del robot e scrivendo su altre locazioni, è possibile imporre determinate cor-renti ai motori stessi. Inoltre ogni millisecondo il controllore genera un interrupt disincronizzazione e si aspetta che dopo 800µs siano presenti, in un’opportuna zonadi memoria, i valori di corrente da imporre ai motori. L’ordine di grandezza delletempistiche in gioco permette di intuire che il rispetto delle temporizzazioni è estre-mamente importante e si comprende quindi la necessità di utilizzare un sistema realtime per gestire il robot.

Considerando che i task real time sono in realtà dei moduli del kernel e che, nelcaso specifico, bisogna creare un driver per la scheda Bit3, si devono tener presentetutte quelle funzioni presenti nel kernel che servono per gestire le periferiche e tuttequelle regole per creare dei driver teoricamente corretti [10].

Per questa specifica applicazione si è deciso di creare due moduli distinti:� Bit3init.o: inizializza la scheda Bit3;

� rtai_comau.o: controlla il robot in real time.

Questi due moduli hanno caratteristiche profondamente diverse: il primo hasolo il compito di inizializzare la scheda Bit3 e non ha caratteristiche real time,mentre il secondo si occupa del controllo in tempo reale del robot. Tener separatele funzionalità permette di modificare la parte real time senza dover modificarel’inizializzazione della scheda e viceversa; inoltre permette di ridurre al minimonecessario il modulo real time, il quale risulta essere più leggero da mandare inesecuzione. Entrando nel cuore del progetto queste caratteristiche sarrano spiegatecon più dettaglio.

8Si veda a tal proposito il capitolo 1

2.3. Controllo del robot SMART-3S con RTAI-Linux 15

2.3.1 Il modulo Bit3init.o

Questo modulo ha il compito tipico di un driver per periferica, cioè nel momentoin cui viene caricato nel kernel riserva le aree di memoria utilizzate dalla scheda e lerilascia quando viene scaricato. Ha anche il compito di verificare che sia possibilecomunicare con il controllore del robot. Nel caso in cui questo non fosse possibile ilmodulo libera le risorse e si “stacca” dal kernel. Quest’ultima caratteristica è moltoimportante perché il modulo rtai_comau.o (che verrà descritto in seguito) richiedeesplicitamente che il modulo che inizializza la scheda sia “linkato” con il kernel. Inpratica la presenza del modulo Bit3init.o nello spazio di indirizzamento del kernelè garante del fatto che esiste la comunicazione tra PC e COMAU e che la schedaBit3 è stata inizializzata correttamente.

2.3.2 Il modulo rtai_comau.o

Il modulo rtai_comau.o è il più importante, è quello che controlla il robot CO-MAU SMART-3S. Il compito principale che deve svolgere è rispondere all’interruptgenerato dal robot, ma non si possono trascurare tutte quelle operazioni che svol-ge per rendere il modulo veramente funzionale. Operazioni come, ad esempio, lacreazione delle FIFO fra user space e kernel space, che servono per far si che unprogramma svillupato per Linux possa dare dai comandi al robot, e la creazione ditutti quei meccanismi che servono per “ingegnerizzare” il progetto9.

È possibile raggruppare il lavoro svolto da questo modulo in tre macro compiti:

1. richiesta di un interrupt real time, questo interrupt non è mascherabile ela funzione che gli viene associata è quella che, dopo opportuni controlli,calcola le correnti da imporre ai motori;

2. creazione di un task periodico, questo task periodico ha il solo compito difiltrare l’interrupt spurio;

3. creazione di FIFO per i comandi, queste FIFO servono per permettere ilcontrollo e il monitoraggio del robot da parte di applicazioni che operano neluser space.

Entrando nel dettaglio delle singole voci è possibile precisare alcuni concetti. Èimportante sottolineare che la separazione dei compiti è una scelta “didattica” per

9Per “ingegnerizzazione” del progetto si intendono tutte quelle funzioni che automatizzano alcu-ne parti del sistema in modo da rendere il sistema stesso utilizzabile anche da persone che non cono-scono profondamente i concetti fondamentali che stanno alla base del progetto. Si veda l’appendiceA per maggiori dettagli.


far comprendere meglio il lavoro svolto da questo modulo, ma in realtà le tre vocicitate andrebbero viste come un tutt’uno.

Interrupt non mascherabile

Questo interrupt è gestito da RTAI. Il segnale che lo genera arriva direttamentedal robot e la funzione che permette di associare il segnale al handler è la seguente:

void intr_handler(void)

{

/*

* Funzione associata al interrupt

* Viene eseguita tutte le volte che arriva l’interrupt numero 3.

* Non ha parametri d’ingersso ne di uscita.

*/

...

}

int init_module(void)

{

int res;

...

if((res=rt_request_global_irq(3,intr_handler))!=0)

return res;

...

}

void cleanup_module(void)

{

...

rt_free_global_irq(3);

...

}

Il codice che deve svolgere l’elaboratore per rispondere al interrupt è quello con-tenuto nella funzione intr_handler(). In questa funzione si eseguono i controlliper assicurarsi che le posizioni dei giunti siano entro i limiti prefissati, le correntinon superino i valori prestabiliti e i giunti non risultino bloccati. Se tutte le verifichevanno a buon fine allora viene invocata la funzione che ha il compito di calcolarele correnti da attuare ai motori. Il codice dell’interrupt handler viene riportato perpermettere al lettore di comprendere meglio la funzione stessa.


void intr_handler(void)

{

int err_CJL=0,err_CSL=0,err_CJB=0;

if (countint>8) {

outb(1,0x378);

countint=0;

WriteCurrents(currents0);

ReadMotorPositions(positions);

err_CJL=CheckJointLimits(positions);

err_CSL=CheckSpeedLimits();

err_CJB=CheckJointBlocked();

if ((!err_CJL)&(!err_CSL)&(!err_CJB)) {

save_cr0_and_clts(linux_cr0);

save_fpenv(linux_fpe);

restore_fpenv(task_fpe);

error_controllo=controllo(positions,currents);

save_fpenv(task_fpe);

restore_fpenv(linux_fpe);

restore_cr0(linux_cr0);

if (!error_controllo) {

WriteCurrents(currents);

for(i=0;i<6;i++)

oldpositions[i]=positions[i];

} else {


DriveOff();

rt_disable_irq(3);

}

} else {


DriveOff();

rt_disable_irq(3);

}

outb(0,0x378);

}

}

La funzione principe in questa routine è controllo(). In questa funzione siusano pesantemente variabili reali e quindi si sfrutta la FPU10. Per avere un cambiodi contesto più rapido, RTAI non salva di default lo stato della FPU passando da un

10FPU è l’acronimo di Floating Point Unit.


task a un altro. Per evitare errori, è opportuno salvare esplicitamente lo stato dellaFPU nel momento in cui si ha necessità di utilizzare tale unità e di ripristinarlo nonappena questo utilizzo termina. Questo è il significato del codice appena prima edimmediatamente dopo l’invocazione della funzione controllo(). In tale funzionesi rende anche necessario l’utilizzo di variabili definite static11 , in caso contrariosi ha un improvviso crash del sistema. Questo è inaccettabile. Se il PC esegue unriavvio non può più rispondere all’interrupt generato dal robot e quindi , poichèl’ultimo valore scritto nella memoria del controllore è correnti nulle, si ha la cadutadel robot attratto dalla forza di gravità. Si noti anche che se il comportamento delsistema fosse diverso, il crash del PC è in ogni caso inaccettabile. Si pensi comecaso estremo al controllo di un razzo per messa in orbita di satelliti, un crash delsistema porterebbe ad una catastrofe.

Quando viene invocata la funzione controllo(), si ha la scrittura del valorelogico alto sulla porta parallela, quando termina il valore viene riportato a zero.Questo genera un impulso sulla porta parallela, la cui durata coincide con il tempoche impiega il processore ad eseguire i calcoli per rispondere al interrupt. Sebbene,tutto questo, possa sembrare a prima vista inutile, è in realtà molto importante perdue motivi. Il primo motivo è sicuramente la possibilità di verificare che la scritturadelle correnti da attuare avvenga veramente prima dei 800µs imposti dal COMAU; ilsecondo è la possibilità di avere un’idea di quanto tempo il processore ha impiegatoper rispondere all’interrupt e, di conseguenza, quanto tempo rimane al sistema persvolgere altre funzioni. Quest’ultimo dato è importante perchè fornisce un idea diquanto tempo rimane al processore per svolgere applicazioni differenti dal controllodel robot, come, ad esempio, un programma di visione artificiale.

Un’altra caratteristica di questo codice, che a prima vista può sembrare bizzarra,è che, in realtà, i calcoli, necessari per conoscere le correnti, vengono svolti tutte levolte che arriva un interrupt e che la variabile countint è maggiore di 8. Questoserve per non considerare l’interrupt spurio che arriva ogni dieci millisecondi. Latecnica utilizzata è estremamente semplice e sarà più chiara in seguito.

Creazione di un task periodico per il filtraggio dell’interrupt spurio

Testando l’arrivo degli interrupt è possibile osservare che ogni dieci millisecon-di ne viene generato uno spurio ad una distanza di circa 200µs dal precedente. Con

11Le variabili static sono locali al blocco in cui sono definite ma hanno durata pari a tuttoil tempo di vita del programma. Esse, pertanto, esistono prima che la funzione in cui sono definitevenga mandata in esecuzione e continuano ad esistere anche al termine della funzione stessa. Questoevita un riallocazione delle risorse ogni volta che una funzione viene mandata in esecuzione, manecessitano di una maggior attenzione da parte del programmatore perché i valori in esse contenutisono persistenti.


una misura del tempo precisa è possibile filtrare questo segnale spurio, escludendotutte le chiamate che distano meno di un intervallo di tempo prefissato dalla chia-mata precedente. In pratica, il problema è risolvibile con un task periodico, conperiodo di 100µs, che incrementa un contatore tutte le volte che viene invocato. Laroutine dell’interrupt dovrà quindi solo controllare che questo contatore abbia supe-rato un valore prefissato. Nel caso in cui il controllo abbia risultato positivo vieneeseguito il codice del handler e riazzerato il contatore, altrimenti si esce senza farnulla. Da queste parole è possibile comprendere perché e presente un controllo sullavariabile countint nella routine di risposta all’interrupt, nel caso specifico si vedeche devono essere trascorsi almeno 800µs dalla chiamata precedente.

Il codice necessario per creare un task che viene mandato in esecuzione ogni100µs è il seguente:

#define TICK_PERIOD 100000

RT_TASK thread;

static void intr_filtro(int t)

{

while(1) {

countint++;

rt_task_wait_period();

}

}


{

RTIME t_period;

...

#ifdef ONE_SHOT

rt_set_oneshot_mode();

#endif

rt_task_init(&thread,intr_filtro,0,STACK_SIZE,0,0,0);

t_period=start_rt_timer(nano2count(TICK_PERIOD));

rt_task_make_periodic(&thread,rt_get_time()+2*t_period,t_period);

...

}

È importante osservare che, come già accennato, RTAI usa un contatore cometimer, il quale ha come base di conteggio il clock di sistema. Al fine di rendere ilcodice più portabile ed indipendente dalla frequenza del processore, si è utilizzatala funzione nano2count(TICK_PERIOD) che converte i nano-secondi in numero diclock macchina.


Creazione delle FIFO di comunicazione fra user space e kernel space

Un task real time per il controllo di un robot senza possibilità di interagire con unoperatore esterno ha, sicuramente, un utilizzo limitato. Per ovviare a questo incon-veniente nel modulo rtai_comau.o sono state create varie FIFO di comunicazionetra user space e kernel space.

Tre sono le FIFO fondamentali in rtai_comau.o:

1. FIFO per comandare il robot. Questa FIFO permette di eseguire semplicima essenziali operazioni, come accendere e spegnere i motori del robot, op-pure fermare il robot mentre esegue una determinata traiettoria cercando diraggiungere un set point.

2. FIFO per controllare il robot. FIFO di maggior importanza per il controllodel robot. È in questa coda che vengono scambiati i dati necessari per ilmovimento del COMAU. È possibile chiedere al modulo di scrivere sullaFIFO la posizione angolare di un singolo giunto e leggerla in un secondomomento da un’applicazione che opera nel user space, oppure, viceversa, èpossibile fornire dei set point ai singoli giunti. Altri movimenti sono statiimplementati, come la possibilità di muoversi nelle direzioni definite dalleterne cartesiane più caratteristiche della robotica. Impostate velocità massimae direzione è possibile muovere il robot dando i comandi di START e di STOP,oppure è possibile fornire un offset in centimetri. Nel caso in cui sia fornitoun offset, il modulo comunicherà il raggiungimento della posizione attraversola FIFO per i responsi dal robot.

3. FIFO per attendere responsi dal robot. FIFO che viene utilizzata dal mo-dulo nel kernel per comunicare il raggiungimento di una posizione richiestain precedenza.

Tutte queste FIFO possono essere considerate sia dal lato utente sia dal latokernel, entrambi gli aspetti sono interessanti. Per spiegarne il funzionamento e iltipo di utilizzo verrà presa in considerazione la FIFO per comandi, i concetti so-no facilmente estendibili alle altre. Questa FIFO è unidirezionale; le applicazionipresenti nel user space scrivono i comandi da passare al modulo, appena entranonella coda il kernel se ne accorge ed invoca l’handler associato. Entrando nel det-taglio, tenendo separati i due spazi di indirizzamento, è possibile comprendere ilfunzionamento.

Considerando la FIFO per i comandi, vista dal lato del kernel space, si posso-no fare importanti osservazioni. Il codice sotto riportato rappresenta una parte dimodulo che sfrutta le FIFO RTAI per comunicare con altre applicazioni.


#define CMDF 0

#define CMDFSize 1000

struct my_msg_struct_controllo {

int command;

...

};

int CMDF_handler(unsigned int fifo, int rw)

{

struct my_msg_struct msg;

if (rw == ’w’) {

rtf_get(CMDF,&msg,sizeof(msg));

switch (msg.command) {

...

case DRIVE_ON:

/*

* Codice per accendere i motori del COMAU

*/

break;

...

}

}

...

}


{

...

rtf_create(CMDF,CMDFSize);

rtf_create_handler(CMDF, X_FIFO_HANDLER(CMDF_handler));

...

}

La cosa più importante che si intuisce dalla gestione della FIFO, è la possibilitàdi associare una funzione che venga invocata in modo automatico tutte le volte chequalche task esegue una scrittura o lettura sulla coda. Nell’esempio riportato si hache, appena un’applicazione scrive o legge un valore sulla FIFO, viene eseguitala funzione CMDF_handler(), la quale controlla se è avvenuta una scrittura nellacoda e in tal caso legge il valore presente nella FIFO stessa. Questa gestione èestremamente intelligente, perché è possibile sincronizzare il modulo caricato nelkernel con eventi asincroni, tipici del mondo esterno, senza aver la necessità di


eseguire inutili polling sulla risorsa interessata, polling che porterebbe solo allospreco di risorse di calcolo.

Considerando ora le applicazioni che vengono eseguite nel user space, un esem-pio di programma potrebbe essere:

struct my_msg_struct_controllo {

int command;

...

};

void WriteToFifoCmd(int data)

{

struct my_msg_struct msg;

msg.command=data;

write(cmd,&msg, sizeof(msg));

}

int main()

{

int cmd;

...

if ((cmd = open("/dev/rtf0", O_WRONLY)) < 0){

exit(-1);

}

...

WriteToFifoCmd(DRIVE_ON);

...

close(cmd);

}

Si nota immediatamente che le FIFO vengono gestite come normalissimi file,è questo, forse, il loro maggior vantaggio. Questa caratteristica permette di utiliz-zare il robot pur non avendo nessuna conoscenza di programmazione real time, maconoscendo solo cosa scrivere e leggere nelle FIFO create dal modulo rtai_comau.o.

Nel modulo rtai_comau.o si sono utilizzate le FIFO sia per la loro facilità diutilizzo, sia perché non vi è la necessità di trasferire grandi quantità di dati. Un’al-ternativa alle FIFO esiste, è la “shared memory”, ma poichè necessita di grandequantità di codice scritto per regolamentare gli accessi in memoria, il suo utilizzoin questa applicazione non è giustificato.

2.4. Osservazioni pratiche su RTAI-Linux 23

2.4 Osservazioni pratiche su RTAI-Linux

Si è già accennato alla necessità che un sistema real time sia particolarmentestabile e robusto. Il kernel di Linux è famoso per la sua estrema stabilità. Questacaratteristica aiuta molto chi sviluppa applicazioni real time basandosi su un’ac-coppiata vincente, RTAI-Linux. Se i task real time sono ben testati, difficilmentecapiteranno spiacevoli sorprese. Inserire un modulo nel kernel è anche un modo permetterlo al riparo da tutte le applicazioni presenti nel user space. È capitato che,per errori grossolani dello sviluppatore (errori miei), il sistema si bloccasse. Nono-stante ciò si è notato che il kernel, e solo quello, continuava a funzionare. Quindianche se tutte le applcazioni ad alto livello erano bloccate, il task real time continua-va a leggere le posizioni dei giunti, calcolare le correnti da attuare e scriverle sulleopportune aree di memoria. Tutto questo è prova di grande stabilità ed affidabilità.


Capitolo 3

Visione artificiale

3.1 Introduzione

Nella robotica vengono spesso utilizzate celle di lavoro dove eventuali oggetti,che un manipolatore deve afferrare, sono in posizioni precise e prestabilite. D’altraparte, la multimedialità sta in questi ultimi tempi diffondendosi a 360 gradi, rag-giungendo livelli tecnologici impensabili fino a pochi anni fa. Anche la roboticaè stata, per certi aspetti, contagiata da questa evoluzione. Non sono rari robot cheparlano, ascoltano e soprattutto vedono. Partendo da questo presupposto è faci-le immaginare robot, che dotati di telecamera, afferrano oggetti nello spazio nonconoscendone la posizione a priori.

3.2 Richiami di ottica e manipolazione d’immagini

È opportuno, al fine di comprendere meglio quello che verrà trattato in seguito,riprendere alcuni concetti basilari dell’ottica geometrica. Verrà inoltre introdotto unalgoritmo di manipolazione dell’immagine, che permette di rilevare il contorno diun oggetto ripreso da una telecamera.

3.2.1 Ottica geometrica

L’ottica geometrica è una branca della fisica che considera le onde elettroma-gnetiche nel campo del visibile, e sfrutta la geometria per spiegare come esse sipropagano. Questo tipo di approccio è valido fintantoché le discontinuità incon-trate dall’onda nella sua propagazione hanno dimensioni molto grandi rispetto alla

26 Visione artificiale

lunghezza d’onda. Generalmente una telecamera rispetta questa ipotesi. Pochi esemplici concetti sono sufficienti per comprendere quello che segue [1].

Fondamentale è sapere come si comporta un raggio luminoso che attraversa unalente, e viene proiettato su di una superficie che è posta a distanza fissa dalla lentestessa. Si consideri la figura 3.1. Un raggio luminoso che parte dal punto P, dopo

��

��

��

��

��

��

O

H

P

L

l

α F

P’

h

S

Figura 3.1: Ottica geometrica.

aver attraversato la lente, colpisce la superficie S nel punto P’. Si definisce fattored’ingrandimento di una lente il valore M ottenuto come:

M �hH

dove h è la distanza tra il punto P’ e l’asse principale della lente1, mentre H è ladistanza tra P e il medesimo asse. Osservando la figura, è possibile notare un’altraproprietà, infatti può essere ricavata la seguente equazione:

tanα �HL�

hl

(3.1)

dove L è la distanza tra la proiezione del punto P sull’asse principale e il punto O2,e l è il suo analogo nel lato opposto della lente. Da questa equazione si concludeche: considerando noto l e misurabile h, si ha che, data la distanza tra il punto P el’asse principale della della lente è ricavabile L, e viceversa.

Si noti inoltre che una telecamera può essere vista come un trasduttore che tra-sforma in segnale elettrico un raggio luminoso proveniente da un oggetto, e che puòessere schematizzata come in figura 3.1 dove S rappresenta il sensore CCD3.

1L’asse principale della lente è definito come la retta passante per i centri che definiscono le duesemicirconferenze che generano la lente.

2Il punto O è detto centro ottico della lente ed è definito come il punto tale che ogni raggiopassante per esso esce in una direzione parallela al raggio incidente.

3CCD: Charged Coupled Device. Dispositivi allo stato solido ad accoppiamento di carica, chetrasformano l’energia luminosa ricevuta in energia elettrica.

3.2. Richiami di ottica e manipolazione d’immagini 27

Tenedo conto delle affermazioni fatte fin ora, è possibile concludere che: se nonsi conosce la dimensione dell’oggetto a priori, le informazioni contenute in un unicofotogramma sono insufficienti per calcolare la distanza fra la telecamera e l’oggetto.Si ha quindi la necessità di ottenere informazioni di due fotogrammi distinti. Duestrade sono percorribili per risolvere il problema e possono essere classificate infunzione della telecamera che si utilizza.

1. Telecamera “monoscopica”: telecamera di tipo classico con un solo obiet-tivo. Per aver due fotogrammi distinti bisogna necessariamente scattarli inistanti diversi, spostando la telecamera per ottenere due immagini differenti.

2. Telecamera stereoscopica: telecamera speciale con due obiettivi con assiottici paralleli. Questi permettono di riprendere la stessa scena da due puntidifferenti nel medesimo istante.

Quello che non si può fare nello spazio si fa nel tempo, questa è la differenza chesi ha a seconda della telecamera adottata. Va da se che, nel caso di telecamera nonstereoscopica, l’oggetto di cui si vuole conoscere la distanza non si deve muoverefra i due “scatti”.

Calcolo della distanza con telecamera “monoscopica”

Questo metodo di calcolo è, almeno teoricamente, molto semplice. Consistenel riprendere un oggetto fermo da una distanza incognita, allontanare la telecame-ra con offset noto e riprendere nuovamente l’oggetto. Valutando la variazione didimensione dell’oggetto, è possibile conoscerne la distanza dalla telecamera. Lasituazione appena descritta è rappresentata in figura 3.2, dove è schematizzata una

��

��

��

��

��

��

O

P P

hh

LL

2

l 1

=H

=l

α α

H 1

2

1

2 1

2 1

2

S

Figura 3.2: Calcolo della distanza con telecamera “monoscopica”.

telecamera e un punto P ripreso da due differenti distanze. Da questa schematizza-zione è possibile trarre alcune conclusioni. Applicando l’equazione 3.1 nei due casi


è possibile ottenere il seguente sistema:

�� L1 �l1h1

H1

L2 �l2h2

H2

da cui con qualche passaggio si ottiene:

L1 � Ah1

h1 � h2dove A � L2 � L1 (3.2)

Alcune osservazioni sono doverose. Si noti che il risultato L1 è dipendente solodalla differenza delle distanze da cui si riprende l’oggetto, e che il risultato ha lastessa unità di misura di A visto che la frazione è adimensionale. Quest’ultimaaffermazione permette anche di concludere che non si ha la necessità di conoscerela dimensione reale dell’oggetto, e che h1 e h2 non devono essere una lunghezza,ma possono anche essere misurati in pixel.

Calcolo della distanza con telecamera stereoscopica

Questo metodo di calcolo utilizza una base teorica semplice, ma richiede moltaaccuratezza nel realizzare la telecamera.

Una telecamera stereoscopica può essere schematizzata come in figura 3.3, cioècome due telecamere separate con assi visivi paralleli. Dato un punto P, i due raggiluminosi, che partono dal punto stesso, passanti per i centri delle due lenti, formanocon gli assi ottici delle telecamere due angoli. Senza entrare nel dettaglio della di-mostrazione, noti questi angoli e alcune caratteristiche costruttive della telecamerastereoscopica, è possibile determinare la distanza che separa il punto P dalle lentidella telecamera, cioè:

L � f � α1 � α2 � l � d � (3.3)

È necessario che i due assi ottici siano paralleli e che i due sensori CCD sianoperfettamente sincronizzati nell’acquisire l’immagine. Quindi, ad ogni punto del-l’immagine ripresa da un’obiettivo della telecamera che abbia un corrispondentenel fotogramma catturato dall’altro obiettivo, è possibile associare una distanza delpunto dalla telecamera.

Si intuisce che diventa fondamentale trovare lo stesso punto dell’oggetto in en-trambi fotogrammi, per poter determinare la distanza di quel punto dalle telecame-re, tale ricerca è un compito gravoso. Particolari accorgimenti costruttivi posso-no ridurre l’insieme dei pixel in cui cercare il punto. Queste osservazioni portano

3.2. Richiami di ottica e manipolazione d’immagini 29

��

��

��

l

L

α 1 α 2

dh2h1

1O O2

H H

P

1 2

P’ P’’

SS1 2

Figura 3.3: Calcolo della distanza con telecamera stereoscopica.

alla conclusione che non è possibile ottenere una telecamera steroscopica metten-do insieme due telecamere classiche, è, invece, necessario che venga costruita eprogettata come un unica telecamera.

3.2.2 L’algoritmo di Canny

Nei problemi di afferraggio è fondamentale conoscere la forma dell’oggetto,per far questo si può utilizzare l’algoritmo di Canny [2]. Questo algoritmo è uti-lizzato per rilevare il contorno degli oggetti. Il contorno di un oggetto presente inun’immagine è formato da aree di punti dove il livello d’intensità varia nettamente.Da questo si intuisce l’utilizzo dell’operatore gradiente per la ricerca dei punti dimassima variazione di luminosità.

L’algoritmo di Canny applica l’operatore gradiente ad un’immagine smussata


mediante filtro gaussiano, ed esegue una soppressione dei punti di non massimo edi quelli perpendicolari alla direzione del contorno per ottenere bordi sottili. Il risul-tato dipende dalla scelta di alcuni parametri, come l’ampiezza del filtro gaussianoe la soglia per la soppressione dei punti di non massimo. Nella scelta di questi pa-rametri, si deve tenere presente che per ripulire le immagini da falsi bordi generatida ombre, è necessario usare soglie abbastanza elevate, ma che questa scelta puòcausare la perdita di alcuni dettagli.

(a) Ingresso (b) Uscita

Figura 3.4: Esempio di applicazione dell’algoritmo di Canny.

In figura 3.4 è rappresentato un esempio di applicazione dell’algoritmo di Can-ny. A sinistra, in toni di grigio, è mostrata l’immagine data in ingresso all’algoritmo,a destra, quella in uscita. Si noti che l’uscita è formata dai punti in cui è presenteuna discontinuità di intensità nell’immagine d’ingresso.

Trovato il contorno di un oggetto, è possibile definire il centro di gravità “geo-metrico”. Questo è calcolato sfruttando solo informazioni legate alla geometriadell’oggetto, senza far riferimento alla massa. La definizione più semplice è datadalla media delle coordinate x e y dei punti che formano l’oggetto. Questa, e altredefinizioni simili, sono usate dall’algoritmo di visione per calcolare la distanza fraoggetto e robot.

3.3 Distanza fra robot e oggetto: soluzione teorica

Si consideri un manipolatore con una telecamera “monoscopica” montata sul-l’end effector. Per afferrare un corpo rigido con il manipolatore, si deve individuarela posizione del corpo rigido sfruttando solo la le informazioni provenienti dallatelecamera..

3.3. Distanza fra robot e oggetto: soluzione teorica 31

Un corpo rigido nello spazio può essere caratterizzato dalla posizione e orienta-mento di una terna solidale al corpo stesso rispetto ad una terna fissa di riferimento.Tre parametri sono sufficienti per individuare la posizione dell’oggetto, possono es-sere scelti arbitrariamente purchè siano linearmente indipendenti. Tre coordinatecartesiane individuano un punto nello spazio rispetto ad una terna di riferimento, ilmedesimo punto può essere caratterizzato da tre coordinate polari.

Afferrare un corpo rigido nello spazio con un robot significa, nella formulazionepiù semplice del problema, far coincidere un punto del corpo rigido con un puntosolidale all’end effector del robot4. Quindi dati due punti, uno solidale all’end ef-fector e l’altro appartenente all’oggetto, è possibile farli coincidere muovendo ilrobot lungo la retta che li congiunge, e spostando il manipolatore di un offset parialla distanza che li separa.

Risolvere il suddetto problema significa risolvere due sotto problemi:� allineamento, consiste nell’allineare l’asse d’approach del robot con la dire-

zione in cui si dovrebbe muovere l’end effector per afferrare l’oggetto;

� calcolo della distanza, consiste nello stimare la distanza tra oggetto e robot.

La scomposizione in due problemi minori non permette di risolverli in parallelo.È necessario risolvere prima l’allineamento poi, in un secondo momento, valutarela distanza dell’oggetto.

L’asse d’approach non deve necessariamente coincidere con l’asse visivo dellatelecamera, ma è sufficiente che questi due siano paralleli. In figura 3.5 è rappresen-tato la parte terminale di un manipolatore, al quale è stata montata una telecamera.Se i due assi sono paralleli, eseguire un’approach con il robot equivale a muovere

��

��

��

��

��

��

d

O

x

y

O x

y

Figura 3.5: Telecamera montata su end effector.

la telecamera lungo il suo asse ottico. Quindi, allineare la telecamera e calcolarela distanza tra telecamera e oggetto equivale, a parte offset noti a priori, calcola-re la distanza fra end effector e oggetto. Per semplicità si è supposto di ragionarenel piano, ma le considerazioni che seguono sono facilmente estendibili al casotridimensionale.

4Un punto solidale all’end effector non deve necessariamente appartenere all’end effector stesso.


3.3.1 Allineamento

Allineare il robot con l’oggetto significa, in ultima analisi, fare in modo chela retta, individuata dall’asse ottico della telecamera, passi per un punto ben pre-ciso dell’oggetto. La scelta più naturale del punto ricade sul centro di gravità“geometrico”.

Si consideri una telecamera montata sull’end effector, per allinearla sono possi-bili due tipi di scelte. Una prima possibilità mantiene inalterato l’orientamento dellatelecamera e utilizza solo movimenti sul piano perpendicolare all’asse visivo del-la telecamera stessa. L’altra possibilità usa rotazioni per modificare l’orientamentodella telecamera.

Considerando il montaggio della telecamera sul gripper, il primo metodo sfruttasolo i movimenti NORMAL e SLIDE per effettuare l’allineamento, mentre l’altrorichiede l’uso dei movimenti PITCH e YAW per risolvere il problema.

I due metodi sono equivalenti se si utilizza un controllo che tiene conto solo delsegno dell’errore. Se si utilizza un qualsiasi altro controllo, che sfrutta anche il mo-dulo dell’errore, allora la soluzione che usa PITCH e YAW presenta un vantaggio:l’errore non dipende dalla distanza tra oggetto e telecamera.

��

��

��

L

lE

e

α

Figura 3.6: Allineamento.

Con riferimento alla figura 3.6, l’angolo α rappresenta l’errore di rotazione,mentre, E quello di traslazione. Con semplici osservazioni geometriche si puònotare che:

E �eLl

e α � arcsin� e

l La variabile e si può considerare nota (basta un semplice conteggio di pixel), cosícome il parametro l che è legato a fattori costruttivi della telecamera. La distanzaL, poichè l’allineamento avviene prima del calcolo della distanza, è da considerarsiincognita. Un qualsiasi controllo che sfrutta le traslazioni della telecamera, basatosul modulo dell’errore, è difficile da realizzare perché dipende da una grandezzaincognita. Più semplice da realizzare è un controllo che sfrutta le rotazioni della

3.4. L’algoritmo di visione artificiale 33

telecamera per annullare l’errore, in quanto quest’ultimo è noto con “precisione”5.Da notare l’approssimazione fatta nel ragionamento, infatti si è supposto, che l’assedi PITCH della telecamera e quello dell’end effector siano coincidenti anche se inrealtà sono paralleli. Lo stesso vale per l’asse di YAW.

Da quanto detto la soluzione che utilizza le rotazioni è migliore. Lo è ancheper un ulteriore motivo, che può essere chiarito solo nel momento in cui verrannodescritti i problemi, che nascono nel fondere insieme la parte real time e quella divisione artificiale.

3.3.2 Calcolo della distanza

Calcolare la distanza di un punto dalla telecamera è semplice e basta applica-re i concetti visti nel paragrafo 3.2.1, in tal caso le variabili hi, con i � 1 � 2, checompaiono in 3.2, sono univoche.

Se si considera un oggetto, che è formato da più punti, la scelta non è più uni-voca. Si potrebbe scegliere l’altezza o la larghezza dell’oggetto come valore daassegnare ad hi. Un’altra scelta potrebbe essere di assegnare ad hi la media delladistanza tra i punti del contorno e il centro di gravità “geometrico”. Per compren-dere il concetto si pensi ad un cerchio. La distanza media dei punti che formano ilcontorno con il CdGG6, disturbi a parte, è il raggio. Se il medesimo cerchio vie-ne inquadrato da due differenti distanze, la sua dimensione cambia e quindi variaanche il raggio.

Un’osservazione è doverosa, poichè il calcolo della distanza avviene dopo l’al-lineamento, parlare di CdGG o del centro dell’immagine è la stessa cosa, almenoin teoria. In pratica non vi è la certezza che l’asse di approach del robot e l’asseottico della telecamera siano perfettamente paralleli. Questo errore di parallelismopuò far si che, dopo l’allontanamento, i due centri non coincidano più. Questo è ilmotivo per cui è preferibile considerare il centro di gravità geometrico.

3.4 L’algoritmo di visione artificiale

L’algoritmo di visione artificiale si basa sui concetti teorici visti in precedenza.Scopo di questo software è permettere al robot di afferrare un oggetto inquadra-to dalla telecamera. Il software deve fornire gli strumenti per essere funzionale;un operatore deve avere la possibilità di muovere il robot e di poter selezionarel’oggetto che si vuole afferrare.

5La precisione è legata anche alla risoluzione della telecamera.6CdGG: centro di gravita “geometrico”.


Figura 3.7: Screenshot del software di visione.

In figura 3.7 è rappresentato uno screenshot del software di visione. Una brevedescrizione può aiutare ad entrare più velocemente nell’ottica del software. La fine-stra principale è Robotic Vision, si possono notare tutte le strutture classiche perl’interazione con operatore. La finestra TP rappresenta un “theach pendent” virtuale,con questo strumento è possibile dare il DRIVE ON e il DRIVE OFF al robot, inol-tre è possibile muoverlo con semplici clic del mouse. Un operatore può posizionareil robot in modo tale da ottenere l’inquadratura che preferisce. La finestra COMAU’seye è aggiornata continuamente e vi è riprodotta l’immagine inquadrata dalla tele-camera. In questa specifica figura, la pallina è stata selezionata per essere afferrata,si nota infatti che è contenuta in un rettangolo verde; l’algoritmo considererà solole informazioni contenute nel suddetto rettangolo per afferrare l’oggetto.

Con questa descrizione in mente è possibile entrare nel dettaglio dell’analisidel software. Nel progettare il software non si deve dimenticare che il controllodel robot in real time è un compito gravoso per il processore, la manipolazioned’immagine forse lo è ancora di più.

Per comprendere come è stato sviluppato l’algoritmo, e le scelte fatte durantela sua creazione, si devono conoscere quali sono i compiti che l’algoritmo devesvolgere. Questi sono tre e per ognuno viene creato un thread7, in modo tale da

7I thread sono “processi leggeri”, nel senso che la creazione, distruzione e sincronizzazione sonorelativamente economiche grazie alla condivisione dello spazio di indirizzamento.


poter essere svolto in parallelo agli altri. I macro-compiti sono:

� creazione e gestione dell’interfaccia grafica del software. Questo threadha il compito di gestire tutta l’interfaccia grafica, è sempre attivo. Il compitoche svolge è occuparsi dell’interazione con l’operatore, ricevere in ingressocomandi e parametri e fornisre in uscita informazioni utili per comprenderele operazioni svolte dal software.

� comunicazione con il modulo real time per il controllo del COMAU. Que-sto thread invia i comandi per far muovere il robot, è il cuore del software.Legge le immagini dal framebuffer nel caso debba allineare il robot e calco-larne la distanza dall’oggetto.

� gestione delle immagini provenienti dalla telecamera. Questo thread ge-stisce l’acquisizione delle immagini, è basato sulla libreria libbgrab. Il suocompito è leggere l’immagine dal framegrabber e, dopo opportune modifi-che, aggiornare la finestra COMAU’s eye. Due modifiche all’immagine sononecessarie per motivi legati al risparmio di risorse. La prima è necessariaperché, per ottenere migliori risultati nella stima della distanza, la risoluzio-ne delle immagini acquisite è elevata, ma per risparmiare risorse di calcolo,la risoluzione delle immagini visualizzate è bassa. La seconda perché l’im-magine acquisita è in bianco e nero mentre per visualizzarla deve avere laprofondità del colore pari a quella dell’interfaccia grafica di Linux. Se nonsi ha la necessità di aggiornare continuamente la finestra, questo thread vienefermato.

Questi compiti devono essere svolti in parallelo, ma, per poter risparmiare risorse,i thread non sono sempre in esecuzione, perciò vengono fermati appena viene amancare la necessità della loro esecuzione.

Per questo parallelismo, spiegare il software è sicuramente più complesso, forseil metodo più lineare è seguire un percorso “temporale”, nel senso di spiegare i varipassi che il programma esegue per afferrare un’oggetto. Le fasi in cui può esserediviso sono:

1. inizializzazione del software;

2. posizionamento del robot e selezione dell’oggetto da afferrare;

3. allineamento della telecamera;

4. calcolo della distanza tra oggetto e telecamera;

5. avvicinamento a distanza minima;


6. afferraggio.

È possibile entrare nel dettaglio delle singole voci per comprendere meglio il pro-gramma.

Inizializzazione del software

Il software, appena inizia l’esecuzione, inizializza il sistema. Carica i modulidel kernel necessari, attiva la comunicazione con il modulo real time che controllail robot e inizializza il framebuffer. Successivamente si divide in tre thread, unoper ogni macro-compito. Se una qualunque di queste inizializzazioni non va a buonfine, il programma esce segnalando l’errore.

Posizionamento del robot e selezione dell’oggetto da afferrare

In questa fase un operatore può muovere il robot per fare in modo che la tele-camera inquadra l’oggetto che si vuole afferrare, per fare ciò ha a disposizione ilteach pendant virtuale. Il TP8, creato in questo software, riprende quello realizzatoin precedenti tesi [9].

Inquadrato l’oggetto, è possibile selezionarlo con due semplici clic nella finestraCOMAU’s eye; il software considera questi due punti come spigoli opposti di un ret-tangolo, e sfrutta solo le informazioni contenute all’interno del rettangolo stesso perafferrare l’oggetto, questo è il motivo per cui viene chiamata bound box. Utilizzaresolo le informazioni di una porzione dell’immagine ha un due vantaggi: da un latosi ha un risparmio di risorse poichè si utilizza un immagine più piccola, dall’altrosi introducono meno disturbi, eliminando tutto quello che è esterno al rettangolo.Selezionato l’oggetto, basta premere sul pulsante start per far si che il robot iniziil’allineamento.

Allineamento della telecamera

Il problema è quello visto nel paragrafo 3.3.1, la soluzione pratica richiede qual-che precisazione in più rispetto a quella già vista in teoria. La soluzione è la seguen-te: se l’asse ottico della telecamera passa per il centro di gravità geometrico, allorail pixel che individua il CdGG è nel centro dell’immagine ripresa dalla telecamera.Quindi, per risolvere il problema, si deve muovere il robot in modo tale che i duepunti coincidano. Con riferimento alla figura 3.8, sia C il centro di gravità geome-

8TP: Teach Pendant


e

ey

O

C

T

x

y

x

Figura 3.8: Allineamento.

trico e T il centro della telecamera. Per farli coincidere si muove il robot usandoPITCH e YAW con velocità proporzionale all’errore misurato in pixel. In pratica,l’algoritmo determina il CdGG dell’oggetto e calcola gli errori nelle due direzioni,imposta quindi la direzione e la velocità con cui muovere il robot. Successivamen-te acquisisce una nuova immagine e ripete il procedimento ricalcolando l’errore eimposta una nuova velocità. Poichè, teoricamente, l’errore è diminuito, l’algoritmoriduce la velocità del robot. Si intuisce, quindi, che il robot si muove velocementese l’errore è grande, riducendo la velocità man mano che i punti C e T si avvicinano.

Muovendo il robot cambia l’inquadratura, quindi l’oggetto si muove all’inter-no del fotogramma e perciò si deve muovere anche il rettangolo che lo seleziona.La soluzione più semplice è la seguente: considerando due fotogrammi successi-vi, se l’oggetto si è spostato di un determinato numero di pixel In questo caso ilsuo CdGG si sarà mosso dello stesso numero di pixel, quindi basta muovere il ret-tangolo di conseguenza. In realtà vi è un problema di inizializzazione, infatti nelprimo movimento non si ha il fotogramma precedente da confrontare, allora si muo-ve la bound box di un numero di pixel proporzionale alla velocità con cui si muoveil robot. La costante di proporzionalità è stata determinata sperimentalmente pertentativi.

È importante che durante l’allineamento l’oggetto rimanga sempre dentro labound box, in caso contrario parte del contorno potrebbe essere escluso dal calcolodel CdGG, producendo un errore nella determinazione del centro stesso.

Durante l’allineamento l’errore dovrebbe solo diminuire, se per qualche mo-tivo dovesse aumentare oltre un certo limite, allora il robot viene fermato perchésignifica che l’oggetto è stato perso.


Inoltre, l’allineamento viene concluso solo quando in tre fotogrammi successivii punti T e C coincidono, questo garantisce maggior sicurezza sulla corretta ese-cuzione dell’allineamento. Cosí facendo si evitano errori dovuti a disturbi presentisolo in un singolo fotogramma.

Calcolo della distanza tra oggetto e telecamera

Per determinare la distanza fra telecamera e oggetto si devono applicare i con-cetti visti nel paragrafo 3.3.2. Data l’immagine ripresa dalla telecamera, si deter-mina il contorno dell’oggetto e il centro di gravità geometrico, successivamente sicalcola la distanza media dei punti che formano il contorno dal CdGG. Eseguendoun approach negativo, si allontana il manipolatore dall’oggetto e si riesegue il cal-colo precedente. Infine, si riporta il manipolatore nella posizione di partenza e siripete il calcolo della distanza media. Cosí facendo, si ottengono tre misure delladistanza media del contorno dal CdGG: la prima e la terza (dm1 e dm3) sono ef-fettuate a distanza D dall’oggetto, mentre la seconda (dm2) ad una distanza pari aD � A. È possibile trovare la distanza D che separa oggetto e telecamera applicandol’equazione:

D �A2

��dm2

dm1 � dm2 � � �dm2

dm3 � dm2 �� (3.4)

dove A è la misura in centimetri del approach negativo eseguito dal manipolatore.

Questo è il minimo indispensabile per risolvere il problema, alcuni accorgimentipossono migliorare molto il risultato finale.

Ricordando i concetti di ottica geometrica e applicando l’equazione 3.1, si hache:

dmi �KD

(3.5)

dove K è una costante che dipende dalla dimensione dell’oggetto e da caratteristi-che costruttive della telecamera. Da questa formula si evince che la dimensionedell’immagine dell’oggetto è inversamente proporzionale alla distanza da cui vieneripreso. In figura 3.9 è graficato l’andamento dell’equazione 3.5 con K � 25009. Sipuò notare che, a parità di approach negativo eseguito, la differenza tra due valori didmi varia in funzione della distanza da cui si esegue il calcolo. Se si considera la te-lecamera come un trasduttore, il cui ingresso è la distanza tra telecamera ed oggettoe l’uscita è la dimensione in pixel dell’oggetto stesso, è possibile affermare che lasua sensibilità non è costante, ma è molto sensibile per oggetti vicini alla telecamerae poco sensibile per quelli lontani. Partendo da queste considerazioni e analizzando

9Il valore di K utilizzato è stato determinato sperimentalmente. Vedi capitolo 4


20 30 40 50 60 70 8030

40

50

60

70

80

90

100

110

120

130

Distanza (cm)

Dim

ensi

one

imm

agin

e (p

ixel

)

Figura 3.9: Risoluzione della telecamera.

i dati sperimentali (vedi capitolo 4) è possibile affermare che il miglior punto dilavoro della telecamera utilizzata in questo progetto è nell’intorno dei 35cm.

Quindi è possibile ottenere una maggior precisione nel determinare la distanzatra oggetto e telecamera, se quest’ultima è posizionata circa a 35cm dall’oggettostesso. Per questo motivo si è scelto di eseguire, in caso di necessità, più volte laprocedura per determinare la distanza tra oggetto e telecamera. Il comportamentodell’algoritmo è il seguente: se determinata la distanza questa risulta apparteneread un range tra i 32 � 5cm e 37 � 5cm allora il robot segue l’avvicinamento a distanzaminima, altrimenti si porta, errore parte, a 35cm e ridetermina la distanza con lastessa procedura descritta in precedenza. Tutto questo garantisce migliori risultati.

Inoltre, per aumentare la precisione, tra due procedure di determinazione delladistanza viene rieseguito l’allineamento. Questo viene fatto per correggere errori diapproach dovuti al non perfetto parallelismo tra asse d’approach e asse visivo, e percorreggere movimenti non perfetti del manipolatore.

Modificare il punto di partenza della procedura del calcolo della distanza signi-fica modificare la dimensione dell’oggetto ripreso; questo comporta una modificanella dimensione della bound box tra una procedura e l’altra. Si noti che, se si ese-gue un approach in avanti tra due procedure, il ridimensionamento del rettangolo diselezione è una necessità, perché la dimensione dell’immagine dell’oggetto aumen-ta. Nel caso opposto, cioè si esegue un approach negativo, il ridimensionamento èun’utilità per eliminare parte dei disturbi.

La soluzione del problema del ridimensionamento della bound box è sempli-


ce se si applicano i concetti dell’ottica geometrica. Si ottiene, infatti, la seguenteequazione:

∆B � Bi

�Di � D f

D f � (3.6)

dove Di rappresenta la distanza iniziale dall’oggetto, D f quella finale e Bi la dimen-sione iniziale della bound box. L’equazione 3.6 restituisce la variazione della boundbox in pixel se Bi corrisponde alla dimensione iniziale della medesima grandezzamisurata in pixel. Tale formula deve essere applicata sia alla dimensione verticaleche a quella orizzontale. Poichè l’oggetto è al centro dell’immagine, il ridimensio-namento deve avvenire in tutte è quattro le direzioni, quindi metà ∆B è applicato inuna direzione e l’altra metà nella direzione opposta.

Si è già fatto notare che è importante che l’oggetto rimanga sempre tutto con-tenuto nel bound box, per questo motivo nel ridimensionamento si è applicato uncoefficiente moltiplicativo di sicurezza pari al 15%. Questo comporta metodi diffe-renti di calcolo del ∆B a seconda che, per portarsi a 35cm dall’oggetto, si eseguaun approach negativo o positivo, cioè:

∆B �

�� 1 � 15Bi

�Di � D f

D f � se D f� Di

0 � 85Bi

�Di � D f

D f � se D f � Di

(3.7)

Questo metodo di calcolo della distanza è sicuramente più macchinoso e, intermini di tempo, più lungo rispetto all’utilizzo di un singolo approach negativo,ma permette di ottenere risultati più precisi e ripetibili.

Avvicinamento a distanza minima

Determinata la distanza fra telecamera ed oggetto, viene eseguito un primo ap-proach per portare la telecamera a 20cm dall’oggetto. Considerando il montaggiodella telecamera sul gripper, si ha che l’oggetto si trova, traslazione in alto a parte,esattamente davanti al gripper.

L’approach per effettuare la presa viene spezzato in due fasi, cosí è possibile in-serire una funzione per determinare i punti di presa ottima. L’immagine, passata allafunzione di presa, è la migliore perché, essendo la telecamera particolarmente vici-na all’oggetto, i disturbi sono sicuramente minori. Inoltre, in tale situazione, poichèla distanza è definita, è possibile determinare la dimensione e altre caratteristichegeometriche dell’oggetto10.

10Basta moltiplicare per un coefficiente noto. Tale costante è stata determinata sperimentalmentee vale: pixel2cm � 0 � 028539647.

3.5. Precisazioni sull’algoritmo di visione 41

Se si considerano le caratteristiche costruttive del gripper, considerare le dimen-sioni reali e i raggi di curvatura dell’oggetto può essere molto utile nel determinarei punti di presa ottima [3].

Afferraggio

Calcolata la presa ottima, con NORMAL e SLIDE si posiziona il manipolatorein modo che l’asse d’approach del gripper passi per il CdGG dell’oggetto, successi-vamente si ruota l’end effector in modo tale che le dita del gripper vadano ad affer-rare l’oggetto nei punti prestabiliti. Infine, con APPROACH si muove il robot perfare in modo che l’oggetto si posizioni dentro il gripper. Quest’ultimo movimentoe parte della traslazione del polso sono dati solo da offset noti a priori e dipendentidal montaggio della telecamera sul gripper.

Si noti, infine, che questa fase avviene in catena aperta, in quanto l’oggetto nonè più inquadrato dalla telecamera.

3.5 Precisazioni sull’algoritmo di visione

Nella descrizione fatta fino ad ora, sono stati volutamente trascurati alcuni det-tagli per non appesantire troppo la trattazione. Alcune precisazioni sono doverose,poichè modificano il comportamento dell’algoritmo o migliorano il risultato finale.

3.5.1 Arresto del manipolatore per determinare la dimensionedell’oggetto

Il modulo del driver per la gestione della scheda d’acquisizione non è real time.Questo comporta che non è possibile associare ad un istante preciso l’immagine ac-quisita, di conseguenza è impossibile creare un legame tra posizione del robot e unospecifico fotogramma. Da queste parole, si intusce la necessità di fermare il robotper creare un corrispondenza univoca fra informazioni contenute nel fotogramma eposizione del manipolatore. Tutto questo preclude la possibilità di calcolare la di-stanza mentre il robot si sta muovendo ed introduce inevitabili ritardi nella soluzionedel problema.

Per evitare questo inconveniente, l’algoritmo invia la richiesta al robot di ese-guire un determinato movimento, e si mette in attesa della risposta da parte del ma-nipolatore di avvenuto raggiungimento della posizione. A robot fermo, si acquisiscel’immagine e la si lega alla posizione del manipolatore.


3.5.2 Utilizzo di più fotogrammi nella determinazione della di-mensione dell’oggetto

Come detto in precedenza, il modulo per la gestione della scheda d’acquisi-zione non è real time, quindi il processo che risponde all’interrupt del COMAU èpiù importante di quello che acquisisce l’immagine della telecamera. Può capitareche, subito dopo il movimento del robot, l’immagine presente nel buffer del frame-grabber sia in realtà “vecchia”, e non corrisponda a quella ripresa in quell’istante.Ovviamente capita che l’immagine richiesta dopo un approach del manipolatorecorrisponda in realtà ad un immagine catturata quando il manipolatore si trovava inun’altra posizione. Se si utilizza un unico fotogramma, tutto questo può produrreerrori nel calcolo della dimensione dell’oggetto.

Per evitare errori nella determinazione della distanza media dei punti del con-torno del CdGG, vengono utilizzati più fotogrammi. L’algoritmo considera cinqueimmagini e per ognuna calcola la dimensione dell’oggetto, successivamente scartail più grande e il più piccolo risultato ed esegue la media dei restanti.

3.5.3 Un motivo pratico per utilizzare PITCH e YAW nell’alli-neamento

Alla luce delle considerazioni fatte sul modulo real time e quello per il frame-grabber, è possibile comprendere un’ulteriore motivo per cui è preferibile utilizzarei movimenti PITCH e YAW per allineare il manipolatore.

Ricordando la tecnica utilizzata per allineare il robot, presentata nel paragrafo3.3.1, si intuisce che se le immagini provenienti dalla telecamera non vengono ag-giornate, non è possibile ricalcolare l’errore di posizionamento e, di conseguenza,non viene ridotta la velocità con cui si tenta di eseguire l’allineamento. La situa-zione è aggravata dal fatto che, se ciò si verifica, non vi è neanche la possibilità daparte dell’algoritmo di accorgersi che l’errore è aumentato e quindi di arrestare ilmanipolatore.

Questa situazione non è immaginaria, anzi, è capitato che non venisse aggiorna-ta l’immagine per qualche secondo. Se ciò accade quando l’errore è ancora grande,spesso si ha la perdita dell’oggetto, poichè la velocità del robot è elevata.

Per ridurre la probabilità che ciò si verifichi, si è utilizzato un’immagine conuna risoluzione minore nella fase di allineamento. Questo accorgimento, però,non ha eliminato il problema, visto che il carico computazionale in questa fase èparticolarmente elevato.

In conclusione, allineare utilizzando i movimenti PITCH e YAW ha il vantaggio

3.5. Precisazioni sull’algoritmo di visione 43

di avere un comportamento del robot più “tranquillo”. In tal caso, infatti, il polsovaria il suo orientamento ma non la sua posizione.


Capitolo 4

Risulati sperimentali

4.1 Introduzione

Nell’algoritmo di visione sono presenti costanti che, a prima vista, sembranocreate magicamente. In realtà, le costanti utilizzate sono state determinate speri-mentalmente con una serie di misure. In questo capitolo verranno presentate tut-te le tecniche utilizzate per determinare parametri fondamentali dell’algoritmo divisione.

4.2 Come sono state ottenute le misure

Capire come sono stati ottenuti i dati è importante. La strada piú semplice èottenerli direttamente dall’algoritmo. Per farlo è stato modificato il software, inoltreè stata creata una situazione “ambientale” particolare.

L’oggetto, del quale si vuole determinare la distanza dalla telecamera, è statosostituito da un foglio di carta attaccato ad una lavagna. Su tale foglio è riportatoun cerchio perfetto, con raggio pari a 5 cm. Il manipolatore è stato allineato con ilcerchio ed è stato posizionato ad una distanza nota dal cerchio stesso. Tale distanzaè pari a 25 cm. A questo punto si è avviata la procedura di misura. Questa deter-mina un serie di grandezze che sono differenti a seconda dello scopo per cui è stataeseguita. In ogni caso si ha la creazione di un file contente una grande quantità didati. Si ritiene inutile, in questa sede, presentare tabelle enormi piene di numeri, chea prima vista possono sembrare inutili. Per tale motivo si è deciso di non riportarei dati in questa tesi se non sottoforma di grafici, sicuramente piú significativi. Inogni caso tali dati sono disponibili nel CD presente la L.A.R., insieme al softwaregenerato durante questa tesi.

46 Risulati sperimentali

4.3 Misura dell’errore di calcolo della distanza

Determinare l’errore nella misura è importante e può aiutare a comprenderescelte fatte nel creare il software.

Per determinare quello che serve è stata eseguita la seguente misura: posizionatala telecamera come specificato nel paragrafo 4.2 è stata poi allontanata, fino ad unadistanza pari 70 cm, con passi di un centimetro. Ad ogni step è stata determinata ladistanza tra oggetto e telecamera. Queste misure sono stata eseguita con approachdifferenti, nello specifico sono state eseguite misure con approach negativi pari a 8cm, 10 cm, 12 cm e 14 cm. Le misure sono state poi ripetute sei volte e ne è statafatta la media limitare gli effetti di disturbi casuali.

Poichè la distanza reale tra oggetto e telecamera è nota, è possibile determinarel’errore nella misura. In figura 4.1 è riportato l’andamento, per diffrenti tipi approa-

25 30 35 40 45 50 55 60 65 700

0.5

1

1.5

Distanza telecamera−oggetto (cm)

Err

ore

(cm

)

approach=14cmapproach=12cmapproach=10cmapproach=8cm

Figura 4.1: Errore medio per differenti approach.

ch, del valore assoluto dell’errore in funzione della distanza da cui è stata eseguitala misura.

Analizzando il grafico è possibile notare che il modulo dell’errore ha un minimonell’intorno di 35 cm. Questo significa che se la distanza viene calcolata quando latelecamera è a 35 cm dall’oggetto si ha maggior precisione nel risultato. Questo è ilmotivo per cui l’algoritmo esegue l’avvicinamento a distanza minima solo se questa

4.3. Misura dell’errore di calcolo della distanza 47

è stata determinata da una distanza compresa tra 32.5 cm e 37.5 cm, in ogni altrocaso tenta di portarsi 35 cm per ricalcolare la distanza.

Alcune considerazioni sono immediate. L’errore, a prima vista, sembra abba-stanza casuale, ma il suo valore assoluto è sempre minore di un centimetro. Unosservazione è doverosa: i dati sono stati ottenuti calcolando la distanza tra teleca-mera e un cerchio nero diseganto su un foglio bianco, situazione particolarmentefavorevole. Se si utilizzano oggetti reali la situazione è peggiore. Riflessi, ombre esituazioni particolari di luce modificano il risultato, cioè rendono il valore assolu-to dell’errore maggiore. In ogni caso, durante lo sviluppo del software si è notatoche, con oggetti reali l’errore, calcolato nell’intorno dei 35 cm, è indicativamenteintorno al centimetro. Il peggioramento delle prestazioni da caso “ideale” e reale ènotevole, ma non disarmante se si considerano le dita del gripper. Errori di un cen-timetro mi sembrano accettabili considerando che il gripper ha dita che misurano 7cm.

Una trattazione che considera solo l’errore medio e non quello massimo è sicu-ramente incompleta. Dai dati utilizzati in precedenza si è ricavato l’errore massimoeseguito nel calcolo della distanza. I risultati ottenuti sono graficati in figura 4.2.

25 30 35 40 45 50 55 60 65 700

0.5

1

1.5


Err

ore

(cm

)

approach=14cmapproach=12cmapproach=10cmapproach=8cm

Figura 4.2: Errore massimo per differenti approach.

L’errore ha lo stesso andamento dell’errore medio e, ovviamente, ha il medesi-mo ordine di grandezza.

Un’ultima considerazione è importante. Nell’algoritmo si è scelto di utiliz-


zare un’approch negativo pari a 12 cm per determinare la distanza tra oggetto etelecamera. Per motivare la scelta si consideri la tabella 4.1.

Approach (cm) Errore medio (cm)8 0,055

10 0,02212 0,01714 0,015

Tabella 4.1: Tabella errore medio.

I dati presenti in suddetta tabella rappresentano la media dell’errore calcolatoposizionando la telecamera a circa 35 cm dall’oggetto1. La media dell’errore èstata determinate per approach differenti. In tal modo è possibile notare come cam-bia l’errore medio in funzione dell’approach eseguito. È evidente che, più questoè grande piú è precisa la determinazione della distanza fra oggetto e telecamera.D’altra parte, approach piccoli implicano movimenti meno vistosi del robot, quindisono preferibili. Si è scelto di utilizzare un’approch negativo pari a 12 cm, poi-chè è un giusto compromesso tra precisione di calcolo e movimenti “tranquilli”del manipolatore. Un approach negativo maggiore a 12 cm non porterebbe ad unmiglioramento cosí significativo da giustificarne l’utilizzo.

4.4 Determinazione della costante pixel2cm

Determinare la dimensione reale, ed altre caratteristiche geometriche, di un og-getto conoscendone solo la dimensione in pixel è sicuramente di grande utilità. Ciòè possibile solo se si conoscono le caratteristiche della telecamera e se si conosce ladistanza tra oggetto e telecamera.

Per determinare quello che serve è stata eseguita la seguente misura: posizionatala telecamera come specificato nel paragrafo 4.2 è stata poi allontanata, fino ad unadistanza pari 70cm, con passi di un centimetro. Ad ogni step è stata determinata ladistanza media del bordo dal centro di gravità geometrico. Questa misura è stataripetuta per 12 volte. Per ogni distanza da cui è stata eseguita la misura si è fattala media dei valori ottenuti. Parte dei dati è stata riportata in tabella 4.2 perché inseguito verranno tratte delle conclusioni che sfruttano questi dati.

La media calcolata è rappresentata in figura 4.3 dai punti blu. La linea rossa

1Per intorno di 35 cm si intende che le misure sono state eseguite con la telecamera posta a 33cm, 34 cm, 35 cm, 36 cm e 37 cm

4.4. Determinazione della costante pixel2cm 49

L (cm) h (cm)25 150,0830 125,2935 107,4340 93,9945 83,5350 75,1955 68,3560 62,6765 57,8270 53,26

Tabella 4.2: Tabella distanza media del bordo dal CdGG

rappresenta la curva che interpola i punti. Per ottenere questa curva si sono utiliz-zati concetti presenti nel paragrafo 3.2.1. Riprendendo la formula 3.1 è possibileaffermare che:

h �H � l

L�

KL

dove K � l � H (4.1)

dove h rappresenta la media della distanza dei punti del bordo dal centro di gravitàgeometrico misurata in pixel, H è l’analoga grandezza dell’oggetto reale ripreso e lè un parametro caratteristico della telecamera. Si noti che, in questo semplice caso,H rappresenta il raggio del cerchio disegnato sul foglio.

Dall’equazione 4.1 si evince che h è una funzione iperbolica. Di conseguenzala curva rossa è data da un funzione del tipo:

y �ax� b (4.2)

dove, in questo esempio, con i dati misurati si ottiene a � 3759 � 9 e b � � 60 � 10� 6.

Per oggetti differenti si avranno costanti differenti e quindi, anche, curve differenti.Si noti che come ci si poteva spettare b è trascurabile, infatti in formula 4.1 noncompare.

Determinate le costanti a e b e possibile determinare la h di quel specifico og-getto per qualunque distanza. Per conferma della validità dei valori ottenuti si èmisurato la media della distanza dei punti del bordo dal CdGG con la telecameraposta 20 cm dal cerchio, e si è ottenuto un valore pari a 187.50 pixel2, calcolandolo stesso valore utilizzando 4.2 si ottiene:

y �ax� b � 3759 � 9

20� 187 � 99 (4.3)

2Si noti che poichè è una media risulta che il numero dei pixel è un valore frazionario


25 30 35 40 45 50 55 60 65 7040

60

80

100

120

140

160


Dis

tanz

a m

edia

del

bor

do d

al C

dGG

(pi

xel)

Dati misuratiInterpolazione dei dati misurati

Figura 4.3: Distanza media in pixel.

Se si conosce l’oggetto ci si può spingere oltre. Poichè il raggio del cerchio èpari 5cm, si ha che per oggetti ripresi da 20cm di distanza è possibile determinarela dimensione reale con un semplice conteggio di pixel, infatti si può dire che valela seguente corrispondenza:

37 � 59 pixel � 1 cm � 1 pixel � 0 � 0266 cm. (4.4)

Si definisce la costante di conversione da pixel a centimetri per un fotogrammadi un oggetto ripreso da 20 cm come: pixel2cm � 0 � 0266cm � pixel

� 1.

Nota questa costante è possibile conoscere le caratteristiche geometriche di qua-lunque oggetto ripreso da 20 cm. Per conferma di ciò è possibile fare una semplicemisura. Se si sostituisce il cerchio precedentemente considerato con uno piú picco-lo, è possibile conoscerne la dimensione sfruttando solo le informazioni provenientidalla telecamera. Infatti, considerato un cerchio di 2.5 cm di raggio ripreso da 20cm, la media della distanza dei punti del contorno dal centro di gravità geometricoè pari a 91.86 pixel. Se la dimensione reale non fosse stata nota si sarebbe potutadeterminare con:

r � 91 � 86 � pixel2cm � 2 � 46 cm (4.5)

dove r è il raggio del cerchio.

Si noti inoltre che la costante a dipende dalla dimensione dell’oggetto e da ca-ratteristiche costruttive della telecamera. Dalla 4.1 e dai dati ottenuti dalle misure

4.5. Conclusioni 51

si ha che:

a � k � H � l � l �aH�

3759 � 95

� 751 � 98 � (4.6)

Nota questa costante è possibile determinare il valore di a per il cerchio di raggiopari a 2.5 cm e, quindi, sapere in anticipo il valore della media della distanza deipunti del bordo dal centro di gravità geometrico. Applicando quanto detto a questoesempio è possibile determinare il valore di h del cerchio di raggio 2.5 cm ripreso a30 cm, infatti:

a � 2 � 5 � l � 1879 � 95 � h � aL�

1879 � 9530

� 62 � 66 (4.7)

Lo stesso valore determinato sperimentalmente è pari a h � 61 � 68 pixel.

4.5 Conclusioni

I dati presenati hanno lo scopo di far comprendere il perchè di alcune scelte fattenell’algoritmo di visione. L’utilizzo di un “ambiente di misura” particolare permettedi ottenere costanti utilizzate nel normale svolgimento del compito di presa conoggetti reali.


Conclusioni

Il lavoro qui concluso ha integrato in un unico PC un sistema distribuito formatoda tre computer, lo scopo di questo sistema è l’afferraggio di oggetti da parte delgripper A.S.I montato sul robot COMAU Smart-3S

Piccoli ritocchi sono stati portati alla parte real time che gestisce il robot, questisi sono resi necessari per rendere piú snella, veloce ed efficiente l’esecuzione deitask RT. Praticamente immutata è la gestione del gripper, infatti essendo eseguitasu di una scheda a parte non sono stati necessarie modifiche sostanziali. Il softwaredi visione artificiale, invece, è stato ricreato partendo da zero, cercando, da un latodi migliorarne la precisione dove ciò è stato possibile, e dall’altro di renderne piúsnella l’eseguzione dove ciò si è reso necessario.

A scapito di un leggero aumento del tempo impiegato per l’afferraggio, si è resaquesta operazione molto piú precisa. Si è inoltre notato che con l’attuale PC non èpossibile eseguire l’inseguimento dell’oggetto, in quanto il carico computazionaleper poterlo fare è troppo elevato.

Gli sviluppi futuri di questo lavoro possono spingersi in diverse direzioni. Si-curamente un primo passo potrebbe essere l’utilizzo di una telecamera stereosco-pica per determinare la distanza fra oggetto e robot. Inoltre, a mio avviso, sarebbevantaggioso modificare il driver del framegrabber per renderlo real time, questoeviterebbe la necessità di fermare il manipolatore per creare una corrispondenzabiunivoca tra immagine acquisita e posizione del robot.

54 Conclusioni

Appendice A

I moduli del kernel di Linux

A.1 Introduzione

Il kernel di un sistema operativo provvede alla gestione e al corretto funzio-namento del computer. Tutto questo lavoro viene implementato via software dalkernel, il quale viene caricato in memoria e messo in esecuzione al momento delboot della macchina. I kernel moderni, per non essere di dimensioni sproposita-te visto la grande varietà di hardware sul mercato, sono modulari; in questo modosi ha un kernel base di dimensioni ridotte, al quale vengono aggiunte funzionalitàcaricando in esso i moduli quando servono.

Un modulo è, quindi, un programma oggetto1 che viene inserito nel nucleoquando una certa funzionalità è richiesta. Il fatto che un modulo viene linkato alkernel ci permette di intuire che esso andrà ad operare nel kernel space2. Nel mo-mento in cui viene caricato nel nucleo mette a disposizione le sue risorse sia ad altreparti del kernel che ai processi utente che ne richiedano i servigi.

A.2 Moduli: funzionamento

Può essere utile analizzare cosa succede quando un modulo viene “linkato”, acausa di una richiesta esplicita da parte dell’utente (si vedrà in seguito come questaprocedura può essere automatizzata), per comprenderne meglio il funzionamento.

1Un programma oggetto ha questo nome perché, pur essendo codice eseguibile, e quindi unprogramma, deve ancora subire delle modifiche affinché possa essere eseguito dal computer.

2Il kernel space è in contrapposizione al user space nel quale operano le normali applicazioniQuesta divisione serve per evitare accessi non autorizzati alle risorse del sistema da parte di processiutente.

56 I moduli del kernel di Linux

Viene di seguito riportato il codice di un ipotetico modulo al quale si farà riferimentoper spiegarne il funzionamento3.

#define __KERNEL__

#define MODULE

#define EXPORT_SYMTAB

#include <linux/module.h>

#include <linux/kernel.h>

#include <asm/io.h>

#include <asm/page.h>

#include <linux/ioport.h>

int sum(int a, int b)

{

return a+b;

}

EXPORT_SYMBOL(sum)


{

if (check_region(0x200,0xf)) {

printk("Area già riservata\n");

return ENODEV;

}

request_region(0x200,0xf,"example_module");

return 0;

}


{

release_region(0x200,0xf);

printk("Modulo rimosso\n");

}

Compilato il sorgente è possibile caricarlo nel kernel in modo esplicito digitan-do al prompt il seguente comando:[root@lar22 misc]$ insmod ./example_module.o

Il comando insmod cerca di caricare il modulo nel nucleo risolvendo tutti quei sim-boli che si trovono nella tabella dei simboli del nucleo ed utilizzati dal kernel stesso,quindi esegue la funzione init_module(). Questa funzione viene richiamata tutte

3Si ipotizzi che il file oggetto ottenuto dalla compilazione di questo sorgente si chiamiexample_module.o.

A.3. Caricamento automatico di un modulo 57

le volte che il modulo viene caricato nel kernel. In essa vengono quindi inizializ-zate tutte quelle strutture dati che il modulo andrà poi ad utilizzare. Nell’esempioriportato questa funzione controlla se una determinata area di memoria è libera e incaso affermativo la riserva in modo che nessun altro modulo possa utilizzarla.

In modo del tutto analogo per rimuovere un modulo dalla memoria si deve digi-tare il comando:[root@lar22 misc]$ rmmod ./example_module.o

In questo caso viene seguita la funzione cleanup_module() che ha il compito dirilasciare le risorse utilizzate dal modulo ripulendo la memoria della strutture defi-nite in init_module(). Questo compito è essenziale perché se non venisse fattole risorse non sarebbero disponibili per altri moduli, anche se queste non sono piùutilizzate.

Il sorgente preso in esame è abbastanza semplice. Si noti che è definita unafunzione sum(), la quale esegue la somma di due numeri, che non è utilizzata dalmodulo preso ad esempio. In realtà tale funzione è messa a disposizione per altrimoduli che volessero utilizzarne i servigi. Si noti che con EXPORT_SYMBOL(sum) siafferma l’intenzione di rendere disponibile ad altri moduli tale funzione. È possi-bile allora introdurre il concetto di module stacking: può accadere che un modulonecessiti di una funzione implementata da un altro modulo e quindi prima di poterlocaricare si ha la necessità di caricarne un altro. I moduli vengono allora “impilati”uno sull’altro come avviene appunto nello stack da cui il nome di module stacking.Un modulo che intenda utilizzare una funzione definita in un altro modulo devechiedere esplicitamente che venga caricato in memoria se non è già presente, e perfare tutto ciò basta aggiungere nella funzione init_module() la seguente porzionedi codice:

int res;

if ((res=request_module(example_module.o))<0){

printk("Non è possibile caricare il modulo richiesto\n");

return res;

}

Dove request_module() è una speciale funzione che fa si che il kernel si in-carichi di caricare tutti i moduli che occorrono al modulo richiesto e poi il modulostesso.

A.3 Caricamento automatico di un modulo

Si è accennato in precedenza che un modulo può venire caricato nel kernel anche


senza una richiesta esplicita da parte di un utente, in modo del tutto automatico.Prima di continuare è opportuno fare qualche precisazione.

In Linux è presente una directory che contiene dei file speciali, ogni file presentein /dev rappresenta in realtà un dispositivo installato (o installabile) nel sistema,questo permette di vedere un dispositivo come se fosse un normale file. Ogni filespeciale ha associato un major number e un minor number che rappresentano ilcodice di identificazione di un determinato dispositivo. È possibile creare un filespeciale digitando il seguente comando:[root@lar22 dev]$ mknod -m 666 /dev/example_device c 200 0

Questo comando crea un file speciale di nome example_device il cui major numberè 200 e il minor number è pari a 04.

Per ottenere il caricamento automatico del modulo si devono aggiungere partidi codice al modulo stesso. Si consideri nuovamente l’esempio precedente e siaggiunga al codice le seguenti parti:

...

#define MOD_NAME "example_module.o"

#define MOD_MAJOR 200

int example_device_open(struct inode *inode, struct file *file)

{

return 0;

}

int example_device_release(struct inode *inode, struct file *file)

{

return 0;

}

struct file_operations example_device_fops = {

open:example_device_open,

release:examples_device_release,

};

...

Inoltre si aggiunga dentro le funzioni init_module() e cleanup_module() iseguenti pezzi di codice:


{

int res;

4Per ulteriori dettagli su mknod si faccia riferimento alle man pages.

A.3. Caricamento automatico di un modulo 59

...

if((res=register_chrdev(MOD_MAJOR,MOD_NAME,&example_device_fops))<0){

printk("Il major number %d non è libero\n",MOD_MAJOR);

return res;

}

...

}


{

...

unregister_chrdev(MOD_MAJOR,MOD_NAME);

...

}

In questo semplice esempio compaiono due funzioni example_device_open()e example_device_release() che non fanno nulla, in realtà in generale hanno unruolo molto importante e vengono eseguite tutte le volte che un programma nel userspace esegue una open() sul nodo che rappresenta il dispositivo con il major num-ber coincidente al MOD_MAJOR. Tutte queste informazioni sono definite nella struttu-ra example_device_fops che contiene i puntatori a tutte le funzioni che operanosul nostro dispositivo e che corrispondono ad altrettante chiamate di sistema. Si notiinoltre la funzione register_chrdev() che serve per “registrare” il dispositivo al-l’interno del nucleo legandolo una volta per tutte al suo major number. La funzionecomplementare viene invocata all’atto della rimozione del modulo dal nucleo, perrendere nuovamente disponibile la risorsa per altri dispositivi.

Resta ora da precisare il modo per collegare un determinato modulo ad un pre-ciso major number. È necessario aggiungere una riga nel file di configurazione deimoduli5 che crei questo legame. Ritornando all’esempio utilizzato fino ad ora, bastaaggiungere:

alias char-major-200 example_module.o

Fatto ciò il tentativo di apertura del file /dev/example_device avrà come effettoil caricamento del modulo nel kernel.

Si noti che il modulo rimarrà in “linkato” al kernel fin tanto che non avverrà unrimozione esplicita con l’opportuno comando, non vi è un metodo automatico dirimozione dei moduli dal kernel space.

5Nella distribuzione RedHat questo file è /etc/modules.conf


Appendice B

Il robot COMAU Smart-3S

B.1 Introduzione

La presente trattazione non è da intendersi sostitutiva ai manuali del COMAUSmart-3S [4] presenti al LAR, l’utilità è quella di facilitare il reperimento delleinformazioni e di chiarire tutti quei problemi di ordine pratico in cui è possibileimbattersi.

Precedenti tesi hanno già affrontato questo argomento, si ritiene utile riproporlocon i necessari adattamenti per il sistema operativo Linux.

B.2 Accensione del COMAU Smart-3S

Per accendere e spegere il COMAU Smart-3S bastano alcune semplici opera-zioni, per accendere:

1. portare la leva di alimentazione sul rosso;

2. girare la chiave rossa su ON.

A questo punto il robot dovrebbe fare il boot. Per spegnerlo bisogan essere sicuri diessere in modalità 0 ed eseguire:

1. girare la chiave rossa su OFF.

2. portare la leva di alimentazione sul verde;

Non riavviare il robot prima che siano trascorsi 20 � 30 secondi dallo spegnimeto.Può accadere che eseguendo la procedura di accensione del controllore non si

riscontri nessun tipo di reazione. In tal caso si riporti la leva di alimentazione sul

62 Il robot COMAU Smart-3S

verde e si apra il C3G 9000. In alto a sinistra, all’interno dell’“armadio”, vi è uninterruttore classificato come: Moeller PKZ2, lo si porti in posizione “0”, poi inposizione “1”. Si richiuda il C3G 9000 e si ripeta la procedura d’accensione. Nelcaso in cui il boot non avvenga ancora si ripeta quanto detto, in due o tre volte tuttodovrebbe risolversi.

Se dopo svariati tentativi non vi è ancora segno di vita da parte del controllorepotrebbe essersi bruciato un fusibile all’interno del C3G 9000. Questo si trova nellascheda la centro dell’“armadio”, dentro il porta fusibile nero, esattamente sopra adun relè giallo. Si controlli l’integrità del fusibile ed eventulamente lo si cambi.

B.3 Comunicazione tra controllore C3G 9000 e PC

Il controllore C3G 9000 può comunicare con un PC attraverso un cavo parallelooppure utilizzando un cavo seriale. Il primo metodo viene utilizzato per control-lare il manipolatore dal PC quando il C3G 9000 è in modalità “aperta”, non vienedescritto nel dettaglio in quanto è stato ampiamente trattato nel capitolo 1. L’al-tro metodo di comunicazione è tramite un cavo seriale, si utilizza semplicementesemplicemente per copiare il software dal PC al controllore o viceversa, non vieneassolutamente usato per il controllo.

B.3.1 Come cambiare della modalità di funzionamento per ilcontrollore C3G 9000

Come già accennato nella configurazione presente al L.A.R. sono possibili duemodalità di funzionamento: una detta “chiusa” e l’altra “aperta”. In modalità chiusal’utente può programmare il manipolatore con un linguaggio di alto livello1, manon può agire sul controllo. In modalità aperta il controllo del manipolatore vieneeseguito direttamente dal PC, in tale modalità vi sono modi differenti di controllareil robot in funzione del punto di apertura del anello di controllo. In questa tesi èstata utilizzata solo la modalità aperta ad un millisecondo.

Per passare dalla modalità chiusa (modalità 0) e quella aperta a un millisecondo(modalità 4) si deve eseguire la seguente procedura:

1. accertarsi che la chiave blu sul C3G 9000 sia su “LOCAL”.

2. caricare dal controllore i programmi ini e cnr1. Per farlo basta selezionare,

1Il linguaggio di programmazione del manipolatore COMAU Smart-3S è il PDL2.

B.3. Comunicazione tra controllore C3G 9000 e PC 63

dalla tastiera del C3G 9000, “PROGRAM”, “GO” e digitare “ini”, successi-vamente selezionare “GO” e digitare “cnr1”.

3. lanciato il software viene chiesto se sul bus VME è presente la scheda Bit3,rispondere “s”, alla richiesta della modalità che si vuole utilizzare: rispondere“4” per quella ad 1ms, viene inoltre chiesto il numero dell’arm: digitare “0”,ed infine indicare i giunti che verranno gestiti dal PC.

4. attendere il riavvio del controllore.

Dopo il riavvio il controllore è necessario caricare i moduli per la comunica-zione e per il controllo real time nel kernel di Linux, tali moduli sono Bit3init.o ertai_comau.o, si veda il paragrafo 2.3 per maggiori dettagli.

Per ritornare in modalità 0 si deve eseguire la seguente procedura:

1. ripetere i passi 1 e 2 della precedente procedura.

2. lanciato il software viene chiesto se sul bus VME è presente la scheda Bit3,rispondere “s”, la successiva domanda è la modalità che si vuole utilizzare:digitare “0”.

3. attendere il riavvio del controllore.

È importante non spegnere il PC quando i moduli per controllo real time sonoancora “linkati” nel kernel e, ancor più importante, non spegnere il manipolatorequando il controllore è in modalità 4. I motivi di tali affermazioni saranno piùchiari in seguito.

B.3.2 Come caricare del software nel C3G 9000

Il controllore C3G 9000 memorizza il sistema operativo e la calibrazione sudella RAM batterizzata, in alcune situazioni è possibile perdere il contenuto dellaRAM. Nel caso in cui, all’avvio, il sistema operativo non sia più presente sulla RAMil controllore tenta di fare il boot del sistema prelevando i file che gli servono dallaporta com02, in questo caso il controllore attiva automaticamente la comunicazionemettendosi in stato client. Il cavo classificato come “cavo seriale di comunicazionetra PC e C3G 9000” realizza fisicamente la connessione tra PC e controllore, questodeve essere collegato tra la porta seriale del PC e la porta “comm:0” del controllore.Si deve ora impostare il PC come server, per farlo basta digitare il seguente coman-do:[root@lar22 DISKC3G]$ kermit

2Questa porta è di tipo seriale ed è posta sul lato anteriore del controllore.


dove nella directory DISKC3G è conrtenuto il sistema operativo del controllore. Perrendere il PC server se deve digitare la seguente sequenza di comandi:

1. SET LINE /dev/ttyS0

2. SET SPEED 38400

3. server

Piochè il sistema operativo originariamente era nei dischetti, periodicamente il con-trollore chiederà di inserire il disco d’installazione successivo; basta premere invioe tutto procederà. Qundo il trasferimento del sistema operativo è completato, per faruscire il PC dal server mode basta premre “CTRL+C” e successivamente digitare“exit”. A questo punto il robot può funzionare solo in modalità “chiusa”, per po-ter utilizzarlo anche nelle altre modalità sono necessari due ulteriori file: ini.cod ecnr1.cod. Per poterli caricare la comunicazione deve essere impostata manualmen-te. Dal lato PC nulla cambia rispetto al trasferimento del sistema operativo. Dallato controllore è necessario eseguire la seguente procedura:

1. assicurarsi di essere nel menu principale tramite il tasto “PREV”.

2. selezionare “UTILITY”, “COMUNICATION” e “MOUNT”.

3. selezionare ora “KERMIT”, alla richiesta della porta sulla quale attivare lacomunicazione, digitare prima “/s”, poi “com0:”, mentre alla richiesta d’in-serimento della velocità di trasmissione si può digitare “38400” se la stessascelta è stata fatto dal lato PC.

In questo modo la comunicazione è attiva. Si devono ora trasferire i due file, perfarlo basta eseguire la seguente procedura:


2. selezionare “FILER” e “COPY”, alla richiesta del nome del file sorgente, di-gitare “com0:[nomefile.estensione]”3, poi digitare la destinazione “rd:” (in-dica la RAM batterizzata).

Per copiare i file dal controllore al PC basta invertire sorgente e destinazione.Per interrompere la comunicazione si deve: sul controllore selezionare “UTILI-

TY”, “COMUNICATION” e “DISMOUNT”, a questo punto basta digitare “com0:”,mentre sul PC basta ripetere quello detto in precedenza.

Con questi due file è possibile utilizzare il manipolatore anche in modalitàaperta.

3Esempio: “com0:*.cod”.

B.4. Calibrazione del COMAU Smart-3S 65

B.4 Calibrazione del COMAU Smart-3S

Calibrare significa “impostare lo zero dei resolver”. Se il robot non è calibratoappare sul monitor del controllore la scritta “ARM NOT CALIBRATE”, in tal casoè necessario eseguire la calibrazione e salvarla sulla RAM batterizzata.

La procedura di calibrazione è la seguente:

1. assicurarsi che la chiave blu sia su “PROGR”.

2. prendere il TEACH PENDANT e premere sui tasti “HOLD” e “DRIVE OFF”del controllore se sono illuminati, ripetere la stesse operazioni sul TEACHPENDANT e accendere i motori premendo il tasto “DRIVE ON”.

3. Utilizzando i tasti dei singoli motori mouvere i giunti in modo che le tacchepresenti sui giunti stessi coincidano.


5. selezionare “CONFIGURE”, “ARM” e “CALIBRATE”, alla richiesta del nu-mero dell’arm premere ENTER e digitare “*”, in modo che tutti i giuntivengano calibrati.

6. spegnere i motori.

7. selezionare “PRT” e “SAVE”, alla richiesta della scheda di controllo premere“ENTER” e successivamente digitare “y”. Questo permette di conservare lacalibrazione.


9. selezionare “CONFIGURE”, “ARM” e “SAVE”, alla richiesta di confermadigitate “y”. Questo salva la calibrazione nella RAM batterizzata.

Ora il robot è calibrato e pronto per essere utilizzato sia nello spazio operativosia in quello di giunto.

È possibile controllare la calibrazione visualizzando sullo schermo del control-lore la posizione dei giunti. Per farlo basta assicurarsi di essere nel menu prin-cipale e selezionare “DISPLAY”, “ARM” e “JOINT”; in questo modo compariràsullo schermo una striscia azzurra con i dati che ci interessano. I gradi riportatidovrebbero essere:

�0 � 0 � � 90 � 0 � 0 � 0 � .


B.5 Possibili cause di errore

Usare il COMAU Smart-3S richiede molta attenzione da parte dell’operatore.Alcune situazioni dovrebbero essere evitate.

Non riavviare mai il PC qunado la comunicazione tra robot e calcolatore è attiva,questa è una delle situazioni in cui si può avere la perdiata del sistema operativonel C3G 9000. Se il sistema è completamente perso problemi non ve ne sono,se però il software non è perso ma danneggiato, non vi è la richiesta da parte delmanipolatore di caricare dall’esterno il sistema operativo. Una soluzione è attendereche la RAM batterizzata si scarichi del tutto. Problemi analoghi si possono avere seil manipolatore viene spento in modalità 4, è quindi opportuno rimettere sempre ilrobot in modalità 0 dopo il suo utilizzo.

È necessario, inoltre, scaricare i moduli real time dal kerenl prima di eseguireun “logout” dall’interfaccia grafica di Linux, in caso contrario si ha il blocco del PCed è necessario premere il tasto reset presente sul calcolatore.

Bibliografia

[1] Marcelo Alonso e Edward J. Finn. Elementi di fisica per l’univeristà,volume 2. Masson S.p.A., seconda edizione, 1983.

[2] Jhon Canny. A computational approach to edge detection. IEEE Transactionson pattern analysis and machine intelligence, PAMI-8(6), Novembre 1986.

[3] Raffaella Carloni. Manipolazione robotica: startgie di presa ottima di oggettiplanari. Tesi di Laurea, Università di Bologna, DEIS, 2002.

[4] COMAU S.p.A. C3G 9000, 3.0 edizione, 1991.

[5] Mark Watson Kurt Wall e Marck Whitis. Programmare in Linux. APOGEO,2000.

[6] Paolo Mantegazza. Rtai programming guide. 2000.

[7] Matthias Kalle Dalheimer Matt Welsh e Lar Kaufman. Linux la guida.APOGEO, 2000.

[8] Havoc Pennington. GTK+/Gnome Sviluppo di applicazioni. APOGEO, 2000.

[9] Dietrich Pescholler. Applicazione di rtai linux per il controllo di un robot. Tesidi Laurea, Università di Bologna, DEIS, 2001.

[10] Alessandro Rubini e Jonathan Corbet. Linux device drivers. O’Reilly, secondaedizione, 2002.

[11] Luca Vittuari. Interfaccia per la scheda di protopizzazione rapida in ambientelinux. Tesi di Laurea, Università di Bologna, DEIS, 2001.

68 Bibliografia

Documents

Università degli Studi di Bologna - LAR-DEIS Home Page · 2002-07-30 · Università degli Studi di Bologna FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica ROBOTICA