Corso di Sistemi per il governo dei robot
Progettazione e
realizzazione di un robot
behavior based
Architettura a Sussunzione
Lorenzo Riano
Propositi
► Chiarire
tra “il dire ed il fare” cosa c’è di
mezzo
► Esaminare la progettazione e la
realizzazione di un robot passo dopo
passo
► Forte interazione
Cosa sarà presentato
► Analisi
del problema
► Analisi dei requisiti
► Analisi progettuale
 Architettura fisica
 Sensoristica
 Supporto computazionale
► Realizzazione
► Problematiche
Cosa NON sarà presentato
► Analisi
metodologica (scelta di paradigmi,
panoramica storica…)
► Descrizione e valutazione del paradigma
► Dettagli di modelli matematici
► Tutto ciò che non era nella slide precedente
(ovvio!)
Descrizione del problema
► Realizzazione
di un robot autonomo che
debba navigare in un ambiente sconosciuto
per trovare un goal (cibo, casa, carica delle
batterie…)
Per autonomo intendiamo un robot che non
necessiti di nessun intervento esterno
(elaborazione off-board, intervento umano)
per il corretto funzionamento
Descrizione dell’ambiente - 1
► Pianeggiante,
senza asperità o elementi che
possano impedire il corretto movimento del
robot (buche, salite, precipizi…)
 Il piano su cui si muove il robot deve essere
abbastanza ruvido da non permettere un
eccessivo slittamento
► L’unico
ostacolo presente sarà il goal
 L’ostacolo deve essere riconoscibile dalla
sensoristica a disposizione
Descrizione dell’ambiente - 2
► Sul
terreno sono presenti opzionalmente delle
tracce che dovrebbero “guidare” il robot verso il
goal.
 Il robot deve essere in grado di distinguerle dallo
sfondo.
► Al
momento dell’attivazione del robot, il goal si
trova “di fronte” ad esso.
 Dato un sistema di coordinate cartesiane con origine nel
robot e con l’asse positivo delle ordinate orientato nella
direzione dove il robot si muoverebbe se andasse in
avanti, il goal è situato in ogni istante nel semipiano
delle ordinate positive.
Descrizione dell’ambiente - 3
y
x
Analisi dei requisiti
Di cosa abbiamo bisogno?
► Un robot che sia in grado di muoversi
 Come si muove?
►
Dei sensori per rilevare un ostacolo
 A distanza? Sonar? Infrarossi?
 A contatto? Bumper?
►
Dei sensori per rilevare le tracce




►
Come sono fatte le tracce?
Telecamera?
Un sensore che rileva il colore?
Un sensore che rileva la luminosità?
Cos’altro?
Analisi progettuale
Dobbiamo stabilire quale sarà l’architettura fisica e logica del
robot, in riferimento all’analisi dei requisiti e a cosa
realmente abbiamo o possiamo permetterci di avere.
Bisogna stabilire quindi:
► Fisicamente come deve essere fatto il robot (dimensioni,
sistema di movimento...)
► Di quali sensori disponiamo, quali devono essere comprati
(creati) e quali sono le loro caratteristiche
► Di che tipo di supporto computazionale (singolo
processore, SMP, Programmable logic Array...) abbiamo
bisogno.
Architettura fisica - 1
► Lego
Technic®
► Sistema di trazione differenziale
 Due motori indipendenti controllano due ruote
indipendenti poste sullo stesso asse. Una terza
ruota è libera di muoversi (caster wheel), e
serve solo a stabilizzare la struttura.
► Peso
e dimensioni sono rilevanti?
Gearing
Doppio differenziale
Motore Lego 71427
Architettura fisica - 2
Come funzionano i motori?
► Normalmente sono motori DC, ovvero a livelli di tensione
(maggiore tensione maggiore velocità angolare)
► Sono controllati in PWM (Pulse Width Modulation), ovvero
viene dato il massimo della tensione a frequenze variabili.
Un volano (flywheel) permette la conservazione
dell’energia meccanica tra un impulso e l’altro
V
9
t
Architettura fisica - 3
►
In che modo la potenza dei motori è
trasmessa alle ruote?
 Un sistema di ingranaggi permette di
trasferire il moto da un asse all’altro. A
seconda delle dimensioni delle ruote
dentate si ottiene un rapporto di
marce diverso. Una marcia alta
permette una buona velocità, perdendo
però in trazione (torque), mentre una
marcia bassa fornisce trazione a scapito
della velocità.
►
Quale rapporto di marce?
 Essendo i motori controllati in PWM, è
bene sacrificare velocità per trazione
Sensoristica
►
Quali sono i sensori a disposizione?
1.
Sensori di contatto (bumper)
Sensore di luminosità
Sensore di temperatura
Sensore di rotazione (shaft encoder)
2.
3.
4.
Sensore di contatto
Sono semplici sensori che indicano se sono stati premuti
(valore binario)
Come vanno inseriti nella struttura?
► Indipendentemente da quanti ne abbiamo a disposizione,
devono coprire almeno la zona frontale del robot (perché?)
► Non devono essere danneggiati! Il sensore di contatto si
attiva quando “già è troppo tardi”, ovvero quando l’impatto
è già avvenuto. Bisogna quindi che la forza dell’urto (anche
se debole) sia trasferita sulla struttura attorno al sensore,
ma non sul sensore stesso!
Sensore di contatto
Sensore di luminosità - 1
►
Misura la quantità di luce riflessa dal
materiale che ha davanti. Un piccolo led
posto a fianco del sensore provvede alla
luce da riflettere.


La quantità di luce riflessa non è funzione del
colore, ma del materiale dell’oggetto! A parità
di materiale, colori più scuri riflettono meno
luce
Il led posto a fianco del sensore può
“sporcare” le letture!
Sensore di luminosità - 2
► La
quantità luce non viene misurata lungo una
linea retta, ma attraverso uno “spot”, il cui raggio
dipende dalla distanza del led dal materiale che
sta riflettendo
► Ciò vuol dire che non misuriamo la luminosità di
un punto di fronte al sensore, ma la media dei
valori contenuti all’interno dello spot
Sensore di luminosità - 3
Sensore di Temperatura
► Misura
la temperatura a contatto (ovvio!)
► I valori letti possono essere convertiti in gradi
Celsius o Farhenheit
Sensore di rotazione
► Misura
le rotazioni compiute al suo interno.
Tipicamente è collegato ad un asse
collegato a sua volta ad un motore.
► Ha una risoluzione di 1/16, ovvero in un
giro si è “attivato” 16 volte.
► E’ in grado di distinguere rotazioni in un
senso (positive) o nell’altro (negative)
Sensore di rotazione
Digressione matematica
RADIANTI!
•Vr e Vl son rispettivamente la velocità lineare della ruota destra e sinistra
•Vr = Ir * F nel discreto
•Ir è il numero di giri contati dall’encoder
•F = (D*π) / (G*R) indica la distanza percorsa dalla ruota ad ogni impulso
dell’encoder
•D è il diametro della ruota (la stessa unità di misura di b)
•G è il rapporto delle marce tra il sensore di rotazione e la ruota
•R è la risoluzione dell’encoder (16)
Odometria - 1
► Consente
di avere un sistema di coordinate
egocentrico del robot (può essere
trasformato in assoluto)
► In ogni istante si possono stabilire
coordinate cartesiane ed orientamento del
robot
► E’ estremamente soggetto ad errori di
accumulo
Odometria - 2
Quali sono le possibili fonti di errore?
► Slittamento delle ruote
► Errori nella misura dei parametri
► Imperfezioni meccaniche
► Il peso del robot curva l’asse e diminuisce il
diametro delle ruote!
► Errori floating point
► ...
Odometria - 3
Come correggerli?
► Variare la sensibilità del sensore di rotazione (in
relazione alla formula vista)
 Diminuire il diametro delle ruote
 Aumentare la distanza tra le ruote
 Aumentare il rapporto delle marce
► Attenzione!
Un sensore di rotazione troppo
sensibile amplifica notevolmente l’errore!
► Comunque vada, anche un minimo errore tende
ad accumularsi col tempo.
Processore
►
►
►
►
►
►
►
►
►
RCX Hitachi H8300
8 Mhz
32 Kb di RAM
32 Kb di ROM
3 Convertitori A/D
3 Uscite analogiche
Torretta IR per la comunicazione
Un display dove è possibile vedere una stringa di massimo
5 caratteri o un numero esadecimale di massimo 5 cifre
Non ha supporto nativo alla matematica floating point!
Toast the Warranty
Interfacciamento verso i sensori
►I
sensori funzionano e “comunicano” in
analogico.
► Con tre convertitori A/D possiamo connettere
fino ad un massimo di 3 sensori (a parte
qualche trucco)
► Come sono alimentati i sensori?
 Il processore fornisce corrente di alimentazione di
base.
 Ogni tot millisecondi, “stacca” la corrente per
leggere i valori riportati dai sensori.
Multiplexer FPGA
Interfacciamento verso i motori
► Come
già visto, i motori sono controllati in
PWM
► La velocità è un parametro che può andare
da 0 a 255 memorizzato in un byte
► Ad ogni interrupt del timer, la velocità viene
sommata a se stessa. Se c’è overflow,
manda un impulso al motore
► Sistema non lineare!
LegOS - BrickOS
Progetto Open Source rilasciato sotto licensa GPL.
► Scritto in C
► Provvede un “sistema operativo” per il processore RCX
► Consente di astrarsi da molti dettagli tecnici relativi al
processore
► Fornisce un’interfaccia verso i sensori/motori
► Ha una dimensione in memoria di circa 18 Kb
► Simula la presenza di un coprocessore matematico per le
operazioni floating point
► Supporta (limitatamente) il multi-threading
►
Creazione di programmi - 1
► Un
programma può essere scritto in C\C++
► Non deve avere richieste di memoria
dinamica (statica e dinamica) eccessive
► Non deve prevedere un carico
computazionale eccessivo
► Non deve usare “troppa” matematica
floating point (meglio se non la usa proprio)
► Deve essere semplice e ben strutturato
(impossibilità di fare debugging)
Creazione di programmi - 2
► Il
programma è compilato off-line (cross
compiling)
 E’ possibile utilizzare uno dei migliori compilatori
esistenti: GCC
► Viene
pre-linkato off-line
► E’ trasferito sul processore tramite una torretta IR
► Una volta sull’RCX vengono effettuati gli ultimi
passi di linking con le routine messe a disposizione
da BrickOS
Alternative
►
Lego FIRMWARE
 E’ il firmware di base fornito dalla Lego. Può essere utilizzato tramite il
software fornito con il set base Mindstorms, un tool grafico molto semplice
da utilizzare quanto limitato
►
NQC (Not Quite C)
 Scritto da Dave Baum, è un linguaggio molto simile al C che non necessita
la creazione di nuovo firmware. Non ha matematica floating point ed è
limitato ad utilizzare al più 32 variabili
►
PbForth
 Il Forth è un linguaggio molto vicino alla macchina, usato per programmare
microcontrollori. Molto interessante, ma poco espressivo
►
Lejos: Micro macchina virtuale JAVA
 Non vi aspettate prestazioni superiori a quelle di Shakey
Realizzazione
► Sappiamo
adesso cosa abbiamo a disposizione.
► I requisiti cui deve soddisfare il robot che creiamo
devono essere:




Capacità di muoversi in un ambiente sconosciuto
Capacità di riconoscere e seguire delle “tracce” per terra
Capacità di riconoscere il goal come unico ostacolo
Come possiamo sfruttare l’informazione “Il goal si trova
di fronte al robot?”
IN OGNI MOMENTO IL ROBOT NON DOVRA’
MAI INVERTIRE DI 180° LA DIREZIONE CHE
AVEVA INIZIALMENTE
Wandering - 1
► “Il
robot deve essre in grado di muoversi in un
ambiente sconociuto”
► Il wandering è il processo di base del robot.
► La sua presenza è motivata principalmente
dall’informazione “Il robot dovrà muoversi in un
ambiente sconosciuto”
► In ogni caso non dovrà mai invertire la propria
direzione di partenza
► Non usa sensori
► Non ha releaser, è sempre attivo
Wandering - 2
►
►
►
Assumiamo che gli unici “turn” che il robot possa
compiere mentre è attivo il Wandering siano di 90° o a
destra o a sinistra.
Il Comportamento del modulo può essere modellato
tramite un automa a stati finiti
Non vi è uno stato di terminazione
Centrato
90° a sinistra
90° a destra
LineFollowing - 1
“Sul terreno sono presenti opzionalmente delle tracce che dovrebbero “guidare” il
robot verso il goal”.
► Come sono fatte le tracce?
►
►
►




Linee nere su sfondo bianco
Non è detto che portino al goal
Non si sa quando iniziano e quando finiscono
Il robot può entrare in un qualsiasi allineamento rispetto alla traccia


La linea nera riflette meno luce rispetto al bianco
Il range di valori tra il nero ed il bianco è 9
Come reagisce il sensore di luminosità ad una linea nera?
E quando lo spot si trova a metà tra il nero ed il bianco?\


►
Nel passaggio dal nero al bianco (e viceversa) il sensore legge tutti i 9 valori che li separa
Ciò vuol dire che possiamo sapere se stiamo per “abbandonare” una linea nera prima di
averla effettivamente abbandonata
E come correggiamo l’andamento?


L’unica informazione che abbiamo è che stiamo per abbandonare la linea nera, ma non
sappiamo se ciò avviene perché essa sta per terminare o perché rispetto al robot sta per
curvare
Possiamo eseguire due test:
1.
2.
•
•
Il primo, non troppo ampio, gira il robot in una direzione finché non trova il nero
Se il primo test è fallito, eseguiamo una svolta molto più ampia in direzione opposta
Se entrambi i test falliscono, allora vuol dire che la linea nera è effettivamente terminata
(oppure non siamo riusciti a riprenderla)
Il releaser è “Il sensore di luminosità vede nero”
LineFollowing - 2
Linea Nera
Vai avanti
Prima ricerca
Fai n tentativi a
destra
Bianco
Seconda ricerca
Fai 2n tentativi a
sinistra
Fine
Fermati
Reversing
►
►
►
►
►
“In ogni momento il robot non dovrà mai invertire il suo
orientamento di 180°
Compito del Reverser è garantire che questa regola sia in
ogni momento applicata
Se per qualche motivo (quali?) il robot inverte il proprio
orientamento, il Reverser prende il controllo e gira il robot
di 180°.
Il releaser è quindi: “Il robot ha un orientamento
maggiore di 180°”
Per tenere traccia dell’orientamento, il Reverser utilizza due
sensori di rotazione collegati alle due ruote della trazione
Goal
► “Il
goal è rappresentato dall’unico ostacolo
presente nell’ambiente”
► Ciò vuol dire che, nel momento in cui viene
rilevato un ostacolo, abbiamo raggiunto il nostro
obiettivo
► L’ostacolo è rilevato attraverso il sensore di
contatto
► Il releaser è: “Il sensore di contatto è stato
premuto”
► Il modulo di Goal ferma il robot
Riassunto dei Behaviors
RELEASER
SENSORI
BEHAVIOR
Nessuno
(sempre attivo)
Nessuno
Wandering
Linea nera
Sensore di
luminosità
LineFollowing
Inversione di
180°
2 Shaft Encoders
Reversing
Ostacolo
Bumper
Goal
Organizzazione a Sussunzione
Bumper
Goal
Shaft Encoders
Reversing
Light Sensor
LineFollowing
Wandering
S
S
S
Motori
Additional credits
► Prof.
Aloisio per la realizzazione di un
“multiplexer di sensori” tramite FPGA
► Prof. Milano per la collaborazione nel
(tentato) sviluppo di un controllore per i
motori
► L’intera comunità Open Source, grazie alla
quale ho potuto realizzare la mia tesi
► La Microsoft, per aver realizzato Power Point
► Chi mi ha fornito il seriale del Power Point
Ultima nota
►
►
►
Il numero di sensori utilizzati in totale è 4
Solo che l’RCX può avere al più 3 sensori
Come è stato possibile?
Il bumper, quando premuto, “ritorna” un livello di tensione
molto alto, molto più alto di quello degli altri sensori
► Collegandolo sulla stessa porta d’ingresso del sensore di
luminosità, il valore che si legge quando il bumper è
premuto non sarà sicuramente un valore di luminosità
► In questo modo, posso sapere univocamente quando viene
premuto il bumper, senza “sporcare” il segnale del sensore
di luminosità
Le vie della Lego sono infinite
►