1. No category

` DEGLI STUDI DI PARMA
UNIVERSITA
Facolt`a di Ingegneria
Corso di Laurea in Ingegneria Informatica
REALIZZAZIONE DI UN’ARCHITETTURA
DI CONTROLLO PER IL ROBOT PIONEER
BASATA SUL FRAMEWORK YARA
Relatore:
Chiar.mo Prof. STEFANO CASELLI
Correlatore:
Ing. FRANCESCO MONICA
Tesi di Laurea di:
GABRIELE CAMELLINI
ANNO ACCADEMICO 2005-2006
Alla mia famiglia,
per la fiducia e l’affetto.
Indice
Indice
i
1 Introduzione
1.1 Scopo della tesi . . . . . .
1.2 Stato dell’arte . . . . . . .
1.2.1 Shapira . . . . . .
1.2.2 Player/Stage . . .
1.3 Organizzazione dei capitoli
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
3
4
5
2 Il Pioneer
2.1 Il robot . . . . . . . . . . . . . . . . . . . .
2.1.1 Documentazione . . . . . . . . . . .
2.2 Caratteristiche tecniche . . . . . . . . . . . .
2.2.1 Struttura . . . . . . . . . . . . . . .
2.2.2 Dimensioni . . . . . . . . . . . . . .
2.2.3 Movimento . . . . . . . . . . . . . .
2.2.4 Sensorialit`a . . . . . . . . . . . . . .
2.2.5 La scheda di controllo . . . . . . . .
2.3 PSOS - Pioneer Server Operating System . .
2.4 Protocollo di comunicazione . . . . . . . . .
2.4.1 Livello fisico . . . . . . . . . . . . . .
2.4.2 Livello data link . . . . . . . . . . . .
2.4.3 Communication Packet Protocol . . .
2.4.4 Interazione client/server . . . . . . .
2.4.5 Client Commands . . . . . . . . . . .
2.4.6 Server Information Packets . . . . . .
2.4.7 Apertura e chiusura della connessione
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
7
8
8
9
9
10
11
12
14
14
15
15
17
17
19
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Aggiornamento del Pioneer
22
3.1 Motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Scelte progettuali . . . . . . . . . . . . . . . . . . . . . . . . . 23
i
INDICE
3.3
3.4
ii
Aggiornamento fisico del robot . . . . . . . . . . . . . . . . . . 23
Realizzazione del PC di bordo . . . . . . . . . . . . . . . . . . 24
4 Progettazione e sviluppo
4.1 YARA . . . . . . . . . . . . . . . . . .
4.2 Fasi di sviluppo . . . . . . . . . . . . .
4.3 Driver P2OS di Player . . . . . . . . .
4.4 Realizzazione delle funzionalit`a di base
4.5 Integrazione nel framework YARA. . .
4.5.1 Implementazione . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
28
29
30
31
33
35
5 Sperimentazione
37
5.1 Taratura dei sonar . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Realizzazione di un comportamento . . . . . . . . . . . . . . . 41
6 Conclusioni
A Procedure tecniche
A.1 Installazione del PC di bordo . . . . . . . . .
A.2 Installazione dello scanner laser Sick LMS 200
A.3 Ricarica delle batterie . . . . . . . . . . . . .
A.3.1 Batterie al piombo . . . . . . . . . . .
A.3.2 Batterie al NiMh . . . . . . . . . . . .
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
48
50
50
51
B Listato dell’applicazione Stay In The Middle
53
B.1 Behaviour per il robot . . . . . . . . . . . . . . . . . . . . . . 53
B.2 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
C Tabella comandi PSOS
57
Bibliografia
59
Ringraziamenti
60
Capitolo 1
Introduzione
Il Pioneer `e un versatile robot mobile, che appartiene alla flotta di robot
disponibili presso il laboratorio RIMLab[1], del Dipartimento di Ingegneria
Informatica dell’Universit`a di Parma.
Il Pioneer `e un robot di ridotte dimensioni, prodotto dall’ActivMedia[2],
dotato di due ruote motrici e di un sistema sensoriale costituito da 7 sonar
(pi`
u altre tipologie di sensori), utilizzato a scopo didattico dagli studenti
del corso di Robotica della Laurea Specialistica. L’utilizzo prettamente didattico non toglie la possibilit`a di utilizzarlo anche a scopo di ricerca, ma
vista la relativa rapidit`a nell’apprenderne il funzionamento `e il robot ideale
per sviluppare applicazioni di robotica mobile nel breve periodo di un corso
universitario. Solitamente, al termine del suddetto corso viene indetta una
”Competition” nella quale gli studenti mettono a confronto i propri programmi di controllo del robot, per compiere una prova nel miglior modo/tempo
possibile.
Fino a questo momento l’utilizzo del Pioneer e’ stato fortemente limitato
a causa della modalit`a di controllo remoto realizzato mediante una coppia di
radio-modem seriali, uno presente sul robot e l’altro collegato ad un PC fisso.
Questa caratteristica limitava il raggio di azione e soprattutto non permetteva
l’espansione delle capacit`a sensoriali mediante l’utilizzo di moderni sensori
quali telecamere digitali e scanner laser.
Dal lato software, il controllo del robot avviene tramite il framework
Player Stage[3], un potente strumento che si interpone tra il robot e l’applicazione di controllo realizzata dall’utente. Nel controllo del Pioneer si
sfruttano tuttavia soltanto pochissime delle funzionalit`a offerte dal framework che, pur non essendo un software computazionalmente pesante, risulta
fortemente sottoutilizzato.
1
CAPITOLO 1. INTRODUZIONE
1.1
2
Scopo della tesi
L’obbiettivo che questa tesi vuole perseguire consiste nello sviluppo di una
nuova architettura di controllo per il robot Pioneer basata sul framework
YARA[4], sviluppato dall’Ing. Francesco Monica presso l’Universit`
a di Parma, che permetta un controllo affidabile ed efficiente del robot.
Per superare i limiti funzionali, ai quali si `e accennato nella sezione precedente, si `e deciso di procedere ad un aggiornamento hardware del robot mediante l’installazione a bordo di un completo PC. Ci`o consente di rendere
il robot autonomo e permette l’utilizzo di una ampia gamma di sensori per
espandere le capacit`a sensoriali.
Successivamente si `e passati allo sviluppo software che, sostanzialmente,
deve portare alla creazione di un modulo da inserire nel framework YARA
per il controllo del Pioneer.
1.2
Stato dell’arte
Nel gergo comune, parlando di un robot, lo si associa quasi esclusivamente
alla struttura hardware e spesso lo si immagina con una forma antropomorfa.
Nella realt`a la parte pi`
u importante di un robot `e il software di controllo che
permette di renderlo autonomo determinandone il comportamento.
Il controllo del robot Pioneer pu`o avvenire in due modalit`a:
- standalone
- client/server
La prima modalit`a consiste nello sviluppo di un programma che viene poi
eseguito direttamente sul microcontrollore a bordo del robot. Siccome il microcontrollore ha capacit`a di elaborazione molto limitate, questa possibilit`a
di controllo non `e stata mai praticamente utilizzata.
Nella modalit`a client/server il robot viene gestito in remoto da un PC.
Sul microcontrollore a bordo del robot `e in esecuzione il server, costituito dal
PSOS, e sul PC il software client riceve i dati sensoriali e invia i comandi di
moto. PSOS (Pioneer Server Operating System) `e un sistema operativo creato dall’ActivMedia per gestire le funzionalit`a di una vasta famiglia di robot
mobili. Per il software client, nel corso della storia del Pioneer, sono state
utilizzate due differenti piattaforme per il controllo del robot con interfaccia
via radio-modem o mediante cavo seriale.
Esse sono:
- Shapira
CAPITOLO 1. INTRODUZIONE
3
- Player/Stage
1.2.1
Shapira
Inizialmente nel controllo del Pioneer veniva utilizzato Shapira, una libreria per lo sviluppo di software, lato client, per interfacciarsi con il PSOS
installato sul robot. La libreria `e stata sviluppata dalla ActivMedia come
software proprietario, quindi non aperta a modifiche e a studi approfonditi
sul funzionamento. Inizialmente era disponibile solo per DOS, poi ne `e stata
rilasciata una versione per Linux. Nella libreria `e disponibile una serie di
funzioni per realizzare la comunicazione client/server e controllare il robot
con comandi di alto e basso livello.
Il pacchetto di sviluppo Shapira, oltre alle funzioni per la programmazione
in linguaggio C del robot, contiene il Colbert Robot Programming Language
e il Behavior Compiler. Il primo `e un linguaggio stile C che permette di controllare direttamente il Robot in modo interattivo, il secondo `e un linguaggio
molto semplice per generare in modo automatico il codice C relativo.
La libreria Shapira `e costituita da due parti:
- la System Architecture
- il Robot Control Architecture
La prima, di pi`
u basso livello, `e costituita dalle funzioni per la comunicazione e il controllo del robot attraverso il PC host. La seconda permette
di gestire i comportamenti pi`
u complessi quali il riconoscimento di ostacoli e
la pianificazione del moto. Le due componenti della libreria vengono gestite
da task eseguiti con temporizzazioni diverse: tempi brevi per la prima, pi`
u
alti per la seconda.
Di seguito vengono elencati i principali difetti della libreria Shapira:
- offrendo delle funzioni per il linguaggio C non `e orientata alla programmazione ad oggetti;
- essendo sviluppata per essere eseguita su sistemi non multitasking, se
eseguita su questi, assorbe molte risorse inutilmente;
- non essendovi implementate delle politiche per il controllo dell’esecuzione dei task, non pu`o essere definita realtime.
CAPITOLO 1. INTRODUZIONE
1.2.2
4
Player/Stage
Player/Stage[3] `e un framework per la robotica mobile nato dalla collaborazione dello Stanford AI Lab, del Robotics Research Lab della University of
Southern California, con il Simon Fraser Autonomy Lab [5].
Il framework Player/Stage `e uno tra i pi`
u utilizzati a livello mondiale nel
controllo dei robot mobili e nella gestione della sensoristica ad essi collegata.
` stato sviluppato per piattaforme UNIX e permette il controllo di decine
E
di modelli di robot mobili e di varie tipologie di sensori (dalle telecamere
digitali, ai sonar, passando per gli scanner laser).
La principale caratteristica, che ne ha decretato il successo, risiede nell’utilizzo di socket TCP per gestire la comunicazione fra le varie parti del
sistema. Questo aspetto presenta indubbi vantaggi: l’utilizzo delle socket
`e molto semplice, esse permettono di separare la gestione dell’hardware del
robot dal programma di controllo, non dipendono dal linguaggio di programmazione utilizzato, introducono una modularit`a nello sviluppo del software
che facilita il costante aggiornamento senza intaccare la compatibilit`a.
Un altro motivo di successo di Player/Stage `e la disponibilit`a di un ambiente per la simulazione del robot: mantenendo inalterata l’applicazione
utente `e possibile interfacciarsi sia con il robot reale che con la sua simulazione.
Il framework `e composto da vari componenti.
Player. Player `e un robot device interface costituito da un server per il controllo dell’hardware reale o simulato di robot mobili tramite scambio
di messaggi TCP con i vari client. Il server offre al client una serie di
servizi remoti, che permettono il controllo dei movimenti del robot e
la lettura delle misure sensoriali. Player implementa un hardware abstraction layer (HAL) per piattaforme robotiche permettendo l’accesso
in modo standard ad una vasta gamma di robot, sollevando cos`ı lo
sviluppatore dalla conoscenza delle modalit`a di controllo di ogni modello. Si pu`o dire che Player si interpone tra sviluppatore e robot, come
il sistema operativo si interpone tra il programmatore e l’elaboratore
hardware.
` la libreria che fornisce un insieme di proxy locali
C++ Client Library. E
che semplificano l’accesso ai servizi remoti occupandosi anche dei formati per la comunicazione. Per controllare un robot il programmatore
ha a disposizione, per esempio, un proxy per il controllo del movimento, un’altro per la lettura dei sonar, un’altro ancora per la lettura dello
scanner laser e in modo analogo, altri proxy per i vari dispositivi hardware. Indipendentemente dalla tipologia di robot, ogni applicazione
CAPITOLO 1. INTRODUZIONE
5
client deve avere un proxy di tipo PlayerClient che instaura la connessione e si occupa della sincronizzazione del client con il server. Oltre
alla implementazione in C++ nel pacchetto ufficiale sono presenti quelle
per C e Java.
Stage. Si tratta del simulatore per ambiente bidimensionale ricostruito a
partire da una mappa fornita come immagine PNM o PNG. Stage
quindi simula l’interazione tra gli oggetti virtuali controllati da Player.
Inizialmente distribuito come applicazione autonoma da Player, nelle
nuove versioni si presenta come suo plugin.
1.3
Organizzazione dei capitoli
La tesi `e organizzata nel modo seguente.
Capitolo 2. Descrizione delle caratteristiche hardware del robot e del protocollo di comunicazione.
Capitolo 3. Aggiornamento fisico del robot.
Capitolo 4. Progettazione e sviluppo dell’architettura di controllo.
Capitolo 5. Sperimentazione e testing del software realizzato.
Capitolo 6. Conclusioni
Capitolo 2
Il Pioneer
Nel presente capitolo verr`a brevemente descritto il robot Pioneer 1 analizzandone le caratteristiche hardware e soprattutto andando ad esaminare
il protocollo di comunicazione che permette il controllo del robot mediante
l’interfaccia seriale.
Figura 2.1: Il robot Pioneer 1
2.1
Il robot
Il termine Pioneer identifica una famiglia di robot mobili, prodotti dalla
ActivMedia, utilizzati soprattutto a scopi didattici e di ricerca nelle universit`a
di tutto il mondo. La famiglia di robot `e composta da tre modelli:
Pioneer 1,AT prodotto a met`a degli anni 90; `e il capostipite.
6
CAPITOLO 2. IL PIONEER
7
Pioneer 2 arrivato sul mercato nel 1999; `e una evoluzione del modello precedente, del quale sono state riviste la struttura portante, l’apparato locomotore e soprattutto sono state ampliate le capacit`a sensoriali aumentando il numero di sonar e introducendo una ampia base di appoggio
superiore, sulla quale possono facilmente essere dislocati vari tipi di
sensori, come per esempio scanner laser, GPS, ecc.. La caratteristica
pi`
u interessante `e la possibilit`a di integrare all’interno del robot un PC
compatibile.
Pioneer 3 ulteriore evoluzione del Pioneer 2 nel quale `e stato sostituito il
microcontrollore di bordo, senza introdurre molte modifiche strutturali.
Inoltre `e stato aggiornato il tool software a corredo
Per ogni modello sono state realizzate due versioni: quella DX, caratterizzata da due ruote motrici e un ruotino posteriore pivottante di sostegno,
adatta ad operare in ambienti interni su superfici regolari, e la versione AT
caratterizzata da 4 potenti ruote motrici che permettono di operare anche
all’aperto su terreni impervi.
Il robot disponibile presso il laboratorio RIMLab `e un Pioneer 1 acquistato nella seconda met`a degli anni 90 ed `e stato utilizzato sia a scopi didattici
sia per sperimentazione a scopo di ricerca.
Nel corso degli anni il Pioneer 1 `e stato oggetto di varie tesi e tesine:
- Simone Monica (a.a. 97/98): Integrazione sul Pioneer di un sistema di
visione a basso costo costituito da un sensore CCD lineare 64x1 pixel
B/N.
- Alessandro Scrivani (a.a. 97/98): Integrazione sul Pioneer di un sistema olfattivo per l’individuazione di fughe di gas.
- Dario Faccini (a.a. 99/00): Ricerca del massimo comportamento reattivo ottenibile con il robot mobile Pioneer 1.
- Matteo Mantovani, Emanuele Tiso, Antonio Valdessalici (a.a. 01/02):
Realizzazione di un sistema di Visione con Telecamera 32x32 della
F.B.C. per Robot Mobile Pioneer 1.
2.1.1
Documentazione
Sul sito della ActivMedia[2] `e possibile reperire la documentazione ufficiale,
cercando fra i vari manuali nella sezione Support: http://robots.mobilerobots.
com/. Per poter scaricare i manuali occorre autenticarsi mediante utente
e password che sono stati forniti al momento dell’acquisto del robot. Per
comodit`a qui di seguito ho riportato i dati di accesso:
CAPITOLO 2. IL PIONEER
8
userid: parmasci
password: Sp*3r/m9W
I documenti che mi sono stati pi`
u utili nella stesura della tesi sono i
seguenti:
- Pioneer 1/AT Operations Manual, Ed. 2[6]: il manuale operativo
del robot che riporta tutte le caratteristiche e spiega le modalit`a di
funzionamento e controllo.
- PSOS Notes: una serie di tabelle nelle quali vengono illustrate la
struttura dei pacchetti scambiati tra client e PSOS e i comandi disponibili per controllare il robot.
- Ricerca del massimo comportamento reattivo ottenibile con il
robot mobile Pioneer 1.[7]: una tesina di Dario Faccini nella quale
viene analizzata molto dettagliatamente la struttura del Pioneer 1.
2.2
2.2.1
Caratteristiche tecniche
Struttura
Il Pioneer 1 `e un robot mobile di ridotte dimensioni, caratterizzato da una
` dotato di due ruote motrici anteriori che permettono
forma quasi circolare. E
il moto roto-transazionale del robot e un ruotino posteriore di appoggio che
ruota liberamente in funzione dei movimenti impressi dalla ruote motrici.
Il Pioneer 1 `e suddivisibile in quattro sezioni principali: la console, il
deck, il body e il nose. Le sezioni sono facilmente individuabili nella figura
2.2.
` posta sul deck in posizione frontale e ospita,
Console: `e la testa del robot. E
al suo interno, la scheda di controllo con il microcontrollore e il radiomodem. Sulla parte superiore sono posizionati tutti i controlli e gli
indicatori necessari per l’utilizzo del robot. Nella parte frontale sono
ospitati i 7 sensori sonar Polaroid.
` una superficie di appoggio piana che consente di
Deck: `e il dorso del robot. E
ospitare periferiche aggiuntive per il robot, come ad esempio la bussola
magnetica.
Body: `e la parte pi`
u grande del robot che alloggia la batteria e i motori.
Presenta sufficiente spazio per poter inserire batterie aggiuntive.
CAPITOLO 2. IL PIONEER
9
Figura 2.2: Struttura del Pioneer 1
Nose: `e la parte inferiore frontale alla quale possono essere collegati vari tipi
di attuatori e sensori, come per esempio, pinze motorizzate o sensori
ottici.
2.2.2
Dimensioni
Il Pioneer 1 si pu`o inserire nella famiglia di robot mobili medio-piccoli. Le
sue dimensioni sono 45cm di lunghezza, 36cm di larghezza e 22cm di altez` realizzato in alluminio laminato di vari spessori ed `e completamente
za. E
assemblato utilizzando bulloni a brugola, senza saldature, cosa che rende
molto semplice la manutenzione. Nella figura 2.3 vengono riportati i dettagli
dimensionali del Pioneer 1.
Come si pu`o osservare, la forma del robot `e approssimativamente circolare, e questo pu`o aiutare molto nella realizzazione degli algoritmi di navigazione. In particolare, il robot pu`o ruotare su se stesso in un cerchio di
raggio 30cm.
2.2.3
Movimento
Il robot viene mosso da due motori elettrici in corrente continua collegati,
mediante riduttori ad ingranaggi, alle due ruote motrici poste sui fianchi
sinistro e destro.
Le caratteristiche dei motori e dell’apparato di movimento sono le seguenti:
Raggio ruote: 12.5cm
CAPITOLO 2. IL PIONEER
10
Figura 2.3: Dimensioni del Pioneer 1
Rapporto di riduzione: 19.7:1
Forza di spinta: 2Kg
Velocit`
a massima transazionale: 0.6m/s
Velocit`
a massima rotazionale: 150◦ /s
Su ogni motore `e montato un encoder di posizione per avere un feed-back
che consente di dosare la potenza fornita ai motori in base alla sforzo richiesto
per il movimento ad una determinata velocit`a.
L’alimentazione viene fornita da una batteria al piombo da 12V con una
capacit`a di 7Ah che garantisce al robot circa 2 ore di autonomia.
2.2.4
Sensorialit`
a
A bordo del Pioneer 1 sono installati i seguenti sensori:
2 encoder di posizione: sono montati su ognuno dei due motori e permettono al PSOS, in esecuzione sul microcontrollore di bordo, di controllare
la velocit`a dei motori, adattando la potenza fornita in funzione delle
condizioni di moto. Ciascun encoder ha una risoluzione di 100 impulsi
per giro, e utilizzati in coppia consentono di tenere traccia della posizione del robot mediante il calcolo dell’odometria. Questa funzione
CAPITOLO 2. IL PIONEER
11
risulterebbe particolarmente utile, ma dai test `e emerso che le misure fornite (effettuate mediante calcolo integrale dal PSOS ) sono poco
precise e non hanno utilit`a concreta.
1 bussola magnetica: `e montata sul deck del robot ed ha una risoluzione
di 2◦ . Sarebbe uno strumento molto utile ma, sfortunatamente, nell’utilizzo in ambienti chiusi risulta fortemente influenzata dai campi
magnetici generati dai dispositivi elettrici.
7 sonar: si tratta di 7 sensori sonar Polaroid gestiti in multiplexing, montati 2 sui fianchi del robot e i restanti 5 sul pannello frontale orientati
con intervalli di 15◦ uno dall’altro. Forniscono una misura abbastanza
precisa della distanza di ostacoli compresi fra 20cm e 5m in condizioni
statiche, ma devono essere utilizzati con appositi accorgimenti software
quando il robot `e in movimento, perch`e le misure fornite sono molto
rumorose. Il firing rate dei sonar `e di 25Hz e via software `e possibile
controllare la sequenza di fire dei 7 sonar e quali attivare.
2.2.5
La scheda di controllo
Come accennato nelle sezioni precedenti, il controllo del Pioneer `e affidato al PSOS esegutio sul microcontrollore di bordo. Questo `e un Motorola
MC68HC11F1 che funziona alla frequenza di bus di 4MHz generata da un
quarzo esterno a 16MHz. Il microcontrollore `e alloggiato su una scheda montata nella console del robot. Dalla scheda partono tutte le connessioni per
controllare i dispositivi di bordo quali i sonar, i motori, la bussola e le porte
di collegamento con l’esterno.
In particolare sulla scheda sono presenti le seguenti porte di espansione:
- 1 connettore per collegare il radio-modem seriale;
- 1 connettore DB9 femmina per il collegamento ad un PC client mediante un cavo di prolunga; il protocollo utilizzato `e un RS-232 standard
con velocit`a di 9600 o 19200 bps, 8 bit di dati, uno stop bit, no parit`a
e nessun controllo di handshaking;
- 1 alimentazione ausiliaria a 12V con interruttore per poter alimentare
qualche dispositivo periferico;
- 4 linee a 5V che possono essere utilizzate per realizzare piccoli circuiti
di controllo da collegare alle porte di I/O;
- 8 ingressi digitali;
CAPITOLO 2. IL PIONEER
12
Figura 2.4: La scheda di controllo
- 8 uscite digitali;
- 1 ingresso analogico che fa capo ad un A/D converter (convertitore
analogico/digitale) con risoluzione di 8 bit;
- 1 timer digitale in ingresso;
- 1 timer digitale in uscita, utile per controllare eventuali servomotori
con i quali azionare piccoli dispositivi meccanici installati sul robot.
Sulla scheda sono anche presenti tutti i dispositivi necessari per interagire
con il robot, come i pulsanti, gli interruttori di alimentazione, il display LCD,
il connettore DB9 per la porta RS232, il connettore di ricarica della batteria,
ecc.
Tutti questi elementi sono resi disponibili all’esterno mediante una frontalino di alluminio, illustrato nella figura 2.5, che costituisce la parte superiore
della console.
2.3
PSOS - Pioneer Server Operating System
Nella modalit`a di controllo client/server, il software server a bordo del Pioneer 1 si occupa di gestire tutti i dettagli di basso livello del robot, come la
gestione del moto, il firing dei sonar e la raccolta degli eco ricevuti e le restanti
funzioni, compresa la comunicazione con l’applicazione client. Sul Pioneer 1
come software server `e installato il Pioneer Server Operating System o, pi`
u
CAPITOLO 2. IL PIONEER
13
Figura 2.5: Pannello di controllo
brevemente, PSOS. Il PSOS `e stato sviluppato dall’ActivMedia per gestire
tutti i modelli di robot mobili della famiglia Pioneer da essa prodotti.
Sul Pioneer 1 `e installata la versione 4.9, che `e l’ultima versione rilasciata
per questo modello di robot.
Nella figura 2.6 `e riportato lo schema a blocchi del PSOS.
All’interno dei due riquadri della figura 2.6sono elencate le varie attivit`a
svolte per la gestione del robot. La gestione dei motori con il controllo sulla
potenza, il fire dei sonar e la lettura dell’eco di ritorno, il controllo degli I/O,
sono rappresentati nel riquadro di sinistra e vengono effettuati grazie ad un
veloce ciclo di interrupt eseguito alla frequenza di qualche KHz. Ad un livello
pi`
u alto, nel riquadro di destra, il server implementa le funzioni di servizio
quali il calcolo delle velocit`a, il calcolo integrale della posizione, la gestione
della sequenza di fire dei sonar e, molto importante, la comunicazione con
l’applicazione client che avviene a una frequenza di 10Hz. Questo valore non
`e molto elevato ma, considerando le basse velocit`a di movimento del robot,
`e sufficiente per un controllo efficace del suo comportamento.
Il PSOS `e memorizzato all’interno di una memoria FLASH da 32Kb e in
aggiunta viene utilizzata una memoria EEPROM nella quale, mediante un
apposito software, si possono impostare i vari parametri che caratterizzano il
robot e il suo comportamento: Serial Number per identificare univocamente
il robot, Modello, Baud Rate della linea seriale, ecc.. Per una loro descrizione
CAPITOLO 2. IL PIONEER
14
Figura 2.6: Architettura del PSOS
dettagliata si faccia riferimento al manuale del robot[6].
2.4
Protocollo di comunicazione
Un protocollo `e un insieme di regole che definisce il formato dei messaggi
e che consente a due entit`a di comunicare e di comprendere il significato
dell’informazioni scambiate.
Nello sviluppo software del progetto gran parte del lavoro ha riguardato l’implementazione su un PC client del protocollo di comunicazione con
il robot. Quindi, per la sua importanza, al Protocollo di comunicazione
client/server `e dedicata la presente sezione.
Il Pioneer, o meglio il server PSOS, comunica con l’applicazione client
attraverso un protocollo a pacchetti bidirezionale. In questa sezione vengono
analizzate tutte le caratteristiche di questo protocollo.
Volendo far riferimento al modello OSI si possono chiaramente individuare il livello fisico e il livello data link, mentre i livelli superiori sono inglobati
in un unico protocollo detto Communication Packet Protocol.
2.4.1
Livello fisico
La comunicazione pu`o avvenire via cavo o via etere.
Via cavo vengono seguite le specifiche per la comunicazione RS-232. In
particolare `e necessario utilizzare un collegamento a 3 poli (1 per la massa
GND, 1 per la trasmissione TX, 1 per la ricezione RX); i livelli di tensione
` consigliato l’utilizzo di un
sono -12V per la codifica dell’1 e +12V per lo 0. E
cavo con conduttori intrecciati e si possono raggiungere i 30m di lunghezza.
CAPITOLO 2. IL PIONEER
15
Via etere vengono utilizzati una coppia di radio-modem operanti a 2.4GHz
che possono essere collegati uno alla porta seriale RS-232 di un PC e l’altro
al connettore apposito presente sulla scheda di controllo a bordo del robot.
2.4.2
Livello data link
Viene utilizzato un protocollo RS-232 compatibile con le seguenti caratteristiche:
- Baud rate: 9600 o 19200 bps
- Dimensione dato: 8 bit
- Bit di stop: 1
- Controllo di parit`a: nessuno
- Handshaking hardware: nessuno
Questo protocollo `e molto utilizzato nella comunicazione tra PC e dispositivi gestiti a microcontrollore, perch`e non richiede hardware aggiuntivo
ed `e semplice da gestire. Per contro, per`o, non presenta una elevata velocit`a di trasmissione e non viene effettuato nessun controllo sull’integrit`a dei
dati ricevuti. L’individuazione di errori nei dati trasmessi deve quindi essere
effettuata al livello superiore della comunicazione.
2.4.3
Communication Packet Protocol
La comunicazione tra client e server avviene attraverso lo scambio bidirezionale di pacchetti dati costituiti da: un header, un contatore, un campo
dati e un valore di checksum. Nella tabella 2.1viene riportata la struttura
dettagliata del pacchetto.
L’header `e formato da due caratteri sempre uguali, scelti in modo tale
che la loro successione sia poco probabile ritrovarla all’interno del resto del
pacchetto. Questo permette di riconoscere l’inizio di un nuovo pacchetto
nel caso in cui la comunicazione subisca delle interruzioni oppure nel momento iniziale quando il client deve sincronizzarsi con il server per ricevere
correttamente i pacchetti.
La dimensione dei pacchetti non `e fissa ma varia in funzione del tipo e
dalla quantit`a di dati trasportati nel pacchetto. Per questo motivo si rende
necessario l’utilizzo di un contatore per poter ricevere correttamente l’intero
pacchetto. Il contatore ha dimensione un byte e il suo valore rappresenta
la lunghezza del campo dati alla quale viene sommato il valore 2 che `e la
CAPITOLO 2. IL PIONEER
Componente
Header
Contatore
N. byte
2
1
Dati
N
Checksum
2
16
Valore
0xFA, 0xFB
N + 2
Descrizione
Intestazione
Numero di byte di dati pi`
u
i 2 byte di controllo
Comandi dal cliente o
informazioni dal server
Da calcolare
Valore per il controllo della
integrit`a del pacchetto
Tabella 2.1: Struttura di un pacchetto dati del PSOS.
lunghezza del campo checksum. La dimensione del pacchetto deve essere
minore di 200 caratteri esclusi l’header e il contatore.
Il contenuto del campo dati varia a seconda che si tratti di un pacchetto
inviato dal client al server o viceversa. Nel primo caso si parla di Client
Commands e nel secondo si parla di Server Information Packets. L’analisi
dettagliata viene descritta nelle prossime sezioni. I tipi di dati che possono
essere utilizzati sono illustrati nella tabella 2.2.
Tipo
Integer
Word
String
String
N. byte
Ordine byte
2
b0 low byte; b1 high byte
4
b0 low byte; b3 high byte
fino a 200,
b0 lunghezza della stringa
lunghezza prefissata b1 primo carattere della stringa
illimitata, terminata b0 primo carattere della stringa
con il carattere nullo
0 (null) ultimo byte
Tabella 2.2: Tipi di dati.
Per i valori numerici non viene specificata una convenzione per i segni,
ma spetta al ricevente interpretare correttamente i valori ricevuti sulla base
del contenuto dei dati.
Il valore di checksum permette di verificare l’integrit`a del pacchetto ricevuto. Se il valore del checksum trasmesso `e diverso da quello ricalcolato dal
ricevitore, significa che il pacchetto contiene degli errori e in tal caso viene
scartato. I rigidi tempi di comunicazione scelti nel protocollo, e la natura realtime dell’interazione client/server, non permette la ritrasmissione dei
pacchetti errati, che vengono scartati utilizzando i successivi.
Per il calcolo del checksum bisogna sommare successivamente, a coppie di
due, tutti i byte del pacchetto scartando il segno e il resto; se il numero di byte
CAPITOLO 2. IL PIONEER
17
`e dispari, l’ultimo byte viene messo a XOR con la parte meno significativa del
checksum gi`a calcolata. Per meglio comprendere il procedimento si esamini
il listato di codice 2.1.
1
2
3
4
5
int CalcChkSum(unsigned char packet[])
{
unsigned char *buffer = &packet[3];
int c = 0;
int n = size - 5;
6
while (n > 1)
{
c += (*(buffer)<<8) | *(buffer+1);
c = c & 0xffff;
n -= 2;
buffer += 2;
}
if (n > 0)
{
c = c^ (int)*(buffer++);
}
return c;
7
8
9
10
11
12
13
14
15
16
17
18
19
}
Listato 2.1: Calcolo del checksum del pacchetto.
2.4.4
Interazione client/server
Un concetto molto importante, nell’architettura di controllo del Pioneer, `e
la modalit`a di scambio di informazioni tra il client e il server: il client `e
un’entit`a che invia comandi, ad esempio per impostare una velocit`a, mentre
il server `e un’entit`a che invia informazioni sullo stato del robot e sulle misure
sensoriali. Per ogni pacchetto scambiato non `e previsto un messaggio di
acknowledgment e l’unica possibilit`a che il client ha di verificare l’esecuzione
dei comandi inviati sta nel controllare, tramite le informazioni pervenute dal
server, se i valori che avrebbero dovuto subire una modifica sono cambiati o
meno.
2.4.5
Client Commands
Il client, per interagire con il robot, invia dei pacchetti contenenti i comandi
che verranno interpretati ed eseguiti dal server. I comandi possono essere
CAPITOLO 2. IL PIONEER
18
inviati al massimo uno ogni 100ms, cio`e con frequenza 10Hz, ed `e necessario
che venga inviato un comando almeno ogni 2s. Se questo limite viene superato, il server interrompe l’alimentazione ai motori di bordo, fermando il
robot. Grazie a ci`o si implementa un meccanismo di sicurezza che blocca il
robot nel caso il client si sia bloccato, oppure sia fuori portata, impedendo
di causare danni a persone o cose nelle vicinanze del robot, o al robot stesso.
La struttura di un pacchetto di comando `e illustrata nella tabella 2.3.
Componente
Header
Contatore
N. byte
2
1
N. Comando
Tipo arg.
(opzionale)
1
1
Argomento
(opzionale)
Checksum
N - 4
2
Valore
0xFA, 0xFB
N + 2
Descrizione
Intestazione
Numero di byte di dati pi`
u
i 2 byte di controllo
0 - 255
Numero comando
Tipo di dato dell’argomento:
0x3B
intero positivo
0x1B
intero negativo o valore assoluto
0x2B
stringa terminata con null
dato
Argomento del comando,
intero o stringa
Da calcolare
Controllo dell’integrit`a
Tabella 2.3: Pacchetto di comando.
Oltre a quelli standard, il pacchetto di comando contiene i seguenti campi:
N. Comando: ogni comando per il PSOS `e identificato da un numero.
L’elenco completo dei comandi `e illustrato nella tabella presente in
appendice C.
Tipo arg.: rappresenta il tipo dell’argomento del comando. Permette di
valutare correttamente il contenuto dei byte successivi, distinguendo
tra numeri positivi, negativi e stringhe. Particolare attenzione va posta
per i numeri negativi che vengono trasmessi in valore assoluto e vanno
successivamente moltiplicati per -1.
Argomento: `e il valore associato al comando. Le stringhe vanno trasmesse
terminate con il carattere ’0’ (null) e per i numeri bisogna mettere
prima il byte meno significativo.
Andare ad analizzare singolarmente i vari comandi disponibili, sarebbe
superfluo ai fini di questa tesi. Nel seguito vengono presi in considerazione
CAPITOLO 2. IL PIONEER
19
i principali comandi che sono poi stati praticamente utilizzati nella stesura
del software.
SYNC0, SYNC1, SYNC2 utilizzati per la sincronizzazione e per l’apertura della connessione tra client e robot.
OPEN apre e attiva il controller dei motori, fornendo alimentazione agli
stessi e attivando anche il modulo che si occupa di gestire i sonar.
CLOSE chiude la connessione, toglie alimentazione ai motori e spegne i
sonar.
PULSE comando neutro: serve soltanto per indicare al server che il client
`e ancora collegato e, quindi, non bisogna interrompere i movimenti in
atto.
VEL permette di impostare la velocit`a transazionale del robot. La velocit`a
deve essere passata come argomento e ha come unit`a i mm/s.
RVEL permette di impostare la velocit`a rotazionale del robot. La velocit`a
deve essere passata come argomento e ha come unit`a i deg/s.
2.4.6
Server Information Packets
Il server invia automaticamente ogni 100ms, ovvero a 10Hz, un Server Information Packet, che contiene lo stato del robot e le misure restituite dai vari
sensori. Nella figura 2.7 `e illustrato il contenuto del pacchetto.
Il numero di campi `e variabile perch`e nel pacchetto non sono contenute
le letture di tutti i sonar, ma solamente quelle dei valori che sono stati aggiornati. Tra le varie informazioni disponibili, le pi`
u significative al fine del
progetto sono quelle legate ai sonar (Sonar readings). Il valore restituito
da queste informazioni deve essere moltiplicato per un’opportuno valore di
conversione, valutato sperimentalmente, per convertirle in metri (vedere la
sezione 5.1).
2.4.7
Apertura e chiusura della connessione
Prima di poter inviare i comandi, il client deve instaurare la connessione con
il server. Infatti, quando il Pioneer viene accesso, entra in uno stato di wait
ed `e necessario eseguire la seguente procedura di sincronizzazione per poter
far entrare il robot in stato di ready.
Il client deve inviare in sequenza i tre comandi SYNC0, SYNC1, SYNC2
e deve controllare che per ciascuno di essi, il server risponda con lo stesso
CAPITOLO 2. IL PIONEER
20
comando. Al terzo pacchetto restituito dal server con il comando SYNC2
vengono aggiunte in coda tre stringhe che descrivono il nome, la classe e
la sub-classe del robot contattato. Queste informazioni sono molto utili nel
caso si abbia a che fare con una flotta di robot ed occorra identificarli univocamente. Successivamente il client invia il comando di OPEN e, come accennato precedentemente, il robot fornisce alimentazione ai motori e attiva i
sonar.
Per chiudere la connessione con il robot, `e sufficiente che il client invii il
comando di CLOSE.
CAPITOLO 2. IL PIONEER
Figura 2.7: PSOS Server Information Packets.
21
Capitolo 3
Aggiornamento del Pioneer
In questo capitolo verranno analizzati gli aggiornamenti hardware che hanno
interessato il Pioneer per permettere l’installazione di un PC di bordo e per
consentire l’utilizzo di nuove tipologie di sensori.
3.1
Motivazioni
Il Pioneer 1 `e un robot progettato e realizzato a met`a degli anni 90. Da allora
la robotica si `e molto evoluta. Dal lato software le richieste di risorse computazionali sono cresciute per permettere l’esecuzione di nuovi e sofisticati algoritmi di controllo, di pianificazione, di elaborazione. Contemporaneamente
`e aumentata la disponibilit`a di sensori sempre pi`
u evoluti.
Il principale limite del Pioneer sta nel controllo che viene realizzato in
remoto da un PC fisso collegato mediante una coppia di radio-modem seriali.
Questo limita fortemente le possibilit`a di utilizzo sia per quanto riguarda il
raggio di azione che per l’impossibilit`a di installare nuove periferiche per
ampliare le capacit`a sensoriali.
Per superare questi limiti occorre soddisfare i seguenti requisiti.
- Dotare il robot di un elaboratore on-board che permetta l’esecuzione dei
programmi di controllo senza la necessit`a di un collegamento remoto.
- Ampliare le capacit`a sensoriali, fornendo il supporto a periferiche quali:
scanner laser, telecamere digitali fireware, webcam USB, ricevitori GPS,
ecc.
- In particolare, bisogna consentire l’installazione dello scanner laser Sick
LMS 200 a bordo del robot. Viste le notevoli dimensioni del dispositivo
occorre prevedere un adeguato supporto per il fissaggio.
22
CAPITOLO 3. AGGIORNAMENTO DEL PIONEER
23
- Fornire un collegamento remoto per consentire di monitorare il robot
mediante la rete wireless WiFi disponibile presso il Dipartimento in cui
sono condotte le sperimentazioni con il Pioneer.
3.2
Scelte progettuali
Per l’aggiornamento, pertanto, si `e scelto di installare a bordo un PC dotato
di adeguati dispositivi di interfacciamento per il collegamento al robot e alle
altre, eventuali, periferiche sensoriali.
Il PC deve avere:
- capacit`a di elaborazione sufficiente per l’esecuzione delle moderne applicazioni robotiche;
- 2 porte seriali: una per il controllo del Pioneer e l’altra per lo scanner
laser Sick LMS 200;
- 1 collegamento di rete wireless WiFi ;
- 1 o pi`
u porte firewire per il collegamento di telecamere digitali;
- 2 o pi`
u porte USB per il collegamento di webcam e altri tipi di periferiche;
- l’alimentazione ricavata dai 12V disponibili a bordo del robot.
Inoltre per l’alimentazione del PC `e necessario potenziare la capacit`a della
batteria di bordo. Bisogna poi realizzare un supporto meccanico per l’installazione dello scanner laser Sick LMS 200 e provvedere alla sua alimentazione
a 24V.
3.3
Aggiornamento fisico del robot
Come prima operazione `e stata fatta una pulizia del robot andando a rimuovere una serie di unit`a e sensori che ormai non venivano pi`
u utilizzati da anni.
In particolare sono stati rimossi il sensore olfattivo per i gas e il sensore ottico
a matrice 32x32 pixel con annessa unit`a di controllo.
Successivamente `e stato aperto il corpo del robot ed `e stata installata,
fissandola opportunamente, una batteria al piombo da 12V e 7Ah oltre a
quella gi`a presente. In seguito sono stati realizzati i cablaggi per collegare le
due batterie in parallelo e per portare all’esterno i connettori necessari alla
CAPITOLO 3. AGGIORNAMENTO DEL PIONEER
24
ricarica e all’alimentazione del PC.
Lo scanner laser Sick LMS 200 `e stato installato realizzando un apposito
supporto in alluminio collocato sulla console del Pioneer. Per fissare il laser
al supporto sono state utilizzate due maniglie a ripresa, che permettono una
facile rimozione del dispositivo al fine di poterlo utilizzare separatamente o
su altri robot. Per la procedura dettagliata di installazione del laser a bordo
del robot fare riferimento alla sezione A.2.
Figura 3.1: Il laser Sick LMS 200 installato sul robot.
L’alimentazione a 24V necessaria per il laser viene fornita da due pacchi batterie da 12V collegati in serie e composti ciascuno da 10 batterie
ricaricabili al NiMh che consentono il contenimento di peso e di ingombri.
Per la ricarica dei pacchi batterie e delle batterie di bordo del robot, fare
riferimento alle procedure descritte nella sezione A.3.
3.4
Realizzazione del PC di bordo
Per installare un PC a bordo del robot erano possibili due alternative: utilizzare un notebook oppure realizzare un PC dedicato assemblando i componenti
necessari reperibili sul mercato.
CAPITOLO 3. AGGIORNAMENTO DEL PIONEER
25
Dopo un’attenta analisi l’utilizzo di un notebook `e stato scartato per una
serie di motivi quali: il costo elevato, la difficolt`a di trovarne uno con dimensioni veramente compatte, l’adeguatezza delle porte di interfacciamento
offerte, la necessit`a di un’alimentatore aggiuntivo per la ricarica oltre a quello
gi`a utilizzato per il robot.
La scelta `e ricaduta sull’utilizzo di un PC dedicato anche se la sua realizzazione ha richiesto una notevole quantit`a di lavoro per ottenere un elaboratore compatto, adatto alle specifiche richieste. Per contenere le dimensioni `e
stata adottata una scheda madre in formato MiniITX prodotta dalla VIA.
Il modello scelto `e il VIA Epia SP13000 LVDS che offre un processore VIA
C3 1.3 GHz ed un elevato numero di porte di interfacciamento. Per il collegamento alla rete wireless `e stato utilizzato un adattatore da installare su
porta USB 2.
Figura 3.2: Main board e hard disk del PC di bordo.
Un PC da installare su un robot mobile deve essere molto robusto per resistere alle sollecitazioni meccaniche che si incontrano durante l’utilizzo. Per
ospitare tutti i componenti (scheda madre, hard disk, alimentatore, adattatore WiFi) `e stato realizzato un compatto case in alluminio. Per costruirlo
si `e partiti da un box in alluminio per uso automobilistico e, successivamente, mediante lavorazioni al trapano e alla fresa, sono state realizzate le
aperture per i connettori dei vari componenti, i supporti per fissarli e sono
state riportate all’esterno le spie LED e i pulsanti necessari all’utilizzo del
computer.
Per la procedura dettagliata di installazione del PC a bordo del robot
fare riferimento alla sezione A.1.
CAPITOLO 3. AGGIORNAMENTO DEL PIONEER
Figura 3.3: Il PC di bordo completato.
Figura 3.4: Il nuovo Pioneer al termine dell’aggiornamento.
26
Capitolo 4
Progettazione e sviluppo
Come accennato nell’introduzione, lo scopo principale di questa tesi consiste
nello sviluppo di una architettura di controllo per il robot Pioneer che permetta di gestirne il comportamento attraverso la lettura dei dati sensoriali e
l’invio di comandi di moto.
Lo sviluppo di un’architettura di controllo software, partendo da zero,
`e un’attivit`a assai complessa che richiede un lungo lavoro di progettazione
e una conoscenza approfondita del sistema operativo sul quale il software
stesso viene eseguito. Occorre inoltre considerare le complicazioni che si introducono se si vuole realizzare un’architettura con caratteristiche real-time.
Per questi e altri motivi, lo sviluppo del software per applicazione robotiche,
(ma anche in altri ambiti) di solito avviene a vari livelli di astrazione. Per
realizzare un’architettura di controllo si sceglie un framework gi`a esistente
sul quale si costruiscono i vari componenti necessari per farlo operare sulla piattaforma desiderata. Un framework `e definito come una struttura di
supporto a partire da cui `e possibile organizzare e realizzare un’applicazione
software. Un framework pu`o includere il programma di gestione, le librerie
di codice, un linguaggio di scripting e altro materiale in grado di aiutare
gli sviluppatori ad unire tutti i componenti per ottenere il software finale.
Nell’ambito della robotica un framework, spesso, mette a disposizione una
serie di funzioni e moduli che sollevano il programmatore dalla necessit`a di
occuparsi dei problemi legati alla schedulazione delle attivit`a e alle modalit`a
di comunicazione tra i vari componenti.
Nello sviluppo dell’architettura per il Pioneer `e stato scelto di appoggiarsi
sul framework YARA [4].
27
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
4.1
28
YARA
YARA[4] `e l’acronimo di Yet Another Robotics Architecture ed `e un framework per la robotica mobile sviluppato presso il Laboratorio di Robotica del
Dipartimento di Ingegneria Informatica dell’Universit`
a di Parma. La caratteristica che lo contraddistingue rispetto ad altre architetture `e l’introduzione
di scheduling real-time avanzato per garantire il rispetto di vincoli temporali.
Sensor Module
Behaviour Module
Activity: sense,T1
Activity: react,T2
Sender: sensor
Receiver: sensor
Actuator Module
Activity: act,T3
Requester: move
Information
Performer: move
Command
Figura 4.1: Schema di un’applicazione YARA.
La struttura di un’applicazione YARA `e schematizzata in figura 4.1,
dove `e rappresentato un esempio di sistema di controllo. Nello schema sono
illustrati i componenti fondamentali descritti di seguito.
Moduli. Il modulo `e il componente fondamentale di YARA e rappresenta
una attivit`a autonoma che si occupa, per esempio, di implementare un
comportamento oppure di interfacciarsi con l’hardware del robot. Un
modulo viene implementato con la classe astratta C++ Module. Per
permettere lo scheduling real-time, il modulo possiede una serie di task
che lo scheduler del framework si incarica di porre in esecuzione sfruttando un set di thread prelevate da una coda comune a tutti i moduli.
Le attivit`a di scheduling sono completamente invisibili al programmatore essendo implementate mediante l’utilizzo di algoritmi e strutture
dati privati.
Attivit`
a. Le attivit`a sono implementate dalla classe template Activity e
rappresentano i task associati a ciascun modulo. La esecuzione di una
attivit`a pu`o essere periodica o aperiodica nel caso venga attivata da un
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
29
evento esterno al modulo. All’atto della dichiarazione di una attivit`a
occorre specificare un parametro temporale, che nel primo caso rappresenta il periodo di attivazione mentre nel secondo `e il tempo minimo
che deve intercorrere tra due rilasci consecutivi. Tale parametro ha
anche il significato di deadline.
Comunicazione. Le attivit`a all’interno dello stesso modulo condividono
dati ed algoritmi e attraverso questi possono agevolmente scambiarsi le
informazioni. Per la comunicazione tra moduli sono disponibili alcuni
pattern. Il primo di questi `e Information che rende possibili l’invio e la
ricezione di dati attraverso due oggetti data member, Sender e Receiver.
Un altro pattern `e Command, che `e dedicato all’invio di comandi da
un Requester ad un Performer su un altro modulo.
Scheduling real-time. L’esecuzione del codice di una Activity `e gestito
da TODS (Timed Object for Distributed Systems) [8], un framework
ad oggetti per la schedulazione real-time realizzato anch’esso presso il Dipartimento di Ingegneria Informatica. TODS schedula i task
del sistema secondo una politica EDF (Earliest Deadline First), ma `e
possibile introdurre facilmente anche altri algoritmi.
Nella presente descrizione non si `e entrati nei dettagli dei vari componenti, perch`e YARA `e tuttora in fase di evoluzione, fornendo sempre nuove
funzionalit`a e qualche componente potrebbe subire delle modifiche.
4.2
Fasi di sviluppo
Nello sviluppo del software si sono seguiti i seguenti passi.
Studio del protocollo. Gi`a descritto nella sezione 2.4, ha permesso, successivamente, di implementare correttamente la comunicazione con il
server rispettando le regole sintattiche e le successioni di comandi necessarie.
Studio del driver P2OS di Player. Per evitare di dover implementare il
protocollo di comunicazione partendo da zero, `e stato analizzato il driver che permette a Player di interfacciarsi con i robot della ActivMedia.
Sviluppo di una classe C++ per la comunicazione con il robot. Il primo obbiettivo di sviluppo software `e stato la creazione di una classe
che permettesse di instaurare una connessione con il robot, e successivamente visualizzasse i dati sensoriali ricevuti dal robot.
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
30
Integrazione nel framework YARA. In questa fase, alla classe creata
precedentemente sono stati aggiunti i dati e i metodi necessari per
trasformarla in un modulo conforme alle specifiche del framework YARA.
Realizzazione di un comportamento. Per testare il funzionamento del
modulo realizzato, `e stata sviluppata una semplice applicazione che
consiste in un comportamento di navigazione stay in the middle basato
sulle letture sensoriali dei sonar.
4.3
Driver P2OS di Player
Per consentire allo sviluppatore l’accesso in modo standard alle varie piattaforme robotiche, Player 1.2.2 `e organizzato su due livelli:
- le interfacce;
- i driver.
Il programmatore che vuole controllare un robot utilizza i proxy, messi
a disposizione dalla C++ client library, per connettersi alle interfacce che
forniscono i dati sensoriali e accettano i comandi di moto. Esistono interfacce
per il controllo dei motori (motor ), per la lettura dei sonar (sonar ), e tante
altre per ogni componente necessario all’utilizzo di un robot. La grande
potenzialit`a di Player sta nel fatto che con un’unica interfaccia `e possibile
controllare il corrispondente elemento di molti modelli diversi di robot mobili.
Ad un livello pi`
u basso, i driver si occupano di tradurre i comandi standard arrivati alle interfacce nei comandi specifici per un determinato robot
mobile o, viceversa, tradurre i dati provenienti dal robot nel formato standard dell’interfaccia relativa a un certo tipo di sensore. Per ogni modello,
o famiglia, di robot esiste un apposito driver che si occupa della traduzione
nelle due direzioni.
Andando ad analizzare i file sorgenti del server Player, si trova una
directory denominata p2os. Questa contiene i seguenti file:
- Makefile.am, Makefile.in necessari alla compilazione delle classi.
- p2os.cc, p2os.h che contengono la classe principale con la quale `e possibile interagire con il sistema operativo p2os a bordo dei robot.
- packet.cc, packet.h contengono una classe (P2OSpacket) che permette
la gestione dei pacchetti scambiati con il robot su una linea seriale,
fornendo dei metodi per costruire, inviare e ricevere un pacchetto.
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
31
- robot params.cc, robot params.h contengono un lungo elenco di parametri
che caratterizzano i vari robot prodotti dalla ActivMedia. Tra i vari
valori presenti si possono facilmente individuare quelli relativi alle dimensioni e geometria del robot, oppure quelli sulla dotazione sensoriale.
- sip.cc, sip.h contengono una classe che permette il parsing e la memorizzazione dei dati provenienti dal robot.
Il driver p2os permette di controllare tutta la famiglia di robot prodotti
dalla ActivMedia sui quali `e eseguito il sistema operativo p2os. Sul Pioneer `e
installato il psos 4.9 che rappresenta la prima versione del sistema operativo
antecedente al p2os. Per questo motivo l’utilizzo dell’intero driver p2os per
la realizzazione del modulo sarebbe assai superfluo perch`e esso prevede tutta
una serie di funzionalit`a non supportate del robot Pioneer 1.
La parte che `e risultata pi`
u utile per lo svolgimento della tesi `e la classe
P2OSpacket. Dopo alcune modifiche questa classe `e stata inserita all’interno
del progetto.
4.4
Realizzazione delle funzionalit`
a di base
Nel progetto e nella realizzazione dell’architettura di controllo si `e mirato a
realizzare un’applicazione che potesse essere integrata nel framework YARA,
cercando, allo stesso tempo, di mantenere un sufficiente grado di generalit`a
per consentire il riutilizzo del codice su altri framework oppure all’interno di
applicazioni stand-alone legate all’utilizzo del Pioneer. Per soddisfare questa
esigenza, si `e deciso di dividere le parti del programma che interessano la
comunicazione tra il PC client e il server sul robot dalle parti riguardanti
l’interazione con il framework YARA.
In questa prima fase di sviluppo, si `e quindi realizzato la classe C++
principale, denominata Pioneer, che implementa le varie funzioni necessarie
alla comunicazione con il robot, permettendo di inizializzare correttamente la
connessione con il PSOS a bordo del Pioneer e, successivamente, di ricevere
ed inviare le informazioni per il controllo.
Per cercare di rendere l’utilizzo della classe il pi`
u semplice possibile si `e
seguito il pattern RAII [Resource Acquisition Is Initialization] instaurando
automaticamente la connessione nel momento in cui l’oggetto della classe
Pioneer viene creato, e rilasciandola quando l’oggetto viene distrutto.
Il contenuto dalla classe Pioneer `e rappresentato nel diagramma UML in
figura 4.2.
L’unico parametro che `e necessario passare al costruttore consiste nel
nome del file associato al device della porta seriale utilizza per il collega-
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
32
Figura 4.2: Diagramma UML della classe Pioneer.
mento con il robot. Il PC a bordo del Pioneer `e dotato di due interfacce
seriali; una di queste `e stata dedicata esclusivamente per le comunicazioni
con il robot ma, nonostante questo, si `e deciso di implementare la possibilit`a
di specificare la porta seriale, in previsione di possibili utilizzi su piattaforme
diverse. Tutte le operazioni necessarie per instaurare la connessione vengono
eseguite dal costruttore della classe richiamando i metodi opportuni.
Per lo scambio di pacchetti tra il PC client e il robot `e stata sviluppata
una classe apposita che permette la gestione di un singolo pacchetto. La
struttura della classe PSOSPacket `e presentata in figura 4.3.
Figura 4.3: Diagramma UML della classe PSOSPacket.
Ogni oggetto della classe PSOSPacket `e un contenitore per un pacchetto. Mediante i metodi Send e Receive si pu`o inviare o ricevere un pacchetto
passando come argomento il file descriptor del device da utilizzare per la
comunicazione. Il contenuto del pacchetto pu`o essere letto o modificato mediante la variabile packet. Se si vogliono caricare dei dati in un pacchetto `e
anche possibile utilizzare il metodo Build che si prende carico di inserire i
dati, passati come argomento, nel pacchetto aggiungendo in automatico l’intestazione e il checksum.
La classe Pioneer, utilizzando degli oggetti della classe PSOSPacket, `e
in grado di comunicare con il robot. L’inizio dello scambio di informazioni
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
33
e comandi fra PC e robot avviene tramite una procedura di handshaking
(stretta di mano). Questa operazione viene eseguita dalla funzione synchronization() che si occupa di inviare i pacchetti di sincronizzazione e attende
le risposte dal robot (si veda la sezione 2.4.7). La stessa funzione si occupa
anche dell’eventuale reset del robot, nel caso una connessione precendente si
sia interrotta senza aver eseguito la sequenza di chiusura.
Il metodo receiveServerData permette la ricezione di un pacchetto di informazioni dal robot passandolo poi alla funzione parser che si occupa di
estrarre i singoli dati e memorizzarli nei relativi attributi della classe. La
funzione setVelocity permette di inviare i comandi per il movimento del robot
impostando separatamente le velocit`a transazionale e rotazionale.
Ultimata la realizzazione della classe `e stato possibile testarla realizzando un semplice programma che permette il controllo del robot mediante la
tastiera del PC, stampando a video le letture dei dati sensoriali. Con questo
programma si `e riusciti a testare la corretta implementazione del protocollo di
comunicazione e a provare il comportamento dinamico del robot, valutando
la correttezza delle informazioni sensoriali restituite.
4.5
Integrazione nel framework YARA.
Nella sezione precedente si `e illustrata la struttura della classe Pioneer analizzandone le funzioni membro che permettono di gestire la comunicazione verso
il robot. Il passo successivo nella realizzazione dell’architettura di controllo
del Pioneer consiste nell’integrazione della classe appena creata all’interno
del framework YARA.
L’elemento fondamentale per l’utilizzo del framework `e il Modulo, inteso
come componente attivo e autonomo che opera all’interno dell’architettura: il
controllo del robot avviene mediante l’esecuzione di pi`
u moduli che svolgono
attivit`a indipendenti e cooperano tra loro attraverso lo scambio di comandi
e informazioni. Non i singoli moduli, ma la loro interazione all’interno del
framework consente di determinare il comportamento del robot. Ogni modulo
svolge una serie di compiti elementari determinati da un insieme di algoritmi
eseguiti sui dati ricevuti, producendo un risultato inviato agli altri moduli
oppure inviato all’hardware del robot. Per esempio, i compiti di un singolo
modulo potrebbero essere: la gestione dei motori, la gestione dei bumber
oppure l’implementazione di un behaviour (comportamento).
L’architettura di controllo del Pioneer deve consentire l’interazione con
il robot attraverso l’invio di comandi ai motori e la ricezione delle letture dei
sonar. Il funzionamento del framework suggerirebbe di implementare queste
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
34
funzionalit`a ricorrendo a due moduli: un modulo Sonar che fornisce le misure
rilevate dai sonar e un modulo Motor per il controllo dei motori sulla base
dei comandi ricevuti dagli altri moduli. Questa impostazione dei moduli
tuttavia non `e risultata adatta per il controllo del Pioneer : la comunicazione
con il robot avviene mediante un’unica linea seriale, sulla quale viaggiano
sia i comandi per i motori che le letture sensoriali e, quindi, risulterebbe
complicato e poco efficiente la condivisione del canale di comunicazione da
parte dei due moduli. Per ovviare a questa limitazione si `e deciso di affidare
il controllo della linea seriale ad un unico modulo. Questo modulo `e stato
chiamato Pioneer ed offre sia le funzioni per gestire i sonar, sia quelle per i
motori.
Per lo scambio di informazioni e comandi tra i moduli il framework
prevederebbe tre pattern di comunicazione:
Information. Consente di inviare e ricevere dati di tipo generale, che serviranno per lo pi`
u a rappresentare misure sensoriali rilevate dal robot.
L’invio dei dati avviene secondo lo schema uno a molti.
Command. Consente di realizzare un meccanismo di comunicazione duale
al precedente, permettendo l’invio di comandi da pi`
u moduli verso uno
unico che si occupa del controllo di un attuatore hardware.
Query. Permette di effettuare la richiesta esplicita di informazioni a un
modulo che le fornisce in risposta.
Per lo scambio delle misure effettuate dai sonar si ricorre al pattern Information e per la gestione dei motori il pi`
u adatto sarebbe il pattern Command,
ma nella attuale versione del framework questo pattern non `e ancora disponibile. Provvisoriamente si `e quindi utilizzato il pattern Information anche per
il controllo dei motori che, pur limitando il campo di utilizzo dell’architettura, `e risultato adeguato allo sviluppo di applicazioni che implementano
semplici comportamenti (si ricorda che la comunicazione con questo pattern
avviene da uno a molti).
Lo svolgimento dei compiti di un modulo, implementati nel codice delle
sue funzioni membro, avviene attraverso delle attivit`
a che si occupano di
mettere in esecuzione le singole funzioni. Nel modulo Pioneer sono necessarie
due attivit`a : una con schedulazione periodica, per la ricezione dei Server
Information Packets (vedi sezione 2.4.6) inviati dal robot contenenti le letture
dei sonar, e un’altra aperiodica, controllata dal sistema di comunicazione del
framework, eseguita nel momento in cui si rende necessario l’invio di comandi
per il controllo dei motori.
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
4.5.1
35
Implementazione
La libreria del framework YARA permette di realizzare un modulo dell’applicazione attraverso la sua implementazione in una classe C++ derivata dalla
classe astratta Module. La classe Pioneer, realizzata nella sezione 4.4, `e stata
trasformata in un modulo del framework. Per prima cosa si `e modificata
l’interfaccia della classe stessa, per dichiarare che questa deriva dalla classe
astratta Module.
Per fornire le misure di distanza rilevate dai sonar, agli altri moduli del
sistema, viene utilizzato il pattern di comunicazione Information: la classe
Pioneer definisce perci`o, al suo interno, un oggetto Sender che invia dati
aventi il nome simbolico sonar. I sonar installati a bordo del Pioneer sono 7,
quindi, per consentire di aggiornare singolarmente le misure rilevate, viene
sfruttata la struttura dati multiple messa a disposizione dalla libreria del
framework. Il dato inviato dall’oggetto Sender viene definito come segue:
typedef YARA::multiple <double, 7> SonarData; .
All’interno del Server Information Packets inviato dal robot, le misure
dei sonar sono restituite sotto forma di numeri interi con valori compresi tra
0 e 30000. Questi valori vengono convertiti in metri prima di essere invitati
ai moduli richiedenti permettendo un uso pi`
u razionale dell’architettura di
controllo (si veda la sezione 5.1).
Il modulo Pioneer per ricevere i comandi di moto da inviare al robot,
utilizza un oggetto Receiver che accetta dati con il nome simbolico motor,
constituti da informazioni di tipo MotorCommand definito nel seguente modo:
struct MotorCommand { double trasl; double rotat}; .
Questa struttura permette di definire contemporaneamente sia la velocit`a
di traslazione (in m/s) che quella di rotazione (in rad/s) da imporre al robot.
Per la gestione della comunicazione con il robot, l’invio dei dati dei sonar
e la ricezione dei comandi per i motori dagli altri moduli, vengono utilizzate
due attivit`a gestite mediante due oggetti Activity definiti all’interno della
classe Pioneer. Il primo oggetto Activity di nome sendReceive permette l’esecuzione periodica ogni 100ms della funzione membro receiveServerData che
si occupa di ricevere il Server Information Packet inviato dal robot, estrarne
il contenuto, inviarne i dati dei sonar agli altri moduli e comunicare al robot
i comandi per gestire i motori. Il secondo oggetto Activity, di nome setVe-
CAPITOLO 4. PROGETTAZIONE E SVILUPPO
36
locity, `e un’attivit`a aperiodica che si occupa di attivare la funzione setVel()
nel momento in cui altri moduli rendono disponibili dei comandi di moto
per il robot. setVel memorizza, nelle variabili private della classe, i valori di
velocit`a ricevuti, utilizzati poi per inviare comandi al robot.
Il framework consente il controllo dell’inizio e della fine della schedulazione delle Activity mediante l’utilizzo di un oggetto Unit da passare al
costruttore di ogni modulo integrato nel framework. Questo oggetto si occupa di richiamare i metodi start() e stop(), implementati in tutti i moduli, che
attivano e disattivando l’esecuzione periodica o aperiodica (su disponibilit`a
dei dati) delle Activity.
La struttura semplificata del modulo Pioneer `e riportata nel listato 4.1
(vengono omessi i metodi e gli attributi non strettamente legati all’integrazione della classe nel framework) .
1
2
3
4
5
class Pioneer : public YARA::Module
{
public:
Pioneer(YARA::Unit& u, const std::string& ttyName_);
~Pioneer() throw();
6
7
8
9
10
11
private:
void start();
void stop();
void receiveServerData();
void setVel();
12
YARA::Activity<void,void> sendReceive;
YARA::Activity<void,void> setVelocity;
YARA::Sender< SonarData > sonar;
YARA::Receiver< MotorCommand > motor;
13
14
15
16
17
double translationVel;
double rotationalVel;
double sonars[7];
18
19
20
21
};
Listato 4.1: Struttura base del modulo Pioneer.
Capitolo 5
Sperimentazione
Le fasi di progettazione e di sviluppo del modulo Pioneer da integrare nel
framework YARA, illustrate nel capitolo precedente, sono state affiancate da
una serie di prove sperimentali per verificare il corretto funzionamento del
codice sviluppato nei vari passi e per consentire l’implementazione di alcune
parti del modulo strettamente legate alla gestione dell’hardware del robot. In
particolare sono state svolte prove per la verifica dell’esecuzione dei comandi
inviati al robot per il controllo dei motori e per tarare le letture dei sonar.
Nel presente capitolo si analizza il lavoro svolto sui sonar del robot e si descrive come, sfruttando le funzionalit`a messe a disposizione dall’architettura
di controllo, sono stati sviluppati alcuni semplici behaviour per permettere il
controllo del comportamento del robot.
5.1
Taratura dei sonar
I 7 sonar installati sul Pioneer permettono la misura della distanza degli
ostacoli presenti di fronte e di fianco al robot. Tale misura viene utilizzata nel controllo del comportamento del robot. Questa tipologia di sensori
viene adotatta su molti modelli di robot mobili per uso indoor, quale miglior
compromesso tra costo e prestazioni.
Il principio di funzionamento dei sonar si basa sull’emissione di un’onda
acustica, ad una determinata frequenza, e sulla misura del tempo di attesa
dell’eco riflesso. Il tempo di attesa viene detto tempo di volo T (tempo di
andata e ritorno) ed `e legato alla distanza d dalla velocit`a del suono in aria
c (344 m/s alla temperatura di 22◦ C) secondo la relazione
d = c ∗ T /2
La velocit`a del suono `e variabile in dipendenza delle condizioni atmosferiche, come temperatura, pressione, umidit`a e vento. Questa sensibilit`a
37
CAPITOLO 5. SPERIMENTAZIONE
38
Figura 5.1: I 5 sonar frontali del Pioneer
rappresenta un limite all’utilizzo dei sonar in ambienti aperti, ma non crea
problemi in ambienti chiusi dove le condizioni climatiche non subiscono grosse
variazioni.
Il PSOS, a bordo Pioneer, si occupa della gestione dei sonar e attraverso
l’invio dei pacchetti al PC fornisce all’applicazione di controllo un valore
della distanza misurata dai singoli sonar. Sfortunatamente questo valore
non `e rappresentato in unit`a temporali o di distanza note ma bens`ı con un
numero intero, compre tra 0 e 30000. Il manuale operativo del robot consiglia
la valutazione sperimentale per il calcolo della funzione di trasferimento da
applicare al valore restituito per poterlo convertire in metri di distanza.
Nel seguito della presente sezione verr`a descritto il procedimento adottato
per trovare la funzione di conversione delle misure dei sonar.
Passo 1
Per ognuno dei 7 sonar sono state raccolte una serie di misure effettuate
ponendo un ostacolo, costituito da una scatola di cartone, a varie distanze
dai sonar stessi (vedere figura 5.2).
Le misure sono state effettuate a 10cm, 20cm, 30cm, 40cm, 50cm, 60cm
di distanza da ogni sonar e il valore ottenuto riportato in una tabella. Ogni
singola misura veniva effettuate nel seguente modo:
- Posizionamento del sonar esattamente di fronte all’ostacolo ad una
determinata distanza.
- Mediante un apposito software eseguito sul PC collegato al robot si calcola il valore misurato dal sonar facendo la media sui campioni restituiti
in 10s di misura.
- Trascrizione del valore nella tabella.
Nella tabella 5.1 sono riportati i valori raccolti.
CAPITOLO 5. SPERIMENTAZIONE
39
Figura 5.2: Dislocazione del Pioneer e dell’ostacolo per la taratura dei sonar.
Figura 5.3:
Sonar
Sonar
Sonar
Sonar
Sonar
Sonar
Sonar
Rappresentazione dall’alto della console del Pioneer con la
dislocazione dei sonar.
0
1
2
3
4
5
6
10 cm 20 cm 30 cm 40 cm 50 cm 60 cm
1230
1370
1932
2508
3097
3652
1190
1376
1958
2506
3108
3651
1198
1371
1945
2517
3089
3663
1223
1366
1943
2520
3082
3660
1174
1377
1937
2509
3103
3674
1180
1373
1944
2532
3103
3662
1227
1372
1936
2518
3084
3648
Tabella 5.1: Misure dei sonar.
CAPITOLO 5. SPERIMENTAZIONE
40
Passo 2
I valori raccolti nella tabella sono stati tracciati nel grafico presente in
figura 5.4.
Figura 5.4: Grafico dei valori raccolti dai sonar.
Dal grafico si vede molto chiaramente che le misure ottenute dai sonar,
come ci si aspettava, sono direttamente proporzionali alla distanza dell’ostacolo ad eccezzione della lettura a 10cm. I grafici corrispondenti ai 7 sonar
rispecchiano tutti lo stesso andamento permettendo di concludere che tutti i
sensori funzionano correttamente. Le misure effettuate a 10cm non sono in
proporzione con le altre perch`e si tratta di una distanza troppo bassa alla
quale i sonar Polaroid non permettono la corretta valutazione del tempo di
volo.
Passo 3
Per individuare la funzione di trasferimento che lega le misure dei sonar
alla distanza in metri dell’ostacolo, si sono calcolate le medie dei valori alle
singole distanze e successivamente si sono calcolate le differenze tra un valore
e il successivo (5.2).
20 cm 30 cm 40 cm 50 cm 60 cm
Media 1372
1942
2515
3095
3659
Diff.
570
573
579
563
Tabella 5.2: Misure dei sonar.
CAPITOLO 5. SPERIMENTAZIONE
41
Dalla tabella si `e ricavata la seguente funzione lineare che lega la misura
effettuata dai sonar (val) alla distanza in metri (dist).
dist = (val − 229)/5720
Questa funzione `e stata successivamente implementata all’interno del
metodo, del modulo Pioneer, che si occupa della gestione e dell’invio delle
misure sensoriali ai vari moduli dell’architettura.
Ulteriori rilevazioni di distanze di ostacoli hanno permesso di valutare un
errore massimo del 2% su misure comprese nel range di funzionamento dei
sensori, cio`e tra i 17cm e i 5,20m.
5.2
Realizzazione di un comportamento
Per mostrare un utilizzo concreto e per valutare il corretto funzionamento dell’architettura di controllo realizzata, sono stati sfruttati il framework
YARA e il modulo Pioneer per progettare una semplice applicazione che consenta al robot di percorrere, in autonomia, un corridoio stando allineato al
centro e, in presenza di ostacoli troppo vicini, di fermarsi per evitare possibili
collisioni. In figura 5.5 viene rappresentato lo schema del sistema preso in
considerazione. distR e distL rappresentano rispettivamente le distanze destra e sinistra tra il robot e le pareti del corridoio, v `e la velocit`a transazionale
e w la velocit`a rotazionale.
La realizzazione dell’applicazione richiede l’implementazione di un behaviour di Collision Avoidance, per il controllo della velocit`a di translazione,
e di un behaviour di Stay In The Middle, per controllare la velocit`a di
rotazione.
Il behaviour di Collision Avoidance si occupa di tenere sotto controllo le
misure dei sonar e impone lo stop del movimento del robot nel caso venga
rilevato un ostacolo a distanza minore di una soglia di sicurezza. Se nessun
ostacolo `e rilevato viene mantenuta una veloci`a di translazione costante pari
a 20 cm/s.
Il behaviour di Stay In The Middle controlla le misure dei sonar laterali
e, sulla base di queste, corregge la direzione di moto del robot cercando di
mantenerlo al centro delle due pareti laterali. Per controllare dinamicamente
il corretto posizionamento del robot viene realizzato un semplice controllo in
retroazione schematizzato in figura 5.6.
L’anello di retroazione permette la regolazione della posizione diff del
robot rispetto al centro del corridoio impostando una velocit`a rotazionale w
proporzionale alla differenza tra la posizione desiderata diff* e quella cal-
CAPITOLO 5. SPERIMENTAZIONE
42
Figura 5.5: Modello del sistema.
Figura 5.6: Regolatore della posizione del robot.
colata diff = distL - distR. Imponendo un valore del set-point diff* pari a
0 il robot dovrebbe procedere mantenendosi al centro del corridoio. Il controllore proporzionale, con guadagno K, imposta la velocit`a rotazionale w
che dovrebbe assicurare la convergenza verso il posizionamento corretto del
robot grazie al comportamento integrale del sistema. Dopo una serie di prove
`e stato individuato il valore di K che consente l’avanzamento del robot senza
eccessive oscillazioni attorno alla traiettoria ideale.
I due behaviour di Collision Avoidance e Stay In The Middle sono stati
implementati in un unico modulo denominato Behaviour che rappresenta il
controllore del sistema robot. Il listati del modulo realizzato e del main program necessario all’esecuzione dell’applicazione sono illustrati nella sezione
CAPITOLO 5. SPERIMENTAZIONE
43
B. Il modulo si registra come receiver di dati sonar permettendo l’esecuzione
della funzione perform() nel momento in cui vengono resi disponibili nuovi
dati dal modulo Pioneer. Le letture dei sonar vengono pubblicate con una frequenza pari a 10 Hz, pertanto anche il controllo del comportamento mediante
la funzione perform() avviene a tale frequenza. All’interno di questa funzione
`e stato implementato il controllore illustrato nella figura 5.7 costituito da due
blocchi che si occupano della gestione dei singoli Behaviour.
Figura 5.7: Controllore.
La divisione in blocchi `e stata rispettata anche nella stesura del codice.
Dopo aver eseguito le letture dei valori dei sonar, questi vengono confrontati
con la costante MIN DIST OBJECT per stabilire la presenza di ostacoli
troppi vicini al robot. Successivamente viene implementato il controllore proporzionale per il calcolo della velocit`a di rotazione e viene inviato il comando
ai motori.
Una serie di test svolti negli ambienti intorno al laboratorio ha mostrato
il corretto funzionamento del sistema realizzato. Il robot percorre i corridoi
mantenendosi al centro ed adattandosi a cambiamenti delle pareti superando
correttamente le colonne portanti che sporgono da esse e riallineandosi nel
caso di un cambiamento della larghezza del corridoio. Il controllore realizzato
`e molto semplice; infatti mostra i suo limiti quando il robot incontra un
curva molto stretta nel corridoio. In questa circostanza il robot continua
ad avvicinarsi alla parete che ha di fronte, fermandosi quando raggiunge la
soglia di sicurezza, imposta dal comportamento di Collision Avoidance, senza
riuscire ad adattarsi al cambiamento di direzione.
Capitolo 6
Conclusioni
In questo progetto di tesi `e stata sviluppata un’architettura di controllo per
il robot mobile Pioneer che consenta la lettura dei dati sensoriali e l’invio
di comandi motori, permettendo la realizzazione di architetture robotiche di
tipo reattivo.
Dopo una prima fase durante la quale si sono analizzati la struttura e i
principi di funzionamento del robot, si `e deciso di procedere ad un aggiornamento fisico del robot stesso che ha portato all’installazione a bordo di un
PC e alla possibilit`a di espandere le capacit`a sensoriali, mediante l’utilizzo
di moderni sensori quali sistemi di visione digitali e scanner laser. Le risorse
computazionali, fornite dal PC di bordo e adeguate alle moderne applicazioni
robotiche, hanno permesso una migliore versatilit`a di utilizzo del robot data,
soprattutto, dalla possibilit`a di operare in completa autonomia senza essere
vincolato ad un postazione fissa per l’elaborazione.
Per lo sviluppo dell’architettura di controllo `e stato sfruttato il framework YARA che consente la creazione di applicazioni robotiche, composte da
una serie di moduli indipendenti, mettendo a disposizione gli strumenti per
realizzare i moduli stessi, per la loro schedulazione real-time e per lo scambio
di informazioni e comandi tra essi.
Il componente principale dell’architettura di controllo, consiste nel modulo Pioneer che si occupa della completa gestione del robot: comunicazione
seriale, pubblicazione dei dati sensoriali e invio dei comandi di moto. Per
come `e strutturato, il modulo solleva lo sviluppatore che lo utilizza dall’occuparsi delle operazioni di basso livello facilitando l’interazione con il robot,
permettendo di concentrarsi sullo sviluppo degli algoritmi che realizzano il
comportamento.
Nella stesura del codice dell’architettura di controllo si `e cercato di mantenere, quanto pi`
u possibile, separate la parte legata alla comunicazione con
il robot dalla parte legata all’integrazione del modulo all’interno del frame44
CAPITOLO 6. CONCLUSIONI
45
work. Questo aspetto `e molto importante in previsione di un futuro riutilizzo, del codice realizzato, all’interno di altri framework oppure in applicazioni
stand-alone.
Terminato lo sviluppo del modulo Pioneer si `e sviluppato qualche semplice modulo comportamentale per verificare il corretto funzionamento dell’architettura di controllo. In particolare sono stati creati un modulo per
il test dei sonar del robot e dei moduli behaviour per semplici applicazioni
di navigazione che hanno permesso di testare l’utilizzo dell’architettura per
il controllo del comportamento dinamico del robot. Inoltre, la creazione di
questi moduli ha mostrato la relativa semplicit`a con la quale si possono realizzare applicazioni robotiche basate sull’architettura di controllo sviluppata.
I possibili sviluppi futuri di questo progetto di tesi sono i seguenti:
- Modificare l’attuale modulo Pioneer per una sua integrazione all’interno di future versioni del framework YARA nelle quali sia disponibile
il pattern di comunicazione Command, per permettere lo sviluppo di
applicazioni robotiche pi`
u complesse.
- Sviluppare un modulo per il framework YARA che consenta l’utilizzo
dello scanner laser Sick LMS 200 installato a bordo del Pioneer.
- Implementare un controllo pi`
u completo dei sensori sonar, attraverso
la gestione della sequenza di firing e permettendo lo spegnimento degli
stessi nel caso non fossero necessari.
- Installare, a bordo del Pioneer, un sistema di visione digitale per ampliare le possibilit`a di utilizzo del robot.
Appendice A
Procedure tecniche
Nelle sezioni della presente appendice vengono illustrate le procedure tecniche
da seguire per l’utilizzo del robot Pioneer e dello scanner laser Sick LMS
200 ponendo particolare attenzione alle operazioni necessarie per la corretta
ricarica delle batterie al piombo e delle batterie al NiMh.
A.1
Installazione del PC di bordo
Normalmente, il PC dedicato viene sempre lasciato montato a bordo del
Pioneer. Nel caso non sia presente, seguire le seguenti operazioni per una
corretta installazione del PC sul robot.
Hardware richiesto:
- Il Pioneer 1.
- Il PC dedicato, normalmente riposto nell’apposita scatola di cartone.
- 2 ghiere di fissaggio, normalmente avvitate alla barre filettate di ottone
presenti sul Deck del robot.
Procedura di installazione:
- Posizionare il Pioneer 1 su un adeguato piano di appoggio.
- Estrarre il PC dalla scatola di cartone nel quale `e riposto.
- Svitare le 2 ghiere di fissaggio avvitate alla barre filettate sul Deck del
robot.
46
Appendice
47
- Collocare il PC sul Deck del robot facendo attenzione che le barre
filettate si vadano ad infilare negli appositi fori presenti nella parte
anteriore del case del PC.
- Avvitare le 2 ghiere di fissaggio alle barre filettate fino a fondo corsa in
modo tale che il PC non sia libero di muoversi.
- Collegare il plug di alimentazione, fissato sul cavo che esce dalla Console del robot, nell’apposito connettore presente nella parte posteriore
sinistra del case del PC.
Figura A.1: Particolare del PC nel quale si pu`o notare il dado di fissaggio, il plug
di alimentazione e l’interruttore.
- Collegare il connettore DB9 presente sul cavo piatto grigio, che esce
dalla parte destra del case, al relativo connettore presente sulla Console
del robot.
- Terminate queste operazioni, `e possibile collocare il robot sul pavimento
nell’ambiente dove verr`a utilizzato.
- Accendere il robot agendo sull’apposito interruttore a slitta posizionato
sulla parte superiore della Console. Controllare che il led rosso power
di fianco all’interruttore si accenda.
- Controllare che la tensione visualizzata a destra sulla riga inferiore del
display LCD, presente sulla Console, sia superiore a 12,0V. In caso
contrario, si consiglia di mettere sotto carica le batterie del robot prima
di un suo utilizzo.
Appendice
48
- Fornire alimentazione al PC agendo sull’interruttore posizionato nella
parte posteriore sinistra del case. Controllare che il led giallo, presente
sulla parte superiore del case, si accenda.
- Premere brevemente il pulsante presente sul case in corrispondenza del
led verde per avviare la fase di boot del PC. Controllare l’accensione
fissa del led verde.
- Terminata la fase di boot del sistema operativo installato nel PC `e
possibile utilizzare il robot.
Figura A.2: Il PC installato correttamente a bordo del robot.
A.2
Installazione dello scanner laser Sick LMS
200
Le seguenti operazioni permettono l’installazione dello scanner laser Sick
LMS 200 sul Pioneer per consentirne l’utilizzo mediante il PC di bordo.
Hardware richiesto:
Appendice
49
- Il Pioneer 1 dotato del PC di bordo.
- Lo scanner laser Sick LMS 200.
- 2 maniglie a ripresa, normalmente avvitate sul retro dello scanner laser.
- 2 pacchi batterie composti ciascuno da 10 batterie ricaricabili al NiMh.
- 1 cavetto adattatore per il collegamento in serie dei due pacchi batterie.
Procedura di installazione:
- Se presenti, svitare le due maniglie a ripresa dal retro dello scanner
laser.
- Posizionare lo scanner laser sull’apposito supporto presente sulla Console del robot.
- Fissare lo scanner laser al supporto utilizzando le due maniglie a ripresa
(vedi figura A.3).
Figura A.3: Fissaggio del laser mediante le maniglie a ripresa.
- Collegare il cavo dati seriale dello scanner laser al connettore della porta
seriale presente sul PC.
- Collocare i due pacchi batterie ai lati della bussola del robot (il cubo
nero presente sul Deck ) fissandoli con un elastico.
- Collegare i due pacchi batterie in serie mediante l’apposito cavo adattatore visibile in figura A.4.
Appendice
50
Figura A.4: Pacchi batterie al NiMh e cavo adattatore.
- Collegare l’altro capo dell’adattatore (il connettore pi`
u grande) al cavo
di alimentazione dello scanner laser.
- Dopo 15-20 secondi, controllare l’accensione del led verde situato sulla
parte superiore dello scanner laser. Se il led verde lampeggia significa
che i pacchi batterie sono scarichi ed `e necessario ricaricarli.
- Lo scanner laser `e pronto per essere utilizzato (figura 3.1).
A.3
Ricarica delle batterie
Quando si lavora nel campo della robotica mobile, e dei dispositivi ad essa
collegati, si ha sempre a che fare con la gestione della ricarica delle batterie.
Le principali tipologie di batterie ricaricabili utilizzate sono quelle al piombo
e quelle al NiMh [Nickel-Metal Hydride].
In questa sezione vengono analizzati i procedimenti necessari per una
corretta ricarica delle due tipologie di batterie.
A.3.1
Batterie al piombo
Il Pioneer ha al suo interno due batterie al piombo da 12V e 7 Ah. Per la
loro ricarica seguire i seguenti passi:
- Procurarsi il caricabatterie MiniTRON con apposito cavo adattatore.
Questo deve avere da un capo un connettore bipolare, da collegare a
Appendice
51
quello presente sul cavo del caricabatterie, e dall’altro un plug nero per
il collegamento al robot.
- Collegare la spina di alimentazione del caricabatterie ad una presa di
rete elettrica.
- Collegare il plug nero nell’apposito connettore presente sulla parte posteriore della Console del robot. Anche se non strettamente necessario
si consiglia di effetture la ricarica delle batterie al piombo solo dopo
aver spento il robot e il PC di bordo.
- Controllare l’accensione fissa del LED rosso sul caricabatterie che indica
la fase di ricarica delle batterie.
- Quando si accende il led verde la fase di ricarica `e completata e si
pu`o scollegare il robot per utilizzarlo. Se non si scollega il robot non si
verifica nessun danno ma, semplicemente, alle batterie viene fornita una
tensione costante di mantenimento per evitare il fenomeno dell’autoscarica.
- Scollegare il robot dal caricabatterie per poterlo utilizzare.
A.3.2
Batterie al NiMh
Rispetto alle batterie al piombo, la ricarica di quelle al NiMh `e un’operazione
da compiere con maggiore attenzione se si vuole garantire una lunga durata
di vita alle batterie stesse.
La ricarica delle batterie al NiMh `e vivamente consigliata eseguirla partendo da batterie completamente scariche. I pacchi batterie utilizzati per
alimentare il laser Sick LMS 200 sono formati , ciascuno, da 10 elementi che,
messi in serie, forniscono una tensione nominale di 12V (1, 2 ∗ 10 = 12) e
si possono considerare scarichi nel momento in cui la tensione scende sotto
gli 11,8V circa. Quando i due pacchi batterie sono collegati al laser bisogna
utilizzarli fino a quando il laser stesso segnala, attraverso il lampeggio del
LED verde, il livello basso della tensione di alimentazione e, di conseguenza,
la scarica delle batterie.
Per la ricarica di un singolo pacco batterie da 10 elementi procedere come
segue.
- Procurarsi un caricabatterie Ansmann ACS410P con apposito cavo
adattatore per consentirne il collegamento al connettore presente sul
pacco batteria.
Appendice
52
- Collegare la spina di alimentazione del caricabatterie ad una presa di
rete elettrica.
- Collegare il connettore del carica batteria a quello del pacco batterie.
- Se non si `e sicuri della completa scarica delle batterie, premere il
pulsante giallo sul carica batterie per avviare il processo di scarica
automatico.
- Attendere, dopo qualche ora, l’accessione del LED verde che indica il
raggiungimento dell’85% di carica delle batterie. Il pacco batterie pu`o
gi`a essere utilizzato. Se si vuole una ricarica completa, si consiglia di
lasciare le batterie sotto carica per almeno 8-10 ore. In ogni caso non
superare le 24 ore di ricarica.
- Scollegare il pacco batterie pronto per l’uso.
Appendice B
Listato dell’applicazione Stay
In The Middle
In questa appendice viene illustrato il codice sorgente del modulo che implementa il comportamento realizzato per testare la funzionalit`a dell’architettura di controllo. Per la descrizione degli algoritmi si veda il capitolo 5.2. Il
listato B.3 rappresenta il programma principale dell’applicazione nel quale si
pu`o facilmente individuare la fase di creazione del modulo Pioneer e del modulo Behaviour che implementa il comportamento. Successivamente mediante
l’istruzione u.start() si avviano l’esecuzione delle Activity dei moduli.
B.1
Behaviour per il robot
Listato B.1: Interfaccia della classe che implementa il modulo Behaviour.
1
2
const double MIN_DIST_OBJECT = 0.30;
const double K = 0.5;
3
4
5
6
7
8
class Behaviour : public YARA::Module
{
public:
// Costruttore
Behaviour(YARA::Unit& u);
9
10
11
12
13
private:
void perform(); // Implementa il comportamento
void start();
void stop();
14
53
Appendice
54
// Oggetti YARA
YARA::Activity<void,void> check;
YARA::Receiver< SonarData > sonar;
YARA::Sender< MotorCommand > motor;
15
16
17
18
19
MotorCommand vel;
20
21
};
Listato B.2: Implementazione della classe Behaviour.
1
#include "Behaviour.h"
2
3
4
5
6
7
8
9
10
11
Behaviour::Behaviour(YARA::Unit& u)
: Module( u, "Behavior" ),
check( this, &Behaviour::perform, 0.05 ),
sonar( this, "sonar" ),
motor( this, "motor" )
{
vel.trasl = 0;
vel.rotat = 0;
}
12
13
14
15
16
void Behaviour::start()
{
sonar.setListener( check,6 );
}
17
18
19
20
21
void Behavior::stop()
{
sonar.clearListener();
}
22
23
24
25
26
27
28
void Behaviour:: perform()
{
try
{
double val[7], lSonar,rSonar,diff;
bool object = false;
29
30
31
32
33
// Lettura dei valori dei sonar
for (int i = 0; i < 7; i++)
{
val[i] = sonar.get(i);
Appendice
55
// Controllo della presenza di ostacoli
if (!object)
{
object = (val[i] < MIN_DIST_OBJECT);
}
34
35
36
37
38
}
39
40
// Implementazione del controllore per il behaviour Stay In
The Middle
rSonar = val[0];
lSonar = val[6];
diff = rSonar - lSonar;
vel.rotat = diff * K;
41
42
43
44
45
46
if (object)
{
std::cout << "Ostacolo" << std::endl;
vel.trasl = 0;
vel.rotat = 0;
}
else
{
std::cout << "Via libera" << std::endl;
vel.trasl = 0.2;
}
std::cout << ", velicita’: Trasl = " << vel.trasl << " Rotat = "
<< vel.rotat << std::endl;
47
48
49
50
51
52
53
54
55
56
57
58
59
// Invio delle velocita’ per i motori
motor.update(vel);
60
61
}
catch ( EmptySlot e )
{
}
62
63
64
65
66
}
Appendice
B.2
56
Main program
Listato B.3: Main program dell’applicazione.
1
2
3
#include "Unit.h"
#include "Pioneer.h"
#include "Behavioru.h"
4
5
6
7
8
9
int main()
{
try
{
Unit u;
10
Pioneer pioneer(u,"/dev/ttyS1");
11
12
Behaviour behaviour(u);
13
14
u.start();
15
16
std::cin.get();
17
18
u.stop();
19
}
catch (PioneerException& err)
{
std::cout << err.what() << std::endl;
}
20
21
22
23
24
25
return 0;
26
27
}
Appendice C
Tabella comandi PSOS
Nella figura C.1 della pagina seguente sono elencati tutti i comandi supportati dal sistema operativo PSOS (eseguito a bordo del Pioneer ). Questi
comandi vengono inviati dal software client, eseguito su un PC remoto, al
robot mediante una linea seriale RS-232 e permettono il controllo del robot
stesso attraverso la gestione della comunicazione e dei dispositivi a bordo del
robot.
57
Appendice
58
Figura C.1: Comandi del PSOS.
Bibliografia
[1] RIMLab, robotics and intelligent machines laboratory. http://rimlab.
ce.unipr.it/.
[2] ActivMedia, mobile robots & robotics software.
mobilerobots.com/.
http://www.
[3] Player/Stage. http://playerstage.sourceforge.net.
[4] F. Monica. Progettazione di una Architettura Modulare, Aperta ed
in Tempo Reale per un Robot Mobile. Tesi di Laurea in Ingegneria
Informatica, Universit`a degli Studi di Parma, 2003.
[5] D. Lodi Rizzini. Introduzione a Player-Stage. Corso di robotica, 2005.
[6] ActivMedia. Pioneer 1/AT operations manual, ed. 2, 1998.
[7] D. Faccini. Ricerca del massimo comportamento reattivo ottenibile con
il robot mobile pioneer 1. Tesina del corso di robotica, 1999.
[8] D. Pallastrelli. Studio e Realizzazione di un Framework Orientato
agli Oggetti per Applicazioni Real-time. Tesi di Laurea in Ingegneria
Informatica, Universit`a degli Studi di Parma, 2002.
59
Ringraziamenti
Ed eccomi giunto all’ultima pagina di questa tesi.
Ripercorrendo questi ultimi mesi sono tante le persone che dovrei ringraziare per avermi aiutato o, semplicemente, tenuto compagnia nei momenti di
”relax”. Se sono qui a scrivere `e anche merito della lunga serie di eventi che
hanno caratterizzato la mia vita. Ricordare e ringraziare tutte le persone
che sono state determinanti per arrivare a questo importante traguardo non
`e semplice, in ogni caso i miei pi`
u grandi ringraziamenti vanno a tutte loro e
a tutti voi che state leggendo queste parole.
Il primo ringraziamento ufficiale al Prof. Caselli, il mio relatore, per
avermi dato la possibilit`a di svolgere questa tesi e per il grande aiuto durante la scrittura di questo elaborato, che ha rappresentato il momento pi`
u
impegnativo di tutto il lavoro svolto.
Un altro importante ringraziamento va all’Ing. Francesco Monica per i
numerosi e preziosi consigli ricevuti durante tutto lo svolgimento della tesi e
per avermi aiutato in quei momenti quando il suo intervento risolveva velocemente tutti i problemi. Il ringraziamento diventa un amichevole ”grazie”
nel momento in cui mi rivolgo all’amico Francesco e con lui a Dario, Jacopo, Monica, Massimo, Michele, Eleonora, Rosa, Chiara, Bruno e a tutte
le persone che ho conosciuto all’interno del Laboratorio di Robotica e della
Palazzina 1.
Ringrazio tutti i compagni di corso conosciuti in questi tre splendidi anni;
grazie a Daniele, Andrea e Pietro per le lunghe chiacchierate fatte durante
i tragitti di spola tra Reggio Emilia e Parma. Grazie a Enrico, Fabio, Mattia, Stefano e Fabio per aver condiviso felicemente gli anni delle superiori e
dell’universit`a.
Grazie a tutti gli amici che ho conosciuto dall’asilo nido fino ad oggi, in
particolare grazie a Francesco e Andrea per essere sempre stati presenti in
questi anni. Grazie a tutti gli amici della compagnia di San Prospero soprattutto per le ultime vacanze estive che hanno permesso di prendermi un
periodo di pausa durante questo impegnativo lavoro.
60
Ringraziamenti
61
Grazie ai miei Genitori, e con loro alla mia ”sorellina” Susanna, per avermi sempre dato fiducia, amore, affetto e aiuto in ogni occasione, per non
aver mai dubitato nelle mie capacit`a. Ringrazio tutti i componenti della mia
famiglia partendo dai Nonni, arrivando agli Zii e ai Cugini.
GRAZIE A TUTTI!