REALIZZAZIONE HARDWARE E SOFTWARE DI UN ROBOT MOBILE DI

SERVIZIOTesi di Laurea in

SISTEMI OPERATIVI

Laureando:Basilio Marco Matessi

Relatore:Chiar.mo Prof. Enzo Mumolo

Anno Accademico 2009-2010

IntroduzioneScopo di un robot mobile di servizio: sviluppare un sistema autonomo che realizzi un servizio utile all'uomo.

In questa tesi è stato sviluppato un robot prototipale.

Obbiettivo: realizzare una flotta di robot mobili per provare algoritmi di coordinazione.

Software realizzato: movimento casuale del robot, schivando gli ostacoli.

Architettura cognitiva a priorità.

Parte meccanica

2

4

5 6

mot

ore

B

motore A

LEGENDA:███ Base del robot███ Sonar collegati███ Sonar non collegati███ Ruote motrici███ Ruote Pivot

Struttura a quadriciclo: 2 route fisse motorizzate 2 ruote pivottanti

Piattaforma a più livelli:Livello 1: batterie, logica di controlloLivello 2: sensori ad ultrasuoni

Scheda di controlloPiattaforma di sviluppo

Scheda a microprocessore TS-7250 (ARM9)Linux 2.4 + estensione RTAI

PeriferichePorte Digital I/OSPIADC 5 canaliEthernet2 porte seriali2 porte USBBus PC10432Mb di memoria flash

SensoriUltrasuoni SRF-05

Logica integrata nel moduloAccesso tramite Digital I/O (pin LCD)

Odometrici Heds-5505Accesso tramite Digital I/O (pin DIO)Funzionamento in quadratura

Specifiche:Frequenza 40kHZRange massimo: 4 metriRange minimo: 3 metri

Circuito stampato realizzato

Parte elettronicaARM

OPTO-ISOLATORE DRIVER Ponte H MOTORI

interfaccia

I/OULTRASUONI ODOMETRIA

I/O

I/O

Parte softwareSistema operativo real-time con Linux+RTAI:

Generazione segnali PWM con thread periodici real timeLettura dai sonar con thread periodici real timeLettura odometri con thread periodici real timeComunicazione con programma utente tramite FIFO

TaskSonar 1

TaskSonar 2

TaskMotori

FIFO

Programma di gestione

TaskSonar 3

TaskSonar 4 RTAI

SchedulerTask

Odometria

LINUXScheduler

Kernel space

Userspace

Task Motori

Segnale PWM in uscita dal driver motori,

con duty-cycle del 65%

Due segnali in quadratura per rilevare velocità e direzione

Una lettura per ogni possibile variazione

Problema!Frequenza di campionamento troppo elevata (320kHz)

Soluzione?● Contatore esterno HCTL-2016 (non implemetato)

Task odometria

ARM

ARM

Prima

Dopo

Debug dei taskDebug dei sonar:

Task che periodicamente: Legge il valore dei sensoriStampa su terminale le distanze

Debug motore:Invio manuale di comandi alla FIFO dei motori

Da terminale:

Debug odometria:Task che periodicamente:

Legge lo stato dei sensoriVerifica se ci sono state variazioniConta la distanza percorsaStampa su terminale dei valori

echo -n "comando" > /dev/rtf/"fifo_motori"

Modello cognitivo utilizzatoStruttura reattiva con priorità:

Priorità

MAX

MIN

Test RoboticiProgramma implemetato Random WalkStruttura reattiva a due livelli:

Esplora, priorità 0Evita ostacolo, priorità 1

Sensori

Esplora

Ostacolo Accettazione

Taskostacolo

Conclusioni

E' stato realizzato un prototipo che usa i sensori ad ultrasuoni per evitare ostacoli.

Il controllo dei motori è stato realizzato dalla scheda ARM utilizzata.

E' stato usato Linux con un patch Real Time.

La lettura degli odometri e' stata progettata ma non realizzata in questa tesi.

E' stato realizzato un programma di movimento casuale nell'ambiente.

Il prototipo funziona correttamente ed è pronto per essere duplicato in diversi esemplari.