1. UNIVERSIT DEGLI STUDI DI TRIESTE Facolt di Ingegneria Corso
di laurea in Ingegneria Informatica PROVA FINALE IN SISTEMI
OPERATIVI REALIZZAZIONE HARDWARE E SOFTWARE DI UN ROBOT MOBILE DI
SERVIZIO Relatore: Laureando: Chiar.mo Prof. Enzo Mumolo Basilio
Marco Matessi Anno Accademico 2009-2010
2. Alla mia famiglia
3. Indice Capitolo 1 -
Introduzione......................................................................................................................5
Capitolo 2 -La robotica mobile e di
servizio........................................................................................6
2.1 Robot
mobile..............................................................................................................................6
2.2 Robot di
servizio........................................................................................................................7
Capitolo 3 -Struttura hardware del
robot:.............................................................................................8
3.1 Parte
meccanica.........................................................................................................................
8 3.2 Parte
elettronica.......................................................................................................................
10 Capitolo 4 -Progetto software del
robot:............................................................................................
18 4.1 Il Sistema
Operativo................................................................................................................
18 4.2 La
preparazione........................................................................................................................18
4.3 Deployment del sistema
operativo...........................................................................................22
Capitolo 5 -Il
progetto........................................................................................................................
24 5.1 Larchitettura
generale.............................................................................................................
24 5.2 I task
RTAI...............................................................................................................................24
5.3 Le FIFO e la Comunicazione
Interprocesso............................................................................
26 5.4 Il collegamento elettrico delle varie parti del
robot.................................................................27
Capitolo 6 -I task
RealTime................................................................................................................30
6.1 Il modulo RTAI per la gestione dei
MOTORI.........................................................................
30 6.2 Il modulo RTAI per la gestione dei sensori
ODOMETRICI................................................... 31
6.3 Il modulo RTAI per la gestione del sensore ad
ultrasuoni.......................................................36
Capitolo 7 -Applicazioni
realizzate:...................................................................................................37
7.1 Debug dei task
real-time..........................................................................................................37
7.2 Il modello
cognitivo.................................................................................................................37
7.3 Random
Walk...........................................................................................................................38
Capitolo 8 -Conclusioni
.....................................................................................................................41
Capitolo 9
-Appendici........................................................................................................................
42 9.1
Redboot....................................................................................................................................42
9.2 Setup e configurazione di un server
NFS................................................................................
43 9.3 Yaffs
File-System.....................................................................................................................44
9.4 Ripristino del file-system
preinstallato....................................................................................45
Capitolo 10
-Bibliografia:...................................................................................................................47
4. Capitolo 1 - Introduzione Capitolo 1 - Introduzione La
robotica mobile di servizio un campo di grande interesse sia
teorico che applicativo e in grande sviluppo. Lo scopo di un robot
mobile di questo tipo quello di sviluppare un sistema autonomo che
realizzi un servizio utile all'uomo. Per questo scopo sono
importanti diversi aspetti. Per citarne alcuni, importante che il
sistema possa interagire con l'uomo usando qualche canale di
comunicazione comune, per esempio quello acustico; altres
necessario che il robot possa evitare gli ostacoli che si possono
presentare durante il suo cammino; anche importante che, nel caso
in cui si abbia una flottiglia di robot, i robot possano comunicare
fra di essi usando un canale accessibile all'uomo in modo da
condividere i messaggi tra robot ed esseri umani. Seguendo l'idea
di far muovere una flotta di robot in un ambiente umano, allo scopo
evidentemente di realizzare qualche servizio, ci si posti il
problema di realizzare una flottiglia di robot olonomi con
l'obiettivo di dotarli di sensori acustici in modo tale che sia i
robot possono dialogare fra di essi attraverso il canale acustico e
che i messaggi possano essere compresi anche dagli esseri umani
presenti nell'ambiente. L'obiettivo descritto abbastanza ambizioso.
In questa tesi stato sviluppato un robot prototipale che si potr
duplicare in un secondo tempo in diversi esemplari per realizzare
una flotta di robot mobili necessaria per sviluppare la
comunicazione acustica con array microfonici e altoparlanti
omnidirezionali. Nel progetto si anche cercato di scegliere
soluzioni a costo moderato. In definitiva si optato per una
semplice piattaforma robotica due ruote motrici e due ruote pivot,
con sensori ad ultrasuoni ed una scheda ARM per fornire sia i
controlli per i motori e le interazioni con i sensori. Il sistema
operativo del sistema Linux con estensione Real Time. Sul prototipo
stata sviluppata una architettura cognitiva a priorit per la
gestione dei sensori e del comportamento del robot. Oltre ad alcuni
programmi di test dei motori e dei sensori, stato sviluppato un
programma di gestione del robot nella modalit 'random walk' nella
quale il robot esplora a caso schivando gli ostacoli. Tale modalit
potrebbe essere alla base dei robot rasaerba o dei robot che
puliscono il pavimento Questa tesi organizzata nel seguente modo:
nei capitoli 3 e 4 si descrivono rispettivamente le parti hardware
e software, nel capitolo 5 e 6 l'architettura del sistema robotico
e i moduli in tempo reale per la generazione del segnale PWM dei
motori e la lettura dei sensori ad ultrasuoni. Il capitolo 7,
infine, descrive l'applicazione RandomWalk realizzata. 5
5. Capitolo 2 - La robotica mobile e di servizio Capitolo 2 -
La robotica mobile e di servizio Nel linguaggio comune, un robot
un'apparecchiatura che esegue compiti automatizzati tramite una
supervisione diretta dell'uomo o per un programma predefinito,
usando tecniche di intelligenza artificiale. Per eseguire questi
compiti il robot deve essere composto da almeno questi tre elementi
principali: i sensori, cio i dispositivi che il robot usa per
osservare l'ambiente circostante: telecamere, sensori a ultrasuoni
o a infrarossi, sensori di contatto, GPS, ecc. ; l'unit di governo,
che si occupa di interpretare i dati forniti dai sensori e di
stabilire le azioni da compiere: in genere si tratta di uno o pi
calcolatori che eseguono programmi appositi. E' qui che si trova
l'intelligenza del robot; gli attuatori, cio i dispositivi che il
robot usa per svolgere fisicamente le azioni sull'ambiente (ad
esempio spostarsi o afferrare un oggetto) decise dall'unit di
governo. 2.1 Robot mobile Per robot mobile si intende un sistema
meccatronico in grado di muoversi intelligentemente in ambienti
terrestri, marini o aerei, riuscendo ad orientarsi e a reagire ad
eventuali ostacoli. Una importante differenza tra robot mobili la
classificazione secondo la tipologia di attuatori utilizzata per
muoversi, principalmente nei robot terrestri troviamo quelli
bastati su ruote e quelli basati su gambe che vengono definiti
solitamente umanoidi. I robot su gambe sono delle macchine i cui
movimenti prendono spunto da quelle delle articolazioni umane, e
sono pensati per quegli ambiti dove i robot devono essere
strettamente integrati in un ambiente umano, si pensi ad esempio ad
un robot che deve salire e scendere dalle scale, questa situazione
godrebbe indubbi vantaggi rispetto alle ruote. Nello studio si
limitato lo studio ai robot su ruote (rover), che rappresentano la
classe pi numerosa di applicazioni, data la semplicit costruttiva
che li caratterizza. I robot ruotati sono pensati per rimanere
stabili sui terreni sui quali si muovono, la loro stabilit sul
terreno caratterizzata dalla presenza di almeno tre ruote. Spesso i
robot mobili sono anche autonomi, come quello discusso in questa
tesi, con questo termine si intendono due propriet: l'autonomia
relativa alle fonti di energia: queste possono essere collocate a
bordo, e allora il robot detto autonomo (rispetto alle fonti di
energia), oppure a terra e collegato ai vari azionamenti di bordo
mediante un cavo, e allora il robot detto non autonomo (rispetto
alle fonti di energia); l'autonomia relativa alle unit di
elaborazione e calcolo (la cosiddetta intelligenza"), queste
possono essere collocate a bordo, oppure no. Nel primo caso il
robot autonomo (rispetto all'elaborazione), nel secondo no. 6
6. Capitolo 2 - La robotica mobile e di servizio 2.2 Robot di
servizio Per robot di servizio si intende una apparecchiatura in
grado di rimpiazzare o migliorare il lavoro dell'umano, in quelle
operazioni sgradevoli o ripetitive della vita quotidiana.
L'evoluzione della robotica negli anni ha avuto origine dalla
risposta a un bisogno dell'uomo di macchine utili che lo aiutassero
nel lavoro fisico. La robotica si sviluppata infatti principalmente
come robotica industriale e ha tuttora una sua linea di sviluppo e
di progresso molto avanzata nell'automazione industriale. Il
successo e il progresso tecnologico conseguiti in campo industriale
hanno incoraggiato lo sviluppo di robot da utilizzare anche al di
fuori della fabbrica, cio i cosiddetti robot di servizio. cos nata
l'area della robotica per applicazioni in ambienti ostili all'uomo,
come lo spazio, gli ambienti sottomarini, o in compiti pericolosi
come nel caso di robot artificieri o di robot utilizzati in
operazioni di soccorso. Tra le applicazioni della robotica di
servizio sono di grande e sempre maggiore rilevanza quelle
biomediche, nell'ambito delle quali vengono studiati e sviluppati
vari tipi di robot per chirurgia, per la riabilitazione e per
l'assistenza a persone disabili e anziane. Quest'ultimo tipo di
applicazione sta rendendo oggi sempre pi realistica l'idea del
personal robot, un robot il cui scopo primario sia quello
dell'assistenza personale. 7
7. Capitolo 3 - Struttura hardware del robot: Capitolo 3 -
Struttura hardware del robot: 3.1 Parte meccanica Un robot mobile
su ruote consiste essenzialmente di un telaio rigido o semi-rigido
sul quale vengono sistemate in modo opportuno una o pi ruote, allo
scopo di sospendere il telaio rispetto al suolo e consentirne la
locomozione. I robot in questione composto da una piattaforma a
disco che sostenuta da quattro ruote fissate in modo ortogonale al
piano, in modo da formare un quadriciclo. Due di queste sono
motorizzate e non sterzanti, mentre la restanti due sono
pivottanti. La direzione ottenuta comandando in modo opportuno i
motori, anche con velocit e direzioni differenti. I due motori
elettrici sono comandati tramite un segnale PWM. Al di sopra del
disco troviamo invece tutta la logica elettronica e l'alloggiamento
per le batterie. La base utilizzata chiamata REX ed stata prodotta
dalla Zagor Robotics1 . Tale base di tipo multi-livello, ed
possibile aggiungere dei livelli all'aumentare della complessit e
delle funzionalit del robot. In questo caso sulla struttura stato
montato un secondo piano, alla quale sono stati montati sei sensori
ultra-suoni. I sensori sono disposti sul piano come illustrato
nella figura seguente, quelli di colore verde sono collegati
elettricamente, mentre quelli rossi non sono collegati per
limitazioni hardware successivamente approfondite. Potendo
utilizzare solo quattro sensori si cercato di utilizzare quelli pi
utili, i sensori uno, due e tre vengono utilizzati per la marcia in
avanti, mentre il sensore quattro viene usato per le manovre di
retro-marcia. 1 www.zagrosrobotics.com 8
8. Capitolo 3 - Struttura hardware del robot: 9 2 3 4 5 6
motoreB motoreA LEGENDA: Base del robot Sonar collegati Sonar non
collegati Ruote motrici Ruote Pivot
9. Capitolo 3 - Struttura hardware del robot: 3.2 Parte
elettronica Il robot dotato di una scheda a microprocessore che
mediante l'integrazione dei sensori in grado di comandare in
maniera autonoma gli attuatori, in modo da svolgere il programma
desiderato. I sensori implementati sono sensori di prossimit per
l'orientamento del robot e sensori odometrici, per il controllo dei
motori. 3.2.1 La scelta della piattaforma hardware Per applicazioni
di questo tipo solitamente viene utilizzato un micro-controllore,
sia per questioni di costo, dimensioni, consumi, praticit. Invece
per questo progetto si deciso di utilizzare una scheda a
micro-processore in quanto questo ha permesso di realizzare un
progetto espandibile, e volendo anche molto complesso in quanto le
capacit di calcolo sono molto pi elevate. La scelta ricaduta sulla
scheda TS-7250 della Tecnologic System2 , una piattaforma dotata di
numerose porte di Digital I/O. Per quanto riguarda la
programmazione ci sono stati notevoli vantaggi rispetto
all'utilizzo di un microcontrollore in quanto il metodo di
caricamento dei programmi da pc risultato molto immediato; esso pu
avviene a caldo tramite svariate interfacce come seriale, ethernet,
wi-fi e pendrive, senza dover caricare manualmente di volta in
volta il programma un programmatore. La piattaforma scelta inoltre
pienamente compatibile con il sistema operativo Linux, questo ha
dato grande vantaggio allo sviluppo del progetto grazie alla
disponibilit di applicazioni e librerie gi pronte. 3.2.2
L'alimentazione Il robot alimentato tramite due batterie al
piombo-gel da 12V, una da 10Ah e una da 2,2Ah. Quella pi grande
stata utilizzata per l'alimentazione dei motori, mentre l'altra
stata collegata alla logica digitale tramite un regolatore di
tensione IP7805 in grado di fornire stabilmente una differenza di
potenziale di +5V. Per questioni di sicurezza sono state utilizzate
due batterie separate in modo da evitare che la logica potesse
ricevere degli sbalzi di tensione causati dall'assorbimento dei
motori. 3.2.3 I sensori di prossimit Tali sensori servono al robot
per rilevare gli oggetti a lui vicini, e a poter prendere decisioni
opportune. Ad esempio se dovesse trovare degli ostacoli o dei
pericoli lungo la sua traiettoria il robot dovrebbe essere in grado
di rilevarli e aggirarli, o eventualmente cercare un percorso
alternativo. In questo progetto sono stati utilizzati sensori ad
ultra-suoni che hanno una portata massima di 10 metri. I sensori ad
ultrasuoni si basano sul principio del Sonar, emettono impulsi
sonori ultrasonici, e 2 www.embeddedarm.com 10
10. Capitolo 3 - Struttura hardware del robot: rilevano
un'eventuale eco di ritorno generata dalla presenza di un oggetto
all'interno della portata nominale. In questo progetto, per
questioni di tempo stata implementata solo una tipologia di sensori
di prossimit, in futuro la struttura potr essere espansa con gli
altri sensori, da usare assieme in modo simultaneo in modo da avere
un feed-back migliore. In particolare su questa scheda ARM potranno
essere facilmente integrati dei sensori ottici operanti con logica
di tipo analogica, in quanto sono disponibili ed inutilizzate
alcune interfacce analogiche. I sensori ottici si basano sulla
rilevazione della riflessione di un fascio luminoso da parte
dell'oggetto rilevato. I sensori ottici sono di tipo infrarosso in
quanto questa radiazione difficilmente si confonde con i disturbi
generati da fonti luminose ambientali. Questi sensori hanno un
range di funzionamento pi limitato, solitamente fino a 100 cm, ma
solitamente forniscono delle misurazioni migliori. Volendo proprio
completare il progetto ed avere dei sensori in grado di coprire la
breve, media e lunga distanza si potrebbero integrare i sensori di
tipo dumer, dispositivi che hanno la propriet di poter determinare
se la sua superficie soggetta a pressione; per rilevare se il robot
ha urtato qualcosa. 3.2.4 Sensori odometrici Tali sensori sono
collegati direttamente ai motori e servono per controllarne il
corretto funzionamento. I sensori odometrici sono collegati
all'albero dei motori e forniscono alla CPU il numero di giri per
minuto e la direzione in cui i motori stanno girando (orario od
antiorario). L'utilizzo dei sensori odometrici potrebbe essere
superfluo in condizioni ideali, infatti modulando correttamente la
potenza fornita ai motori la CPU dovrebbe conoscere gli spostamenti
effettuati, ma in condizioni reali e quindi imprevedibili, tali
sensori sono fondamentali, si pensi ad esempio se il robot dovesse
affrontare una salita in cui la resa dei motori dovesse variare, in
questo caso una stima degli spostamenti fatta sulla potenza fornita
ai motori si rivelerebbe errata, mentre quella ottenuta dalla
lettura tramite i sensori odometrici sarebbe molto pi utile e
veritiera. 3.2.5 I motori Sulla piattaforma sono stati montati due
motori elettrici a corrente continua a cui sono state fissate le
due ruote di movimento. Tali motori vengono pilotati tramite un
segnale PWM (Pulse Width Modulation), un'onda quadra che permette
di controllare l'assorbimento di un carico elettrico (nel nostro
caso il motore DC), variando (modulando) il duty cycle. 11
11. Capitolo 3 - Struttura hardware del robot: I due motori
sono collegati alla scheda principale tramite una interfaccia che
stata realizzata e progettata in laboratorio. Essenzialmente essa
composta su un circuito opto-isolatore e un driver per i motori. Il
circuito opto-isolatore stato implementato per motivi di sicurezza
in modo da ottenere un isolamento galvanico tra la logica digitale
e quella di potenza necessaria al movimento dei motori. 12
12. Capitolo 3 - Struttura hardware del robot: 3.2.6 Schema a
blocchi: 3.2.7 Il materiale utilizzato Sistema embedded TS-7250
della Technologic Systems Sensori ultrasuoni Devantech SRF005
Sensori Odometrici HEDS-5505 della Agilent Technologies Motori
M455M63 della Globe Motors Technologic System TS-7250 Il TS-7250 un
sistema embedded basato su un chip Cirrus Logic con core ARM9:
lEP9302. Questo chip a basso consumo include nel suo package un
processore ARM920T funzionante a 200Mhz e una serie di periferiche
standard come quelle USB o Ethernet e linee di digital I/O. La
caratteristica che rende appetibile questo sistema per la robotica
il basso consumo (circa 2 3 W) e la disponibilit di una moltitudine
di periferiche on-board. 13 ARM OPTO-ISOLATORE DRIVER Ponte H
MOTORI interfaccia I/OULTRA SUONI ODOMETRIA I/O I/O
13. Capitolo 3 - Struttura hardware del robot: Devantech SRF005
Il sensore SRF005 un sensore distanziometrico a ultrasuoni che
integra gi un microcontrollore che gestisce la generazione degli
impulsi e la loro rilevazione. E controllabile tramite delle porte
di Digital I/O (DIO). La sua portata di circa 4 metri con una
precisione dellordine del centimetro. Sensori odometrici HEDS-5505
I sensori odometrici sono atti a rilevare il verso e la velocit di
rotazione dellasse di un motore. Questo modello in particolare usa
una tecnologia ottica a quadratura. Ogni sensore si collega
direttamente a due porte di digital I/O sulle quali vengono
trasmessi due segnali sfasati di 90. Grazie a questi segnali si pu
determinare il movimento del motore. Motori M455M63 Questi motori
vengono utilizzati per muovere le ruote del robot, e vengono
comandati tramite la scheda di interfaccia. 3.2.8 Scheda di
interfaccia motori (progetto e realizzazione) La scheda stata
realizzata in laboratorio per soddisfare le esigenze del progetto.
14
14. Capitolo 3 - Struttura hardware del robot: Era necessario
un circuito che permettesse di isolare galvanicamente la scheda ARM
dai motori e che contenesse anche il driver per i motori.
L'interfaccia stata prima studiata e realizzata su bread-board, ed
in seguito una volta verificato il corretto funzionamento si
realizzato il circuito stampato. La scheda basata sul seguente
schema: Le porte di I/O sono direttamente pilotate dal processore
ARM Cirrus Logic EP9302-CQZ, lavorano con logica compresa tra 0 e
3.3 Volt, e quando sono configurate come uscite possono fornire
massimo 4mA. Tali porte sono state utilizzate per comandare i
motori, ma per tenere separate le correnti tra la logica della
scheda ARM, e quella dei motori, si scelto di interporre tra di
essi un opto- accoppiatore (TLP521-4), e due circuiti integrati
7400 che fungono da buffer. I circuiti integrati 7400 dispongono di
4 porte NAND e lavorano con logica TTL, ma sono utilizzati in modo
da operare come porte NOT, unendo gli ingressi NAND. I due
integrati operano sostanzialmente da buffer, in quanto le porte
digitali della scheda ARM configurate come uscite digitali sono in
grado di erogare 4mA ciascuna, mente l'assorbimento delle linee
dell'opto-isolatore sono di 10mA. La parte di isolazione stata
utilizzata anche in modo da poter invertire i segnali della logica
di funzionamento, in modo da funzionare come una porta NOT. Tale
scelta stata operata perch la scheda ARM all'accensione presentava
dei segnali posti con livello logico alto, e senza questo
accorgimento il robot fino alla sua inizializzazione sarebbe stato
15
15. Capitolo 3 - Struttura hardware del robot: libero di
muoversi privo di controllo. Per pilotare i motori si utilizzato il
circuito integrato SN754410, che contiene al suo interno due ponti
H, prendendo come riferimento l'applicazione del controller Wirz
203. Il Wirz 203 un circuito amplificatore che serve per modulare
la tensione fornita ai motori allo scopo di poter regolare la
velocit di rotazione degli stessi. Questo circuito dispone di due
controlli motori indipendenti che vengono pilotati tramite due
coppie di porte di digital I/O. Il ponte H un circuito che permette
di invertire la rotazione dei motori. Nell'immagine ho mostrato in
modo semplificato il principio di funzionamento: Inoltre si deciso
di integrare sul circuito anche un regolatore di tensione che
permettesse di ottenere 5 volt a partire dai 12 volt della
batteria. Tale regolatore usato sia per alimentare l'interfaccia
sia la scheda ARM. Tale regolatore utilizza l'integrato IP7805, un
regolatore di tensione di precisione a che livella la tensione a +5
volt. Tra le caratteristiche di questo integrato troviamo la
possibilit di riuscire ad erogare fino a 1 Ampere, la protezione
termica per sovraccarico, e la protezione per il corto-circuito.
Per il disegno del circuito stampato su utilizzato il software
Design Spark3 , mentre per la realizzazione ci si appoggiati ad una
ditta esterna. Nell'immagine seguente possibile vedere lo schema
elettrico dell'interfaccia: 3 www.designspark.com 16 Attivando i
transistor A1 e B2 la corrente scorre nel motore in un verso mentre
attivando i transistor B1 e A2 la corrente scorre nel verso
opposto. E' da evitare la configurazione in cui sono accesi
entrambi i transistor A o entrambi i transistor B infatti la
corrente di corto circuito su un lato del ponte potrebbe creare
seri danni al ponte stesso o al circuito di alimentazione.
16. Capitolo 3 - Struttura hardware del robot: Schema completo:
17
17. Capitolo 4 - Progetto software del robot: Capitolo 4 -
Progetto software del robot: 4.1 Il Sistema Operativo La
Technologic System supporta per la TS-7250 GNU/Linux, WinCE e
Netbsd. La scheda viene precaricata dalla fabbrica con una
distribuzione Debian minimale (TS-Linux), basata su kernel linux
2.4, realizzata dal produttore stesso. 4.1.1 La scelta del sistema
operativo Uno dei criteri di scelta del sistema operativo, oltre
costo e supporto per il nostro hardware, stata la possibilit di
soddisfare i requisisti imposti dal nostro progetto. Tra questi
requisiti vi era per esempio la necessit di rispondere rapidamente
ai dati sensoriali che elabora, per esempio, al fine di evitare la
collisione con oggetti o persone nellambiente in cui si muove. Per
questo motivo un sistema operativo real-time solitamente
preferibile per lo sviluppo di sistemi robotici. Nellambito dei
sistemi operativi real-time utilizzabili che siano supportati e che
non siano commerciali, si deciso di usare una distribuzione
GNU/Linux con estensioni real-time. 4.1.2 The Real-time Application
Interface (RTAI) RTAI si presenta come una patch per il kernel
Linux e una serie di librerie di supporto per lo sviluppo. La patch
introduce, tramite le HAL (Hardware Abstraction Layer) del kernel,
un nuovo schedulatore che programma i processi in real-time (task)
in maniera precisa e deterministica. Questultimo considera il
kernel Linux come un idle task eseguendolo quando il kernel
real-time non attivo. Il task Linux, inoltre, non pu mai bloccare
gli interrupt o impedire di essere interrotto nella sua esecuzione
(being preempted). RTAI stato sviluppato dal Dipartimento di
Ingegneria Aerospaziale del Politecnico di Milano ed liberamente
utilizzabile. 4.2 La preparazione 4.2.1 Il bootloader Sulla TS-7250
precaricato un bootloader basato su eCos4 , un sistema operativo
real-time minimale per sistemi embedded. Questo bootloader si
chiama RedBoot5 (Red Hat Embedded Debug and Boot strap firmware) ed
stato utilizzato nel nostro progetto per il caricamento
dellimmagine del kernel, per la sua esecuzione e per scrivere
limmagine stessa sulla memoria flash della scheda. RedBoot un
bootloader, che non viene usato solo su piattaforme di questo tipo
di piattaforme, ma viene utilizzato da molti altri dispositivi
embedded come router, palmari e console da gioco. Per questioni di
praticit, a tal proposito, sono stati realizzati due script di
avvio separati per Redboot: uno utilizzato in fase di sviluppo, ed
uno per il sistema finale dimostrativo. Per quanto riguarda
lutilizzo di Redboot si provveduto a riportare nel testo, quando
necessario, i comandi utilizzati. 4 www.ecos.sourceware.org 5
www.sourceware.org/redboot 18
18. Capitolo 4 - Progetto software del robot: Per ulteriori
dettagli su Redboot sono stati scritti degli approfondimenti
nellappendice. 4.2.2 Scelta della GNU Cross-Platform Toolchain Per
poter compilare un codice valido per la nostra piattaforma robotica
si dovuta utilizzare di una cross-platform toolchain, cio di un
insieme di programmi e librerie necessari per la compilazione e la
generazione di eseguibili per una piattaforma diversa da quella su
cui essa viene usata. A questo scopo il produttore della scheda
fornisce sul suo repository ftp6 gi una gamma di toolchain di cui
si scelto di utilizzare, in particolare, la
crosstool-linux-gcc-3.3.4-glibc-2.3.2- 0.28rc39. 4.2.3 Preparazione
del kernel Una volta recuperati i sorgenti del kernel
tskernel-2.4.26-ts11 si provveduto ad applicare la patch adeos
rttskernel-2.4.26-tsX-adeos.patch per lestensione real-time,
disponibile sempre nel ftp della Technologic System. Questa patch
consiste in uno script di modifica dei sorgenti del kernel atto ad
introdurre le nuove funzionalit necessarie per trasformarlo in un
Sistema Operativo real-time. Prima di poter applicare la suddetta
patch, stato necessario definire al suo interno alcune
informazioni, in modo che la stessa venga applicata con successo.
In particolare, si sono modificate le righe che specificano la
versione di kernel su cui applicare la patch e il prefisso del
cross- compilatore che si ha intenzione di utilizzare. Nella
fattispecie, sono state aggiunte/rimosse le seguenti righe:
-EXTRAVERSION =-ts11 +EXTRAVERSION =-ts11-rt +CROSS_COMPILE =
/tools/crosstool/arm-9tdmi-linux-
gnu/gcc-3.3.4-glibc-2.3.2/bin/arm-9tdmi-linux-gnu- +DEPMOD=
/bin/true E stato, poi, bypassato lutilizzo del comando depmod
sostituendolo con /bin/true in quanto non in grado di gestire la
cross-compilazione. E stata quindi applicata la patch con il
comando: patch -p1 -b < ./../rt-tskernel-2.4.26-ts11-
adeos.patch Si passati quindi a modificare il Makefile del kernel
assicurando che le seguenti variabili fossero correttamente
impostate. ARCH := arm CROSS_COMPILE =
/tools/crosstool/arm-9tdmi-linux-
gnu/gcc-3.3.4-glibc-2.3.2/bin/arm-9tdmi-linux-gnu- DEPMOD =
/bin/true 6 ftp.embeddedarm.com 19
19. Capitolo 4 - Progetto software del robot: 4.2.4
Configurazione del kernel La configurazione del kernel essenziale
per far riconoscere ed utilizzare al sistema operativo le
periferiche del sistema. Tale operazione avviene attraverso degli
script di configurazione e un menu visuale in cui lutente pu
scegliere direttamente lhardware che vuol fargli supportare. In tal
senso la Technologic System ha provveduto a fornire, insieme ai
sorgenti del suo kernel, pi script di configurazione per il loro
hardware. Questo avrebbe, in teoria, dovuto rendere questa
operazione abbastanza semplice. Tuttavia una modifica nella
tipologia di flash montata sulla scheda (una variazione nella
dimensione dei blocchi di memoria) ha creato non pochi problemi
nella configurazione del kernel stesso. Il driver YAFFS, indicato
nella configurazione del sistema che si voleva utilizzare, non
supporta il tipo di flash memory con blocchi da 512byte e per
questo impediva le operazione di scrittura sulla flash della
scheda. Per questo motivo nella configurazione del kernel di
notevole importanza assicurarsi del tipo di flash presente sulla
scheda e utilizzare uno dei due seguenti script di configurazione
per il suo corretto funzionamento. ts7250_config per memoria con
blocchi da 512byte ts7250_2k_config per memoria con blocchi da
2kbyte Quindi per una corretta configurazione del kernel per
lhardware utilizzato si deve eseguire i seguenti comandi: make
[ts7250_config|ts7250_2k_config] per configurare le periferiche
della scheda make oldconfig per configurare il supporto RTAI
attivando quando richiesto solamente attivando solamente ADEOS e
ADEOS DOMAINS ARE THREAD e quindi make dep make menuconfig A questo
punto sar possibile visualizzare la configurazione finora impostata
ed eventualmente integrare il supporto per altre periferiche. Nel
nostro caso in specifico i seguenti moduli sono stati
attivati/integrati: Loadable module support Kernel module loader
20
20. Capitolo 4 - Progetto software del robot: System Type
EP9301 Options EP9301 Internal DMA Support Plug and Play
configuration Plug and Play support ISA Plug and Play support Sound
Sound support OSS sound modules Verbose initialisation USB support
USB verbose debug messages USB Audio support 4.2.5 Compilazione del
kernel Per compilare il kernel si possono quindi eseguire i comandi
make make zImage make modules make modules_install
INSTALL_MOD_PATH= A questo punto si ha a disposizione nella
directory ./arch/arm/boot/ limmagine del kernel da installare nella
scheda e (nella cartella specificata dalla variabile
INSTALL_MOD_PATH) i moduli del kernel da inserire nel file system
della scheda arm. 4.2.6 Compilazione dei moduli rtai Si usata la
versione di RTAI 3.2 (magma) che quella ufficialmente supportata
dalla Technologic System. Prima della compilazione pu essere
necessario modificare il codice sorgente per evitare linsorgere di
problemi durante la configurazione. Nel file
rtai-3.2/base/config/kconfig/mconf.c alla riga 91 bisogna togliere
lattributo statico alla variabile current_menu Fatto ci si prosegue
nella compilazione con i seguenti comandi: 21
21. Capitolo 4 - Progetto software del robot: make ARCH=arm
CROSS_COMPILE=/tools/crosstool/arm-9tdmi-linux-
gnu/gcc-3.3.4-glibc-2.3.2/bin/arm-9tdmi-linux-gnu- make install Nel
menu di configurazione bisogna prestare attenzione a selezionare il
giusto path ai sorgenti del kernel che si compilato
precedentemente. E inoltre conveniente specificare il percorso tipo
/usr/realtime dove verr effettuata la build da spostare nella
board. NOTA IMPORTANTE: E necessario ricompilare rtai ogni
qualvolta sia STATO ricompilato il kernel 4.2.7 Preparazione del
file-system Per la prepazione del file-system del nostro sistema
embedded si partiti dal file-system originale, precaricato nella
flash, al quale si sono aggiunti i moduli e le librerie necessarie
per il funzionamento RTAI. In particolare: I moduli del kernel
vanno copiati nella directory /lib/modules del root file-system di
destinazione. I moduli RTAI vanno copiati preferibilmente dentro
/usr/realtime. Il contenuto della build di player stata copiata
integralmente dentro /usr/local/ Le librerie richieste da player
(libpthread, libsdtc++ e libtools) sono state copiate nella
directory /usr/lib/ Tutti i percorsi qui menzionati sono relativi
alla root del file system della scheda arm. 4.3 Deployment del
sistema operativo Per poter utilizzare il file-system da noi
preparato necessario passare il device che lo contiene come
parametro allesecuzione del kernel. Questo si pu effettuare
modificando lo script di avvio del sistema operativo, nel
bootloader. Durante lo sviluppo di questo progetto, come gi
menzionato nellintroduzione, sono stati utilizzati due modi per
caricare il file-system. 4.3.1 Il sistema di sviluppo Il primo modo
di sviluppo prevede la condivisione del root file-system tramite
una seconda macchina di sviluppo. Grazie a ci, non stato necessario
aggiornare di continuo il file-system presente sulla flash della
scheda ad ogni modifica delle librerie o dei moduli sviluppata.
Inoltre, tale approccio non ci ha vincolato alla dimensioni della
flash. Questo stato realizzato utilizzando una condivisione nfs
contentente il file-system che stato creato (maggiori dettagli a
questo proposito vengono forniti in appendice) e provvedendo a
modificare i parametri del comando exec dello script di caricamento
del kernel nel bootloader. In particolare stato rimosso il
parametro root ed stato aggiunto il parametro nfsroot come segue:
22
22. Capitolo 4 - Progetto software del robot: exec c
"console=ttyAM0,115200 ip= nfsroot=:" dove lip del server che fa da
host al servizio nfs il nome della condivisione nfs contenente il
root file system da usare 4.3.2 Il sistema di Produzione Il sistema
di produzione indipendente da altre macchine. Anzi, non previsto
sia collegato in rete ad alcuna altra macchina. Deve quindi
caricare il file-system dalla memoria flash integrata nella scheda.
Per caricare il file-system sulla scheda necessario seguire la
procedura per il ripristino del file- system specificata
nellappendice. C da considerare, inoltre, un problema riguardante
le dimensione del file-system stesso. La scheda a nostra
disposizione monta una memoria flash troppo piccola (32MB) rispetto
la dimensione necessaria a ospitare tutte le librerie che
potrebbero essere necessarie. Si deciso quindi di dividere il
file-system spostando il contenuto di /usr su una memoria flash
esterna da collegare alla scheda tramite porta USB. Per fare ci si
partizionata e formattata questultima con un file-system ext3 (con
il comando mkfs). A questo punto non rimasto che copiare al suo
interno la cartella /usr e fare il mount della stessa sul sistema
con i seguenti comandi. /usr/bin/loadUSBModules.sh Per caricare i
moduli di gestione dellUSB. mount -t auto
/dev/scsi/host0/bus0/target0/lun0/part1 /usr Per fare il mount
della prima partizione della chiavetta USB. E tuttavia
consigliabile salvare il primo script in /etc/init.d e richiamarlo
con un link simbolico in /etc/rc.d/rc3.d/ e aggiungere nel file
/etc/fstab la seguente riga:
/dev/scsi/host0/bus0/target0/lun0/part1 ext3 /usr Infine sar
necessario modificare la linea di avvio del kernel nello script di
avvio del bootloader nel seguente modo: exec c
"console=ttyAM0,115200 root=/dev/mtdblock1" 23
23. Capitolo 5 - Il progetto Capitolo 5 - Il progetto 5.1
Larchitettura generale Sono stati realizzati sei task real-time
atti a leggere le informazioni dai sensori ultrasuoni e degli
odometri e al comando dei motori. Quattro per i sonar e uno per gli
odometri e uno per il motore. Questi task lavorano in kernel space,
e per dialogare con il programma di gestione che lavora in user
space utilizzano le FIFO di sistema. Tale architettura viene
illustrata nel seguente diagramma: 5.2 I task RTAI I task RTAI
sono, in pratica, dei moduli del kernel linux che fanno uso di
caratteristiche speciali tipiche dei sistemi operativi real-time
introdotte da RTAI. I moduli del kernel linux Un modulo del kernel
linux una porzione di codice che pu essere aggiunta al kernel linux
durante la sua esecuzione. Uno dei vantaggi principali di questa
caratteristica che non necessario ricompilare lintero kernel del
sistema operativo ogniqualvolta si voglia far supportare al sistema
operativo un nuovo dispositivo hardware o implementarne una nuova
funzionalit. Il gestore che permette il caricamento di moduli in
run-time si chiama Loadable Kernel Module (LKM) e introduce diverse
categorie di moduli (o meglio di servizi) caricabili: Driver per
periferiche, Driver per file-system, Driver di rete, Moduli per
definire nuove chiamate a sistema o per ridefinirne quelle
esistenti, Nuovi interpreti per eseguibili. E importante sapere che
i moduli del kernel, essendo eseguiti in kernel-space, 24 Task
Sonar 1 Task Sonar 2 Task Motori FIFO Programma di gestione Task
Sonar 3 Task Sonar 4 Task Odometria Kernel space User space RTAI
Scheduler LINUX Scheduler
24. Capitolo 5 - Il progetto NON possono: Usare funzioni della
libreria standard C, Usare aritmetiche floating-point. Laggiunta e
la rimozione di un modulo del kernel linux pu venire eseguita
tramite i comandi di sistema insmod e rmmod. 5.2.1 La struttura di
un modulo del kernel linux Linterfaccia di un modulo del kernel
linux costituita fondamentalmente da due metodi che vengono
chiamati rispettivamente allinserimento e alla rimozione del modulo
stesso. Li riportiamo qui: int init_module(void) void
cleanup_module(void) Per sviluppare un modulo valido per il kernel
sufficiente implementare tali moduli. 5.2.2 Sviluppo di un task
real-time Come spiegato, un task real-time si presenta come un
modulo del kernel linux. Le due chiamate sopra citate dovranno
quindi essere presenti nel codice del modulo. Inoltre
nellinizializzazione avremo una serie di chiamate a funzione
necessarie per la creazione del task real-time e il suo
schedulamento. In particolare saranno presenti le seguenti chiamate
a funzione: rt_task_init; rt_task_make_periodic_relative_ns
start_rt_timer La prima istruzione crea un nuovo task real-time, la
seconda imposta la periodicit del task e infine la terza avvia il
timer. Nella funzione di clean-up del modulo, invece, si troveranno
le rispettive funzioni per fermare il timer e distruggere il task:
stop_rt_timer(); rt_task_delete(); 5.2.3 Le principali funzioni
RTAI RT_TASK* rt_task_init ( int name, int priority, int
stack_size, int max_msg_size ) Crea un nuovo task real-time. name
lidentificatore unico con il quale possible referenziare il task.
priority la priorit del task. int rtf_create ( unsigned int minor,
int size ) Crea una FIFO real-time della dimensioni iniziale size e
identificatore minor int rt_task_make_periodic_relative_ns (
RT_TASK * task, RTIME start_delay, RTIME 25
25. Capitolo 5 - Il progetto period ) Imposta il task task in
modalit periodica con periodo period. start_delay definisce il
ritardo di prima esecuzione. void rt_task_wait_period ( void )
Attende fino al sopraggiungere del prossimo periodo. E usato nei
task periodici. Permette lesecuzione di altri task durante questo
intervallo di tempo. start_rt_timer ( int ) Avvia un timer
real-time. stop_rt_timer Ferma il timer real-time. 5.3 Le FIFO e la
Comunicazione Interprocesso Uno dei punti cruciali del progetto
creare un sistema di comunicazione che permetta di trasferire le
informazione tra i task in real-time e il processo in user-space.
Per fare ci, purtroppo, non possibile utilizzare gli strumenti
classici dellambiente linux per lIPC (Inter Process Communication).
RTAI per mette a disposizione strumenti simili che sopperiscono a
questa mancanza. Questi strumenti sono: Le Fifo Real-time RTAI
fornisce una versione specializzata delle FIFO per lambiente
real-time. Sono dei buffer unidirezionali non bloccanti che
permettono il trasferimento di dati in modalit asincrona. Ad ogni
FIFO corrisponde un file del tipo /dev/rtf/ dove il numero
identificatore della FIFO. La creazione e laccesso deve avvenire
dal task real-time tramite le API fornite, mentre i processi in
user-space possono accedervi tramite le primitive classiche che
linux mette a disposizione per laccesso ai file. Shared memory
Viene allocato un blocco di memoria che pu essere letto e scritto
da tutti i processi attivi nella macchina. Si accede a questa
memoria direttamente con un puntatore. Per questo motivo bisogna
garantire laccesso in mutua esclusione per il corretto
funzionamento. Ci pu avvenire tramite dei semafori. E possibile
accedere alla memoria condivisa tramite un file di sistema.
(/dev/rtai_shm) Message Queue e RPC E un meccanismo di scambio di
messaggi dove mittente e destinatario devono conoscersi. Le code di
messaggi vengono ordinate per priorit e le chiamate sono bloccanti
fintantoch il destinatario non riceve il messaggio o nel caso delle
RPC fino alla risposta del destinatario. Mailbox In questo caso la
mailbox fa da centro di smistamento dei messaggi. Pi produttori e
consumatori possono registrarsi contemporaneamente alla stessa
mailbox e mandare e ricevere messaggi. Nel nostro caso stato scelto
di utilizzare delle FIFO per le IPC in quanto luso che ne dobbiamo
fare limitato e il loro utilizzo molto semplice. Per utilizzare una
FIFO in un task real-time sufficiente utilizzare i seguenti
comandi: 26
26. Capitolo 5 - Il progetto int rtf_create(unsigned int fifo,
int size) Crea la FIFO real-time con identificativo fifo e
dimensione iniziale size. int rtf_put(unsigned int fifo, char *
buf, int count) Scrive nella FIFO fifo, un array di byte buf della
dimensione count. rtf_destroy ( int fifo ) Distrugge la FIFO
real-time precedentemente creata con identificatore fifo. 5.4 Il
collegamento elettrico delle varie parti del robot Per il
collegamento del circuito dei motori e degli odometri stata
utilizzata la porta DIO del TS-7250, che formata da 16 pin di cui 2
per l'alimentazione delle periferiche a 3,3V, 9 per per le porte
digitali DIO, e i restanti per il bus seriale SPI, operanti con una
logica da 3,3V. Ad ogni porta DIO sono associate due bit in
memoria, uno che indica se il pin viene utilizzato come ingresso o
uscita, e l'altro pin il dato da trasmettere o ricevere. Per il
collegamento dei sensori ad ultra-suoni stata utilizzata la porta
LCD, a differenza di quella precedente, questa opera con tensioni a
+5V. Sono presenti 8 pin di DIO e 2 per l'alimentazione dei
dispositivi. Siccome ogni sensore occupa 2 linee, stato possibile
collegare solo 4 sensori di questo tipo. Inoltre per evitare di
sovraccaricare la scheda TS-7250 si preferito prelevare
l'alimentazione direttamente dal regolatore di tensione. Volendo in
futuro utilizzare ulteriori sensori di questo, o altri dispositivi
operanti a +5V , possibile utilizzare un circuito transricevitore,
in grado di funzionare in modo bidirezionale modificando i segnali
da +5V a +3,3V e viceversa come ad esempio il 74LVC1T45 delle Texas
Instruments7 . Sono stati utilizzati i seguenti registri: DIO_0
DIO_7 0x8084_0004 Data register 0x8084_0014 Direction Data Register
LCD_0 LCD_7 0x8084_0000 Data register 0x8084_0010 Direction Data
Register I collegamenti sono rappresentati nella tabella seguente:
7 www.ti.com 27
27. Capitolo 5 - Il progetto DIO Pin Segnale Collegamento
Direzione 1 DIO_0 PWM motore A Out 3 DIO_1 DIR motore A Out 5 DIO_2
PWB motore B Out 7 DIO_3 DIR motore B Out 9 DIO_4 ODO_A motore A In
11 DIO_5 ODO_B motore A In 13 DIO_6 ODO_A motore B In 15 DIO_7
ODO_B motore B In 16 +3.3 V Vcc odometri Out 2 GND GND odometri -
LCD Pin Segnale Collegamento Direzione 8 LCD_0 Echo sensore 1 In 7
LCD_1 Trigger sensore 1 Out 10 LCD_2 Echo sensore 2 In 9 LCD_3
Trigger Sensore 2 Out 12 LCD_4 Echo sensore 3 In 11 LCD_5 Trigger
sensore 3 Out 14 LCD_6 Echo sensore 4 In 13 LCD_7 Trigger sensore 4
Out 28
28. Capitolo 5 - Il progetto 5.4.1 Schema dei collegamenti: 29
Uscita motori Ingresso alim. motori +12V TS-7250 Circuito motori
Ingresso +5V logica Logica motori Uscita +5V Alim. TS-7250 DIO
Ingresso odometri Collegamento sonar LCD
29. Capitolo 6 - I task RealTime Capitolo 6 - I task RealTime
6.1 Il modulo RTAI per la gestione dei MOTORI Il modulo RTAI per la
gestione dei MOTORI colloquia attraverso quattro porte di digital
I/O (due per motore) con il circuito basato sull'integrato SN754410
per il controllo motori. Il circuito ha bisogno di due segnali
distinti in ingresso per ogni motore, rappresentanti la direzione
del moto e la velocit. Per quanto riguarda la selezione della
direzione necessario alternare il livello del segnale sulla porta
di digital I/O per invertire la direzione. Si noti che per occorre
eseguire loperazione a motori fermi per non danneggiare il
circuito. Per quanto riguarda invece la modifica di velocit di
rotazione dei motori, questa avviene tramite la generazione di
unonda quadra a frequenza fissa (tra i 1kHz e i 20kHz) e variando
il duty cycle, ovverosia il tempo in cui il livello di tensione
alto nel periodo. E stato creato quindi un task con il compito di
generare il segnale per i due motori in base ai dati letti dalla
FIFO di input con la procedura rappresentata nel seguente
diagramma. E' interessante segnalare che per la sistemazione fisica
dei motori (uno di fronte all'altro), per far avanzare il robot i
due motori devono girare in direzione opposta. 30 Segnale PWM in
uscita dal driver motori con duty-cycle del 65%
30. Capitolo 6 - I task RealTime 6.2 Il modulo RTAI per la
gestione dei sensori ODOMETRICI Il modulo RTAI per la gestione dei
sensori odometrici colloquia con i sensori attraverso due coppie di
porte di digital I/O. I sensori odometrici sono gli HEDS-5505,
econder a doppio canale a quadratura, e sono montati direttamente
sugli alberi motori. 6.2.1 Il funzionamento degli encoder: Il
funzionamento illustrato nella figura seguente: Un disco perforato
montato sull'albero e disposto tra la coppia emettitore-ricevitore
(encoder). Quando il motore in funzione l'emettitore emette sempre
la luce, mentre il ricevitore la riceve ad intermittenza. Misurando
la frequenza d'intermittenza siamo in grado di valutare i giri del
motore per minuto, e conoscendo il diametro delle ruote, possiamo
ottenere la velocit di movimento del robot. Usando due coppie di
encoder, sfasati tra di solo rispetto all'asse del motore di 90
gradi, siamo anche in grado di conoscere la direzione in cui sta
girando il motore, confrontando lo sfasamento dei segnali prodotti.
31
31. Capitolo 6 - I task RealTime I segnali essendo sfasati non
cambiano mai entrambi contemporaneamente, usando un campionamento
sufficientemente veloce possiamo confrontare due stati consecutivi
e tramite la tabella seguente capire se il motore rimasto fermo,
andato in avanti o indietro. 6.2.2 Il programma: Sono stati creati
due task separati: uno per leggere i dati e uno per riempire la
FIFO. Si scelto questo approccio in quanto necessario campionare lo
stato delle due porte abbastanza velocemente da non perdere lordine
in cui i fronti donda salgono o scendono ma sarebbe inutile
immettere dati nella FIFO con questa cadenza. Si quindi preferito
inserire le informazioni nella FIFO in un task separato con una
periodicit diversa. Il task per la lettura eseguir quindi le
seguente operazioni periodicamente: Lettura dello stato delle due
linee di ogni motore Confronto con lo stato precedente di ogni
motore In caso di variazione di stato, incremento o decremento del
contatore motore 6.2.3 Il codice // PUNTO 1 state=inb_p(PORTB);
nowa=state & DIO_ODOMETRY1_MASK; nowb=state &
DIO_ODOMETRY2_MASK; // PUNTO 2 tempa =
step_odo(&olda,nowa,DIO_ODOMETRY1_MASK); tempb =
step_odo(&oldb,nowb,DIO_ODOMETRY2_MASK); // PUNTO 3
counta+=(signed int)tempa; countb-=(signed int)tempb; dove
step_odo() assume come argomenti lo stato passato, lo stato attuale
del segnale e la maschera 32
32. Capitolo 6 - I task RealTime da usare per poi determinare
il verso di rotazione. Da notare che le variabili counta e countb
vengono incrementate con segno opposto in quanto, per far avanzare
correttamente il robot i motori girano in senso opposto. 6.2.4 La
frequenza di campionamento Un problema affrontato stato quello di
dover scegliere la frequenza di campionamento adeguata in quanto:
una frequenza troppo elevata mette in crisi la cpu, occupando tutti
i cicli di clock e bloccando l'intero sistema; una troppo bassa non
sufficiente per riuscire ad invidiare tutti i cambiamenti di stato,
con il risultato di ottenere misurazione errata. I dati messi a
disposizione dal costruttore della piattaforma sono i seguenti:
Velocit massima 24 metri al minuto Ruote motrici con 15 cm di
diametro Econder con 500 tick per giro Da questi dati si ottenuta
una stima della frequenza di campionamento necessaria:
24/(0,15)=51,93 giri / minuto 50,93 / 60 = 0,85 giri / secondo
0,85500 = 424,41 tick /secondo Considerando che in un periodo ci
sono quattro stati (00,01,11,10), e che per ogni stato per
sicurezza dovremmo avere almeno due letture 424,418=3.395,3 letture
/ secondo E' stato provato il programma con una frequenza di
campionamento di 3400 Hz, ma nonostante questo il programma non
funzionava correttamente. Per cercare di risolvere questo
inconveniente si deciso di utilizzare un oscilloscopio per
analizzare in modo preciso i segnali emessi degli odometri. Questa
prova stata effettuata collegando le sonde alle due uscite di un
odometro e facendo girare il rispettivo motore alla massima
velocit. La lettura ottenuta visibile nella figura seguente.
33
33. Capitolo 6 - I task RealTime Dall'immagine si possono
vedere i due segnali opportunamente sfasati tra loro. La scala dei
tempi stata impostata su 10us. Dalla foto un periodo dato da circa
2,5 intervalli, quindi da 25 us. 1 / 0,000025 = 40.000 tick
/secondo Dalle precedenti considerazioni: 400008=320.000 letture /
secondo Quindi si scoperto che era necessaria una frequenza di
campionamento di almeno 320 kHz, un valore 100 volte superiore a
quello inizialmente ipotizzato. Tale differenza si scoperto essere
causata dai riduttori di giri dei motori, che precedentemente erano
stati ignorati, quindi in definitiva i motori di cui non avevo le
specifiche girano alla velocit di 5200 rpm. 34
34. Capitolo 6 - I task RealTime Dopo aver fatto queste
misurazione ho scoperto che i motori sono molto probabilmente i
IM-13 E- 2120 della Globe Motors8 , di cui sono liberamente
disponibili i data-sheet. I nomi reali molto probabilmente sono
stati camuffati per motivi di tipo commerciale. 6.2.5 Problemi
Dalle considerazioni precedenti si pu vedere che necessaria una
frequenza di campionamento abbastanza elevata. A tale frequenza le
numerose letture mandano il processore al 100%, causando il blocco
del sistema, mentre a frequenze inferiori si ottengono delle
letture non corrette. Quindi, nonostante il programma realizzato
sia corretto, a causa delle limitazioni hardware non previste
precedentemente si deciso di non utilizzare tali sensori in questo
progetto. In futuro potranno essere re-implementati, utilizzando un
approccio differente, delegando la lettura degli stati ad hardware
esterno come il contatore in quadratura HCTL-2016 della
Hewlett-Packard9 . Se di decidesse di utilizzare questa soluzione
bisogna considerare che sarebbero necessari due integrati di questo
tipo (uno per motore) e che ogni integrato richiede 8 pin di DIO,
per un totale di 16. A questo punto si avrebbe il problema di dover
gestire un numeroso numero di pin, non disponibili sulla TS-7250 e
bisognerebbe implementare in modo opportuno un multiplexer. 8
www.globe-motors.com 9 www.hp.com 35 Odometro Heds 5505 Riduttore
di giri
35. Capitolo 6 - I task RealTime 6.3 Il modulo RTAI per la
gestione del sensore ad ultrasuoni Ogni sensore ad ultrasuoni si
interfaccia alla scheda TS-7250 tramite due porte di digital I/O.
Lo schema di funzionamento abbastanza semplice: alzando il livello
del segnale di una delle due porte di digital I/O possibile inviare
un segnale trigger che produce il segnale acustico. Sullaltra
linea, invece, sar possibile osservare il tempo di percorrenza
delleco del segnale: dalla partenza allarrivo. Si veda dunque il
seguente grafico illustrativo: 6.3.1 Il codice: Invio del trigger:
outb_p(DIO_OUTPUT_PIN_MASK,DIO_LCD_DATA);
rt_sleep(nano2count(15000LL)); outb_p(0x00,DIO_LCD_DATA); Attesa
che il segnale si alzi sulla seconda linea DIO: while
((inb_p(DIO_LCD_DATA) & DIO_INPUT_PIN_MASK) == 0x00){ }
start_eco_pulse = rt_get_cpu_time_ns(); Attesa che il segnale si
abbassi e calcolo della differenza dei tempi: while
((inb_p(DIO_LCD_DATA) & DIO_INPUT_PIN_MASK) != 0x00){ }
distance = rt_get_cpu_time_ns()-start_eco_pulse; 36
36. Capitolo 7 - Applicazioni realizzate: Capitolo 7 -
Applicazioni realizzate: 7.1 Debug dei task real-time Sono stati
realizzati dei piccoli programmi operanti in user-space per testare
il corretto funzionamento dei vari task real-time di gestione dei
sensori e dei motori. I driver essendo dei programma che girano in
kernel space, molto importante che funzionino correttamente perch
un loro malfunzionamento potrebbe bloccare l'intero sistema. 7.1.1
Debug task motori Per i motori invece stato sufficiente comunicare
manualmente con le FIFO di sistema da terminale nel seguente modo:
echo -n "comando" > /dev/rtf/"fifo_motori" 7.1.2 Debug task
sonar stato scritto un programma che periodicamente: legge il
valore dei sensori; stampa su terminale le distanze. 7.1.3 Debug
task odometria stato scritto un programma che periodicamente: Legge
lo stato dei sensori Verifica se ci sono state variazioni Conta la
distanza percorsa Stampa su terminale dei valori Purtroppo essendo
non funzionando correttamente il modulo driver degli odometri
questo task attualmente non fornisce dati utili al progetto. 7.2 Il
modello cognitivo Una volta realizzati e testati i driver di
gestione, stato necessario valutare l'utilizzo di un modello
cognitivo che permettesse al robot di muoversi autonomamente, e di
prendere decisioni in base al programma scelto. Tali decisione
vengono effettuate utilizzando i dati sensoriali, in maniera
opportuna, in modo da evitare gli ostacoli. Il modello congnitivo
utilizzato quello chiamato prioritize che concede al robot una
completa autonomia in un mondo reale e dinamico. 37
37. Capitolo 7 - Applicazioni realizzate: In questo modo il
robot in grado di muoversi liberamente nell'ambiente senza per
questo urtare gli oggetti facendo uso di quest'unica componente,
anche in assenza dell'unit di mappatura e soprattutto di quella di
pianificazione di alto livello. La parte reattiva del modello
cognitivo strutturata in una funzionale architettura come si pu
vedere in fig: I quattro livelli comportamentali agiscono in
parallelo essendo tutti dei thread realtime schedulati in maniera
periodica. Ogni thread decide autonomamente quando attivarsi, e cio
quando fare richiesta dell'attuazione sul robot delle proprie
volont. La condizione di attivazione del comportamento Bump per
esempio il segnale di contatto proveniente dai bumper, quella di
Obstacle Avoidance la presenza, tra le letture di tutti i sonar, di
un valore al di sotto di una certa soglia, mentre il livello di
navigazione sempre attivo. Le volont dei vari comportamenti sono in
genere in concorrenza e perci per regolare l'output verso l'agente
mobile, necessario un meccanismo decisionale basato sulla priorit.
Entra in gioco cos un quinto thread, chiamato Prioritize, che ha lo
scopo di verificare periodicamente quali livelli si sono attivati e
di attuare ogni volta gli ordini impartiti da quello avente priorit
maggiore. 7.3 Random Walk stata implementata una applicazione
reattiva chiamata Random Walk, che muove il robot in maniera
casuale, evitando gli ostacoli che via via incontra sul suo
cammino. Avendo a disposizione all'atto pratico solo i 4 sensori
ultra-suoni, sono stati realizzati solo due livelli di thread:
Esplora, task a bassa priorit che muove il robot in modo casuale
Ostacolo, task ad alta priorit che si attiva se viene rilevato un
oggetto vicino dai sonar frontali e imposta una manovra per
evitarlo 38 Priorit MAX MIN
39. Capitolo 7 - Applicazioni realizzate: 7.3.2 Diagramma di
flusso thread ostacolo: Da notare che per ogni sensore la manovra
di rotazione dura un tempo differente, questo accorgimento stato
preso per evitare che il robot si incarti, ruotando sempre su se
stesso. 40
40. Capitolo 8 - Conclusioni Capitolo 8 - Conclusioni In questa
tesi stata descritta la realizzazione di un prototipo di un robot
mobile olonomo con sensori ad ultrasuoni. E' stata realizzato un
programma di gestione, basato su una architettura a priorit,
corrispondente ad una applicazione del tipo 'pulisci pavimenti'. Il
robot, in questa configurazione, si sposta a caso nell'ambiente
schivando gli ostacoli. Lo scopo ultimo di questo progetto quello
di realizzare una flotta di robot per provare sistemi di
comunicazione attraverso il canale acustico. Il prototipo limitato
ai sensori ad ultrasuoni per rilevare ostacoli. La lettura degli
odometri e' stata progettata ma non realizzata. Il progetto verr
completato in una prossima tesi. Per ora, e' stata provato il
funzionamento corretto del sistema che dunque pronto ad essere
duplicato in diversi esemplari. 41
41. Capitolo 9 - Appendici Capitolo 9 - Appendici 9.1 Redboot
9.1.1 Accesso al bootloader Per poter accedere a Redboot, nel caso
si vogliano cambiare i paramenti di avvio necessario interrompere
il suo caricamento nei primi secondi della fase di accensione della
scheda ARM, altrimenti successivamente viene caricato il kernel e
non pi possibile accedere al bootloader. Per interrompere il
caricamento, sono possibili due alternative: via porta seriale
inviando la sequenza di escape (CTRL-C) via ethernet, tramite il
protocollo telnet connettendosi all'indirizzo IP 192.168.0.50,
porta 9000 9.1.2 Caricamento del Kernel tramite I/O Tramite web
server: load -v -r -b 0x00218000 -m http -h Da flash: fis load -b
0x00218000 Da TFTP load b 0x00218000 h 192.168.0.1 vmlinuxNFS 9.1.3
Scrittura/Cancellazione del kernel nella flash Per visualizzare la
lista delle partizioni della flash si usa il comando: fis list Per
cancellare una partizione si usa il comando: fis delete Per creare
una nuova partizione (dopo averla caricata in memoria): fis create
b -l 9.1.4 Esecuzione un kernel linux Dopo aver caricato in memoria
un kernel con il comando load o fis load 42
42. Capitolo 9 - Appendici exec c "parametri del kernel" NOTA
IMPORTANTE: E necessario prestare attenzione, all'uso corretto
degli apici, soprattutto se si fanno dei copia/incolla da word
processor: questi " (ASCII hex 34) sono diversi da questi . 9.1.5
Configurazione della scheda, e del script di avvio Per visualizzare
la configurazione corrente: fconfig l Per modificare la
configurazione corrente: fconfig In particolare per fare il boot da
flash si user il seguente script: fis load exec -c
"console=ttyAM0,115200 root=/dev/mtdblock1" per fare il boot da nfs
si user invece: fis load exec -c "console=ttyAM0,115200 ip=
nfsroot=:" lip che si vuol dare allinterfaccia ethernet della
scheda lip del server che fa da host al servizio nfs il nome della
condivisione nfs contenente il root file-system da usare 9.2 Setup
e configurazione di un server NFS L'NFS un file system che consente
ai computer di utilizzare la rete per accedere ai dischi remoti
come fossero dischi locali. Per configurare un server NFS su Linux
essenziale editare il file /etc/exports e avviare i servizi portmap
e nfs. Il file /etc/exports non altro che un elenco dove si
specifica quali risorse condividere e con quali modalit (ad esempio
readonly o read-write), e con quali credenziali i client potranno
accedere 43
43. Capitolo 9 - Appendici a tale risorse (ad esempio network
mask etc). Per modificare tale file occorre essere utente root. Di
seguito riportato un esempio del file: #La directory /export e
tutto il suo contenuto #esportato via NFS in modalit read-only(ro)
e ai #soli client con un ip #di network uguale a 10.0.0.0/24
/export 10.0.0.0/255.255.255.0(ro) #La directory /home/kernel e
tutto il suo #contenuto esportato via NFS in moadalit read-
#write(rw) e ai soli client #con un ip di network uguale a
10.0.0.0/24 /home/kernel 10.0.0.0/255.255.255.0(rw) Una volta
impostato correttamente il file /etc/exports, si pu avviare il
servizio avviando i demoni RPC e NFS: /etc/rc.d/init.d/portmap
start /etc/rc.d/init.d/nfs start Nel caso in cui il servizio sia gi
attivo occorre semplicemente eseguire il seguente comando per fare
in modo che il file /etc/exports venga riletto e che si aggiornino
le tabelle interne di appoggio al servizio NFS: exportfs a Una
configurazione ottimale per un file-system pu essere:
/home/matessi/armroot
192.168.0.0/255.255.255.0(rw,no_root_squash,insecu re_locks) Si
deve poi ricordare di modificare il file /etc/fstab della
partizione ARM in modo appropriato, aggiungendo :/to/nfsroot />
nfs exec,dev,suid 1 1 e commentando: /dev/hda1 / ext2 defaults 1 1
9.3 Yaffs File-System YAFFS10 (Yet Another Flash File System) un
file system ottimizzato per memorie NAND e NOR, ed utilizzato per
la memoria interna della scheda ARM. 10 www.yaffs.net 44
44. Capitolo 9 - Appendici Il driver Yaffs per la gestione del
file-system su flash durante il boot di default trover 3
partizioni. La prima contenente il bootroom, la seconda il
file-system del sistema e la terza contenente il kernel del sistema
operativo e il redboot. Pi o meno il log di avvio del kernel si
presenter cos: Searching for NAND flash... NAND device:
Manufacturer ID: 0xec, Chip ID: 0x75 (Samsung NAND 32MiB 3,3V
8-bit) Scanning device for bad blocks Using static partition
definition Creating 3 MTD partitions on "NAND 32MiB 3,3V 8- bit":
0x00000000-0x00004000 : "TS-BOOTROM" 0x00004000-0x01d04000 :
"Linux" 0x01d04000-0x02000000 : "RedBoot" Per visualizzare il log
si pu usare il comando dmesg. 9.4 Ripristino del file-system
preinstallato Per ripristinare o installare un nuovo file-system,
bisogna prima cancellare il vecchio completamente. Per fare ci
consigliabile eseguire il kernel su un file-system esterno montato
magari con nfs ed eseguire il comando: eraseall /dev/mtd/1 Oppure:
mount /dev/mtdblock/1 /mnt cd /mnt rm fr NOTA IMPORTANTE: in questo
paragrafo si suppone che la seconda partizione sia quella del file-
system. IL NUMERO di /dev/mtd/1 e /dev/mtdblock/1 va sostituito con
quello opportuno della partizione linux (la numerazione parte da 0)
A questo punto si pu estrarre la nuova immagine montando la
partizione flash, qualora non sia gi stato fatto. mount
/dev/mtdblock/1 /mnt (se non stato gi fatto) tar xzvf -C /mnt
umount /mnt Si pu quindi riavviare la scheda con il comando 45
45. Capitolo 9 - Appendici shutdown -r now 46
46. Capitolo 10 - Bibliografia: Capitolo 10 - Bibliografia:
Articoli e manuali: Robotic Explorations: A Hands-on Introduction
to Engineering, Fred Martin, Prentice Hall, 2001. Getting started
with ts-linux Technologic Systems, 2006 Linux for ARM on TS-7000
User's Guide Technologic Systems, 2006 TS-7250 Hardware Manual
Technologic Systems, 2006 TS ARM Linux Developer's Manual
Technologic Systems, 2004 Trasmissione video in tempo reale e
localizzazione GPS nella robotica di sorveglianza - Stefano
Moratto, 2000 Integrazione di sensori ad ultrasuoni e di
localizzazione acustica nella robotica di servizio - Fabio Daris,
2001 Sviluppo di un Driver per il Controllo di un Robot Mobile in
Ambiente Multipiattaforma - Damiano Vittor, 2008 Sviluppo di un
robot mobile a comando vocale Lorenzo Dal Col, 2007 Siti internet
di riferimento: RTAI https://www.rtai.org Technologic System
http://www.embeddedarm.com Design Spark http://www.designspark.com
Zagros Robotics http://www.zagrosrobotics.com Documentazione
tecnica: SRF05 - Ultra-Sonic Ranger
http://www.robot-electronics.co.uk/htm/srf05tech.htm Low Current
Motor Driver https://www.zagrosrobotics.com/files/wirz203.pdf
Agilent Technologies Optical Encoders
http://www.zagrosrobotics.com/files/heds55xx.pdf Cirrus Logic
EP9302 http://www.cirrus.com/en/products/pro/detail/P1066.html
TS-7250 ARM Single Board Computer 47
47. Capitolo 10 - Bibliografia:
http://www.embeddedarm.com/products/board-detail.php?product=TS-7250
Linux for ARM on TS-7000 Series SBC's
http://www.embeddedarm.com/software/software-arm-linux.php Real
Time Application Interface for TS-7000 series SBC's
http://www.embeddedarm.com/software/arm-linux-24-rtai.php Robotic
Explorations: A Hands-on Introduction to Engineering
ftp://ftp.prenhall.com/pub/esm/electrical_and_computer_engineering.s045/martin/robotic_e
xplorations_1e/PowerPoint/ 48
48. Voglio ringraziare i miei genitori che con sacrificio mi
hanno permesso di arrivare fino a questo traguardo. Un
ringraziamento a mio fratello Alessio, per la disponibilit che ha
avuto in questo periodo. Desidero ringraziare Enzo Mumolo, per
l'occasione che mi ha dato di fare il tirocinio e la tesi presso il
laboratorio SMART LAB, e per la pazienza avuta durante questi mesi.
Un ringraziamento a tutti i compagni di studi, nonch amici che mi
hanno aiutato e sostenuto a superare esami che sembravano
impossibili, ma anche per le molte serate passate assieme. In
particolare Flavio, Davide, Gabriele, Marco e per ultima, ma non
per questo la meno importante Daniela.