REALIZZAZIONE HARDWARE E SOFTWARE DI UN ROBOT MOBILE DI SERVIZIO - Tesi

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

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 L’architettura 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

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

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

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

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

9
2
3
4
5
6
motoreB
motoreA
LEGENDA:
███ Base del robot
███ Sonar collegati
███ Sonar non collegati
███ Ruote motrici
███ Ruote Pivot

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

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

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

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: l’EP9302.
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

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 dell’ordine del centimetro.
Sensori odometrici HEDS-5505
I sensori odometrici sono atti a rilevare il verso e la velocità di rotazione dell’asse 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

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

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.

Schema completo:
17

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 nell’ambiente in cui si
muove. Per questo motivo un sistema operativo real-time è solitamente preferibile per lo sviluppo di
sistemi robotici.
Nell’ambito 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.
Quest’ultimo 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 dell’immagine del kernel,
per la sua esecuzione e per scrivere l’immagine 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 l’utilizzo di Redboot si è provveduto a riportare nel testo, quando necessario, i
comandi utilizzati.
4 www.ecos.sourceware.org
5 www.sourceware.org/redboot
18

Per ulteriori dettagli su Redboot sono stati scritti degli approfondimenti nell’appendice.
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 l’estensione 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 l’utilizzo 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-
DEPMOD = /bin/true
6 ftp.embeddedarm.com
19

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 l’utente può scegliere direttamente l’hardware 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 l’hardware 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

● 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=
<percorso di destinazione>
A questo punto si ha a disposizione nella directory ./arch/arm/boot/ l’immagine 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 l’insorgere
di problemi durante la configurazione.
Nel file
rtai-3.2/base/config/kconfig/mconf.c
alla riga 91 bisogna togliere l’attributo statico alla variabile current_menu
Fatto ciò si prosegue nella compilazione con i seguenti comandi:
21

make ARCH=arm
CROSS_COMPILE=/tools/crosstool/arm-9tdmi-linux-
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 all’esecuzione 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 nell’introduzione, 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

exec –c "console=ttyAM0,115200 ip=<ip>
nfsroot=<ipnfsserver>:<nome condivisione>"
dove
• <ipnfsserver> è l’ip del server che fa da host al servizio nfs
• <nome condivisione> è 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 nell’appendice.
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 quest’ultima 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 dell’USB.
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

Capitolo 5 - Il progetto
5.1 L’architettura 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 l’intero 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

NON possono:
• Usare funzioni della libreria standard C,
• Usare aritmetiche floating-point.
L’aggiunta 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
L’interfaccia di un modulo del kernel linux è costituita fondamentalmente da due metodi che
vengono chiamati rispettivamente all’inserimento 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
nell’inizializzazione 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” è l’identificatore 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

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 l’esecuzione 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 dell’ambiente linux per l’IPC
(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 l’ambiente 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/<num> dove <num> è il
numero identificatore della FIFO. La creazione e l’accesso 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 l’accesso 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 l’accesso 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 l’uso 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

• 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

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
9 LCD_3 Trigger Sensore 2 Out
28

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

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 l’operazione 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 un’onda
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%

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

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 l’ordine in cui i fronti d’onda 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

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,85·500 = 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,41·8=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

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:
40000·8=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

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

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.
Sull’altra linea, invece, sarà possibile osservare il tempo di percorrenza dell’eco del segnale: dalla
partenza all’arrivo.
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

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

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

7.3.1 Gestione delle priorità:
39
Sensori
Esplora
Ostacolo Accettazione

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

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

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 <http server
IP> <kernel name>
Da flash:
fis load <nome partizione> -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 <nome partizione>
Per creare una nuova partizione (dopo averla caricata in memoria):
fis create –b <base_memory> -l<lunghezza> <nome
partizione>
9.1.4 Esecuzione un kernel linux
Dopo aver caricato in memoria un kernel con il comando load o fis load
42

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 <kernelimagename>
exec -c "console=ttyAM0,115200
root=/dev/mtdblock1"
per fare il boot da nfs si userà invece:
fis load <kernelimagename>
exec -c "console=ttyAM0,115200 ip=<ip>
nfsroot=<ipnfsserver>:<nome condivisione>"
• <ip> è l’ip che si vuol dare all’interfaccia ethernet della scheda
• <ipnfsserver> è l’ip del server che fa da host al servizio nfs
• <nome condivisione> è 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

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
<ip>:</path/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

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 <filesystem.tar.gz> -C /mnt
umount /mnt
Si può quindi riavviare la scheda con il comando
45

shutdown -r now
46

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

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

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.

REALIZZAZIONE HARDWARE E SOFTWARE DI UN ROBOT MOBILE DI SERVIZIO - Tesi

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à REALIZZAZIONE HARDWARE E SOFTWARE DI UN ROBOT MOBILE DI SERVIZIO - Tesi

Similaire à REALIZZAZIONE HARDWARE E SOFTWARE DI UN ROBOT MOBILE DI SERVIZIO - Tesi (20)

REALIZZAZIONE HARDWARE E SOFTWARE DI UN ROBOT MOBILE DI SERVIZIO - Tesi