Documente Academic
Documente Profesional
Documente Cultură
PROIECT DE DIPLOM
2004
VIZAT EF CATEDR,
Conf. Dr. Ing. Liviu Miclea
bun:
suficient:
insuficient:
mediu:
mic:
mediu:
mic:
mediu:
mic:
mare:
mare:
mare:
multe:
puine:
nici una:
insuficient:
deloc:
suficient:
insuficient:
suficiente:
insuficiente:
parial:
aproape complet:
bune:
Data:
Semntura conductorului:
SINTEZA
Proiectului de diplom:
Semntura absolventului:
Declaraia autorului,
I. Introducere ..............................................................................1
II. Memoriu tehnic .....................................................................3
2.1. Ce este un robot? ............................................................................. 4
2.1.1.
2.1.2.
2.1.3.
2.1.4.
2.1.5.
2.1.6.
1. Introducere
pagina 1
pagina 2
2. Memoriu tehnic
pagina 3
2.1.2 Definiie
Conform enciclopediei Webster, un robot este un dispozitiv automat, care execut funcii
normal atribuite oamenilor, sau o main cu asemnare de om.
n timp ce aceast definiie ar putea fi satisfctoare pentru unii dintre noi, nu este ns
neaprat i complet. O alt definiie a fost dat de Institutul de Robotic din America, n anul
1979. Conform acestei definiii, un robot este o main reprogramabil, multifuncional
creat pentru a muta diverse materiale, buci, unelte sau alte dispozitive specializate prin
diverse micri programate, pentru realizarea unei varieti mari de sarcini.
O definiie mai scurt i larg acceptat la ora actual este urmtoarea: un robot este un
sistem inteligent care interacioneaz cu mediul fizic nconjurtor, prin intermediul unor
senzori i a unor efectori (figura 2.1).
Pentru a modela lumea nconjurtoare, este
Senzori
necesar ca un robot s adune date prin
intermediul senzorilor de-a lungul unei
Mediul
perioade de timp. Orice tip de senzor este
nconjurtor
bineneles predispus la erori.
Efectori
Figura 2.1. Robotul i interaciunea acestuia cu mediul nconjurtor
Prin prisma acestei definiii, s-ar putea spune c i omul este un robot. Omul
interacioneaz cu lumea nconjurtoare prin intermediul unor senzori i a unor efectori,
reprezentate n lumea biologic de terminaii nervoase respectiv muchi. Bineneles, diferena
cea mai semnificativ ntre robot i om, este c robotul a fost creat de om, i nu invers.
pagina 4
Robot
microprocesor, microcontroller
camere video, senzori de lumin, sonare
Urechi
Gur
Schelet
Echilibru
Muchi
Mncare
Membre
Structur mecanic
Senzori pentru orientare
Actuatori hidraulici/electrici/pneumatici
Surs de curent, baterii
roi, picioare, enile
Tabel 1. Asemnri ntre om i robot.
pagina 5
robotul simte mediul nconjurtor, adica primete informaii despre mediu prin
senzorii lui
2.
3.
Control
Execuie
Planificare
Modelare
Senzori
Percepie
Mediul nconjurtor
Efectori
pagina 6
Mediul nconjurtor
Senzori
Gndete obiectivele
Planific schimbrile din
lumea ambiant
Monitorizeaz schimbrile
Construiete harta
Exploreaz
Ocolete obstacole
Efectori
roboi statici, roboi folosii n diverse fabrici i laboratoare ca de exemplu brae robot
roboi mobili, roboi care se deplaseaz ntr-un anumit mediu fr intervenie uman i
realizeaz anumite obiective
roboi autonomi, roboi care i ndeplinesc sarcinile fr intervenie din partea unui
operator uman i i obin energia necesar funcionrii din mediul nconjurtor
tele-roboi, roboi care sunt ghidai prin dispozitive gen telecomand de un operator
uman
linii automate de producie in fabrici, sunt tot un fel de roboi, chiar dac nu sunt
mobili, deoarece au toate facilitile definiiei noastre
Dintre toate aceste tipuri de mai sus, lucrarea de fa i propune s studieze doar roboii
mobili, de aceea ori de cte ori se va face referire la denumirea de robot acesta va fi de fapt un
robot mobil.
pagina 7
2.2.2.1 Pioneer DX
Robotul Pioneer 3 DX are dimensiunile de
44x38x22cm, avnd scheletul mecanic construit din
aluminiu. Roile au diametrul de 16.5cm (respectnd
astfel regulamentul Ligii de fotbal a roboilor, categoria
mijlocie). Pe lng cele dou roi, mai exist o a treia
roat mic n spatele robotului pentru stabilitate [20].
Specificaiile Pioneer 3 DX: viteza lui maxim poate
atinge 1.6metrii/secund pe teren drept, suport greuti
de pn la 23 Kilograme, i de asemenea poate urca pe
teren n ramp cu o nclinaie de maxim 25%.
Exist o larg gam de accesorii pentru robotul Pioneer3 DX, printre care:
Acces la reea wireless ethernet
Sistem de localizare i navigare bazat pe senzori
laser
Gripper
Senzori pentru coleziune (bumper sensors) pentru
evitarea coliziunilor n cazul n care robotul e prea
aproape de perete i sonarele nu mai detecteaz sub
o anumit distan
Camer video stereo
Senzori bazai pe unde n spectru infrarou
Sistem de localizare bazat pe GPS (Global
Positioning System)
Figura 2.5. Pioneer 3 DX, vedere spate
(imagine (c) 2003 ActivMedia Robotics)
pagina 9
Platforma
de baz
Sonar
Roi
Figura 2.7. Schema de baz a robotului Pioneer 3 AT
2.2.2.2 Pioneer AT
Pioneer 3 AT nu ne intereseaz prea mult, dect poate din punct de vedere al
specificaiilor tehnice. Acest robot este mai costisitor dect fratele lui, robotul Pioneer3 DX,
ns, avnd patru roi poate fi folosit pe orice tip de teren, cu precdere cel accidentat.
Robotul Pioneer 3 AT vine cu dotri standard destul de
atractive printre care 16 sonare, camer cu night-vision (vedere
de noapte), baze radio wireless ethernet, GPS i asa mai departe.
Pentru medii de lucru largi, n afara laboratorului, mai mult ca
sigur c un Pioneer 3 AT s-ar descurca mai bine dect fratele sau
mai mic, Pioneer 3 DX.
Figura 2.8. Pioneer 3 AT
(imagine (c) 2003 ActivMedia Robotics)
pagina 10
2.2.2.3 Amigobot
Mezinul familiei de roboi Pioneer este robotul Amigobot. Acesta reprezint robotul
ideal pentru aplicaii didactice att datorit dimensiunilor i preului su redus, ct i
faptului c este complet funcional pentru o sumedenie de aplicaii.
Amigobot-ul este echipate cu 8 sonare (senzori cu ultrasonice), 6 dispuse n faa
robotului, iar 2 n spatele acestuia. Exist dou versiuni de Amigobot [19]:
Tethered (ro. cu fir)
pagina 11
pagina 12
Autonomia se refer la principiul care afirm c agenii pot opera n mediul lor fr
ajutor din partea omului, chiar dac acest ajutor pare a fi absolut necesar la prima vedere.
Agenii menin intern o list de obiective i acioneaz n consecin pentru a putea
ndeplini acele obiective. Un element cheie al autonomiei lor este chiar proprietatea de a
aciona proactiv, adic capacitatea de a avea iniiativ n loc de a sta i a atepta un
rspuns din partea mediului.
Cooperarea este motivul principal pentru a avea mai muli ageni i nu unul singur.
Pentru a putea coopera, agenii trebuie s aib o anumit capacitate de socializare, adic
abilitatea de a interaciona cu ali ageni i posibil chiar i oameni prin intermediul unui
anumit limbaj.
Pentru a fi cu adevart inteligeni, agenii ar trebui s aib capacitatea de a nva din
mediul nconjurtor, pe msur ce acetia intr n interaciune cu el. Capacitatea de a
nva ar putea de asemenea s ia forma unei performane crescute de-a lungul timpului.
Folosind aceste trei caracteristici, putem deduce c exist patru tipuri de ageni: ageni
colaboratori, ageni colaboratori cu capacitate de nvare, ageni cu capacitate de nvare
dar care nu colaboreaz (eng. interface agents), respectiv ageni cu adevrat inteligeni.
Cele patru tipuri de ageni, mpreun cu cele trei caracteristici explicate mai sus, sunt
prezentate sub form de grafic in figura 2.11.
Ageni inteligeni
Cooperare
Capacitatea
de a nva
Autonomie
Ageni colaboratori
2.
3.
4.
5.
6.
7.
8.
pagina 15
pagina 16
Mediul nconjurtor
Efectori
Agent
Senzori
eluri
Aciuni
Cunotine
despre mediu
Figura 2.12. Schema general a unui sistem centralizat bazat pe un singur agent
Sistemele multiagent reale difer fa de sistemele centralizate pe un singur agent, n
primul rnd prin faptul c agenii existeni ntr-un sistem multiagent, i modeleaz elurile i
comportamentul n funcie de ceilali ageni din sistem. Cu toate c aceast interaciune ar
putea fi privit ca un stimul din partea mediului nconjurtor, interaciunea (comunicarea)
ntre ageni este privit ca fiind separat de mediu.
Din punct de vedere al agentului individual, sistemele multiagent difer fa de sistemele
centralizate datorit faptului c dinamica sistemului poate fi determinat de ali ageni din
sistem. Pe lng incertitudinea care este prezent n mediu, i ceilali ageni pot afecta mediul
n moduri imprevizibile. De aceea, toate sistemele multiagent pot fi privite ca avnd un
comportament dinamic.
pagina 17
ntr-un sistem multiagent, pot exista ageni care au capacitatea de a comunica cu ali
ageni, respectiv ageni care nu pot comunica direct.
Schema general a unui sistem multiagent este prezentat n figura 2.13.
Mediul nconjurtor
Efectori
Senzori
Senzori
Agent
eluri
Aciuni
Cunotine
despre mediu
Efectori
eluri
Aciuni
Cunotine
despre mediu
Agent
pagina 18
pagina 19
despre o anumit situaie, etc. Folosind o astfel de viziune despre lumea agenilor, se poate
nelege mai uor ce acetia pot s fac.
Agenii au capacitatea s negocieze unul cu cellalt. Ei pot cere unor ali ageni s fac
anumite lucruri pentru ei.
n momentul n care se dorete rezolvarea unei probleme cu ajutorul agenilor, este
recomandat modelarea unei situaii asemntoare n lumea real, i apoi gsirea unei soluii
practice. De exemplu dac se dorete construirea unui mecanism prin care un agent s caute
ali ageni care sunt interesai de o anumit discuie, o situaie similar n lumea real ar fi
gsirea unei persoane ntr-o camer plin de oameni necunoscui. Pentru a rezolva aceast
problem, exist mai multe abordri: fie toi oamenii din ncpere vor fi ntrebai dac sunt
interesai de o discuie pe tema respectiv, fie s-ar putea striga foarte tare e cineva interesat
de tema aceasta? astfel nct toate persoanele prezente s aud. O abordare alternativ ar fi
gsirea unei persoane care ar putea s gseasc acele persoane interesate de tema respectiv
pentru tine. Toate aceste abordri constituie situaii reale, i ar putea fi un punct bun de
plecare n construirea unui algoritm pentru ageni. Prin aceste translatri din lumea agenilor
n lumea real i invers, se pot gsi diverse metode de pornire n schiarea unui algoritm.
Habitatul n care agenii funcioneaz, nu este altceva dect un system software care
ruleaz pe arhitectura agent respectiv. El pune la dispoziie agentului acea funcionalitate
necesar pentru executarea codului, pentru mobilitate, comunicare cu ceilali ageni, i altele.
O alt analogie pentru un habitat ar fi aceea c el se comport ca un sistem de operare pentru
agent. Fr un habitat, agenii nu ar putea exista. Pe o arhitectur agent se pot rula unul sau
mai multe habitate simultan.
O alt definiie a habitatului ar fi: o colecie de camere care mpart o baz comun de
cod i un JVM (eng. Java Virtual Machine Main Virtual Java). O camer nu este altceva
dect un loc n care exist un anumit numr de ageni mpreun cu resursele lor. Agenii pot
prsii camera curent i se pot muta n alte camere din habitat. Fiecare camer din habitat
conine un registru n care agenii se pot nscrie n momentul n care intr sau ies dintr-o
camer. Fiecare camer are un identificator unic.
Platforma ADK are dou componente principale: AFC (eng. Agent Foundation Classes) i
ARE (eng. Agent Runtime Environment). Majoritatea dezvoltatorilor vor interaciona doar cu
componenta AFC pentru modelarea agenilor. AFC conine metodele cele mai importante din
ARE i de aceea nu este necesar programarea ARE direct. Doar n cazul n care anumite
metode nu sunt deja n AFC, este necesar nteraciunea direct cu ARE.
Pentru a folosi un agent, un habitat sau ARE trebuie s ruleze deja pe arhitectura agent.
Componenta ARE creeaz toate structurile i resursele necesare pentru ca un agent s poat
exista. Agenii sunt rulai ntr-un mediu alctuit din camere. Agenii se pot muta dintr-o
camer n alta, i pot comunica cu ali ageni prin mesaje exprimate ntr-un limbaj comun
tutoror agenilor din sistem. De asemenea, agenii pot comunica cu alte componente software
ale sistemului care nu fac neaprat parte dintr-un agent. Exemple de astfel de componente
sunt: baze de date, roboi, sisteme de e-mail, etc.
Conceptual, un agent ADK este alctuit din corpul asignat lui i din comportamentul
aferent acestuia.
Corpul include toate componentele necesare executrii codului agent, trimiterii de mesaje
i mutrii agentului dintr-un loc n altul n reea. Corpul agentului este partea cea mai
tehnic i cea mai rigid din punct de vedere al configurabilitii.
pagina 20
Analiz
Heartbeat
Execuie
task
Aciune
Trimite
mesaj
Mutare n
alt camer
Percepia
n prima etap, agentul inspecteaz mediul n care se afl i i construiete un model al
acestuia, n funcie de informaia pe care o primete de la mediu. Informaia primit poate fi
sub form de eveniment sau de stare de la anumii senzori. Evenimentele externe sunt
ntotdeauna mesaje. Un agent poate primi mesaje de la agenii de sistem (eng. system agents)
sau de la ali ageni din habitat. Comportamentul activat de astfel de mesaje este cunoscut sub
denumirea de comportament reactiv.
Agentul primete i informaii de la evenimentele interne, cunoscute sub denumirea de
heartbeat. Acest tip de semnal este trimis la intervale de timp exacte i i d posibilitatea
agentului de a se comporta spontan i nu doar de a reaciona la evenimente externe. Acest tip
de comportament se numete comportament proactiv.
pagina 21
Analiza
n aceast etap, agentul este obligat s proceseze informaia primit i s decid aciunile
viitoare pe baza ei. Aceste decizii trebuie s fie implementate de persoana care se ocup cu
dezvoltarea sistemului agent. Ca exemplu, dac se dorete construcia unui agent de tip
calculator care s primeasc un mesaj coninnd operatorii unui calcul matematic, i s trimit
napoi rezultatul ca un alt mesaj, atunci etapa de analiz poate consta n departajarea
operatorilor matematici i efectuarea calculului matematic efectiv.
Analiza informaiei se face ntotdeauna prin task-uri. Un task este o unitate de analiz
care este folosit pentru construcia unui model comportamental mai complex. Cum un agent
trebuie s manifeste un comportament complex i inteligent, el poate s ruleze mai multe taskuri simultan. Apariia unui anumit eveniment va determina ca toate task-urile interesate de
acel eveniment s primeasc mesajul aferent evenimentului respectiv. Task-urile sunt
procesate cu ajutorul unor modele de task-uri (eng. Task Model). Modelele de task-uri permit
agentului s ruleze mai multe task-uri ntr-o anumit ordine: fie n paralel, fie secvenial.
Aciunea
Aciunea efectiv a unui agent este definit tot cu ajutorul unor task-uri. O varietate de
task-uri sunt deja implementate n mediul ADK. Printre cele mai evidente task-uri necesare,
se gsesc i task-urile pentru trimiterea unui mesaj ctre un alt agent, sau task-urile pentru
mutarea unui agent dintr-o locaie n alta n sistem. Planificarea unui task este i ea n sine tot
un task.
Aceast etap se activeaz n momentul n care agentul interacioneaz fie cu ali ageni
fie cu mediul n care el ruleaz.
Agentul de sistem este tot timpul prezent n habitat pe perioada rulrii programului
Rolul agenilor de sistem este de a oferi anumite servicii speciale agenilor obinuii. Ei au
fost creai datorit faptului c un agent obinuit nu trebuie lsat s interacioneze niciodat
direct cu sistemul din care face parte.
Agenii de sistem prezeni n orice habitat sunt:
Agentul de habitat (eng. habitat agent). Acest agent menine o list cu toate camerele
prezente ntr-un habitat. De asemenea el cunoate toate adresele celorlali ageni din
sistem.
pagina 22
Agentul de camer (eng. room agent). Rolul acestui agent este de a gestiona o camer. n
momentul n care un agent obinuit intr ntr-o camer, acesta este contactat de agentul de
camer care i va actualiza o list cu agenii prezeni n aceea camer. Orice alte aciuni
care necesit un intermediar n camera respectiv vor fi executate tot de agentul de
camer.
Agentul transportor (eng. transporter) este utilizat pentru transferul agenilor dintr-o
camer n alta.
Mai multe informaii despre aceste tipuri de ageni se gsesc n [6].
n momentul n care se dorete construirea unei noi aplicaii bazate pe platforma ADK,
trebuie executate mai multe funcii, printre care:
- crearea de noi habitate
- crearea de noi ageni
- crearea comportamentului unui agent nou
- definirea conversaiilor ntre ageni
pagina 23
Pe cale de a reui
Pe cale de a eua
pagina 24
Task-ul eueaz
Succes confirmat
Task reuit
Pe cale de a eua
Task-ul este
replanificat
Pe cale de a reui
Euare confirmat
Task euat
Orice task poate fi privit ca o metod asincron. Ca orice metod, un task promite s
fac ceva. Starea unui task poate fi citit pentru a verifica dac un task se mai execut sau s-a
terminat. Difereniind ntre succesul i eecul unui anumit task, se poate vorbi despre o
schem de programare robust. Un task care s-a terminat cu succes poate fi privit ca o metod
care returneaz toate condiiile ndeplinite, n timp ce un task care a euat poate fi privit ca o
metod care arunc o excepie.
putnd fi simple informaii despre anumite stri, sau liste complete de elemente rezultate n
urma anumitor aciuni.
Protocolul de comunicaie
Ca n cazul oricrei forme de comunicaie, att emitorul ct i receptorul trebuie s
utilizeze acelai set de reguli pentru ca fiecare s neleag ce spune cellalt. Dac nu este
respectat acelai set de reguli, un agent nu este capabil s comunice cu ali ageni din sistem.
De asemenea, aceti ageni nu o s-i poat rspunde acestuia deoarece nu vorbesc un limbaj
comun. Aadar, primul lucru care trebuie fcut este s se stabileasc un set de reguli pe baza
crora se poate comunica. Acest set de reguli se numete protocol. Un protoocol de
comunicaie definete ceea ce poate fi trimis, cum poate fi trimis, i respectiv, ceea ce se
ateapt ca rspuns.
Limbajul
Definirea unui protocol nu este ns suficient pentru o comunicare reuit. De exemplu,
protocolul definete dac o ntrebare poat fi trimis i stabilete tipul de rspuns care trebuie
trimis pentru acea ntrebare napoi. ns, protocolul nu definete ce anume conine ntrebarea
respectiv i cum trebuie s fie interpretat rspunsul.
nainte ca o comunicaie eficient s poat avea loc ntre ageni, ei trebuie s-i stabileasc
un context comun. Dac agenii se pot nelege asupra unei structuri i asupra nelesului unei
colecii de subiecte, atunci ei pot schimba ntre ei mesaje n acest limbaj. Un agent poate
folosi limbaje multiple pentru a comunica n diferite contexte. De exemplu, un agent ar putea
folosi un limbaj comercial pentru a face afaceri cu un alt agent, sau un limbaj transport cu
un alt agent.
Protocolul FIPA
Exist un set definit de protocoale de comunicaie interagent care pot fi folosite pentru
comunicare. Unul dintre acestea este protocolul FIPA, bazat pe mesaje.
Agenii construii cu ADK urmeaz acest protocol FIPA. Dialectul implementat de
Tryllian se bazeaz pe specificaiile FIPA din ianuarie 1999, dar la care s-au adus unele
modificri ulterioare.
Mesajele sunt trimise nainte i napoi ntre un emitor i un receptor, i fiecare mesaj are
un identificator (eng. performative). Acest identificator de tip al unui mesaj FIPA d
semnificaia mesajului, semantica lui i implic ce poate conine mesajul i cum trebuie
entitile receptoare s reacioneze la primirea lui. Toi aceti identificatori sunt definii de
protocolul FIPA, care mai definete pe lng ei i ce fel de mesaje poate receptorul s
rspund la recepionarea unui mesaj primit cu un anumit identificator.
n afar de identificatorul menionat, mesajele au o structur intern care conine date. De
exemplu, aceast structur poate conine un identificator al emitorului mesajului (expeditor),
cui ii este adresat mesajul (destinatar), precum i motivul pentru care respectivul mesaj a fost
trimis. Aceast structur intern este de asemenea stabilit de ctre protocolul FIPA, sub
forma unor parametrii de mesaj. O parte din aceti parametri sunt automat iniializai n
pagina 26
momentul n care un mesaj este trimis, dar exist i parametrii care pot fi iniializai de ctre
agent. Parametrii setai de agent sunt acei parametrii utilizai la implementarea limbajeloragent.
Protocolul FIPA este destul de complex. Subsetul ADK al protocolului FIPA nu folosete
toi identificatorii FIPA. n tabelul 2 sunt prezentai acei identificatori de mesaj implementai
i folosii de ctre ADK.
Identificator
Request
Query-ref
Subscribe
Semnificaie
Solicit receptorului s efectueze o anumit aciune.
Solicit receptorului s rspund cu o anumit informaie.
Solicit notificarea emitorului de ctre receptor de fiecare
dat cnd starea unei anumite proprieti se schimb.
Cancel
Comunic receptorului s nceteze execuia aciunii anterior
solicitate.
Inform
Informeaz receptorul despre o anumit stare de lucruri (sau
un rezultat ca urmare a unei cereri sau autonom).
Agree
Comunic receptorului c solicitarea i-a fost aprobat.
Refuse
Comunic receptorului c solicitarea i-a fost respins
(refuzat).
Failure
Informeaz receptorul c a aprut o problem n ncercarea
de a trata mesajul primit.
Not-understood
Informeaz receptorul c mesajul primit nu a fost neles.
Tabel 2. Tipuri de identificatori FIPA folosii n ADK
Ordinea n care se trimit aceste mesaje nu este arbitrar. De exemplu cnd un o cerere de
tip request este primit, rspunsurile posibile sunt doar mesajele de genul not-understood,
refuse sau agree. Dac o cerere de tip agree este trimis, mesajele care pot urma sunt de
tipul failure sau inform.
Partea de coninut a mesajului ADK const din urmtoarele cmpuri:
Performatives (identificator de mesaj)
Subject (subiectul mesajului)
Arguments (argumente) cmp opional.
Spre exemplu cnd un agent primete un mesaj cu timpul curent, identificatorul mesajului
ar putea fi de tipul inform, subiectul ar putea fi timp, iar argumentul ora, minutul,
secunda curent.
Iniiator
Participant
Query-ref
Refuse
[refuzat]
Failure
[euat]
Inform
Figura 2.16. Modul de interaciune query-ref
pagina 29
Iniiator
Participant
Request
Refuse
[refuzat]
Failure
[euat]
Inform
Agree
[confirmat]
Failure
[euat]
[confirmat]
Inform
Iniiator
Participant
Subscribe
Refuse
[refuzat]
Failure
[euat]
Agree
[confirmat]
Inform
0..n
[confirmat]
Cancel
[anulat]
Agree
[anulat]
pagina 31
2.6.1. Saphira/ARIA
Saphira este o arhitectur dezvoltat pentru controlul roboilor mobili [31]. Iniial
proiectul a fost dezvoltat pentru robotul Flakey la SRI International, iar apoi timp de 10 ani
proiectul a fost mbuntit n continuu i a ajuns o arhitectur care suport o varietate de
funcii destinate roboilor mobili. Saphira i roboii Pioneer s-au clasat pe locul 1 n
competiia AAAI intitulat Call a Meeting din august 1996.
Saphira a ajuns acum la versiunea 8 i a fost mprit n dou pri: toate rutinele low-level
au fost rescrise i reorganizate ntr-un subsistem separat software numit ARIA, iar restul
rutinelor high-level au rmas n Saphira. Sistemul Saphira/ARIA poate fi privit ca o
arhitectur dual.
ARIA conine arhitectura sistem, care de fapt este un set integrat de rutine pentru
comunicarea cu robotul, respectiv pentru controlarea robotului de pe un calculator personal.
Aceast arhitectur sistem a fost construit pentru a facilita scrierea aplicaiilor complexe
pentru roboii mobili. Arhitectura sistem este o arhitectura deschis (eng. open architecture).
Dezvoltatorii care vor s i scrie propriile rutine pentru controlul low level al roboilor nu
trebuie s-i bat capul cu controlul hardware sau comunicarea la nivel de cod main, ci pot
s foloseasc aceast arhitectur sistem.
Deasupra arhitecturii sistem se afl Saphira, o arhitectur de control a robotului,
arhitectur care a fost proiectat pentru a adresa probleme legate de navigare, localizare sau
recunoatere de obiecte. Saphira i ARIA i mpart sarcinile, ARIA ocupndu-se de sarcinile
low-level precum interpretarea senzorilor sau alte comenzi, iar Saphira de cele high-level.
Saphira i ARIA sunt scrise n limbajul C++.
Arhitectura platformei Saphira/ARIA este prezentat n figura 2.19.
pagina 32
Rutine
utilizator
asincrone
Datorit faptului c sunt invocate la fiecare 100ms, micro-task-urile trebuie s-i mpart
sarcinile n intervale de timp mici care pot opera n aceste limite.
Pentru sarcini mai complicate, timpul necesar unui micro-task nu este suficient. Pentru
aceasta este nevoie de un alt tip de rutine utilizator. Aceste rutine sunt de tip asincron i
sunt de fapt fire de execuie diferite care mpart un spaiu de adresare comun cu rutinele
librriilor Saphira, ele fiind independente de ciclul sincron de 100ms. Dezvoltatorul poate
porni oricte astfel de fire execuie, limitrile fiind impuse doar de sistemul de operare. De
menionat c librriile Saphira au o prioritate mai mare dect aceste rutine utilizator
asincrone, astfel c orice operaie consumatoare de timp poate co-exista cu arhitectura
sistem Saphira/ARIA, fr s afecteze controlul robotului realizat n timp real.
Datorit faptului c toate rutinele Saphira/ARIA sunt stocate n mai multe librrii, un
program utilizator ar putea s includ doar acele rutine pe care le folosete. Astfel, un
client al platformei Saphira poate fi un program compact, care va folosi librriile Saphira
pentru acele sarcini necesare accesrii robotului.
ARIA comunic cu robotul prin pachete, trimind comenzi serverului robot i primind
informaii napoi de la robot. Clienii uzuali pot transfera ntre una si 4 comenzi pe secund
robotului, cu toate c serverul robot poate face fa aproximativ la 100 de comenzi pe
secund. Aceast limit depinde de rata comunicrii seriale precum i de mrimea pachetului
n octei. Toi clienii primesc automat 10 sau mai multe pachete cu informaii napoi de la
robot. Aceste pachete conin date de la senzori sau informaii privitoare la motoarele robotului
printre altele.
Totui, canalul de date nu este 100% sigur din punct de vedere al integritii datelor.
Astfel, fiecare pachet conine cte un cmp de control (eng. checksum) pentru a determina
daca respectivul pachet a fost sau nu corupt n timpul transferului. Dac a fost corupt,
pachetul va fi ignorat, sistemul fiind responsabil pentru transmiterea unui pachet nou. Dac un
numr mare de pachete va fi retrimis din cauza coruperii acestora, performana sistemului
ARIA va fi afectat.
Legtur TCP/IP ctre ali ageni
Rutine de afiare
Rutine de
localizare
Markov
Rutine de
interpretare ale
senzorilor
Interfaa de
conectare la ali
roboi
Harta global
Spaiul local
perceptual
Planificator drum n
timp real bazat pe
gradient
Aciuni Colbert
Controlul
comportamentului
Controlul micrii
Analiz stare
Figura 2.20. Arhitectura sistemului de control a platformei Saphira/ARIA
pagina 34
Arhitectura de control a sistemului Saphira/ARIA este alctuit dintr-un set de micro-taskuri i sarcini asincrone care implementeaz toate funciile necesare pentru navigarea
robotului. Un client tipic va folosi un subset al acestei arhitecturi.
Roboii mobili lucreaz ntr-un spaiu geometric, reprezentarea acestui spaiu fiind critic
pentru performaa lor. Exist dou tipuri de reprezentri geometrice n Saphira, i anume:
Spaiul perceptual local (eng. LPS Local Perceptual Space) este un sistem de
coordonate cu raza de aciune egal cu civa metri i centrul pe robot
Spaiul hart global (eng. GMS Global Map Space) este un sistem de
coordonate cu o perspectiv mai larg, folosit pentru a reprezenta obiecte care fac
parte din mediul de lucru al robotului n coodonate absolute (globale).
Sistemul LPS este folositor pentru urmrirea micrilor robotului n spaii mici de lucru,
pentru interpretarea datelor de la senzori sau pentru a nregistra obiectele care trebuie ocolite
n drumul robotului. Acest sistem ofer robotului informaii locale despre mediul su
nconjurtor. Fereastra principal a mediului Saphira afieaz sistemul LPS al robotului.
(figura 2.21).
Structurile din GMS se numesc artifacte i reprezint obiecte din mediu sau structuri
interne. O colecie de astfel de obiecte, cum ar fi coridoare, ui, camere pot fi grupate toate
mpreun pentru a forma o hart ce poate fi folosit ulterior.
Cercurile mici reprezint valori ale sonarelor: cele verzi reprezint valorile curente, iar
cele albastre i negre sunt valorile precedente. Dreptunghiul mic din faa robotului
reprezint unghiul. Dreptunghiurile mai mari de culoare verde indic zone de senzitivitate
pentru comportamentul care controleaz robotul. Liniile reprezint perei i sunt ncrcate
dintr-un fiier de tip hart. Informaiile despre poziia, viteza i starea intern a robotului
sunt prezentate n partea stng a ferestrei.
Mediul Saphira/ARIA include i un simulator care poate fi extrem de util n cazul n
care nu se dispune de un robot fizic i se vrea testarea unui anumit comportament al
robotului. Ca i robotul, simulatorul Pioneer are erori realiste la citirile sonarelor, astfel
nct dac un program client funcioneaz pe simulator atunci el va funciona mai mult ca
sigur i pe robot.
Simulatorul permite de asemenea construirea unei lumi nconjurtoare n care robotul
poate naviga.
Dezavantajul principal al simulatorului este acela c mediul construit este o abstracie
a lumii reale, cu simple linii intr-un spaiu 2D n locul unor obiecte geometrice complexe
pe care robotul le ntlnete n lumea real.
Figura 2.22 prezint o fereastr de test a simulatorului Pioneer.
pagina 36
2.6.2. Player/Stage
Proiectul Player/Stage este alternativa freeware la platforma Saphira/ARIA. Proiectul a
nceput n anul 1998 la University of Southern California din Statele Unitele ale Americii. El
este rezultatul muncii lui Brian Gerkey, Richard Vaughan, Andrew Howard precum i alii.
Cu toate c proiectul a inceput la USC, el a fost mutat n anul 2001 pe Sourceforge.net, i
momentan dezvoltarea lui se face sub licen GPL (GNU Public License).
Ca i platforma Saphira/ARIA, proiectul Player/Stage este format din dou componente
principale:
Componenta server, numit Player, care ofer o interfa flexibil pentru o varietate de
senzori i actuatori (deci roboi)
Componenta simulator, numit Stage, care este un simulator 2D scalabil pentru roboi
Sistem de operare
Linux 2.2, 2.4
SunOS 5.6, 5.8
Linux 2.4
Linux 2.4.19
Player
D
D
D
D
Suport hardware
D
N
N
D
Stage
D
D
D
N
Linux 2.4.18-rmk3
Linux 2.2
FreeBSD 4.7
OS X.1, X.2
D
D
D
N
N
N
N
D
D
2.6.2.1. Player
Dup cum am afirmat deja, Player este un server pentru dispozitive cum ar fi senzorii sau
actuatorii prezeni pe diferite tipuri de roboi mobili. Adevrata putere a acestui server const
n faptul c sunt suportate o multitudine de platforme hardware i software, spre deosebire de
Saphira care poate lucra doar cu roboii firmei ActivMedia Robotics. Astfel, teoretic este
posibil ca o aplicaie scris pentru un anumit gen de roboi s funcioneze fr modificri
majore pe alt gen de roboi, fcui de alt firm, dar cu caracteristici tehnice asemntoare.
Player folosete un model de server client bazat pe protocolul de reea TCP. Datorit
acestui fapt, aplicaiile client pot fi scrise practic n orice limbaj de programare, ele putnd fi
executate de pe orice calculator conectat la o reea de calculatoare care conine server-ul
Player activ conectat la robot. Dezvoltatorii proiectului Player au avut grij s fac o distincie
clar ntre interfaa programator i structura de control.
pagina 37
Roboi
Firma
productoare
ActivMedia
Nume
dispozitiv
Roboi
bazai pe
PSOS/P2OS
Tipul de
conexiune
RS232
Driverul aferent
p2os_aio/aio, p2os_bumper/bumper,
p2os_compass/position, p2os_dio/dio,
p2os_gripper/gripper, p2os_position/position,
p2os_power/power, p2os_sonar/sonar,
p2os_sound/sound
Trogdor
RS232
trogdor/position
(O-Bot)
Robotics
reb_ir/ir, reb_position/position,
K-Team
extension
RS232
reb_power/power
board(REB)
B21r,
rwi_bumper/bumper, rwi_position/position,
RWI
Mobil
ATRV jr
rwi_power/power, rwi_sonar/sonar
Roboi
rflex_aio/aio, rflex_dio/dio,
RWI
bazai pe
RS232
rflex_position/position, rflex_power/power,
RFLEX
rflex_sonar/sonar, rflex_bumper/bumper
Robotic
Canal dual
SegWay
Mobility
rmpposition/position, rmppower/power
CAN
Platform
Tabel 3. Lista roboilor care funcioneaz corect cu Player versiunea 1.4rc2
Botrics
Diverse
componente
hardware
Firma
productoare
Nume dispozitiv
Tipul de
conexiune
Driverul aferent
SICK
SICK
Sony
pagina 38
Diverse componente
Software
Firma productoare
Jim Bruce
ActivMedia (Paul Rybski)
Centrul pentru tehnologie
n domeniul sintezei
vocale, Universitatea din
Edinburgh
Nume dispozitiv
Tipul de
conexiune
Driverul aferent
Direct nglobat
n Player
Socket TCP
acts/blobfinder
Festival
Socket TCP
festival/speech
cmvision/blobfinder
Direct nglobat
service_adv
n Player
Tabel 5. Lista dispozitivelor software care funcioneaz corect cu Player v1.4rc2
Reed Hedges
libservice discovery
Numele interfeei
Player
Null
Power
Gripper
Position
Sonar
Laser
Blobfinder
Ptz
Audio
Fiducial
Comms
Speech
GPS
0x000E
0x000F
Bumper
Truth
0x0010
0x0011
0x0012
0x0014
0x0015
0x0016
0x0017
0x0018
0x0019
0x001A
IDARTurret
IDAR
Descartes
DIO
AIO
IR
WiFi
Waveform
Localize
Mcom
Descriere
Serverul Player
Interfa nul
Sistemul de putere al robotului (motoarele)
Gripper pentru robot
Baza robotului, folosit pentru localizare
Sistem de senzori cu ultrasunete
Sistem de senzori cu laser
Sistem de detecie culoare
Camer video cu posibilitate de rotire i zoom
Detectare i generare de sunete
Detector de obiecte marcate aprioric
Sistem de comunicare general
Sistem de recunoatere vocal
Sistem de poziionare global (Global
Positioning System)
Sistem de senzori paraoc
Sistem de localizare (folosit doar n
simulatorul Stage)
Colecie de senzori IDAR
Senzor IDAR (Infrared Data and Ranging)
Baz robot Descartes
Intrri/Ieiri n format digital
Intrri/Ieiri in format analog
Sistem de senzori n spectrul infrarou
Plac de reea Wireless Ethernet
Date sub format digital RAW
Sistem de localizare a robotului
Comunicare intre roboti
pagina 39
0x001B
Sound
Pornete sunete nregistrate pentru ascultare
0x001C
AudioDSP
Generare i detectare de sunet
0x001D
AudioMixer
Controlul nivelelor de sunet
0x001E
Position3D
Baz robot care se deplaseaz n 3 dimensiuni
0x001F
Simulation
Interfaa pentru controlul simulatorului
0x0020
Service_adv
Sistem de detectare servicii
0x0021
Blinkenlight
Sistem de lumini care clipesc
0x0022
Camera
Imagini provenite de la o camer video
Tabel 6. Codurile interfeelor suportate de Player
Orice operaiune de conectare la serverul Player se face dup un scenariu clasic, descris n
figura 2.23. n primul rnd clientul trebuie s stabileasc o conexiune de conectare cu serverul
Player, trimind o cerere n acest sens. Dup ce aceast conexiune s-a stabilit, clientul
informeaz i cere serverului s-i garanteze accesul la un anumit dispozitiv pe care acesta
dorete s-l foloseasc. Dup aceea, serverul va furniza n continuu (n bucl) date ctre
client, iar clientul va analiza aceste date i n funcie de rezultat va trimite serverului anumite
comenzi ctre efectori.
Client
Server
Stabilete conexiunea
Activeaz dispozitivul
dorit
Citete date de la
senzori
bucl
Trimite comenzi
efectorilor
Figura 2.23. Exemplu de interaciune client-server folosind Player
Arhitectura de baz a serverului Player a fost n aa fel construit nct s permit cu
mult uurin att modificarea codului pentru dispozitivele deja existente ct i adugarea de
cod (drivere) pentru noi dispozitive.
Serverul Player este implementat n limbajul C++ i folosete funciile standard POSIX
phtread pentru a utiliza mai multe fire de execuie. Structura arhitectural general a
sistemului este prezentat n figura 2.24. Poriunea din centru descrie chiar sistemul Player, n
partea stng se gsesc dispozitivele fizice, iar n partea dreapt clienii care doresc s le
utilizeze. Fiecare client folosete un socket de tip TCP pentru a se conecta la serverul Player.
Dac clientul se afl pe acelai calculator ca i serverul Player, atunci conexiunea va fi de tip
loopback (ro. bucl nchis), n caz contrar realizndu-se o conexiune TCP prin reea ntre
cele dou componente. La cellalt capt, Player se conecteaz la dispozitivele respective prin
diverse standarde, cel mai popular fiind standardul serial RS232. nuntrul Player, fiecare fir
de execuie comunic cu celelalte fire printr-un spaiu de adresare comun.
pagina 40
Dispozitiv fizic
D0
comenzi
date
Dispozitiv
D0
Buffer
comenzi D0
Client
C0
date
Buffer
date D0
comenzi
Servici pentru
clieni multifir
Buffer
comenzi DN
Dispozitiv fizic
DN
comenzi
date
Dispozitiv
DN
Buffer
date DN
comenzi
date
Client
CN
2.6.2.2. Stage
A dou component principal a proiectului Player/Stage este simulatorul 2D numit Stage.
Acest simulator folosete roboi virtuali care interacioneaz cu device-uri simulate. Stage
suport mai multe modele de senzori, incluznd sonare, senzori laser, camere video i altele.
Tot mediul construit n Stage poate fi accesat prin intermediul unui client care va comunica cu
un server Player.
Lumea construit pentru simulatorul Stage se ncarc dintr-un fiier cu extensia .world.
Toate obiectele i dispozitivele care vor fi ncrcate n mediul virtual trebuie definite n
fiierul care descrie lumea. Exist dou tipuri de dispozitive care pot fi definite: pasive i
active. Dispozitivele pasive sunt de fapt obiecte, toate fiind derivate dintr-un model de baz
numit entitate (eng. entity).
Lista obiectelor care se pot defini este:
Bitmap - o colecie de obiecte fixe care se ncarc dintr-un fiier de tip PNM (eng.
Portable Anymap Format). Din aceste fiiere se pot ncrca perei, planul unei camere,
etc.
pagina 41
Toate obiectele de mai sus sunt derivate din tipul de baz entity. n timp ce tipul entity nu
poate fi instaniat direct, toate celelalte entiti motenesc proprietile tipului de baz.
Acestea sunt:
Name de tip string, descrie un nume pentru entitatea respectiv, folosit de GUI (eng.
Graphical User Interface, ro. Interfaa Grafic Utilizator)
Shape forma entitii respective, valorile admisibile fiind rect pentru dreptunghi
respectiv circle pentru cerc
Mass de tip float, stabilete masa obiectului respectiv (folosit la obiectele de tip
puck)
Color de tip string, stabilete culoarea obiectului respectiv, pentru o list complet
de culori trebuie consultat fiierul rgb.txt din distribuia de X-Windows)
Size [0 0]
Pose [0 0 0]
Color black
Obstacle_return invisible
Sonar_return invisible
Vision_return invisible
Laser_return invisible
Idar_return IDARTransparent
Id -1
Mass 1000.0
Interval 0.1
Fiecare obiect din cele definite mai sus motentete aceste proprieti, ns schimb
valorile implicite ale acestora.
Box
Este cel mai simplu tip de obiect care poate fi descris. Tipul obstacolului poate fi
dreptunghiular sau sub form de cerc. Valorile implicite ale proprietilor entitate pentru acest
tip de obiect sunt:
Shape rect
Size [1.0 1.0]
Color yellow
Obstacle_return visible
Sonar_return visible
Vision_return visible
Laser_return visible
Idar_return IDARReflect
Bitmap
Acest tip de obiect este folosit pentru a ncrca o lume virtual dintr-un fiier de tip PNM.
Valorile implicite ale proprietilor entitate pentru acest tip de obiect sunt:
Color black
Obstacle_return visible
Sonar_return visible
Vision_return visible
Laser_return visible
Idar_return IDARReflect
File
Scale 0
Se menioneaz c pe lng valorile motenite de la tipul entity, acest tip de obiect mai adaug
nc dou proprieti, i anume file, care va descrie numele fiierului PNM care se va ncrca
de pe disc, respectiv scale, care specific scara imaginii n metri/pixeli (sau uniti/pixeli n
cazul n care se vor specifica alte uniti de msur diferite de metru).
pagina 43
Puck
Obiectul de tip puck descrie o entitate care poate fi mutat att de robot ct i de utilizator.
Pe lng proprietile de baz, mai adaug i o proprietate numit friction, care descrie
coeficientul de frecare al obiectului cu mediul respectiv.Valorile implicite ale proprietilor
entitate pentru acest tip de obiect sunt:
Shape circle
Size [0.08 0.08]
Color green
Obstacle_return visible
Sonar_return visible
Vision_return visible
Friction 0.05
Mass 0.2
Interval 0.01
Tipurile de dispozitive active care funcioneaz corect cu simulatorul Stage versiunea
1.3.3 sunt:
Broadcast permite clienilor s comunice unul cu cellalt prin platforma
Player/Stage, mesajele trimise de un client fiind primite de toi ceilali
Idar dispozitiv de tip senzori cu infrarou (eng. Infrared Data and Ranging)
Idarturret list de senzori de tip IDAR accesai mpreun pentru o eficien mai
mare
Toate aceste tipuri folosesc un alt tip de baz numit device, care are dou tipuri de proprieti
i anume: port, care descrie numrul portului unde dispozitivul respectiv este ataat, respectiv
pagina 44
index care descrie numrul dispozitivului respectiv. Proprietatea index se folosete atunci
cnd se folosesc mai multe instane ale aceluiai tip de dispozitiv.
Se prezint n continuare un exemplu de mediu pentru robot creat dintr-un fisier de tip
world. De notat c toate liniile care ncep cu caracterul # sunt considerate comentarii i
ignorate de ctre componenta programului Stage care se ocup cu citirea obiectelor din fiier.
# fiier simple.world
resolution 0.02
gui ( size [502.0 506.0]
origin [5.018 4.950 0]
scale 0.021
)
bitmap ( file cave.pnm.gz
resolution 0.02
)
# ncarc anumite tipuri de dispozitive din alt fiier cu numele pioneer.inc
include pioneer.inc
position ( port 6665
pose [1.0 1.0 20]
laser ()
)
Dup ce acest fiier va fi citit de ctre Stage, se va ncrca imaginea din fiierul
cave.pnm.gz i se va aduga un dispozitiv robot echipat cu senzori laser i care se va conecta
la un server Player pe portul 6665.
Pentru a accesa robotul respectiv, trebuie scris un client care s se conecteze pe portul
6665 folosind protocolul TCP i s comunice cu serverul Player. Robotul se va deplasa n
simulatorul Stage exact ca i cum ar fi n lumea real. Astfel se pot testa anumii algoritmi
fr a folosi un robot fizic.
Exemplul dat folosete mai multe tipuri de roboi virtuali respectiv de obiecte n mediu.
Astfel, cele trei dispozitive de culoare roie din partea dreapt a ecranului sunt trei roboi
AmigoBot fabricai de firma ActivMedia Robotics. Dispozitivele de culoare albastra (jos n
ecran), roie (stnga jos) respectiv verde (stnga mijloc) sunt roboi de tip Pioneer fabricai tot
de firma ActivMedia Robotics. Celelalte obiecte colorate sunt de tip puck. Pereii sunt descrii
prin liniile de culoare neagr.
De notat este faptul c Stage este construit pentru a suporta populaii de dimensiuni mari
de roboi mobili, astfel fiind posibil construirea de lumi relativ complexe.
Figura 2.25. prezint o imagine captur a ecranului utilizator Stage.
pagina 45
Figura 2.26. Mediu construit pentru simulatorul Stage ca exemplu pentru modelul de entitate
puck
pagina 46
Se observ analogia ntre tipul de obiect puck i o bil de biliard. Proprietatea friction
va seta coeficientul de frecare al obiectului n mediul virtual construit.
2.6.2.3. Gazebo
Pe lng simulatorul 2D Stage, mai exist nc un simulat anexat proiectului Player/Stage,
i anume simulatorul Gazebo, ajuns la versiunea stabil 0.3.0.
Gazebo este un simulator pentru roboi, i este folosit ndeosebi pentru medii deschise, de
mari dimensiuni. Ca i Stage, Gazebo este capabil s simuleze populaii de roboi, senzori i
obiecte, dar face acest lucru ntr-o lume virtual n 3D. Diferena esenial dintre cele dou
simulatoare (pe lng faptul evident c Stage este 2D, iar Gazebo 3D) este c, n timp ce
Stage este construit pentru a simula populaii de mari dimensiuni de roboi cu o fidelitate
moderat, Gazebo este construit pentru a simula comportamentul unor grupuri mai mici de
roboi (mai puin dect 10) ns cu o fidelitate mult mai mare. Aadar, cele dou simulatoare
sunt complementare, utilizatorii putnd schimba ntre ele n funcie de necesitile lor.
Exemple de medii posibile construite n simulatorul Gazebo sunt ilustrate n figurile 2.27,
2.28, 2.29 i 2.30.
Fiecrui model i este asociat un set de atribute ca de exemplu poziia modelului <pos> i
orientarea <rot>. Definiiile modelelor pot de asemenea s fie mbricate. Exemplu:
<model:Pioneer2AT>
<id>robot1</id>
<pos>0 0 0.40</pos>
<rot>0 0 45</rot>
<model:SickLMS200>
<id>laser1</id>
<pos>0.15 0 0.20</pos>
<rot>0 0 0</rot>
</model:SickLMS200>
</model:Pioneer2AT>
n exemplul menionat, robotul mpreun cu senzorul laser formeaz un corp compact.
Gazebo suport o varietate de modele de dispozitive hardware. Acestea sunt:
ClodBuster: robot cu 4 roi
3. Memoriu justificativ
pagina 51
Platforma
ADK
JavaClient
Alte rutine
utilizator, algoritmi
3.2. Robotux
Datorit faptului c platforma robot Player/Stage funcioneaz doar sub sisteme de operare
bazate pe UNIX (ex. Linux), prezentarea proiectului ntr-o form finit s-a dovedit a fi un alt
impediment. Sistemul fiind distribuit, era necesar rularea acestuia pe un anumit numr de
calculatoare, devenind astfel necesar instalarea unui sistem de operare Linux pe fiecare din
aceste calculatoare n parte.
Astfel a aprut ideea dezvoltrii unei platforme bazat pe sistemul de operare Linux care
s poat rula att aplicaia conceput i dezvoltat n acest proiect, precum i alte proiecte
ulterioare, fr a fi necesar instalarea unui sistem de operare doar pentru acest lucru. Pentru a
realiza dezideratul propus, noua platform trebuia s elimine necesitatea unei instalri
apriorice pe un calculator personal, deci s poat rula direct de pe un suport de stocare extern.
S-au studiat mai multe alternative, cea mai convenabil fiind pn la urm o soluie bazat pe
medii de stocare optice, respectiv Compact Discuri.
Pentru a rula o platform direct de pe CD fr a o instala pe discul calculatorului, s-a
apelat la o distribuie de Linux deja existent, i anume Debian Linux. Aceast distribuie
permite individualizarea aplicaiilor i a pachetelor ce urmeaz a fi folosite, i crearea unei
distribuii proprii bazate pe aceste pachete.
innd cont c platforma care urma a fi dezvoltat era destinat lucrului cu roboi mobili,
iar mascota sistemului de operare Linux pe care platforma este construit (kernelul sistemului
de operare), se numete Tux (*), numele platformei a venit de la sine: Robotux.
(*) Mascota sistemului de operare Linux (impropriu spus sistem de operare, Linux fiind
doar numele kernelului unei distribuii) este un pinguin care poart numele de Tux.
Pentru a facilita construcia platformei s-au apelat la alte distribuii de Linux bazate pe
Debian Linux, deja existente pe reeaua Internet, i anume: Knoppix i Morphix. Aceste
distribuii, ca i Debian Linux, permit instalarea lor pe un Compact Disc i apoi rularea
acestui sistem de operare direct de pe CD. Toate fiierele necesare care trebuiesc a fi
modificate n timpul rulrii platformei se copiaz ntr-un RAM drive n memoria
calculatorului.
Robotux a ajuns la versiunea stabil 0.1, el necesitnd dezvoltri ulterioare n funcie de
preferinele viitorilor utilizatori. n aceast distribuie, au fost incluse att platforma
Player/Stage ct i o suit de aplicaii i utilitare necesare dezvoltrii de software pentru roboi
pagina 53
mobili. Astfel, a fost inclus kitul Java SDK 1.4.1 de la Sun Microsystems, editorul Bluefish,
programul de grafic bitmap/vectorial Gimp versiunea 2.0 pentru construirea hrilor ce vor
fi utilizate n simulatorul Stage sau n simulatorul Gazebo, i altele.
n figurile 3.2, 3.3, 3.4 se prezint imagini din procesul de startare a sistemului de operare
Robotux v0.1.
Figura 3.5. Imagine cu desktopul platformei Robotux v0.1 dup ce procesul de ncrcare
s-a terminat
Platforma Robotux fiind construit, timpul alocat instalrii i configurrii sistemului de
operare int pe care urmeaz s se starteze platforma final (platforma agent + platforma
robot) a fost redus substanial. De la cele cteva ore (poate chiar zile) necesare instalrii i
configurrii fiecrei staii care necesita conectarea la un robot fizic, timpul necesar pornirii
aplicaiei s-a redus la cteva minute maxim. Conectarea n laborator a unui numr de roboi se
poate face acum rapid i uor fr a consuma timpul util cu probleme de configurare a
sistemului de operare.
Robotux beneficiaz de un suport al protocolului DHCP (abr. Dynamic Host
Configuration Protocol), astfel c, ntr-o reea care conine un server DHCP, toate adresele de
reea vor fi alocate dinamic de ctre acesta, utilizatorul fiind scutit de aceste operaiuni.
De asemenea, s-a inclus suport pentru NTP (abr. Network Time Protocol), sincronizarea
timpului fiind fcut cu un server din reea, astfel eliminnd problemele care pot s apar din
cauza diferenelor de timp ntr-o aplicaie cu sisteme distribuite.
Pentru a nu recompila de la nceput toat distribuia de Robotux, ori de cte ori proiectul
bazat pe platforma agent i pe platforma robot este modificat, s-a decis ca proiectul s fie
dezvoltat fie pe un alt calculator n reea care urmeaz s fie accesat de ctre platforma
Robotux, fie pe o partiie a unui disc pe calculatorul local. Astfel Robotux poate fi folosit att
ca platform de dezvoltare, dar mai ales ca platform pentru testare. Protocolul ales pentru
accesarea unui calculator pe care aplicaia se dezvolt este SMB (Samba).
pagina 55
pagina 56
spiritului slab de observaie orict de atent ar fi, de multe ori exist lucruri care
scap privirii umane
Se pleac de la ideea de ce trebuie fcut ntr-un anumit spaiu (fie el sediu de firm sau
muzeu, etc) noaptea, n momentul n care sistemul clasic de securitate este activ. Pe lng
asigurarea securitii zonei respective, trebuie realizat i curarea acesteia. Se presupune c
zona este intens folosit n timpul zilei, deci noaptea ea trebuie curat.
Se va lua ca exemplu (pentru a simula o situaie real) ca spaiu de lucru, interiorul unui
muzeu. n acest muzeu exist anumite exponate care trebuie pzite noaptea de hoi. Pe lng
aceasta, slile muzeului trebuiesc curate de murdria acumulat n timpul zilei din cauza
vizitatorilor.
Pentru a implementa un asemenea scenariu folosind roboi mobili, evident ar trebui s
existe dou tipuri de astfel de roboi, i anume:
un robot de tip cleaner (ro. curtor) care se va ocupa de parcurgerea spaiului ce se
dorete a fi curat
un robot de tip security (ro. paznic) care se va ocupa de asigurarea securitii
muzeului
Acestea fiind stabilite, vom avea nevoie deci de doi ageni, un cleaner i un security. Ei
vor patrula mediul n permanen, mplinind sarcinile ce le-au fost date. Agenii vor comunica
cu roboii mobili, vor schimba informaii ntre ei, inndu-se unii pe alii tot timpul informai
despre starea celorlali.
n momentul detectrii unui anumit obstacol, agenii vor avea responsabilitatea s se
informeze ntre ei, i s investigheze dac obstacolul este un posibil obiect nou n mediu, un
obiect vechi care a fost deplasat cu civa centimetri, sau un posibil intrus n sistem. Pentru a
realiza acest lucru, trebuie ca agenii s aib permanent o hart dinamic a mediului, i s
schimbe informaii despre aceasta ntre ei.
Se presupune c roboii de tip cleaner sunt mai puin performani dect cei security, deci
mai ieftini. Performana ar putea fi exprimat prin prezena unor senzori mai buni, de
acuratee mare, motoare mai rapide, procesoare mai puternice pentru prelucrarea comenzilor
complexe, etc. Datorit acestui fapt, roboii cleaner nu vor putea identifica cu exactitate noul
obiect aprut n mediu. Pentru a rezolva aceast problem, ei vor fi nevoii s contacteze unul
sau mai muli roboi security care, fiind echipai cu senzori mai performani (laser de
exemplu), venind la locul scenei vor reui s detecteze i s identifice mult mai bine inta
respectiv. n cazul n care rezultatul analizei arat c noul obiect este sigur (se va discuta
ulterior ce poate fi numit sigur i ce nu pentru o anumit situaie), agenii security vor avea
responsabilitatea s actualizeze hrile proprii ale mediului ambiant i s trimit un mesaj n
acest sens tuturor agenilor participani din sistem, pentru ca i acetia s poat include noul
obiect pe hrile lor.
n cazul n care noul obiect este un posibil intrus, roboii de tip security vor lua decizia s
acioneze n privina opririi i imobilizrii acestuia. nainte de a lua aceste decizii, ei vor
trebui totui s se consulte i s verifice daca ntr-adevr intrusul este sau nu periculos pentru
sistem.
Pentru c acest lucru nu mai este deja de competena agentului security, sistemul va trebui
s conin un alt tip de agent, numit supervisor, care va putea interfaa chiar i cu un operator
pagina 58
uman la nevoie. Acest agent va avea sarcina de a lua deciziile importante n cazul detectrii
unui intrus, precum dac intrusul va fi imobilizat, sau dac vor fi altertate autoritile.
Pentru a pstra i un jurnal cu evenimentele importante din sistem, respectiv cu harta
dinamic a sistemului, se va beneficia de prezena unui alt tip de agent, numit DC (eng. abr.
Database Connector, ro. conector la baza de date). Acest agent va fi n permanen conectat la
o baz de date i va menine toate informaiile necesare sistemului n aceast baz de date. El
va avea un rol dual, att de stocare de informaie, ct i de interogare a bazei de date n
anumite situaii n care sistemul necesit anumite rapoarte.
Toi agenii menionai pn acum trebuie s comunice ntre ei, s trimit i s primeasc
mesaje, i totul ntr-un cadru dinamic. Pentru a comunica, ei trebuie nti s se gseasc unul
pe cellalt, acest lucru fiind posibil prin implementarea unui alt tip de agent, numit DF (eng.
abr. Directory Facilitator) care are ca prim rol implementarea unui serviciu de tip pagini
aurii al societii multiagent.
Sumariznd informaiile prezentate, societatea multiagent va fi alctuit din 5 tipuri
distincte de ageni, i anume:
Cleaneri, implementai pe roboi mobili, scop principal curarea mediului
DF, scop principal asigurarea unui serviciu de tip pagini aurii pentru ceilali
ageni
pagina 59
Numrul habitatelor necesar crete astfel la 5. Mai mult de un habitat va putea fi rulat de
pe aceeai arhitectur agent, ns numrul maxim de instane va fi dat de posibilitatea
arhitecturii de conectare la roboi. Astfel, dac o anumit arhitectur agent permite conectarea
a doi roboi simultan, numrul maxim de habitate posibile pe acea arhitectur va fi trei: dou
coninnd ageni cleaner sau security i DF plus unul coninnd Supervisor, DBCon i DF.
O posibil schem a lumii virtuale create pentru aplicaie este prezentat n figura 3.7. Se
observ zonele cu gri deschis care descriu exponatele muzeului, respectiv agenii roboi.
Cercurile (culoare verde) descriu agenii cleaner, care se ocup de curarea podelelor, iar
romburile (culoare roie) descriu agenii security, care se ocup de asigurarea securitii n
perimetrul respectiv.
pagina 60
Zon de siguran
maxim
cleaner
robot
security
robot
zona poate conine att senzori de micare auxiliari, ct i alte dispozitive menite
s porneasc alarma n momentul n care cineva intr n interiorul zonei respective
(senzorii fiind activai)
Scenariul s-ar putea desfura n felul urmtor: agenii cleaner i fac treaba, curind
podelele pn n momentul n care supervisor-ul decide c o anumit zon de securitate
maxim trebuie i ea curat. n acest moment, pe baza informaiilor din mediu, el va trimite
pagina 61
acolo cel mai apropiat agent cleaner i va dezactiva sistemul de senzori pentru zona de
securitate maxim. Pentru a asigura pe tot timpul procesului de curare al zonei i securitatea
acesteia, unul sau mai muli ageni security vor fi trimii mpreun cu agentul cleaner pentru
paz. n momentul n care zona s-a terminat de curat, agenii i vor relua rolul obinuit n
sistem, raportnd faptul c operaiunea s-a desfurat cu succes, iar agentul supervisor va
activa sistemul senzorial de securitate n momentul n care toi roboii au prsit zona
respectiv. Agenii i implicit roboii lor vor continua sarcinile care le-au fost date nainte de
implicarea n aciunea precedent.
O discuie mai ampl despre rolul fiecrui agent n sistem, precum i despre
comportamentul asignat acestuia va avea loc n momentul prezentrii n parte a fiecrui agent
din societatea Robotux.
De notat faptul c, agentul DF prezent n fiecare habitat din cadrul sistemului multiagent,
va face public periodic serviciile fiecrui agent n parte, att la nivel de habitat local, ct i la
nivel global de sistem reea. Rolul lui este de a pstra o list permanent, actualizat dinamic,
n primul rnd cu ceilali ageni DF din sistem cu care va comunica, i n al doilea rnd cu
fiecare agent n parte, oriunde s-ar afla acesta n sistem. n momentul n care un agent dorete
s comunica cu alt agent (un exemplu ar fi agentul cleaner dorete s informe agentul security
despre prezena unui obiect strin n mediu), acesta va ntreba agentul DF, unde anume se afl
localizat agentul cu care trebuie s comunice. Pentru a interoga agentul DF de acest lucru,
fiecare agent trebuie s tie adresa agentului DF local. Acest lucru se realizeaz printr-o
operaie de nregistrare a fiecrui agent, n momentul activrii lor n sistem, la DF-ul local.
Astfel comunicarea ntre ageni se desfoar ntr-un mod sigur, fr a exista probleme n
sensul gsirii unui anumit agent n sistem.
pagina 62
extra este pachetul n care se regsesc diverse clase folosite de toate celalalte
pachete ale aplicaiei
tasks este pachetul n care se gsesc att clasele care conin majoritatea taskurilor folosite de toi agenii precum i task-uri specifice, grupate n urmtoarele
pachete:
Cleaner pachetul care conine clase coninnd task-uri specifice agentului
Cleaner
DBCon pachetul care conine clase coninnd task-uri specifice agentului
DBCon
DF pachetul care conine clase coninnd task-uri specifice agentului DF
Security pachetul care conine clase coninnd task-uri specifice agentului
Security
Supervisor pachetul care conine clase coninnd task-uri specifice agentului
Supervisor
agents
cleaner
dbcon
df
security
supervisor
SpaceWander
algorithms
extra
tasks
WallBumping
WallFollowing
Cleaner
DBCon
DF
Security
Supervisor
pagina 63
Tip date
Integer
max-results
Integer
search-id
Descriere
Adncimea maxim de propagare a cutrii n
federaia DF. O valoare negativ indic faptul c
agentul emitor este dispus s lase cutarea s
propage n toat federaia.
Numrul maxim de rezultate pe care cutarea le
poate returna. O valoare negativ indic faptul
c emitorul este dispus s primeasc toate
rezultatele disponibile.
Un identificator unic global cutrii. Dac acesta
nu este specificat, el va fi generat automat.
Tabel 7. Parametrii de cutare ai agentului DF.
String
Pentru gsirea agentului DF local, orice agent i poate interoga directorul prin
mecanismele furnizate de ctre AFC (componenta ADK) spre a gsi agentul care furnizeaz
serviciu extra.Constants.DF_SERVICE_NAME. Informaii despre operaiile suportate de
ctre agentul DF sunt prezentate n tabelele urmtoare.
register
Cerere de tip request
Nume parametru
[subiect]
ContentKeys.SERVICE_NAME
ContentKeys.SERVICE_OWNER
Descriere
Tip date
Trebuie
s
aib
valoarea
Functions.REGISTER
Numele serviciului pe care agentul
dorete s-l publice
Adresa
agentului
care
ofer
serviciul. De notat c aceasta poate
fi diferit de adresa agentului care
emite cererea
String
String
String
Rspuns euat
Performativ
refuse
failure
Motiv
String
Descriere
deregister
Cerere de tip request
Nume parametru
[subiect]
ContentKeys.SERVICE_NAME
ContentKeys.SERVICE_OWNER
Descriere
Trebuie
s
aib
valoarea
Functions.DEREGISTER
Numele serviciului pe care agentul
dorete s-l publice
Adresa
agentului
care
ofer
serviciul. De notat c aceasta poate
fi diferit de adresa agentului care
emite cererea
Tip date
String
String
String
String
pagina 66
Rspuns euat
Performativ
refuse
failure
Motiv
Descriere
search
Cerere de tip request
Nume parametru
[subiect]
ContentKeys.SEARCH_KEY
ContentKeys.MAX_RESULTS
ContentKeys.SEARCH_DEPTH
ContentKeys.SEARCH_TIMEOUT
ContentKeys.SEARCH_ID
Descriere
Trebuie s aib valoarea
Functions.SEARCH
Numele serviciului cutat
Numrul
maxim
de
rezultate care poate fi
returnat ca rspuns. O
valoare negativ nseamn
c agentul este dispus s
accepte toate rezultatele
disponibile.
Valoarea
implicit este -1
Adncimea maxim la care
se poate propaga cutarea
n federaia de DF-uri. O
valoare negativ nseamn
c se permite propagarea n
ntreaga federaie. Valoarea
implicit este -1
Timpul dup care cutarea
va eua, n secunde
Identificatorul unic al
cutrii. Dac nu este
precizat, un identificator
unic se genereaz automat
i se ataeaz cutrii
nainte de propagarea n
federaie
Prezen
Tip date
Obligatorie
String
Obligatorie
String
Opional
Integer
Opional
Integer
Obligatorie
Integer
Opional
String
Descriere
Tip date
[subiect]
Identic cu cel al cererii
ContentKeys.RESULTS_COUNT Numrul de rezultate returnate. Poate fi nul
ContentKeys.RESULT_PREFIX
Prefixului i se ataeaz un index ntre 0 i n1, unde n este numrul rezultatelor, i la
cheile obinute n acest fel se afl stocate
adresele agenilor returnate ca rezultate
Rspuns euat
Performativ
Motiv
String
Integer
String
Descriere
pagina 67
refuse
failure
Dac DF primete o cerere cu un subiect diferit de cele reprezentnd funcii valide, replic
cu un mesaj de tip refuse avnd motivul Exceptions.UNSUPPORTED_FUNCTION.
Comportamentul DF este relativ simplu, i const n cea mai mare parte din tratarea
cererilor care sosesc pe adresa sa. Pentru aceasta, el trebuie s menin o structur de date
corespunztoare agenilor nregistrai ca furnizori ai diferitelor servicii. Cea mai potrivit
structur este o tabel indexat dup numele serviciului, care conine cte o mulime nevid
de adrese de ageni la fiecare index. Figura 3.9 prezint acest lucru.
registru-servicii
serviciu-0
furnizor-1, furnizor-2
serviciu-1
.
.
serviciu-n
furnizor-2
furnizor-1, furnizor-3, furnizor-4
pagina 68
InitPropertiesTask
RegisterTask
SearchTask
ListenerTask
HandleDFRequestTask
PeerDiscoveryTask
pagina 70
Cutarea tuturor agenilor de tip cleaner respectiv security din cadrul societii
multiagent i adugarea lor la o list de adrese intern
Trimiterea periodic a unor informaii referitoare la poziia robotului n mediu,
ctre toi agenii activi din societate: DBCon, Supervisor, respectiv toi agenii de
tip Security i Cleaner
Afiarea pe ecran a informaiilor primite de la ali ageni de tip cleaner i security
cu privire la poziia acestora n mediu
Exist mai multe discuii care pot s apar cu privire la comportamentul agentului Cleaner
ntr-un sistem complet funcional. Actualmente, codul existent n proiectul Robotux versiunea
0.1 face ca agentul Cleaner s beneficieze de un comportament oarecum incipient. Trebuie
discutate mai multe aspecte legate de funcionalitatea agentului, toate aceste aspecte fiind
strns legate de robotul fizic ce va implementa agentul Cleaner.
Pe de-o parte, agentul Cleaner, ar trebui s aib capacitatea de a detecta anumite obstacole
n calea lui, i de a le ocoli. Detecia de obstacole, compararea mediul cu o hart din memorie,
interpretarea obstacolelor, localizarea robotului n mediu sunt funcii care in ntr-o bun
msur de dotrile hardware ale robotului. n funcie de tipul i calitatea senzorilor folosii, se
poate obine o poziie mai exact a acestuia n mediu, ajungnd la erori de maxim civa
centimetri. Aceste lucruri ns sunt mai dificil de realizat n lumea real, datorit faptului c
sonarele robotului Pioneer2 existent n dotare, nu sunt deloc performante, erorile date uneori
de acestea fiind destul de mari. Pe de alt parte, comportamentul robotului poate fi mult mai
bine controlat n simulatorul Stage, datorit faptului c aici putem simula anumite tipuri de
senzori care ns nu sunt prezeni i n lumea real pe robotul existent n dotare. Ideea
proiectului a fost ns de a nu supraestima dotarea robotului, pe de o parte pentru a putea
demonstra eficacitatea unui algoritm bine implementat att n simulator ct i n lumea real,
iar pe de alt parte pentru a menine eventualele costuri de implementare a unui robot fizic de
tip Cleaner la o sum relativ mic de bani.
Un scenariu ideal ar fi ca agentul Cleaner s poat detecta daca un anumit obstacol ntlnit
n calea lui, face parte din mediu sau nu. n cazul n care un obiect a fost mutat cu civa
centimetri, robotul ar trebui s detecteze acest lucru i s nu alarmeze ali ageni, ci pur i
simplu s trimit mesaje de actualizarea a hrii, pentru ca aceast procedur s nu mai fie
repetat n momentul n care un alt agent robot ar trece pe lng locaia respectiv. n cazul n
care obiectul este mutat la o distan semnificativ (rmne de discutat pentru fiecare caz n
parte care este distana maxim admisibil), atunci el ar trebui s alarmeze c n sistem este
posibil s fi intrat un intrus. Pentru aceasta el va folosi lista agenilor security i va trimite
mesaje pentru a comunica lucrul respectiv. Cel mai apropiat agent security va avea
responsabilitatea s se deplaseze n locaia respectiv i, folosind un sistem de senzori mai
performant, s detecteze nivelul de siguran al intrusului. Acest nivel de siguran, depinde
de fiecare sistem n parte, n sensul c cel care implementeaz soluia Robotux ntr-un anumit
mediu, va trebui s defineasc i posibilele pericole pentru mediu cu un anumit nivel mai mic
sau mai mare de alert.
Robotul cleaner ar putea adopta una din tacticile:
disimulare robotul se va mica n continuare i i va face treaba, curnd
chiar i n jurul obiectului suspect, ncercnd s dovedeasc c el nu are
capacitatea de a detecta obiecte strine n mediu (eng. play dumb tactic) i
deci nu a observat intrusul
pagina 71
InitPropertiesTask
InitialisationTask
RegisterTask
ConnectTask
ListenerTask
HandleCleanerInformTask
DFRequestTask
UpdateSecurityListTask
SearchTask
UpdateSecurityListTask
SendRobotInfoTask
.......
SpaceWanderer
SendMessageTask
SendMessageTask
<Cleaner_port>6000</Cleaner_port>
<Cleaner_timeout>10</Cleaner_timeout>
<Cleaner_retries>6</Cleaner_retries>
<!-- The speed of the cleaner robot -->
<Cleaner_speed>150</Cleaner_speed>
<!-- Basic patrolling algorithm implementation for the cleaner robot
Possible algorithms values: 0 = wall bumper
1 = wall follower
2 = space wanderer
(any other value will default to wall bumper)
-->
<Cleaner_palgorithm>2</Cleaner_palgorithm>
</Cleaner_config>
Proprietii Cleaner.HOSTNAME din Constants.java i corespune Cleaner_host din
fiierul de configurare. Ea descrie numele/adresa IP a server-ului Player la care clientul care
implementeaz codul pentru robotul Cleaner se va conecta. Valoarea implicit este localhost.
Proprietii Cleaner.PORT din Constants.java i corespune Cleaner_port din fiierul de
configurare. Ea descrie numrul portului server-ului Player la care clientul care
implementeaz codul pentru robotul Cleaner se va conecta. Valoarea implicit este 6665.
Proprietii Cleaner.REGISTRATION_TIMEOUT din Constants.java i corespune
Cleaner_timeout din fiierul de configurare. Ea descrie numrul de secunde dup care cererea
de nregistrare la DF-ul local va eua. Valoarea implicit este de 10 secunde.
Proprietii Cleaner.REGISTRATION_RETRIES din Constants.java i corespune
Cleaner_retries din fiierul de configurare. Ea descrie numrul de ncercri de nregistrare la
DF-ul local dup care agentul va eua. Valoarea implicit este de 6 ncercri.
Proprietii Cleaner.SPEED din Constants.java i corespune Cleaner_speed din fiierul de
configurare. Ea descrie viteza n mm/s a robotului Cleaner. Valoarea implicit este de 150 de
mm/s.
Proprietii Cleaner.ALGORITHM din Constants.java i corespune Cleaner_palgorithm
din fiierul de configurare. Ea descrie tipul algoritmului de navigare implementat de agentul
Cleaner pentru robotul pe care l controleaz. Valoarea implicit este algoritmul
SpaceWanderer.
Dup terminarea operaiunii de iniializare, i parametrii agentului vor fi citii din fiier,
agentul Cleaner se va nregistra la DF-ul local prin apelarea RegisterTask, dar nu nainte de a
lansa o operaiune de cutare pentru agenii Supervisor i DBCon. De notat c operaiunea de
conectare la serverul Player specificat, se realizeaz nainte de acestea prin apelarea task-ului
ConnectTask.
Adresele agenilor DBCon i Supervisor vor fi pstrate i la ele se va face referire ori de
cte ori se va dori trimiterea unor mesaje ctre acetia.
Urmtorul pas este de a lansa task-ul HandleCleanerInformTask de tipul ListenerTask
care se va ocupa de tratarea mesajelor primite de agentul Cleaner. Comportamentul simplist
pagina 73
va face ca aceste mesaje s fie doar afiate pe ecranul calculatorului. Mesajele sunt de tip
Performatives.INFORM.
n paralel se vor starta cele dou task-uri periodice: UpdateCleanerListTask i
UpdateSecurityListTask care apeleaz task-uri de tipul SearchTask prin intermediul
DFRequestTask. Ele se ocup de meninerea listei curente de ageni Cleaner i Security din
cadrul cocietii multiagent. Aceste liste sunt reinute apoi i ele vor fi folosite ori de cte ori
va fi nevoie transmiterea unui mesaj ctre aceti ageni.
Un alt task pornit n paralel, va fi SendRobotInfoTask, task periodic apelat la fiecare
secund, care va trimite mesaje ctre toi agenii din sistem, specificnd att poziia curent a
robotului ct i unghiul pe care se deplaseaz acesta (viteza fiind cunoscut) fa de
orizontal.
Un ultim task pornit este task-ul care se ocup de navigarea robotului, n figur fiind
prezentat task-ul care implementeaz algoritmul SpaceWanderer. Alternative posibile sunt
oricare din ceilali algoritmi, ns SpaceWanderer se apropie cel mai mult de un
comportament ideal al agentului Cleaner.
Robotul cleaner este definit n fiierul robotux.world, fiier care definete lumea virtual
folosit n simulatorul Stage.
# ---[ Cleaner Robot agent ]--define cleaner omniposition (
power ()
p2dx_sonar ()
truth ()
size [0.3 0.3]
obstacle_return "visible"
sonar_return "visible"
vision_return "visible"
laser_return "bright"
color "blue"
interval 0.01
)
Dispozitivele folosite sunt deci, 16 sonare de tip Pioneer, un dispozitiv de localizare truth
pentru simulatorul Stage, respectiv accesul la motoarele robotului.
pagina 74
InitPropertiesTask
InitialisationTask
RegisterTask
ConnectTask
ListenerTask
HandleSecurityInformTask
DFRequestTask
UpdateSecurityListTask
SearchTask
UpdateSecurityListTask
SendRobotInfoTask
.......
WallFollower
SendMessageTask
SendMessageTask
pagina 78
InitPropertiesTask
InitialisationTask
RegisterTask
ConnectTask
ListenerTask
HandleConnectorRequestTask
pagina 79
pagina 80
pagina 81
Sistemul mai conine i un intrus, simulat printr-un alt robot cu form de cerc de culoare
maro. Caracteristicile lui sunt echivalente cu cele ale unui robot cleaner, ns acestuia i-a fost
asignat un anumit identificator aparte, pentru a putea fi detectat de robotul security.
Se observ c, toate camerele video situate pe robot au rol de a demonstra doar c robotul
interacioneaz cu obiectele din mediu. Ele nu sunt ns folosite de sistemul Robotux.
Sistemul de senzori cu laser, va fi n schimb folosit pentru identificarea obiectelor din mediu.
Fiecare obiect sau robot are asignat un identificator. De asemenea fiecare exponat are ataat
un anumit identificator, care ajut la localizarea n spaiu a robotului.
Datorit faptului c nu s-au folosit roboi fizici, numrul habitatelor care se poate porni pe
aceeai arhitectur agent nu mai este limitat de numrul de roboi fizici care se puteau conecta
pe aceea arhitectur. Astfel n teorie, toi agenii ar putea rula pe aceeai arhitectur agent,
ns datorit performanelor sczute ale unei astfel de implementri, acest lucru nu este
recomandat.
n momentul startrii celor 5 habitate necesare, configuraia societii multiagent arat ca
cea din figura 3.15.
Security1
DF3
Cleaner1
DF2
Security2
DF4
DBCon
DF1
Supervisor
DF5
Cleaner2
De notat c instruciunile date mai sus reprezint doar paii generali care trebuie urmai,
instruciunile pas cu pas fiind dificile de prezentat innd cont de dinamica mediului Linux i
de multitudinea de distribuii existente pe Internet. De aceea, se recomand persoanelor care
nu sunt familiarizate cu mediul Linux, s citeasc nti manualul de folosire al acestui sistem
de operare.
pagina 83
4. Concluzii i dezvoltare
ulterioar
pagina 84
Proiectul Robotux a fost dezvoltat din nevoia de a avea o platform pentru dezvoltare de
software dedicat sistemelor multiagent i roboilor mobili. Acest lucru a fost realizat n mare
parte, ns proiectul necesit suport i dezvoltri ulterioare pentru a putea fi ntrebuinat pe
scar larg.
Sistemul de securitate cu acelai nume, Robotux, prezentat ca aplicaie exemplu n
proiectul de fa, nu a fost construit cu scopul de a fi 100% funcional n momentul terminrii
proiectului, ci mai degrab pentru a demonstra avantajele unui sistem distribuit bazat pe
ageni software n lucrul cu roboi mobili.
Nu se ateapt ca sistemul de securitate Robotux s devin un standard n lumea
sistemelor de securitate, ns sunt cteva elemente care nu ar trebui totui neglijate, i pe care
un sistem clasic de securitate le-ar putea ngloba. Dezvoltarea ultrarapid a tehnologiei va
permite n curnd sisteme mai inteligente dect cele pe care le folosim acum. Astfel, unele
elemente din aceste sisteme ar putea fi uor nglobate n locul operatorilor umani. O asemenea
soluie bazat pe roboi mobili i ageni software nu numai c ar fi mai ieftin, datorit
faptului c sistemul ar necesita doar cheltuieli iniiale mari, n timp ce unul sau mai muli
operatori umani ar trebui pltii lunar pentru activitile pe care le fac, dar ar putea fi i mai
eficient. Oamenii n general au un comportament predictibil, erorile umane sunt repetabile,
iar n cazul unui sistem de securitate, exist acele elemente precum oboseala, rutina, stresul
sau pur i simplu un spirit de observaie slab, care slbesc sistemul, fcndu-l penetrabil n
faa unui posibil intrus. O alt caracteristic important a unui sistem informatic este aceea c
un algoritm bine conceput ar putea include anumite elemente aleatoare care i-ar micora
semnificativ gradul de predictibilitate.
Sistemul Robotux este complet scalabil, noi ageni pot fi adugai sistemului dinamic,
pornii n habitate noi, atta timp ct noi ageni se conformeaz regulilor sistemului. Un
anumit grad de redundan este disponibil, n sensul c un agent poate prelua sarcinile unui alt
agent n cazul n care acesta nu poate face fa sarcinilor respective. De asemenea, trebuie
menionat faptul c sistemul funcioneaz i cu un singur agent Security respectiv un singur
agent Cleaner. Totui pentru a demonstra c sistemul de comunicare funcioneaz eficace
ntre roboi, s-a decis ca numrul minim al acestora s fie 4.
Un alt loc n care un sistem de securitate bazat pe ageni software i roboi mobili ar putea
s fie mai bine tolerat dect un sistem clasic, este acolo unde prezena uman nu este dorit
(de exemplu medii n care temperatura trebuie inut la o anumit valoare, iar prezena uman
ar putea afecta echilibrul termic ntr-un mod negativ).
Ca dezvoltri ulterioare, se propune n primul rnd finalizarea algoritmilor de navigare,
proiectarea agentului Supervisor, respectiv nglobarea unui comportament mai puternic
pentru agenii roboi. De asemenea, este neaprat nevoie de includerea unor alte tipuri de
algoritmi pentru navigarea roboilor n mediu (ca de exemplu D*).
Alte lucruri ar putea fi mbuntite folosind roboi mai buni, mai rapizi n locul celor de
la ActivMedia. Datorit faptului c senzorii sunt cei care ne dau datele despre mediu, rolul
acestora este foarte important n sistem. Cu ct senzorii sunt mai precii, cu att sistemul este
mai precis i funcioneaz n parametrii dorii.
Un alt punct slab al sistemului este faptul c roboii sunt alimentai de la baterii. Un sistem
de detectare a nivelului bateriei, precum i posibilitatea robotului de a se alimenta singur
pagina 85
(asemntor ca unele AGV-uri) de la priz n momentul n care acest nivel critic este detectat,
ar putea fi o mbuntire semnificativ a proiectului.
Nu n ultimul rnd, trebuie dezvoltai algoritmii de procesare a datelor primite de la
senzori, precum i implementarea unui comportament mai eficace al agenilor Security, cu
eventuala posibilitate de control n formaie al acestora.
pagina 86
Bibliografie
Bibliografia listeaz toate titlurile lucrrilor, documentelor i literaturii de specialitate
utilizate n lucrare. Referirea nspre aceste titluri din interiorul lucrrii urmeaz notaia
[index], spre exemplu o referire poate arta astfel: [3] sau [12].
1. Ronald C. Arkin, (1998), Behavior-Based Robotics, The Massachusetts Institute of
Technology Press 1998
2. M. Isabel Ribeiro, Alessandro Saffiotti, (2002), Lecture notes from European Summer
School on Cooperative Robotics, Institute for Systems and Robotics 2002
3. *** The Developers Guide, ADK 2.1 Edition, (2002), Tryllian Holding N.V.
4. *** The ADK Scenarios, ADK 2.1 Edition, (2002), Tryllian Holding N.V.
5. *** The Quickstart Guide, ADK 2.1 Edition, (2002), Tryllian Holding N.V.
6. *** Public ARE Specifications, revision 1.16 Edition, (2002), Tryllian Holding N.V.
7. *** Tryllian ADK v2.1 API Specification, (2002), Tryllian Holding N.V.
8. ***
FIPA
SC00001,
Abstract
Architecture
Specification,
http://www.fipa.org/specs/fipa00001/SC00001L.html
9. *** Java2 Platform, Standard Edition v1.4.1 API Specification, (2002), Sun
Microsystems, Inc.
10. Lucian Buoniu, Sisteme multiagent n DBIST i testare distribuit, (2003), Facultatea
de Automatic i Calculatoare, Universitatea Tehnic din Cluj-Napoca
11. Richard T. Vaughan, Brian P. Gerkey, and Andrew Howard. On device abstractions
for portable, reusable robot code. In Proc. of the IEEE/RSJ Intl. Conf. on Intelligent
Robots and Systems (IROS), pages 21212427, Las Vegas, Nevada, October 2003.
12. Brian P. Gerkey, Richard T. Vaughan, and Andrew Howard. The Player/Stage
Project: Tools for Multi-Robot and Distributed Sensor Systems. In Proc. of the Intl.
Conf. on Advanced Robotics (ICAR), pages 317323, Coimbra, Portugal, July 2003.
13. Brian P. Gerkey, Richard T. Vaughan, Kasper Sty, Andrew Howard, Maja J Mataric
and Gaurav S Sukhatme. Most Valuable Player: A Robot Device Server for
Distributed Control. In Proc. of the IEEE/RSJ Intl. Conf. on Intelligent Robots and
Systems (IROS), pages 12261231, Wailea, Hawaii, October 2001.
14. Brian P. Gerkey, Richard T. Vaughan, Andrew Howard, (2003), Player version
1.42rc2 User manual, http://playerstage.sourceforge.net/doc/Player-manual-1.4.pdf
15. Richard T. Vaughan, Andrew Howard, Brian P. Gerkey, (2003), Stage version 1.3.3
User manual, http://playerstage.sourceforge.net/doc/Stage-manual-1.3.3.pdf
16. Andrew Howard, Nathan Koenig, (2004), Gazebo version 0.3.0 User manual,
http://playerstage.sourceforge.net/doc/Gazebo-manual-0.3.0.pdf
17. Maxim A. Batalin, (2004), Javaclient for Player/Stage HowTo
18. *** MySQL Reference Manual for version 4.0.20
19. *** AmigoBOT Technical Manual, (2000), ActivMedia Robotics, LLC.
20. *** Pioneer2/PeopleBot Operations Manual, (2001), ActivMedia Robotics, LLC.
21. *** AmigoBOT Users Guide, (2003), ActivMedia Robotics, LLC.
22. Stuart Rusell, Peter Norvig, Artificial Intelligence A modern approach (The
Intelligent agent book), (1995), Prentice Hall, New Jersey
23. Johann Borenstein, Yoram Koren, The Vector Field Histogram Fast Obstacle
Avoidance for Mobile Robots, (1991), IEEE Transactions on Robotics and
Automation, vol. 7, no. 3, june 1991
24. Howie Choset, Keiji Nagatani, Nicole A. Lazar, The Arc-Transversal Median
Algorithm: A Geometric Approach to Increasing Ultrasonic Sensor Azimuth Accuracy,
(2003), IEEE Transactions on Robotics and Automation, vol. 19, no. 3, june 2003
pagina A.1
//
robot = (PlayerClient)getProperty(Constants.Cleaner.ROBOT);
robot.runThreaded(1,1);
robot.setNotThreaded();
motors = (PositionPlayerDevice)getProperty(Constants.Cleaner.MOTORS);
sonar = (SonarPlayerDevice)getProperty(Constants.Cleaner.SONAR);
truth = (TruthPlayerDevice)getProperty(Constants.Cleaner.TRUTH);
int SPEED = new Integer
(getProperty(Constants.Cleaner.SPEED).toString()).intValue();
// enable motors
motors.setMotorState(1);
// ignore the first sonar readings (stupid, stupid robot)
int time1 = motors.getTimeForDataSampled_sec();
int time2 = motors.getTimeForDataSampled_sec();
while (time2 - time1 < 3) {
robot.readAll ();
time2 = motors.getTimeForDataSampled_sec();
}
int refreshInterval = 10;
addTask (new PeriodicalTask (new UpdateCleanerListTask
(Constants.Cleaner.Cleaner_ADDRESSES), refreshInterval, false));
addTask (new PeriodicalTask (new UpdateSecurityListTask
(Constants.Cleaner.Security_ADDRESSES), refreshInterval, false));
refreshInterval = 1;
String me = "[" + getMyAddress().getHost() + ":" + getMyAddress().getPort() + "]";
addTask (new PeriodicalTask (new SendRobotInfoTask("cleaner-robot-"+me, truth,
fiducial, "database"), refreshInterval, false));
addTask (new PeriodicalTask (new SendRobotInfoTask("cleaner-robot-"+me, truth,
fiducial, "cleaner"), refreshInterval, false));
addTask (new PeriodicalTask (new SendRobotInfoTask("cleaner-robot-"+me, truth,
fiducial, "security"), refreshInterval, false));
int algorithm = new Integer
(getProperty(Constants.Cleaner.ALGORITHM).toString()).intValue();
switch (algorithm) {
case 0:{
addTask (new PeriodicalTask (new WallBumper1 (robot, motors,
pagina A.2
agents/dbcon/DatabaseConnector.java
package agents.dbcon;
import tasks.ListenerTask;
import tasks.HandlersFactory;
import tasks.DBCon.HandleConnectorRequestTask;
import tryllian.afc.agent.Agent;
import tryllian.are.TransientAgent;
import tryllian.afc.task.Task;
import tryllian.afc.task.standard.DieTask;
import tryllian.afc.task.TaskScheduler;
import tryllian.afc.task.standard.LogTask;
import tryllian.afc.message.DefaultMessageFilter;
import tryllian.afc.message.Performatives;
import tryllian.afc.message.IncomingMessage;
import tasks.DBCon.DBConInitTask;
public class DatabaseConnector extends Agent implements TransientAgent {
private static String AGENT_NAME = "DatabaseConnector";
public DatabaseConnector (String[] args) {
setName (AGENT_NAME);
}
public void agentStarted () {
Task initTask = new DBConInitTask ();
//
agents/DF/DirectoryFacillitator.java
package agents.df;
import extra.Constants;
import tasks.InitPropertiesTask;
import tasks.HandlersFactory;
import tasks.ListenerTask;
import tasks.DF.HandleDFRequestTask;
import tasks.DF.PeerDiscoveryTask;
import tryllian.are.TransientAgent;
import tryllian.afc.agent.Agent;
import tryllian.afc.task.Task;
import tryllian.afc.task.TaskGroup;
import tryllian.afc.task.TaskScheduler;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.standard.PeriodicalTask;
import tryllian.afc.task.standard.LogTask;
import tryllian.afc.task.standard.DieTask;
import tryllian.afc.task.standard.RegisterTask;
import tryllian.afc.message.DefaultMessageFilter;
import tryllian.afc.message.Performatives;
import tryllian.afc.message.IncomingMessage;
import java.util.HashSet;
import java.util.HashMap;
public class DirectoryFacilitator extends Agent implements TransientAgent, TaskListener {
//
public DirectoryFacilitator () {
setName ("DirectoryFacilitator");
setName ("DF");
setProperty (Constants.DF.PEERS_REGISTRY, new HashSet ());
setProperty (Constants.DF.ACTIVE_SEARCHES, new HashSet ());
pagina A.4
agents/security/SecurityRobot.java
package agents.security;
import extra.Constants;
import algorithms.WallBumping.WallBumper1;
import algorithms.WallBumping.WallBumper2;
import algorithms.WallFollowing.WallFollower;
import tasks.HandlersFactory;
pagina A.5
pagina A.6
//
robot = (PlayerClient)getProperty(Constants.Security.ROBOT);
robot.runThreaded(1,1);
robot.setNotThreaded();
motors = (PositionPlayerDevice)getProperty(Constants.Security.MOTORS);
sonar = (SonarPlayerDevice)getProperty(Constants.Security.SONAR);
truth = (TruthPlayerDevice)getProperty(Constants.Security.TRUTH);
fiducial = (FiducialInterface)getProperty(Constants.Security.FIDUCIAL);
int SPEED = new Integer
(getProperty(Constants.Security.SPEED).toString()).intValue();
// enable motors
motors.setMotorState(1);
// ignore the first sonar readings (stupid, stupid robot)
int time1 = motors.getTimeForDataSampled_sec();
int time2 = motors.getTimeForDataSampled_sec();
while (time2 - time1 < 3) {
robot.readAll ();
time2 = motors.getTimeForDataSampled_sec();
}
int refreshInterval = 10;
addTask (new PeriodicalTask (new UpdateCleanerListTask
(Constants.Security.Cleaner_ADDRESSES), refreshInterval, false));
addTask (new PeriodicalTask (new UpdateSecurityListTask
(Constants.Security.Security_ADDRESSES), refreshInterval, false));
refreshInterval = 1;
String me = "[" + getMyAddress().getHost() + ":" + getMyAddress().getPort() + "]";
addTask (new PeriodicalTask (new SendRobotInfoTask("security-robot-"+me, truth,
fiducial, "database"), refreshInterval, false));
addTask (new PeriodicalTask (new SendRobotInfoTask("security-robot-"+me, truth,
fiducial, "cleaner"), refreshInterval, false));
addTask (new PeriodicalTask (new SendRobotInfoTask("security-robot-"+me, truth,
fiducial, "security"), refreshInterval, false));
int algorithm = new Integer (getProperty
(Constants.Security.ALGORITHM).toString()).intValue();
switch (algorithm) {
case 0:{
addTask (new PeriodicalTask (new WallBumper2 (robot, motors,
sonar, truth, SPEED, robotSize), 1, false));
break;
}
case 1:{
addTask (new PeriodicalTask (new WallBumper1 (robot, motors,
sonar, truth, SPEED, robotSize), 10, false));
break;
}
case 2:{
pagina A.7
agents/supervisor/SecurityRobot.java
package agents.supervisor;
import tasks.Supervisor.SupervisorInitTask;
import tryllian.afc.agent.Agent;
import tryllian.afc.task.Task;
import tryllian.are.TransientAgent;
public class SuperAgent extends Agent implements TransientAgent {
public SuperAgent () {
setName ("Supervisor Agent");
}
public void agentStarted () {
Task initTask = new SupervisorInitTask ();
addTask (initTask);
}
}
algorithms/SpaceWanderer/SpaceWanderer.java
package algorithms.SpaceWanderer;
import Javaclient.src.PlayerClient;
import Javaclient.src.PositionPlayerDevice;
import Javaclient.src.SonarPlayerDevice;
import Javaclient.src.TruthPlayerDevice;
import Javaclient.src.Beacon;
import tryllian.afc.task.DefaultTask;
public class SpaceWanderer extends DefaultTask {
private PlayerClient robot;
private PositionPlayerDevice motors;
private SonarPlayerDevice sonar;
private TruthPlayerDevice truth;
private int beaconCount;
pagina A.8
algorithms/WallBumping/WallBumper1.java
package algorithms.WallBumping;
import Javaclient.src.PlayerClient;
import Javaclient.src.PositionPlayerDevice;
import Javaclient.src.SonarPlayerDevice;
import Javaclient.src.TruthPlayerDevice;
import Javaclient.src.Beacon;
import tryllian.afc.task.DefaultTask;
public class WallBumper1 extends DefaultTask {
private PlayerClient robot;
private PositionPlayerDevice motors;
private SonarPlayerDevice sonar;
private TruthPlayerDevice truth;
private int beaconCount;
private Beacon[] beacons;
private int SONARS[];
private int robotSize;
private int speed;
private int SPEED = speed;
boolean left = true;
int next = 0;
public WallBumper1 (PlayerClient r, PositionPlayerDevice m, SonarPlayerDevice s, TruthPlayerDevice
t, int speed,int size) {
this.robot = r;
this.motors = m;
this.sonar = s;
this.truth = t;
this.speed = speed;
this.robotSize = size;
}
/*
* Simple WALL BUMP algorithm. Makes use of 4 sonar sensors (3, 4, 11, 12), but needs a robot with
16 sonar sensors.
*/
public void handleHeartbeat () {
SONARS = sonar.getRanges();
if (wallInFront()) {
left = false;
}
if (wallInBack()) {
left = true;
}
if (left) SPEED = speed;
pagina A.10
algorithms/WallBumping/WallBumper2.java
package algorithms.WallBumping;
import Javaclient.src.PlayerClient;
import Javaclient.src.PositionPlayerDevice;
import Javaclient.src.SonarPlayerDevice;
import Javaclient.src.TruthPlayerDevice;
import tryllian.afc.task.DefaultTask;
public class WallBumper2 extends DefaultTask {
private PlayerClient robot;
private PositionPlayerDevice motors;
private SonarPlayerDevice sonar;
private TruthPlayerDevice truth;
private int SPEED;
private int robotSize;
private int SONARS[];
private int TURN = 20;
boolean bumped = false;
boolean calibrated = false;
private long count = 0;
public WallBumper2 (PlayerClient r, PositionPlayerDevice m, SonarPlayerDevice s, TruthPlayerDevice
t, int speed,int size) {
this.robot = r;
this.motors = m;
this.sonar = s;
this.truth = t;
this.SPEED = speed;
this.robotSize = size;
}
/*
* WALL BUMP algorithm version 2. Needs a robot with just 8 sonar sensors, but it is very hard to
impossible to make the
* robot be exactly perpendicular without changing course on the walls.This could probably be solved
by using more
* accurate sensors.
pagina A.11
algorithms/WallFollowing/WallFollower.java
package algorithms.WallFollowing;
import extra.Constants;
import Javaclient.src.PlayerClient;
import Javaclient.src.PositionPlayerDevice;
import Javaclient.src.SonarPlayerDevice;
import Javaclient.src.TruthPlayerDevice;
import tryllian.afc.task.DefaultTask;
public class WallFollower extends DefaultTask {
private PlayerClient robot;
private PositionPlayerDevice motors;
private SonarPlayerDevice sonar;
private TruthPlayerDevice truth;
private int robotSize;
private int SPEED;
private int SONARS[];
private int MIN = 0;
boolean followingLeftWall = true;
private boolean movingLeft = false;
int count = 0;
int count1 = 0;
boolean gotWall = false;
boolean needAdjustment = true;
boolean needAlignment = true;
boolean doneAlignment = false;
private int LEAST = 200;
private int MIN = 0;
private int BUMP = 190;
public WallFollower (PlayerClient r, PositionPlayerDevice m, SonarPlayerDevice s, TruthPlayerDevice
t, int speed, int size) {
pagina A.13
pagina A.15
extra/Constants.java
package extra;
public interface Constants {
public interface DBCon {
public static final String HOSTNAME
= "localhost";
public static final String DBNAME
= "ZeeRobots";
public static final String USERNAME
= "Robotux";
public static final String PASSWORD
= "ZeeRobots";
public static final String REGISTRATION_TIMEOUT
= "registration-timeout";
public static final String REGISTRATION_RETRIES
= "registration-retries";
public static final String DATABASE_CONNECTION
= "database-connection";
}
public static interface DF {
public static final String PEERS_DISCOVERY_INTERVAL = "peers-discovery-interval";
public static final String PING_TIMEOUT
= "ping-timeout";
pagina A.17
= "register";
= "deregister";
= "search";
pagina A.18
= "ping";
}
public static interface Exceptions {
public static final String ALREADY_REGISTERED = "already-registered";
public static final String NOT_REGISTERED
= "not-registered";
public static final String SEARCH_ALREADY_ACTIVE= "search-already-active";
public static final String MISSING_ARGUMENT = "missing-argument";
public static final String UNSUPPORTED_FUNCTION
= "unsupported-function";
}
public static interface ContentKeys {
public static final String SERVICE_NAME
public static final String SERVICE_OWNER
public static final String SEARCH_ID
public static final String SEARCH_KEY
public static final String SEARCH_DEPTH
public static final String SEARCH_TIMEOUT
public static final String MAX_RESULTS
public static final String RESULTS_COUNT
public static final String RESULT_PREFIX
}
= "service-name";
= "service-owner";
= "search-id";
= "search-key";
= "search-depth";
= "search-timeout";
= "max-results";
= "results-count";
= "result-";
extra/DFNotFoundException.java
package extra;
public class DFNotFoundException extends Exception {
public DFNotFoundException () {
super ("Directory-Facilitator agent not found within habitat");
}
}
extra/GenericInfo.java
package extra;
public abstract class GenericInfo implements java.io.Serializable {
}
extra/Guidelines.java
package extra;
public class Guidelines implements java.io.Serializable {
public short beaconID;
public short range;
public short bearing;
public short orientation;
public short rangeUncertain;
public short bearingUncertain;
public short orientationUncertain;
pagina A.19
extra/RobotInfo.java
package extra;
import java.util.Calendar;
public class RobotInfo extends GenericInfo {
public String agentname = "";
public int xPos = 0;
public int yPos = 0;
public int heading = 0;
public String timestamp = "";
public int beaconCount;
public Guidelines[] beacons;
public RobotInfo (String creator, int x, int y, int h, int bcount, Guidelines[] b) {
this.agentname = creator;
this.xPos = x;
this.yPos = y;
this.heading = h;
this.beaconCount = bcount;
this.beacons = b;
this.timestamp = createTimestamp();
}
private String createTimestamp () {
Calendar calendar = Calendar.getInstance ();
int hour = (calendar.get(Calendar.AM_PM) == Calendar.PM ? 12 : 0)
+ calendar.get(Calendar.HOUR),
minute = calendar.get(Calendar.MINUTE),
second = calendar.get(Calendar.SECOND),
millisecond = calendar.get(Calendar.MILLISECOND);
StringBuffer stamp = new StringBuffer();
stamp.append(hour < 10 ? "0" : "").append(hour)
.append(':')
.append(minute < 10 ? "0" : "").append(minute)
.append(':')
.append(second < 10 ? "0" : "").append(second)
.append('.')
.append(millisecond < 10 ? "00" : millisecond < 100 ? "0" : "")
.append(millisecond);
return stamp.toString();
}
}
pagina A.20
tasks/Cleaner/CleanerInitTask.java
package tasks.Cleaner;
import extra.Constants;
import tasks.InitialisationTask;
import tasks.InitPropertiesTask;
import tasks.DFRequestTask;
import tasks.ServiceSearchTask;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.Task;
import tryllian.afc.task.TaskGroup;
import tryllian.afc.task.TaskScheduler;
import tryllian.afc.task.AgentContext;
import tryllian.afc.task.standard.TaskRetryTask;
import tryllian.address.AgentAddress;
public class CleanerInitTask extends InitialisationTask {
private ServiceSearchTask DBConSearcher, SuperSearcher;
private static final String Cleaner_SERVICENAME = "cleaner-robot";
public CleanerInitTask () {
super (Cleaner_SERVICENAME, new String[] {
Constants.Cleaner.HOSTNAME,
Constants.Cleaner.PORT,
Constants.Cleaner.REGISTRATION_TIMEOUT,
Constants.Cleaner.REGISTRATION_RETRIES,
Constants.Cleaner.SPEED,
Constants.Cleaner.ALGORITHM
});
}
public void taskStarted () { super.taskStarted();}
public void taskEnded (TaskEvent te) {
if (te.getTask() instanceof InitPropertiesTask) {
AgentContext context = getAgentContext ();
int timeoutValue = new Integer (context.getProperty
(Constants.Cleaner.REGISTRATION_TIMEOUT).toString()).intValue();
int retriesValue = new Integer (context.getProperty
(Constants.Cleaner.REGISTRATION_RETRIES).toString()).intValue();
int ssTimeout = 12;
int ssRetries = 5;
Task serviceSearch = new TaskGroup (new Task[] {
DBConSearcher = new ServiceSearchTask ("database-connector", 1, -1
ssRetries, ssTimeout),
SuperSearcher = new ServiceSearchTask ("super-agent", 1, -1, ssRetries,
ssTimeout)
});
Task registration = new TaskRetryTask (DFRequestTask.createRegisterTask
(Cleaner_SERVICENAME,
context.getMyAddress().toString(), timeoutValue), retriesValue);
Task sequencer = new TaskScheduler (new Task [] {
new ConnectTask (),
pagina A.21
tasks/Cleaner/ConnectTask.java
package tasks.Cleaner;
import extra.Constants;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.AgentContext;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.standard.LogTask;
import java.net.ConnectException;
import java.net.UnknownHostException;
import java.io.IOException;
import Javaclient.src.PlayerClient;
import Javaclient.src.PositionPlayerDevice;
import Javaclient.src.SonarPlayerDevice;
import Javaclient.src.TruthPlayerDevice;
public class ConnectTask extends DefaultTask implements TaskListener {
private static final char PLAYER_ALL_MODE = 'a';
private String hostname;
private String port;
public void taskStarted () {
AgentContext context = getAgentContext ();
this.hostname = context.getProperty(Constants.Cleaner.HOSTNAME).toString();
this.port = context.getProperty(Constants.Cleaner.PORT).toString();
LogTask l = new LogTask ("Connecting to " + hostname + ":" + port);
l.addTaskListener (this);
addTask(l);
}
pagina A.22
tasks/Cleaner/HandleCleanerInformTask.java
package tasks.Cleaner;
import extra.RobotInfo;
import extra.GenericInfo;
import tasks.HandleMessageTask;
import tryllian.afc.message.IncomingMessage;
import tryllian.afc.message.object.ObjectMessage;
public class HandleCleanerInformTask extends HandleMessageTask {
public HandleCleanerInformTask (IncomingMessage msg) { super (msg);}
public void taskStarted () {
if (msg.getSubject().equals ("position-info")) {
GenericInfo info = retrieveObject ();
if (info instanceof RobotInfo) {
RobotInfo a = (RobotInfo)info;
System.err.println ("[" + a.timestamp + "] Robot " + a.agentname + " is at
X=" + a.xPos + ",Y=" + a.yPos + " heading=" + a.heading);
}
}
}
private GenericInfo retrieveObject () {
ObjectMessage objMsg = new ObjectMessage ();
objMsg.fillContents(msg);
try {
return (GenericInfo)objMsg.retrieveObject();
} catch (Exception e) {
System.err.println (e.getMessage ());
return null;
pagina A.23
tasks/DBCon/ConnectTask.java
package tasks.DBCon;
import extra.Constants;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.AgentContext;
import tryllian.afc.task.standard.LogTask;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class ConnectTask extends DefaultTask {
public ConnectTask () { super (); }
public void taskStarted () {
AgentContext context = getAgentContext ();
String connectionString = "jdbc:mysql://" +
context.getProperty(Constants.DBCon.HOSTNAME) + ":3306/" +
context.getProperty(Constants.DBCon.DBNAME) + "?user=" +
context.getProperty(Constants.DBCon.USERNAME) + "&password=" +
context.getProperty(Constants.DBCon.PASSWORD);
addTask (new LogTask ("Connecting to " + connectionString));
// load the driver
try {
Class.forName("com.mysql.jdbc.Driver");
} catch (ClassNotFoundException e) {
addTask(new LogTask(e.getMessage ()));
}
// connect to the database
try {
Connection con = DriverManager.getConnection(connectionString);
context.setProperty(Constants.DBCon.DATABASE_CONNECTION, con);
succeed ();
} catch (SQLException e) {
System.err.println (e.getMessage());
fail ();
}
}
}
tasks/DBCon/DBConInit.java
package tasks.DBCon;
import extra.Constants;
import tasks.InitialisationTask;
import tasks.InitPropertiesTask;
import tasks.DFRequestTask;
import tryllian.afc.task.Task;
pagina A.24
tasks/DBCon/HandleConnectorRequestTask.java
package tasks.DBCon;
import extra.RobotInfo;
import extra.GenericInfo;
import tryllian.afc.message.IncomingMessage;
pagina A.25
tasks/DBCon/UpdateDatabaseTask.java
package tasks.DBCon;
import extra.Constants;
import tryllian.afc.task.DefaultTask;
import java.sql.Connection;
import java.sql.Statement;
import java.sql.SQLException;
public class UpdateDatabaseTask extends DefaultTask {
public UpdateDatabaseTask () { super (); }
//
tasks/DF/HandleDFRequestTask.java
package tasks.DF;
import extra.Constants;
import tryllian.afc.task.standard.LogTask;
import tryllian.afc.message.IncomingMessage;
import tasks.HandleMessageTask;
import tryllian.afc.message.NoSuchAgentException;
import tryllian.afc.message.fipa.Agree;
import tryllian.afc.message.fipa.Refuse;
import tryllian.afc.message.fipa.Failure;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Set;
public class HandleDFRequestTask extends HandleMessageTask {
public HandleDFRequestTask (IncomingMessage msg) { super (msg); }
public void taskStarted () {
// register or deregister request
if ( (msg.getSubject().equals (Constants.Functions.REGISTER)) ||
(msg.getSubject().equals (Constants.Functions.DEREGISTER))) {
String serviceName = msg.getContent(Constants.ContentKeys.SERVICE_NAME);
String serviceOwner =
msg.getContent(Constants.ContentKeys.SERVICE_OWNER);
if ((serviceName == null) || (serviceOwner == null)) {
try { msg.reply(new Refuse (msg.getSubject(),
Constants.Exceptions.MISSING_ARGUMENT));
} catch (NoSuchAgentException nsae) {}
addFinalTask (new LogTask ("Missing argument(s) in [" + msg.getSubject()
+ "] requested by [" + msg.getSender() + "]."));
return;
}
HashMap registry = (HashMap)getAgentContext().getProperty
(Constants.DF.SERVICES_REGISTRY);
Set providers = (HashSet)registry.get(serviceName);
if (msg.getSubject().equals(Constants.Functions.REGISTER)) {
if (providers == null) {
providers = new HashSet ();
registry.put(serviceName, providers);
}
if (providers.contains(serviceOwner)) {
try { msg.reply (new Failure (msg.getSubject(),
Constants.Exceptions.ALREADY_REGISTERED));
} catch (NoSuchAgentException nsae) {}
addFinalTask (new LogTask ("[" + serviceOwner + "] already
pagina A.27
//
tasks/DF/PeerDiscoveryTask.java
package tasks.DF;
import extra.Constants;
pagina A.28
pagina A.29
tasks/DF/SearchTask.java
package tasks.DF;
import extra.Constants;
import tasks.DFRequestTask;
import tryllian.afc.task.Task;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.standard.LogTask;
import tryllian.afc.message.IncomingMessage;
import tryllian.afc.message.NoSuchAgentException;
import tryllian.address.AgentAddress;
import tryllian.afc.message.fipa.Agree;
import tryllian.afc.message.fipa.Refuse;
import java.util.Set;
import java.util.HashSet;
import java.util.Map;
import java.util.Iterator;
public class SearchTask extends DefaultTask implements TaskListener {
private transient IncomingMessage request;
private String searchID;
private String searchKey;
private int maxResults;
private Set results = new HashSet ();
private boolean resultsSent = false;
private int subSearchesCount = 0;
public SearchTask (IncomingMessage request) {
this.request = request;
}
public void taskStarted () {
Set activeSearches = (Set)getAgentContext().getProperty
(Constants.DF.ACTIVE_SEARCHES);
pagina A.30
= (Set)getAgentContext().getProperty(Constants.DF.PEERS_REGISTRY);
= request.getContent(Constants.ContentKeys.SEARCH_ID);
tasks/Security/ConnectTask.java
package tasks.Security;
import extra.Constants;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.AgentContext;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.standard.LogTask;
import java.net.ConnectException;
import java.net.UnknownHostException;
pagina A.33
pagina A.34
tasks/Security/HandleSecurityInformTask.java
package tasks.Security;
import extra.RobotInfo;
import extra.GenericInfo;
import extra.Constants;
import tasks.HandleMessageTask;
import tryllian.afc.message.IncomingMessage;
import tryllian.afc.message.object.ObjectMessage;
import tryllian.address.AgentAddress;
public class HandleSecurityInformTask extends HandleMessageTask {
private boolean foundIntruder = false;
public HandleSecurityInformTask (IncomingMessage msg) { super (msg);}
public void taskStarted () {
if (msg.getSubject().equals ("position-info")) {
GenericInfo info = retrieveObject ();
if (info instanceof RobotInfo) {
RobotInfo a = (RobotInfo)info;
System.err.println ("[" + a.timestamp + "] Robot " + a.agentname + " is at
X=" + a.xPos + ",Y=" + a.yPos + " heading=" + a.heading);
foundIntruder = false;
if (a.beaconCount > 0) {
for (int i=0; i < a.beaconCount; i++)
if ((a.beacons[i].beaconID >= 151) &&
(a.beacons[i].beaconID <= 200)) {
foundIntruder = true;
if (a.beacons[i].range < 2000) {
System.err.println (" ---> Possible INTRUDER found at " + a.beacons[i].range + "mm with
orientation=" + a.beacons[i].orientation + " and ID=" + a.beacons[i].beaconID);
getAgentContext().setProperty(Constants.Security.INTRUDER_ALERT, "!stop!");
AgentAddress myAddress = getAgentContext().getMyAddress();
try {
AgentAddress[] otherSecurityAddresses =
(AgentAddress[])getAgentContext().getProperty(Constants
.Security.Security_ADDRESSES);
for (int cnt=0; cnt < otherSecurityAddresses.length; cnt++) {
if (otherSecurityAddresses[i] != myAddress) {
System.err.println (" Sent message to " +
otherSecurityAddresses[i]. getHost());
}
}
} catch (Exception e) { }//System.err.println (e.toString()); }
}
} // if beaconID
} // if beaconCount
if (!foundIntruder)
getAgentContext().setProperty(Constants.Security.INTRUDER_ALERT, "!go!");
} // if instanceof
} // if Subject
}
private GenericInfo retrieveObject () {
ObjectMessage objMsg = new ObjectMessage ();
objMsg.fillContents(msg);
try {
return (GenericInfo)objMsg.retrieveObject();
pagina A.35
tasks/Security/SecurityInitTask.java
package tasks.Security;
import extra.Constants;
import tasks.InitialisationTask;
import tasks.InitPropertiesTask;
import tasks.ServiceSearchTask;
import tasks.DFRequestTask;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.Task;
import tryllian.afc.task.TaskGroup;
import tryllian.afc.task.TaskScheduler;
import tryllian.afc.task.AgentContext;
import tryllian.afc.task.standard.TaskRetryTask;
import tryllian.address.AgentAddress;
public class SecurityInitTask extends InitialisationTask {
private ServiceSearchTask DBConSearcher, SuperSearcher;
private static final String Security_SERVICENAME = "security-robot";
public SecurityInitTask () {
super (Security_SERVICENAME, new String[] {
Constants.Security.HOSTNAME,
Constants.Security.PORT,
Constants.Security.REGISTRATION_TIMEOUT,
Constants.Security.REGISTRATION_RETRIES,
Constants.Security.SPEED,
Constants.Security.ALGORITHM,
});
}
public void taskStarted () { super.taskStarted();}
public void taskEnded (TaskEvent te) {
if (te.getTask() instanceof InitPropertiesTask) {
AgentContext context = getAgentContext ();
int timeoutValue = new Integer (context.getProperty(
Constants.Security.REGISTRATION_TIMEOUT).toString()).intValue();
int retriesValue = new Integer (context.getProperty
(Constants.Security.REGISTRATION_RETRIES).toString()).intValue();
int ssTimeout = 12;
int ssRetries = 5;
Task serviceSearch = new TaskGroup (new Task[] {
DBConSearcher = new ServiceSearchTask ("database-connector", 1, -1,
ssRetries, ssTimeout),
SuperSearcher = new ServiceSearchTask ("super-agent", 1, -1, ssRetries,
ssTimeout)
pagina A.36
tasks/Supervisor/SupervisorInitTask.java
package tasks.Supervisor;
import extra.Constants;
import tasks.InitialisationTask;
import tasks.InitPropertiesTask;
import tasks.DFRequestTask;
import tasks.ServiceSearchTask;
import tryllian.afc.task.AgentContext;
import tryllian.afc.task.Task;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.TaskGroup;
import tryllian.afc.task.TaskScheduler;
import tryllian.afc.task.standard.TaskRetryTask;
import tryllian.address.AgentAddress;
public class SupervisorInitTask extends InitialisationTask {
private ServiceSearchTask DBConSearcher;
private static final String Supervisor_SERVICENAME = "super-agent";
public SupervisorInitTask() {
super (Supervisor_SERVICENAME, new String [] {
Constants.Supervisor.REGISTRATION_TIMEOUT,
Constants.Supervisor.REGISTRATION_RETRIES,
});
}
pagina A.37
//
//
sequencer.addTaskListener(this);
addTask (sequencer);
return;
}
if ( (te.getTask() instanceof TaskScheduler ) && (te.getTask().getState().isSucceeded())) {
getAgentContext().setProperty(
Constants.Cleaner.DBCon_ADDRESS,
((AgentAddress[])DBConSearcher.getFinishValue())[0]);
}
if (te.getTask ().getState().isSucceeded()) succeed ();
else fail (te.getTask().getFinishValue ());
}
}
tasks/DFRequestTask.java
package tasks;
import extra.Constants;
import extra.DFNotFoundException;
import tryllian.afc.message.OutgoingMessage;
import tryllian.afc.message.fipa.Request;
import tryllian.address.AgentAddress;
import tryllian.afc.message.IncomingMessage;
import java.net.MalformedURLException;
public class DFRequestTask extends RequestTask {
protected DFRequestTask (OutgoingMessage req, int timeout) {
super (req, timeout);
}
public static DFRequestTask createRegisterTask (String serviceName, String serviceOwner, int
pagina A.38
pagina A.39
tasks/HandleMessage.java
package tasks;
import tryllian.afc.task.Task;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.message.IncomingMessage;
public abstract class HandleMessageTask extends DefaultTask implements TaskListener {
protected transient IncomingMessage msg;
protected HandleMessageTask (IncomingMessage msg) {
this.msg = msg;
}
protected void addFinalTask (Task finalTask) {
finalTask.addTaskListener (this);
pagina A.40
tasks/HandlersFactory.java
package tasks;
import tryllian.afc.task.Task;
import tryllian.afc.message.IncomingMessage;
public interface HandlersFactory extends java.io.Serializable {
public Task createHandler(IncomingMessage msg);
}
tasks/InitialisationTask.java
package tasks;
import tryllian.afc.task.Task;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
public abstract class InitialisationTask extends DefaultTask implements TaskListener {
protected String agentName;
private String[] propNames;
protected InitialisationTask (String AGENT_NAME, String[] propNames) {
this.agentName = AGENT_NAME;
this.propNames = propNames;
}
public void taskStarted () {
Task propsInit = new InitPropertiesTask (agentName, propNames);
propsInit.addTaskListener(this);
addTask (propsInit);
}
public void taskStarted (TaskEvent te) {}
}
tasks/InitPropertiesTask.java
package tasks;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.standard.LogTask;
import javax.xml.parsers.SAXParserFactory;
import javax.xml.parsers.SAXParser;
import org.xml.sax.XMLReader;
//import org.xml.sax.helpers.DefaultHandler;
pagina A.41
tasks/ListenerTask.java
package tasks;
import tryllian.afc.task.ReactiveTask;
import tryllian.afc.message.MessageFilter;
import tryllian.afc.message.IncomingMessage;
public class ListenerTask extends ReactiveTask {
protected HandlersFactory factory;
public ListenerTask (MessageFilter filter, HandlersFactory factory) {
this.factory = factory;
setMessageFilter (filter);
}
public void handleMessage (IncomingMessage msg) {
addTask (factory.createHandler (msg));
}
}
tasks/RequestTask.java
package tasks;
import tryllian.afc.task.ReactiveTask;
import tryllian.afc.message.OutgoingMessage;
import tryllian.afc.message.DefaultMessageFilter;
import tryllian.afc.task.interaction.SendMessageTask;
import tryllian.afc.message.IncomingMessage;
import tryllian.afc.message.Performatives;
public class RequestTask extends ReactiveTask {
public static final String TIMEOUT_FINISH_VALUE = "Request Timed Out";
protected OutgoingMessage req;
protected int timeout;
private long timerStart;
private static long instancesCounter = 0;
public RequestTask (OutgoingMessage req, int timeout) {
this.req = req;
this.timeout = timeout;
}
public void taskStarted() {
//if no conversation ID is currently set, generate a unique one
if (req.getConversationID() == null) {
//we guarantee the uniqueness by combining the issuing
pagina A.46
tasks/SendRobotInfoTask.java
package tasks;
import extra.Constants;
import extra.RobotInfo;
import extra.Guidelines;
import tryllian.afc.task.Task;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.address.AgentAddress;
import tryllian.afc.task.interaction.SendMessageTask;
import java.util.Set;
import java.util.HashSet;
import java.util.Iterator;
import Javaclient.src.Beacon;
import Javaclient.src.TruthPlayerDevice;
import Javaclient.src.FiducialInterface;
import tryllian.afc.message.object.ObjectMessage;
pagina A.47
tasks/ServiceSearchTask.java
package tasks;
pagina A.49
tasks/UpdateCleanerListTask.java
package tasks;
pagina A.50
import tasks.DFRequestTask;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.address.AgentAddress;
public class UpdateCleanerListTask extends DefaultTask implements TaskListener {
private String Cleaner_addresses = "cleaner-addresses";
public UpdateCleanerListTask (String property) {
this.Cleaner_addresses = property;
}
public void taskStarted () {
int timeoutValue = 15;
int maxresults = 3;
DFRequestTask cleanerSearch = DFRequestTask.createSearchTask ("cleaner-robot", -1,
maxresults, timeoutValue);
cleanerSearch.addTaskListener(this);
addTask (cleanerSearch);
}
public void taskStarted (TaskEvent te) {}
public void taskEnded(TaskEvent te) {
if (te.getTask().getState().isSucceeded()) {
AgentAddress[] results = ((DFRequestTask)te.getTask()).getSearchResults();
getAgentContext().setProperty(Cleaner_addresses, results == null ? new
AgentAddress[0] : results);
}
}
}
tasks/UpdateSecurityListTask.java
package tasks;
import tasks.DFRequestTask;
import tryllian.afc.task.DefaultTask;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.address.AgentAddress;
public class UpdateSecurityListTask extends DefaultTask implements TaskListener {
private String Security_addresses = "security-addresses";
public UpdateSecurityListTask (String property) {
this.Security_addresses = property;
}
public void taskStarted () {
int timeoutValue = 15;
int maxresults = 3;
DFRequestTask cleanerSearch = DFRequestTask.createSearchTask ("security-robot", -1,
maxresults, timeoutValue);
pagina A.51
pagina A.52
pagina B.3
pagina B.4
pagina C.1
srcdir="${relative.source}"
destdir="${relative.compiled}"
classpath="${project.classpath}"
debug="true"
optimize="false"
/>
</target>
<!-Create the jarfile
pagina D.1
jarfile="${relative.jarfiles}/block.jar"
basedir="${relative.compiled}"
compress="${options.jarfiles.compress}"
/>
</target>
<!-targets for building DNA files
-->
<target name="supervisor" depends="init, jar">
<dna dna="${agents.dnadir}/supervisor.dna"
agentdescriptor="${relative.descriptors}/supervisor.xml"
keystore="${jarsign.keystore}"
alias="${jarsign.tryllian-developer}"
storepass="${jarsign.password}">
<content
name="block.jar"
file="${relative.jarfiles}/block.jar"
target="standard"
/>
</dna>
</target>
<target name="security" depends="init, jar">
<dna dna="${agents.dnadir}/security.dna"
agentdescriptor="${relative.descriptors}/security.xml"
keystore="${jarsign.keystore}"
alias="${jarsign.tryllian-developer}"
storepass="${jarsign.password}">
<content
name="block.jar"
file="${relative.jarfiles}/block.jar"
target="standard"
/>
<content
name="Javaclient.jar"
file="${relative.libraries}/Javaclient.jar"
target="standard"
/>
</dna>
</target>
<target name="cleaner" depends="init, jar">
<dna dna="${agents.dnadir}/cleaner.dna"
agentdescriptor="${relative.descriptors}/cleaner.xml"
keystore="${jarsign.keystore}"
alias="${jarsign.tryllian-developer}"
storepass="${jarsign.password}">
<content
name="block.jar"
file="${relative.jarfiles}/block.jar"
target="standard"
/>
<content
name="Javaclient.jar"
file="${relative.libraries}/Javaclient.jar"
pagina D.2
pagina D.4
pagina D.7
pagina E.4