1. 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. 2. Alla mia famiglia
3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Capitolo 3 - Struttura hardware del robot: Schema completo: 17
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
38. 38. Capitolo 7 - Applicazioni realizzate: 7.3.1 Gestione delle priorit: 39 Sensori Esplora Ostacolo Accettazione
39. 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. 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. 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. 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. 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. 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. 45. Capitolo 9 - Appendici shutdown -r now 46
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. 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. 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.