Progetto e Realizzazione di una Piattaforma Robotica per

Transcript

UNIVERSITÀ DEGLI STUDI DI PARMA
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA IN INGEGNERIA ELETTRONICA
PROGETTO E REALIZZAZIONE DI UNA
PIATTAFORMA ROBOTICA PER APPLICAZIONI
INDOOR: STUDIO DI UN CASO NELL’AMBITO DEL
PROGETTO ROBOCUP ITALIA
Relatore:
Chiar.mo Prof. Ing. G. ADORNI
Correlatori: Dott. Ing. S. CAGNONI
Dott. Ing. M. MORDONINI
Candidato:
CARLO BERNARDI
ANNO ACCADEMICO
1999–2000
Ai miei genitori
e ai miei nonni
Indice
Introduzione
1
1 Nascita di un robot
3
1.1
La struttura di un robot . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1.1
Robot autonomi . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.1.2
Interazione con l’ambiente esterno . . . . . . . . . . . . . . .
5
La RoboCup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.1
RoboCup: categoria middle-size . . . . . . . . . . . . . . . .
6
1.2.2
Categoria middle-size: estratto del regolamento . . . . . . . .
7
1.3
Romolo il precursore . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.4
Architettura di TinoZoff . . . . . . . . . . . . . . . . . . . . . . . .
10
1.4.1
Dispositivi installati su TinoZoff . . . . . . . . . . . . . . . .
10
Architettura di Galavrón . . . . . . . . . . . . . . . . . . . . . . . .
12
1.5.1
Percezione . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.5.2
Elaborazione . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.5.3
Azione . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.5.4
Alimentazione . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2
1.5
2 Elaborazione delle immagini
2.1
2.2
14
Acquisizione e segmentazione . . . . . . . . . . . . . . . . . . . . .
14
2.1.1
Caratteristiche della videocamera . . . . . . . . . . . . . . .
15
2.1.2
Caratteristiche del frame-grabber . . . . . . . . . . . . . . .
19
Strategia di elaborazione . . . . . . . . . . . . . . . . . . . . . . . .
20
ii
Indice
2.3
iii
Estrazione delle informazioni . . . . . . . . . . . . . . . . . . . . . .
20
2.3.1
23
Calcolo della posizione della palla . . . . . . . . . . . . . . .
3 Struttura software
3.1
3.2
3.3
3.4
Sistemi a behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.1.1
Agenti ed agenti autonomi . . . . . . . . . . . . . . . . . . .
25
3.1.2
Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.3
ETHNOS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.1.4
Saphira . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.1.5
Confronto tra Saphira ed ETHNOS . . . . . . . . . . . . . .
32
Gli esperti del robot . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.1
Copertura della porta . . . . . . . . . . . . . . . . . . . . . .
35
3.2.2
Riposizionamento . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.3
Visione . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Interazione con il mondo . . . . . . . . . . . . . . . . . . . . . . . .
38
3.3.1
Controllo del movimento . . . . . . . . . . . . . . . . . . . .
38
3.3.2
Strategia di attivazione del kicker . . . . . . . . . . . . . . .
38
Esempio: l’esperto di riposizionamento . . . . . . . . . . . . . . . .
39
4 Il sistema di potenza
4.1
4.2
43
Alimentazione a batterie . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.1
Parametri da considerare . . . . . . . . . . . . . . . . . . . .
43
4.1.2
Tipi di batterie . . . . . . . . . . . . . . . . . . . . . . . . .
45
Più potenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.2.1
La scheda di potenza . . . . . . . . . . . . . . . . . . . . . .
53
4.2.2
Il KaOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.2.3
Controllo dei motori . . . . . . . . . . . . . . . . . . . . . .
57
4.2.4
Sviluppi futuri del KaOS . . . . . . . . . . . . . . . . . . . .
59
5 Sviluppi futuri e conclusioni
5.1
25
60
Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.1.1
60
Algoritmi genetici . . . . . . . . . . . . . . . . . . . . . . .
Indice
iv
5.1.2
5.2
Nuovi sensori . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Risultati delle competizioni . . . . . . . . . . . . . . . . . . . . . . .
62
5.2.1
Parigi ’98 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.2.2
Stoccolma ’99 . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.2.3
Amsterdam 2000 . . . . . . . . . . . . . . . . . . . . . . . .
65
A Manuale d’uso del robot
67
A.1 Batterie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
A.1.1 Carica delle batterie con il caricabatterie . . . . . . . . . . . .
67
A.1.2 Carica con alimentatore da banco . . . . . . . . . . . . . . .
68
A.2 Circuito pneumatico per il kicker . . . . . . . . . . . . . . . . . . . .
69
A.3 Alimentazione del robot . . . . . . . . . . . . . . . . . . . . . . . .
69
A.3.1 Alimentazione da batterie . . . . . . . . . . . . . . . . . . .
69
A.3.2 Alimentazione con alimentatore PC . . . . . . . . . . . . . .
70
A.3.3 Alimentazione con alimentatore da banco . . . . . . . . . . .
70
A.4 Scheda di controllo . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
A.4.1 Collegamenti elettrici . . . . . . . . . . . . . . . . . . . . . .
71
A.4.2 Aggiornamento del PSOS . . . . . . . . . . . . . . . . . . .
71
A.4.3 Parametri del PSOS . . . . . . . . . . . . . . . . . . . . . . .
71
A.5 Collegamento al robot . . . . . . . . . . . . . . . . . . . . . . . . . .
72
A.5.1 Collegamento diretto . . . . . . . . . . . . . . . . . . . . . .
72
A.5.2 Collegamento tramite rete . . . . . . . . . . . . . . . . . . .
73
A.6 Programmazione . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.6.1 Avvio del programma . . . . . . . . . . . . . . . . . . . . .
74
A.6.2 Modifica e procedure di compilazione . . . . . . . . . . . . .
74
B Schema del robot
75
C Listato del KaOS
79
Ringraziamenti
120
Bibliografia
121
Elenco delle figure
1.1
Un robot B14 RWII. . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2
Architettura del robot “Romolo”. . . . . . . . . . . . . . . . . . . . .
9
1.3
Il robot TinoZoff. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.4
Il robot Galavrón. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.1
Schema del sistema di acquisizione delle immagini. . . . . . . . . . .
15
2.2
Conversione A/D del segnale video. . . . . . . . . . . . . . . . . . .
16
2.3
Posizionamento delle telecamere su Galavrón. . . . . . . . . . . . . .
19
2.4
Acquisizione di immagini tramite specchio sferico. . . . . . . . . . .
21
2.5
Campo inquadrato dalle telecamere del robot. . . . . . . . . . . . . .
22
2.6
Calcolo della posizione della palla. . . . . . . . . . . . . . . . . . . .
24
3.1
Ethnos: il funzionamento di un esperto. . . . . . . . . . . . . . . . .
30
3.2
Saphira: architettura di sistema. . . . . . . . . . . . . . . . . . . . .
32
3.3
Saphira: architettura di controllo. . . . . . . . . . . . . . . . . . . . .
33
3.4
Esperto di decisione: strategia di copertura della porta. . . . . . . . .
36
3.5
Zona di corretta posizione del robot e sistema di riferimento adottato.
39
3.6
Esperto ETParking: analisi dei singoli stati. . . . . . . . . . . . . . .
41
3.7
Esperto ETParking: diagramma degli stati. . . . . . . . . . . . . . . .
42
4.1
Profili di scarica per diversi tipi di celle. . . . . . . . . . . . . . . . .
45
4.2
Effetto memoria per le celle al Ni-Cd. . . . . . . . . . . . . . . . . .
47
4.3
Velocità del robot con diversi carichi. . . . . . . . . . . . . . . . . .
52
4.4
Funzionamento degli encoders incrementali. . . . . . . . . . . . . . .
55
v
Elenco delle figure
vi
4.5
Schema di funzionamento del sistema operativo KaOS. . . . . . . . .
56
4.6
Potenza ai motori: modulazione ad ampiezza di impulso (PWM). . . .
58
5.1
RoboCup ’98. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.2
Tabellone della RoboCup ’98. . . . . . . . . . . . . . . . . . . . . .
63
5.3
RoboCup ’99. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.4
Tabellone della RoboCup ’99. . . . . . . . . . . . . . . . . . . . . .
64
5.5
EuRoboCup 2000. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
B.1 Schema elettrico del robot Galavrón. . . . . . . . . . . . . . . . . . .
78
Elenco delle tabelle
1.1
RoboCup: tabella dei colori. . . . . . . . . . . . . . . . . . . . . . .
7
3.1
ETHNOS: gli esperti del robot. . . . . . . . . . . . . . . . . . . . . .
34
4.1
Confronto delle caratteristiche di diversi tipi di batterie. . . . . . . . .
51
4.2
Parametri dei motori del robot. . . . . . . . . . . . . . . . . . . . . .
54
4.3
68HC11F1: pins utilizzati nel controllo dei motori. . . . . . . . . . .
59
A.1 Parametri del PSOS. . . . . . . . . . . . . . . . . . . . . . . . . . .
72
vii
Introduzione
L’oggetto di questa tesi riguarda le problematiche relative alla realizzazione di robot
autonomi che devono eseguire compiti in ambienti chiusi, solo parzialmente noti. A
tale scopo è stato progettato un sistema di visione e controllo per robot mobili che
consenta di individuare un pallone (opportunamente colorato) e cerchi di impedire che
tale pallone entri in una speciale “porta”. Anche se si è cercato per quanto possibile
di esporre argomenti generali, in questa tesi viene descritto il progetto e la realizzazione di un robot portiere secondo determinate specifiche: le specifiche tecniche della
RoboCup: The Robot World Cup Initiative.
La RoboCup è nata con lo scopo di confrontare su di un terreno comune, quello
del gioco del calcio, diverse soluzioni nell’ambito dell’intelligenza artificiale e della
robotica e per favorire la ricerca su sistemi autonomi, sistemi multi-agente e cooperazione. La partecipazione alla RoboCup, tramite la squadra nazionale italiana ART
(Azzurra Robot Team), è stata possibile grazie al progetto RoboCup Italia che, oltre
all’Università di Parma, ha interessato anche le Università di Roma (La Sapienza), Milano Bicocca, Milano Politecnico, Palermo, Genova, Padova ed il Consorzio Padova
Ricerche.
Nel corso di questo lavoro sono state analizzate le diverse componenti di un’architettura classica per un robot autonomo, visto come un agente dotato di percezione,
elaborazione (reasoning), azione sul mondo circostante. Per un robot autonomo la percezione consiste in tutti quei sottosistemi in grado di apportare una conoscenza sullo
stato dell’ambiente esterno. Il robot in questione è dotato di due telecamere con ottiche
grandangolari e di una schiera di sensori infrarossi e di sensori di contatto. Le immagini inquadrate dalle telecamere hanno richiesto un grosso sforzo elaborativo per estrarre
1
Introduzione
2
le informazioni importanti per il robot. Trattandosi di un robot portiere, la principale
informazione riguarda la posizione e la direzione della palla. È stato necessario quindi
finalizzare l’elaborazione dell’immagine ad un efficiente riconoscimento di oggetti.
L’analisi delle prestazioni del sistema robotico realizzato sfruttando una base mobile commerciale ha messo in risalto che le prestazioni erano insufficienti per l’ambito
qui descritto, ragione per cui è stata realizzata una scheda di potenza per motori elettrici in corrente continua ed è stato scritto in assembler un sistema operativo (KaOS)
preposto al controllo dei motori del robot. Tale sistema operativo è ospitato su un
microprocessore Motorola MC68HC11.
Il progetto è stato suddiviso in due parti: la prima è consistita nello sviluppo dei
sistemi di visione e di controllo e nella loro sperimentazione presso il Dipartimento di
Ingegneria dell’Informazione dell’Università di Parma, mentre la seconda nella partecipazione alla RoboCup ’98 a Parigi (luglio 1998) dopo uno stage di preparazione a
Padova presso il Consorzio Padova Ricerche, alla RoboCup ’99 a Stoccolma (agosto
1999) ed infine alla EuRoboCup, il primo campionato europeo di calcio per robot, nel
giugno 2000 ad Amsterdam.
Capitolo 1
Nascita di un robot
Un robot, secondo l’accezione corrente, è un servitore meccanico, cioè una macchina
che serve a coadiuvare o a sostituire l’uomo nel lavoro. L’utilizzo di robot è diventato
indispensabile in numerose applicazioni: catene di montaggio, esplorazione spaziale e
sottomarina, ambiti di lavoro pericolosi per l’uomo oppure in ambito bellico. Tuttavia i
robot sono ancora nella prima fase del loro sviluppo. Non si assiste ancora, in robotica,
alla diffusione di massa di robot personali, contrariamente a quanto è avvenuto per i
calcolatori. I robot attuali ricordano più i mainframes obsoleti che non gli attuali e
versatili personal computer. Infatti sono progettati essenzialmente per eseguire compiti
specifici. Un robot di una catena di montaggio non può essere riconvertito per altri
compiti perché è stato progettato e costruito per quel determinato compito. In altre
parole, mentre i personal computer possono facilmente essere riprogrammati, i robot
attuali sono fortemente dipendenti dai compiti che devono svolgere. Si presenta cosı̀
un primo problema: quello della flessibilità nell’eseguire determinati compiti. Tale
flessibilità può essere richiesta anche dall’ambito in cui si intende utilizzare il robot.
1.1 La struttura di un robot
Per struttura di un robot si intendono tutti quei sottosistemi funzionali che costituiscono il robot stesso. Da un punto di vista fisico si possono classificare i robot in base
ai sensori e agli attuatori a bordo. Un robot mobile deve possedere quegli attuatori
3
Capitolo 1. Nascita di un robot
4
(ruote, gambe, cingoli) che ne consentono il movimento. Inoltre deve essere dotato di un insieme di sensori che rendano possibile un movimento non banale. In un
braccio robotizzato si possono ad esempio distinguere il sistema di controllo, quello
di movimento, quello di manipolazione e quello di programmazione. Gli attuatori sono dunque quei dispositivi che consentono al robot di cambiare la propria posizione,
la propria configurazione esterna o di cambiare la posizione di oggetti. I sensori sono
quei dispositivi che permettono al robot di conoscere lo stato dell’ambiente circostante
(telecamere, sonar, sensori ad infrarossi, sensori di prossimità e di contatto e cosı̀ via)
e il proprio stato interno (encoders, bussole, accelerometri).
1.1.1 Robot autonomi
I robot possono essere autonomi oppure controllati dall’uomo. La differenza sostanziale è che un robot autonomo deve essere in grado, entro certi limiti, di districarsi da
situazioni potenzialmente pericolose e quindi deve poter prendere decisioni esclusivamente sulla base di dati preesistenti e di ciò che percepisce dai sensori. In questo senso,
un robot autonomo è dotato di flessibilità in quanto può cambiare il proprio comportamento come reazione a mutamenti dell’ambiente esterno. Un robot autonomo deve in
sostanza mostrare una relazione tra percezione e azione e questa relazione deve essere
in qualche modo “intelligente”, cioè finalizzata ad uno scopo. In un robot autonomo si
possono distinguere almeno quattro sottosistemi:
Percezione,
Elaborazione delle informazioni,
Azione,
Alimentazione.
I primi due sottosistemi costituiscono l’intelligenza del robot, mentre gli altri due
permettono al robot di eseguire i compiti per cui è stato progettato, consentendo al
robot di interagire con l’ambiente esterno.
5
1.1.2 Interazione con l’ambiente esterno
Nella costruzione di un robot va tenuto presente l’ambiente nel quale il robot stesso
si troverà ad operare. Una prima classificazione è quella di suddividere i robot in
base al fatto che l’ambiente esterno sia conosciuto a priori (totalmente o parzialmente)
dal robot, oppure che il robot si trovi ad operare in un ambiente totalmente ignoto.
Una definizione più approfondita di che cosa si intenda per conoscenza verrà data in
seguito. Il robot si troverà quindi ad operare in un ambiente definito da regole che
codificano i colori e le geometrie dell’ambiente stesso e che limitano in certi casi la
libertà di movimento del robot. Tutto ciò, unitamente ad altre informazioni, costituisce
il bagaglio di conoscenze a priori (knowledge base) che il robot deve possedere.
Volendo costruire un robot portiere per la RoboCup, si deve tener presente che il
regolamento aiuta a conoscere l’ambiente in cui il robot si muoverà. In pratica, essendo
definito per regolamento che la palla è di colore rosso, il robot sa di doversi aspettare
sempre una palla rossa. Viceversa, il robot non sa dove e come si muoverà la palla, nè
dove e come si muoveranno gli altri robot. Si può quindi affermare che il robot portiere
si muoverà in un ambiente noto solo parzialmente. Inoltre è importante sottolineare
che il robot deve essere autonomo, ciò vuol dire che il livello di conoscenza che il
robot possiede può essere modificato solo in base alle informazioni che provengono
dalle telecamere, dai sensori o da altri robot e non da un eventuale intervento umano
dall’esterno.
1.2 La RoboCup
Anche se si cercherà per quanto possibile di esporre argomenti generali, lo svolgimento
di questa tesi è però fortemente orientato ad un particolare ambiente, la RoboCup,
entro il quale si sono svolte tutte le prove. È opportuno quindi illustrare brevemente
l’ambito entro il quale è stato concepito questo lavoro. La RoboCup, organizzata dalla
RoboCup Federation, è una manifestazione che propone alla comunità scientifica una
sfida, quella di costruire ed organizzare squadre di robot-calciatori e di farli competere
in un torneo. Nata nel 1997 da un’idea dei giapponesi H.Kitano e M.Asada[10], la
6
Robot World Cup Initiative si è data come obbiettivo a lungo termine quello di giungere
a costruire, intorno all’anno 2050, una squadra di robot calciatori bipedi che sia capace
di sfidare secondo le regole della FIFA la squadra che allora sarà campione del mondo
di calcio. Nondimeno, a breve termine la RoboCup prevede di dare un significativo
impulso alla ricerca nei campi dell’intelligenza artificiale e della robotica. Infatti lo
sviluppo di sensori, di comportamenti e di cooperazione necessari per raggiungere
l’obiettivo fissato dalla RoboCup può avere una applicazione immediata in tutti quei
campi laddove già i robot sono utilizzati o dove ne è ormai prossimo l’impiego.
Secondo il regolamento, vi sono essenzialmente due categorie di robot: small-size
e middle-size (detta anche F-2000). La differenza principale, a parte le dimensioni,
consiste nel fatto che i robot della categoria middle-size devono essere completamente
autonomi per quanto riguarda la visione. Nella small-size, al contrario, i robot sono
aiutati da una telecamera che inquadra tutto il campo di gioco, il cosiddetto “Global
Vision System”. Il robot del progetto segue le specifiche della categoria middle-size
F-2000.
1.2.1 RoboCup: categoria middle-size
La categoria middle-size è stata pensata per favorire la ricerca su sistemi autonomi,
sistemi multi-agente, cooperazione e per studiare robot che possano assolvere a compiti specifici in ambienti in cui non è possibile una forma di telecontrollo diretto. In
particolare si pensi alle fabbriche, dove già oggi si fa largo uso di robot nel ciclo produttivo, oppure all’esplorazione dello spazio, un campo quest’ultimo in cui per ragioni
di sicurezza ed economicità i robot verranno sempre più utilizzati. E proprio in campo
spaziale possono esserci le ricadute più significative. Infatti, poiché le distanze spesso
non consentono un controllo diretto dei veicoli, risulta fondamentale poter disporre di
robot con un certo livello di autonomia. In questo ambito ricade l’esplorazione dei
corpi del sistema solare, che ha come esempi più recenti il robot marziano Sojourner
e la sonda NEAR, attualmente in orbita intorno all’asteroide Eros[8].
Colore
Rosso
Blu
Giallo
Verde
Bianco
Ciano
Magenta
7
Oggetto
palla
una porta
l’altra porta
campo
linee
marker squadra 1
marker squadra 2
Tabella 1.1: RoboCup: tabella dei colori.
1.2.2 Categoria middle-size: estratto del regolamento
Campo di gioco. La dimensione del campo di gioco è di 50009000 mm circa e la
superficie è di colore verde. Una parete bianca alta 500 mm circonda tutto il
campo ad eccezione delle porte. Sul campo vi sono alcune linee che identificano
il centrocampo e le aree di rigore. Le linee sono di colore bianco, larghe 40 mm.
Il cerchio di centrocampo ha un diametro di 2000 mm. Le aree di rigore sono
due rettangoli di 30001000 mm.
Porte. Le porte sono larghe 2000 mm, sono alte 900 mm ed hanno una profondità che
deve essere superiore al diametro della palla. Ogni porta è dipinta di un colore
unico definito nella tabella dei colori.
Palla. La palla per i robot della categoria Middle-Size è un pallone FIFA standard
numero 4, diametro 200 mm. Il colore è definito nella tabella dei colori.
Squadre e robot. Una squadra è composta di un massimo di quattro robot e può avere
un portiere. Le dimensioni di ogni singolo robot non devono superare i 2025 cm2
di area circoscritta dal perimetro del robot stesso nella sua massima estensione.
Vi sono limitazioni specifiche per le convessità del perimetro. Inoltre, la diagonale massima interna a tale area non può essere più di 63 cm. È ammessa
qualsiasi forma a patto che le dimensioni non superino quelle massime previste.
Un robot può essere alto al massimo 80 cm. Il colore dei robot deve essere nero
8
per quanto più possibile e comunque si devono evitare quei colori presenti nella
tabella dei colori.
Comunicazioni e sensori. Non ci sono restrizioni alle comunicazioni con e tra i robot
ed il computer remoto (la cosiddetta consolle della squadra), eccetto per il divieto di intervento degli operatori. Qualunque tipo di sensore è ammesso, eccetto
il sistema di visione globale (una telecamera esterna che inquadra tutto il campo
dall’alto). Sono proibiti dispositivi che trattengono la palla o che limitano uno
dei gradi di libertà della palla.
Partita. Una partita consiste di due tempi di 10 minuti ciascuno con un intervallo di
15 minuti. Vince la squadra che segna più reti.
1.3 Romolo il precursore
Nella fase di sviluppo e sperimentazione si è utilizzato un robot mobile B14 della Real
World Interface Inc. (figura 1.1), dotato di un computer con processore Pentium 200
MMX e sistema operativo Linux (Slackware con kernel versione 2.0.30). Il robot B14,
ribattezzato Romolo, è inoltre dotato di una scheda frame-grabber Matrox Meteor per
l’acquisizione di immagini da telecamera a colori e di una schiera di 16 sensori a raggi infrarossi disposti ad intervalli regolari intorno al robot. In base alla definizione
dell’immagine acquisita, il sistema è in grado di elaborare un certo numero di fotogrammi ogni secondo (frame-rate). Il parametro relativo al frame-rate è fondamentale
per avere una risposta accettabile ai movimenti della palla. Si è scelto di far acquisire
le immagini con una risoluzione di 120 linee per 160 colonne ad una profondità di
colore di 24 bit in formato RGB. Questa configurazione dà luogo ad un frame-rate di
circa 7 fotogrammi al secondo.
Il software realizzato si occupa ciclicamente di acquisire un’immagine dalla telecamera, di elaborarla per ottenere l’informazione relativa alla posizione della palla
rispetto al robot, di decidere se e verso dove far muovere il robot, di controllare se il
robot è davanti alla porta o meno e, infine, di dare gli opportuni comandi ai motori
delle ruote. Diversamente dai suoi successori, su Romolo non è stato utilizzato alcun
9
Figura 1.1: Un robot B14 RWII.
Camera
Frame
grabber
Linux
Pentium MMX
Movimento
Figura 1.2: Architettura del robot “Romolo”.
Sensori a
infrarossi
10
sistema ad agenti per il controllo del comportamento. Ad occuparsi di tutte le decisioni
relative al movimento del robot è il programma.
Una delle limitazioni maggiori riscontrate con Romolo è stata quella della non
grande ampiezza del campo inquadrato dalla telecamera, pari a circa 70o . Se da un lato
un angolo cosı̀ stretto ha fatto sı̀ che le immagini della telecamera non presentassero
particolari distorsioni (tanto che nell’elaborazione delle immagini la distorsione è stata
trascurata), dall’altro lato è evidente che nel contesto è preferibile che un portiere
debba poter inquadrare la parte più ampia possibile del campo di gioco. La telecamera
è stata posizionata sulla parte superiore del robot ed è stata inclinata in modo da coprire
una zona che andasse da circa 10 cm dalla base del robot fino a circa 2 metri di distanza.
1.4 Architettura di TinoZoff
Nella realizzazione del robot TinoZoff ci si è posti come obbiettivo principale quello
di poter avere a disposizione una architettura aperta, in grado di essere facilmente aggiornata. Questo obbiettivo è stato solo parzialmente raggiunto con TinoZoff, mentre
è stato raggiunto con successo nella creazione di Galavrón.
In base all’esperienza acquisita con Romolo, si è voluto implementare un sistema
di visione che garantisse un ampio campo inquadrato e nello stesso tempo non fosse
troppo penalizzante come risoluzione. Sono state acquistate due telecamere a basso
costo e due ottiche grandangolari dotate di 120o di apertura. Con queste si è realizzato
uno schema di visione binoculare, ma non stereo, in grado di coprire più di 200o di
terreno di gioco.
1.4.1 Dispositivi installati su TinoZoff
Essenzialmente, l’architettura di TinoZoff è composta da quattro blocchi: alimentazione, visione, elaborazione, azione.
Alimentazione. Il sistema di alimentazione di TinoZoff è composto da due batterie al
Pb-acido da 12V-4Ah collegate in serie, che forniscono 24 V all’alimentatore.
L’autonomia del robot è variabile in quanto dipende dall’utilizzo dei motori. In
11
Figura 1.3: Il robot TinoZoff.
ogni caso è più che sufficiente a concludere una partita senza la necessità di
dover sostituire le batterie nell’intervallo.
Visione. Su TinoZoff, come detto in precedenza, sono state installate due telecamere. I segnali video delle due telecamere vengono fatti confluire a due schede di
acquisizione. Le due schede sono differenti, infatti una è una Matrox Meteor,
mentre l’altra è una Intel Smart Video III basata sul chip BrookTree BT848.
Elaborazione. TinoZoff si basa su di un robot Pioneer 1 ActivMedia. Il PC installato
a bordo comprende una motherboard Asus Tx-97 con un processore AMD K6 a
200 MHz e una RAM da 64 Mb (funzionante a 66 MHz).
Azione. TinoZoff si muove grazie a due motori[6] in corrente continua con encoder incorporati Pittman della serie GM9034. Inoltre è dotato di un sistema pneumatico
per respingere la palla (kicker) con una bombola per aria compressa da un litro
e due pistoni Camozzi da 5cm a singolo effetto comandati da due elettrovalvole.
Il kicker esteso è visibile nella figura 1.3.
12
Figura 1.4: Il robot Galavrón.
1.5 Architettura di Galavrón
Galavrón nasce come sviluppo di TinoZoff. Come già era stato possibile constatare,
la progettazione e la successiva realizzazione di un robot in grado di svolgere efficacemente il compito per cui è nato presuppongono alcuni compromessi. Si devono
inoltre valutare i limiti entro i quali sia davvero possibile applicare le tecniche che si
intendono utilizzare. Si è visto che la maggior parte del tempo impiegato nella costruzione è stata utilizzata per individuare soluzioni ai problemi “reali”, cioè derivanti da
caratteristiche e vincoli dell’ambiente reale.
Galavrón è costituito da un telaio modulare in alluminio che comprende quattro
sottosistemi: percezione (visione, infrarossi e bumper), elaborazione, azione (motori e
kicker) ed alimentazione.
Per quanto riguarda il telaio, grande attenzione è stata posta al fine di rendere
agevoli gli interventi di modifica di componenti e di manutenzione all’interno del
robot.
13
1.5.1 Percezione
Diversamente da TinoZoff, questo sottosistema non comprende solo la visione. Infatti
su Galavrón sono installati quattro sensori infrarossi ed inoltre l’informazione di attivazione dei microswitch del kicker viene passata al PC, con la possibilità di utilizzarla
per valutare se ci sono stati urti.
1.5.2 Elaborazione
Nonostante il rapidissimo incremento nelle prestazioni dei processori e delle memorie,
un upgrade del PC del robot è legato anche ad altri fattori non trascurabili. In primo
luogo si deve considerare l’assorbimento del processore in quanto all’aumentare delle
frequenze di clock aumenta anche la potenza assorbita. Di conseguenza, mantenendo
il medesimo sistema di alimentazione, si riduce l’autonomia. Su Galavrón è installato
un processore Intel Celeron a 466 MHz che assorbe circa 20 Watt, un assorbimento
decisamente inferiore a quelli dei più moderni Pentium III o AMD Athlon.
1.5.3 Azione
Il sottosistema di azione comprende i motori ed il kicker. I motori sono gli stessi di
TinoZoff. Il controllo dei motori è trattato più in dettaglio al punto 4.2.3. Il kicker
è stato realizzato ex-novo e si basa su quattro elettrovalvole che controllano quattro
pistoni a doppio effetto. La bombola è in alluminio e ha una capacità di due litri. Vi è
anche una piccola bombola per il circuito chiuso di ritorno, a bassa pressione.
1.5.4 Alimentazione
Galavrón è stato predisposto per ospitare due o quattro batterie al Pb-acido, oppure
due batterie agli ioni di litio. Inoltre si è cercato di installare componenti che avessero
un consumo di corrente limitato. Per una descrizione più completa del sistema di
alimentazione si rimanda al capitolo 4 e all’appendice B.
Capitolo 2
Elaborazione delle immagini
Di tutti i campi di applicazione, quello che ha tratto i maggiori benefici dall’aumento
della capacità di elaborazione dei moderni PC è senz’altro quello legato al multimediale ed in particolare quello legato all’elaborazione delle immagini. Questo corrisponde
a poter trattare un flusso enorme di dati in un tempo ragionevole. I dati contenuti
in una immagine non sono però direttamente accessibili all’elaboratore in quanto una
immagine richiede di essere acquisita e digitalizzata.
2.1 Acquisizione e segmentazione
Per acquisizione di un’immagine si intende il processo tramite il quale l’immagine
inquadrata da una videocamera o da un qualsiasi altro sensore ottico viene trasferita
nella memoria del computer[22]. A rigor di logica, si può parlare di acquisizione anche
quando si passa allo scanner una foto o una diapositiva in quanto la pellicola fotografica è a tutti gli effetti un sensore ottico. Tuttavia nell’ambito dei robot mobili risulta
evidente che l’acquisizione delle immagini deve avere una caratteristica imprescindibile: essere quasi istantanea. In questa sezione verrà quindi considerata l’acquisizione
di immagini tramite videocamera. L’immagine inquadrata viene trasformata dalla videocamera in un segnale video analogico in banda base ed inviata in questa forma ad
una scheda di conversione A/D. Questa scheda è detta frame-grabber (letteralmente:
cattura-fotogrammi) e si occupa di convertire l’immagine in un formato digitale adatto
14
Capitolo 2. Elaborazione delle immagini
Videocamera
Segnale video
analogico
15
Frame-grabber
Immagine
digitalizzata
Figura 2.1: Schema del sistema di acquisizione delle immagini.
all’elaborazione elettronica. In fig.2.1 è stato schematizzato un sistema di acquisizione
di immagini.
2.1.1 Caratteristiche della videocamera
La videocamera è composta dal sensore CCD (Charge Coupled Device, cioè dispositivo ad accoppiamento di carica), dall’ottica e da una parte elettronica di conversione
del segnale. Il segnale in uscita dalla videocamera (segnale video) può essere secondo uno dei tre seguenti formati: PAL (standard europeo), NTSC (standard americano) o SECAM (standard francese). Questi tre formati si differenziano tra l’altro per
il numero di linee che compongono l’immagine. Il sensore CCD è il “cuore” della
videocamera. Le caratteristiche principali del sensore riguardano la risoluzione, l’intervallo spettrale e l’efficienza quantica. Le caratteristiche dell’ottica che prenderemo
in considerazione sono due: campo inquadrato e distorsione.
Risoluzione del sensore. La risoluzione del sensore dipende dal numero di pixel del
sensore stesso e dalle dimensioni dei singoli pixel. La dimensione di un pixel
può arrivare a pochi micron per lato nei migliori CCD. Il numero di righe di pixel
16
Una linea di informazione
Impulsi di
sincronismo orizzontale
(a) Segnale video analogico.
Tensione (V)
Una linea di informazione
Tempo (t)
11
00
00
11
11
00
00
11
Pixel dell’immagine digitalizzata
(b) Conversione A/D del segnale video.
Figura 2.2: Conversione A/D del segnale video.
17
del sensore può non essere un multiplo esatto del numero di righe dello standard
dell’immagine in uscita, per cui può esservi la necessità che l’elettronica faccia
una interpolazione.
Intervallo spettrale ed efficienza quantica. Questi parametri sono relativi alla percezione del colore. Per intervallo spettrale si intende l’intervallo delle lunghezze
d’onda della radiazione elettromagnetica che vengono rivelate dal sensore.
L’occhio umano ha un intervallo spettrale che va dai 400nm (violetto) ai 700nm
(rosso). Inoltre la sensibilità al colore nell’occhio umano non è costante in tutto
l’intervallo, ma presenta un massimo intorno ai 500600nm. Questo massimo
varia a seconda delle condizioni di luce, spostandosi verso il violetto nelle ore
notturne. Da ultimo, il cervello elabora l’informazione ricevuta dall’occhio, per
cui la percezione del colore è in qualche modo influenzata da ciò che ci si aspetta
di vedere. Un esempio di questa elaborazione è che l’immagine che si forma
sulla retina è capovolta ed è compito del cervello raddrizzarla[21].
In un sensore CCD l’intervallo spettrale è solitamente più ampio coprendo anche
lunghezze d’onda nel vicino infrarosso. La sensibilità al colore in un sensore
CCD difficilmente ricalca quella dell’occhio umano, per cui vengono a determinarsi dominanti cromatiche che nei sensori di bassa qualità possono essere
evidenti, richiedendo una calibrazione del colore nell’immagine acquisita. L’efficienza quantica è un parametro che indica quanti fotoni vengono “catturati”
dal sensore ed in pratica è un indicatore della capacità del CCD di registrare immagini anche in condizioni di luce scarsissima. Per fare un paragone, sia pure
approssimativo, con le pellicole fotografiche, le migliori raggiungono sensibilità di 1600 ISO (a scapito però di una perdita della risoluzione). Un sensore
CCD ha una sensibilità equivalente a oltre 20000 ISO, senza alcuna perdita di
risoluzione.
Questo parametro è fondamentale qualora non siano note a priori le caratteristiche di illuminazione dell’ambiente all’interno del quale si muoverà il robot.
Proprio per questo motivo, prima delle gare della RoboCup si devono calibrare i
colori delle immagini acquisite dalle telecamere. In ambito RoboCup la defini-
18
zione dei colori e del tipo di luce delle lampade che illuminano il campo è una
problematica ancora aperta. Non basta dichiarare che il pallone è rosso, il campo
è verde e cosı̀ via, ma sarebbe opportuno indicare i colori tramite un riferimento
quale ad esempio i codici Pantone utilizzati dalle tipografie.
Campo inquadrato. Il campo inquadrato dalla videocamera deve essere valutato in
funzione dell’applicazione che si intende realizzare. Nel campo dei robot mobili
si devono valutare i compiti che ciascun robot è chiamato ad eseguire. Il regolamento della RoboCup prevede esplicitamente la presenza di un robot portiere,
per cui è ragionevole cercare di “far vedere” al portiere quanto più terreno di gioco possibile. Sono cosı̀ state implementate varie soluzioni per ampliare il campo
inquadrato, soluzioni che si possono raggruppare in quattro categorie: sistemi di
visione omnidirezionali, poche telecamere con ottiche grandangolari, tante telecamere ciascuna inquadrante una porzione di campo limitata ed infine la soluzione con una sola telecamera orientabile ed eventualmente con zoom. Galavrón
è dotato di un sistema di visione con due telecamere con ottiche grandangolari
posizionate con un angolo di 90o , come nelle figure 2.3 e 2.5. In fase di sviluppo
è stato testato anche un sistema di visione omnidirezionale. Tale sistema, utilizzato anche da alcuni robot della squadra ART, è stato scartato in quanto vi sono
notevoli difficoltà tecniche nell’ottenere specchi dalla forma adeguata. In figura 2.4 si vedono due esempi di acquisizione tramite un improvvisato specchio
sferico.
Distorsione. La distorsione introdotta dalle ottiche dipende dalla geometria delle ottiche stesse, considerando come ottica non solo le lenti degli obiettivi delle telecamere, ma anche eventuali specchi. Il robot, muovendosi, sfrutta le informazioni
del sistema di visione per aggiornare costantemente la propria conoscenza riguardo all’ambiente esterno, pertanto può essere necessario valutare l’impatto
della distorsione sulla percezione del robot e, se necessario, correggerla.
19
Figura 2.3: Posizionamento delle telecamere su Galavrón.
2.1.2 Caratteristiche del frame-grabber
Il frame-grabber riceve in ingresso il segnale video analogico prodotto dalla videocamera (figura 2.2(a)) e invia sul bus dati del PC l’immagine in formato digitale. La
trasformazione da segnale analogico a digitale (conversione A/D) è compiuta in due
fasi:
campionamento del segnale analogico ad una frequenza fissa,
conversione della tensione del segnale negli istanti di campionamento in valori
che vengono memorizzati all’interno dei pixel dell’immagine digitalizzata come
da figura 2.2(b).
Su TinoZoff sono state installate due schede di acquisizione diverse (una basata sul
chip BT848 ed una Matrox Meteor). È apparsa subito evidente una grande differenza nella qualità dell’immagine acquisita a parità di telecamere. Questo problema ha
inciso negativamente sulla calibrazione corretta del sistema di acquisizione. Cosı̀ su
20
Galavrón si è deciso di installare due frame-grabbers dello stesso modello, AverMedia
Ez-Capture, basati sul chip BrookTree BT878.
2.2 Strategia di elaborazione
Il sistema di acquisizione delle immagini, di cui vediamo uno schema in figura 2.5(a),
acquisisce contemporaneamente entrambe le immagini provenienti dalle due telecamere (figure 2.5(b) e 2.5(c)). Tuttavia viene elaborata solo quell’immagine che inquadra
la palla. In pratica, all’avvio del programma il robot elaborerà l’immagine proveniente
da una delle due telecamere. Se viene trovata la palla, allora l’immagine da elaborare
nel ciclo successivo sarà ancora quella proveniente dalla stessa telecamera, altrimenti verrà eleborata l’altra. Questo meccanismo di switching delle immagini funziona
anche quando la palla si trova nella zona in cui le inquadrature delle due telecamere
si sovrappongono (figura 2.5(a)), garantendo cosı̀ al robot di poter avere sempre l’informazione sulla posizione della palla. Un punto critico di questa architettura risiede
proprio nella presenza di una zona di sovrapposizione delle inquadrature. Per fare
in modo che il robot abbia informazioni univoche sulla posizione della palla quando
essa è all’interno di tale zona, bisogna calibrare con estrema precisione le tabelle di
look-up. Tali tabelle restituiscono la posizione della palla sul piano di gioca a partire
dalla posizione che essa ha all’interno dell’immagine acquisita. È chiaro pertanto che
la procedura di elaborazione delle immagini deve poter restituire lo stesso dato di posizione sia che stia elaborando l’immagine di sinistra, sia quella di destra. Purtroppo
questo presupposto non è sempre verificato in quanto la zona di sovrapposizione si
trova al margine delle immagini, proprio là dove è maggiore la distorsione introdotta
dalle ottiche.
2.3 Estrazione delle informazioni
L’immagine acquisita è salvata in un buffer in memoria in formato RGB a 32 bit. Tale
formato prevede quattro bytes per pixel, di cui solo i primi tre (relativi ai colori blu,
verde e rosso) vengono utilizzati nell’elaborazione. L’obbiettivo dell’elaborazione è
Figura 2.4: Acquisizione di immagini tramite specchio sferico.
21
Campo inquadrato
dalla telecamera
sinistra
22
Zona di
sovrapposizione
delle due immagini
(~30°)
120°
111
000
000
111
000
111
000
111
000
111
000
111
Campo inquadrato
dalla telecamera
destra
120°
(a) Schema del campo inquadrato corrispondente alle immagini qui sotto.
(b) Campo inquadrato dalla telecamera sinistra.
(c) Campo inquadrato dalla telecamera destra.
Figura 2.5: Campo inquadrato dalle telecamere del robot.
23
quello di estrarre dall’immagine l’informazione sulla posizione della palla. In ambito
RoboCup la palla è di colore rosso per regolamento. In realtà il colore ufficiale è
l’arancione, tuttavia si tratta di un arancione molto intenso che spesso tende a saturare
verso il rosso.
2.3.1 Calcolo della posizione della palla
L’elaborazione si compone di tre passaggi fondamentali:
estrazione dei pixel giudicati di colore rosso,
calcolo del loro baricentro nell’immagine,
assegnazione di una posizione fisica sul campo al punto ottenuto nel passaggio
precedente.
Il primo passaggio è quello dell’estrazione dei pixel rossi. A tale scopo l’immagine
viene scandita e ogni pixel viene confrontato con determinate soglie relative ai tre
colori. In dettaglio, prima di affermare che un pixel è rosso vengono effettuati due
confronti:
eliminazione del bianco,
soglia sul rosso.
Non è sufficiente porre una soglia sul byte relativo al colore rosso per affermare che
un pixel è rosso. Infatti anche un pixel bianco o ad esempio marrone presenterà una
componente rossa molto elevata. L’eliminazione del bianco serve proprio ad eliminare
quei pixel che, pur avendo una forte componente rossa, non sono rossi. Per fare questo,
si marcano come “non rossi” tutti quei pixel per i quali
Red
(Green + Blue) < SOGLIA
1:
Il secondo confronto avviene esclusivamente sulla componente rossa dei pixel che
hanno superato il primo confronto. Sono considerati “rossi” tutti quei pixel per i quali
Red > SOGLIA 2:
24
Tabella di
look-up
Figura 2.6: Calcolo della posizione della palla.
A questo punto viene calcolato il baricentro dei pixel rossi ottenendone le coordinate X e Y riferite all’immagine. Per passare da queste coordinate alle coordinate
della palla sul campo (figura 2.6) si utilizzano due tabelle di look-up, una per ogni
telecamera. Queste tabelle presentano quattro colonne ciascuna. Nelle prime due colonne sono elencate tutte le possibili diverse coordinate X-Y nell’immagine, mentre
nelle ultime due le corrispondenti posizioni della palla sul terreno. Le tabelle vengono
caricate in memoria all’avvio del programma, in modo che l’accesso sia il più rapido
possibile. Per la generazione delle tabelle sono stati sviluppati programmi ad hoc che
hanno richiesto la creazione di un modello del sistema ottico delle telecamere. Questi
tools consentono anche di marcare determinati pixel come “esterni al campo di gioco”,
in modo da limitare l’elaborazione al solo campo utile.
Capitolo 3
Struttura software
Non sempre si pone l’attenzione dovuta alle interazioni che avvengono nel mondo reale tra gli agenti in quanto entità fisiche dotate di massa, forma e dimensione. In questo
capitolo si tratterà della organizzazione dei comportamenti del robot, analizzando i
principi di progettazione di agenti autonomi[20], la collaborazione multi-agente, l’elaborazione dei dati provenienti dai sensori (la cosiddetta fusione sensoriale) finalizzata
alla pianificazione di obbiettivi. In questo ambito talvolta la parola robot verrà usata
in luogo della più corretta espressione agente robotico, cioè un agente che opera nel
mondo reale.
3.1 Sistemi a behaviors
3.1.1 Agenti ed agenti autonomi
In questo capitolo si parlerà di agenti autonomi e di comportamenti. Risulta opportuno
definire una terminologia di base[20]:
Agente. Entità in grado di percepire attraverso sensori e di agire tramite attuatori.
Se si parla di agente intelligente, le azioni sono collegate alle percezioni razionalmente. Nel caso dei robot descritti in questa tesi si parla appunto di agenti
intelligenti.
25
Capitolo 3. Struttura software
26
Agente robotico. Agente che opera nel mondo fisico. I sensori e gli attuatori di un
agente robotico sono dispositivi che leggono l’ambiente esterno e influiscono su
di esso.
Agente deliberativo. Agente in grado di pianificare una sequenza di azioni da eseguire successivamente.
Agente reattivo. Agente che reagisce agli stimoli esterni immediatamente, senza elaborare piani a lungo termine. Gli agenti robotici ricadono essenzialmente in
questa categoria.
Agente autonomo. Un agente autonomo ha come caratteristica il fatto che il controllo
sulle azioni è svolto dall’agente stesso. Possono esservi vari livelli di autonomia,
ad esempio un agente autonomo può prendere le proprie decisioni solo dopo aver
comunicato con altri agenti. In questo caso si può parlare di coordinamento in
un sistema multi-agente.
In ambito RoboCup, considerando ogni robot della squadra come un agente autonomo, vi possono essere varie soluzioni di coordinamento. In particolare si è osservato
che alcune squadre non adottano alcuna forma di coordinamento. I robot sono cosı̀
agenti con un grado totale di autonomia. Tuttavia l’aspetto negativo della mancanza di
coordinamento è che spesso i robot si ostacolano a vicenda senza riuscire a raggiungere un obbiettivo comune. Azzurra Robot Team implementa un coordinamento che
è il più sofisticato tra quelli visti finora, prevedendo che i robot in campo si scambino messaggi di posizione propria, della palla e di ruolo in modo da far emergere un
comportamento complessivo di squadra funzionale al raggiungimento dell’obbiettivo
e cioè del goal.
L’agente robotico vede l’ambiente reale esterno secondo tre principali caratteristiche:
Percezione. L’agente percepisce in tempo reale (o quasi, dal momento che si tratta di
interazioni reali) il comportamento di quegli oggetti di cui non conosce forma,
posizione e movimento.
27
Comportamento. A seconda dei cambiamenti dinamici dell’ambiente circostante,
l’agente individua il comportamento ritenuto migliore. In ambito RoboCup è
a questo livello che entra in gioco il coordinamento con gli altri agenti presenti.
Il comportamento (o behavior) è un programma che implementa le specifiche
corrispondenti ad una determinata azione.
Azione. Il controllo su oggetti dell’ambiente circostante presuppone una serie di problematiche nuove quando si pensi che le principali applicazioni robotiche realizzate finora prevedono la manipolazione di oggetti statici o con traiettorie prevedibili. L’esecuzione di un’azione consente all’agente di portarsi da uno stato
iniziale ad uno stato finale definito dalle specifiche dell’azione stessa. Un piano
d’azione è dunque composto da azioni che, se eseguite con successo, portano
l’agente a raggiungere l’obbiettivo finale.
La pianificazione delle azioni da svolgere è sempre possibile. Tuttavia si deve fare
una importante distinzione tra condizioni ideali e mondo reale. In condizioni ideali si
può trovare un piano di azione ottimale caratterizzato da:
perfetta conoscenza dell’ambiente esterno,
certezza sull’effetto delle proprie azioni.
Nel mondo reale vi sono però problemi che limitano, e in taluni casi rendono
impossibile, la ricerca di un piano di azione ottimo:
incertezza sulla conoscenza dell’ambiente esterno,
incertezza sull’effetto delle proprie azioni,
incertezza sulle informazioni ricevute dai sensori.
3.1.2 Behaviors
Per behavior si intende un insieme di processi che coinvolgono percezione ed azione.
Un behavior è caratterizzato da una lista di precondizioni che ne determinano l’attivazione. Quando tali condizioni sono verificate, il behavior diventa attivo, mandando
28
in esecuzione i propri processi[12]. Un sistema a behaviors (cioè a comportamenti),
indipendentemente dal linguaggio di programmazione con cui lo si implementa, è in
generale costituito da una architettura in cui sono contenuti i behaviors e da una serie
di regole per la progettazione, l’attivazione e l’interazione dei behavior tra di loro e
con l’ambiente esterno.
La struttura software che si è realizzata è costituita da un insieme di agenti che
cooperano tra di loro scambiandosi vari tipi di messaggi. Brooks[5], nel 1986, ha proposto una prima, innovativa, architettura a behavior, la subsumption architecture. Con
essa Brooks assume che un compito complesso possa essere suddiviso in tanti behavior che vengono eseguiti parallelamente e che competono per il controllo esclusivo
dell’agente. Le idee di Brooks applicate alla robotica non prevedono un tipo di intelligenza standard a bordo, come può essere un programma creato secondo regole rigide.
Viceversa, il comportamento complessivo del robot è determinato dall’interazione e
dalla cooperazione di tanti comportamenti elementari. Successivamente al lavoro di
Brooks, sono state presentate soluzioni nuove e più flessibili riguardo all’attivazione
dei vari behaviors.
L’obbiettivo finale è comunque quello di far avere al robot comportamenti funzionali allo scopo per il quale è stato costruito mediante l’integrazione di percezione,
decisione e movimento. In pratica, il robot dovrà muoversi secondo una logica che non
è direttamente implementata in una particolare sezione di codice, ma che è viceversa
il risultato dell’integrazione dei moduli di percezione, decisione e comunicazione con
gli altri robot. Possiamo sintetizzare questa tecnica con il termine purposive vision,
cioè l’integrazione di purposive action e visual perception.
Uno schema ad alto livello comprende quattro tipi di agenti principali: Percezione,
Decisione, Movimento e Comunicazione. Questi, cooperando tra di loro, formano
quello che può essere definito come agente fisico. Ogni agente a sua volta si può
considerare è costituito da un insieme di sub-agenti di più basso livello.
29
3.1.3 ETHNOS
Il sistema utilizzato per la gestione degli agenti è ETHNOS[18][19] (Expert Tribe
in a Hybrid Network Operating System), realizzato presso l’Università di Genova.
ETHNOS è un sistema basato sulle specifiche real time POSIX e fornisce le primitive
per la creazione di agenti, per la loro schedulazione e la loro interoperabilità, fornendo
un prefissato protocollo di comunicazione tra i processi. Gli agenti di ETHNOS sono
chiamati esperti e sono quelli che in precedenza sono stati definiti come sub-agenti.
In realtà non è detto che di per sè un esperto abbia tutte le caratteristiche per essere
definito come un agente, e cioè autonomy, social ability, reactivity, pro-activeness.
Ciò che conta è che un determinato insieme di esperti costituisca un agente con tutte le
carte in regola per essere definito tale. Possiamo descrivere semplicemente un esperto
come un programma che esegue ripetutamente una stessa porzione di codice, preposta
a risolvere un compito specifico. ETHNOS permette la schedulazione di tre tipi di
esperti:
Esperti periodici. Eseguono il proprio compito secondo una scadenza temporale prefissata.
Esperti sporadici. Eeguono il proprio compito in relazione al verificarsi di determinati eventi (ricezione di messaggi di attivazione).
Esperti di background. Eseguono il proprio compito solo quando il processore non è
occupato nell’esecuzione di esperti periodici o sporadici.
Possono essere creati anche esperti di subscheduling, con il compito di schedulare
esperti periodici o sporadici. La schedulazione avviene tramite il kernel, un programma che si interfaccia con lo scheduler di sistema gestendo le priorità degli esperti e
le comunicazioni tra di loro. In ETHNOS gli esperti sono programmati in linguaggio
C/C++.
Il kernel riconosce come esperto un qualunque oggetto appartenente ad una classe derivata dalla classe ETEepert. Tale classe genitrice mette a disposizione tre funzioni (Init,Do your duty e Close), che devono essere definite all’interno del codice
dell’esperto che si vuole creare.
30
START
Init
Do your duty
Close
STOP
Figura 3.1: Ethnos: il funzionamento di un esperto.
Init(). Questa funzione comprende una parte di codice che il kernel eseguirà una volta
sola, prima dell’attivazione dell’esperto.
Do your duty(int wc). È il codice vero e proprio dell’esperto, cioè quello che viene
eseguito ogni volta che il kernel cede il controllo all’esperto.
Close(). È analoga ad Init(), cioè si tratta di una parte di codice che il kernel eseguirà
una volta sola, dopo l’ultima esecuzione dell’esperto.
Ogni esperto in ETHNOS è dunque organizzato secondo tre blocchi funzionali.
Questi blocchi sono costituiti dalle procedure di inizializzazione (Init), di esecuzione
(Do Your Duty) e di chiusura (Close), come riportato in figura 3.1.
Condizioni di schedulabilità degli esperti. L’appartenenza di un esperto a uno dei
tre tipi elencati (esperti periodici, sporadici o di background) è conseguenza dei
parametri passati al costruttore della classe ETExpert e delle operazioni eseguite
31
all’interno della funzione Init(). In particolare, per gli esperti periodici è necessario specificare nel costruttore il periodo di attivazione ed è questo parametro
a determinarne la priorità sugli altri esperti in quanto più è breve il periodo di
attivazione, maggiore è la priorità. Per gli esperti sporadici o di background si
può impostare un livello di priorità prefissato. Il periodo di attivazione degli
esperti periodici ne determina anche la schedulabilità o meno. Infatti ETHNOS
è un sistema real time e deve perciò garantire la schedulabilità degli esperti. È il
kernel ad occuparsi di questo compito svolgendo un test di schedulabilità secondo l’algoritmo Rate Monotonic. Questo algoritmo pone come condizione per la
schedulabilità un fattore U di utilizzazione del processore
n
U
=
Ci
∑ Ti
i=1
<
0:69
dove Ci è il tempo di esecuzione dell’esperto i-esimo e Ti è il periodo dell’esperto
i-esimo.
3.1.4 Saphira
Saphira[2] è un’architettura per il controllo dei robot mobili sviluppata da Kurt Konolige ed implementata con successo su numerosi robot, tra cui i robot commerciali
Pioneer della ActivMedia[11]. Dal momento che sia TinoZoff che Galavrón sono nati
a partire da un robot Pioneer 1 ActivMedia, è opportuno accennare anche a Saphira
quale possibile sistema da utilizzare. Analogamente ad ETHNOS, il sistema Saphira
è dotato di uno scheduler, il cosiddetto micro-tasking OS, un sistema operativo che si
occupa di schedulare ciclicamente i task di controllo del robot e quelli definiti dall’utente. Più in dettaglio, Saphira è composta da due architetture distinte: la prima, detta
architettura di sistema (fig.3.2), si occupa delle operazioni basilari per il controllo del
robot. Nello specifico, a questo livello vengono inviati e ricevuti i pacchetti di comunicazione con il robot, viene aggiornata una copia dello stato interno del robot detta
state reflector ed inoltre vengono eseguiti i micro-task definiti dall’utente. La seconda
architettura, detta architettura di controllo (fig.3.3), consiste in una serie di micro-task
32
Micro tasks dell’utente e attività
Routines di controllo e applicazioni
State reflector
Routines
asincrone
definite
dall’utente
Pacchetti di comunicazione
Micro-tasking OS sincrono
Figura 3.2: Saphira: architettura di sistema.
che implementano tutte le funzioni necessarie alla navigazione del robot. Questa seconda architettura si basa sui dati provenienti dallo state reflector. Con Saphira i task
vengono programmati in linguaggio C/C++, mentre le attività sono programmate in
Colbert, un linguaggio pseudo-C interpretato, assai semplice da imparare.
3.1.5 Confronto tra Saphira ed ETHNOS
Un confronto in assoluto tra Saphira ed ETHNOS non è possibile in quanto, pur essendo entrambi sistemi ad agenti e potendo coesistere e scambiarsi messaggi nell’ambito
di una architettura ad agenti distribuita, presentano ad una analisi più approfondita
differenze sostanziali. In primo luogo la schedulazione dei processi è sostanzialmente
differente essendo più rigida in ETHNOS, ma anche fornendo per questo prestazioni di
gran lunga migliori rispetto a Saphira. Il controllo sulla schedulazione dei processi[19]
è totale in ETHNOS. Questo punto si è rivelato cruciale nella scelta di ETHNOS quale
sistema per la gestione degli agenti. Infatti, dal momento che risulta critico il tempo
di risposta del robot ad un comando di movimento, ETHNOS garantisce su questo
33
Linguaggio
Colbert
Routines
di visualizzazione
Global Map
Routines
di registrazione
Local
Perceptual
Space
Controllo
fuzzy
Controllo diretto
del movimento
Routines di gestione
dei sensori
State reflector
Figura 3.3: Saphira: architettura di controllo.
versante prestazioni migliori rispetto a Saphira. Viceversa, Saphira offre al programmatore la possibilità di utilizzare variabili fuzzy ed è dotata di tools di sviluppo e di
controllo decisamente più user friendly.
3.2 Gli esperti del robot
Gli esperti di Galavrón sono undici e si possono considerare appartenenti ad uno dei
tre agenti seguenti: percezione, elaborazione ed azione.
L’agente di percezione è descritto dalla funzione di transizione di stato:
W ORLD STAT E (k) INT STAT E (k) ! PERCEPT (k)
in cui:
WORLD STATE(k) è lo stato dell’ambiente esterno in cui opera l’agente fisico,
34
Esperto
Funzione
ETVision
ET Localization
ET Decision
ET Pioneer
ET FollowBall
ET TurboBoost
ET Intercept
ET Line
ET Parking
ETCommunication
ET Receive
Acquisizione e elaborazione immagini
Controllo posizione del robot
Decisione sul movimento
Comunicazioni con la scheda di controllo
Posiziona il robot davanti alla palla
Manda il robot incontro alla palla
Manda il robot in copertura della porta
Calibra l’odometria guardando le linee dell’area
Riporta il robot all’interno dell’area
Invia i messaggi agli altri robot
Riceve i messaggi dagli altri robot
Tabella 3.1: ETHNOS: gli esperti del robot.
INT STATE(k) è lo stato interno dell’agente fisico,
PERCEPT(k) è ciò che viene rilevato allo stato k.
L’agente di azione è descritto dalla funzione:
INT STAT E (k) ! WORLD STAT E (k + 1):
L’agente di decisione è il collegamento tra l’agente di percezione e quello di azione.
Esso presenta la seguente funzione di transizione di stato:
REASONING(k) : PERCEPT (k) KNOW LEDGE BASE ! INT STAT E (k + 1)
in cui KNOWLEDGE BASE rappresenta la base di conoscenze del sistema.
Vediamo in dettaglio un esperto appartenente a ciascuno dei tre agenti sopra descritti.
35
3.2.1 Copertura della porta
ETDecision è l’esperto che decide dove far muovere il robot considerato lo stato interno del robot e le informazioni della visione. L’esperto di decisione riceve messaggi
sulla posizione della palla dall’esperto di visione. Questi messaggi vengono elaborati
alla luce della conoscenza del sistema e dello stato interno e viene presa la decisione.
La decisione diviene operativa nel momento in cui viene prodotto un messaggio indirizzato all’esperto che deve compiere l’azione decisa e viene inviato al kernel. Si tratta
di un esperto sporadico, in modo da essere perfettamente sincronizzato con l’esperto di
visione. La “conoscenza del sistema” è costituita dalle strategie utilizzate per la navigazione e per il controllo delle azioni di gioco a seconda delle diverse situazioni che si
vengono a creare. Lo stato del sistema in un determinato istante è costituito dall’insieme dei messaggi che vengono prodotti in quell’istante, dai messaggi che provengono
dagli altri robot, dalle informazioni odometriche, dalle informazioni sulla palla e sulle linee e dallo stato precedente. Il codice che implementa l’esperto di decisione è
organizzato a grandi linee secondo lo schema:
- costruttore oggetto,
- inizializzazione,
- controlla se la palla è visibile, non visibile oppure è visibile ma non valida,
- in base allo stato della palla prende una decisione.
Sel la palla è visibile, l’esperto calcola la retta che congiunge la palla al centro
della porta e decide di muoversi verso il punto di intersezione con la retta sulla quale
si sta muovendo il robot (figura 3.4). Nel caso la palla sia troppo vicina al robot (entro
circa 50cm), l’esperto di decisione si limita a far stare il robot davanti alla palla.
3.2.2 Riposizionamento
Prima di introdurre il concetto di riposizionamento del robot e di come questo venga attuato, è importante sottolineare che il robot possiede costantemente determinate
Congiungente
palla-centro porta
36
Movimento del robot
in copertura
Figura 3.4: Esperto di decisione: strategia di copertura della porta.
informazioni sulla propria posizione in campo. In pratica, il robot è in grado di localizzarsi. Con il termine localizzazione si intende il processo che consente al robot di
individuare ed aggiornare la propria posizione e la propria orientazione grazie ai dati
provenienti dai sensori. Il processo di localizzazione può essere più o meno preciso,
questo dipende dal metodo e anche dal tipo di sensori utilizzati. Volendo migliorare
nella precisione è possibile utilizzare metodi di localizzazione sofisticati, oppure sensori più precisi. Entrambe le soluzioni presentano costi. In particolare, metodi più
sofisticati presuppongono una maggior pesantezza computazionale che non sempre è
compatibile con l’applicazione reale. Galavrón è in grado, sia pure con alcuni limiti,
di autolocalizzarsi, cioè di compiere autonomamente il processo di localizzazione.
Per riposizionamento del robot si intende una manovra al termine della quale il
robot si riporta in una posizione predefinita e con una orientazione predefinita. La
manovra di riposizionamento può anche prevedere una calibrazione dell’odometria del
robot se questa si discosta troppo dalle informazioni che il robot ricava dai suoi sensori.
L’odometria è quell’insieme di informazioni che consentono al robot di conoscere il
cammino percorso sul terreno a partire da una posizione iniziale nota. Di fatto, gli
odometri (composti da una parte hardware, gli encoder dei motori, e dal software di
decodifica) sono sensori di posizione relativi. Essi cioè aggiornano costantemente la
37
posizione rispetto a quella che il robot possedeva nello stato precedente.
Nel caso del robot portiere il riposizionamento consiste nel far tornare il robot all’interno dell’area di porta, al centro, e con una orientazione parallela al fondo campo.
Il robot, cioè, torna in quella che è la sua posizione iniziale. In una successiva sezione viene trattato più in dettaglio l’esperto di riposizionamento ed il suo diagramma di
flusso.
3.2.3 Visione
La visione consiste nell’acquisizione delle immagini dalle telecamere e dalla elaborazione per ottenere le informazioni volute. A questo scopo è preposto l’esperto di
visione ETVision. Compito principale dell’esperto di visione è dunque quello di restituire la posizione della palla rispetto al robot a partire dalle immagini acquisite. La
funzione Do Your Duty dell’esperto di visione contiene al suo interno le funzioni di
acquisizione delle immagini, di filtraggio delle stesse alla ricerca dei pixel rossi (colore
della palla) e di calcolo delle coordinate della palla.
L’esperto di visione è un esperto periodico con un periodo di 100ms. Il codice che
implementa l’esperto è organizzato a grandi linee secondo lo schema:
- costruttore oggetto;
- inizializzazione telecamere;
- inizializzazione buffers (aree di memoria che contengono le immagini);
- caricamento tabelle di look-up (servono per convertire le coordinate in pixel in
centimetri sul sistema di riferimento solidale col robot);
- acquisizione immagini;
- ricerca palla;
- calcolo posizione;
- invio messaggio di localizzazione palla.
38
Il sistema di riferimento scelto è un sistema ortogonale con l’asse delle ascisse
disposto parallelamente alla porta con direzione positiva verso destra e con l’asse delle
ordinate perpendicolare alla porta con direzione positiva verso centro-campo.
3.3 Interazione con il mondo
3.3.1 Controllo del movimento
Il controllo del movimento viene svolto a basso livello dal sistema operativo della scheda di controllo (PSOS o KaOS). A più alto livello è l’esperto di decisione a inviare la
maggior parte dei comandi di movimento in base alle decisioni prese. Vi sono tuttavia anche altri esperti che saltuariamente possono scavalcare l’esperto di decisione.
Uno di questi è l’esperto ETTurboboost. Quando la palla si trova a fianco del robot,
la strategia migliore è quella di far muovere il robot verso la palla il più velocemente
possibile. L’esperto ETTurboboost ha proprio questo compito e viene attivato in condizioni d’emergenza quando evidentemente la strategia di copertura precedentemente
illustrata ha fallito. Gli esperti che inviano comandi di movimento richiamano determinate funzioni in una classe messa a disposizione dall’esperto ETPioneer il quale
si occupa della gestione del protocollo di comunicazione con la scheda di controllo
tramite la porta seriale.
3.3.2 Strategia di attivazione del kicker
L’esperto di decisione, sulla base dei messaggi di posizione della palla, decide se abilitare o meno il sistema di calcio (kicker). Se il robot non vede la palla, il kicker viene
disabilitato in modo da evitare di attivarlo in caso di urti contro altri robot o contro i
bordi del campo. Viceversa, nel caso in cui la palla rimanga ferma a pochi centimetri
dal robot, l’esperto di decisione può forzare l’attivazione delle elettrovalvole per cercare comunque di spazzare la palla. Siccome il KaOS disabilita a sua volta il kicker
se gli infrarossi rilevano un ostacolo, tale attivazione forzata da parte dell’esperto di
decisione scavalca il KaOS e determina comunque un calcio.
39
Y
11111111111
00000000000
00000000000
11111111111
00000000000
11111111111
90°
180°
0°
X
Fascia di posizione
270°
Figura 3.5: Zona di corretta posizione del robot e sistema di riferimento adottato.
3.4 Esempio: l’esperto di riposizionamento
Come anticipato, l’esperto di riposizionamento (ETParking) ha il compito di riposizionare il robot nell’area, in posizione centrale. Questo esperto viene familiarmente
chiamato anche esperto di parcheggio in quanto la manovra che fa compiere al robot è
assai simile a quella di una automobile che parcheggia.
Viene attivato nei casi in cui il robot sia avanzato eccessivamente (addirittura fuori
dall’area) o sia arretrato eccessivamente (addirittura all’interno della porta). Il riposizionamento avviene esclusivamente in base alle informazioni odometriche, per cui
sorge la necessità di convalidarlo mediante la visione (esperto ETLine). L’esperto
ETParking è un esperto sporadico e viene attivato nel momento in cui l’esperto di decisione produce il messaggio MSG PARKING. Il robot viene riposizionato facendogli
compiere le seguenti manovre fondamentali:
- ruota fino a formare un angolo di 45 gradi con la linea di porta (la rotazione avviene
nel verso in cui è minore l’angolo da descrivere per raggiungere la posizione
desiderata);
- avanza o arretra fino a raggiungere la corretta posizione;
- ruota in senso contrario rispetto alla prima rotazione, in modo da disporsi parallelamente alla linea di porta;
40
- si dispone in posizione centrale rispetto alla porta;
- attiva l’Esperto ETLine per convalidare la manovra di parcheggio mediante la visione.
Nel caso in cui la palla risulti visibile mentre sta compiendo manovre di parking
l’esperto di decisione può interrompere la manovra inviando all’esperto di parcheggio
il messaggio di stop. L’esperto può essere modellato mediante un Automa a Stati Finiti
(ASF), come mostra la figura 3.7. Ogni stato rappresenta una manovra del robot. In
rosso sono evidenziati i passaggi di stato allorchè il robot vede la palla ed è costretto
perciò ad interrompere la manovra di riposizionamento. Gli stati sono i seguenti:
A: controlla che il robot sia nella fascia di tolleranza consentita lungo l’asse y. In caso
positivo passa allo stato B, altrimenti allo stato H.
B: controlla l’allineamento. Se il robot forma un angolo diverso da 0 gradi (5o di tolleranza) con la linea di porta, lo fa ruotare finché tale posizione viene raggiunta.
In questo caso si passa allo stato H.
H: ci si arriva da A se l’ordinata del robot non è nella fascia consentita (figura 3.5).
Controlla se il robot si trova a destra o a sinistra del centro della porta.
C: se il robot è a destra del centro della porta ruota di +45o .
D: si muove verso sinistra finché non raggiunge la stessa y.
E: se il robot è a sinistra del centro della porta ruota di
45o .
F: si muove verso destra finché non raggiunge la stessa y.
I: riposiziona il robot al centro della porta.
L: attiva l’esperto ETLine, in modo che il robot si allinei con la riga bianca che
delimita l’area.
Da notare che lo stato L attiva l’esperto ETLine direttamente, scavalcando il meccanismo standard secondo il quale dovrebbe segnalare all’esperto di decisione la necessità di attivare l’esperto ETLine.
START
41
START
Y
nel range
consentito?
Sì
STATO(k+1)=B
START
Orientaz.
nel range
consentito?
No
No
Ruota il robot
Orientaz.
intorno a
+45°?
Sì
No
Ruota il robot
Sì
STATO(k+1)=H
STATO(k+1)=I
STATO(k+1)=D
STOP
STOP
STOP
(a) Stato A.
(b) Stato B.
START
(c) Stato C.
START
Orientaz.
intorno a
+45°?
No
STATO(k+1)=C
Sì
START
Orientaz.
nel range
consentito?
No
Orientaz.
intorno a
-45°?
STATO(k+1)=B
Sì
Y
nella zona
corretta?
No
Muoviti a sinistra
Sì
No
Sì
X
tra -100mm
e +100mm?
No
Y
nella zona
corretta?
Muove il robot
Sì
No
STATO(k+1)=L
STATO(k+1)=B
STOP
STOP
STOP
(e) Stato I.
START
(f) Stato F.
START
Sì
X
>=0?
Muoviti a destra
Sì
STATO(k+1)=B
(d) Stato D.
STATO(k+1)=E
STATO(k+1)=C
No
Orientaz.
intorno a
-45°?
No
Ruota il robot
START
Sì
Attiva esperto ETLine
STATO(k+1)=E
STATO(k+1)=F
STOP
STOP
(g) Stato H.
STOP
(h) Stato E.
(i) Stato L.
Figura 3.6: Esperto ETParking: analisi dei singoli stati.
Figura 3.7: Esperto ETParking: diagramma degli stati.
Robot entro la fascia
di posizione
Robot fuori dalla
fascia di posizione
B
H
Robot a destra
della porta
Robot entro la fascia
di posizione
Robot a sinistra
della porta
C
A
Riposizionamento
completato
E
L
Angolo
errato
Robot
allineato
con la porta
Angolo
+45°
D
Angolo
errato
Angolo
-45°
F
Robot centrato
correttamente
rispetto alla porta
I
42
Capitolo 4
Il sistema di potenza
4.1 Alimentazione a batterie
L’alimentazione tramite batterie è una componente critica della costruzione del robot.
Attualmente vengono infatti utilizzate batterie al Pb-acido. Sono però disponibili anche batterie di diversi tipi. Vediamo di analizzare i pro e i contro delle più comuni
batterie1 cominciando dai parametri che devono guidare nella scelta[9][13]. Anche se
tutti i parametri seguenti sono importanti nella scelta del tipo di batterie da utilizzare
in ambito robot mobili, è però chiaro che non tutti hanno lo stesso peso nella decisione
finale.
4.1.1 Parametri da considerare
Energia specifica (o densità di energia o capacità). Determinata dalla tensione della cella e dalla quantità di carica che può essere immagazzinata, E = qV . Questo
parametro è solitamente valutato sulla base del peso o del volume della cella:
Capacità teorica in peso = qV =massa (Watt hr=kg)
Capacità teorica in volume = qV =volume (Watt hr=l )
1 Le
informazioni tecniche contenute in questa sezione sono state reperite nei siti internet di vari
produttori, in particolare Varta (www.varta.com) e Duracell (www.duracell.com). Essenziali
sono state anche le informazioni reperite nel newsgroup sci.chem.electrochem.battery.
43
Capitolo 4. Il sistema di potenza
44
I valori teorici sono raggiunti solo in parte, specialmente a causa del fatto che
tali valori trascurano il rapporto peso / volume dei componenti inattivi. Più
correttamente, la capacità è il prodotto della densità di energia per la massa della
cella ed è riportata in Ah o mAh.
Potenza specifica (o densità di potenza). Solitamente valutata in termini di massa
della cella:
Potenza specifica = E tempo=massa = qV =hr massa della cella (W =kg)
Questo parametro è legato alla densità energetica dato un certo tasso di scarica
e indica quanto rapidamente può essere scaricata la cella e quanta potenza viene
generata. Una cella con un’alta densità energetica può fornire una tensione elevata e una riduzione di capacità con alti tassi di scarica e perciò avere una bassa
densità di potenza.
Potenziale della cella. Tensione operativa ai capi della cella e profilo di scarica[9]. In
figura 4.1 sono disegnati i profili di scarica per alcuni tipi di celle. Essi indicano
come varia il potenziale della cella durante la fase di scarica.
Carica/scarica. Numero di cicli di carica/scarica che una cella può sopportare.
Tasso di autoscarica. Indica quanto rapidamente la batteria perde potenziale quando
viene lasciata carica e inutilizzata.
Vita utile. Durata di vita della cella, espressa in anni, indipendentemente dal fatto che
la batteria venga utilizzata o meno.
Sicurezza. Situazioni di potenziali pericoli causati dal modo di impiego o da un errato
utilizzo della batteria, tossicità dei materiali, reattività dei componenti, comportamento in corto circuito o in caso di danneggiamento del rivestimento.
Ambiente ed ecologia. Queste considerazioni riguardano in primo luogo l’impiego di
materiali non tossici per l’uomo e per l’ambiente e la possibilità di riciclaggio.
45
Figura 4.1: Profili di scarica per diversi tipi di celle.
Condizioni operative speciali. Vi sono batterie adatte per alte o basse temperature,
batterie sigillate che possono essere utilizzate in qualunque posizione, batterie
pressurizzate. Non è il caso dei robot mobili, tuttavia vi può essere necessità di
garantire biocompatibilità.
Costo. Anche se è stato lasciato per ultimo, non è certo un parametro trascurabile.
Determinate tecnologie costruttive presentano a tutt’oggi un costo che le rende
impraticabili, tuttavia siccome l’evoluzione in questo campo è abbastanza rapida
(sulla scia della diffusione di apparati portatili come telefoni cellulari o laptop),
è probabile che in un prossimo futuro questo parametro incida meno nella scelta.
4.1.2 Tipi di batterie
Piombo-acido. È il tipo di batteria utilizzato. Queste batterie sono utilizzate principalmente dall’industria automobilistica. Ne esistono diversi tipi a seconda delle
applicazioni. In generale le celle sono costituite da un catodo di PbO2 , un anodo
46
di Pb e un elettrolita di acido solforico. Le due reazioni agli elettrodi sono:
Pb + SO4
= PbSO4
PbO2 + 4H + + 2e
+ SO4
(sol ) + 2e
= PbSO4
(sol )
Entrambi gli elettrodi si dissolvono nell’elettrolita durante la reazione di scarica.
Durante il processo di carica avvengono le reazioni inverse, tuttavia una carica eccessivamente protratta (overcharge) porterà all’elettrolisi dell’acqua con la
conseguente formazione di H2 gassoso (pericolosissimo!) al catodo. Le batterie
al Pb-acido sigillate, in commercio dagli anni ’70, non richiedono il rabbocco
periodico dell’elettrolita. Ciò si ottiene inserendo un ricombinante catalitico che
produce acqua dall’idrogeno e dall’ossigeno che talvolta si formano durante il
processo di carica. Le celle hanno un potenziale nominale di 2V, hanno un costo
decisamente basso e hanno una elevata densità di potenza (necessaria all’avviamento dei motori a scoppio, può arrivare a 600 W/kg). Altro vantaggio è la facile
reperibilità di diversi formati. Una batteria del robot costa intorno alle 50000 lire. Volendo aumentare l’energia immagazzinata a bordo del robot è sufficiente
sostituire le batterie con altre. Un altro vantaggio delle batterie al Pb-acido è
la loro bassa resistenza interna, che si traduce in una ottima capacità di fornire
correnti di spunto. Possono sopportare alcune centinaia di cicli di carica/scarica
(intorno a 500). Se però vengono scaricate completamente, tale limite si abbassa
drasticamente. Tuttavia l’inconveniente principale che queste batterie comportano è il peso che in talune applicazioni può risultare eccessivo. Infatti la densità
di energia di queste celle è tipicamente inferiore a 100 W hr/kg. Le batterie di
TinoZoff pesano 1,7kg ciascuna.
Nickel-Cadmio. Queste celle contengono un catodo composto di Ni(OH )2 , un catodo
di cadmio e un elettrolita acquoso composto di KOH. La reazione complessiva
nella cella è
2NiOOH + 2H2 O + Cd = 2Ni(OH )2 + Cd (OH )2
Figura 4.2: Effetto memoria per le celle al Ni-Cd.
47
48
Le batterie composte da celle al Ni-Cd possono sopportare più di 1000 cicli di
carica/scarica. Presentano gli stessi vantaggi delle batterie al Pb-acido, tranne
per il fatto che hanno un costo lievemente superiore e la loro disponibilità è
limitata ai formati commerciali AAA, AA, C, D e pochi altri. Una cella al Ni-Cd
fornisce una tensione di 1,2V che rimane pressoché costante durante il processo
di scarica. Questo è un problema nel momento in cui si vuole determinare il
livello di carica. Altro problema è l’effetto memoria (fig.4.2) di cui questo tipo
di batterie risente, cioè la progressiva riduzione nella capacità di immagazzinare
energia qualora vengano ricaricate dopo cicli di scarica non completi. L’effetto
memoria comporta l’impossibilità di utilizzare la carica residua di una cella a
Ni-Cd se essa non viene completamente scaricata. Ciò è dovuto alla formazione
di una superficie passiva agli elettrodi. Questa superficie si comporta da barriera
a ulteriori reazioni chimiche nella cella.
Nickel-Metalidrato. Nelle celle al NiMH l’anodo è un elettrodo composto da un metallo idrato che serve da sorgente solida di idrogeno che possa essere ossidato
per formare protoni. La reazione all’anodo è:
MH + OH
= M + H2 O + e
perciò la reazione completa della cella diventa:
NiOOH + MH = Ni(OH )2 + M
Gli anodi sono costituiti da metalli in grado di intrappolare idrogeno, ad esempio
Pd. Tuttavia questi non sono utilizzati nelle celle al NiMH per svariate ragioni
tra cui il costo del palladio. Gli anodi usati in questo tipo di celle sono allora
leghe composte di diversi metalli come vanadio, titanio, zirconio, nickel, cromo,
cobalto e ferro. Tali leghe si dividono in due classi: tipo AB5 come ad esempio
la lega LaNi5 e tipo AB2 come ad esempio TiMn2 o ZrMn2 . Sono da preferire
anodi formati da leghe di tipo AB5 poiché offrono una migliore resistenza alla
corrosione. Le batterie al Nickel-Metalidrato conservano molti dei vantaggi dei
49
quelle al Ni-Cd, in particolare un lungo ciclo di vita utile, mantenendosi superiori in quanto a densità di energia e di potenza. Lo svantaggio principale di
queste batterie è il costo che va da 4 a 10 volte quello di una analoga batteria al
Pb-acido.
Litio e ioni di litio. Le batterie agli ioni di litio sono una tecnologia nuovissima essendo in commercio solo dalla metà degli anni ’90. Rispetto agli altri tipi di
batterie fin qui presentati, quelle agli ioni di litio sono le più delicate in assoluto
e vengono utilizzate in quelle applicazioni che richiedono alte densità di energia e dove il costo è un parametro trascurabile. Due batterie agli ioni di litio
da 10,8V-4,5Ah sono state acquistate per il robot Galavrón. Il costo di una di
queste batterie è circa sette volte quello di una equivalente batteria al Pb-acido.
Le prime batterie al litio non ricaricabili sono state commercializzate intorno al
1970, tuttavia gli studi per ottenere batterie al litio ricaricabili sono proseguiti
per oltre vent’anni a causa di problemi legati alla sicurezza. Il litio è il metallo
più leggero, ha il potenziale elettrochimico più alto e fornisce il più elevato contenuto energetico. Le batterie ricaricabili che usano il litio come elettrodo sono
perciò in grado di fornire sia una tensione elevata, che una eccellente densità
energetica (grazie al minor peso). A causa però dell’intrinseca instabilità del
litio metallico, in particolare durante il processo di carica, le batterie ricaricabili
basate sul litio oggi in commercio fanno uso di ioni di litio ottenuti da composti
quali il biossido di litio-cobalto (LiCoO2 ). Diversamente dalle batterie al litio
(che possono anche esplodere), le batterie agli ioni di litio sono relativamente
sicure. I vantaggi delle batterie agli ioni di litio sono sostanzialmente l’elevata
densità di energia (100 W hr/kg), l’assenza di effetto memoria e il ciclo di vita
che permette fino a 500800 cicli di carica/scarica. Gli svantaggi sono dovuti
al costo e al rischio di danneggiamento dovuto all’overcharge o a corto circuiti.
Alcaline non ricaricabili. Le batterie alcaline sono batterie primarie, cioè non ricaricabili2 . Le batterie alcaline concettualmente sono simili alle pile Leclanchè,
2 In
commercio esistono anche batterie alcaline ricaricabili, tuttavia il loro brevissimo ciclo di vita
(massimo 3050 cicli di carica/scarica) le rende impraticabili per l’impiego nei robot mobili.
50
cioè Zinco-carbone, ma fanno uso di un elettrolita alcalino (KOH) più conduttivo, anziché acido come nelle celle Zinco-carbone. Questo abbassa la resistenza
interna della cella e di conseguenza permette di ottenere tassi di scarica più elevati e maggiori densità di potenza. Questo tipo di celle solitamente ha un anodo
di Zn sinterizzato e un catodo di MnO2 anch’esso sinterizzato a cui viene aggiunta polvere di grafite per aumentarne la conduttività. L’elettrolita è in gel
con l’aggiunta di derivati della cellulosa. Le reazioni agli elettrodi in ambiente
basico sono:
Zn + 2OH
= Zn(OH )2 + 2e
2MnO2 + H2 O + 2e
= Mn2 O3 + 2OH
Le batterie alcaline hanno densità di energia teorica paragonabile a quelle Zncarbone, cosı̀ come hanno lo stesso potenziale di cella (1,5V), ma forniscono
valori di energia più alti sperimentalmente. Esse sono tuttavia più costose. In
particolare bisogna considerare che non sono ricaricabili3 e quindi non sono
proponibili in ambito robot mobili. Un tipo di cella alcalina molto interessante
è quella a Zinco-aria in cui lo zinco è ossidato come prima, mentre al catodo si
ha la seguente reazione:
O2 + H2 O + 4e
= 2OH
La reazione complessiva della cella è dunque:
2Zn + O2 = 2ZnO
Di fatto questa è un ibrido tra una batteria e una cella a combustibile in cui il
combustibile (l’O2 presente nell’aria) è illimitato e non aggiunge peso alla cella.
3 Le
batterie alcaline non ricaricabili possono essere “rigenerate” mettendole per alcune ore in un
caricabatterie. Questo processo (che non è una ricarica vera e propria) può essere ripetuto due o tre
volte al massimo. Esso restituisce alla batteria una durata che è circa il 2030% di quella iniziale[14].
Densità
di energia
Whr kg)
Pot.
cella
V
=
( )
40
38 60
2; 1
1; 2
NiMh
60 80
1; 2
Litio
300
3; 0
Ioni Li
Alcaline
non ric.
Duracell
Alcaline
ricaricab.
Zn-aria
110
140
3; 6
1; 5
80
1; 5
310
1; 4
Tipo
Pb-acido
Ni-Cd
(
51
Capacità
mAh)
(
1 120Ah
AA 800
C
1500
D 2500
AA 1200
C
2200
D 4000
C
5000
D 14000
1 4Ah
AA 2800
C
7800
D 15000
Resist.
interna
Carica
( )
0; 006
0; 009
scarica
500
più di
1000
0; 1
500
0; 3
800
0; 1
30
Tabella 4.1: Confronto delle caratteristiche di diversi tipi di batterie.
Questo rende le celle a Zn-aria convenienti in quanto a densità di energia (si
raggiungono valori anche di 900 W hr/kg). Anche se questo tipo di celle non è
reversibile, tuttavia lo ZnO può essere rimosso dalle celle esaurite e sottoposto
ad elettrolisi per riformare Zn metallico.
4.2 Più potenza
Un problema che è emerso nel corso dello sviluppo del robot è che il tempo di risposta
ad un comando di movimento deve essere quanto più rapido possibile. Risulta evidente la necessità di dotare il robot di un sistema hardware all’altezza delle prestazioni
richieste.
52
Figura 4.3: Velocità del robot con diversi carichi.
Lo sforzo maggiore si è concentrato sui motori[7]. I motori del robot sono motori
in corrente continua, a magneti permanenti, con spazzole e collettore, controllati in
tensione d’armatura[6]. I robot Pioneer 1 ActivMedia[1] sono dotati di una scheda che
comprende la parte di controllo dei motori e quella di potenza. L’integrato che invia la
potenza ai motori è un L298N della ST. Il vantaggio di tale integrato è che è composto
da due banchi indipendenti e quindi ne serve uno solo per controllare due motori in
corrente continua. La scheda di controllo dei motori è però dimensionata per un Pioneer 1 il quale, stando al manuale, ha una massa di 7,7kg e un carico utile dichiarato
di 4,5kg. Usando come base un Pioneer 1, sono stati aggiunti diversi componenti e la
massa complessiva del robot ha superato i 25kg. È chiaro che questo incremento di
massa ha causato notevoli problemi nella reattività del robot TinoZoff.
Per avere un’indicazione quantitativa dei problemi di reattività sono stati fatti alcuni test. In fig.4.3 è rappresentato il risultato di uno di questi test. Al robot vengono
53
impartiti due comandi distanziati di 4 secondi. Il primo comando viene dato all’istante
zero ed è un comando di speed (1000)4 , cioè il programma ordina al robot di partire
verso destra alla massima velocità. Dopo 4000 millisecondi viene dato un comando
di speed ( 1000), per cui il robot deve invertire la direzione. Si è valutata la reazione del robot TinoZoff con diverse condizioni di carico. La condizione ideale è quella
disegnata in rosso ed è stata ottenuta con il robot sollevato dal terreno: si tratta quindi
di una condizione puramente teorica, che pone un limite alle prestazioni. Con il robot
in configurazione da gara la curva della velocità è quella disegnata in rosa. Le curve
blu e verde sono state ottenute con il robot sul campo, ma alleggerito di alcuni kg. In
particolare la curva blu è stata ottenuta alleggerendo il robot di 2.9kg, mentre quella
verde alleggerendo di 3.5kg. Risulta evidente che, in configurazione da gara, il robot
raggiunge la velocità impostata dopo circa tre secondi. Questo è un tempo altissimo
poiché significa che nella realtà non potrà mai arrivare a raggiungere una velocità di
1000mm=sec, infatti il robot portiere deve muoversi all’interno dell’area di porta, che
è un rettangolo di 3 metri per 1.
Ci siamo cosı̀ trovati ad avere un sottosistema di movimento diventato insufficiente.
Inoltre va considerato che non è sempre possibile lavorare sul versante della riduzione
della massa del robot. Infatti un robot “leggero” potrebbe trovarsi in difficoltà negli
scontri con gli altri robot. La situazione a cui si era giunti non era però più sostenibile
anche a causa del fatto che l’integrato L298N subiva forti sollecitazioni. Già prima
della partenza per la RoboCup ’99 si sono manifestati malfunzionamenti di questo
integrato.
4.2.1 La scheda di potenza
Proprio a causa delle limitazioni imposte dall’integrato L298N, si è deciso di progettare una scheda che fosse in grado di fornire una maggiore potenza ai motori. L’L298N
limita la corrente erogabile ad ogni motore a 2A. Ricercando tra gli integrati disponibili per sostituirlo, la scelta è caduta sull’LMD18200 della National Semiconductors.
dettaglio, si assegna alla classe ETPioneer la velocità 1000, cioè 1000mm=sec, tramite il
comando ETHNOS Topazia > SetSpeed (1000).
4 In
Tensione d’armatura
Resistenza elettrica
Induttanza
Costante di coppia
Gradiente tensione motore
Corrente di stallo
Rapporto di riduzione
54
Grandezza
Valore
E
R
L
kT
kE
IS
N
12V
0:83Ω
0:63 10 3H
18:22 10 3N m=A
18:24 10 3V s=rad
14:46A
19:7 : 1
Tabella 4.2: Parametri dei motori del robot.
La caratteristica principale di questo integrato è quella di fornire fino a 3A di corrente
in continua. Inoltre l’LMD18200 possiede una serie di protezioni e di controlli che
ne rendono più facile l’utilizzo rispetto all’L298N quali un segnale di thermal flag e
un input di brake. Infine, l’LMD18200 ha i diodi di ricircolo della corrente che sono
integrati, mentre con l’L298N servono 4 diodi a recupero rapido per ogni motore.
I motori dei Pioneer sono motori Pittman serie GM9034 e sono alimentati a 12 Volt,
questo poiché l’alimentazione sui Pioneer è garantita da una sola batteria da 12V. I parametri principali dei motori sono riportati in tabella in quanto, nei datasheets forniti,
la Pittman li riporta solo in once e pollici e non in grandezze SI. Siccome su Galavrón sono presenti due batterie da 12V in serie per garantire 24V all’alimentatore del
PC, si è pensato di utilizzarli per alimentare a 24V anche i motori in modo da ottenere
maggiore potenza, anche in base alle indicazioni di [6], che danno come parametri ottimali per questo tipo di robot una tensione di alimentazione E = 24V con una corrente
massima Imax
=
6:2A ed un rapporto di riduzione di 19:7 : 1. La scheda di potenza
dei motori è stata pensata per ricevere in ingresso tensioni da 12 a 35V. Tuttavia, una
volta collegati i 24V, si sono avuti problemi nella lettura degli encoder dei motori con
conseguenti instabilità del controller. Per risolvere questo problema si è lavorato su
due fronti. Innanzitutto è stata realizzata una scheda aggiuntiva di alimentazione dei
motori. Tale scheda accetta in ingresso tensioni da 21 a 35V e restituisce in uscita 18V
stabilizzati, con un assorbimento massimo di corrente di 5A. D’altra parte si è deciso
55
Figura 4.4: Funzionamento degli encoders incrementali.
di migliorare anche la gestione degli encoder, per lo meno campionando i segnali ad
una frequenza maggiore di quella garantita dal PSOS.
4.2.2 Il KaOS
Per il robot Galavrón è stato sviluppato in assembler5 anche un altro sistema operativo,
detto KaOS (Karlo Operating System), che può essere scaricato sul microprocessore.
Questo sistema operativo è nato per superare le limitazioni del PSOS in fase di campionamento dei segnali degli encoder6 . Il funzionamento del KaOS (vedi figura 4.5) si
basa su tre routines principali attivate da tre segnali di interrupt. Due di questi (l’interrupt TOC 4 e l’interrupt TOC 5) sono temporizzati, mentre il terzo (l’interrupt dell’interfaccia di comunicazione seriale) si attiva ogniqualvolta il microprocessore riceve un
carattere dal PC. I parametri del KaOS sono per la maggior parte fissati all’interno del
codice assembler. Possono essere variati soltanto il revcount, l’acc e il parametro
experim, che però ha un significato differente. Ponendo experim a 1 si attivano
funzioni supplementari quali l’obstacle avoidance tramite i sensori infrarossi e l’ini5 Fondamentale
per lo sviluppo del KaOS come di qualunque altra applicazione con il 68HC11 è il
manuale di riferimento[16], presente sul sito www.mot-sps.com in formato PDF. Per assemblare il
codice si è utilizzato l’assemblatore A6801 ed il linker XLINK, operanti in ambiente Windows. Sono
stati realizzati anche alcuni tools di sviluppo ad hoc.
6 Gli encoder dei motori del robot sono del tipo incrementale a quadratura di fase (figura 4.4), a
due canali (A e B), senza il canale I, e prevedono 100 impulsi per giro dell’albero motore[7]. I due
canali possono presentare quattro diversi stati, per un totale di 400 stati per giro di albero motore.
Siccome il motore ha un rapporto di riduzione di 19.7:1, per ogni giro di ruota vi sono 7880 diversi
stati. La risoluzione degli encoder si calcola dividendo la circonferenza della ruota (che ha un diametro
di 125mm) per 7880.
INTERRUPT TOC 4
Frequenza: 12500 Hz
56
Lettura degli encoder
Impostazione delle PWM ai motori
INTERRUPT TOC 5
Frequenza: 1250 Hz
Controllo dei motori
Analisi dei dati dei sensori
Blocco motori di emergenza
Visualizzazione sul display LCD
Spedizione pacchetti di comun.
Esecuzione dei comandi
INTERRUPT SERIAL C.I.
Attivo alla ricez. di un car.
Ricezione dei pacchetti dal PC
Figura 4.5: Schema di funzionamento del sistema operativo KaOS.
57
bizione del kicker. Viceversa, ponendo a zero questo parametro, le informazioni dei
sensori infrarossi vengono passate direttamente al PC.
Il KaOS è nato esclusivamente con lo scopo di poter campionare i segnali degli
encoder ad una frequenza maggiore rispetto a quella garantita dal PSOS (10kHz). Per
ottenere questo risultato sono state sacrificate importanti funzioni che il PSOS offre,
e cioè: nel KaOS manca la gestione dei sonar, della bussola, dei servomotori, del
livello delle batterie e del cicalino. Inoltre il set dei comandi, pur mantenendosi fedele
al protocollo di comunicazione del PSOS, è più ridotto e presenta comandi diversi
sviluppati appositamente per Galavrón quali quelli dedicati al kicker.
4.2.3 Controllo dei motori
Per una spiegazione dettagliata del controllo dei motori si rimanda a [6] per la parte
del controllo hardware e a [7] per la parte del controllo proporzionale-integrativo. In
questo paragrafo tratteremo brevemente di come generare a livello del microprocessore i segnali necessari al controllo. I motori vengono controllati dal microprocessore
68HC11 tramite i segnali di direzione e di velocità. Quest’ultimo è un segnale in formato a modulazione di ampiezza di impulso (PWM - Pulse Wave Modulation). La
velocità di rotazione di un motore viene variata cambiando il duty cycle del segnale
PWM in modo da fornire una tensione media all’armatura pari a quella desiderata.
All’interno del KaOS, la routine che si occupa di variare il duty cycle della PWM
è quella dell’interrupt TOC4[16]. Essa viene eseguita ad una frequenza di 12500Hz,
per cui trascorrono 80µs tra un’esecuzione e la successiva. Siccome la versione del
68HC11 utilizzata (la F1[15]) non prevede direttamente alcuna uscita PWM, è compito
del programmatore occuparsi di ottenerle. Dunque il KaOS utilizza gli interrupt TOC1
e TOC2 come monostabili variandone la durata di attivazione tra un minimo di 5µs7
ed un massimo di 80µs (massima velocità), che corrisponde non più ad una PWM,
ma ad un segnale continuo. Questi due interrupt agiscono su due pin di output del
7
Il limite minimo è necessario in quanto gli integrati di potenza non vengono attivati da impulsi
troppo brevi. Nel caso dell’LMD18200 l’impulso minimo è di 1µs, mentre per l’L298N è di 3µs.
58
V
PWM del 25%
1111
0000
0000
1111
0000
1111
0000
1111
0
V
11111
00000
00000
11111
00000
11111
00000
11111
40
80
11111111
00000000
00000000
11111111
00000000
11111111
00000000
11111111
11111111
00000000
120
111111111
000000000
000000000
111111111
000000000
111111111
111111111
000000000
111111111
000000000
PWM del 50%
0
V media ai motori
40
80
160
µs
160
µs
V media ai motori
120
Periodo: 80µs
Figura 4.6: Potenza ai motori: modulazione ad ampiezza di impulso (PWM).
68HC11[15]. Volendo spegnere i motori è sufficiente disattivare gli interrupt TOC1 e
TOC2.
La routine assembler di controllo dei segnali PWM dei motori è, come detto, contenuta all’interno della routine dell’interrupt TOC4. Viene riportata qui di seguito senza
ulteriori commenti8. Per approfondimenti si faccia riferimento a [16] e [15].
8 Con
LDX
#Registers
LDD
Word_PWM_cycl_ant
BEQ
TOC4_Int_b
ADDD
TCNT,X
STD
TOC1,X
BCLR
OC1D,X,#B7
BSET
CFORC,X,#B7
BSET
OC1D,X,#B7
il 68HC11 vi sono diversi modi per ottenere un’onda PWM. Essi dipendono anche dal tipo di
hardware intorno al processore. Una soluzione diversa è illustrata in [9].
Pin n.ro
35
36
27
26
59
61
63
65
59
Nome
PA7/TOC1
PA6/TOC2
PG0
PG1
PE0
PE1
PE2
PE3
Funzione
PWM motore anteriore
PWM motore posteriore
Direzione motore anteriore
Direzione motore posteriore
Encoder A motore anteriore
Encoder B motore anteriore
Encoder A motore posteriore
Encoder B motore posteriore
Tabella 4.3: 68HC11F1: pins utilizzati nel controllo dei motori.
TOC4_Int_b
TOC4_Int_a
LDD
Word_PWM_cycl_post
BEQ
TOC4_Int_a
ADDD
TCNT,X
STD
TOC2,X
BCLR
TCTL1,X,#B6
BSET
CFORC,X,#B6
BSET
TCTL1,X,#B6
BSET
OC1D,X,#B7
4.2.4 Sviluppi futuri del KaOS
Futuri sviluppi del KaOS prevedono la gestione dei sensori del kicker come bumpers,
lo sviluppo di un protocollo più efficiente in modo da superare la limitazione della velocità della linea seriale e l’introduzione di nuovi comandi come ad esempio la
possibilità di variare il parametro di accelerazione in run time.
Capitolo 5
Sviluppi futuri e conclusioni
Essenziale allo sviluppo del robot è la sperimentazione di nuove metodologie. Sperimentare significa anche rimettere in discussione i risultati raggiunti per confrontarli con le nuove idee. In questo capitolo sono presentati anche i risultati ottenuti, in
termini sportivi, da Azzurra Robot Team.
5.1 Sviluppi futuri
5.1.1 Algoritmi genetici
Fra le nuove strategie di controllo del robot, assai interessante si è rivelata una basata
su algoritmi genetici[3]. Sul robot TinoZoff è stata implementata anche una strategia
di movimento basata su di un algoritmo genetico la cui evoluzione è stata portata a
termine su di un simulatore. Al robot simulato venivano effettuati vari tiri in porta e
l’evoluzione dell’algoritmo veniva guidata dall’efficienza del robot nel parare questi
tiri. Risultati incoraggianti si sono avuti al momento del passaggio dal simulatore al
robot reale.
5.1.2 Nuovi sensori
Nell’analisi dei sensori (di qualunque sensore) bisogna considerare due parametri: sensibilità e campo d’azione. La sensibilità di un sensore indica di quanto varia il segnale
60
Capitolo 5. Sviluppi futuri e conclusioni
61
di uscita del sensore al variare della grandezza misurata. Indicando con V l’uscita del
sensore (tipicamente in Volt) e con x la grandezza fisica misurata, la sensibilità S del
sensore è definita da
∆V
V
=S
∆x
:
x
Il campo d’azione, altresı̀ detto anche portata, indica la massima distanza utile alla
quale il sensore percepisce.
Sulla base di quanto detto, si vede che un sensore è essenzialmente un sistema che
converte una grandezza in un’altra, più facilmente misurabile dal processore del robot.
I sensori possono essere suddivisi in due categorie: analogici e digitali.
Un sensore analogico fornisce in uscita un segnale a tensione variabile secondo la
legge vista prima. Non necessariamente la variazione della grandezza da misuarare ha
un andamento lineare, ma può essere anche del tipo logaritmico o esponenziale. Di
questo ne va tenuto conto al momento di progettare il sensore. Il 68HC11F1 installato
a bordo del robot è dotato di quattro porte a cui si possono collegare direttamente
segnali analogici variabili tra 0 e 5V. Per non interferire con la misura, il carico su
queste porte deve avere una certa impedenza (dell’ordine dei 510kΩ). In ogni caso,
per le specifiche di collegamento al microprocessore e per le modalità di lettura dei
dati si vedano [16] e [15].
Un sensore digitale fornisce in uscita un segnale che può assumere solo due livelli
logici, zero e uno, ai quali corrispondono due diversi livelli di tensione, di solito 0
e 5V. Un sensore analogico può essere usato come digitale ponendo una soglia. Di
fatto i sensori a raggi infrarossi presenti sul robot sono proprio di questo tipo in quanto il ricevitore rende disponibile in uscita un segnale la cui corrente è proporzionale
all’intensità del segnale ricevuto. L’interfacciamento di sensori digitali al micro è relativamente semplice, potendosi fare direttamente ai pin di input/output, oppure tramite
un integrato che svolga le funzioni di buffer.
In base all’ambiente nel quale si muove il robot, potrebbe essere interessante implementare sensori di pressione realizzati con microswitches o veri e propri sensori di
pressione utilizzando i materiali conduttivi forniti come protezione dei circuiti integrati
durante il trasporto[8].
62
Figura 5.1: RoboCup ’98.
5.2 Risultati delle competizioni
In questa sezione si è voluto fare un breve bilancio delle competizioni alle quali hanno
partecipato i robot dell’Università di Parma nell’ambito del progetto RoboCup Italia.
5.2.1 Parigi ’98
La partecipazione alla RoboCup ’98 a Parigi è stata preceduta dalla “Scuola di progettazione per robot calciatori”, uno stage di due settimane tenutosi a Padova. Lı̀ è nato il
robot TinoZoff. A Padova le università partecipanti al progetto RoboCup Italia[17] si
sono organizzate per formare la squadra italiana di robot calciatori. Tutti i robot della
squadra, ad eccezione di un robot del Politecnico di Milano, sono stati costruiti partendo da robot commerciali Pioneer 1 ActivMedia[1]. In particolare, il portiere è stato
fornito dall’Università di Brescia, allora facente parte del progetto. La caratteristica
più importante del robot portiere di Brescia (chiamato Saracinescu) era l’interessante
sistema di visione omnidirezionale che sfruttava uno specchio sferico. Questo sistema
63
Figura 5.2: Tabellone della RoboCup ’98.
garantisce al robot di avere una visione completa dell’ambiente circostante potendo
inquadrare contemporaneamente la porta e la palla.
Volendo sviluppare qualcosa di diverso, su TinoZoff si è deciso di installare un
sistema di visione con due telecamere dotate di ottiche ad ampio angolo di apertura.
Prima della scelta definitiva del sistema di visione, si è voluto sperimentare su Romolo
il sistema di visione omnidirezionale.
Il brevissimo tempo a disposizione per il montaggio ed i test del robot, unito a
inevitabili problemi meccanici in fase costruttiva, non hanno permesso di presentare
in campo TinoZoff per le gare della RoboCup ’98. Tuttavia l’esperienza parigina si è
rivelata utilissima nel prosieguo del lavoro su TinoZoff e sugli altri robot della squadra.
Infatti si sono viste le svariate soluzioni presentate dalle squadre partecipanti ed è stato
possibile trarre spunti molto interessanti. Inoltre anche dal punto di vista sportivo la
RoboCup ’98 è stata positiva per la spedizione italiana, avendo terminato ai quarti di
finale dopo aver superato le tre partite di qualificazione senza subire reti.
Figura 5.3: RoboCup ’99.
Figura 5.4: Tabellone della RoboCup ’99.
64
65
Figura 5.5: EuRoboCup 2000.
5.2.2 Stoccolma ’99
Anche per la partecipazione alla Robocup ’99 si è svolto uno stage di preparazione tenutosi a Roma nell’ambito della “Scuola di progettazione dei robot calciatori” seguito
da vari incontri a Padova presso il consorzio Padova Ricerche.
TinoZoff è stato designato quale portiere titolare ed è stato l’unico robot della squadra ad aver disputato per intero tutte e nove le partite della manifestazione. Il risultato
finale della RoboCup ’99 è stato quanto mai lusinghiero dal momento che la squadra
ART si è piazzata al secondo posto dopo aver sconfitto nelle eliminatorie gli americani
dell’USC Dreamteam (campioni RoboCup ’97), gli iraniani dell’Università di Teheran
(che poi diventeranno campioni) e, soprattutto, i tedeschi dell’Università di Friburgo,
autentici dominatori della RoboCup ’98, in una semifinale entusiasmante. TinoZoff ha
subito complessivamente cinque reti, di cui tre nella finale anche a causa di un problema ai motori e ha contribuito in maniera fondamentale al raggiungimento dell’ottimo
risultato di squadra.
5.2.3 Amsterdam 2000
Al primo campionato europeo di calcio per robot erano presenti (per la categoria middle size) nove squadre europee più la squadra dell’Università di Teheran, invitata in
66
qualità di campione del mondo in carica. Proprio la squadra iraniana e Azzurra Robot Team, all’inizio viste come favorite, si sono incontrate nella finale. Cosı̀ come a
Stoccolma, anche ad Amsterdam a vincere è stata la squadra iraniana. Tuttavia i robot italiani, tra cui Galavrón, hanno mostrato maggiori doti scientifiche, evidenziando
un gioco di squadra che, a livello di calcio per robot, comporta un coordinamento di
behaviors distribuiti sui vari robot. Su sette partite disputate, ART ne ha vinte cinque,
una pareggiata e una (la finale) persa, subendo complessivamente tre reti e segnandone
quattordici.
Appendice A
Manuale d’uso del robot
A.1 Batterie
L’intero set di batterie di Galavrón è composto da 8 batterie piombo-acido da 12V-4Ah.
Tali batterie devono essere caricate a tensione costante e con un limite di corrente.
Vanno usate sul robot al massimo della carica. La tensione massima a vuoto è di
circa 13V. Prima di iniziare la carica, è opportuno segnare sul registro la tensione della
batteria e l’operazione “CARICA”. Quando finisce la carica, bisogna di nuovo segnare
sul registro il numero della batteria, la sua tensione a vuoto e l’indicazione “FINE
CARICA”.
Batterie agli ioni di litio. Recentemente sono state acquistate anche due batterie agli
ioni di litio da 10,8V-4,5Ah. Queste batterie, che sono batterie standard per
laptop, presentano un enorme vantaggio in termini di peso rispetto a quelle al
Pb-acido. Esse pesano infatti 430g l’una rispetto ai 1700g di una batteria al
Pb-acido.
A.1.1 Carica delle batterie con il caricabatterie
I caricabatterie in dotazione sono due. Sono marchiati Parma e Parma2. Forniscono in
uscita una tensione a vuoto di circa 14V e sono limitati in corrente a 500mA. Vanno
collegati prima alla presa della corrente (230V) e poi alla batteria da caricare tramite
67
Appendice A.
68
gli appositi connettori faston (rosso con rosso e nero con nero). Il led sul caricabatteria è l’indicatore di carica e si spegne quando la tensione raggiunge i 13,6V circa.
Usando un cavo che metta in parallelo due batterie, è possibile caricarne anche due
contemporaneamente con un solo caricabatterie. Si deve verificare che le due batterie
abbiano all’incirca la stessa tensione a vuoto. La tensione delle batterie dopo la carica
è di circa 13,5V e si stabilizza intorno ai 13,1V dopo circa 30 minuti. Se si può, è
opportuno attendere questo tempo prima di utilizzarle, ciò per prolungare la vita delle
batterie. I tempi di carica sono di 58 ore con una sola batteria collegata al carica-
batterie. Se si collegano due batterie contemporaneamente, i tempi di carica possono
anche raddoppiare.
A.1.2 Carica con alimentatore da banco
Si imposta la tensione in uscita dall’alimentatore a 13,8V e il limite di corrente tra 400
e 600mA. Si collega la batteria (rosso con rosso e nero con nero) e si accende il circuito.
La batteria è carica quando assorbe meno di 1520 mA. Anche in questo caso vale il
discorso che si possono caricare più batterie contemporaneamente. Aumentando però
il limite di corrente complessivo, il tempo di carica non aumenta.
Il limite di corrente dovrebbe essere sempre compreso tra il 10 ed il 15%
della corrente nominale in Ah.
È possibile caricare una batteria anche con un limite di corrente più alto. In tal modo
si abbrevia il tempo di carica, ma la batteria sopporterà un numero inferiore di cicli di
carica/scarica.
Superbatteria (12V-12Ah) per il circuito pneumatico. Con i mezzi a disposizione,
l’unico modo per caricarla è quello di usare l’alimentatore da banco. Si imposta come di consueto la tensione a 13,8V e si limita la corrente tra 1200 e
1500 mA. La carica si ottiene quando la batteria assorbe circa 80100 mA.
La superbatteria rimane carica anche dopo parecchie decine di cicli di gonfiaggio della bombola. Volendo, è possibile utilizzare anche una batteria di quelle
da 4Ah, tuttavia, poiché l’assorbimento richiesto dal compressore è di circa 3
Ampere, è preferibile non usare inutilmente le batterie del robot.
Appendice A.
69
A.2 Circuito pneumatico per il kicker
La carica massima della bombola è di 9 bar (kg=cm2 ). Il limite da non superare in nessun caso è di 10 bar. Infatti il circuito a valle della bombola (raccordi, elettrovalvole
e pistoni) è garantito per una pressione massima di 10 bar. Inoltre si deve considerare
che, già a 9 bar, un calcio del robot fa scendere la pressione di circa 0,5 bar. Oltre
questo limite si avrebbe quindi un guadagno trascurabile di potenza di calcio in quanto più la pressione è alta, più la bombola si scarica rapidamente. La carica avviene
collegando il compressore alla valvola della bombola. A sua volta il compressore va
alimentato con la superbatteria tramite la presa accendisigari. Questa presa ha due
connettori faston, uno nero ed uno blu. Il nero va col nero della batteria ed il blu con
il rosso. Il tempo di carica, partendo dalla bombola vuota ed arrivando a 9 bar, è di
circa 2’30”. Durante questa fase bisogna prestare la massima attenzione a non surriscaldare il compressore. Se si può, è opportuno caricare la bombola fino alla pressione
desiderata, lasciarla riposare e poi effettuare un “rabbocco”. Infatti, dal momento che
l’aria in pressione si surriscalda, attendendo qualche secondo è possibile far stare più
aria nella bombola.
Svuotamento della bombola. Quando il robot viene spento, il circuito DEVE essere
vuotato. Tale operazione si effettua inserendo la punta di un cacciavite nella
valvola della bombola per consentire la fuoriuscita dell’aria.
A.3 Alimentazione del robot
Il robot può essere alimentato con due batterie da 12V-4Ah, tramite un alimentatore
standard AT per personal computer, oppure tramite l’alimentatore da banco.
A.3.1 Alimentazione da batterie
Per le gare, oppure per le prove dei motori, il robot deve essere alimentato tramite
batterie. Si devono collegare le batterie ai connettori faston che escono dagli alloggiamenti laterali alla base del robot. Le due batterie sono poi da collocare all’interno
Appendice A.
70
dei rispettivi alloggiamenti facendo attenzione a lasciare i faston verso l’esterno. Può
essere utilizzata anche una terza batteria, da collocarsi sopra al robot. Questa configurazione comporta un maggior peso del robot, tuttavia ha il vantaggio di separare
l’alimentazione del PC da quella dei motori.
A.3.2 Alimentazione con alimentatore PC
Un normale alimentatore standard AT può essere usato quando si intende lavorare
sul robot per lunghi periodi, oppure ogniqualvolta si intenda risparmiare le batterie.
L’alimentatore in dotazione è stato modificato per permettere un collegamento rapido
e sicuro alla motherboard del robot. Si deve collegare il connettore a 15 terminali
maschio dell’alimentatore con il connettore a 15 terminali femmina presente sul robot.
Questo connettore alimenta la motherboard e l’hard disk. Inoltre si deve collegare
un connettore a 4 terminali femmina dell’alimentatore con il connettore a 4 terminali
maschio che va alle telecamere.
A.3.3 Alimentazione con alimentatore da banco
Il robot può essere alimentato anche tramite l’alimentatore da banco utilizzando la
presa posta sul tetto in plexiglass. L’alimentatore deve essere posto in modo di funzio-
namento PARALLEL, con una tensione di 2427V ed un limite in corrente di almeno
3A. Qualora si desiderasse utilizzare anche la scheda motori, bisogna collegare al robot anche due batterie e regolare l’alimentatore a circa 27V. In questa configurazione
le batterie rimangono in “tampone”, cioè sono costantemente sotto carica, ma sono
pronte a fornire la necessaria corrente di spunto richiesta dai motori. Senza le due batterie, l’alimentatore andrebbe in limitazione di corrente abbassando la tensione fornita
e facendo fatalmente spegnere il PC.
A.4 Scheda di controllo
La scheda di controllo si occupa del movimento del robot tramite la lettura degli encoder dei motori, nonché dei sensori. Essa comunica con il PC tramite un collegamento
Appendice A.
71
seriale RS232. È dotata di un microprocessore Motorola MC68HC11F1[16] e di una
flash eprom da 32Kbytes del tipo AT29C256 che contiene un piccolo sistema operativo
detto PSOS (Pioneer Server Operating System), giunto alla versione 4.9.
In considerazione del fatto che un ciclo di lettura/scrittura in memoria del
microprocessore è di circa 140ns (con una frequenza di clock interno pari a
4MHz), se si intende sostituire la flash eprom si deve utilizzare un modello
con un tempo di accesso pari a 120ns o inferiore.
A.4.1 Collegamenti elettrici
I collegamenti necessari al funzionamento della scheda di controllo sono essenzialmente il connettore di alimentazione, gli encoder dei motori, la porta seriale e i connettori di I/O.
A.4.2 Aggiornamento del PSOS
Il PSOS è residente nella EPROM della scheda di controllo e può essere aggiornato o sostituito con il KaOS sfruttando il programma psosdl1. Innanzitutto occorre
mettere la scheda di controllo in boot mode premendo il tasto nero in basso a destra.
Tenendo premuto il tasto nero si deve premere il tasto rosso a fianco (reset) e poi rilasciare prima il tasto rosso e poi il nero. Con questa operazione il 68HC11 viene messo
in modalità di bootstrap[16] in quanto i pin 2 e 3 del micro, normalmente alti, vengono
portati a zero e poi si effettua un reset.
A questo punto si può lanciare il programma con la sintassi
./psosdl -b bootload.s19 nomefile.s19
A.4.3 Parametri del PSOS
Essenziali al funzionamento del robot sono i parametri del PSOS[1]. Si tratta di una
serie di valori che vengono scritti nella memoria non volatile del microprocessore e che
1 Si
trova nella directory /backup/home/portiere/ETHNOS/ETPioneer/Psos49.
Appendice A.
Parametro
revcount
motor
experim
baud
stallmax
stallwait
acc
pparam
dparam
iparam
Max.
65535
1
1
1
32767
127
127
20
60
20
72
Min.
0
0
0
0
0
0
2
5
20
0
Default
32000
1
0
0
16384
4
4
10
45
10
Galavrón
35100
1
1
0
32767
4
8
20
20
20
Tabella A.1: Parametri del PSOS.
servono ad interpretare correttamente i dati degli encoder, le impostazioni del controllo
PID del robot e le impostazioni di velocità e di accelerazione2 .
I parametri utilizzati dal robot sono visualizzati nella tabella A.1. Per modificare i
parametri si deve usare il programma psoscf senza ulteriori comandi. Si veda il [1]
per approfondimenti.
A.5 Collegamento al robot
L’accesso al PC del robot è possibile in due modi diversi: collegandosi direttamente
tramite tastiera, mouse e video, oppure collegandosi via rete tramite la WaveLan.
A.5.1 Collegamento diretto
Per collegarsi direttamente al robot bisogna connettere una tastiera, un mouse (sulla
porta PS/2 oppure COM2 poiché la COM1 è utilizzata dalla scheda dei motori) ed un
video VGA. Se il robot è lontano dalla postazione di lavoro si può usare la prolunga
2 Se
si utilizza il sistema operativo KaOS, il parametro experim si riferisce all’utilizzo dei sensori
a raggi infrarossi.
Appendice A.
73
(circa 5 metri) per i tre dispositivi. Al login si può accedere come superutente (login: root), oppure come utente normale (login: bernaca password: bernaca). Si
consiglia di accedere come root, passando successivamente all’utente normale se si
utilizza ETHNOS. Digitando startx parte l’ambiente grafico KDE (versione 1.1.2).
Prima di spegnere il robot si deve uscire dall’ambiente grafico seguendo le voci Fine Sessione/Esci da KDE. Una volta tornati in modalità testo si deve digitare
halt avendo i diritti di root.
Quando appare la scritta System halted, allora è possibile spegnere il
robot.
Questa procedura, sebbene non obbligatoria, è tuttavia caldamente consigliata poiché
spegnendo correttamente il PC si evita il check del disco al successivo riavvio.
A.5.2 Collegamento tramite rete
Il collegamento tramite rete è il sistema che si utilizza di solito, anche perché è l’unico
possibile in gara. Dal computer remoto si accede a Galavrón tramite rlogin. Ovviamente deve essere predisposto il collegamento installando la WaveLan sul computer remoto oppure utilizzando un router. L’indirizzo IP di Galavrón è 192.168.100.51.
In questo caso non è possibile accedere a Galavrón come root, ma si deve usare
l’utente bernaca. Per eventuali modifiche a queste impostazioni, si rimanda alla
letteratura su Linux, come ad esempio [4].
È opportuno avviare il programma di Galavrón come utente e non come
superutente. Infatti il sistema ETHNOS si impossessa di tutte le risorse
del robot e, se si pianta, non c’è altro da fare se non spegnere il robot. Se
invece il programma viene lanciato da utente normale, allora ETHNOS
non ha accesso a tutte le risorse. Se si pianta in questo caso si ottiene un
segmentation fault, però si riesce a riavviare il programma senza
dover spegnere e riaccendere il robot.
Appendice A.
74
A.6 Programmazione
Il programma del robot è scritto in linguaggio C/C++.
A.6.1 Avvio del programma
Come spiegato in precedenza, il programma del robot viene avviato solitamente come
utente normale. Per comodità è stato creato un link al programma nella directory
/home/bernaca in quanto è la directory in cui si entra collegandosi come utente
normale.
La procedura di avvio è semplice. Il programma si lancia digitando il seguente
comando: ./tino [portnum] dove portnum è il numero della porta di comunicazione per lo scambio dei messaggi e può andare da 1200 fino a 1900. Di solito
per convenzione si usa la porta numero 1800. Si noti la presenza del punto e dello
slash prima del nome del programma. Siccome su Galavrón è installata la distribuzione Mandrake 7.0 di Linux, il punto e lo slash sono richiesti per avviare eseguibili in
directory non comprese nel PATH. In gara si usa lanciare uno script che tiene sotto controllo l’esecuzione del programma e lo riavvia in caso di segmentation fault.
La procedura è la seguente: ./ripeti tino 1800 dove 1800 è il numero della
porta.
A.6.2 Modifica e procedure di compilazione
Il programma può essere modificato solo come utente root.
Appendice B
Schema del robot
Galavrón è composto dai seguenti sottosistemi:
Sistema di alimentazione. L’alimentatore di bordo è un alimentatore per PC con lo
standard AT. Accetta in ingresso tensioni variabili tra 18 e 36 V e fornisce le
necessarie tensioni alla motherboard, alle telecamere e alla scheda di controllo.
All’alimentatore sono collegate due batterie in serie per una tensione di ingresso
di 24 V.
Computer di bordo. Il PC a bordo del robot è composto da un processore Intel Celeron a 466 MHz e la dotazione di memoria RAM prevede 128 Mb. La RAM
è del tipo a 133 MHz, tuttavia il Celeron la gestisce a 66 MHz. L’hard disk è
un hard disk da computer portatile da 6 Gb su cui è stato installato il sistema
operativo Linux Mandrake 7.0 (kernel 2.2.14) grazie al quale “gira” il sistema
ETHNOS[18]. Il peso dell’hard disk è di 90 grammi, l’assorbimento di corrente è circa un quinto di quello di un hard disk normale ed inoltre è garantita
una eccezionale resistenza agli urti. Sulla motherboard sono installate quattro
schede:
Scheda video S3 ViRGE/Dx
Scheda di rete Lucent WaveLAN (su apposito adattatore)
Due frame grabbers Aver Media Ez-Capture (chip BT878)
75
Appendice B.
Schema del robot
76
Telecamere. Ai due frame grabber sono collegate le due telecamere tramite un piccolo cavo coassiale che porta i segnali VID OUT e VID GND. Il collegamento
elettrico alle telecamere prevede i 12 V di alimentazione delle telecamere ed i
5 V che servono a tenere aperti gli otturatori delle ottiche.
Scheda di controllo. È una scheda dotata di un microprocessore con un piccolo sistema operativo (KaOS) dedicato al controllo del movimento del robot. La scheda in particolare pilota i driver dei motori (sulla scheda di potenza) e gestisce
i segnali degli encoder aggiornando l’odometria del robot. Inoltre è presente
un’interfaccia per l’I/O grazie alla quale sono possibili fino ad otto ingressi ed
altrettante uscite. La comunicazione con il PC avviene tramite linea seriale.
L’integrato utilizzato per l’interfaccia TTL/RS232 è un Maxim MAX233 che,
rispetto al meno recente MAX232, presenta il vantaggio di avere già integrati i
condensatori per le traslazioni dei livelli di tensione tra TTL e RS232. Devono
essere presenti i segnali RX, TX e GND. Questa scheda assorbe circa 200 mA,
per cui è alimentata senza problemi da un +12 V in uscita dall’alimentatore del
PC.
Scheda di potenza. Si occupa di fornire la potenza ai motori. I segnali che pilotano
questa scheda sono isolati otticamente per una maggiore sicurezza. Tale scheda
è alimentata a 18 V tramite una ulteriore scheda di alimentazione dedicata. In
uscita verso il micro viene fornito un segnale di allarme collegato all’allarme
di sovratemperatura dei driver. Questo segnale, anch’esso optoisolato, viene
utilizzato dal micro per togliere potenza ai motori nel caso diventi attivo. In
ingresso, invece, la scheda sente la presenza dei 5 V di alimentazione del micro.
Dovessero mancare, è prevista l’attivazione del brake, cioè della frenatura dei
motori tramite gli opportuni pin degli LMD18200.
Scheda del kicker. Questa scheda è dedicata alla gestione degli ingressi e delle uscite
dei kicker. Essa viene utilizzata per azionare le elettrovalvole del kicker tramite
transistori Darlington e è direttamente connessa alla scheda del 68HC11. Il kicker è composto da una bombola in alluminio per l’aria compressa e da quattro
elettrovalvole che attivano quattro pistoni a doppio effetto con i cilindri lunghi
Appendice B.
Schema del robot
77
8cm. Le elettrovalvole sono attivate dalla chiusura del contatto di un sensore posto sul kicker. Un monostabile si occupa di mantenere le elettrovalvole eccitate
per un tempo sufficiente a far compiere ai pistoni l’intera corsa.
Scheda dei sensori infrarossi. È collegata direttamente ai sensori, ai quali invia il
segnale modulato e dai quali riceve il segnale di ritorno. Il clock è lo stesso
del microprocessore (4 MHz). I segnali di ritorno vengono inviati agli ingressi
digitali del micro.
MOT. POST.
BUMPERS
THERMAL FLAG
DIR. E PWM MOTORI
ENCODERS
Figura B.1: Schema elettrico del robot Galavrón.
+12V
PC GND
SCHEDA
KICKER
+18V
SCHEDA
DI CONTROLLO
(68HC11F1)
ALIMENTATORE
DEI MOTORI
+12V
PC GND
24V
12V
4 Ah
ALIMENTATORE
DI BORDO
+12V
+5V
-5V
-12V
PWR GOOD
PC GND
NOSE E GENERAL I/O
Schema del robot
SCHEDA
POTENZA
MOTORI
ELETTRO
VALVOLE
Appendice B.
MOT. ANT.
SCHEDA
INFRAROSSI
SERIALE
RS232
+12V
PC GND
PC
MOTHERBOARD
Intel Celeron
466 MHz
COAX
VID OUT + VID GND
12V
4 Ah
TV
CAMERA
78
+12V
+5V
PC GND
Appendice C
Listato del KaOS
* Definizioni generali
* ----------------------------------------------------------------Registers
equ
$1000
;Register Bank Origin
EEP_ORG
equ
$6E00
;EEPROM Memory Origin
EEP_LEN
equ
$0200
;EEPROM Memory Lenght
RAM_ORG
equ
$0000
;RAM Memory Origin
RAM_TOP
equ
$03FF
;RAM top for Stack assign
* Assegnazione simbolica dei bit nel byte
* ----------------------------------------------------------------B7
equ $80
B6
equ $40
B5
equ $20
B4
equ $10
B3
equ $08
B2
equ $04
B1
equ $02
B0
equ $01
* Definizione dei bit in SCCR2
* ----------------------------------------------------------------TIE equ B7 ;transmit interrupt enable
TCIE equ B6 ;transmit complete int. enable
RIE equ B5 ;receiver interrupt enable
ILIE equ B4 ;idle line interrupt enable
TXE equ B3 ;transmit enable
RXE equ B2 ;receiver enable
RWU equ B1 ;receiver wake-up
SBK equ B0 ;send break
* Definizione dei bit in SCSR
* ----------------------------------------------------------------TDRE equ B7 ;transmit data register empty
TC equ B6 ;transmit complete
RDRF equ B5 ;receiver data register full
IDLE equ B4 ;idle line
OR equ B3 ;over-run error
NF equ B2 ;noise error
FE equ B1 ;framing error
* Definizioni dei registri interni
* ----------------------------------------------------------------PORTA equ $00 ;I/O Port A
DDRA equ $01 ;Data Direction for Port A
PORTG equ $02 ;I/O Port G
DDRG equ $03 ;Data Direction for Port G
79
Appendice C.
Listato del KaOS
PORTB equ $04 ;Output-only Port B
PORTF equ $05 ;Output-only Port F
PORTC equ $06 ;I/O Port C
DDRC equ $07 ;Data Direction for Port C
PORTD equ $08 ;I/O Port D
DDRD equ $09 ;Data Direction for Port D
PORTE equ $0A ;Input-only Port E
CFORC equ $0B ;Compare Force Register
OC1M equ $0C ;OC1 Action Mask Register
OC1D equ $0D ;OC1 Action Data Register
TCNT equ $0E ;Timer Counter Register (+ $0F)
TIC1 equ $10 ;Input Capture 1 Register (+ $11)
TOC1 equ $16 ;Output Compare 1 Register (+ $17)
TOC2 equ $18 ;Output Compare 2 Register (+ $19)
TOC3 equ $1A ;Output Compare 3 Register (+ $1B)
TOC4 equ $1C ;Output Compare 4 Register (+ $1D)
TOC5 equ $1E ;Output Compare 5 Register (+ $1F)
TCTL1 equ $20 ;Timer Control Register 1
TCTL2 equ $21 ;Timer Control Register 2
TMSK1 equ $22 ;Timer Interrupt Mask Register 1
TFLG1 equ $23 ;Timer Interrupt Flag Register 1
TMSK2 equ $24 ;Timer Interrupt Mask Register 2
TFLG2 equ $25 ;Timer Interrupt Flag Register 2
PACTL equ $26 ;Pulse Accumulator Control Register
PACNT equ $27 ;Pulse Accumulator Count Register
SPCR equ $28 ;SPI Control Register
SPSR equ $29 ;SPI Status Register
SPDR equ $2A ;SPI Data Register
BAUD equ $2B ;SCI Baud Rate Generator
SCCR1 equ $2C ;SCI Control Register 1
SCCR2 equ $2D ;SCI Control Register 2
SCSR equ $2E ;SCI Status Register
SCDR equ $2F ;SCI Data Read/Write
ADCTL
equ $30 ;A/D Control Register
ADR1_MOTOR_L
equ $31 ;A/D Result Register 1
ADR2_MOTOR_R
ADR3_ANALOG_INP equ $33 ;A/D Result Register 3
ADR4_BATTERY
BPROT equ $35 ;EEPROM Block Protect Register
OPT2 equ $38 ;Option 2 Register
OPTION equ $39 ;System Configuration Options
COPRST equ $3A ;Arm/Reset COP Timer
PPROG equ $3B ;EEPROM Programming Control Register
HPRIO equ $3C ;High Priority I-bit & Miscellaneous
INIT equ $3D ;RAM & I/O Mapping Register
TEST1 equ $3E ;Factory Test Control Register
CONFIG equ $3F ;COP, ROM, EEPROM Enables
CSSTRH equ $5C ;Chip Select Strobe
CSCTL equ $5D ;Chip Select Control Register
CSGADR equ $5E ;Chip Select General I/O Address
CSGSIZ equ $5F ;Chip Select General I/O Size
* Definizioni delle variabili in EEPROM
* ----------------------------------------------------------------EE_Word_Revcont equ
$6F02
EE_Char_Motor
equ
$6F04
EE_Char_Experim equ
$6F05
; 1 = Infrarossi attivi
EE_Array_Name
equ
$6F06
EE_Char_Baudrat equ
$6F1B
EE_Word_Stallmx equ
$6F1C
EE_Char_Stallwa equ
$6F1E
EE_Char_Watchdg equ
$6F1F
EE_Char_Pparam equ
$6F20
EE_Char_Dparam equ
$6F21
EE_Char_Iparam equ
$6F22
EE_Array_Subcla equ
$6F23
EE_Char_6
equ
$6F2B
EE_Word_2
equ
$6F2C
EE_Word_3
equ
$6F2E
EE_Char_Acc
equ
$6F30
80
Appendice C.
Listato del KaOS
* Definizioni delle variabili in RAM
* ----------------------------------------------------------------Char_temp
equ
$0000
Char_Dig_input equ
$0001
Char_Kicker
equ
$0002
Char_81
equ
$0005
Char_temp_5
equ
$0006
Char_temp_3
equ
$0007
Char_temp_4
equ
$0008
Word_temp_1
equ
$0009
Word_Rkick
equ
$000B
Char_temp_2
equ
$000D
Char_IR_enable equ
$000E
Word_millisec
equ
$0010
Word_Lkick
equ
$0012
Char_31
equ
$0014
Char_28
equ
$0015
Char_9
equ
$0016
Char_47
equ
$0019
Char_49
equ
$001A
Char_48
equ
$001B
Word_48
equ
$001C
Word_49
equ
$001E
Word_20
equ
$0020
Word_19
equ
$0022
Char_70
equ
$0024
Word_Right_vel equ
$0025
Word_Left_vel
equ
$0027
Word_29
equ
$0029
Word_30
equ
$002B
Char_25
equ
$002D
Char_6
equ
$002E
Word_PWM_cycl_L equ
$0030
Word_PWM_cycl_R equ
$0032
Word_appl_R_pwr equ
$0034
Word_appl_L_pwr equ
$0036
Word_56
equ
$0038
Word_57
equ
$003A
Word_Acceleraz equ
$003C
Word_FRkick
equ
$003E
Char_motor_test equ
$0040
Word_err_attu_R equ
$0041
Word_err_prec_R equ
$0043
Word_dposprec_R equ
$0045
Char_IPD_R
equ
$0047
Char_DI_R
equ
$0048
Char_I_R
equ
$0049
Word_tens_mot_R equ
$004A
Word_err_attu_L equ
$004C
Word_err_prec_L equ
$004E
Word_dposprec_L equ
$0050
Char_IPD_L
equ
$0052
Char_DI_L
equ
$0053
Char_I_L
equ
$0054
Word_tens_mot_L equ
$0055
Char_58
equ
$0057
Char_59
equ
$0058
Char_oper_flags equ
$0059
Word_12
equ
$005A
Word_14
equ
$005C
Word_36
equ
$005E
Word_37
equ
$0060
Word_7
equ
$0062
Word_Thpos
equ
$0064
Word_ang_setpnt equ
$0066
Word_4
equ
$0068
Word_6
equ
$006A
Word_8
equ
$006C
Word_13
equ
$006E
Word_51
equ
$0070
Word_32
equ
$0072
81
Appendice C.
Listato del KaOS
Word_33
Word_34
Word_35
Word_FLkick
Word_83
Char_22
Char_87
Char_88
Word_Xpos
Word_10
Word_Ypos
Word_11
Char_Motorstatu
Word_78
Word_79
Char_23
Char_24
Char_89
Char_sonar_rdng
Word_80
Char_42
Word_22
Word_22_L
Char_7
Word_50
Char_36
Char_32
Char_33
Char_35
Char_34
Char_2
Char_nr_comando
Char_cmd_arg_1
Char_cmd_arg_2
Char_38
Char_45
Char_44
Word_intg_cur_L
Word_mot_curr_L
Word_intg_cur_R
Word_mot_curr_R
Char_stall_L
Char_stall_R
Char_watcdg_cnt
Char_Dig_output
Word_24
Char_modo_test
Char_41
Word_53
Word_54
Word_55
Sonars_buffer
Display_buffer
Display_char_1
Display_char_2
Display_char_3
Display_char_4
Display_char_5
Display_char_6
Display_char_7
Display_char_8
Display_char_9
Display_char_10
Display_char_11
Display_char_12
Display_char_13
Display_char_14
Display_char_15
Display_char_16
Display_char_17
Display_char_18
Display_char_19
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
$0074
$0076
$0078
$007A
$007D
$007E
$007F
$0080
$0081
$0083
$0084
$0085
$0087
$0088
$008A
$008C
$008D
$008E
$008F
$0090
$0092
$0093
$0094
$0095
$0096
$0098
$0099
$009A
$009B
$009C
$009D
$009E
$009F
$00A0
$00C9
$00CA
$00CB
$00CC
$00CE
$00D0
$00D2
$00D4
$00D5
$00D6
$00D8
$00DA
$00DD
$00DE
$00E0
$00E2
$00E4
$00EA
$00FF
$0100
$0101
$0102
$0103
$0104
$0105
$0106
$0107
$0108
$0109
$010A
$010B
$010C
$010D
$010E
$010F
$0110
$0111
$0112
82
Appendice C.
Listato del KaOS
Display_char_20
Display_char_21
Display_char_22
Display_char_23
Display_char_24
Display_char_25
Display_char_26
Display_char_27
Display_char_28
Display_char_29
Display_char_30
Display_char_31
Word_Pak_header
Char_Byte_count
Char_29
Char_27
Word_42
Word_43
Word_44
Word_45
Word_46
Word_Revcount
Char_15
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
equ
$0113
$0114
$0115
$0116
$0117
$0118
$0119
$011A
$011B
$011C
$011D
$011E
$011F
$0121
$0199
$019A
$019B
$019D
$019F
$01A1
$01A3
$01D0
$01D4
* Dispositivi di I/O
* ----------------------------------------------------------------LCD_Register_I equ
$1060
LCD_Register_D equ
$1061
IO2_Register_0 equ
$1800
DIGITAL_OUTPUT equ
$1801
DIGITAL_INPUT
equ
$2000
********************************************************
* KARLO OPERATING SYSTEM v.1.0 FOR ART 2000 - GALAVRON *
********************************************************
P68H11
$defcpu.inc
* Codice
* ----------------------------------------------------------------RSEG CODE
* ----------------------------------------------------------------* Startup
* ----------------------------------------------------------------Startup
LDS
#$03FF
LDX
#Registers
BSET
TMSK2,X,#B0
SEI
LDAA
#(B7+B6+B5+B4+B3)
STAA
DDRA,X
BCLR
PORTA,X,#B3
LDAA
#(B3+B2+B1+B0)
STAA
DDRG,X
CLR
Char_2
LDAA
#(B7+B5+B4+B0)
Startup_c
STAA
BAUD,X
LDAA
#(TXE+RXE)
STAA
SCCR2,X
CLR
SCCR1,X
BSET
OPTION,X,#B7
BSET
CSCTL,X,#B5
CLR
IO2_Register_0
BCLR
SPCR,X,#(B7+B6+B5+B4)
CLRA
STAA
DDRD,X
JSR
Clear_sonars
LDX
#Registers
LDAA
#B5
STAA
CSGADR,X
LDAA
#(B2+B1)
83
Appendice C.
Startup_d
Listato del KaOS
STAA
BSET
LDD
STD
LDAA
STAA
LDD
STD
STD
STD
STD
STAA
STD
STD
STD
STD
STD
STD
STD
STD
STAA
STD
STD
STD
STD
STD
STD
STD
STD
STAA
STD
STD
STAA
STD
STAA
STAA
STAA
LDAA
STAA
LDAA
STAA
STAA
CLRA
STD
STAA
LDAA
LSRA
STAA
STAA
ADDA
ADDA
STAA
STAA
LDAA
SUBA
STAA
STAA
LDD
STD
STD
LDAB
CLRA
STD
LDD
STD
LDD
STD
LDD
STD
LDD
STD
LDD
84
CSGSIZ,X
CSCTL,X,#(B3+B0)
EE_Word_Revcont
; (35100 - #$891C)
Word_Revcount
EE_Char_Experim
; Abilitazione IR
Char_IR_enable
#$0000
Word_millisec
Word_Thpos
Word_7
Word_ang_setpnt
Char_motor_test
Word_Xpos
Word_10
Word_11
Word_12
Word_13
Word_14
Word_PWM_cycl_L
Word_PWM_cycl_R
Char_Kicker
Word_Rkick
Word_Lkick
Word_FRkick
Word_FLkick
Word_Left_vel
Word_Right_vel
Word_19
Word_20
Char_6
Char_stall_L
Word_22
Char_7
Char_58
Char_oper_flags
Char_9
Char_sonar_rdng
#$FF
Char_Dig_input
#(B4+B3+B2+B1+B0) ;Inizializzazione del kicker
Char_Dig_output
DIGITAL_OUTPUT
Word_24
Char_15
#$00
Char_I_R
Char_I_L
#$14
#$3C
Char_IPD_R
Char_IPD_L
#$3C
#$00
Char_DI_R
Char_DI_L
#Array_1
Word_29
Word_30
EE_Char_Acc
Word_Acceleraz
#$0100
Word_32
#$FF00
Word_33
#$0018
Word_34
#$FFE8
Word_35
#$01A0
;EE_Char_Iparam
;EE_Char_Pparam
;EE_Char_Dparam
;EE_Char_Dparam
;EE_Char_Iparam
Appendice C.
Startup_g
Startup_j
Startup_k
Startup_l
Startup_n
Startup_m
Listato del KaOS
STD
LDD
STD
LDAA
STAA
LDAA
STAA
STAA
STAA
STAA
STAA
LDAA
LDAB
STD
LDAA
STAA
JSR
CLR
CLR
BSET
BSET
LDD
ADDD
STD
LDAA
STAA
LDAA
STAA
BSET
LDAA
STAA
BSET
CLR
CLI
LDX
JSR
LDAA
JSR
LDAA
STAA
LDD
STD
LDD
STD
LDD
STD
LDD
STD
LDD
STD
LDAA
STAA
LDAA
STAA
JSR
JSR
CLR
LDAA
STAA
LDX
JSR
LDX
LDAB
JSR
LDAA
STAA
BSET
LDX
BRSET
JMP
JSR
LDY
Word_36
#$FE60
Word_37
#$04
Char_Motorstatu
#$00
Char_23
Char_24
Char_25
Char_modo_test
Char_27
#$FA
#$FB
Word_Pak_header
#$20
Char_28
LCD_Init
TMSK1,X
TMSK2,X
TFLG1,X,#(B5+B4+B3)
TMSK1,X,#(B4+B3)
TCNT,X
#$0014
TOC5,X
#B0
TCTL2,X
#(B7+B6+B5)
TCTL1,X
PACTL,X,#B7
#B7
OC1M,X
OC1D,X,#B7
Char_temp
#MSG_startup
String_to_buf
#$0A
Delay_A_10s
Char_Dig_output
DIGITAL_OUTPUT
#$0208
Word_42
#$0008
Word_43
#$0208
Word_44
#$0008
Word_45
#$0208
Word_46
#$05
Char_29
#$01
Char_27
CLOSE_MOTORS
RS232_Init
Char_modo_test
#$04
Char_Motorstatu
#MSG_sync
String_to_buf
#MSG_ca
#$10
String_to_buf_c
#$4B
Display_char_5
Char_oper_flags,#$10
#Registers
PORTA,X,#B2,Startup_m
Startup_r
Subroutine_7
Word_7
85
Appendice C.
Startup_o
Listato del KaOS
LDAB
JSR
LDAA
CMPA
BEQ
LDX
LDAB
JSR
JSR
LDAA
CMPA
BEQ
LDY
LDAB
JSR
BRA
#$0F
Wri_Y_5_digit
Char_Motorstatu
#$04
Startup_n
#MSG_conn
#$00
String_to_buf_c
Command_exec
Char_Motorstatu
#$04
Startup_k
Word_7
#$0F
Wri_Y_5_digit
Startup_o
* ----------------------------------------------------------------* Delays 250 millisec. with break
* ----------------------------------------------------------------Delay_250ms
JSR
Subroutine_10
LDX
#Registers
BRSET
PORTA,X,#B2,Delay_250ms
LDAA
#$32
Delay_250ms_a
JSR
Delay_7ms
DECA
BGT
Delay_250ms_a
RTS
MSG_sync
fcc
fcb
’KaOS
0
ART 2000’
MSG_ca
fcc
fcb
’ C
0
MSG_conn
fcc
fcb
’Connesso! ’
0
A’
* ----------------------------------------------------------------* Reset RS232 serial port
* ----------------------------------------------------------------RS232_Reset
JSR
RS232_R_int_dis
JSR
Delay_250ms
JSR
RS232_Init
RTS
* ----------------------------------------------------------------* Startup (test mode)
* ----------------------------------------------------------------Startup_r
LDAA
#$05
JSR
Delay_A_10s
BSR
RS232_Reset
LDX
#MSG_test_mot
JSR
String_to_buf
LDAA
#$0A
JSR
Dly_A_10s_brk
TSTA
BNE
Startup_t
JSR
Test_Motors
Startup_t
LDAA
#$05
JSR
Delay_A_10s
LDX
#MSG_test_digin
JSR
String_to_buf
LDAA
#$0A
JSR
Dly_A_10s_brk
TSTA
BNE
Startup_q
JSR
Test_Dig_in
Startup_q
LDAA
#$05
JSR
Delay_A_10s
LDX
#MSG_test_cpu
JSR
String_to_buf
86
Appendice C.
Startup_pas1
Startup_pas2
Startup_pas3
Startup_pas4
Startup_pas5
Startup_w
Listato del KaOS
LDAA
JSR
TSTA
BNE
JSR
LDAA
JSR
LDX
JSR
LDAA
JSR
TSTA
BNE
LDAA
JSR
LDX
JSR
LDAA
JSR
TSTA
BNE
LDAA
JSR
LDX
JSR
LDAA
JSR
TSTA
BNE
LDAA
JSR
LDX
JSR
LDAA
JSR
TSTA
BNE
LDAA
JSR
LDX
JSR
LDAA
JSR
JMP
87
#$0A
Dly_A_10s_brk
Startup_w
Test_CPU
#$05
Delay_A_10s
#MSG_pasqua1
String_to_buf
#$0A
Dly_A_10s_brk
Startup_w
#$05
Delay_A_10s
#MSG_pasqua2
String_to_buf
#$0A
Dly_A_10s_brk
Startup_w
#$05
Delay_A_10s
#MSG_pasqua3
String_to_buf
#$0A
Dly_A_10s_brk
Startup_w
#$05
Delay_A_10s
#MSG_pasqua4
String_to_buf
#$0A
Dly_A_10s_brk
Startup_w
#$05
Delay_A_10s
#MSG_pasqua5
String_to_buf
#$0A
Delay_A_10s
Startup
MSG_test_digin
fcc
fcb
’Digin:
0
BOOT termina’
MSG_test_cpu
fcc
fcb
’Test CPU.....BOOT termina’
0
MSG_test_mot
fcc
fcb
’Test MOTORI..BOOT termina’
0
MSG_pasqua1
fcc
fcb
’KaOS thanks:
0
MSG_pasqua2
fcc
fcb
’Stefano Cagnoni Monica Mordonini’
0
MSG_pasqua3
fcc
fcb
’Carlo Bernardi
0
MSG_pasqua4
fcc
fcb
’Marcel. CarlettiFrida Loprieno
0
’
MSG_pasqua5
fcc
fcb
’Giov. Remondini Cristiano Rota
0
’
Giovanni Adorni ’
Enzo Bocelli
’
* ----------------------------------------------------------------* LCD Init
* -----------------------------------------------------------------
Appendice C.
Listato del KaOS
LCD_Init
LDX
BSET
BSET
LDAA
BSR
LDAA
BSR
LDAA
BSR
LDAA
BSR
LDY
JSR
LDAA
BSR
RTS
#Registers
CSCTL,X,#(B7+B6)
CSSTRH,X,#(B7+B6)
#$38
LCD_Command
#$06
LCD_Command
#$0C
LCD_Command
#$01
LCD_Command
#MSG_startup
LCD_Write_msg
#$C0
LCD_Command
* ----------------------------------------------------------------* LCD Command
* ----------------------------------------------------------------LCD_Command
LDAB
$60,X
ANDB
#$80
BNE
LCD_Command
STAA
$60,X
RTS
* ----------------------------------------------------------------* LCD Write Char
* ----------------------------------------------------------------LCD_Write_ch
LDAB
$60,X
ANDB
#$80
BNE
LCD_Write_ch
STAA
$61,X
LCD_Write_ch_a RTS
* ----------------------------------------------------------------* LCD Write Message
* ----------------------------------------------------------------LCD_Write_msg
LDAA
$00,Y
BEQ
LCD_Write_ch_a
JSR
LCD_Write_ch
INY
BRA
LCD_Write_msg
* ----------------------------------------------------------------* LCD Write Y Using 5 Digits
* ----------------------------------------------------------------Wri_Y_5_digit
STY
Char_temp_3
LDY
#Display_buffer
ABY
LDD
Char_temp_3
CLR
Char_temp_2
TSTA
BPL
Wri_Y_5_digit_a
BSET
Char_temp_2,#$01
LDD
#$0000
SUBD
Char_temp_3
Wri_Y_5_digit_a LDX
#$000A
IDIV
ADDB
#$30
STAB
$00,Y
DEY
XGDX
LDX
#$000A
IDIV
ADDB
#$30
STAB
$00,Y
DEY
XGDX
LDX
#$000A
IDIV
ADDB
#$30
88
Appendice C.
Listato del KaOS
STAB
DEY
XGDX
LDX
IDIV
ADDB
STAB
DEY
XGDX
LDX
IDIV
ADDB
STAB
DEY
LDAB
BRCLR
LDAB
Wri_Y_5_digit_b STAB
RTS
$00,Y
#$000A
#$30
$00,Y
#$000A
#$30
$00,Y
#$A0
Char_temp_2,#$01,Wri_Y_5_digit_b
#$2D
$00,Y
* ----------------------------------------------------------------* LCD Write Y Using 3 Digits
* ----------------------------------------------------------------Wri_Y_3_digit
STY
Char_temp_3
LDY
#Display_buffer
ABY
LDD
Char_temp_3
CLR
Char_temp_2
TSTA
BPL
Wri_Y_3_digit_a
BSET
Char_temp_2,#$01
LDD
#$0000
SUBD
Char_temp_3
Wri_Y_3_digit_a LDX
#$000A
IDIV
ADDB
#$30
STAB
$00,Y
DEY
XGDX
LDX
#$000A
IDIV
ADDB
#$30
STAB
$00,Y
DEY
XGDX
LDX
#$000A
IDIV
ADDB
#$30
STAB
$00,Y
DEY
LDAB
#$A0
BRCLR
Char_temp_2,#$01,Wri_Y_3_digit_b
LDAB
#$2D
Wri_Y_3_digit_b STAB
$00,Y
RTS
MSG_startup
fcc
fcb
’KaOS 1.0 ART2000TH.FL.ON-IR KICK’
0
MSG_cf
fcc
fcb
’CF: ’
0
* ----------------------------------------------------------------* String to buffer
* ----------------------------------------------------------------String_to_buf
JSR
Clear_buffer
LDAB
Char_31
String_to_buf_c LDY
#Display_buffer
ABY
String_to_buf_b LDAA
$00,X
BEQ
String_to_buf_a
CMPB
#$20
89
Appendice C.
Listato del KaOS
BGE
STAA
INCB
INY
INX
BRA
String_to_buf_a STAB
RTS
String_to_buf_a
$00,Y
String_to_buf_b
Char_31
* ----------------------------------------------------------------* Clear buffer
* ----------------------------------------------------------------Clear_buffer
PSHX
LDD
#$0000
STAA
Char_31
LDX
#Display_buffer
Clear_buffer_a STD
$00,X
INX
INX
CPX
#(Display_buffer+$20) ;#$011F nel psos vecchio
BLT
Clear_buffer_a
LDAA
#$FF
STAA
Char_28
PULX
RTS
* ----------------------------------------------------------------* Write to LCD
* ----------------------------------------------------------------Write_to_LCD
LDAB
LCD_Register_I
ANDB
#$80
BNE
Write_to_LCD_a
LDAB
Char_28
BLT
Write_to_LCD_b
CMPB
#$20
BGE
Write_to_LCD_a
LDY
#Display_buffer
ABY
INCB
CMPB
#$10
BNE
Write_to_LCD_c
LDAB
#$FE
Write_to_LCD_c STAB
Char_28
LDAB
$00,Y
BNE
Write_to_LCD_d
LDAB
#$A0
Write_to_LCD_d STAB
LCD_Register_D
Write_to_LCD_a RTS
Write_to_LCD_b ANDB
#$01
BEQ
Write_to_LCD_e
LDAB
#$02
STAB
LCD_Register_I
CLR
Char_28
RTS
Write_to_LCD_e LDAB
#$C0
STAB
LCD_Register_I
LDAB
#$10
STAB
Char_28
RTS
* ----------------------------------------------------------------* Delays 7 millisec.
* ----------------------------------------------------------------Delay_7ms
PSHY
LDY
#$1004
Delay_7ms_a
DEY
BNE
Delay_7ms_a
PULY
RTS
* ----------------------------------------------------------------* Delays register A /10 sec. with break
90
Appendice C.
Listato del KaOS
* ----------------------------------------------------------------Dly_A_10s_brk
LDAB
#$64
MUL
ADDD
Word_millisec
LDX
#Registers
Dly_A_10s_brk_a BRCLR
PORTA,X,#B2,Dly_A_10s_brk_b
CPD
Word_millisec
BNE
Dly_A_10s_brk_a
LDAA
#$00
RTS
Dly_A_10s_brk_b LDAA
#$01
RTS
* ----------------------------------------------------------------* Delays register A /10 sec.
* ----------------------------------------------------------------Delay_A_10s
LDAB
#$64
MUL
ADDD
Word_millisec
Delay_A_10s_a
CPD
Word_millisec
BNE
Delay_A_10s_a
RTS
* ----------------------------------------------------------------* Disabilita il kicker se gli IR laterali sono attivi
* ----------------------------------------------------------------Kick_disable
LDAA
DIGITAL_INPUT
STAA
Char_Dig_input
BITA
#$01
BEQ
Kick_disable_a
BITA
#$04
BEQ
Kick_disable_a
Kick_disable_b LDAA
Char_Dig_output
ORAA
#B0
STAA
Char_Dig_output
STAA
DIGITAL_OUTPUT
RTS
Kick_disable_a LDAA
Char_Dig_output
ANDA
#$FE
STAA
Char_Dig_output
STAA
DIGITAL_OUTPUT
RTS
* ----------------------------------------------------------------* Timer Output Compare 5 Interrupt
* ----------------------------------------------------------------TOC5_Int
LDX
#Registers
LDD
#$0320
;$03E8
ADDD
$1E,X
STD
$1E,X
BCLR
$23,X,#$F7
LDAA
$22,X
PSHA
ANDA
#$10
STAA
$22,X
CLI
BRCLR
Char_IR_enable,#$01,TOC5_a
BSR
Kick_disable
TOC5_a
LDAA
#$14
STAA
$30,X
LDX
Word_millisec
INX
STX
Word_millisec
LDAA
Char_Kicker
BEQ
TOC5_c
BRCLR
Char_Kicker,#B4,TOC5_a1
LDD
Word_Rkick
CPD
Word_millisec
BNE
TOC5_a1
BSET
Char_Dig_output,#B4
BCLR
Char_Kicker,#B4
TOC5_a1
BRCLR
91
Appendice C.
TOC5_a2
TOC5_a3
TOC5_a4
TOC5_c
TOC5_d
TOC5_e
TOC5_f
TOC5_g
TOC5_h
TOC5_i
TOC5_j
TOC5_k
Listato del KaOS
LDD
CPD
BNE
BSET
BCLR
BRCLR
LDD
CPD
BNE
BSET
BCLR
BRCLR
LDD
CPD
BNE
BSET
BCLR
LDAA
STAA
LDX
LDD
STX
PSHA
CLRA
NEGB
BGE
LDAA
LDX
CMPB
BGE
LDX
CMPB
BGE
LDX
CMPB
BGE
LDX
STX
CMPB
BLT
LDX
STX
CMPB
BGT
LDX
STX
NEGB
ADCA
NEGA
ADDD
STD
CLRA
PULB
TSTB
BGE
LDAA
LDX
CMPB
BGE
LDX
CMPB
BGE
LDX
CMPB
BGE
LDX
STX
CMPB
BLT
LDX
STX
CMPB
Word_FRkick
Word_millisec
TOC5_a2
Char_Dig_output,#B3
Char_Kicker,#B3
Word_Lkick
Word_millisec
TOC5_a3
Char_Dig_output,#B2
Char_Kicker,#B2
Word_FLkick
Word_millisec
TOC5_a4
Char_Dig_output,#B1
Char_Kicker,#B1
Char_Dig_output
DIGITAL_OUTPUT
#$0000
Char_49
Char_49
TOC5_d
#$FF
#Array_4
#$0C
TOC5_e
#Array_3
#$00
TOC5_e
#Array_1
#$F4
TOC5_e
#Array_2
Word_30
#$19
TOC5_f
#$001E
Word_PWM_cycl_L
#$E7
TOC5_g
#$001E
Word_PWM_cycl_L
#$0
Word_49
Word_49
TOC5_i
#$FF
#Array_2
#$0C
TOC5_j
#Array_1
#$00
TOC5_j
#Array_3
#$F4
TOC5_j
#Array_4
Word_29
#$19
TOC5_k
#$001E
Word_PWM_cycl_R
#$E7
92
Appendice C.
TOC5_l
TOC5_m
TOC5_n
TOC5_r
TOC5_s
TOC5_q
TOC5_x
TOC5_w
TOC5_v
TOC5_y
TOC5_z
TOC5_af
TOC5_ai
TOC5_ah
TOC5_am
TOC5_ao
TOC5_aq
Listato del KaOS
BGT
LDX
STX
NEGB
ADCA
NEGA
ADDD
STD
JSR
DEC
BNE
LDAA
STAA
LDAA
STAA
LDAA
BEQ
BITA
BEQ
JSR
BRA
BITA
BEQ
JSR
LDAA
DECA
BGT
DEC
BGT
LDD
STD
STD
STD
LDAA
BNE
STD
STD
LDD
STD
LDAA
STAA
CMPA
BNE
DEC
CMPA
BNE
DEC
CMPA
BNE
DEC
CMPA
BNE
LDAA
BEQ
JMP
LDX
BRSET
JMP
BRCLR
CMPA
BNE
JMP
CMPA
BNE
JMP
CMPA
BNE
JMP
CMPA
BNE
BRCLR
JMP
TOC5_l
#$001E
Word_PWM_cycl_R
#$0
Word_48
Word_48
Write_to_LCD
Char_9
TOC5_q
#$FF
Char_28
#$C8
Char_9
Char_oper_flags
TOC5_q
#$02
TOC5_s
Subroutine_49
TOC5_q
#$04
TOC5_q
Wri_mottst_data
Char_70
TOC5_v
Char_watcdg_cnt
TOC5_w
#$0000
Word_12
Word_14
Word_13
Char_motor_test
TOC5_x
Word_56
Word_57
Word_Thpos
Word_ang_setpnt
#$14
Char_70
#$14
TOC5_y
Char_25
#$13
TOC5_z
Char_45
#$12
TOC5_af
Char_44
#$0A
TOC5_ah
Char_modo_test
TOC5_ai
TOC5_ak
#Registers
PORTA,X,#$04,TOC5_ak
TOC5_test
Char_58,#$04,TOC5_ak
#$09
TOC5_am
TOC5_an
#$07
TOC5_ao
TOC5_PID_ctr_L
#$05
TOC5_aq
TOC5_PID_ctr_R
#$03
TOC5_ak
Char_58,#$40,TOC5_ak
TOC5_as
93
Appendice C.
Listato del KaOS
TOC5_ak
LDD
STD
LDAA
DECA
ANDA
BNE
LDAB
LSRB
LSRB
LDX
ABX
LDAB
BEQ
CLRA
LSLD
STD
LSLD
LSLD
ADDD
ORAB
STD
LDAA
LSLA
LSLA
LSLA
ANDA
STAA
LDAA
ANDA
ORAA
STAA
STAA
BRCLR
TST
BGT
LDAA
STAA
LDX
BRSET
BRA
LDD
STD
LDD
STD
CPD
BLE
LDAA
STAA
LDD
STD
CPD
BLE
LDAA
STAA
LDD
STD
STD
BRA
CLRA
LDAB
TST
BEQ
LSRB
ADDD
STD
CLRA
LDAB
TST
BEQ
LSRB
ADDD
STD
*
*
*
*
*
TOC5_at
*
*
TOC5_aw
TOC5_ax
TOC5_ay
TOC5_az
TOC5_av
TOC5_ba
TOC5_bb
#$0000
Word_22
Char_70
#$03
TOC5_at
Char_70
#$01C3
$00,X
TOC5_at
Word_22
Word_22
#$01
Word_22
Char_70
#$E0
Char_81
Char_Dig_output
#$1F
Char_81
Char_Dig_output
DIGITAL_OUTPUT
Char_58,#$80,TOC5_au
Char_44
TOC5_av
#$19
Char_44
#Registers
PORTD,X,#B4,TOC5_aw
; THERMAL FLAG
TOC5_ax
#$0000
Char_stall_L
Word_intg_cur_L
Word_mot_curr_L
#$7FFF
;EE_Word_Stallmx
TOC5_ay
#$01
Char_stall_L
Word_intg_cur_R
Word_mot_curr_R
#$7FFF
;EE_Word_Stallmx
TOC5_az
#$01
Char_stall_R
#$0000
Word_intg_cur_L
Word_intg_cur_R
TOC5_au
(Registers+ADR1_MOTOR_L)
Char_87
TOC5_ba
Word_intg_cur_L
Word_intg_cur_L
(Registers+ADR2_MOTOR_R)
Char_88
TOC5_bb
Word_intg_cur_R
Word_intg_cur_R
94
Appendice C.
Listato del KaOS
TOC5_au
BRCLR
BRCLR
LDAA
DECA
BGT
LDAA
STAA
CMPA
BNE
JMP
CMPA
BNE
JMP
CMPA
BNE
JMP
LDAA
BGT
LDAA
STAA
LDX
LDAA
EORA
STAA
BEQ
LDAA
STAA
BCLR
BRA
LDAA
STAA
BSET
JSR
BRCLR
LDAA
CMPA
BEQ
TSTA
BGT
LDAA
STAA
JSR
PULA
STAA
RTI
TST
BEQ
TST
BNE
LDX
STX
LDAA
STAA
CLR
LDAA
STAA
LDAA
STAA
BRA
TOC5_bd
TOC5_be
TOC5_bg
TOC5_bc
TOC5_bk
TOC5_bj
TOC5_bl
TOC5_bm
TOC5_test
BRCLR
LDAA
STAA
LDD
STD
STD
STD
LDD
STD
LDX
JSR
JMP
95
Char_58,#$01,TOC5_bc
Char_24,#$FF,TOC5_bc
Char_89
TOC5_bd
#$28
Char_89
#$02
TOC5_be
TOC5_bc
#$01
TOC5_bg
TOC5_bc
#$14
TOC5_bc
TOC5_bc
Char_25
TOC5_bj
#$19
Char_25
#Registers
Char_6
#$01
Char_6
TOC5_bk
#$2A
Display_char_31
PORTA,X,#$08
TOC5_bj
#$A0
Display_char_31
PORTA,X,#$08
Write_to_LCD
Char_58,#$20,TOC5_bl
Char_45
#$03
TOC5_bm
TOC5_bl
#$05
Char_45
Data_packet
(TMSK1+Registers)
Char_15
TOC5_bl
Char_2
TOC5_bl
#$01D5
Word_50
Char_15
Char_36
Char_15
#$01
Char_2
#$AC
(Registers+SCCR2)
TOC5_bl
PORTA,X,#$04,TOC5_test
#$01
Char_modo_test
#$0000
Word_ang_setpnt
Word_Thpos
Word_7
#$7FFF
Word_Revcount
#MSG_test
String_to_buf
TOC5_ak
; cuore (2A)
; cuore (A0)
Appendice C.
Listato del KaOS
MSG_test
fcc
fcb
’Inizio modo test,premere il BOOT.’
0
Subroutine_49
LDY
LDAB
JSR
LDY
LDAB
JSR
LDD
SUBD
XGDY
LDAB
JSR
RTS
Word_48
#$06
Wri_Y_5_digit
Word_49
#$0F
Wri_Y_5_digit
Word_48
Word_49
#$16
Wri_Y_5_digit
Set_mottst_flag JSR
BSET
LDX
JSR
RTS
Set_motors_on
#MSG_PA
String_to_buf
Wri_mottst_data LDY
LDAB
JSR
LDY
LDAB
JSR
LDY
LDAB
JSR
LDY
LDAB
JMP
RTS
Word_Right_vel
#$04
Wri_Y_3_digit
Word_Left_vel
#$0B
Wri_Y_3_digit
Word_appl_R_pwr
#$13
Wri_Y_3_digit
Word_appl_L_pwr
#$18
Wri_Y_3_digit
MSG_PA
fcc
fcb
’P
0
Set_motors_on
LDD
STAA
STD
STD
STD
STD
STD
STAA
STD
STD
STD
STD
STAA
STD
STD
STD
STD
STD
STD
STD
STD
BSET
RTS
#$0000
Char_47
Char_49
Word_48
Word_49
Word_Right_vel
Word_Left_vel
Char_Stall_cont
Word_PWM_cycl_L
Word_PWM_cycl_R
Word_56
Word_57
Char_70
Word_err_attu_R
Word_err_prec_R
Word_dposprec_R
Word_tens_mot_R
Word_err_attu_L
Word_err_prec_L
Word_dposprec_L
Word_tens_mot_L
Char_58,#$04
BCLR
BCLR
LDD
STD
STD
LDAA
JSR
LDD
Char_58,#$04
#$0000
Word_PWM_cycl_L
Word_PWM_cycl_R
#$01
Dly_A_10s_brk
#$0000
*
CLOSE_MOTORS_a
A’
96
Appendice C.
TOC5_PID_ctr_R
TOC5_ct
TOC5_cu
TOC5_cu1
TOC5_cv
TOC5_cw
TOC5_cz
TOC5_da
TOC5_PID_ctr_L
TOC5_db
TOC5_dc
Listato del KaOS
STD
STD
RTS
Word_PWM_cycl_L
Word_PWM_cycl_R
CLR
LDD
CPD
BLT
LDAA
STAA
STAA
LDD
BRA
CPD
BGT
LDAA
STAA
STAA
LDD
SUBD
LDX
STD
JSR
CMPB
BEQ
BLT
ADDB
BRA
ADDB
STD
LDX
TSTA
BPL
BCLR
NEGB
ADCA
NEGA
BRSET
LDD
BRA
BSET
BRSET
LDD
STD
JMP
Char_88
Word_Right_vel
#$0005
TOC5_ct
#$03
Char_Motorstatu
Char_88
Word_Right_vel
TOC5_cu
#$FFFB
TOC5_cu
#$03
Char_Motorstatu
Char_88
Word_Right_vel
Word_57
#Word_err_attu_R
$00,X
Motor_PID_ctr
#$00
TOC5_cv
TOC5_cu1
#$08
TOC5_cv
#$F8
Word_appl_R_pwr
#Registers
LDAA
STAA
CLR
LDD
CPD
BLT
LDAA
STAA
STAA
LDD
BRA
CPD
BGT
LDAA
STAA
STAA
LDD
SUBD
LDX
STD
BSR
CMPB
BEQ
BLT
ADDB
BRA
#$02
Char_Motorstatu
Char_87
Word_Left_vel
#$0005
TOC5_db
#$03
Char_Motorstatu
Char_87
Word_Left_vel
TOC5_dc
#$FFFB
TOC5_dc
#$03
Char_Motorstatu
Char_87
Word_Left_vel
Word_56
#Word_err_attu_L
$00,X
Motor_PID_ctr
#$00
TOC5_dd
TOC5_de
#$08
TOC5_dd
97
TOC5_cz
PORTG,X,#$02
#$0
Char_Dig_input,#$04,TOC5_da
#$0000
TOC5_da
PORTG,X,#$02
Char_Dig_input,#$01,TOC5_da
#$0000
Word_PWM_cycl_R
TOC5_ak
; IR STOP
; IR STOP
Appendice C.
Listato del KaOS
TOC5_de
TOC5_dd
ADDB
STD
LDX
TSTA
BPL
BSET
NEGB
ADCA
NEGA
BRSET
LDD
BRA
BCLR
BRSET
LDD
STD
JMP
#$F8
Word_appl_L_pwr
#Registers
CLR
LDD
BGE
INC
NEGB
ADCA
NEGA
STAA
LDAA
MUL
STAA
LDAA
LDAB
MUL
ADDB
ADCA
TST
BGT
NEGB
ADCA
NEGA
STD
CLR
LDD
STD
BGE
INC
NEGB
ADCA
NEGA
STAA
LDAA
MUL
STAA
LDAA
LDAB
MUL
ADDB
ADCA
TST
BEQ
NEGB
ADCA
NEGA
ADDD
STD
CLR
LDD
STD
BGE
INC
NEGB
ADCA
NEGA
Char_temp_2
$04,X
Motor_PID_ctr_a
Char_temp_2
TOC5_df
TOC5_di
TOC5_dj
Motor_PID_ctr
Motor_PID_ctr_a
Motor_PID_ctr_b
Motor_PID_ctr_c
Motor_PID_ctr_d
98
TOC5_di
PORTG,X,#$01
#$0
Char_Dig_input,#$04,TOC5_dj
#$0000
TOC5_dj
PORTG,X,#$01
Char_Dig_input,#$01,TOC5_dj
#$0000
Word_PWM_cycl_L
TOC5_ak
#$0
Char_temp_3
$08,X
Char_temp_5
$08,X
Char_temp_3
Char_temp_5
#$0
Char_temp_2
Motor_PID_ctr_b
#$0
Word_temp_1
Char_temp_2
$02,X
$04,X
Motor_PID_ctr_c
Char_temp_2
#$0
Char_temp_3
$07,X
Char_temp_5
$07,X
Char_temp_3
Char_temp_5
#$0
Char_temp_2
Motor_PID_ctr_d
#$0
Word_temp_1
Word_temp_1
Char_temp_2
$00,X
$02,X
Motor_PID_ctr_e
Char_temp_2
#$0
; IR STOP
; IR STOP
Appendice C.
Listato del KaOS
Motor_PID_ctr_e STAA
LDAA
MUL
STAA
LDAA
LDAB
MUL
ADDB
ADCA
TST
BGT
NEGB
ADCA
NEGA
Motor_PID_ctr_f ADDD
ADDD
CPD
BLE
LDD
Motor_PID_ctr_g CPD
BGE
LDD
Motor_PID_ctr_h STD
RTS
Char_temp_3
$06,X
Char_temp_5
$06,X
Char_temp_3
Char_temp_5
#$0
Char_temp_2
Motor_PID_ctr_f
#$0
Word_temp_1
$09,X
#$0048
Motor_PID_ctr_g
#$0048
#$FFB8
Motor_PID_ctr_h
#$FFB8
$09,X
Subroutine_34
LDD
STD
STD
STD
BSET
BSET
RTS
#$0000
Word_Thpos
Word_7
Word_ang_setpnt
Char_58,#$08
Char_59,#$02
Subroutine_35
BCLR
BCLR
RTS
Char_58,#$08
Char_59,#$02
TOC5_an
LDD
STD
ADDD
STD
LDD
STD
ADDD
STD
LDD
STD
STD
LDD
ADDD
STD
LDD
SUBD
BEQ
CPD
BLE
LDD
ADDD
STD
BRA
ADDD
BGE
LDD
SUBD
STD
BRA
LDD
STD
LDD
SUBD
STD
TST
Word_48
Word_Right_vel
Word_20
Word_20
Word_49
Word_Left_vel
Word_19
Word_19
#$0000
Word_48
Word_49
Word_Right_vel
Word_Left_vel
Word_83
Word_14
Word_12
TOC5_dk
Word_Acceleraz
TOC5_dl
Word_12
Word_Acceleraz
Word_12
TOC5_dk
Word_Acceleraz
TOC5_dm
Word_12
Word_Acceleraz
Word_12
TOC5_dk
Word_14
Word_12
Word_Right_vel
Word_Left_vel
Word_4
Word_Revcount
TOC5_dl
TOC5_dm
TOC5_dk
99
;$005C
;$005C
;$FFA4
;$FFA4
Appendice C.
TOC5_dn
TOC5_do
TOC5_dp
TOC5_dq
TOC5_dr
TOC5_dt
TOC5_du
TOC5_dv
TOC5_dw
Listato del KaOS
BLT
ADDD
BLT
CPD
BLT
SUBD
BRA
ADDD
BVS
BGE
CPD
BLT
TST
BGE
SUBD
BRA
ADDD
STD
LSRD
LSRD
LSRD
LSRD
LDX
FDIV
XGDX
STD
BRSET
LDD
STD
JMP
BRSET
JMP
LDD
SUBD
BLT
CPD
BLT
SUBD
BRA
CPD
BGT
ADDD
STD
LDD
STAA
BGE
NEGA
ADCA
NEGB
LSRD
LSRD
LSRD
LSRD
LSRD
TBA
MUL
STD
LSRD
LSRD
LSRD
LSRD
TST
BLT
NEGB
ADCA
NEGA
ADDD
BLT
CPD
BLE
CPD
BLE
TOC5_dn
Word_7
TOC5_do
Word_Revcount
TOC5_dp
Word_Revcount
TOC5_dp
Word_7
TOC5_dp
TOC5_dp
Word_Revcount
TOC5_dp
Word_7
TOC5_do
Word_Revcount
TOC5_dp
Word_Revcount
Word_7
Word_Revcount
Word_Thpos
Char_58,#$08,TOC5_dq
Word_Thpos
Word_ang_setpnt
TOC5_ak
Char_59,#$02,TOC5_dr
TOC5_ds
Word_ang_setpnt
Word_Thpos
TOC5_dt
#$0800
TOC5_du
#$1000
TOC5_du
#$F800
TOC5_du
#$1000
Word_6
Word_4
Char_temp_2
TOC5_dv
#$0
Word_8
Char_temp_2
TOC5_dw
#$0
Word_6
TOC5_dx
Word_34
TOC5_dy
Word_32
TOC5_dz
100
Appendice C.
TOC5_dx
TOC5_dy
TOC5_dz
TOC5_eb
TOC5_ds
TOC5_ea
TOC5_ec
TOC5_ed
TOC5_ef
TOC5_ee
TOC5_eh
TOC5_eg
Listato del KaOS
LDD
BRA
CPD
BGE
CPD
BGT
LDD
BRA
LDD
ASRA
RORB
ASRA
RORB
STD
SUBD
BEQ
CPD
BLE
LDD
ADDD
STD
BRA
ADDD
BGE
LDD
SUBD
STD
BRA
LDD
STD
LDD
CLR
LDD
ADDD
CPD
BLE
LDD
INC
BRA
CPD
BGE
LDD
INC
STD
SUBD
SUBD
CPD
BLE
BRSET
SUBD
STD
LDD
SUBD
STD
LDD
BRA
CPD
BGE
BRSET
SUBD
STD
LDD
SUBD
STD
LDD
STD
JMP
Word_32
TOC5_dz
Word_35
TOC5_dy
Word_33
TOC5_dz
Word_33
TOC5_dz
#$0000
Word_51
Word_13
TOC5_ea
#$0008
TOC5_eb
Word_13
#$0008
Word_13
TOC5_ea
#$0008
TOC5_ds
Word_13
#$0008
Word_13
TOC5_ea
Word_51
Word_13
Word_13
Char_temp_2
Word_12
Word_13
Word_36
TOC5_ec
Word_36
Char_temp_2
TOC5_ed
Word_37
TOC5_ed
Word_37
Char_temp_2
Word_57
Word_13
Word_13
Word_36
TOC5_ee
Char_temp_2,#$01,TOC5_ef
Word_36
Char_81
Word_57
Char_81
Word_57
Word_36
TOC5_eg
Word_37
TOC5_eg
Char_temp_2,#$01,TOC5_eh
Word_37
Char_81
Word_57
Char_81
Word_57
Word_37
Word_56
TOC5_ak
TABELLA_sin fcb 0,0,1,001,002,002,002,003,003,004,004,004,005,005,005,006
fcb 006,007,007,007,008,008,009,009,009,010,010,011,011,011,012,012
fcb 013,013,013,014,014,014,015,015,016,016,016,017,017,018,018,018
fcb 019,019,020,020,020,021,021,021,022,022,023,023,023,024,024,025
101
Appendice C.
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
fcb
Listato del KaOS
025,025,026,026,027,027,027,028,028,028,029,029,030,030,030,031
031,032,032,032,033,033,034,034,034,035,035,035,036,036,037,037
037,038,038,039,039,039,040,040,041,041,041,042,042,042,043,043
044,044,044,045,045,046,046,046,047,047,047,048,048,049,049,049
050,050,051,051,051,052,052,052,053,053,054,054,054,055,055,055
056,056,057,057,057,058,058,059,059,059,060,060,060,061,061,062
062,062,063,063,063,064,064,065,065,065,066,066,067,067,067,068
068,068,069,069,070,070,070,071,071,071,072,072,073,073,073,074
074,074,075,075,076,076,076,077,077,077,078,078,079,079,079,080
080,080,081,081,081,082,082,083,083,083,084,084,084,085,085,086
086,086,087,087,087,088,088,088,089,089,090,090,090,091,091,091
092,092,093,093,093,094,094,094,095,095,095,096,096,096,097,097
098,098,098,099,099,099,100,100,100,101,101,102,102,102,103,103
103,104,104,104,105,105,105,106,106,107,107,107,108,108,108,109
109,109,110,110,110,111,111,111,112,112,113,113,113,114,114,114
115,115,115,116,116,116,117,117,117,118,118,118,119,119,120,120
120,121,121,121,122,122,122,123,123,123,124,124,124,125,125,125
126,126,126,127,127,127,128,128,128,129,129,129,130,130,130,131
131,131,132,132,132,133,133,133,134,134,134,135,135,135,136,136
136,137,137,137,138,138,138,139,139,139,140,140,140,141,141,141
142,142,142,143,143,143,144,144,144,145,145,145,146,146,146,147
147,147,147,148,148,148,149,149,149,150,150,150,151,151,151,152
152,152,153,153,153,153,154,154,154,155,155,155,156,156,156,157
157,157,158,158,158,158,159,159,159,160,160,160,161,161,161,161
162,162,162,163,163,163,164,164,164,164,165,165,165,166,166,166
167,167,167,167,168,168,168,169,169,169,170,170,170,170,171,171
171,172,172,172,172,173,173,173,174,174,174,174,175,175,175,176
176,176,176,177,177,177,178,178,178,178,179,179,179,179,180,180
180,181,181,181,181,182,182,182,183,183,183,183,184,184,184,184
185,185,185,185,186,186,186,187,187,187,187,188,188,188,188,189
189,189,189,190,190,190,191,191,191,191,192,192,192,192,193,193
193,193,194,194,194,194,195,195,195,195,196,196,196,196,197,197
197,197,198,198,198,198,199,199,199,199,200,200,200,200,201,201
201,201,202,202,202,202,202,203,203,203,203,204,204,204,204,205
205,205,205,206,206,206,206,206,207,207,207,207,208,208,208,208
208,209,209,209,209,210,210,210,210,210,211,211,211,211,212,212
212,212,212,213,213,213,213,214,214,214,214,214,215,215,215,215
215,216,216,216,216,216,217,217,217,217,218,218,218,218,218,219
219,219,219,219,220,220,220,220,220,221,221,221,221,221,221,222
222,222,222,222,223,223,223,223,223,224,224,224,224,224,225,225
225,225,225,225,226,226,226,226,226,227,227,227,227,227,227,228
228,228,228,228,228,229,229,229,229,229,230,230,230,230,230,230
231,231,231,231,231,231,232,232,232,232,232,232,232,233,233,233
233,233,233,234,234,234,234,234,234,235,235,235,235,235,235,235
236,236,236,236,236,236,236,237,237,237,237,237,237,237,238,238
238,238,238,238,238,239,239,239,239,239,239,239,240,240,240,240
240,240,240,240,241,241,241,241,241,241,241,242,242,242,242,242
242,242,242,242,243,243,243,243,243,243,243,243,244,244,244,244
244,244,244,244,244,245,245,245,245,245,245,245,245,245,246,246
246,246,246,246,246,246,246,246,247,247,247,247,247,247,247,247
247,247,248,248,248,248,248,248,248,248,248,248,248,249,249,249
249,249,249,249,249,249,249,249,249,250,250,250,250,250,250,250
250,250,250,250,250,250,251,251,251,251,251,251,251,251,251,251
251,251,251,251,252,252,252,252,252,252,252,252,252,252,252,252
252,252,252,252,252,253,253,253,253,253,253,253,253,253,253,253
253,253,253,253,253,253,253,253,253,253,254,254,254,254,254,254
254,254,254,254,254,254,254,254,254,254,254,254,254,254,254,254
254,254,254,254,254,254,254,254,255,255,255,255,255,255,255,255
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255
255,255
Subroutine_31
LDD
STD
STD
STD
STD
STD
BSET
RTS
#$0000
Word_Xpos
Word_10
Word_11
Word_Thpos
Word_7
Char_58,#$40
TOC5_as
CLR
Char_temp_2
102
Appendice C.
TOC5_ei
TOC5_ej
TOC5_ek
TOC5_el
TOC5_em
Subroutine_56
Listato del KaOS
LDD
BPL
NEGB
ADCA
NEGA
INC
LSRD
BCC
ADDD
STD
LDD
CPD
BGE
LDX
BSR
LDD
SUBD
LDX
BSR
JMP
CPD
BGE
INC
SUBD
LDX
BSR
INC
LDD
SUBD
LDX
BSR
JMP
CPD
BGE
INC
SUBD
LDX
BSR
LDD
SUBD
LDX
BSR
JMP
SUBD
LDX
BSR
INC
LDD
SUBD
LDX
BSR
JMP
ADDD
XGDY
LDAA
LDAB
MUL
BRCLR
STD
LDD
SUBD
STD
LDAA
SBCA
STAA
TST
BEQ
LDAB
CLRA
STD
LDD
Word_83
TOC5_ei
#$0
Char_temp_2
TOC5_ej
#$0001
Word_83
Word_Thpos
#$0400
TOC5_ek
#Word_Ypos
Subroutine_56
#$0400
Word_Thpos
#Word_Xpos
Subroutine_56
TOC5_ak
#$0800
TOC5_el
Char_temp_2
#$0400
#Word_Xpos
Subroutine_56
Char_temp_2
#$0800
Word_Thpos
#Word_Ypos
Subroutine_56
TOC5_ak
#$0C00
TOC5_em
Char_temp_2
#$0800
#Word_Ypos
Subroutine_56
#$0C00
Word_Thpos
#Word_Xpos
Subroutine_56
TOC5_ak
#$0C00
#Word_Xpos
Subroutine_56
Char_temp_2
#$1000
Word_Thpos
#Word_Ypos
Subroutine_56
TOC5_ak
#TABELLA_sin
$00,Y
Char_22
Char_temp_2,#$01,Subroutine_56_a
Char_temp_3
$01,X
Char_temp_3
$01,X
$00,X
#$00
$00,X
Word_83
Subroutine_56_b
$00,Y
Char_temp_3
$00,X
103
Appendice C.
Listato del KaOS
SUBD
STD
RTS
Subroutine_56_a ADDD
STD
LDAA
ADCA
STAA
TST
BEQ
LDAB
CLRA
ADDD
STD
Subroutine_56_b RTS
TOC4_Int
TOC4_Int_b
TOC4_Int_a
TOC4_Int_c
Array_1 fcb
fcb
fcb
fcb
LDX
LDD
ADDD
STD
BCLR
LDAA
ANDA
ORAA
TAB
ANDB
LDX
ABX
LDAB
SUBB
STAB
CLC
RORA
RORA
TAB
ANDB
RORA
RORA
RORA
ANDA
STAA
LDX
ABX
LDAB
SUBB
STAB
LDX
BRSET
LDD
BEQ
ADDD
STD
BCLR
BSET
BSET
LDD
BEQ
ADDD
STD
BCLR
BSET
BSET
BSET
RTI
Char_temp_3
$00,X
$01,X
$01,X
$00,X
#$0
$00,X
Word_83
Subroutine_56_b
$00,Y
$00,X
$00,X
#Registers
#$0050
TOC4,X
TOC4,X
TFLG1,X,#(B7+B6+B5+B3+B2+B1+B0)
PORTE,X
#(B3+B2+B1+B0)
Char_47
#(B5+B4+B3+B2+B1+B0)
Word_30
Char_48
$00,X
Char_48
#(B5+B4+B3+B2+B1+B0)
#(B7+B6+B5+B4)
Char_47
Word_29
Char_49
$00,X
Char_49
#Registers
PORTD,X,#B4,TOC4_Int_a
Word_PWM_cycl_L
TOC4_Int_b
TCNT,X
TOC1,X
OC1D,X,#B7
CFORC,X,#B7
OC1D,X,#B7
Word_PWM_cycl_R
TOC4_Int_a
TCNT,X
TOC2,X
TCTL1,X,#B6
CFORC,X,#B6
TCTL1,X,#B6
OC1D,X,#B7
000,255,001,254,000,255,001,254,000,255,001,254,000,255,001,254
001,000,254,255,001,000,254,255,001,000,254,255,001,000,254,255
255,254,000,001,255,254,000,001,255,254,000,001,255,254,000,001
254,001,255,000,254,001,255,000,254,001,255,000,254,001,255,000
Array_2 fcb 000,255,253,254,000,255,253,254,000,255,253,254,000,255,253,254
104
Appendice C.
Listato del KaOS
fcb 253,000,254,255,253,000,254,255,253,000,254,255,253,000,254,255
fcb 255,254,000,253,255,254,000,253,255,254,000,253,255,254,000,253
fcb 254,253,255,000,254,253,255,000,254,253,255,000,254,253,255,000
Array_3 fcb
fcb
fcb
fcb
000,255,001,002,000,255,001,002,000,255,001,002,000,255,001,002
001,000,002,255,001,000,002,255,001,000,002,255,001,000,002,255
255,002,000,001,255,002,000,001,255,002,000,001,255,002,000,001
002,001,255,000,002,001,255,000,002,001,255,000,002,001,255,000
Array_4 fcb
fcb
fcb
fcb
000,003,001,002,000,003,001,002,000,003,001,002,000,003,001,002
001,000,002,003,001,000,002,003,001,000,002,003,001,000,002,003
003,002,000,001,003,002,000,001,003,002,000,001,003,002,000,001
002,001,003,000,002,001,003,000,002,001,003,000,002,001,003,000
Subroutine_33
LDD
STAA
STD
STD
BSET
RTS
#$0000
Char_44
Word_intg_cur_L
Word_intg_cur_R
Char_58,#$80
Init_sonars
LDAA
STAA
STAA
STAA
LDD
STD
LDAA
STAA
BSET
RTS
#$00
Char_89
Char_23
Char_sonar_rdng
#$00EA
Word_80
#$00
(Registers+PORTG)
Char_58,#$01
* ----------------------------------------------------------------* Clear sonars
* ----------------------------------------------------------------Clear_sonars
BCLR
Char_58,#$01
BCLR
LDAA
#$00
STAA
(Registers+PORTG)
STAA
Char_sonar_rdng
RTS
* ----------------------------------------------------------------* RS232 Init
* ----------------------------------------------------------------RS232_Init
LDAA
#$FA
STAA
Char_32
CLRA
STAA
Char_33
STAA
Char_34
LDAA
#$04
STAA
Char_Motorstatu
LDAA
#$01
STAA
Char_35
STAA
Char_36
CLR
Char_2
LDAA
#(B5+B3+B2)
STAA
(Registers+SCCR2)
CLR
(Registers+SCCR1)
RTS
* ----------------------------------------------------------------* RS232 Interrupt disable
* ----------------------------------------------------------------RS232_R_int_dis JSR
Subroutine_21
LDAA
#(B3+B2)
STAA
(Registers+SCCR2)
CLR
(Registers+SCCR1)
RTS
105
Appendice C.
Listato del KaOS
Subroutine_17
LDAA
JSR
LDX
LDAA
STAA
LDAA
STAA
CMPA
BEQ
JMP
PSHY
INX
INX
LDY
LDAA
STAA
BEQ
INX
INY
BRA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDY
LDAA
STAA
BEQ
INX
INY
BRA
INX
XGDX
SUBD
STAB
PULY
JMP
Subroutine_17_a
Subroutine_17_b
Subroutine_17_c
Subroutine_17_d
Subroutine_17_e
106
#$01
Delay_A_10s
#Char_Byte_count
#$03
$00,X
Char_nr_comando
$01,X
#$02
Subroutine_17_a
Data_packet_d
#Array_name
$00,Y
$00,X
Subroutine_17_c
;#EE_Array_Name
Subroutine_17_b
#$70
$00,X
#$69
$00,X
#$6F
$00,X
#$6E
$00,X
#$65
$00,X
#$65
$00,X
#$72
$00,X
#$00
$00,X
#Array_subcla
$00,Y
$00,X
Subroutine_17_e
Subroutine_17_d
#$0120
Char_Byte_count
Data_packet_d
Array_subcla
fcc
fcb
’Pion1m’
0
Array_name
fcc
fcb
’galavron’
0
Subroutine_27
PSHY
LDAB
CMPB
BLE
INX
CLRA
XGDY
$00,X
#$02
Subroutine_27_a
;#EE_Array_Subcla
Appendice C.
Listato del KaOS
DEY
LDD
Subroutine_27_c DEY
BEQ
DEY
BEQ
ADDD
INX
INX
BRA
Subroutine_27_b EORB
INX
Subroutine_27_a PULY
RTS
SCI_Int_b
SCI_Int_e
SCI_Int_c
SCI_Int
SCI_Int_a
SCI_Int_d
SCI_Int_f
SCI_Int_h
SCI_Int_j
LDX
LDAA
STAA
INX
STX
DEC
BNE
LDAA
STAA
CLR
LDAA
BITA
BNE
RTI
LDAA
LDAB
BEQ
BITA
BNE
BITA
BEQ
LDAA
LDX
LDAB
PSHB
ANDB
STAB
CLI
LDAB
CMPB
BNE
CMPA
BNE
LDAA
STAA
BRA
CMPB
BNE
CMPA
BNE
LDAA
STAA
BRA
CMPB
BNE
STAA
BLT
CMPA
BGT
STAA
LDAA
STAA
BRA
CMPB
BNE
LDY
LDAB
#$0000
Subroutine_27_a
Subroutine_27_b
$00,X
Subroutine_27_c
$00,X
Word_50
$00,X
(Registers+SCDR)
Word_50
Char_36
SCI_Int_e
#$2C
(Registers+SCCR2)
Char_2
(Registers+SCSR)
#$28
SCI_Int_d
(Registers+SCSR)
Char_2
SCI_Int_a
#$80
SCI_Int_b
#$28
SCI_Int_c
(Registers+SCDR)
#Registers
$22,X
#$10
$22,X
Char_32
#$FA
SCI_Int_f
#$FA
SCI_Int_g
#$FB
Char_32
SCI_Int_g
#$FB
SCI_Int_h
#$FB
SCI_Int_i
#$01
Char_32
SCI_Int_g
#$01
SCI_Int_j
$015D
SCI_Int_i
#$32
SCI_Int_i
Char_33
#$02
Char_32
SCI_Int_g
#$02
SCI_Int_i
#$015D
Char_35
107
Appendice C.
SCI_Int_l
SCI_Int_k
SCI_Int_i
SCI_Int_g
Data_packet_d
Data_packet_e
Subroutine_28
Listato del KaOS
ABY
STAA
INCB
STAB
DEC
BGT
LDX
JSR
DEY
CPD
BNE
LDAA
STAA
BRCLR
LDAA
STAA
BSR
BRA
LDAA
STAA
BRCLR
LDAA
STAA
LDAA
STAA
LDAA
STAA
PULA
STAA
RTI
TST
BNE
LDX
STX
INX
INX
JSR
STD
LDAA
ADDA
STAA
LDAA
STAA
LDAA
STAA
RTS
LDD
STD
LDX
LDAA
STAA
INX
LDAA
INX
CMPA
BEQ
CMPA
BNE
LDAA
STAA
INX
LDAA
STAA
BRA
Subroutine_28_b CMPA
BNE
LDAA
STAA
INX
LDAA
$00,Y
Char_35
Char_33
SCI_Int_g
#$015D
Subroutine_27
$00,Y
SCI_Int_k
#$01
Char_34
Char_oper_flags,#$10,SCI_Int_l
#$2B
Display_char_16
Subroutine_28
SCI_Int_i
#$02
Char_34
Char_oper_flags,#$10,SCI_Int_i
#$2D
Display_char_16
#$FA
Char_32
#$01
Char_35
(Registers+TMSK1)
Char_2
Data_packet_e
#Word_Pak_header
Word_50
Subroutine_27
$00,X
Char_Byte_count
#$3
Char_36
#$01
Char_2
#$AC
(Registers+SCCR2)
#$0000
Char_cmd_arg_1
#$015E
$00,X
Char_nr_comando
$00,X
#$FE
Subroutine_28_a
#$3B
Subroutine_28_b
$00,X
Char_cmd_arg_2
$00,X
Char_cmd_arg_1
Subroutine_28_a
#$1B
Subroutine_28_c
$00,X
Char_cmd_arg_2
$00,X
108
Appendice C.
Listato del KaOS
STAA
LDD
SUBD
STD
CMPA
BNE
LDAA
STAA
BLT
CMPA
BLE
LDAA
LDY
INX
LDAB
INY
STAB
DECA
BGT
LDAA
BRCLR
ADDA
STAA
RTS
Char_cmd_arg_1
#$0000
Char_cmd_arg_1
Char_cmd_arg_1
#$2B
Subroutine_28_a
$00,X
Char_cmd_arg_2
Subroutine_28_a
#$28
Subroutine_28_d
#$28
#$00A0
Subroutine_32
BSET
CLR
CLR
RTS
Char_58,#$20
Char_45
Char_15
Subroutine_21
BCLR
RTS
Char_58,#$20
Data_packet
LDX
LDAA
STAA
INX
LDAA
ORAA
STAA
INX
LDD
ANDA
STAB
INX
STAA
INX
LDD
ANDA
STAB
INX
STAA
INX
LDD
ASRA
RORB
ASRA
RORB
STAB
INX
STAA
INX
LDD
STAB
INX
STAA
INX
LDD
STAB
INX
STAA
INX
#Char_Byte_count
#$1B
$00,X
Subroutine_28_c
Subroutine_28_d
Subroutine_28_e
Subroutine_28_a
Subroutine_28_f
$00,X
$00,Y
Subroutine_28_e
Char_nr_comando
Char_oper_flags,#$10,Subroutine_28_f
#$30
Display_char_18
Char_Motorstatu
#$30
$00,X
Word_Xpos
#$7F
$00,X
$00,X
Word_Ypos
#$7F
$00,X
$00,X
Word_Thpos
$00,X
$00,X
Word_Left_vel
$00,X
$00,X
Word_Right_vel
$00,X
$00,X
109
Appendice C.
Listato del KaOS
Data_packet_b
CLRA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
LDD
ASRA
RORB
ASRA
RORB
STAB
INX
STAA
INX
CLRA
STAA
INX
STAA
INX
LDD
LSRD
STAB
INX
LDAA
STAA
INX
TSTA
BEQ
LDY
LDAA
STAA
INX
LDD
INY
INY
INY
STAB
INX
STAA
INX
LDAA
ADDA
STAA
DEC
BGT
LDD
STD
CLR
LDD
STAB
INX
STAA
INX
CLRA
STAA
INX
LDAA
STAA
INX
LDAA
STAA
INX
JMP
Data_packet_a
Data_packet_c
Subroutine_7
LDAA
CLR
CMPA
BNE
110
; Char_batt_level
$00,X
Char_stall_L
$00,X
Char_stall_R
$00,X
Word_ang_setpnt
$00,X
$00,X
$00,X
; PTU Servo H
$00,X
; PTU Servo L
#$0000
; Word_Compass
$00,X
Char_sonar_rdng
$00,X
Data_packet_a
#Sonars_buffer
$02,Y
$00,X
$00,Y
$00,X
$00,X
Char_Byte_count
#$3
Char_Byte_count
Char_sonar_rdng
Data_packet_b
#$00EA
Word_80
Char_sonar_rdng
#$0005
$00,X
$00,X
; ADR3 - Analog Input
$00,X
DIGITAL_INPUT
$00,X
Char_Dig_output
$00,X
Data_packet_d
Char_34
Char_34
#$01
Subroutine_7_a
Appendice C.
Subroutine_7_a
Subroutine_7_b
SETV
SETV_a
SETV_b
SETRV
SETRV_a
SETRV_b
Listato del KaOS
LDAA
CMPA
BNE
ADDA
STAA
JSR
LDAA
INCA
STAA
CMPA
BLE
LDAB
STAB
RTS
CLR
LDAA
STAA
LDAB
RTS
LDD
BLT
LSRD
CPD
BLT
LDD
STD
NEGB
ADCA
NEGA
STD
RTS
LDD
BLT
LSLD
LSLD
CPD
BLT
LDD
STD
NEGB
ADCA
NEGA
STD
RTS
Char_nr_comando
Char_38
Subroutine_7_b
#$30
Display_char_5
Subroutine_17
Char_38
Char_38
#$02
Subroutine_7_a
#$00
Char_Motorstatu
Char_38
#$33
Display_char_5
#$00
Char_cmd_arg_1
SETV_b
#$01A0
SETV_a
#$01A0
Word_36
#$0
Word_37
Char_cmd_arg_1
SETRV_b
#$0100
SETRV_a
#$0100
Word_32
#$0
Word_33
SET_ORIGIN
LDD
STD
STD
STD
STD
STD
RTS
#$0000
Word_ang_setpnt
Word_Xpos
Word_Ypos
Word_Thpos
Word_7
DIGOUT
LDAA
COMA
ANDA
LDAB
ANDB
STAB
ORAA
STAA
STAA
RTS
Char_cmd_arg_1
BCLR
LDAA
STAA
BSET
LDD
ADDD
STD
RTS
Char_Dig_output,#B4
Char_Dig_output
DIGITAL_OUTPUT
Char_Kicker,#B4
Word_millisec
#$01F4
Word_Rkick
RIGHT_KICK
Char_Dig_output
Char_cmd_arg_2
Char_cmd_arg_1
Char_cmd_arg_1
Char_cmd_arg_1
Char_Dig_output
DIGITAL_OUTPUT
111
Appendice C.
Listato del KaOS
VEL2
BCLR
LDAA
LDAB
BGE
LDAA
LSLD
STD
LDAA
LDAB
BGE
LDAA
LSLD
STD
RTS
Char_58,#$08
#$00
Char_cmd_arg_1
VEL2_a
#$FF
LDAA
CLR
CMPA
BNE
LDAA
STAA
LDAA
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BNE
JMP
CMPA
BNE
JMP
CMPA
BNE
JMP
CMPA
BNE
JMP
CMPA
BNE
JMP
CMPA
BNE
JMP
RTS
Char_34
Char_34
#$01
Command_exec_l
#$64
Char_watcdg_cnt
Char_nr_comando
#$01
OPEN_MOTORS
#$02
CLOSE_MOTORS
#$07
SET_ORIGIN
#$1E
DIGOUT
#$20
VEL2
#$30
RIGHT_KICK
#$0B
Command_exec_b
VEL
#$0D
Command_exec_c
DHEAD
#$0C
Command_exec_d
HEAD
#$15
Command_exec_j
RVEL
#$06
Command_exec_k
SETV
#$0A
Command_exec_l
SETRV
CLOSE_MOTORS
LDAA
STAA
LDD
JSR
JSR
JSR
JMP
#$04
Char_Motorstatu
#$0000
Clear_sonars
Subroutine_35
Subroutine_21
CLOSE_MOTORS_a
OPEN_MOTORS
LDD
STD
STD
STD
STD
STD
STD
STD
STD
#$0000
Word_12
Word_14
Word_51
Word_13
Word_ang_setpnt
Word_Xpos
Word_Ypos
Word_Thpos
VEL2_a
VEL2_b
Command_exec
Command_exec_a
Command_exec_b
Command_exec_c
Command_exec_d
Command_exec_j
Command_exec_k
Command_exec_l
112
Word_56
#$00
Char_cmd_arg_2
VEL2_b
#$FF
Word_57
;EE_Char_Watchdg
Appendice C.
VEL
VEL_a
VEL_b
VEL_c
VEL_d
DHEAD
DHEAD_a
DHEAD_b
DHEAD_c
Listato del KaOS
STD
STD
LDD
STD
LDD
STD
LDD
STD
LDD
STD
LDAA
STAA
LDAB
STAB
LDD
STD
LDD
STD
LDD
STD
LDD
STD
JSR
JSR
JSR
JSR
JSR
JMP
Word_7
Char_stall_L
#$0100
Word_32
#$FF00
Word_33
#$01A0
Word_36
#$FE60
Word_37
#$02
Char_Motorstatu
#$07
Char_24
#$0001
Char_41
#$0203
Word_53
#$0405
Word_54
#$0607
Word_55
Init_sonars
Set_motors_on
Subroutine_31
Subroutine_32
Subroutine_33
Subroutine_34
BRSET
JSR
LDD
ASRA
RORB
STD
ASRA
RORB
ASRA
RORB
NEGB
ADCA
NEGA
ADDD
CPD
BLE
LDD
CPD
BGE
LDD
STD
RTS
Char_58,#$08,VEL_a
Subroutine_34
Char_cmd_arg_1
BRSET
JSR
BSET
CLR
LDD
BGE
NEGB
INC
LDAA
MUL
LSRD
LSRD
LSRD
LSRD
TST
BEQ
NEGB
ADCA
NEGA
ADDD
Char_58,#$08,DHEAD_a
Subroutine_34
Char_59,#$02
Char_temp_2
Char_cmd_arg_1
DHEAD_b
Char_cmd_arg_1
#$0
Char_cmd_arg_1
Word_36
VEL_c
Word_36
Word_37
VEL_d
Word_37
Word_14
Char_temp_2
#$B6
Char_temp_2
DHEAD_c
#$0
Word_ang_setpnt
113
Appendice C.
DHEAD_d
DHEAD_e
HEAD
HEAD_a
HEAD_b
HEAD_c
HEAD_d
HEAD_e
RVEL
RVEL_a
RVEL_b
RVEL_c
RVEL_d
Test_Dig_in
Test_Dig_in_a
Test_Motors
Listato del KaOS
BLT
CPD
BLT
SUBD
BRA
ADDD
STD
RTS
DHEAD_d
#$1000
DHEAD_e
#$1000
DHEAD_e
#$1000
Word_ang_setpnt
BRSET
JSR
BSET
CLR
LDD
TSTA
BEQ
BGT
ADDD
BRA
INC
LDAA
MUL
LSRD
LSRD
LSRD
LSRD
TST
BEQ
ADDD
BLT
CPD
BLT
SUBD
BRA
Char_58,#$08,HEAD_a
Subroutine_34
Char_59,#$02
Char_temp_2
Char_cmd_arg_1
BRSET
JSR
BCLR
LDD
ASRA
RORB
STD
ASRA
RORB
ASRA
RORB
NEGB
ADCA
NEGA
ADDD
CPD
BLE
LDD
CPD
BGE
LDD
STD
RTS
HEAD_d
HEAD_c
#$0168
HEAD_b
Char_temp_2
#$B6
Char_temp_2
HEAD_e
#$0B61
DHEAD_d
#$1000
DHEAD_e
#$1000
DHEAD_e
Char_58,#$08,RVEL_a
Subroutine_34
Char_59,#$02
Char_cmd_arg_1
Char_cmd_arg_1
#$0
Char_cmd_arg_1
Word_36
RVEL_c
Word_36
Word_37
RVEL_d
Word_37
Word_51
LDX
BRCLR
LDAA
LDAB
JSR
LDAA
JSR
TSTA
BEQ
RTS
#Registers
$00,X,#$04,Test_Dig_in_a
DIGITAL_INPUT
#$07
Write_A_as_bin
#$01
Dly_A_10s_brk
LDX
BRCLR
#Registers
$00,X,#$04,Test_Motors_a
Test_Dig_in
114
Appendice C.
Listato del KaOS
JSR
LDAA
STAA
LDD
STD
LDD
STD
LDAA
JSR
TSTA
BNE
LDD
STD
LDAA
JSR
TSTA
BNE
LDD
STD
LDAA
JSR
TSTA
BNE
Set_mottst_flag
#$01
Char_motor_test
#$0000
Word_56
#$0032
Word_57
#$64
Dly_A_10s_brk
Test_Motors_a
#$0078
Word_57
#$14
Dly_A_10s_brk
Test_Motors_a
#$FFC4
Word_57
#$32
Dly_A_10s_brk
Test_Motors_a
LDD
#$0000
* Le due righe seguenti spengono il ciclo della PWM delle due ruote. PROVA.
Test_Motors_a
Test_CPU
Test_CPU_a
Test_CPU_b
STD
STD
Word_PWM_cycl_L
Word_PWM_cycl_R
STD
LDD
STD
LDAA
JSR
TSTA
BNE
LDD
STD
LDAA
JSR
TSTA
BNE
LDD
STD
LDAA
JSR
LDAA
STAA
JMP
Word_57
#$0032
Word_56
#$64
Dly_A_10s_brk
LDX
JSR
JSR
LDAA
STAA
LDY
LDD
ADDD
LDX
INY
BRCLR
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
Test_Motors_a
#$0078
Word_56
#$14
Dly_A_10s_brk
Test_Motors_a
#$FFC4
Word_56
#$32
Dly_A_10s_brk
#$00
Char_motor_test
CLOSE_MOTORS_a
#MSG_cpu_pct
String_to_buf
OPEN_MOTORS
#$0A
Char_temp
#$0000
Word_millisec
#$03E8
#Registers
$00,X,#$04,Test_CPU_c
115
Appendice C.
Listato del KaOS
Test_CPU_c
CPD
BNE
XGDY
LDX
IDIV
XGDX
XGDY
LDAB
JSR
DEC
BGT
JMP
#$0A
Wri_Y_3_digit
Char_temp
Test_CPU_a
CLOSE_MOTORS
MSG_cpu_pct
fcc
fcb
’CPU %:’
0
Subroutine_10
JSR
TSTB
BNE
RTS
JSR
CMPA
BLO
CMPA
BNE
LDAA
JMP
PSHA
JSR
PSHX
PULY
JSR
PULA
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
CMPA
BEQ
RTS
LDAA
JSR
BRA
XGDY
STAB
BRA
JMP
XGDY
ANDA
STAA
ORAB
STAB
LDAA
BRA
XGDY
PSHB
PSHX
PULA
PULB
ABA
PULB
ABA
STAA
TSTB
SCI_poll_A
Subroutine_10_a
Subroutine_10_b
Subroutine_10_c
Subroutine_10_d
Subroutine_10_g
Subroutine_10_e
Subroutine_10_j
Subroutine_10_f
Word_millisec
Test_CPU_b
#$01F4
Subroutine_10_a
SCI_send_A
#$61
Subroutine_10
#$73
Subroutine_10_b
#$3E
SCI_send_A
SCI_get_X
SCI_get_X
#$72
Subroutine_10_c
#$77
Subroutine_10_d
#$63
Subroutine_10_e
#$62
Subroutine_10_f
#$67
Subroutine_10_g
#$70
Subroutine_10_h
#$65
Subroutine_10_i
$00,X
SCI_send_A
Subroutine_10_j
$00,X
Subroutine_10_j
Startup
$00,X
$00,X
$00,X
$00,X
#$3E
SCI_send_A
Char_temp_5
116
Appendice C.
Listato del KaOS
BEQ
Subroutine_10_k JSR
STAA
STAA
ADDA
STAA
INX
DECB
BNE
DEX
Subroutine_10_l LDAA
CMPA
BNE
Subroutine_10_m LDAA
JSR
BRA
Subroutine_10_h XGDX
PSHB
JSR
CLR
PULB
BLT
TBA
BRA
Subroutine_10_i XGDX
CLR
BRA
Subroutine_10_m
SCI_get_A
$00,X
Char_81
Char_temp_5
Char_temp_5
SCI_get_X
JSR
PSHA
JSR
TAB
PULA
XGDX
RTS
SCI_get_A
SCI_get_A
LDAA
ANDA
BEQ
LDAA
RTS
(Registers+SCSR)
#$28
SCI_get_A
(Registers+SCDR)
SCI_poll_A
LDAB
LDAA
ANDA
BEQ
LDAB
LDAA
RTS
#$00
(Registers+SCSR)
#$28
SCI_poll_A_a
#$01
(Registers+SCDR)
SCI_poll_A_a
SCI_send_A
Subroutine_10_k
$00,X
Char_81
Subroutine_10_l
Char_temp_5
SCI_send_A
Subroutine_10_j
Clear_sonars
Char_oper_flags
Subroutine_10_j
Subroutine_10_j
Char_oper_flags
Subroutine_10_j
SCI_get_A
LDAB
(Registers+SCSR)
ANDB
#$80
BEQ
SCI_send_A
STAA
(Registers+SCDR)
RTS
* ----------------------------------------------------------------* LCD Write Register A As Bin
* ----------------------------------------------------------------Write_A_as_bin LDX
#Display_buffer
ABX
LDAB
#$30
BITA
#$80
BEQ
W_A_as_bin_a
LDAB
#$31
W_A_as_bin_a
STAB
$00,X
INX
LDAB
#$30
BITA
#$40
BEQ
W_A_as_bin_b
LDAB
#$31
W_A_as_bin_b
STAB
$00,X
INX
117
Appendice C.
W_A_as_bin_c
W_A_as_bin_d
W_A_as_bin_e
W_A_as_bin_f
W_A_as_bin_g
W_A_as_bin_h
W_A_as_bin_i
Listato del KaOS
LDAB
BITA
BEQ
LDAB
STAB
INX
LDAB
BITA
BEQ
LDAB
STAB
INX
LDAB
BITA
BEQ
LDAB
STAB
INX
LDAB
BITA
BEQ
LDAB
STAB
INX
LDAB
BITA
BEQ
LDAB
STAB
INX
LDAB
BITA
BEQ
LDAB
STAB
INX
LDAB
PSHX
LDX
BRCLR
LDAB
PULX
STAB
RTS
#$30
#$20
W_A_as_bin_c
#$31
$00,X
#$30
#$10
W_A_as_bin_d
#$31
$00,X
#$44
#$08
W_A_as_bin_e
#$20
$00,X
#$43
#$04
W_A_as_bin_f
#$20
$00,X
#$42
#$02
W_A_as_bin_g
#$20
$00,X
#$41
#$01
W_A_as_bin_h
#$20
$00,X
#$30
#Registers
PORTD,X,#B4,W_A_as_bin_i
#$31
$00,X
Return_from_INT RTI
RSEG
JMP
BOOTMODE
Startup
RSEG
LSRD
INX
EFFE
RSEG
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
IVECT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
SCI_Int
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
TOC5_Int
118
Appendice C.
Listato del KaOS
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
FDB
end
TOC4_Int
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Return_from_INT
Startup
Return_from_INT
Return_from_INT
Startup
119
Ringraziamenti
Ringrazio in primo luogo il prof. Giovanni Adorni per la disponibilità e l’attenzione
con cui ha seguito lo sviluppo del lavoro descritto in questa tesi e per l’impegno messo
nel coordinamento di Azzurra Robot Team nell’ambito del progetto RoboCup Italia,
senza cui questo lavoro non sarebbe stato possibile.
Desidero ringraziare anche l’ing. Stefano Cagnoni e l’ing. Monica Mordonini che
hanno messo costantemente a disposizione il proprio tempo e le proprie competenze
nella realizzazione dei robot.
Ringrazio i colleghi studenti che hanno partecipato alla progettazione e realizzazione dei robot per la RoboCup, creando un sereno ambiente di collaborazione: Enzo
Bocelli, Marcello Carletti, Frida Loprieno, Giovanni Remondini, Massimo Romano,
Cristiano Rota.
Voglio infine ringraziare i membri del Dipartimento di Ingegneria dell’Informazione e degli altri dipartimenti che hanno supportato con entusiasmo il nostro progetto, in
particolare il prof. Giovanni Franceschini per la grande e continua disponibilità.
120
Bibliografia
[1] ActivMedia Inc. Pioneer Mobile Robot Operation Manual. ActivMedia Inc.,
ott. 1997.
[2] ActivMedia Inc. e Real World Interface Inc. Saphira Manual - Version 6.1.
ActivMedia Inc., gen. 1998.
[3] G. Adorni, S. Cagnoni e M. Mordonini. Genetic programming of a goalkeeper control strategy for the RoboCup middle size competition. Department of
Computer Engineering, University of Parma.
[4] N. Barkakati. I segreti di Red Hat Linux. Apogeo, 1999. ISBN 88-7303-482-9.
[5] R. A. Brooks. A layered intelligent control system for a mobile robot. IEEE
Journal of Robotics and Automation, vol. RA-2:pp. 14–23, apr. 1986.
[6] F. Cappelli. Robot mobile PIONEER 1: Caratterizzazione dei servomotori e del
carico. Modello dinamico del sistema. Università di Roma “La Sapienza”, dic.
1999.
[7] G. Franceschini. Appunti di Azionamenti Elettrici per l’Automazione. Università
di Parma, A.A. 1999-2000.
[8] J. Iovine. Robots, Androids and Animatrons: 12 incredible projects you can
build!. McGraw-Hill, 1998. ISBN 0-07-032804-8.
[9] J. L. Jones, A. M. Flynn e B. A. Seiger.
Mobile Robots: Inspiration to
Implementation, 2nd ed.. AK Peters Ltd, nov. 1998. ISBN 1-56881-097-0.
121
Bibliografia
122
[10] H. Kitano e M. Asada. RoboCup: e ora in campo gli automi. Le Scienze,
vol. 372:pp. 32–42, ago. 1999.
[11] K. Konolige, K. L. Myers, E. H. Ruspini e A. Saffiotti. The Saphira architecture: A design for autonomy. Journal of Experimental and Theoretical Artificial
Intelligence, 1997.
[12] P. Maes e R. A. Brooks. Learning to coordinate behaviors. In AIII, pp. 796–802.
Boston, MA, ago. 1990.
[13] F. G. Martin. The 6.270 Robot Builder’s Guide, 2nd ed.. Massachusetts Institute
of Technology, dic. 1992.
[14] G. McComb. The Robot Builder’s Bonanza: 99 inexpensive robotics projects.
TAB Books, a division of McGraw-Hill, 1987. ISBN 0-8306-2800-2.
[15] Motorola Inc. HC11: MC68HC11 Technical Data. Rap. tecn., Motorola Inc.,
1995.
[16] Motorola Inc. Motorola M68HC11 Reference Manual Rev.3. Motorola Inc.,
1996.
[17] D. Nardi, G. Clemente e E. Pagello. ART - Azzurra Robot Team. Progetto
RoboCup Italia.
[18] M. Piaggio, A. Sgorbissa e L. Tricerri. ETHNOS Kernel User Manual. Rap.
tecn., Università di Genova, gen. 1999. Dipartimento di Informatica, Sistemistica
e Telematica.
[19] M. Piaggio, A. Sgorbissa e R. Zaccaria. A programming environment for real
time control of distributed multiple robot systems. Dipartimento di Informatica,
Sistemistica e Telematica, Università di Genova.
[20] S. J. Russel e P. Norvig. Artificial Intelligence. A Modern Approach. PrenticeHall, 1995.
Bibliografia
123
[21] P. Stroppa. L’occhio, questo sconosciuto. Nuovo Orione, vol. 66:pp. 26–31,
nov. 1997.
[22] P. Zamperoni.
Metodi di elaborazione digitale di immagini.
Masson, Milano, Italy, 1990.
Casa editrice

Progetto e Realizzazione di una Piattaforma Robotica per

Transcript

Documenti analoghi

Io Robot - DivxMania

Giaccone La robotica - Istituto di Istruzione Superiore "Aldo Moro"

Simulatore cinematico di Robot 3R

Click to Download! - ENCICLOROBOPEDIA

AS3-15 copertina.indd

GUIDA AL NOMAD XR4000

the legacy of Exhibitions - kawaii

Progetto e Realizzazione di una Piattaforma Robotica per

Transcript

Documenti analoghi

Io Robot - DivxMania

Giaccone La robotica - Istituto di Istruzione Superiore "Aldo Moro"

Simulatore cinematico di Robot 3R

Click to Download! - ENCICLO*ROBO*PEDIA

AS3-15 copertina.indd

GUIDA AL NOMAD XR4000

the legacy of Exhibitions - kawaii

Click to Download! - ENCICLOROBOPEDIA