Rusu Diploma Thesis

UNIVERSITATEA TEHNIC DIN CLUJ-NAPOCA
FACULTATEA DE AUTOMATIC I CALCULATOARE

P
P
R
R
O
O
I
I
E
E
C
C
T
T
D
D
E
E
D
D
I
I
P
P
L
L
O
O
M
M

Absolvent: Radu Bogdan Rusu

Conductori: conf. dr. ing. Liviu Miclea
prof. dr. ing. Gheorghe Lazea

2004

S
S
i
i
s
s
t
t
e
e
m
m
m
m
u
u
l
l
t
t
i
i
a
a
g
g
e
e
n
n
t
t
p
p
e
e
n
n
t
t
r
r
u
u
r
r
o
o
b
b
o
o
i
i

m
m
o
o
b
b
i
i
l
l
i
i
:
:
R
R
o
o
b
b
o
o
t
t
u
u
x
x

Facultatea de Automatic i Calculatoare
Catedra de Automatic
DECAN, VIZAT EF CATEDR,
Prof. Dr. Ing. Sergiu Nedevschi Conf. Dr. Ing. Liviu Miclea

Absolvent: Radu Bogdan Rusu

T TE EM MA A P PR RO OI IE EC CT TU UL LU UI I D DE E D DI IP PL LO OM M

1. Enunul temei:
Sistem multiagent pentru roboi mobili: Robotux

2. Date iniiale:
Document ai a de i mpl ement are a si st emel or mul t i agent i a si st emelor robot .

3. Coninutul proiectului:
A. Piese scrise:
Foai e de capt , Apreci erea cadrul ui di dact ic conduct or, Si nt eza,
Memori u t ehni c, Memori u j ust i f icati v, Bi bli ografie, Anexa

B. Piese desenate, programe surs:
Coduri surs al e claselor i i nt erf eel or pachet elor apl icai ei precum i ale
scri pt uri l or de i nst al are si rul are a acest ei a, Fiiere de confi gurare al e
apl i cai ei , Jurnale de f unc ionare al e apli cai ei pent ru scenari i -t est

4. Locul documentrii: UNIVERSITATEA TEHNIC DIN CLUJ-NAPOCA

5. Consultani: asi st. i ng. Radu Roboti n

6. Data emiterii temei: 1 noi embri e 2004

7. Termen de predare: 11 i uni e 2004

Semntura conductorului de proiect:
Semntura absolventului:

UNIVERSITATEA TEHNIC DIN CLUJ-NAPOCA Nota obinut la Proba 2:
Facultatea de Automatic i Calculatoare Prezentare i susinere proiect de diplom

A Ap pr re ec ci i e er re ea a c ca ad dr ru ul l u ui i d di i d da ac ct t i i c c c co on nd du uc c t t o or r

Asupra proiectului de diplom:

Autor: Radu Bogdan Rusu
Conductor: conf. dr. ing. Liviu Miclea

1. Documentarea absolventului asupra temei:
foarte bun: bun: suficient: insuficient:

2. Gradul de noutate al temei:
foarte mare: mare: mediu: mic:

3. Gradul de dificultate al temei:

4. Volumul de munc depus:

5. Idei originale sau semnificative introduse de ctre absolvent n proiect:
foarte multe: multe: puine: nici una:

6. Rezultatele au fost testate (sunt corecte):
complet: parial: insuficient: deloc:

7. Cerinele temei au fost ndeplinite:
complet: aproape complet: suficient: insuficient:

8. Prezentarea (claritatea) i aspectul lucrrii:
foarte bune: bune: suficiente: insuficiente:

9. Alte aprecieri (dac este cazul):

Data: Semntura conductorului:


S SI IN NT TE EZ ZA A

Proiectului de diplom:

Autor: Radu Bogdan Rusu
Conductori: conf. dr. ing. Liviu Miclea

1. Definirea problemei: Lucrarea se ocup de studiul comportamental al roboilor n sisteme
multiagent, precum i de posibilitile acestora de comunicare folosind ageni software.
2. Domeniul de utilizare, posibiliti de aplicare: Sisteme care folosesc extensiv roboii
mobili, sisteme de securitate bazate pe ageni software Java i roboi mobili.
3. Documentare: Principalele surse de informare au fost documentaia platformei agent,
documentaia platformei robot, cartea Behaviour-Based Robotics, de Ronald C. Arkin,
cartea Artificial Inteligence a modern approach, de Stuart Rusell i Peter Norvig.
Pentru detalii a se vedea bibliografia.
4. Soluii posibile pentru abordarea temei: Fiind aleas ca soluie multiagent platforma
ADK de la firma Tryllian, s-au considerat diverse platforme robot, dintre care s-a insistat
asupra platformei Saphira/ARIA i asupra platformei Player/Stage.
5. Soluia sau metoda aleas: Platforma robot aleas a fost Player/Stage, att datorit
faptului c reprezint o soluie puternic suportat de comunitatea open-source, ct i
datorit posibilitii de a folosi dou tipuri de simulatoare: Gazebo (3D) i Stage (2D).
6. Rezultate obinute: O simulare a unui posibil scenariu real pentru un sistem de securitate
modern folosind ageni software i roboi mobili.
7. Testri i verificri: Un scenariu realist de sistem distribuit de securitate a fost modelat i
supus societii multiagent, demonstrnd conceptele de baz ale sistemului Robotux.
8. Contribuii personale: Instalarea i configurarea platformelor ADK i Player/Stage,
elaborarea ntregului volum de cod-surs al aplicaiei, ageni, comportamentul roboilor.
9. Concluzii: Lucrarea demonstreaz avantajele abordrii distribuite bazate pe ageni
software ale unui sistem multirobot, precum i posibilitatea de a implementa acest gen de
sisteme n proiecte realiste.

Data:
Semntura conductorului: Semntura absolventului:

Declaraia autorului,

Subsemnatul Radu Bogdan Rusu, student al Facultii de Automatic i
Calculatoare, Universitatea Tehnic din Cluj-Napoca, declar prin prezenta c ideile, partea de
proiectare i experimentare, rezultatele, analizele i concluziile cuprinse n aceast Proiect de
Diplom constituie efortul meu propriu, mai puin acele elemente ce nu-mi aparin, pe care le
indic i le recunosc ca atare.
Declar de asemenea, c dup tiina mea lucrarea n aceast form este original i nu
a mai fost niciodat prezentat sau depus n alte locuri sau altor instituii dect cele indicate
n mod expres de mine.

Data: 11 iunie 2004 Student: Radu Bogdan Rusu
Matricola: 1836/X
Semntura

Sistem multiagent pentru roboi mobili: R Ro ob bo ot tu ux x
Cuprins

I. Introducere ..............................................................................1

II. Memoriu tehnic .....................................................................3

2.1. Ce este un robot? ............................................................................. 4
2.1.1. Breviar. Scurt istoric........................................................................................ 4
2.1.2. Definiie ............................................................................................................. 4
2.1.3. Concepte ale existenei roboilor..................................................................... 5
2.1.4. Asemnri cu omul........................................................................................... 5
2.1.5. Modul de interaciune ...................................................................................... 6
2.1.6. Tipuri de roboi................................................................................................. 7

2.2. Ce este un robot mobil?................................................................. 8
2.2.1. Definiie. Caracteristici .................................................................................... 8
2.2.2. Exemple de roboi mobili ................................................................................. 8
2.2.2.1.Pioneer DX................................................................................................... 9
2.2.2.2.Pioneer AT.................................................................................................. 10
2.2.2.3.AmigoBot ................................................................................................... 11

2.3. Ce este un agent? ........................................................................... 12
2.3.1. Definiie. Caracteristici .................................................................................. 12
2.3.2. Agent raional. Agent inteligent .................................................................... 13
2.3.3. Clasificarea agenilor ..................................................................................... 13
2.3.4. Structura agenilor inteligeni ....................................................................... 15
2.3.5. Mediul agent. Tipuri de medii agent............................................................. 15

2.4. Ce este un sistem multiagent? ................................................... 17

2.5. Platforme multiagent.................................................................... 19
2.5.1. Agent Development Kit ........................................................................... 19
2.5.1.1.Agenii de sistem....................................................................................... 22
2.5.1.2.Tipuri de task-uri n ADK. Modele de task-uri ..................................... 23
2.5.1.3.Implementarea modelului task-urilor .................................................... 24
2.5.1.4.Comunicarea ntre ageni ........................................................................ 25
2.5.1.5.Parametrii mesajelor FIPA...................................................................... 27
2.5.1.6.Modele de interaciune............................................................................. 28

2.6. Platforme robot .............................................................................. 32
2.6.1. Saphira/ARIA............................................................................................. 32
2.6.2. Player/Stage................................................................................................. 37
2.6.2.1.Player......................................................................................................... 37
2.6.2.2.Stage........................................................................................................... 41
2.6.2.3.Gazebo ....................................................................................................... 47

Cuprins

III. Memoriu justificativ.........................................................51

3.1. Selectarea platformei robot........................................................ 52
3.2. Robotux............................................................................................. 53
3.3. Proiectarea i implementarea aplicaiei................................. 56
3.3.1.Stabilirea obiectivelor aplicaiei .................................................................... 56
3.3.2.Structura societii multiagent ...................................................................... 57
3.3.3.Structura pachetelor software Robotux ....................................................... 62
3.3.4.Proiectarea agentului DF............................................................................... 64
3.3.5.Proiectarea agentului Cleaner....................................................................... 70
3.3.6.Proiectarea agentului Security ...................................................................... 74
3.3.7.Proiectarea agentului DBCon........................................................................ 79
3.3.8.Proiectarea agentului Supervisor.................................................................. 80
3.3.9.Integrarea agenilor n sistem........................................................................ 81
3.3.10.Manual de instalare...................................................................................... 83

IV. Concluzii i dezvoltare ulterioar..............................84

Lista de figuri

1. Figura 2.1 Robotul i interaciunea acestuia cu mediul nconjurtor .......................... 4
2. Figura 2.2 Modul de interaciune clasic al unui robot................................................. 6
3. Figura 2.3 Modul de interaciune al unui robot propus de Brooks.............................. 7
4. Figura 2.4 Pioneer 3 DX, vedere frontal.................................................................... 9
5. Figura 2.5 Pioneer 3 DX, vedere spate........................................................................ 9
6. Figura 2.6 Dispunerea senzorilor sonar..................................................................... 10
7. Figura 2.7 Schema de baz a robotului Pioneer 3 AT............................................... 10
8. Figura 2.8 Pioneer 3 AT............................................................................................ 10
9. Figura 2.9 Robotul Amigobot n versiunea tethered ................................................. 11
10. Figura 2.10 Robotul Amigobot n versiune wireless................................................. 11
11. Figura 2.11 Tipuri de ageni ...................................................................................... 14
12. Figura 2.12 Schema general a unui sistem centralizat............................................. 17
13. Figura 2.13 Schema general a unui sistem multiagent ............................................ 18
14. Figura 2.14 Comportamentul agentului ADK........................................................... 21
15. Figura 2.15 Diagrama de stare a unui task ADK....................................................... 25
16. Figura 2.16 Modul de interaciune query-ref............................................................. 29
17. Figura 2.17 Modul de interaciune request................................................................ 30
18. Figura 2.18 Modul de interaciune subscribe-cancel................................................. 31
19. Figura 2.19 Arhitectura sistem a platformei ARIA................................................... 33
20. Figura 2.20 Arhitectura sistemului de control a platformei Saphira/ARIA .............. 34
21. Figura 2.21 Fereastra principal a Saphira reprezentnd sistemul LPS .................... 35
22. Figura 2.22 Fereastra principal a simulatorului Pioneer.......................................... 36
23. Figura 2.23 Exemplu de interaciune client-server folosind Player .......................... 40
24. Figura 2.24 Arhitectura global a serverului Player.................................................. 41
25. Figura 2.25 Exemplu de mediu virtual construit pentru simulatorul Stage............... 46
26. Figura 2.26 Mediu construit pentru Stage ca exemplu pentru entitatea puck ........... 46
27. Figura 2.27 Exemplu de mediu virtual construit pentru simulatorul Gazebo ........... 47
28. Figura 2.28 Interaciune cu mediul nconjurtor ....................................................... 47
29. Figura 2.29 Simulare a robotului NASA JPL de tip paianjen ................................... 48
30. Figura 2.30 Simulare a robotului Segway RPM n Gazebo ...................................... 48
31. Figura 2.31 Model al lumii virtuale n Gazebo versiunea 0.3.0................................ 50
32. Figura 2.32 Imagine de la o camer virtual instalat pe robotul mobil ................... 50

33. Figura 3.1 Arhitectura sistemului rezultat (ADK + Player/Stage) ............................ 52
34. Figura 3.2 Imagine din procesul de boot-up al platformei Robotux ........................ 54
37. Figura 3.5 Ecranul Robotux v0.1 dup terminarea procesului de ncrcare.............. 55
38. Figura 3.6 Un exemplu al societii multiagent Robotux.......................................... 60
39. Figura 3.7 O posibil hart a lumii simulate Robotux............................................... 61
40. Figura 3.8 Ierarhia de pachete a aplicaiei Robotux.................................................. 63
41. Figura 3.9 Structura registrului de servicii DF.......................................................... 68
42. Figura 3.10 Comportamentul agentului DF............................................................... 69
43. Figura 3.11 Comportamentul agentului Cleaner ....................................................... 72
44. Figura 3.12 Comportamentului agentului Security ................................................... 76
45. Figura 3.13 Comportamentul agentului DBCon ....................................................... 79
46. Figura 3.14 Harta virtual a mediului Robotux simulat n Stage ............................ 81
47. Figura 3.15 - Configuraia societii multiagent Robotux............................................ 82


pagina 1

1
1
.
.
I
I
n
n
t
t
r
r
o
o
d
d
u
u
c
c
e
e
r
r
e
e

Introducere

pagina 2

Dezvoltarea exponenial a sistemelor informatice ct i a microelectronicii n ultima
perioad, precum i creterea continu a gradului de integrare a sistemelor bazate pe roboi
mobili, duc la concepte noi, precum societi multirobot. Aceste societi sunt formate din
zeci pn la sute de roboi mobili care trebuie s lucreze mpreun pentru a ndeplini anumite
sarcini ce le sunt date. Dac pn la un numr mic de roboi, controlul acestora se poate face
centralizat, folosind arhitecturi de tip client server, comunicarea ntre acetia devine greoaie
cnd numrul roboilor din societate depete o anumit valoare prag.

Rezolvarea acestor probleme const n adaptarea sistemelor multiagent pentru lucrul cu
roboi mobili. Integrarea societii multirobot cu o societate multiagent ntr-un sistem unitar,
heterogen, scalabil, redundant i flexibil devine o soluie necesar pentru rezolvarea
problemelor complexe. Lucrarea de fa i propune s studieze conceptele eseniale ale unui
astfel de sistem complex, multiagent, multirobot, rolul pe care un agent software l are n acest
sistem, modul de comunicare al agentului cu robotul fizic, precum i metodele de comunicare
ntre roboi cu ajutorul agenilor n cadrul societii formate.

Dac acum civa ani, roboii mobili erau folosii doar n scopuri educaionale sau pentru
cercetare, acum acetia ncep s devin folosii pe scar larg i n alte tipuri de sisteme.

Ca i demonstraie a conceptelor prezentate n lucrare, se va prezenta o aplicaie bazat pe
un scenariu real, i anume sistemul de securitate Robotux. Acest sistem se dorete a fi o
alternativ la un sistem de securitate clasic, care folosete camere video i operatori umani
pentru a monitoriza activitatea ntr-o anumit zon. Sistemul Robotux, implementat eficient,
nu numai c ar putea fi mai ieftin dect un sistem clasic, dar, n opinia autorului, i mai bun
dect acesta. Argumentele principale se bazeaz pe erorile care le poate genera factorul
uman, n orice sistem de securitate existent care funcioneaz pe principiul clasic camer
video monitorizare paznic. O persoan uman este previzibil n aciunile pe care le
ntreprinde, n timp ce un sistem distribuit bazat pe algoritmi puternici poate include anumite
elemente aleatoare care micoreaz semnificativ factorul de predictibilitate al aciunilor sale
urmtoare. Acest lucru ngreuneaz munca unui posibil intrus n sistem.

Pe lng motivele prezentate mai sus, factorul uman poate slbi sigurana unui sistem de
securitate datorit oboselii, rutinei, stresului, sau pur i simplu datorit unui spirit slab de
observaie. Robotux ncearc s elimine aceaste probleme, abordnd o soluie distribuit
bazat pe un sistem multiagent care lucreaz cu roboi mobili. Societatea astfel creat este
capabil s fac fa unui grad divers de situaii, sistemul fiind att scalabil ct i redundant.

Scopul lucrrii de fa nu a fost de a implementa acest sistem ntr-un stadiu n care el s
poat fi folosit pe scar larg n viitorul apropiat. n schimb s-a ncercat demonstrarea
avantajelor unei soluii cu control descentralizat, folosind ageni software, n lucrul cu roboi
mobili, respectnd conceptele de baz ale comunicrii multiagent. Se vor studia i detalia att
posibilitile de conectare a unei platforme multiagent cu o platform robot, ct i modalitile
de comunicare, navigare, respectiv control al roboilor mobili din societatea astfel format.

pagina 3

2
2
.
.
M
M
e
e
m
m
o
o
r
r
i
i
u
u
t
t
e
e
h
h
n
n
i
i
c
c

Ce este un robot?

pagina 4
Efectori
Mediul
nconjurtor
Senzori
2 2. .1 1. . C Ce e e es st te e u un n r ro ob bo ot t? ?

2.1.1. Breviar. Scurt istoric

Cuvntul robot provine din limba ceh (robota) i nseamn muncitor, sau rob.
Proveniena acestui cuvnt este strns legat de scenaristul Karel Capek, care a introdus acest
cuvnt n anul 1921 ntr-una din scenetele acestuia: R.U.R. (Rossums Universal Robots).
Tema acestei scenete era despre dezumanizarea persoanei ntr-o civilizaie bazat din ce n ce
mai mult pe tehnologie. Se pare c sceneta a avut un enorm succes la acea vreme.

Termenul de robotics (n traducere liber robotic) se refer la tiina care se ocup de
studiul i utilizarea roboilor. Acest termen a fost prima dat folosit de scriitorul i omul de
tiin american de origine rus, Isaac Asimov, ntr-o scurt povestioar numit Runaround
n anul 1942. Aceast poveste scurt a fost apoi inclus ntr-o colecie numit I, Robot, care
a fost publicat n anul 1950.

Primii roboi s-au numit Unimates i au aprut n anii 50, fiind dezvoltai de George
Devol i Joe Engelberger. Acesta din urm a format Unimation i a fost primul care a vndut
roboi, fiind considerat de unii ca printele roboticii.

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
necesar ca un robot s adune date prin
intermediul senzorilor de-a lungul unei
perioade de timp. Orice tip de senzor este
bineneles predispus la erori.

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.

Ce este un robot?

pagina 5
2.1.3 Concepte ale existenei roboilor

Binecunoscutul autor de literatur Science Fiction, Isaac Asimov, a propus trei legi ale
roboticii sau mai bine zis ale existenei unui robot [26]. Mai trziu acesta a adugat nc o
lege, numit legea zero. Cu toate c aceste legi au fost privite la nceput ca fiind o pur
ficiune, ele au fost preluate mai trziu att de ali scriitori de Science Fiction ct i de oameni
de tiin, ca i principii de baz pentru existena unui robot. Astfel, Isaac Asimov este
recunoscut de unii ca fiind printre oamenii care au pus bazele (fie ele pur abstracte) ale tiinei
pe care astzi o numim robotic. Legile existenei unui robot sunt:

Legea 0. Un robot nu are voie s provoace vreun ru umanitii, sau prin inactivitate, s
permit vreun ru umanitii.

Legea 1. Un robot nu are voie s rneasc o persoan uman, sau s permit rnirea unei
persoane umane prin inactivitatea acestuia, cu excepia cazului cnd aceast lege contravine
cu vreo lege anterioar.

Legea 2. Un robot trebuie s respecte toate ordinele date de o persoan uman, cu excepia
acelor reguli care intr n conflict cu vreo lege anterioar.

Legea 3. Un robot trebuie s-i protejeze propria existen atta timp ct aceast activitate
nu intr n conflict cu legile anterioare.

2.1.4. Asemnri cu omul

Aa cum corpul uman are nevoie de anumite organe pentru a putea interaciona cu mediul
nconjurtor, precum i pentru a susine organismul n via, aa i orice model de robot
generalizat ar trebui s conin mai multe elemente de natur mecanic sau electric, care s
execute diverse funcii pentru ca acesta s poat opera. O prezentare sumar a unor asemnri
ntre caracteristicile unei persoane umane i ale unui model robot sunt prezentate n tabelul
urmtor.

Om Robot
Creier microprocesor, microcontroller
Ochi camere video, senzori de lumin, sonare
Urechi senzori pentru sunet, senzori cu ultrasunete
Gur Receptoare i transmitoare pentru video/date/sunet
Schelet Structur mecanic
Echilibru Senzori pentru orientare
Muchi Actuatori hidraulici/electrici/pneumatici
Mncare Surs de curent, baterii
Membre roi, picioare, enile
Tabel 1. Asemnri ntre om i robot.

Ce este un robot?

pagina 6
2.1.5. Mod de interaciune

Modul de interaciune clasic al unui robot const din trei pai, lineari, repetitivi [27]:

1. robotul simte mediul nconjurtor, adica primete informaii despre mediu prin
senzorii lui

2. robotul planific ce s fac n continuare, construind un model al lumii
nconjurtoare, bineneles lund n calcul att obiectivele pe termen scurt (un
exemplu ar fi detectarea unui obstacol) ct i obiectivele pe termen lung (spre
exemplu s ajung dintr-un anumit punct ntr-un alt punct stabilit din mediu)

3. robotul i pune n aplicare planul prin intermediul efectorilor

Figura 2.2. Modul de interaciune clasic al unui robot.

Acest model a fost predominant n timpul anilor 80. Odat cu simplitatea oferit de acesta
ns, intervin i anumite probleme care trebuie luate n calcul. Una din aceste probleme este
faptul c rigiditatea acestui model l face foarte lent. La fiecare iteraie a acestui algoritm,
trebuie realizate toate operaiile din nou i anume: citirea senzorilor, modelarea lumii
nconjurtoare, planificarea operaiilor viitoare respectiv realizarea acestora. Lent nseamn
de fapt c, la viteza cu care mediul se schimb, obiectivele planificate de la nceput vor fi greu
de atins. n final algoritmul implementat ajunge s funcioneze ca o simpl bucl, ceea ce-l
face oarecum inadecvat ntr-un mediu dinamic n continu schimbare.

O arhitectur nou propus de Brooks ntr-un seminar n 1986 [27], propunea un set de
nivele (layere), fiecare nivel coninnd un program de control care e capabil s lucreze la
viteza cu care pot apare schimbri n mediul nconjurtor (figura 2.3). Aceast arhitectur,
asigur o cale pentru a putea construi si testa incremental un sistem de control pentru roboi.
Prin calculul parelel, se mrete viteza de execuie a unei iteraii, fiecare modul devenind
autonom. Astfel se evit controlul centralizat, inteligena algoritmului fiind asignat n
totalitate planificatorului.

Efectori
Mediul nconjurtor
Senzori
P
e
r
c
e
p
i
e

M
o
d
e
l
a
r
e

P
l
a
n
i
f
i
c
a
r
e

E
x
e
c
u
i
e

C
o
n
t
r
o
l

Ce este un robot?

pagina 7

Figura 2.3. Modul de interaciune propus de Brooks.

2.1.6. Tipuri de roboi

Momentan, roboii sunt utilizai n majoritatea industriilor. Exist att de multe tipuri de
roboi folosii pentru diverse servicii, nct o enumerare a tuturor tipurilor acestora ar fi
aproape imposibil. O clasificare oarecum rudimentar a celor mai ntlnite tipuri de roboi ar
putea fi:
- androizi, roboi construii ca s mimeze comportamentul i nfiarea uman

- 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.

Efectori
Mediul nconjurtor
Senzori
Gndete obiectivele
Planific schimbrile din
lumea ambiant
Monitorizeaz schimbrile
Construiete harta
Exploreaz
Ocolete obstacole
Ce este un robot mobil?

pagina 8
2 2. .2 2. . C Ce e e es st te e u un n r ro ob bo ot t m mo ob bi il l? ?

2.2.1. Definiie. Caracteristici

Un robot mobil ar putea fi descris ca un robot care trebuie s se deplaseze ntr-un anumit
mediu, far ajutorul unui operator uman, i s execute anumite sarcini date de acesta. Deci
principala lui caracteristic este mobilitatea.

Roboii mobili au ntrebuinri multiple. De-a lungul timpului au existat i exist roboi
mobili cu funcii diverse, de la aspirator pentru cas la explorator spaial, de la vehicol ghidat
automat (AGV) folosit in industrie la robot didactic folosit doar pentru scopuri tiinifice.

Pentru a se putea deplasa n mediul ambiant, roboii mobili au nevoie de anumite
componente mecanice care sa le permit o micare precis (altfel deplasarea s-ar face haotic).
La ora actual exist mai multe de astfel componente, printre care:

roi probabil cele mai ieftine, simple i flexibile componente

enile dau o aderen mrit, greutatea robotului fiind distribuit pe o suprafa
mai mare

picioare robotul este susinut de un numr de picioare, minimum unul

perne de aer sau perne magnetice

Clasa roboilor mobili cu roi este probabil cea mai popular. Din aceast clas fac parte si
AGV-urile (Automated Guided Vehicles vehicole cu ghidare automat).

2.2.2. Exemple de roboi mobili

Lucrarea de fa nu i propune s abordeze toate tipurile de roboi mobili. Acest lucru nu
numai ca nu ar fi posibil datorit volumului extrem de documentaie necesar, dar datorit
evoluiei pe scar larg a fenomenului, chiar dac s-ar realiza acest lucru, lucrarea ar fi
depit n cateva luni de zile. De aceea, se vor prezenta cteva exemple de roboi mobili,
special alese pentru a sublinia extraordinara lor importan n secolul al XXI-lea.

Se va insista deci asupra unui singur tip de roboi mobili, i anume roboii didactici
(folosii doar pentru cercetare n domeniul universitar).
Ca i exemple vom lua roboii Pioneer de la ActivMedia Robotics pentru exemplul
roboilor didactici.

ActivMedia Robotics LCC este recunoscut ca fiind printre firmele n ascensiune rapid
n Statele Unite ale Americii n domeniul tehnologiei. Gama lor de roboi se ntinde de la
roboi industriali la roboi folosii doar in scopuri educaionale pentru cercetare. Dintre roboii
educaionali cei mai populari sunt roboii din seria Pioneer, precum i robotul Amigobot.

Robotul Pioneer a ajuns la versiunea 3, el avnd dou variante de baz: varianta cu 2+1
roi (2 motoare + 1 pentru stabilitate) cunoscut sub numele de Pioneer DX, respectiv varianta
cu 4 roi cunoscut sub numele de Pioneer AT.

pagina 9
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%.

Figura 2.4. Pioneer 3 DX, vedere frontal
(imagine (c) 2003 ActivMedia Robotics)

n varianta de baz, robotul Pioneer3 DX are 8 sonare (senzori cu ultrasunete), aezate
ntr-o configuraie de 180 grade (figura 2.6).

Senzorii pot s citeasc date corect ntre distane de 15cm i 7m.

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


pagina 10

Senzorii cel mai des folosii la roboii Pioneer sunt
senzorii cu ultrasunete. n modulul de baz al roboilor
Pioneer DX, exist 8 astfel de senzori dispui ca n
figura 2.6. Unghiul de dispunere al senzorilor este:

Figura 2.6. Dispunerea senzorilor sonar

Astfel, numerotarea ncepe din partea
dreapt cu numrul 0 i se termin n
partea stng cu numrul 7.

n figura 2.7 se prezint o schem a robotului Pioneer 3 DX, mpreun cu principalele
elemente componente.

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
Numr senzor Unghi
0 90
o

1 50
o

2 30
o

3 10
o

4 -10
o

5 -30
o

6 -50
o

7 -90
o

Roi
Sonar
Platforma
de baz

pagina 11

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)

Figura 2.9. Robotul Amigobot n versiunea tethered

Versiunea cu fir a robotului Amigobot, permite acestuia deplasarea pn la distane de
maxim 5m de calculatorul personal la care este conectat.

Wireless (ro. fr fir)

Figura 2.10. Robotul Amigobot n versiunea wireless

Versiunea fr fir a robotului Amigobot, folosete o baz radio instalat pe robot
pentru a comunica cu un calculator personal. Distana maxim pn la care comunicaia se
desfoar cu succes este de 100m. Exist dou tipuri de baze radio care se pot folosi, i
anume:
Unsecure Personal Serial Ethernet
Secure Enterprise Serial Ethernet

Diferena ntre cele dou const n faptul c varianta securizat folosete anumite
metode de criptare a datelor pentru sigurana lor.

Ce este un agent?

pagina 12
2 2. .3 3. . C Ce e e es st te e u un n a ag ge en nt t? ?

2.3.1. Definiie. Caracteristici

O definiie clasic a unui agent se apropie destul de mult de una din definiiile robotului
prezentate anterior. Conform [10], un agent este orice entitate care poate fi vzut ca
percepnd mediul prin intermediul unor senzori i acionnd asupra acestuia prin intermediul
unor efectori. Un agent uman are ochi, urechi i ali analizatori pe post de senzori, i mini,
picioare, gur i alte pri ale corpului pe post de efectori. Un agent robotizat, folosete
senzori cu ultrasunete, lasere, camere video pe post de senzori, respectiv diverse motoare pe
post de efectori. Un agent software i reprezint aciunile i percepiile ca iruri codificate de
bii.

O definiie mai complex a unui agent software [28] este: un agent
reprezint o poriune sofisticat de cod software care poate funciona
autonom, ntr-un mediu distribuit ce-i este pus la dispoziie, i care poate s
rezolve un numr de probleme mai mult sau mai puin complexe.

Una din funciile de baz ale unui agent o reprezint capacitatea acestuia
de a interaciona i comunica cu ali ageni din acelai habitat cu el, sau din
habitate vecine.

n contextul ADK ([3] i [7]), un habitat este reprezentat de o aplicaie n care un anumit
numr de ageni ruleaz.

Agenii difer de programele convenionale de calculator prin:

Agenii sunt autonomi

Agenii conin un anumit nivel de inteligen, de la reguli fixe la motoare de nvare
care le permit s se adapteze la schimbrile din mediul n care ei opereaz

Agenii nu acioneaz doar reactiv, ci uneori i proactiv

Agenii au capaciti de a se socializa, adic pot comunica cu sistemul, ali ageni din
sistem, sau cu utilizatorul

Agenii pot coopera cu ali ageni pentru a duce la bun sfrit anumite sarcini complexe,
pe care ei singuri nu le pot ndeplini

Agenii se pot muta dintr-o parte n alta n sistem, cu scopul de a accesa resurse
ndeprtate sau de a ntlni ali ageni

Ce este un agent?

pagina 13
2.3.2. Agent raional. Agent inteligent

Russell i Norvig au introdus conceptele de agent raional respectiv de agent
inteligent[22]. Un agent raional, este un agent care face ntotdeauna lucrul care trebuie fcut.
Pentru a determina succesul aciunii unui agent trebuie introdus o noiune de performan.
Msura performanei se face evident, n mod diferit de la agent la agent, important fiind ns
momentul n care se face evaluarea performanei. Pot exista ageni mai rapizi care termin
mai repede, dar apoi lenevesc, iar ali ageni care ncep mai lent, urmnd apoi o traiectorie
ascendent din punct de vedere al eficacitii. Astfel dac se face o msurare a performanei
ntr-un moment de timp prost ales, unii ageni vor ieii clar favorizai, chiar dac nu sunt cei
mai performani din sistem.

Un agent raional ideal este definit astfel: pentru fiecare secven posibil de percepii, un
agent raional ideal trebuie s efectueze orice aciune care maximizeaz performanele, pe
baza datelor provenite din secvena de percepii i din cunotinele ncorporate ale agentului.

Ce nseamn ns cunotinele ncorporate ale agentului? Dac un agent s-ar baza doar
pe cunotinele lui iniiale (ncorporate n cod, ncrcate la startarea agentului), atunci acel
agent nu ar mai avea nevoie sa fie atent la percepii, deci i-ar lipsi autonomia.
Comportamentul unui agent trebuie s fie astfel conceput nct agentul s aib capacitatea de
a nva din mediu, i de a folosi att cunotinele ncorporate n codul su, ct i de a se baza
pe experiena format de la startarea sa n sistem. Un sistem devine autonom, atunci cnd
comportamentul acelui sistem se bazeaz n mare parte pe experien, i nu pe capacitatea
creatorului su de a prevede fiecare situaie care s-ar putea petrece.

Un agent complet autonom ns, nu va avea anse prea mari de funcionare corect n
sistem. Cnd agentul este startat, experiena lui va fi nul, astfel el va trebui s acioneze
oarecum aleator. Trebuie deci stabilit un echilibru ntre autonomia dat unui agent i
cunotinele care trebuie introduse aprioric n codul agentului.

2.3.3. Clasificarea agenilor

H.Nwana [29] a clasificat agenii software dup mai multe criterii, scopul final fiind
de a observa i investiga anumite serii tipologice de ageni.

O prim clasificare se poate face dup proprietatea agenilor de mobilitate. Din acest
punct de vedere exist dou tipuri de ageni: ageni care se pot mica prin mediul reelei,
adic mobili, respectivi ageni care nu se pot deplasa, adic ageni statici

O a doua clasificare s-ar putea face dup modul de judecat al agentului respectiv.
ntlnim deci ageni care gndesc n mod deliberat, care posed un model intern simbolic
i care se angajeaz n planificri i negocieri cu scopul de a obine coordonarea cu ceilali
ageni, i de asemenea ageni reactivi, care nu conin un model intern al mediului i care
acioneaz n funcie de stimuli/rspuns de la stimuli (vezi Brooks [27] asemnare cu
modelul pentru roboi).

Un al treilea criteriu de clasificare are n vedere atributele pe care un agent ar trebui s le
manifeste. Bt Labs a identificat o list de minim trei astfel de atribute i anume:
autonomia, capacitatea de a nva i cooperarea.
Ce este un agent?

pagina 14
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.

Figura 2.11. Tipuri de ageni

Un al patrulea criteriu de clasificare s-ar putea baza pe rolul agenilor n sistemul
respectiv, spre exemplu, ageni WWW (eng. abr. World Wide Web). Acest categorie de
ageni de regul caut anumite informaii prin intermediul motoarelor de cutare gen
Google sau Altavista, fiind necesari pentru managementul vastei cantiti de informaie
existent n reeaua Internet. Acest tip de ageni se numesc ageni internet, ei putnd fi
statici, mobili, cu aciune deliberat, etc.

n al cincilea rnd, se poate include o categorie special de ageni hibrizi care combin
dou sau mai multe filozofii ntr-un singur agent.

n realitate, agenii exist ntr-un spaiu multi-dimensional. Orice reprezentare ntr-un
spaiu bidimensional sau tridimensional ar fi incomplet i inexact. Totui, pentru a fi
mai uor neles, acest spaiu multi dimensional se scrie ca o list. Astfel se pot identifica
opt tipuri de ageni:
1. ageni colaboratori (care au ca prim scop colaborarea ntre ei)
Cooperare
Capacitatea
de a nva
Autonomie
Ageni inteligeni
Ageni colaboratori
Ageni colaboratori cu capacitate
de nvare
Ageni cu capacitate de nvare
non-colaboratori
Ce este un agent?

pagina 15
2. ageni non-colaboratori cu capacitate de nvare
3. ageni mobili
4. ageni internet (eng. information agents)
5. ageni cu comportament reactiv
6. ageni hibrizi
7. sisteme de ageni heterogeni
8. ageni inteligeni

2.3.4. Structura agenilor inteligeni

Agenii inteligeni nu sunt o realitate ci o aspiraie. Se poate spune c un anumit agent
tinde ctre un model i un anumit grad de inteligen, n funcie de algoritmul implementat.
Proiectarea unui agent nseamn de fapt proiectarea programului agent: o funcie care
realizeaz transformarea ntre percepiile i aciunile agentului. Programul agent poate rula pe
orice tip de calculator, sau dispozitiv programabil (PDA spre exemplu), numit arhitectura
agent. Bineneles, programul agent trebuie s fie astfel conceput nct s poat rula pe
arhitectura aleas.

n general arhitectura agent face percepiile accesibile programului agent, ruleaz
programul agent i acioneaz efectorii pe baza alegerilor de aciune efectuate de program.
Relaia ntre ageni, programele agent i arhitecturile pe care acestea ruleaz poate fi rezumat
n urmtoarea relaie:

Agent = arhitectur agent + program agent

2.3.5. Mediul agent. Tipuri de medii agent

Mediile agent se pot clasifica dup mai multe criterii([10], [22]). Astfel se pot delimita
medii:

Accesibile/inaccesibile. Dac senzorii unui agent i ofer acestuia acces la starea complet
a mediului, atunci se spune c acel mediu este accesibil acelui agent. Un mediu devine
complet accesibil atunci cnd senzorii unui agent detecteaz toate acele aspecte relevante
n alegerea aciunii de efectuat. Evident, n cazul n care agentul nu poate accesa starea
complet a mediului, se spune despre mediul respectiv c este inaccesibil. Un mediu
accesibil este mult mai convenabil dect un mediu inaccesibil, deoarece agentul nu trebuie
s menin intern informaii despre starea lumii nconjurtoare.

Statice/dinamice. Dac n timp ce agentul ruleaz, mediul nconjurtor se schimb, atunci
se spune despre acel mediu c este dinamic pentru agentul respectiv. Dac mediul rmne
la fel, atunci se spune despre acel mediu c este static. Dac ns, mediul nu se schimb n
timp, ns performana agentului se modific, se spune despre acel mediu c este
semidinamic.

Deterministe/nedeterministe. Dac starea viitoare a mediului este complet determinat de
starea curent i de aciunile agentului, atunci se poate spune despre mediul respectiv c
este determinist. n caz contrar, mediul este nedeterminist. Un agent nu trebuie s se ocupe
Ce este un agent?

pagina 16
de incertutidine ntr-un mediu accesibil i determinist. Logic, un mediu care este
inaccesibil va aprea nedeterminist agentului.

Episodice/neepisodiec. ntr-un mediu episodic, experiena agentului este divizat n
episoade. Fiecare episod const din agentul care raioneaz i apoi acioneaz. Calitatea
aciunii depinde doar de episodul n sine. Mediile episodice sunt mai simple, deoarece
agentul nu trebuie s gndeasc nainte n timp.

Discreet/continue. Dac exist un numr clar definit, limitat, de percepii i aciuni, se
spune despre acel mediu c este discret.
Ce este un sistem multiagent?

pagina 17
2 2. .4 4. . C Ce e e es st te e u un n s si is st te em m m mu ul lt ti ia ag ge en nt t? ?

Capacitile de comunicare ale unui agent duc la conceptul de sistem multiagent. Aadar,
un sistem multiagent este o reea distribuit de ageni software, care lucreaz mpreun pentru
a rezolva anumite probleme care sunt peste capacitile individiuale ale fiecrui agent n parte.
Se poate spune c un sistem multiagent este o colecie de habitate unde agenii sunt rulai.

nainte de a studia i a clasifica sistemele multiagent, trebuie nti considerat alternativa
sistemelor centralizate pe un singur agent (eng. single-agent)[30]. Sistemele de acest gen au
un singur agent care ia toate deciziile, n timp ce restul agenilor se comport ca i clieni. Cu
toate c, aparent sistemele bazate pe un agent central ar trebui sa fie mai simple dect
sistemele multiagent, n cazul anumitor sarcini complexe, se ntmpl chiar invers. Controlul
sistemului fiind distribuit ntre mai muli ageni, fiecare agent poate fi construit mai simplu.

n general, agentul dintr-un sistem de tip centralizat single-agent se modeleaz pe el i
mediul nconjurtor. Bineneles, agentul face parte din mediu, dar putem considera c un
agent are anumite componente care nu fac parte din mediu. Agentul este o entitate
independent, cu propriile lui eluri, aciuni i cunotine. ntr-un sistem de tip single-agent,
nici o alt entitate de acest gen nu va fi recunoscut de agent. Deci chiar dac exist ali ageni
n mediul respectiv, ei vor fi considerai ca fcnd parte din mediul nconjurtor.

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.

Mediul nconjurtor
Agent
eluri
Aciuni
Cunotine
despre mediu
Efectori
Senzori
Ce este un sistem multiagent?

pagina 18
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.

Figura 2.13. Schema general a unui sistem multiagent

Mediul nconjurtor
eluri
Aciuni
Cunotine
despre mediu
Efectori
Senzori
eluri
Aciuni
Cunotine
despre mediu
Senzori Efectori
Agent
Agent
Platforme multiagent

pagina 19
2 2. .5 5. . P Pl la at tf fo or rm me e m mu ul lt ti ia ag ge en nt t

n momentul de fa exist deja implementate o mulime de platforme pentru dezvoltarea
de software bazat pe ageni. Alegerea unei platforme devine deci o operaiune sensibil, fiind
absolut necesar stabilirea din start a obiectivelor proiectului respectiv. Lucrarea de fa nu-i
propune o comparaie ntre diversele platforme existente, fiind deja destule documente
disponibile despre acest subiect (vezi [10] de exemplu).

Problema care se pune nainte de nceperea unui anumit proiect este dac este necesar s
rezolvi problemele propuse folosind ageni sau nu. Rspunsul la aceast ntrebare nu este din
pcate unul prea uor. n general, agenii pot fi folosii pentru a rezolva aproape orice
problem software, dar n unele cazuri ei nu sunt neaprat cea mai bun soluie. Un set de
ntrebri care ar putea valida soluia aleas pentru un anumit proiect este:
- Este nevoie de interconectarea unor sisteme incompatibile unul cu cellalt?
- Este nevoie de programare care implic reele de calculatoare?
- Dac da, sunt aceste calculatoare n regiuni geografice diferite?
- Ar fi posibil rezolvarea acestor probleme prin scrierea de cod autonom i mobil?
- Sunt inginerii programatori experi n limbajul de programare Java?

2.5.1. Agent Development Kit

ADK (eng. Agents Development Kit) este o platform creat de firma olandez Tryllian n
anul 1998, pentru dezvoltarea de software bazat pe ageni mobili. n concepia firmei Tryllian
[3], un agent devine mult mai puternic dac acesta este i mobil, adic dac are capacitatea
de a se muta de pe un calculator pe altul sau dintr-o reea n alta. Agenii cu astfel de
capabiliti au potenialul de a fi un element esenial n viitorul programrii distribuite.

Odat cu conceptul de mobilitate ns, intervine i riscul compromiterii securitii unui
agent. Din punct de vedere al securitii, agenii trebuie s fie incapabili s-i fac ru unul
altuia, sau s permit defectarea codului propriu. Platforma ADK ofer faciliti puternice n
aceast direcie, asigurnd att sigurana ct i securitatea agenilor n mediul n care acetia
opereaz.

Firma Tryllian explic de ce tehnologiile bazate pe ageni sunt importante: software-ul
trebuie s fie uor de neles. Oamenii nu pot gndi foarte uor n logic binar, cod main
sau noiuni abstracte zilnic. O persoan tinde s se simt confortabil dac folosete n loc de
aceste concepte, noiuni bazate pe situaii din viaa real.

n lumea ADK exist trei concepte de baz: agentul, locul n care acesta opereaz i
mesajele pe care agenii le folosesc ca s comunice ntre ei.

O metafor pentru agent ar putea fi chiar o persoana uman. Ca i un om, un agent este,
pn la un anumit punct, autonom, i este capabil de a lua anumite decizii bazate pe situaia
curent n care acesta se afl. Conceptul de loc denot locaia curent a agentului n sistem.
Un agent poate fi doar ntr-un singur loc la un moment dat, dar are de asemenea capacitatea
de a se muta dintr-un loc n altul. Oamenii vorbesc unul cu cellalt, deci comunic ntre ei.
Agenii pot de asemenea comunica prin trimitere i recepie de mesaje. Ca i persoanele
umane, agenii i pot pune unuia altuia ntrebri, pot rspunde sau spune ce nu au neles

pagina 20
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 21

Comportamentul unui agent specific aciunile i nivelul agentului de cunoatere.
Cunotinele unui agent pot fi introduse aprioric startrii agentului, dar ele pot fi
acumulate i pe timpul vieii agentului. Dezvoltatorul trebuie s construiasc n aa fel
codul agentului nct s-i permit acestuia s se comporte pe baza unei bucle de tip
percepie-raiune-aciune. Acest algoritm permite unui agent s funcioneze i s
interacioneze n mod inteligent cu un mediu care are o dezvoltare dinamic sau cu un
mediu necunoscut.

Algoritmul de tip percepie-raiune-aciune, restricioneaz agentul de la anumite aciuni.
Acesta nu va putea s mearg unde vrea el sau s fac ce vrea el, cnd vrea el. Pe baza
informaiilor din mediul su, el va trebui s i construiasc un raionament i apoi s
acioneze n consecin. Toate aceste etape ale algoritmului pot fi modelate n programul
agent relativ uor.

Astfel, etapa nti corespunde fie primirii unui mesaj de ctre agent fie a unui semnal de
ceas (eng. heartbeat, ro. btaie de inim).

Raiunea corespunde executrii unei anumite sarcini (eng. task), iar etapa de aciune
corespunde executrii unei alte sarcini de genul trimiterii unui mesaj sau mutrii agentului n
alt locaie.

Figura 2.14. Comportamentul agentului ADK

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.

Percepie
Comportamentul unui agent
Analiz Aciune
Primete
mesaj
Heartbeat Execuie
task
Trimite
mesaj
Mutare n
alt camer

pagina 22
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 task-
uri 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.

2.5.1.1. Agenii de sistem.

Un tip special de agent n reprezint agentul de sistem (eng. system agent). Diferena
dintre un agent obinuit i un agent de sistem este aceea c agentul de sistem este creat
automat de platforma agent i nu de dezvoltatorul proiectului. Caracteristicile principale ale
unui agent de sistem sunt:
Agentul de sistem este proprietatea habitatului i nu a utilizatorului

Agentul de sistem nu prsete camera n care se afl

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 23

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

2.5.1.2. Tipuri de task-uri n ADK. Modele de task-uri.

Fiecare agent pstreaz o list cu toate task-urile active la un anumit moment dat. Noi
task-uri pot fi adugate sau terse din aceast list. Un task poate primi mesaje sau heartbeat-
uri. Un task terminat va returna un cod, care va semnifica dac task-ul a euat sau dac
operaia s-a desfurat cu succes.

Task-urile se pot executa fie simultan (n paralel), fie secvenial. Ct timp un task se
execut, se poate porni un nou task, cu condiia ca noul task s nu depind de task-ul care deja
se execut. n cazurile n care task-urile trebuie executate ntr-o anumit ordine, un nou task
trebuie s atepte terminarea task-ului precedent nainte de a putea fi pornit, deoarece acesta
poate fi influenat de anumite variabile care sunt modificate de task-ul precedent.

Motivele pentru care exist un model al execuiei task-urilor sunt urmtoarele [3]:

Task-urile trebuie s fie pe ct posibil, independente unul fa de cellalt. Acest
procedeu se numete procesare asincron. Motivul din spatele acestei condiii este
c task-urile care nu trebuie s atepte dup alte task-uri pot fi executate mai repede.

Task-urile trebuie adaptate n aa fel nct s permit o procesare eficient a mesajelor.
Aproape tot comportamentul unui agent este definit n termeni de transmitere sau
recepionare de mesaje.

Task-urile trebuie s poat fi organizate ntr-un mod robust. Aceasta nseamn c
succesul sau euarea unui task trebuie s poat fi detectate i folosite ca i condiie
pentru executarea altor task-uri.


pagina 24
2.5.1.3. Implementarea modelului task-urilor.

La modul general, un agent menine informaii despre care din task-urile sale sunt active i
interesate de anumite evenimente. Un task poate defini ce se ntmpl la primirea unui anumit
tip de eveniment, poate modifica starea intern a agentului, sau poate executa o aciune ca de
exemplu trimiterea unui mesaj. Dup ce aciunea a fost planificat, task-ul rmne ntr-o stare
de ateptare pn la primirea urmtorului eveniment. Un task se poate termina la un anumit
moment i atunci el va fi ndeprtat din comportamentul agentului.
Cnd o anumit secven de aciuni este necesar, task-urile pot fi organizate cu ajutorul
unui planificator (eng. scheduler). n acest caz, un singur task poate fi executat la un
moment dat, existnd posibilitatea controlului momentului n care o anumit aciune va avea
loc. Acest lucru necesit verificarea strii task-ului.

Fiecare task are o stare intern, care este folosit pentru verificarea dac un task este deja
pornit/activ sau s-a terminat. Cnd un task se termin, starea lui intern ne va indica dac
task-ul a euat sau nu n activitatea sa.

Diagrama de stare a unui task implementat n ADK este prezentat n figura 2.15.

Un task poate avea una din urmtoarele stri:

Creat: task-ul a fost creat, dar nu a fost planificat nc

Activ: task-ul este n curs de execuie

Pe cale de a reui

Pe cale de a eua

Reuit: execuia task-ului s-a terminat cu succes

Euat: execuia task-ului s-a terminat cu eroare


pagina 25
Figura 2.15. Diagrama de stare a unui task ADK

Pe lng strile prezentate n diagrama de stare, un task se mai poate afla i n alte dou
stri convenional derivate, i anume:
Inactiv: orice alt stare diferit de starea activ

Terminat: oricare din strile reuit sau 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.

2.5.1.4. Comunicarea ntre ageni.

O important funcie a agenilor n mediul ADK o reprezint comunicarea. Pentru a
comunica, agenii trebuie s foloseasc un set comun de mesaje care pot fi nelese de toi
participanii. Setul de mesaje astfel definit formeaz un limbaj.

Dialectul implementat de ADK respect protocolul standard FIPA [8] de comunicare. Se
vor defini conceptele de baz necesare pentru actul comunicativ.

Mesajul

Mesajele sunt purttori elementari de informaie. Ele pot fi reprezentate prin obiecte
transmise de ctre unii ageni ctre ali ageni. Complexitatea lor difer de la caz la caz, ele
Task creat
Task-ul este creat
Task activ
Pe cale de a reui
Task reuit
Pe cale de a eua
Task euat
Task-ul este planificat
Task-ul reuete Task-ul eueaz
Succes confirmat Euare confirmat
T
a
s
k
-
u
l

e
s
t
e

r
e
p
l
a
n
i
f
i
c
a
t


pagina 26
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 27
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 limbajelor-
agent.

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 Semnificaie
Request Solicit receptorului s efectueze o anumit aciune.
Query-ref Solicit receptorului s rspund cu o anumit informaie.
Subscribe 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.

2.5.1.5. Parametrii mesajelor FIPA

Unii din identificatorii FIPA prezentai anterior, necesit unul sau mai multe argumente
(parametrii).

Un mesaj de tip agree trebuie s conin:
o identificatorul agentului
o aciunea asupra creia se efectueaz confirmarea

pagina 28
o condiiile n care acordul este valabil

Primul parametru este implicit, al doilea reprezint subiectul mesajului, iar al treilea
parametru poate lipsi. Un mesaj de acest tip poate de asemenea raporta rezultatele aciunii
confirmate. La nivel abstract, este mult mai logic ca aceste rezultate s fie defapt un mesaj de
tip inform, ns aceasta este o modalitate ineficient care complic inutil lucrurile i creeaz
trafic inutil n reea. Aadar este o idee mai bun s se foloseasc adresa agentului ntr-un
mesaj de tip agree ca i parametru.

Un mesaj de tip failure trebuie s conin:
o Aciunea care a euat ca i subiect al mesajului
o Motivul pentru care aceast aciune a euat

Un mesaj de tip inform trebuie s conin ca i parametru aseriunea asupra creia
informeaz.

Un mesaj de tip not-understood trebuie s conin:
o Aciunea sau evenimentul la care rspunde ca i subiect
o Motivul pentru care mesajul nu a fost neles, motiv care face parte dintr-un
set limitat de motive posibile

Un mesaj de tip query-ref trebuie s conin un descriptor bine definit al obiectului la care
se refer mesajul. ADK solicit de asemenea tipul obiectului ca subiect al mesajului.

Un mesaj de tip cancel trebuie s conin aceleai argumente ca i un mesaj de tip query-
ref.

Un mesaj de tip refuse trebuie s conin:
o Aciunea care este refuzat ca i subiect al mesajului
o Motivul refuzului aciunii

Un mesaj de tip request trebuie s conin o descriere a aciunii solicitate ca i subiect al
mesajului.

Un mesaj de tip subscribe trebuie s conin aceleai argumente ca i un mesaj de tip
query-ref.

2.5.1.6. Modele de interaciune

La ce fel de mesaje rspuns se poate atepta un agent dup ce trimite un anumit tip de
mesaj? Exist trei astfel de tipuri de conversaie care pot s apar: interaciune de tip query-
ref, interaciune de tip request, i interaciune de tip subscribe-cancel.

Se vor prezenta pe rnd cele trei tipuri de interaciuni.

A. Interaciune de tip query-ref

Primul tip de conversaie presupune c un agent (fie numele acestuia Alice), l ntreab pe
alt agent (fie numele lui Bob) despre o anumit informaie (query-ref). Acesta poate rspunde
n patru feluri:

pagina 29
Livreaz informaia (inform)
Refuz s livreze informaia (refuse)
Este pus n imposibilitate de a livra informaia (failure)
Nu nelege ce ncearc Alice s zic (not-understood)

Figura 2.16. Modul de interaciune query-ref

B. Interaciune de tip request

n urmtoarea conversaie, Alice l roag pe Bob s efectueze o anumit aciune (request),
spre exemplu s creeze o camer nou n habitat. Din nou, Bob poate rspunde n patru feluri:

Dac solicitarea este onorat, el pur i simplu trimite un mesaj n acest sens.

Iniiator Participant
Query-ref
Refuse
Failure
Inform
[euat]
[refuzat]

pagina 30

Figura 2.17. Modul de interaciune request

C. Interaciune de tip subscribe-cancel

Al treilea i ultimul tip de conversaie este i cel mai complicat. Acum Alice i cere lui
Bob s o informeze periodic despre schimbrile care pot aprea n timp. Din nou Bob poate
rspunde n cele patru feluri:

Un mesaj de tip inform repetat poate s apar n conversaia celor doi ageni. Cu toate
acestea, acest rspuns poate declana un mesaj de tip cancel. Acest mesaj nu poate fi refuzat
(dac agentul are permisiunea de a se nscrie la informaia respectiv, el ar trebui s aib i
permisiunea de a anula aceast nscriere). De asemenea, acest mesaj nu poate fi neneles.
Euarea este o posibilitate, dar acceptabil doar n acele situaii n care un agent ncearc s
anuleze o nscriere care nu a avut loc.
Request
Refuse
Failure
Inform
[euat]
[refuzat]
Agree
[confirmat]
[euat]
Failure
Inform
[confirmat]

pagina 31

Figura 2.18. Modul de interaciune subscribe-cancel

Nota: Majoritatea informaiilor prezente n acest capitol au fost preluate i adaptate din
[3], [5], [6], [8] respectiv [10].

Subscribe
Refuse
Failure
Agree
[euat]
[refuzat]
Inform
[confirmat]
[confirmat]
0..n
Cancel
[anulat]
[anulat]
Agree
Platforme robot

pagina 32
2 2. .6 6. . P Pl la at tf fo or rm me e r ro ob bo ot t

Creierul fiecrui robot este fie un microprocesor fie un microcontroler. Aceste circuite
integrate specializate au nevoie de o anumit plaftorm software ca s poat funciona. ns
nu este de ajuns o platform doar pentru creier. Un robot conine multe alte componente de
natur mecanic sau electric care sunt la fel de importante ca i microprocesorul sau
microcontrolerul.

Datorit acestui fapt, n general fiecare robot are o platform de dezvoltare software
proprie. Platforma conine att librriile necesare programrii robotului, precum i exemple,
documentaie, i n unele cazuri chiar codul surs al platformei robot.

Pentru c n lucrarea de fa subiectul principal l constituie robotul Pioneer de la firma
ActivMedia, a fost necesar gsirea unei platforme software adecvate pentru acest tip de
robot. Din fericire, pe lng alternative propus de firma ActivMedia mai exist i alte
platforme freeware pentru dezvoltare de software bazat pe roboi mobili. Astfel, lucrarea de
fa va prezenta dou platforme de acest gen, i anume: Saphira/ARIA de la firma ActivMedia
Robotics precum i alternativa open source numit Player/Stage.

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.

Platforme robot

pagina 33

Figura 2.19. Arhitectura sistem a platformei Saphira/ARIA

Toate rutinele din partea stng sunt executate sincron la fiecare 100ms. n acelai timp se
pot executa rutine utilizator asincrone ca i fire de execuie separate.

La fiecare 100ms, sistemul de operare sincron bazat pe micro-task-uri parcurge bucla n
care se afl rutinele sistem i execut toate aceste rutine pe rnd. Astfel fiecare rutin depinde
de rutine precedent, deci execuia se face sincron. Sistemul de operare are totui anumite
limitri: fiecare micro-task trebuie s se termine ntr-un interval de timp relativ foarte mic i
s predea controlul napoi sistemului. ns arhitecturile PC mai rapide de 500Mhz permit
executarea de micro-task-uri complexe cum ar fi spre exemplu un calcul probabilistic de
procesare a valorii sonarelor (senzori cu ultrasunete).

Rutinele utilizator sunt de patru tipuri:

Primul tip de rutine utilizator este bazat pe micro-task-uri, exact ca i rutinele librriilor
Saphira/ARIA, i se execut la fiecare ciclu (100ms). Astfel, acest tip de rutine utilizator
sunt privite ca o extensie a librriilor Saphira/ARIA. Ele pot accesa resursele sistem la
orice nivel, cel mai de jos nivel posibil fiind nivelul de analiz a strii robotului.

Al doilea tip de rutine se bazeaz pe limbajul Colbert, i sunt modelate sub forme de
activiti. Limbajul pentru activiti are un set complet i complex de rutine de control i o
sintax relativ uor de neles pentru utilizator. Activitile sunt un tip special de micro-
task-uri i ruleaz tot n ciclii de 100ms ca i micro-task-urile obinuite. Activitile sunt
interpretate de limbajul Colbert, utilizatorul avnd posibilitatea s le despart pe buci, s
le examineze i s le rescrie, fr s parseasc aplicaia curent. Dezvoltatorii se pot
concentra pe optimizarea algoritmilor n loc s fie preocupai de operaii de debugging a
codului efectiv.
Cod utilizator bazat pe micro-
task-uri
Comunicare low-level cu robotul
Analiz stare
Rutine de control ale aplicaiei
Sistem de operare sincron bazat
pe micro-task-uri

Rutine
utilizator
asincrone
Conexiune TTY sau TCP/IP
Platforme robot

pagina 34
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.

Figura 2.20. Arhitectura sistemului de control a platformei Saphira/ARIA
Rutine de afiare
Rutine de
interpretare ale
senzorilor
Rutine de
localizare
Markov
Interfaa de
conectare la ali
roboi
Planificator drum n
timp real bazat pe
gradient
Aciuni Colbert
Controlul
comportamentului
Controlul micrii
Harta global
Analiz stare
Spaiul local
perceptual
Legtur TCP/IP ctre ali ageni
Platforme robot

pagina 35
Arhitectura de control a sistemului Saphira/ARIA este alctuit dintr-un set de micro-task-
uri 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.

Figura 2.21. Fereastra principal Saphira reprezentnd sistemul LPS
Platforme robot

pagina 36
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.

Figura 2.22. Fereastra principal a simulatorului Pioneer

Platforme robot

pagina 37
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

Proiectul Player/Stage a ajuns la versiunea 1.4rc2 la componenta Player respectiv 1.3.3 la
componenta Stage. Aceast versiune ruleaz pe urmtoarele platforme hardware i sisteme de
operare ([14] i [15]):

Arhitectur Sistem de operare Player Suport hardware Stage
x86 Linux 2.2, 2.4 D D D
Sparc SunOS 5.6, 5.8 D N D
Sparc64 Linux 2.4 D N D
ARM SA1110
(Bitsy)
Linux 2.4.19 D D N
ARM SA1110
(iPAQ 3765)
Linux 2.4.18-rmk3 D D N
Alpha Linux 2.2 D N N
x86 FreeBSD 4.7 D N D
PowerPC OS X.1, X.2 D N D

D reprezint faptul c respectiva component a fost testat i funcioneaz.
N reprezint faptul c respectiva component nu a fost testat dar ar putea funciona.
Suport hardware se refer la componentele hardware suportate de Player, de exemplu
sicklms200.

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.
Platforme robot

pagina 38
O list cu toate componentele hardware i software suportate de ultima versiune stabil a
serverului Player este dat n tabelele 3, 4, 5.

Pe lng componentele prezentate, mai exist i alte dispozitive suportate n ultimele
versiuni instabile ale proiectului, dispozitive care sunt n curs de testare. De asemenea, Player
mai suport i o serie de algoritmi printre care amintim algoritmul AMCL (eng. Adaptive
Monte Carlo Localization, ro. Algoritmul de localizare Monte Carlo) sau algoritmul pentru
ocolirea obstacolelor VFH (eng. Vector Field Histogram).

Roboi
Firma
productoare
Nume
dispozitiv
Tipul de
conexiune
Driverul aferent
ActivMedia
Roboi
bazai pe
PSOS/P2OS
RS232
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
Botrics
Trogdor
(O-Bot)
RS232 trogdor/position
K-Team
Robotics
extension
board(REB)
RS232
reb_ir/ir, reb_position/position,
reb_power/power
RWI
B21r,
ATRV jr
Mobil
rwi_bumper/bumper, rwi_position/position,
rwi_power/power, rwi_sonar/sonar
RWI
Roboi
bazai pe
RFLEX
RS232
rflex_aio/aio, rflex_dio/dio,
rflex_position/position, rflex_power/power,
rflex_sonar/sonar, rflex_bumper/bumper
SegWay
Robotic
Mobility
Platform
Canal dual
CAN
rmpposition/position, rmppower/power
Tabel 3. Lista roboilor care funcioneaz corect cu Player versiunea 1.4rc2

Diverse
componente
hardware
Firma
productoare
Nume dispozitiv Tipul de
conexiune
Driverul aferent
SICK Senzor laser LMS 200 RS232/RS422 sicklms200/laser
SICK Senzor laser LMS 200 Mobil rwi_laser/laser
Sony Camer video EVID30 RS232 sonyevid30/ptz
CMU
Camer video
CMUcam
RS232 prin
PSOS/PS2OS AUX
p2os_cmucam/blobfinder
InterSense Intertia Cube2 IMU RS232 intertiacube2/position
MicroStrain 3DM-G IMU RS232 microstrain3dmg/position
Garmin Geko201 GPS RS232 garminmea/gps
Amtec Powercube RS232 amtecpowercube/ptz
Tabel 4. Lista dispozitivelor hardware (incomplet) care funcioneaz corect cu Player
v1.4rc2

Platforme robot

pagina 39
Diverse componente
Software
Firma productoare Nume dispozitiv Tipul de
conexiune
Driverul aferent
Jim Bruce
Color machine vision
(CMVision)
Direct nglobat
n Player
cmvision/blobfinder
ActivMedia (Paul Rybski)
ActivMedia Color
Tracking System
Socket TCP acts/blobfinder
Centrul pentru tehnologie
n domeniul sintezei
vocale, Universitatea din
Edinburgh
Festival Socket TCP festival/speech
Reed Hedges libservice discovery
Direct nglobat
n Player
service_adv
Tabel 5. Lista dispozitivelor software care funcioneaz corect cu Player v1.4rc2

O list complet cu interfeele suportate direct n Player, mpreun cu o scurt descriere a
acestora este prezentat n tabelul 6.

Valoare Numele interfeei Descriere
0x0001 Player Serverul Player
0x00FF Null Interfa nul
0x0002 Power Sistemul de putere al robotului (motoarele)
0x0003 Gripper Gripper pentru robot
0x0004 Position Baza robotului, folosit pentru localizare
0x0005 Sonar Sistem de senzori cu ultrasunete
0x0006 Laser Sistem de senzori cu laser
0x0007 Blobfinder Sistem de detecie culoare
0x0008 Ptz Camer video cu posibilitate de rotire i zoom
0x0009 Audio Detectare i generare de sunete
0x000A Fiducial Detector de obiecte marcate aprioric
0x000B Comms Sistem de comunicare general
0x000C Speech Sistem de recunoatere vocal
0x000D GPS Sistem de poziionare global (Global
Positioning System)
0x000E Bumper Sistem de senzori paraoc
0x000F Truth Sistem de localizare (folosit doar n
simulatorul Stage)
0x0010 IDARTurret Colecie de senzori IDAR
0x0011 IDAR Senzor IDAR (Infrared Data and Ranging)
0x0012 Descartes Baz robot Descartes
0x0014 DIO Intrri/Ieiri n format digital
0x0015 AIO Intrri/Ieiri in format analog
0x0016 IR Sistem de senzori n spectrul infrarou
0x0017 WiFi Plac de reea Wireless Ethernet
0x0018 Waveform Date sub format digital RAW
0x0019 Localize Sistem de localizare a robotului
0x001A Mcom Comunicare intre roboti
Platforme robot

pagina 40
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.

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.
Client Server
Stabilete conexiunea
Activeaz dispozitivul
dorit
Citete date de la
senzori
Trimite comenzi
efectorilor
bucl
Platforme robot

pagina 41

Figura 2.24. Arhitectura global a serverului Player

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.

Box - obstacol de tip fix (poate fi mutat de utilizator dar nu de robot)

Puck obstacol de tip mobil (poate fi mutat i de utilizator i de robot)

Dispozitiv fizic
D0
Dispozitiv fizic
DN
Dispozitiv
D0
Dispozitiv
DN
date
comenzi
Buffer
date D0
Buffer
comenzi DN
Buffer
comenzi D0
Buffer
date DN
Servici pentru
clieni multifir
Client
C0
Client
CN
comenzi
comenzi
date
date
date
comenzi
Platforme robot

pagina 42
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)

Pose de tip [x y a], stabilete poziia iniial a obiectului respectiv prin X i Y,
respectiv orientarea n grade fa de axa orizontal

Shape forma entitii respective, valorile admisibile fiind rect pentru dreptunghi
respectiv circle pentru cerc

Size mrimea entitii respective, de forma [sizeX sizeY]

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)

Fiducial_id de tip ntreg, stabilete un ID care va fi folosit de dispozitivul
fiducialfinder pentru a recunoate obiectul respectiv. Valorile admisibile sunt ntre 0 i
255.

Obstacle_return specific prin visible sau invisible dac entitatea respectiv va
fi tratat ca un obstacol sau nu n calea robotului.

Sonar_return specific prin visible sau invisible dac entitatea respectiv va fi
detectat de sonarele unui robot sau nu.

Vision_return specific prin visible sau invisible dac entitatea respectiv va fi
observat de o camer video sau nu.

Laser_return specific prin visible sau invisible dac entitatea respectiv va fi
observat de un senzor cu laser sau nu. O alt valoare posibil este bright care
specific faptul c entitatea va fi observat ca o lumin strlucitoare de laser.

Idar_return specific ce tip de comportament va manifesta obiectul cnd va
interaciona cu o raz IDAR (eng. Infrared Data and Ranging), valorile posibile fiind
IDARTransparent, IDARReflect, IDARReceive

Interval specific intervalul folosit pentru actualizarea modelului n interfaa grafic
n secunde. Un interval mai mic poate s mreasc fidelitatea simulrii, dar procesorul
va fi folosit ntr-un procent mai mare.

Valorile implicite pentru proprietile de mai sus sunt:
Name
Shape none
Platforme robot

pagina 43
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
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).

Platforme robot

pagina 44
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
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

GPS dispozitiv de tip GPS, momentan n teste

Gripper dispozitiv de tip gripper cu dou poziii (nchis deschis)

Laser senzor de tip laser

Fiducialfinder identific anumite obiecte n mediu, se bazeaz pe senzorul de tip
laser

Position robot cu motor diferenial

Omniposition robot de tip omnidirectional

Ptz camer video cu funcii de zoom i rotaie/translaie

Sonar list de senzori sonar

Truth dispozitiv de localizare folosit doar n simulatorul Stage

Blobfinder detector de pete de culoare

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
Platforme robot

pagina 45
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.

Platforme robot

pagina 46

Figura 2.25. Exemplu de mediu virtual construit pentru simulatorul Stage

Pentru a nelege mai bine tipul de entitate puck, se prezint n figura 2.26. un alt exemplu
de lume virtual.

Figura 2.26. Mediu construit pentru simulatorul Stage ca exemplu pentru modelul de entitate
puck
Platforme robot

pagina 47
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.

Figura 2.27. Exemplu de mediu virtual construit pentru simulatorul Gazebo

Exemplul din figura alturat arat doi
roboi de tip Pioneer 2 AT fabricai de firma
ActivMedia Robotics ntr-un mediu virtual 3D
dinamic.

Cei doi roboi sunt echipai cu senzori
laser respectivi GPS (eng. abr. Global
Positioning System).

Figura 2.28. Interacionnd cu mediul nconjurtor
Platforme robot

pagina 48

Figura 2.29. prezint un tip de robot
paianjen (hexapod) cu 18 grade de libertate.
Robotul a fost construit de ctre Dyan A. Shell
de la University of Southern California, SUA
i imit modelul robotului hexapod JPL (eng.
abr. Jet Propulsion Laboratory) al NASA.

Figura 2.29. Robotul NASA JPL de tip paianjen

Gazebo ofer o simulare realist a fizicii
obiectelor rigide: roboii pot mpinge obiecte,
le pot ridica (folosind grippere sau orice alte
dispozitive de prindere) i n general pot
interaciona cu mediul nconjurtor.

Figura 2.30. Robot de tip Segway RMP simulat n Gazebo

Toate dispozitivele suportate de simulatorul Gazebo pot fi accesate prin interfeele
standard ale serverului Player. Ca i toate celelalte componente ale proiectului Player/Stage,
simulatorul Gazebo este dezvoltat sub licen GPL.
Motorul grafic al simulatorului folosete funcii OpenGL[16]. Pentru ca mediul s
funcioneze corect, cel puin o fereastr i o camer video trebuie s fie definite n fiierul care
definete lumea virtual. Parametrii pentru fereastr definesc mrimea acesteia, titlul i modul
n care aceasta va fi manipulat. Parametrii pentru camera video definesc modelele
poligonale, rata de remprosptare a ecranului, etc.

Lumea virtual este definit ntr-un fiier n care se definesc declaraiile modelelor care se
vor folosi. Un model poate fi un robot (exemplu Pioneer 2 AT sau Segway RPM), un senzor
(exemplu SICK LMS200) sau o component static a mediului (exemplu MapExtruder). Un
exemplu de declaraie a unui robot Pioneer2AT ar fi:

<model: Pioneer2AT>
<id>robot1</id>
<pos>0 0 0.40 </pos>
<rot>0 0 45</rot>
</model: Pioneer2AT>
Platforme robot

pagina 49
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

Factory: o unealt pentru crearea de modele dinamice

GarminGPS: model de tip GPS

GroundPlane: planul care reprezint podeaua

MapExtruder: transform o imagine 2D n geometrie 3D

MonoCam: camera video color cu control adjustabil al poziiei i cu facilitate de zoom
optic

Pioneer2AT: robot ActivMedia Pioneer2AT (eng. all terain) cu 4 roi

Pioneer2DX: robot ActivMedia Pioneer2DX cu 2 roi motoare plus o roat castor

SegwayRPM: robot de tip Segway RPM (eng. Robot Mobility Platform)

SickLMS200: senzorul laser SICK

Shrimp: un robot fabricat dup modelul de robot Shrimp de la firma BlueBotics

SimpleSolid: obiecte solide de tip cutie sau sfer

SonyVID30: camer video color cu control adjustabil al poziiei i cu facilitate de
zoom optic

TruthWidget: model pentru localizare folosit de simulator

UserX11GLCamera: interfaa utilizator
Platforme robot

pagina 50
Figura 2.31 prezint o imagine captur a ecranului utilizator Gazebo.

Figura 2.31. Model al lumii virtuale n simulatorul Gazebo versiunea 0.3.0

Robotul de tip Pioneer2DX din figur are o camer video instalat. Imaginea pe care
robotul o vede este prezentat n figura 2.32.

Figura 2.32. Imagine preluat de la o camer virtual instalat pe robotul mobil.

pagina 51

3
3
.
.
M
M
e
e
m
m
o
o
r
r
i
i
u
u
j
j
u
u
s
s
t
t
i
i
f
f
i
i
c
c
a
a
t
t
i
i
v
v

Selectarea platformei robot

pagina 52
Player/Stage
JavaClient
Platforma
ADK
Alte rutine
utilizator, algoritmi
3.1. Selectarea platformei robot

innd cont de faptul c platforma de dezvoltare pentru ageni ADK este bazat pe
limbajul de programare Java de la Sun Microsystems, a fost necesar gsirea unei platforme
robot care s permit programarea n acest limbaj. De asemenea, a trebuit gsit o modalitate
de interconectare a celor dou platforme, astfel nct ele s funcioneze ca un tot unitar.

Iniial varianta aleas a fost platforma Saphira/ARIA de la firma ActivMedia Robotics,
aceast platform suportnd limbajul Java prin folosirea JNI (Java Native Interfaces).
Argumentele pentru alegerea acestei platforme au fost:
Platforma ofer un suport puternic pentru dezvoltarea aplicaiilor software,
dedicate roboilor ActivMedia Pioneer2

Existena unei documentaii abundente att n limba englez ct i n limba romn

Model bazat pe micro-task-uri

Proiectul a pornit aadar n direcia integrrii platformei Saphira/ARIA mpreun cu
platforma ADK n scopul construirii unui mediu de dezvoltare robust, bazat pe ageni
inteligeni, dedicat roboilor mobili. Din nefericire, s-a constatat c aceste dou platforme nu
se pot folosi mpreun, acest fapt fiind datorat n mare msur faptului c ambele platforme
sunt nchise din punct de vedere al codului surs (ambele platforme sunt puse la dispoziie
doar sub form de librrii, nu i de cod surs). S-a mai observat c suportul oferit de platforma
Saphira/ARIA pentru limbajul de programare Java este ntr-un stadiu incipient, multe funcii
nefiind implementate nc, sau implementate ntr-un mod eronat.

Alternativa open source, platforma Player/Stage s-a dovedit a fi singura soluie viabil
pentru implementarea proiectului n limbajul Java. Cu toate c la nceput lucrurile nu au mers
pe fgaul lor normal, proiectul Player/Stage fiind scris n limbajul C++, ca i Saphira/ARIA
de altfel, totul a revenit la normal odat cu descoperirea pachetului software numit JavaClient.

JavaClient reprezint soluia ideal pentru integrarea platformei Player/Stage cu limbajul
Java. Acest pachet software a fost conceput i dezvoltat de Maxim Batalin de la University of
Southern California din Statele Unite ale Americii. JavaClient se ofer gratis, sub licen
GPL, dezvoltatorilor de aplicaii dedicate roboilor mobili. Proiectul a ajuns la versiunea
stabil 1.3.2 i suport majoritatea dispozitivelor suportate de platforma Player/Stage. Autorul
recomand folosirea Java 2 SDK versiunea 1.4.0 sau mai nou pentru a putea compila corect
sursele proiectului.
Se prezint arhitectura sistemului rezultat n figura 3.1.

Figura 3.1. Arhitectura sistemului rezultat (ADK + Player/Stage).
R Ro ob bo ot tu ux x

pagina 53

Dup un studiu extensiv al platformei Player/Stage s-a ajuns la concluzia c aceast
platform este mai puternic dect Saphira/ARIA, permind att conectarea i utilizarea unui
numr mai mare de dispozitive hardware i software, precum i un suport foarte bun din
partea comunitii open source, proiectul fiind n continu dezvoltare.

Posibilitatea de a folosi att un simulator 3D ct i un simulator 2D complex, posibilitatea
de a folosi acelai cod scris pentru un tip de roboi i pe alte modele de roboi, precum i
faptul c arhitectura sistemului este complet deschis, fiind posibil programarea clienilor n
orice limbaj de programare posibil, au contribuit din plin la construirea arhitecturii sistem mai
sus menionate.

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 54
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.2. Imagine din procesul de boot-up al platformei Robotux



pagina 55

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).

Stabilirea obiectivelor aplicaiei

pagina 56

3.3. Proiectarea i implementarea aplicaiei

Acest capitol prezint n detaliu tot procesul de proiectare i implementare al aplicaiei. n
primul subcapitol se va discuta despre obiectivele generale ale aplicaiei, n continuare
urmnd a se prezenta tipurile de ageni care vor forma societatea multiagent. n urmtorul
subcapitol se va prezenta tipul de roboi folosit, precum i modul n care acetia au fost
conectai la aplicaia dezvoltat. Se va stabili apoi structura pachetelor software ce vor forma
aplicaia, dup care se continu cu fiecare component n parte a aplicaiei, stabilind care este
rolul i obiectivele fiecreia. n ultimul subcapitol se va prezenta modul n care toate
componentele legate mpreun reuesc s realizeze obiectivele propuse ale aplicaiei.

3.3.1. Stabilirea obiectivelor aplicaiei

Principalul obiectiv al proiectului a fost realizarea unei conexiuni ntre o platform de
ageni software i roboii fizici existeni n dotare. Scopul a fost controlarea comportamentului
unor roboi mobili folosind ageni inteligeni, precum i interconectarea mai multor roboi
mobili ca ageni ntr-un anumit sistem, fr o tipologie clasic de tipul master (server) slave
(client), care nu ar funciona n cazul n care serverul ar fi oprit.

Folosind ageni, comportamentul unui robot poate fi mult mai bine conceput i controlat.
Dispare necesitatea unui control ierarhic, cu toate c acesta poate fi implementat n continuare
dac se dorete, de preferat fiind totui controlul descentralizat, distribuit.

Pentru ca roboii s fie controlai de ageni software, este nevoie ca fiecare robot s fie
conectat la un agent. Numrul de roboi care se pot conecta pe un calculator personal d limita
superioar a numrului de ageni care pot rula pe acel calculator. Pentru ca agenii s poat
exista ntr-o anumit locaie, este nevoie ca un habitat s fie prezent i pornit n locaia
respectiv. Societatea multiagent va fi format din totalitatea habitatelor ADK care ruleaz n
diverse locaii conectate ntre ele.

Datorit faptului c obiectivul principal al proiectului a fost atins, s-a cutat apoi
soluionarea unui exemplu din viaa real, prin crearea unui scenariu plauzibil, n care o
societate multiagent care controleaz o populaie de roboi mobili ar putea fi util. Astfel, s-a
ajuns la ideea unui sistem de securitate i curenie care ar putea fi implementat folosind
roboi mobili, n orice sediu al unei firme, muzeu, banc, etc.

Obiectivul principal al proiectului a devenit realizarea unei aplicaii care s funcioneze
att n simulator ct i ntr-un mediu real. Bineneles, volumul de munc fiind mare iar
proiectul complex, sistemul construit va necesita optimizri ulterioare pentru a funciona
perfect, ns toate conceptele de baz vor fi demonstrate. Sistemul va prezenta toate avantajele
unui sistem distribuit bazat pe ageni precum i utilitatea acestora ntr-o aplicaie care
folosete roboi mobili.

Numele sistemului de securitate este Robotux, identic cu numele platformei de dezvoltare.

Structura societii multiagent

pagina 57

3.3.2. Strutura societii multiagent

Pentru a stabili tipurile de ageni necesari care mpreun vor forma societatea multiagent,
trebuie nti compus scenariul aplicaiei n detaliu.

Aplicaia dezvoltat va fi prezentat ca o alternativ la un sistem de securitate clasic.
Soluia aplicaiei se va baza pe roboi mobili i ageni software Java pentru a crea un sistem
mai eficient, mai securizat i mai ieftin dect unul deja existent.

Orice sistem de securitate clasic, folosete camere video mpreun cu senzori pentru a
monitoriza activitatea ntr-o anumit zon de interes. n timp ce acest sistem s-a dovedit a fi
bine conceput de-a lungul timpului, exist anumii factori care l predispun la erori. Unul din
aceti factori este factorul uman. Pentru ca informaiile primite din mediu s fie analizate,
este nevoie de cel puin un operator uman. Acesta are datoria de a vizualiza informaiile
primite de la camerele video n timp real, i de a observa dac se produc anumite schimbri n
mediu. Cu ct suprafaa acoperit este mai mare, cu att numrul camerelor video este mai
mare. De asemenea, cu ct suprafaa este mai neregulat, cu att numrul unghiurilor
moarte este mai mare.

Termenul de unghi mort se refer la acea poriune din mediu, unde o camer video nu
poate capta informaii datorit unor obiecte care se interpun ntre camera video i poriunea
respectiv. De asemenea pot exista zone unde distana dintre camer i poriunea respectiv
este prea mare pentru ca aceasta s poat fi observat de camer. Trebuie spus ns c, aceste
unghiuri moarte depind de poziiile n care sunt amplasate camerele video.

Astfel, dac un anumit mediu conine multe astfel de unghiuri moarte, numrul camerelor
video trebuie suplimentat pentru a acoperi i zonele cu vizibilitate zero (sau redus). Prea
multe camere video vor obosi ns un operator uman. Deci pentru a observa cu atenie
activitatea n acele zone este nevoie de mai muli operatori umani care s monitorizeze
ecranele.

Factorul uman este cel care slbete securitatea sistemului, datorit:
oboselii adunate n orele de lucru s-a constatat tiinific c operaiile de rutin
ntre anumite ore din zi, obosesc organismul uman att psihic ct i fizic

stresului operatorul uman trebuie s fie n permanen alert pentru a observa
fiecare detaliu din informaia oferit de camerele video

spiritului slab de observaie orict de atent ar fi, de multe ori exist lucruri care
scap privirii umane

Sistemul de securitate va necesita astfel cheltuieli suplimentare pentru angajai, un numr
mai mare de camere, vor trebui angajai eventual i paznici care s patruleze n anumite zone
la intervale de timp regulate. De asemenea, un factor important n securitatea unui astfel de
sistem este previzibilitatea. Fiina uman este de regul previzibil n aciunile care le
ntreprinde. Un intrus n sistem ar putea anticipa elementele previzibile ale unui paznic i
aciona n sensul evitrii contactului direct cu acesta.

Aplicaia propus, Robotux, vrea s elimine o parte din aceste probleme prin nlocuirea
sistemului clasic de securitate cu un sistem dual bazat pe ageni software i roboi mobili.

pagina 58

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 59
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

Security, implementai pe roboi mobili, scop principal asigurarea securitii
mediului

Supervisor, care va monitoriza in permanen starea sistemului i va lua deciziile
importante n anumite situaii

DBCon, agent responsabil cu asigurarea conectivitii la o baz de date precum i
cu actualizarea ei

DF, scop principal asigurarea unui serviciu de tip pagini aurii pentru ceilali
ageni

O schem de principiu a mediului este prezentat n figura 3.6. Ca i exemplu vom
presupune c mediul n care trebuie instalat sistemul poate fi acoperit de 4 roboi.


pagina 60

Figura 3.6. Un exemplu al societii multiagent Robotux

Datorit faptului c sistemul trebuie s fie distribuit, societatea multiagent va fi mprit
n habitate, iar fiecare habitat n parte va gzdui un anumit numr i tip de ageni. n eventuala
posibilitate n care mediul ce se dorete a fi protejat nu este foarte mare, este posibil
acoperirea acestuia cu 4 roboi mobili: 2 de tipul cleaner, iar 2 de tipul security. n acest caz,
structura societii multiagent ar putea arta ca i cea din figura precedent. mprirea n
habitate se face astfel:
dou habitate vor conine agenii Security i DF

dou habitate vor conine agenii Cleaner i DF

un habitat va conine agenii Supervisor, DBCon i DF

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 61

Figura 3.7. O posibil hart a lumii simulate Robotux

Pe lng acestea, n figur se mai definete i o zon de siguran maxim, prezentat sub
culoarea gri nchis. Aceast zon are urmtoarele caracteristici:
n perimetrul ei se afl anumite exponate de mare valoare, care trebuie pzite cu o
mai mare strictee

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)

nu exist nici un mijloc de dezactivare a senzorilor sau a alarmei n jurul zonei
respective, accesul acestora fiind realizat doar prin intermediul agentului
supervisor

datorit faptului c i aceast zon trebuie curat, agentul supervisor are
capacitatea de a dezactiva i activa senzorii din acea zon permind astfel accesul
n zon

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
cleaner
security
robot
robot
Zon de siguran
maxim
Exponate prezentate n muzeu
Structura pachetelor software Robotux

pagina 62
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.

3.3.3. Structura pachetelor software Robotux

Datorit faptului c platforma de baz pe care s-a construit aplicaia este limbajul Java, de
la Sun Microsystems, tot codul surs aferent a fost organizat n pachete ([9]), respectiv n
clase i interfee. ntreaga structur logic a aplicaiei este reflectat n numele acestor pachete
i relaiile existente ntre ele. Pentru a nelege aceast structur, este necesar stabilirea
ierarhiei pachetelor, acest lucru devenind critic pentru uurina n programare, depanare,
utilizare i dezvoltare ulterioar.

n acest scop au fost create mai multe pachete, fiecare cu un anumit rol n sistem i o
anumit nsemntate:
agents este pachetul principal n care se regsesc pachetele:
cleaner pachetul care conine clasele aferente agentului Cleaner
dbcon pachetul care conine clasele aferente agentului DBCon
df pachetul care conine clasele aferente agentului DF
security pachetul care conine clasele aferente agentului Security
supervisor pachetul care conine clasele aferente agentului Supervisor

algorithms este pachetul n care se regsesc urmtoarele pachete:
SpaceWanderer pachetul care conine clasele aferente algoritmului de
navigare denumit space wanderer (ro. "hoinar prin spaiu adic robotul se
va deplasa prin mediu ncercnd s gseasc spaiile cele mai largi)
Structura pachetelor software Robotux

pagina 63
WallBumping pachetul care conine clasele aferente algoritmilor de navigare
de tip wall bumping (robotul se va deplasa ntre doi perei paraleli i va
patrula n aceast zon)
WallFollowing pachetul care conine clasele aferente algoritmului de
navigare denumit wall follower (robotul se va deplasa n mediu, patrulnd n
jurul pereilor)

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 task-
urilor 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

Sintetiznd, ierarhia stabilit de pachetele aplicaiei este prezentat n figura 3.8.

Figura 3.8. Ierarhia de pachete a aplicaiei Robotux

agents
algorithms
extra
tasks
cleaner
dbcon
df
security
supervisor
SpaceWander
WallBumping
WallFollowing
Cleaner
DBCon
DF
Security
Supervisor
Proiectarea agentului DF

pagina 64

3.3.4. Proiectarea agentului DF

La proiectarea agentului DF, s-a folosit documentaia prezentat n [8] i [10]. O mare
parte din funcionalitatea DF-ului prezentat n [10] a fost preluat i adaptat n sistemul
Robotux.
Rolul agentului DF (eng. abr. Directory Facilitator) este de a asigura un serviciu de tip
pagini aurii societii de ageni. Aceasta implic meninerea unei liste de capabiliti a
agenilor, cu posibiliti de modificare i de interogare a acesteia de ctre oricare agent al
societii. De asemenea, agenii DF trebuie s fie conectai n reea, pentru a permite
interogrilor s ofere rezultate globale, care s includ i referine nspre agenii aflai la
distan.

Agentul DF trebuie s fie de ncredere, n sensul c el trebuie s se strduiasc s menin
o list complet, precis i la curent a agenilor autorizai din directorul su. Cel puin un
agent DF trebuie s fie rezident n fiecare habitat al sistemului multiagent. n sistem, poate
exista orice numr de ageni DF, i acetia se pot nregistra unii pe alii pentru a forma
federaii. Numrul agenilor DF ns nu trebuie s fie mai mic dect numrul habitatelor din
sistem.

Fiecare agent care dorete s i publice serviciile altor ageni trebuie s gseasc un DF
corespunztor i s solicite acestuia nregistrarea descrierii sale n lista agentului DF. Nu
exist obligaii suplimentare pentru agentul care s-a nregistrat. Spre exemplu, el poate refuza
o cerere de a executa un serviciu pentru care este nregistrat. De asemenea, un agent DF nu
poate garanta validitatea sau acurateea informaiei pe care o livreaz, i nici nu poate controla
ciclul de via al altor ageni.

Funcia de denregistrare are drept consecin faptul c, din momentul denregistrrii,
agentul DF nu va mai furniza agentului respectiv rspunsuri la interogri. n orice moment,
pentru orice motiv, un agent poate s solicite DF-ului modificarea descrierii sale. Descrierea
unui agent este format din adresa agentului urmat de numele serviciului oferit de agentul
respectiv.

Un agent poate cuta informaii prin interogarea DF, ns agentul DF nu garanteaz
validitatea informaiei livrate ca rspuns unei cereri de cutare, deoarece el nu impune
restricii asupra informaiilor care i se nregistreaz. Cu toate acestea, DF poate s
restricioneze accesul la informaia din directorul su i s verifice permisiunile de acces ale
agenilor care ncearc s l informeze despre schimbri ale strilor agenilor.

Astfel, funciile ndeplinite de un agent DF sunt:
Register nregistrare

Deregister denregistrare

Modify modificare

Search cutare

Agentul DF ncorporeaz un mecanism de cutare care efectueaz cutarea nti local i
apoi o extinde la ali DF, dac acest lucru este permis. Mecanismul implicit de cutare este

pagina 65
unul n adncime n federaie. Pentru scopuri specifice, constrngeri suplimentare pot fi
folosite n cutare. Cnd DF primete o cerere de cutare, el trebuie s determine dac este
nevoie s propage cutarea ctre ali ageni DF care sunt nregistrai n lista lui. Este permis
propagarea doar dac valoarea parametrului max-depth (parametru care descrie adncimea
unei cutri n federaie) este mai mare dect 1 i dac nu a primit anterior o cerere de cutare
cu acelai search-id (parametru care descrie un identificator al cutrii).

Dac propagarea este iniiat, agentul DF trebuie s respecte urmtoarele reguli:
Valoarea parametrului search-id nu poate fi schimbat i valorile parametrilor search-
id trebuie s fie unice

nainte de propagare, valoarea parametrului max-depth trebuie s fie sczut cu 1

Parametrii de cutare ai unui agent DF sunt prezentai n tabelul 7.

Numele parametrului Descriere Tip date
max-depth 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.
Integer
max-results Numrul maxim de rezultate pe care cutarea le
poate returna. O valoare negativ indic faptul
c emitorul este dispus s primeasc toate
rezultatele disponibile.
Integer
search-id Un identificator unic global cutrii. Dac acesta
nu este specificat, el va fi generat automat.
String
Tabel 7. Parametrii de cutare ai agentului DF.

n tratarea cererilor pot surveni anumite excepii. Acestea sunt:
unsupported-function agentul DF nu suport funcia cerut

missing-argument un parametru a crui prezen este obligatorie lipsete din
cererea primit de ctre DF

De asemenea, o cerere poate fi refuzat. Excepiile care pot surveni ca motiv al unei
aciuni de refuz sunt:
already-registered agentul emitor este deja nregistrat ca furnizor al serviciului
pentru care dorete s se nregistreze

not-registered agentul emitor nu este nregistrat ca furnizor al serviciului de la
care dorete s se denregistreze

Fiecare agent definete o intefa care conine constantele utilizate pentru identificarea
diverselor elemente folosite n iniializare, funcionare, schimb de mesaje, etc. Aceast
interfat se stocheaz n pachetul extra, i deriv din interfaa Constants aflat n acelai
pachet. Aceast interfa conine subinterfee care definesc grupri logice de constante
nrudite. Interfeele definite pentru agentul DF sunt:
DF constante de uz general


pagina 66
Functions identific operaiile suportate de ctre DF

Exceptions excepii ce pot apare n tratarea cererilor la DF

ContentKeys identific cheile cu care se stocheaz diveri parametrii n
mesajele schimbate ntre DF i ali ageni

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 Descriere Tip date
[subiect]
Trebuie s aib valoarea
Functions.REGISTER
String
ContentKeys.SERVICE_NAME
Numele serviciului pe care agentul
dorete s-l publice
String
ContentKeys.SERVICE_OWNER
Adresa agentului care ofer
serviciul. De notat c aceasta poate
fi diferit de adresa agentului care
emite cererea
String
Rspuns succes de tip agree
[subiect] Identic cu cel al cererii String
Rspuns euat
Performativ Motiv Descriere
refuse Exceptions.MISSING_ARGUMENT
Ambii sau unul dintre cei doi
parametrii obligatorii lipsete
failure Exceptions.ALREADY_REGISTERED
Agentul este deja nregistrat ca
furnizor al serviciului respectiv
Tabel 8. Cererea de nregistrarea a unui serviciu la agentul DF.

deregister
[subiect]
Functions.DEREGISTER
String
ContentKeys.SERVICE_NAME
Numele serviciului pe care agentul
dorete s-l publice
String
ContentKeys.SERVICE_OWNER
Adresa agentului care ofer
serviciul. De notat c aceasta poate
fi diferit de adresa agentului care
emite cererea
String

pagina 67
Rspuns euat
Ambii sau unul dintre cei doi
parametrii obligatorii lipsete
failure Exceptions.ALREADY_REGISTERED
Agentul este deja nregistrat ca
furnizor al serviciului respectiv
Tabel 9. Cererea de denregistrarea a unui serviciu la agentul DF.

search
Nume parametru Descriere Prezen Tip date
[subiect]
Functions.SEARCH
Obligatorie String
ContentKeys.SEARCH_KEY Numele serviciului cutat Obligatorie String
ContentKeys.MAX_RESULTS
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
Opional Integer
ContentKeys.SEARCH_DEPTH 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
Opional Integer
ContentKeys.SEARCH_TIMEOUT Timpul dup care cutarea
va eua, n secunde
Obligatorie Integer
ContentKeys.SEARCH_ID Identificatorul unic al
cutrii. Dac nu este
precizat, un identificator
unic se genereaz automat
i se ataeaz cutrii
nainte de propagarea n
federaie
Opional String
ContentKeys.RESULTS_COUNT Numrul de rezultate returnate. Poate fi nul Integer
ContentKeys.RESULT_PREFIX Prefixului i se ataeaz un index ntre 0 i n-
1, unde n este numrul rezultatelor, i la
cheile obinute n acest fel se afl stocate
adresele agenilor returnate ca rezultate
String
Rspuns euat

pagina 68
Unu dintre parametrii
obligatoriu lipsete
failure Exceptions.SEARCH_ALREADY_ACTIVE
Cutarea a trecut deja
prin nodul reprezentat de
acest DF n federaie
Tabel 10. Cererea de cutare a unui serviciu la agentul DF

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.

Figura 3.9. Structura registrului de servicii DF

Cutarea implic probleme la propagarea n reea. Cererea de cutare are ca parametru o
valoare numit timeout (timpul dup care cutarea va eua, n secunde). Dac timeout-ul se
propag neschimbat n reea, apare urmtorul pericol: la nivelul superior este nevoie de o
cuant pentru schimbarea mesajelor. Dac la nivelul inferior se produce un timeout, aceasta
invalideaz datorit prezenei acelei cuante de timp i cutarea la nivelul superior care altfel s-
ar fi putut s fie perfect valid. Aadar, trebuie introdus un decrement de timeout care s se
aplice nainte de propagare. Cum timeout-ul nu poate fi lsat s scad pn foarte aproape de
zero, trebuie impus i un prag minim sub care timeout-ul de cutare nu poate s scad.

n rest, evitarea propagrii infinite a cutrilor se face cu meninerea unui registru de
identificatori pentru cutrile active, i cu refuzul efecturii unei cutri care este deja activ.

Mai este nevoie de o component comportamental care s se ocupe de federarea agenilor
DF n societate. Cum n ADK exist deja un mecanism bazat pe JXTA de cutare automat a
habitatelor ntre ele, problema este relativ simpl. La intervale regulate de timp, fiecare DF i
interogheaz ARE-ul prin intermediul SA despre habitatele cunoscute, i pentru fiecare
habitat returnat, trimite cte o cerere special de tip Functions.PING. Dac agentul rspunde
el va fi adugat la registrul federaiei de DF din cadrul acestui DF.

Comportamentul agentului DF, precum i task-urile aferente acestui tip de agent sunt
prezentate n figura 3.10.

serviciu-0

serviciu-1
.
.
serviciu-n
furnizor-1, furnizor-2
furnizor-2
furnizor-1, furnizor-3, furnizor-4
registru-servicii

pagina 69

Figura 3.10. Comportamentului agentului DF

Iniializarea agentului DF se face prin apelarea task-ului general InitPropertiesTask avnd
ca parametrii att numele agentului DF (directory-facilitator), ct i anumii parametrii care
necesit a fi iniializai. Citirea valorilor parametrilor
DF.PEERS_DISCOVERY_INTERVAL,DF.PING_TIMEOUT,DF.SEARCH_TIMEOUT_D
ECREMENT respectiv DF.MINIMUM_SEARCH_TIMEOUT se face din fiierul config.xml.

Structura fiierului care conine parametrii de iniializare ai agenilor este n format
standard XML, agentului DF corespunzndu-i urmtoarele intrri:


<DF_config>

<DF_peers>20</DF_peers>

<DF_pingtimeout>5</DF_pingtimeout>

<DF_decrement>2</DF_decrement>

<DF_searchtimeout>4</DF_searchtimeout>
</DF_config>

Proprietatea DF.PEERS_DISCOVERY_INTERVAL descrie intervalul la care se
iniializeaz remprosptarea federaiei DF. Valoarea asignat n fiierul de configurare
config.xml este de 20 de secunde.

Proprietatea DF.PING_TIMEOUT descrie timeout-ul unei cereri ping la un DF ndeprtat.
Valoarea asignat n fiierul de configurare config.xml este de 5 secunde.

Proprietatea DF.SEARCH_TIMEOUT_DECREMENT descrie decrementul timeout-ului
de cutare. Valoarea asignat n fiierul de configurare config.xml este de 2 secunde.

Proprietatea DF.MINIMUM_SEARCH_TIMEOUT descrie pragul minim de timeout al
unei cereri de cutare. Valoarea asignat n fiierul de configurare config.xml este de 4
secunde.
InitPropertiesTask RegisterTask
ListenerTask
HandleDFRequestTask
PeerDiscoveryTask
SearchTask
Proiectarea agentului Cleaner

pagina 70

Dup terminarea operaiunii de iniializare a agentului DF, acesta se va nregistra ca i
agent DF n propria-i list. Urmeaz apoi a fi startate task-urile ListenerTask care se ocup
ascultarea mesajelor care vin ctre agentul DF. Fiecare mesaj care este primit va fi trecut
printr-un filtru, task-ul de ascultare va crea un task de tratare a mesajului, cu ajutorul unui
obiect primit tot la construcie, i anume un generator de task-uri de tratare, care
implementeaz interfaa tasks.HandlersFactory. Acesta specific o singur metod,
TaskcreateHandler (IncomingMessage msg), care returneaz task-ul de tratare pentru mesajul
respectiv. n acest fel, fiecare agent poate s i instaleze n comportament un generator de
task-uri de tratare personalizat, astfel nct mesajele s fie tratate corect. Acest lucru este fcut
i de ctre DF, task-ul de tratare fiind tasks.DF.HandleDFRequestTask.

Task-ul tasks.DF.HandleRequestTask se ocup direct de cererile de nregistrare,
denregistare i ping, cererile de cutare fiind trimise ctre task-ul tasks.DF.SearchTask.

Remprosptarea listei de DF-uri din federaie se face periodic, cu ajutorul task-ului
tasks.DF.PeerDiscoveryTask. Rmne de notat prezena unui alt task care nu este direct
folosit de ctre DF, dar este furnizat pentru crearea de cereri ctre acesta. Este vorba de task-
ul tasks.DFRequestTask, care implementeaz un mecanism de trimitere mesaje/ateptare dup
rspuns. Clasa furnizeaz metode statice pentru crearea de cereri specifice ctre DF-ul local,
cu diverse combinaii de parametri. De asemenea, ea furnizeaz i o metod convenabil
pentru obinerea rezultatelor unei cereri de cutare.

3.3.5. Proiectarea agentului Cleaner

Rolul agentului Cleaner este de a realiza controlul comportamental al unui robot fizic,
pentru a putea ndeplini anumite sarcini propuse pentru acesta. Sarcina de baz a unui robot
cleaner este e a parcurge pe ct posibil toat suprafaa unei incinte cu scopul de a o cura.
Robotul fizic este echipat cu un sistem de perii, i va funciona asemntor cu un aspirator
automat.

Conectarea la robot se realizeaz fizic prin conectarea unui cablu RS232 de la portul
COM1 al calculatorui ce va rula arhitectura agent, la interfaa serial RS232 a robotului
Pioneer 2.

Agentul are datoria de a implementa un algoritm de navigare a robotului n mediu. n
Robotux exist o suit de astfel de algoritmi construii, ns cel mai potrivit pentru funcia
agentului Cleaner este algoritmul SpaceWanderer. Acest algoritm se bazeaz pe informaiile
primite de la cele 8 sonare ale robotului Pioneer, i determinnd valoarea cea mai mare dintre
ele, va ncerca s se deplaseze n locaia respectiv. Practic, robotul va parcurge zonele cele
mai larg deschise, evitnd zone cu multe obstacole. Acest algoritm de navigare nu este unul
ideal pentru funciile robotului curtor, ns acest lucru va fi adresat n versiunea urmtoare
a proiectului.

Funciile principale n Robotux versiunea 0.1 ale agentului Cleaner sunt:
Nagivarea n mediu folosind unul din algoritmii implementai (cel mai bun pentru
acest caz pare a fi SpaceWanderer)


pagina 71
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 72
oprire robotul se va opri la distana maxim admisibil de subiect, i va
ncerca s-l studieze (monitorizeze) pn n momentul n care un agent security
va sosi la faa locului (eng play dead tactic)

Desigur toate aceste elemente constituie studiul comportamental al agentului Cleaner, i
vor fi mai mult dect sigur discutate i implementate ntr-o versiune ulterioar a proiectului.

Comportamentul agentului Cleaner, precum i task-urile aferente acestui tip de agent, aa
cum au fost ele implementate n Robotux versiunea 0.1, sunt prezentate n figura 3.11.

Figura 3.11. Comportamentului agentului Cleaner

Iniializarea agentului Cleaner se face prin apelarea task-ului CleanerInitTask care,
trimind ca parametru numele agentului cleaner-robot la task-ul InitPropertiesTask (prin
intermediul InitialisationTask) va iniializa parametrii corespunztori agentului. Aceti
parametrii vor fi citii din fiierul de configurare config.xml.

Structura fiierului care conine conine parametrii de iniializare ai agenilor este n
format standard XML, agentului Cleaner corespunzndu-i urmtoarele intrri:


<Cleaner_config>

<Cleaner_host>192.168.0.1</Cleaner_host>

.......
CleanerInitTask
InitialisationTask
InitPropertiesTask
ListenerTask HandleCleanerInformTask
UpdateSecurityListTask
DFRequestTask
SearchTask
SendRobotInfoTask
SendMessageTask SendMessageTask
SpaceWanderer
RegisterTask
ConnectTask

pagina 73
<Cleaner_port>6000</Cleaner_port>
<Cleaner_timeout>10</Cleaner_timeout>
<Cleaner_retries>6</Cleaner_retries>

<Cleaner_speed>150</Cleaner_speed>

<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
Proiectarea agentului Security

pagina 74
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.

3.3.6. Proiectarea agentului Security

Rolul agentului Security este de a realiza controlul comportamental al robotului de paz.
Sarcina acestuia este de a patrula n mediu cu scopul de a detecta, identifica i apoi la nevoie,
neutraliza un posibil intrus. Se presupune c robotul security este dotat cu un sistem de
senzori mai performant dect cel folosit la robotul cleaner, i de asemenea cu un posibil
sistem de neutralizare. Acest sistem de neutralizare nu va fi folosit dect n cazul n care
agentul Supervisor va lua o decizie n acest sens. Un posibil sistem de neutralizare ar putea fi
lumini puternice, sau sunete pe o anumit frecven. Nu este neaprat necesar folosirea unor
arme de foc pentru neutralizarea subiectului.


pagina 75
Ca i n cazul agentului Cleaner, conectarea la robot se realizeaz fizic prin conectarea
unui cablu RS232 de la portul COM1 al calculatorui ce va rula arhitectura agent, la interfaa
serial RS232 a robotului Pioneer 2.

Robotux versiunea 0.1 conine mai muli algoritmi implementai pentru patrulare.
Variantele mai puin complicate, numite algoritmi WallBumping, nu fac altceva dect s
mite robotul perpendicular ntre doi perei paraleli. Acest lucru se poate realiza n dou
feluri, in funcie de dotrile hardware ale robotului. Dac robotul este echipat doar cu 8
senzori sonar, atunci se va folosi algoritmul WallBumper2, care va ncerca s calibreze
robotul s se poziioneze perpendicular, ori de cte ori acesta ajunge n faa lui. Totui, la
operaia de rotire a robotului vor apare inevitabil erori, astfel nct algoritmul nu va funciona
perfect. O variant mai simpl dar mai precis se face n cazul n care robotul este echipat cu
16 sonare, n acest caz fiind posibil deplasarea acestuia perfect perpendicular.

Algoritmul cel mai complex implementat este ns WallFollower. Acesta se va deplasa n
mediu dup conturul pereilor, urmnd a detecta i ocoli obstacolele care pot s apar n faa
robotului.

Funciile principale ale unui agent Security sunt:
Nagivarea n mediu folosind unul din algoritmii implementai (cel mai bun pentru
acest caz pare a fi WallFollower)

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,
respectiv lista obiectelor cunoscute i detectate 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

Alertarea tuturor agenilor Security n cazul detectrii unui obiect cu o anumit
identitate sau cu identitate necunoscut.

Exist mai multe discuii care pot s apar cu privire la comportamentul agentului
Security ntr-un sistem complet funcional. Actualmente, codul existent n proiectul Robotux
versiunea 0.1 face ca agentul Security 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 Security.

Agentul Security trebuie s fie capabil s comunice cu ali ageni de tip Security, respectiv
Cleaner, n eventualitatea detectrii unui obstacol necunoscut n mediu. Astfel, n cazul n
care un agent de tip Cleaner detecteaz un posibil intrus, agentul Security are datoria de a
trimite n zona respectiv robotul su pentru a investiga mai bine situaia. Calitatea
identificrii obiectului va depinde de tipul i performana senzorilor folosii. Un scenariu
viabil ar putea fi utilizarea unor senzori care pot detecta n spectrul infrarou temperatura unui
obiect de la distan. Astfel se va putea verifica relativ uor dac intrusul este sau nu persoan
uman. n cazul detectrii unei persoane umane, toi agenii Security vor fi informai, i n
funcie de decizia venit din partea agentului Supervisor, acetia vor ncerca s imobilizeze
intrusul.

pagina 76
Comportamentul agentului Security, precum i task-urile aferente acestui tip de agent, aa

Figura 3.12. Comportamentului agentului Security

Iniializarea agentului Security se face prin apelarea task-ului SecurityInitTask care,
trimind ca parametru numele agentului security-robot la task-ul InitPropertiesTask (prin
intermediul InitialisationTask) va iniializa parametrii corespunztori agentului. Aceti

format standard XML, agentului Security corespunzndu-i urmtoarele intrri:

<Security_config>
<Security_host>192.168.0.1</Security_host>
<Security_port>7000</Security_port>
<Security_timeout>10</Security_timeout>
<Security_retries>6</Security_retries>

<Security_speed>150</Security_speed>

<Security_palgorithm>2</Security_palgorithm>
</Security_config>

Proprietii Security.HOSTNAME din Constants.java i corespune Security_host din
fiierul de configurare. Ea descrie numele/adresa IP a server-ului Player la care clientul care
implementeaz codul pentru robotul security se va conecta. Valoarea implicit este localhost.

Proprietii Security.PORT din Constants.java i corespune Security_port din fiierul de
configurare. Ea descrie numrul portului server-ului Player la care clientul care
implementeaz codul pentru robotul security se va conecta. Valoarea implicit este 6665.

Proprietii Security.REGISTRATION_TIMEOUT din Constants.java i corespune
Security_timeout din fiierul de configurare. Ea descrie numrul de secunde dup care cererea

Proprietii Security.REGISTRATION_RETRIES din Constants.java i corespune
Security_retries din fiierul de configurare. Ea descrie numrul de ncercri de nregistrare la

Proprietii Security.SPEED din Constants.java i corespune Security_speed din fiierul de
configurare. Ea descrie viteza n mm/s a robotului Security. Valoarea implicit este de 150 de
mm/s.

Proprietii Security.ALGORITHM din Constants.java i corespune Security_palgorithm
din fiierul de configurare. Ea descrie tipul algoritmului de navigare implementat de agentul
Security pentru robotul pe care l controleaz. Valoarea implicit este algoritmul
WallFollower.

agentul Security 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 HandleSecurityInformTask de tipul ListenerTask
care se va ocupa de tratarea mesajelor primite de agentul Security. Comportamentul simplist
Performatives.INFORM. n momentul n care un agent Security primete un alt mesaj cu
subiectul position-info care conine o list de obiecte necunoscute (n simulator acest lucru
reprezint un obiect cu un identificator ntr-un anumit interval), atunci robotul security are
datoria s se opreasc i s afieze pe ecran mesajul Possible INTRUDER found. n
versiunile urmtoare, acest comportament va fi nlocuit de o posibil deplasare a robotului
Security n locaia n care intrusul a fost descoperit. Pentru aceasta ns este nevoie de un
algoritm de navigare de tip D* sau asemntor, algoritm a crei implementare nu a fost
subiectul lucrrii de fa.

pagina 78

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, unghiul pe care se deplaseaz acesta (viteza fiind cunoscut) fa de orizontal,
respectiv o list complet de obiecte din mediu pe care robotul le detecteaz, respectiv
distana pn la acele obiecte.

Un ultim task pornit este task-ul care se ocup de navigarea robotului, n figur fiind
prezentat task-ul care implementeaz algoritmul WallFollower. Alternative posibile sunt
oricare din ceilali algoritmi, ns WallFollower se apropie cel mai mult de un comportament
ideal al agentului Security.

Robotul security este definit n fiierul robotux.world, fiier care definete lumea virtual
folosit n simulatorul Stage.
# ---[ Security Robot agent ]---
define security position (
power ()
p2at_sonar ()
truth ()
laser (
max_range 80
fiducialfinder (
range_anon 80
range_id 40
)
ptz (lens "wide" blobfinder ())
)
size [0.4 0.4]
color "red"
interval 0.01
)

Dispozitivele folosite sunt deci, 8 sonare de tip Pioneer, un dispozitiv de localizare truth
pentru simulatorul Stage, un sistem de senzori laser mpreun cu o camer video virtual
montat pe robot, respectiv accesul la motoarele robotului.

Proiectarea agentului DBCon

pagina 79

3.3.7. Proiectarea agentului DBCon

Rolul acestui agent este de a asigura o permanent legtur cu o baz de date att pentru
stocare a de informaii despre activitatea sistemului (jurnal), ct i pentru interogarea acesteia
n cazul n care se doresc anumite informaii despre starea sistemului.

Comportamentul agentului DBCon, precum i task-urile aferente acestui tip de agent, aa

Figura 3.13. Comportamentului agentului DBCon

Iniializarea agentului DBCon se face prin apelarea task-ului DBConInitTask care,
trimind ca parametru numele agentului database-connector la task-ul InitPropertiesTask
(prin intermediul InitialisationTask) va iniializa parametrii corespunztori agentului. Aceti

format standard XML, agentului DBCon corespunzndu-i urmtoarele intrri:


<DBCon_config>
<DBCon_hostname>192.168.0.1</DBCon_hostname>
<DBCon_dbname>ZeeRobots</DBCon_dbname>
<DBCon_username>Robotux</DBCon_username>
<DBCon_password>ZeeRobots</DBCon_password>
<DBCon_timeout>10</DBCon_timeout>
<DBCon_retries>6</DBCon_retries>
</DBCon_config>

Proprietii DBCon.HOSTNAME din Constants.java i corespune DBCon_host din
fiierul de configurare. Ea descrie numele/adresa IP a server-ului MySQL la care agentul
DBCon se va conecta. Valoarea implicit este 192.168.0.1.

Proprietii DBCon.DBNAME din Constants.java i corespune DBCon_dbname din
fiierul de configurare. Ea descrie numele bazei de date folosit n cadrul proiectului.
Valoarea implicit este ZeeRobots.

Proprietii DBCon.USERNAME din Constants.java i corespune DBCon_username din
fiierul de configurare. Ea descrie numele utilizatorului folosit pentru accesarea bazei de date.
Valoarea implicit este Robotux.
DBConInitTask
InitialisationTask
InitPropertiesTask
ListenerTask HandleConnectorRequestTask
RegisterTask
ConnectTask
Proiectarea agentului Supervisor

pagina 80

Proprietii DBCon.PASSWORD din Constants.java i corespune DBCon_password din
fiierul de configurare. Ea descrie parola folosit pentru accesarea bazei de date folosit n
cadrul proiectului. Valoarea implicit este ZeeRobots.

Proprietii DBCon.REGISTRATION_TIMEOUT din Constants.java i corespune
DBCon_timeout din fiierul de configurare. Ea descrie numrul de secunde dup care cererea

Proprietii DBCon.REGISTRATION_RETRIES din Constants.java i corespune
DBCon_retries din fiierul de configurare. Ea descrie numrul de ncercri de nregistrare la

agentul DBCon se va nregistra la DF-ul local prin apelarea RegisterTask.

Urmtorul pas este de a lansa task-ul HandleDBConRequestTask de tipul ListenerTask
care se va ocupa de tratarea mesajelor primite de agentul DBCon. Comportamentul simplist
Performatives.INFORM.

Baza de date la care agentul DBCon se conecteaz este gzduit de serverul de baze de
date MYSQL, folosind pachetul aplicaie mysql-connector-java-3.0.11-stable-bin.jar.

3.3.8. Proiectarea agentului Supervisor

n versiunea curent a proiectului Robotux, comportamentul agentului Supervisor nu a
fost nc implementat, dezvoltarea acestuia fiind propus pentru o versiune ulterioar.

Integrarea agenilor n sistem

pagina 81

3.3.9. Integrarea agenilor n sistem

Datorit faptului c sistemul necesita cel puin 4 roboi n varianta minimal, iar acetia nu
au existat n dotare, singura alternativ rmas a fost folosirea simulatorului Stage. Modelarea
lumii reale ntr-un mediu virtual se poate observa n figura 3.14.

Figura 3.14. Harta virtual a mediului simulat n Stage

Astfel, mediul virtual creat conine dou camere, separate ntre ele printr-un hol. Schema
reprezint n continuare o posibil variant a unei pri dintr-un muzeu. n fiecare din cele
dou camere exist mai multe exponate, reprezentate n figur prin dreptunghiuri.
Roboii au fost astfel dispui, nct s acopere ntreaga suprafa a mediului, n fiecare
camer existnd att un robot security ct i un robot cleaner.

Roboii cleaner sunt reprezentai n simulator sub form de cercuri, fiecrui robot cleaner
fiindu-i ataat un sistem de 16 sonare. Rolul lor este simplu, de a naviga n spaii largi
deschise, i de a-i transmite periodic poziia, unghiul, respectiv viteza, celorlali ageni.

Roboii security sunt reprezentai n simulat sub form de dreptungi, de culoare roie.
Fiecare robot security are ataat un sistem de 8 sonare, senzori laser, respectiv o camer
video. Imaginea pe care robotul o vede prin camera video este reprezentat n figur n
dreptunghiurile cu contur negru.

Integrarea agenilor n sistem

pagina 82
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.

Figura 3.15. Configuraia societii multiagent Robotux

Agenii DF sunt conectai ntre ei permanent, actualizarea listelor fcndu-se n funcie de
parametrul DF_peers din fiierul config.xml. Legturile ntre acetia se pot observa n figur
prin liniile nentrerupte.

Agenii Security i Cleaner comunic ntre ei pe baza adreselor aflate prin intermediul
agenilor DF. Actualizarea listelor de adrese n cadrul fiecrui agent se face la fiecare 10
secunde. Legturile ntre acetia se pot observa n figur prin liniile punctate.

De asemenea, toi agenii Security i Cleaner vor comunica agentului DBCon, starea lor
(folosind obiecte de tipul RobotInfo). Agentul Supervisor nu este folosit n proiectul Robotux
versiunea 0.1, codul acestuia urmnd a fi dezvoltat ulterior.
DF1
DF2
DF3
DF4
DF5 DBCon
Supervisor
Cleaner1
Cleaner2
Security1
Security2
Manual de instalare

pagina 83

3.3.10. Manual de instalare

Fiecare habitat necesar pentru proiectul Robotux se recomand a fi pornit de pe o
arhitectur agent distinct. Pentru a facilita acest lucru, se recomand folosirea CD-ului
bootabil al platformei Robotux bazat pe sistemul de operare Linux.

Paii necesari pornirii proiectului sunt urmtorii:
Calculator compatibil x86 (cu toate c proiectul va funciona pe oricare din
platformele care pot rula Linux cu condiia ca acestea s fie suportate i de
platforma robot Player/Stage) pe post de server, configurat corect ca server de
DHCP, Samba, DNS, cu adresa IP 192.168.0.1

Pe server trebuie instalat platforma Java SDK versiunea 1.4.0+, respectiv
Player/Stage versiunea 1.4rc2/1.3.3

Se pornete platforma Robotux de pe live CD-ul anexat proiectului pe 4
calculatoare distincte

Dac totul este corect configurat hardware, cele 4 calculatoare cu platforma
Robotux se vor conecta automat prin protocolul DHCP la server, li se vor asigna
automat adrese IP

Se pornete proiectul prin executarea scriptului /etc/Robotux.sh de pe platforma
Robotux pe cele 4 calculatoare, respectiv prin rularea habitat-ului
DBCon/Supervisor pe server

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.

Concluzii i dezvoltare ulterioar

pagina 84

4
4
.
.
C
C
o
o
n
n
c
c
l
l
u
u
z
z
i
i
i
i

i
i
d
d
e
e
z
z
v
v
o
o
l
l
t
t
a
a
r
r
e
e

u
u
l
l
t
t
e
e
r
r
i
i
o
o
a
a
r
r


pagina 85
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 86
(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.

Bibliografie

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
Bibliografie

25. Benjamin Kuipers, CS 378 Robotics course, (2004) Department of Computer
Sciences, The University of Texas at Austin
26. Isaac Asimov, The Complete Robot, (1983), Harper Collins, UK
27. Jeremy Elson, Mobile Robot Control Architectures, (1999)
28. Radu Bogdan Rusu, Liviu Miclea, Szilard Enyedi, Robotux, a multiagent robot based
security system, (2004), IEEE-TTTC International Conference on Automation,
Quality&Testing, Robotics, May 13-15 2004, Technical University of Cluj-Napoca,
Romania
29. Hyacinth S. Nwana, Software Agents: An overview, (1996), Knowledge Engineering
Review, vol. 11, no. 3, pp. 1-40, sept 1996, Cambridge University Press
30. Peter Stone, Manuela Veloso, Multiagent systems: A survey from a machine learning
perspective, (1997), Computer Science Department, Carnegie Mellon University, USA
31. Kurt G. Konolige, Saphira Software Manual v8, (2001), SRI International, Menlo
Park, California, USA

Codul surs al proiectului Robotux

pagina A.1
A An ne ex xa a A A. . C Co od du ul l s su ur rs s a al l p pr ro oi ie ec ct tu ul lu ui i R Ro ob bo ot tu ux x

a ag ge en nt ts s/ /c cl le ea an ne er r/ /C Cl le ea an ne er rR Ro ob bo ot t. .j ja av va a

package agents.cleaner;

import extra.Constants;
import algorithms.WallBumping.WallBumper1;
import algorithms.SpaceWanderer.SpaceWanderer;
import algorithms.WallFollowing.WallFollower;
import tasks.HandlersFactory;
import tasks.ListenerTask;
import tasks.UpdateCleanerListTask;
import tasks.UpdateSecurityListTask;
import tasks.Cleaner.CleanerInitTask;
import tasks.SendRobotInfoTask;
import tasks.Cleaner.HandleCleanerInformTask;
import tryllian.afc.agent.Agent;
import tryllian.afc.task.Task;
import tryllian.are.TransientAgent;
import tryllian.afc.task.TaskScheduler;
import tryllian.afc.task.TaskListener;
import tryllian.afc.task.TaskEvent;
import tryllian.afc.task.standard.LogTask;
import tryllian.afc.task.standard.DieTask;
import tryllian.afc.task.standard.PeriodicalTask;
import tryllian.afc.message.DefaultMessageFilter;
import tryllian.afc.message.Performatives;
import tryllian.afc.message.IncomingMessage;
import Javaclient.src.PlayerClient;
import Javaclient.src.PositionPlayerDevice;
import Javaclient.src.SonarPlayerDevice;
import Javaclient.src.TruthPlayerDevice;
import Javaclient.src.FiducialInterface;

import java.util.HashSet;

public class CleanerRobot extends Agent implements TransientAgent, TaskListener {

private static String AGENT_NAME = "CleanerRobot";
private static int robotSize = 400;
private PlayerClient robot;
private PositionPlayerDevice motors;
private SonarPlayerDevice sonar;
private TruthPlayerDevice truth;
private FiducialInterface fiducial;
private int SONARS[];

public CleanerRobot (String[] args) {
setName (AGENT_NAME);

setProperty (Constants.Cleaner.Cleaner_ADDRESSES, new HashSet ());
setProperty (Constants.Cleaner.Security_ADDRESSES, new HashSet ());

}

public void agentStarted () {
Task initTask = new CleanerInitTask ();


pagina A.2
Task scheduler = new TaskScheduler (new Task[] {
initTask,
});
scheduler.addTaskListener (this);
addTask (scheduler);
}

public void taskStarted (TaskEvent te) {}

public void taskEnded (TaskEvent te) {
if (te.getTask().getState().isSucceeded()) {
DefaultMessageFilter listenerFilter = new DefaultMessageFilter ();
listenerFilter.setPerformative(Performatives.INFORM);
HandlersFactory factory = new HandlersFactory () {
public Task createHandler (IncomingMessage msg) {
return new HandleCleanerInformTask (msg);
}
};
Task listener = new ListenerTask (listenerFilter, factory);
addTask (listener);

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();
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));
fiducial, "cleaner"), refreshInterval, false));
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.3
sonar, truth, SPEED, robotSize), 1, false));
break;
}
case 1:{
addTask (new PeriodicalTask (new WallFollower (robot, motors,
break;
}
case 2:{
addTask (new PeriodicalTask (new SpaceWanderer(robot, motors,
break;
}
default:{
break;
}
}
} else {
addTask (new TaskScheduler (new Task[] {
new LogTask ("Could not initialise. Dying."),
new DieTask ()
}));
}
}
}

a ag ge en nt ts s/ /d db bc co on n/ /D Da at ta ab ba as se eC Co on nn ne ec ct to or r. .j ja av va a

package agents.dbcon;

import tasks.DBCon.HandleConnectorRequestTask;

import tasks.DBCon.DBConInitTask;

public class DatabaseConnector extends Agent implements TransientAgent {

private static String AGENT_NAME = "DatabaseConnector";

public DatabaseConnector (String[] args) {
}

Task initTask = new DBConInitTask ();

// listenerFilter.setPerformative(Performatives.REQUEST);

pagina A.4
return new HandleConnectorRequestTask (msg);
}
};


Task onInitFailure = new TaskScheduler (new Task[] {
new DieTask ()
});

TaskScheduler sequencer = new TaskScheduler();
sequencer.addTask (initTask, listener, onInitFailure);
sequencer.addTask (listener, null, null);
sequencer.addTask (onInitFailure, null, null);
addTask (sequencer);
}

}

a ag ge en nt ts s/ /D DF F/ /D Di ir re ec ct to or ry yF Fa ac ci il ll li it ta at to or r. .j ja av va a

package agents.df;

import tasks.InitPropertiesTask;
import tasks.DF.HandleDFRequestTask;
import tasks.DF.PeerDiscoveryTask;

import tryllian.afc.task.TaskGroup;
import tryllian.afc.task.standard.RegisterTask;

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.5
setProperty (Constants.DF.SERVICES_REGISTRY, new HashMap ());
}

// Start [InitPropertiesTask] and [RegisterTask] in parallel
TaskGroup initialiser = new TaskGroup (new Task[] {
new InitPropertiesTask ("directory-facilitator", new String[] {
Constants.DF.PEERS_DISCOVERY_INTERVAL,
Constants.DF.PING_TIMEOUT,
Constants.DF.SEARCH_TIMEOUT_DECREMENT,
Constants.DF.MINIMUM_SEARCH_TIMEOUT,
}),
new RegisterTask (Constants.DF_SERVICE_NAME)
});
initialiser.addTaskListener (this);
addTask (initialiser);
}

// Overrides TaskListener's taskStarted() method

// Overrides TaskListener's taskEnded () method

//init the DF behaviour
DefaultMessageFilter listenerFilter = new DefaultMessageFilter();
listenerFilter.setPerformative(Performatives.REQUEST);
HandlersFactory factory = new HandlersFactory() {
public Task createHandler(IncomingMessage msg) {
return new HandleDFRequestTask(msg);
}
};

addTask (new ListenerTask (listenerFilter, factory));
int peersDiscoveryInterval = new Integer (getProperty
(Constants.DF.PEERS_DISCOVERY_INTERVAL).toString()).intValue();
addTask (new PeriodicalTask (new PeerDiscoveryTask (), peersDiscoveryInterval,
false));
} else {
// Start [LogTask] and after it finishes start [DieTask]
new DieTask ()
}));
}
}

}

a ag ge en nt ts s/ /s se ec cu ur ri it ty y/ /S Se ec cu ur ri it ty yR Ro ob bo ot t. .j ja av va a

package agents.security;

import algorithms.WallFollowing.WallFollower;

pagina A.6
import tasks.UpdateCleanerListTask;
import tasks.UpdateSecurityListTask;
import tasks.SendRobotInfoTask;
import tasks.Security.SecurityInitTask;
import tasks.Security.HandleSecurityInformTask;


public class SecurityRobot extends Agent implements TransientAgent, TaskListener {

private static String AGENT_NAME = "SecurityRobot";
private static int robotSize = 400;
private FiducialInterface fiducial;


public SecurityRobot (String[] args) {

setProperty (Constants.Security.Cleaner_ADDRESSES, new HashSet ());
setProperty (Constants.Security.Security_ADDRESSES, new HashSet ());
}

Task initTask = new SecurityInitTask ();

Task scheduler = new TaskScheduler (new Task[] {
initTask
});
scheduler.addTaskListener (this);
addTask (scheduler);
}


setProperty(Constants.Security.INTRUDER_ALERT, "!go!");


pagina A.7
return new HandleSecurityInformTask (msg);
}
};

addTask (listener);

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)
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));
fiducial, "cleaner"), refreshInterval, false));
fiducial, "security"), refreshInterval, false));

int algorithm = new Integer (getProperty
(Constants.Security.ALGORITHM).toString()).intValue();
switch (algorithm) {
case 0:{
break;
}
case 1:{
break;
}
case 2:{

pagina A.8
addTask (new PeriodicalTask (new WallFollower (robot, motors,
break;
}
default:{
break;
}
}
} else {
new DieTask ()
}));
}
}
}

a ag ge en nt ts s/ /s su up pe er rv vi is so or r/ /S Se ec cu ur ri it ty yR Ro ob bo ot t. .j ja av va a

package agents.supervisor;

import tasks.Supervisor.SupervisorInitTask;

public class SuperAgent extends Agent implements TransientAgent {

public SuperAgent () {
setName ("Supervisor Agent");
}

Task initTask = new SupervisorInitTask ();
addTask (initTask);
}
}

a al lg go or ri it th hm ms s/ /S Sp pa ac ce eW Wa an nd de er re er r/ /S Sp pa ac ce eW Wa an nd de er re er r. .j ja av va a

package algorithms.SpaceWanderer;

import Javaclient.src.Beacon;
import tryllian.afc.task.DefaultTask;

public class SpaceWanderer extends DefaultTask {

private int beaconCount;

pagina A.9
private Beacon[] beacons;
private int robotSize;
private int speed;
private int SPEED = speed;
private int left, right;
private int rotate = 0;
int next = 0;

public SpaceWanderer (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 Space Wanderer algorithm.
*/
public void handleHeartbeat () {
SONARS = sonar.getRanges();
int lefts, rights;
if (SONARS[1] < SONARS[2])
lefts = SONARS[1];
else
lefts = SONARS[2];
if (SONARS[6] < SONARS[5])
rights = SONARS[6];
else
rights = SONARS[5];

if ((lefts < (robotSize + rotate * 200)) || (rights < (robotSize + rotate * 200))) {
if (rotate ==0 ) {
if (SONARS[0] > SONARS[7]) {
left = -50;
right = 50;
rotate =1;
} else {
left = 50;
right = -50;
rotate =1;
}
}
} else {
rotate =0;
left = 100;
right = 100;
if (left < right ) {
left += 40;
if (SONARS[7] > SONARS[0])
left += 20;
if ((lefts < 700) && (rights > 700))
left += 30;
} else {
right += 40;
right += 20;

pagina A.10
if ((lefts < 700) && (rights > 700))
right += 30;
}
}
motors.setSpeed ((left + right) / 2, (int)((left - right) * 180 / 753.9));
}
}

a al lg go or ri it th hm ms s/ /W Wa al ll lB Bu um mp pi in ng g/ /W Wa al ll lB Bu um mp pe er r1 1. .j ja av va a

package algorithms.WallBumping;


public class WallBumper1 extends DefaultTask {

private int beaconCount;
private Beacon[] beacons;
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;
}

/*
* Simple WALL BUMP algorithm. Makes use of 4 sonar sensors (3, 4, 11, 12), but needs a robot with
16 sonar sensors.
*/

if (wallInFront()) {
left = false;
}
if (wallInBack()) {
left = true;
}

if (left) SPEED = speed;

pagina A.11
else SPEED = -speed;

motors.setSpeed (SPEED, 0);
}

public boolean wallInFront () {
return ((SONARS[3] <= robotSize) || (SONARS[4] <= robotSize));
}

public boolean wallOnSide () {
}

public boolean wallInBack () {
}

}

a al lg go or ri it th hm ms s/ /W Wa al ll lB Bu um mp pi in ng g/ /W Wa al ll lB Bu um mp pe er r2 2. .j ja av va a

package algorithms.WallBumping;



public class WallBumper2 extends DefaultTask {

private int SPEED;
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;
}

/*
* 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.12
*/
// update readings from the sonars

if ((wallInFront()) || (wallOnSide()))
bumped = true;

motors.setSpeed(SPEED, 0);

int sonarLeft = SONARS[0];
int sonarRight = SONARS[7];

if (bumped) {
if (!calibrated) calibrateFront ();
int turn = 0;
if (SONARS[0] < SONARS[7]) {
if (SONARS[7] > robotSize) {
turn = -TURN;
}
} else {
if (SONARS[0] > robotSize) {
turn = TURN;
}
}

motors.setSpeed (0, turn);

count = System.currentTimeMillis();
do {
} while ((System.currentTimeMillis() - count < 1000 * 9) ||
(Math.abs (SONARS[0] - sonarRight) > 30) &&
(Math.abs (SONARS[7] - sonarLeft) > 30));
bumped = false;
calibrated = false;
count = 0;
}
}

private void calibrateFront () {
int turnrate = 0;
int counter = 0;
while ((Math.abs (SONARS[3] - SONARS[4]) > 10) || (counter > 8)) {
// if not good after 8 calibrations, no point in going any further - avoiding infinite loops
counter++;
System.err.print("Calibrate front -> "); printSensorValues (0);
turnrate = -5;
else
turnrate = 5;
motors.setSpeed (0, turnrate);
calibrated = true;
}
}

public boolean wallInFront () {
}

pagina A.13

public boolean wallOnSide () {
}

public boolean wallInBack () {
}

private void printSensorValues (int i) {
System.err.println (i+0 + "=" + SONARS[i+0] +
"/" + (i+1)+ "=" + SONARS[i+1] +
"/" + (i+2)+ "=" + SONARS[i+2] +
"/" + (i+3)+ "=" + SONARS[i+3] +
"/" + (i+4)+ "=" + SONARS[i+4] +
"/" + (i+5)+ "=" + SONARS[i+5] +
"/" + (i+6)+ "=" + SONARS[i+6] +
"/" + (i+7)+ "=" + SONARS[i+7]);
}

}

a al lg go or ri it th hm ms s/ /W Wa al ll lF Fo ol ll lo ow wi in ng g/ /W Wa al ll lF Fo ol ll lo ow we er r. .j ja av va a

package algorithms.WallFollowing;



public class WallFollower extends DefaultTask {

private int SPEED;
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.14
this.robot = r;
this.motors = m;
this.sonar = s;
this.truth = t;
this.SPEED = speed;
}

public void taskStarted () {
try {
if (getAgentContext().getProperty
(Constants.Security.INTRUDER_ALERT).toString().startsWith("!stop!")) {
motors.setSpeed (0, 0);
return;
}
} catch (Exception e) {}

adjust ();
if (!gotWall) find();
else {
if (!avoid(followingLeftWall)) {
if (followingLeftWall) {
if ((SONARS[0] > robotSize) && (SONARS[1] > robotSize))
count++;
else
count = 0;

if (count >= 150) {
find();
count = 0;
}
}
follow(followingLeftWall);
}
else
count = 0;
}
}

public void adjust () {
if (needAdjustment) {

int min = 0;
for (int i=0; i<8; i++) {
if (SONARS[i] < SONARS[min])
min = i;
}

int angle = 0;
switch (min) {
case 0: angle = 90; break;
case 4: angle = -10; break;
case 7: angle = -90 ;break;
}

pagina A.15
motors.setSpeed(0, angle);
needAdjustment = false;
}
}

public void find () {
if (!wallNearby ())
motors.setSpeed (SPEED, 0);
else {
align ();
}
}

public boolean wallNearby () {
for (int i=0; i<8; i++) {
if (SONARS[i] < MIN)
for (int x=0; x < 10; x++) motors.setSpeed (-20, 0);
if ((SONARS[i] <= robotSize) && (SONARS[i] >= MIN))
return true;
}
return false;
}

void align () {
if (needAlignment) {

int tolerance = 30;

if (SONARS[0] < (robotSize + tolerance)) {
SONARS = sonar.getRanges ();
motors.setSpeed (0,20);
} else {

int prev = SONARS [0];

if (SONARS[0] <= prev) {
doneAlignment = true;
}
if (doneAlignment) {
motors.setSpeed (0, -20);
needAlignment = false;
gotWall = true;
}
}
}
}

public void follow (boolean leftWall) {


pagina A.16
int a = SONARS [0] + 110;
int b = SONARS [1] + 110;
double C = Math.toRadians ( 46 );

// cosinus law
double c = Math.sqrt ( (a*a) + (b*b) - (2*a*b*Math.cos(C)) );

// sinus law
double B = Math.toDegrees( Math.asin ((b/c) * Math.sin (C)) );

double alpha = Math.toRadians (180 - B);

double distance2Wall = a * Math.sin (alpha);
distance2Wall -= 410;

distance2Wall = Math.min(distance2Wall, SONARS[0]);

double theta = B - 90;
double e = distance2Wall - robotSize;
double angle = motors.yaw;
double v = SPEED;
double k_e = -0.21;
double k_theta = 0;

if (SONARS[2] < 2*robotSize) {
motors.setSpeed (SPEED, -12);
return;
}

double w = (-1 * k_theta*theta) - (k_e * e);
w = w / 2;

if (w < 0) {
if (Math.abs (w) > 12)
w = -12;
} else {
if (w > 12)
w = 12;
}

if (w < 0) {
if (!movingLeft) count1 = 0;
count1++;
movingLeft = true;
if (count1 == 10) w = 0;
if (count1 >= 20) count1 = 0;
} else {
if (movingLeft) count1 = 0;
count1++;
movingLeft = false;
if (count1 == 10) w = 0;
if (count1 >= 20) count1 = 0;
}
motors.setSpeed(SPEED, (int)w);
}

public boolean avoid (boolean leftWall) {

pagina A.17

boolean bumped = false;

for (int i=0; (i<8) && (!bumped); i++) {
if ((i <=2 ) && ((SONARS[i] <= LEAST) && (SONARS[i] >= MIN)) ||
(i>2) && ((SONARS[i] <= LEAST) && (SONARS[i] >=MIN))) {

bumped = true;
back_Up ();

if ((i >= 3) || leftWall)
motors.setSpeed(0, -20);
else
break;
} else
if (((i==1) || (i==2)) && ((SONARS[i] <= BUMP) &&
(SONARS[i] >= MIN)) ||
((i == 3) || (i == 4)) && ((SONARS[i] <= BUMP) &&
(SONARS[i] >= MIN))) {

bumped = true;
if ((i >=3 ) || leftWall)
motors.setSpeed ((int)(SPEED*0.75), -20);
else
motors.setSpeed ((int)(SPEED*0.75), 20);
break;
}

}
return bumped;
}

public void back_Up () {
for (int i=0; i < 20; i++) {
motors.setSpeed (-30, 0);
}
}

}

e ex xt tr ra a/ /C Co on ns st ta an nt ts s. .j ja av va a

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.18
public static final String SEARCH_TIMEOUT_DECREMENT= "search-timeout-decrement";
public static final String MINIMUM_SEARCH_TIMEOUT = "minimum-search-timeout";
public static final String PEERS_REGISTRY = "peers-registry";
public static final String ACTIVE_SEARCHES = "active-searches";
public static final String SERVICES_REGISTRY = "registered-services";
}

public static interface Cleaner {
public static final String PORT = "6665";
public static final String ROBOT = "player-client";
public static final String MOTORS = "position-player-device";
public static final String SONAR = "sonar-player-device";
public static final String TRUTH = "truth-player-device";
public static final String SPEED = "cleaner-speed";
public static final String ALGORITHM = "patrol-algorithm";
public static final String DBCon_ADDRESS = "dbcon-address";
public static final String Supervisor_ADDRESS = "supervisor-address";
public static final String Cleaner_ADDRESSES = "cleaner-addresses";
public static final String Security_ADDRESSES = "security-addresses";
}

public static interface Security {
public static final String PORT = "6665";
public static final String ROBOT = "player-client";
public static final String MOTORS = "position-player-device";
public static final String SONAR = "sonar-player-device";
public static final String TRUTH = "truth-player-device";
public static final String FIDUCIAL = "fiducial-player-device";
public static final String SPEED = "security-speed";
public static final String ALGORITHM = "patrol-algorithm";
public static final String INTRUDER_ALERT = "intruder-alert";
public static final String Supervisor_ADDRESS = "supervisor-address";
public static final String Cleaner_ADDRESSES = "cleaner-addresses";
public static final String Security_ADDRESSES = "security-addresses";
}

public static interface Supervisor {
}

public static final String DF_SERVICE_NAME = "directory-facilitator";
public static final String JNDI_SERVICE_PREFIX = "adk/.:/tryllian/services/";
public static final String JNDI_DF_SERVICE_NAME = JNDI_SERVICE_PREFIX +
DF_SERVICE_NAME;
public static final String SERVICE_SEARCH_RETRIES = "12"; // 12 attempts
public static final String SERVICE_SEARCH_TIMEOUT = "5"; // 5 seconds between attempts
public static final String SERVICE_REFRESH_INTERVAL = "30"; // 30 seconds

public static interface Functions {
public static final String REGISTER = "register";
public static final String DEREGISTER = "deregister";
public static final String SEARCH = "search";

pagina A.19
public static final String PING = "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 = "service-name";
public static final String SERVICE_OWNER = "service-owner";
public static final String SEARCH_ID = "search-id";
public static final String SEARCH_KEY = "search-key";
public static final String SEARCH_DEPTH = "search-depth";
public static final String SEARCH_TIMEOUT = "search-timeout";
public static final String MAX_RESULTS = "max-results";
public static final String RESULTS_COUNT = "results-count";
public static final String RESULT_PREFIX = "result-";
}

}

e ex xt tr ra a/ /D DF FN No ot tF Fo ou un nd dE Ex xc ce ep pt ti io on n. .j ja av va a

package extra;

public class DFNotFoundException extends Exception {

public DFNotFoundException () {
super ("Directory-Facilitator agent not found within habitat");
}
}

e ex xt tr ra a/ /G Ge en ne er ri ic cI In nf fo o. .j ja av va a

package extra;

public abstract class GenericInfo implements java.io.Serializable {
}

e ex xt tr ra a/ /G Gu ui id de el li in ne es s. .j ja av va a

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.20
public Guidelines (short id, short range, short bear, short orient, short rangeu, short bearu, short orientu)
{
this.beaconID = id;
this.range = range;
this.bearing = bear;
this.orientation = orient;
this.rangeUncertain = rangeu;
this.bearingUncertain = bearu;
this.orientationUncertain = orientu;
}
}

e ex xt tr ra a/ /R Ro ob bo ot tI In nf fo o. .j ja av va a

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.21
t ta as sk ks s/ /C Cl le ea an ne er r/ /C Cl le ea an ne er rI In ni it tT Ta as sk k. .j ja av va a

package tasks.Cleaner;

import tasks.InitialisationTask;
import tasks.DFRequestTask;
import tasks.ServiceSearchTask;
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();}


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.22
registration,
serviceSearch
});

sequencer.addTaskListener(this);
return;
}

if ( (te.getTask() instanceof TaskScheduler ) && (te.getTask().getState().isSucceeded())) {
getAgentContext().setProperty(
Constants.Security.DBCon_ADDRESS,
((AgentAddress[])DBConSearcher.getFinishValue())[0]);
Constants.Security.Supervisor_ADDRESS,
((AgentAddress[])SuperSearcher.getFinishValue())[0]);
}
if (te.getTask ().getState().isSucceeded()) succeed ();
else fail (te.getTask().getFinishValue ());
}
}

t ta as sk ks s/ /C Cl le ea an ne er r/ /C Co on nn ne ec ct tT Ta as sk k. .j ja av va a


import java.net.ConnectException;
import java.net.UnknownHostException;
import java.io.IOException;

public class ConnectTask extends DefaultTask implements TaskListener {

private static final char PLAYER_ALL_MODE = 'a';
private String hostname;
private String port;


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.23
public void taskStarted (TaskEvent te) { }

try {
// load the driver
PlayerClient robot = new PlayerClient (hostname, new Integer (port).intValue());
PositionPlayerDevice motors = robot.requestPosition(PLAYER_ALL_MODE);
SonarPlayerDevice sonar = robot.requestSonar(PLAYER_ALL_MODE);
TruthPlayerDevice truth = robot.requestTruth(PLAYER_ALL_MODE);

context.setProperty(Constants.Cleaner.ROBOT, robot);
context.setProperty(Constants.Cleaner.MOTORS, motors);
context.setProperty(Constants.Cleaner.SONAR, sonar);
context.setProperty(Constants.Security.TRUTH, truth);
succeed ();
} catch (ConnectException ce) {
addTask (new LogTask ("EXCEPTION! = " + ce.toString()));
} catch (UnknownHostException uhe) {
addTask (new LogTask ("EXCEPTION! = " + uhe.toString()));
} catch (IOException ioe) {
addTask (new LogTask ("EXCEPTION! = " + ioe.toString()));
}
}

}

t ta as sk ks s/ /C Cl le ea an ne er r/ /H Ha an nd dl le eC Cl le ea an ne er rI In nf fo or rm mT Ta as sk k. .j ja av va a


import extra.RobotInfo;
import extra.GenericInfo;
import tasks.HandleMessageTask;
import tryllian.afc.message.object.ObjectMessage;

public class HandleCleanerInformTask extends HandleMessageTask {

public HandleCleanerInformTask (IncomingMessage msg) { super (msg);}

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.24
}
}
}

t ta as sk ks s/ /D DB BC Co on n/ /C Co on nn ne ec ct tT Ta as sk k. .j ja av va a

package tasks.DBCon;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class ConnectTask extends DefaultTask {

public ConnectTask () { super (); }


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 ();
}
}
}

t ta as sk ks s/ /D DB BC Co on n/ /D DB BC Co on nI In ni it t. .j ja av va a



pagina A.25
//import tryllian.afc.task.standard.LogTask;

public class DBConInitTask extends InitialisationTask {

private static final String DBCon_SERVICENAME = "database-connector";

public DBConInitTask () {
super (DBCon_SERVICENAME,
new String[] {
Constants.DBCon.HOSTNAME,
Constants.DBCon.DBNAME,
Constants.DBCon.USERNAME,
Constants.DBCon.PASSWORD,
Constants.DBCon.REGISTRATION_TIMEOUT,
Constants.DBCon.REGISTRATION_RETRIES,
});
}

super.taskStarted();
}


int timeoutValue = new Integer (getAgentContext().getProperty
(Constants.DBCon.REGISTRATION_TIMEOUT).toString()).intValue();
int retriesValue = new Integer (getAgentContext().getProperty
(Constants.DBCon.REGISTRATION_RETRIES).toString()).intValue();

(DBCon_SERVICENAME,
getAgentContext().getMyAddress().toString(), timeoutValue), retriesValue);

new ConnectTask (),
new UpdateDatabaseTask (),
registration
});

return;
}

}
}

t ta as sk ks s/ /D DB BC Co on n/ /H Ha an nd dl le eC Co on nn ne ec ct to or rR Re eq qu ue es st tT Ta as sk k. .j ja av va a



pagina A.26

public class HandleConnectorRequestTask extends HandleMessageTask {

public HandleConnectorRequestTask (IncomingMessage msg) { super (msg); }

if (a.beaconCount > 0) {
System.err.println ("Detected objects list:");
for (int i=0; i < a.beaconCount; i++)
System.err.println (" ---> Object with ID=" +
a.beacons[i].beaconID + " at " +
a.beacons[i].range + "cm");
}
}
}
}

try {
return null;
}
}

}

t ta as sk ks s/ /D DB BC Co on n/ /U Up pd da at te eD Da at ta ab ba as se eT Ta as sk k. .j ja av va a


import java.sql.Connection;
import java.sql.Statement;
import java.sql.SQLException;

public class UpdateDatabaseTask extends DefaultTask {

public UpdateDatabaseTask () { super (); }

Connection con = (Connection)getAgentContext ().getProperty
(Constants.DBCon.DATABASE_CONNECTION);
try {
Statement stmt = con.createStatement();
// stmt.executeUpdate ("INSERT");
} catch (SQLException e) {

pagina A.27
fail (e);
}

succeed ();
}
}

t ta as sk ks s/ /D DF F/ /H Ha an nd dl le eD DF FR Re eq qu ue es st tT Ta as sk k. .j ja av va a

package tasks.DF;

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.Set;

public class HandleDFRequestTask extends HandleMessageTask {

public HandleDFRequestTask (IncomingMessage msg) { super (msg); }

// 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));
addFinalTask (new LogTask ("[" + serviceOwner + "] already

pagina A.28
registered as provider of service [" + serviceName + "]."));
return;
}

providers.add (serviceOwner);

try { msg.reply (new Agree (msg.getSubject()));
addFinalTask (new LogTask ("Registered [" + serviceOwner + "] as provider
of service [" + serviceName + "]."));
return;
} else {
// deregister request
if ((providers == null) || !providers.contains(serviceOwner)) {
try { msg.reply (new Failure
(msg.getSubject(),Constants.Exceptions.NOT_REGISTERED));
addFinalTask (new LogTask ("[" + serviceOwner + "] is not
registered as provider of service [" + serviceName + "]."));
return;
}

providers.remove(serviceOwner);

try { msg.reply(new Agree (msg.getSubject()));
addFinalTask (new LogTask ("Deregistered " + serviceOwner + "] from
providers of service [" + serviceName + "]."));
return;
}
}

// search request
if (msg.getSubject().equals(Constants.Functions.SEARCH)) {
addFinalTask (new SearchTask (msg));
return;
}

// ping request
if (msg.getSubject().equals(Constants.Functions.PING)) {
try {
msg.reply (new Agree (msg.getSubject()));
// addFinalTask (new LogTask ("Replied to ping by [" + msg.getSender() + "]."));
return;
}

try { msg.reply (new Refuse (msg.getSubject(),
Constants.Exceptions.UNSUPPORTED_FUNCTION));
addFinalTask (new LogTask ("Unsupported function [" + msg.getSubject() + "] in request
from [" + msg.getSender() + "]."));
}
}

t ta as sk ks s/ /D DF F/ /P Pe ee er rD Di is sc co ov ve er ry yT Ta as sk k. .j ja av va a

package tasks.DF;


pagina A.29
import tryllian.address.IDReference;

import java.util.Iterator;

public class PeerDiscoveryTask extends DefaultTask implements TaskListener {

private Set newPeers;
private int pingTasksCounter = 0;


newPeers = new HashSet();
Set habitats = getAgentContext().getDirectory().getHabitats();
for (Iterator i = habitats.iterator(); i.hasNext();) {
try {

//form the address of a (presumed) DF
AgentAddress peer = AgentAddress.create((IDReference)i.next(),
Constants.JNDI_DF_SERVICE_NAME);
//skip ourselves
if (peer.getHabitatIDRef().equalsIDReference
(getAgentContext().getMyAddress().getHabitatIDRef()))
continue;

//ping the remote DF
int peerValue = new Integer (getAgentContext ().getProperty
(Constants.DF.PING_TIMEOUT).toString()).intValue();
DFRequestTask pingTask = DFRequestTask.createPingTask(peer,
peerValue);
pingTask.addTaskListener(this);
addTask(pingTask);
pingTasksCounter++;
} catch(java.net.MalformedURLException murle) {
continue;
}
}
// if the only known habitat is this one, no ping request are issued
if (pingTasksCounter == 0) refreshComplete ();
}


public void taskEnded(TaskEvent te) {
AgentAddress peer = ((IncomingMessage)te.getTask().getFinishValue()).getSender();
addTask(new LogTask("Adding peer [" + peer + "]."));
newPeers.add(peer);
} else {
addTask(new LogTask("Peer [" + ((DFRequestTask)te.getTask()).getRequest()
.getReceiver() + "] did not reply to the ping request."));
}


pagina A.30
if (--pingTasksCounter == 0) refreshComplete();
}

// Updates the peers registry and terminates the task.
private void refreshComplete() {
Set peers = (Set)getAgentContext().getProperty(Constants.DF.PEERS_REGISTRY);

//update the peers with the new active set
peers.clear();
peers.addAll(newPeers);

//make sure the message is displayed before the task succeeds
LogTask finalLog = new LogTask("Peers refresh complete.");
finalLog.addTaskListener(new TaskListener() {
public void taskStarted(TaskEvent te) {}
public void taskEnded(TaskEvent te) { succeed(); }
});
addTask(finalLog);
}
}

t ta as sk ks s/ /D DF F/ /S Se ea ar rc ch hT Ta as sk k. .j ja av va a

package tasks.DF;


import tryllian.afc.message.NoSuchAgentException;
import tryllian.afc.message.fipa.Agree;
import tryllian.afc.message.fipa.Refuse;
import java.util.Map;

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;
}

Set activeSearches = (Set)getAgentContext().getProperty
(Constants.DF.ACTIVE_SEARCHES);

pagina A.31
Set peers = (Set)getAgentContext().getProperty(Constants.DF.PEERS_REGISTRY);
searchID = request.getContent(Constants.ContentKeys.SEARCH_ID);

//refuse search if already passed this node
if (activeSearches.contains(searchID)) {
try { request.reply(new Refuse(request.getSubject(),
Constants.Exceptions.SEARCH_ALREADY_ACTIVE));
return;
}

//spawn an unique search ID if one not specified
if (searchID == null) searchID = getAgentContext().getMyAddress() + "-" +
(activeSearches.size() + 1);
activeSearches.add(searchID);

//retrieve search parameters
searchKey = request.getContent(Constants.ContentKeys.SEARCH_KEY);
if (searchKey == null) {
try { request.reply(new Refuse(request.getSubject(),
Constants.Exceptions.MISSING_ARGUMENT));
addFinalTask(new LogTask("Search key missing " + "in request from [" +
request.getSender() + "]."));
return;
}

maxResults = getIntContent(request,Constants.ContentKeys.MAX_RESULTS);
int searchDepth = getIntContent(request,Constants.ContentKeys.SEARCH_DEPTH);
addTask(new LogTask("[" + request.getSender().getHost() + ":" + request.getSender ().getPort
() + "] is searching "
+ (maxResults == -1 ? "any number of" : "at most " + maxResults)
+ " providers of service [" + searchKey + "], at "
+ (searchDepth == -1 ? "any depth" : "max depth " + searchDepth)));

//search first locally
Map servicesRegistry = (Map)getAgentContext().getProperty
(Constants.DF.SERVICES_REGISTRY);
Set providers = (Set)servicesRegistry.get(searchKey);
if (providers != null) results.addAll(providers);

//if search depth does not allow remote search, we have no peers
//or we've accomplished our max results, finish the search
if ( (searchDepth == 1) || peers.isEmpty() || ((maxResults >= 0) && (results.size() >=
maxResults)) ) {
int resultsCount = sendResults();
finalizeSearch();
if (resultsCount > 0)
addFinalTask(new LogTask("Sent " + resultsCount + " search results back to
[" + request.getSender().getHost()+
":" + request.getSender().getPort() + "]."));
return;
}

//extend the search to the peers
if (searchDepth > 1) searchDepth--;
int searchTimeout = getIntContent(request,Constants.ContentKeys.SEARCH_TIMEOUT);

//we need to give the messages at this level time to be exchanged,
//so we decrement the search timeout for the next level
int searchTimeoutDecrement = new Integer (getAgentContext().getProperty

pagina A.32
(Constants.DF.SEARCH_TIMEOUT_DECREMENT).toString()).intValue();
int minimumSearchTimeout = new Integer (getAgentContext().getProperty(
Constants.DF.MINIMUM_SEARCH_TIMEOUT).toString()).intValue();
searchTimeout = Math.max(searchTimeout - searchTimeoutDecrement,
minimumSearchTimeout);

for (Iterator i = peers.iterator(); i.hasNext();) {
AgentAddress peer = (AgentAddress)i.next();
DFRequestTask subSearch = DFRequestTask.createSearchTask(
peer, searchID, searchKey, maxResults, searchDepth,
searchTimeout
);
subSearch.addTaskListener(this);
addTask(subSearch);
subSearchesCount++;
}
}



IncomingMessage subResponse = (IncomingMessage)te.getTask().getFinishValue();
if (!resultsSent) {

//add the subquery results
int subCount;
try {
subCount = Integer.parseInt(subResponse.getContent
(Constants.ContentKeys.RESULTS_COUNT));
} catch (NumberFormatException nfe) { subCount = 0; }
for (int i = 0; i < subCount; i++)

results.add(subResponse.getContent(Constants.ContentKeys.RESULT_PREFIX + i));
if ((maxResults != -1) && (results.size() >= maxResults)) {
addTask(new LogTask("Sent " + resultsCount + " search
results back to [" + request.getSender().getHost()+
:" + request.getSender().getPort() + "]."));
}
}
} else {
//subquery failed
boolean timedout = te.getTask().getFinishValue().equals
(DFRequestTask.TIMEOUT_FINISH_VALUE);
}

if (--subSearchesCount == 0) {

//send results if not already sent
if (!resultsSent){
addTask(new LogTask("Sent " + resultsCount + " search results back to [" +
request.getSender().getHost()+
:" + request.getSender().getPort() + "]."));
}

finalizeSearch();

pagina A.33
}
}

// Finalizes the search. Does <strong>not</strong> terminate the task.
private void finalizeSearch() {
((Set)getAgentContext().getProperty
(Constants.DF.ACTIVE_SEARCHES)).remove(searchID);
}

// Sends the search results back to the agent that issued the search.
private int sendResults() {

//send the response
Agree reply = new Agree(request.getSubject());
reply.setContent(Constants.ContentKeys.SEARCH_KEY, searchKey);
int i = 0;

//at most maxResults items are sent, if maxResults specified
for (Iterator iterator = results.iterator();iterator.hasNext() && ((maxResults == -1) || (i <
maxResults));i++) {
reply.setContent(Constants.ContentKeys.RESULT_PREFIX + i,
(String)iterator.next());
}
reply.setContent(Constants.ContentKeys.RESULTS_COUNT, Integer.toString(i));
try { request.reply(reply);

resultsSent = true;
return i;
}

protected static int getIntContent(IncomingMessage msg, String key) {
try {
String stringValue = msg.getContent(key);
return stringValue == null ? -1 : Integer.parseInt(msg.getContent(key));
} catch(NumberFormatException nfe) { return -1; }
}

private void addFinalTask(Task finalTask) {
finalTask.addTaskListener(new TaskListener() {
public void taskStarted(TaskEvent te) {}
public void taskEnded(TaskEvent te) { succeed(); }
});
addTask(finalTask);
}

}

t ta as sk ks s/ /S Se ec cu ur ri it ty y/ /C Co on nn ne ec ct tT Ta as sk k. .j ja av va a

package tasks.Security;

import java.net.ConnectException;
import java.net.UnknownHostException;

pagina A.34
import java.io.IOException;
import Javaclient.src.PtzPlayerDevice;
import Javaclient.src.BlobfinderInterface;

public class ConnectTask extends DefaultTask implements TaskListener {

private static final char PLAYER_ALL_MODE = 'a';
private String hostname;
private String port;


this.hostname = context.getProperty(Constants.Security.HOSTNAME).toString();
this.port = context.getProperty(Constants.Security.PORT).toString();

LogTask l = new LogTask ("Connecting to " + hostname + ":" + port);

addTask(l);

}

public void taskStarted (TaskEvent te) { }

try {
// load the driver
PlayerClient robot = new PlayerClient (hostname, new Integer (port).intValue());
PositionPlayerDevice motors = robot.requestPosition(PLAYER_ALL_MODE);
SonarPlayerDevice sonar = robot.requestSonar(PLAYER_ALL_MODE);
TruthPlayerDevice truth = robot.requestTruth(PLAYER_ALL_MODE);
FiducialInterface fiducial = robot.requestFiducial(PLAYER_ALL_MODE);

PtzPlayerDevice ptz = robot.requestPtz(PLAYER_ALL_MODE);
BlobfinderInterface blob = robot.requestBlobfinder(PLAYER_ALL_MODE);

context.setProperty(Constants.Security.ROBOT, robot);
context.setProperty(Constants.Security.MOTORS, motors);
context.setProperty(Constants.Security.SONAR, sonar);
context.setProperty(Constants.Security.TRUTH, truth);
context.setProperty(Constants.Security.FIDUCIAL, fiducial);
succeed ();
} catch (ConnectException ce) {
addTask (new LogTask ("EXCEPTION! = " + ce.toString()));
} catch (UnknownHostException uhe) {
addTask (new LogTask ("EXCEPTION! = " + uhe.toString()));
} catch (IOException ioe) {
addTask (new LogTask ("EXCEPTION! = " + ioe.toString()));
}
}

}


pagina A.35
t ta as sk ks s/ /S Se ec cu ur ri it ty y/ /H Ha an nd dl le eS Se ec cu ur ri it ty yI In nf fo or rm mT Ta as sk k. .j ja av va a



public class HandleSecurityInformTask extends HandleMessageTask {

private boolean foundIntruder = false;

public HandleSecurityInformTask (IncomingMessage msg) { super (msg);}

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
}

try {

pagina A.36
return null;
}
}
}

t ta as sk ks s/ /S Se ec cu ur ri it ty y/ /S Se ec cu ur ri it ty yI In ni it tT Ta as sk k. .j ja av va a



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,
});
}




int timeoutValue = new Integer (context.getProperty(
Constants.Security.REGISTRATION_TIMEOUT).toString()).intValue();
(Constants.Security.REGISTRATION_RETRIES).toString()).intValue();
int ssTimeout = 12;
int ssRetries = 5;

DBConSearcher = new ServiceSearchTask ("database-connector", 1, -1,
ssRetries, ssTimeout),
SuperSearcher = new ServiceSearchTask ("super-agent", 1, -1, ssRetries,
ssTimeout)

pagina A.37
});

(Security_SERVICENAME,

new ConnectTask (),
registration,
serviceSearch
});

return;
}

Constants.Security.DBCon_ADDRESS,
Constants.Security.Supervisor_ADDRESS,
((AgentAddress[])SuperSearcher.getFinishValue())[0]);
}
}
}

t ta as sk ks s/ /S Su up pe er rv vi is so or r/ /S Su up pe er rv vi is so or rI In ni it tT Ta as sk k. .j ja av va a

package tasks.Supervisor;


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.38

int timeoutValue = new Integer (context.getProperty
(Constants.Supervisor.REGISTRATION_TIMEOUT).toString()).intValue();
(Constants.Supervisor.REGISTRATION_RETRIES).toString()).intValue();

DBConSearcher = new ServiceSearchTask ("database-connector", 1, -1, 12,
10)});

(Supervisor_SERVICENAME,

// new ConnectTask (),
// new PatrolTask(),
serviceSearch,
registration
});

return;
}

Constants.Cleaner.DBCon_ADDRESS,
}

}
}

t ta as sk ks s/ /D DF FR Re eq qu ue es st tT Ta as sk k. .j ja av va a

package tasks;

import extra.DFNotFoundException;
import tryllian.afc.message.OutgoingMessage;
import tryllian.afc.message.fipa.Request;
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.39
timeout) {
Request msg = new Request (Constants.Functions.REGISTER);
msg.setContent(Constants.ContentKeys.SERVICE_NAME, serviceName);
msg.setContent(Constants.ContentKeys.SERVICE_OWNER, serviceOwner);
return new DFRequestTask (msg, timeout);
}

public static DFRequestTask createDeregisterTask (String serviceName, String serviceOwner, int
timeout) {
Request msg = new Request (Constants.Functions.DEREGISTER);
msg.setContent(Constants.ContentKeys.SERVICE_NAME, serviceName);
msg.setContent(Constants.ContentKeys.SERVICE_OWNER, serviceOwner);
return new DFRequestTask (msg, timeout);
}

public static DFRequestTask createPingTask(AgentAddress peer, int timeout) {
Request msg = new Request(Constants.Functions.PING);
msg.setReceiver(peer);
return new DFRequestTask(msg, timeout);
}

public static DFRequestTask createSearchTask (String searchKey, int timeout) {
return createSearchTask (searchKey, -1, -1, timeout);
}

public static DFRequestTask createSearchTask (String searchKey, int maxResults, int timeout) {
return createSearchTask (searchKey, maxResults, -1, timeout);
}

public static DFRequestTask createSearchTask (String searchKey, int maxResults, int searchDepth, int
timeout) {
Request req = new Request (Constants.Functions.SEARCH);
req.setContent (Constants.ContentKeys.SEARCH_KEY, searchKey);
req.setContent (Constants.ContentKeys.MAX_RESULTS, Integer.toString (maxResults));
req.setContent(Constants.ContentKeys.SEARCH_DEPTH, Integer.toString(searchDepth));
return new DFRequestTask (req, timeout);
}

public static DFRequestTask createSearchTask (AgentAddress peer, String searchID, String searchKey,
int maxResults, int searchDepth, int timeout) {
Request req = new Request (Constants.Functions.SEARCH);
req.setReceiver (peer);
req.setContent (Constants.ContentKeys.SEARCH_ID, searchID);
req.setContent (Constants.ContentKeys.SEARCH_KEY, searchKey);
req.setContent (Constants.ContentKeys.MAX_RESULTS, Integer.toString (maxResults));
req.setContent(Constants.ContentKeys.SEARCH_DEPTH, Integer.toString(searchDepth));
return new DFRequestTask (req, timeout);
}

public AgentAddress[] getSearchResults() {
if (!req.getSubject().equals(Constants.Functions.SEARCH) || !getState().isSucceeded()) return
null;
IncomingMessage msg = (IncomingMessage)getFinishValue();
int resultsCount;
try {
resultsCount = Integer.parseInt(
msg.getContent(Constants.ContentKeys.RESULTS_COUNT));
} catch (NumberFormatException nfe) {
resultsCount = 0;
}


pagina A.40
if (resultsCount == 0) return null;

AgentAddress[] results = new AgentAddress[resultsCount];
for (int i = 0; i < resultsCount; i++)
try {
results[i] =
AgentAddress.create(msg.getContent(
Constants.ContentKeys.RESULT_PREFIX + i));
} catch (MalformedURLException mfurle) {
results[i] = null;
}
return results;
}

private AgentAddress getLocalDF() throws DFNotFoundException {
java.util.Iterator dfsIter = getAgentContext().getDirectory().getServiceAgents
(Constants.DF_SERVICE_NAME).iterator();
if (!dfsIter.hasNext()) throw new DFNotFoundException();
return (AgentAddress)dfsIter.next();
}

public void taskStarted() {
//if request receiver is not set at task start time, we need to
//find it out - search for the local DF
if (req.getReceiver() == null) {
try {
req.setReceiver(getLocalDF());
} catch(DFNotFoundException dfnfe) {
fail(dfnfe);
return;
}
}
//set the search timeout content value for a search request
if (req.getSubject().equals(Constants.Functions.SEARCH))

req.setContent(Constants.ContentKeys.SEARCH_TIMEOUT,Integer.toString(timeout));
//delegate conversation handling to superclass
super.taskStarted();
}
}

t ta as sk ks s/ /H Ha an nd dl le eM Me es ss sa ag ge e. .j ja av va a
package tasks;


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.41
addTask (finalTask);
}

public void taskEnded (TaskEvent te) { succeed (); }
}

t ta as sk ks s/ /H Ha an nd dl le er rs sF Fa ac ct to or ry y. .j ja av va a

package tasks;


public interface HandlersFactory extends java.io.Serializable {
public Task createHandler(IncomingMessage msg);
}

t ta as sk ks s/ /I In ni it ti ia al li is sa at ti io on nT Ta as sk k. .j ja av va a
package tasks;


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;
}

Task propsInit = new InitPropertiesTask (agentName, propNames);
propsInit.addTaskListener(this);
addTask (propsInit);
}

}

t ta as sk ks s/ /I In ni it tP Pr ro op pe er rt ti ie es sT Ta as sk k. .j ja av va a

package tasks;

import javax.xml.parsers.SAXParserFactory;
import javax.xml.parsers.SAXParser;
import org.xml.sax.XMLReader;
//import org.xml.sax.helpers.DefaultHandler;

pagina A.42
import org.xml.sax.ErrorHandler;
import org.xml.sax.ContentHandler;
import org.xml.sax.Locator;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.SAXParseException;
import java.util.StringTokenizer;

public class InitPropertiesTask extends DefaultTask implements TaskListener, ContentHandler {

private static final String filename = "run/config.xml";
protected String agentName;
protected String key;
protected boolean DB, DF, SU, SE, CL;
private String[] propNames;

private String value;

public InitPropertiesTask (String AGENT_NAME, String[] propNames) {
this.agentName = AGENT_NAME;
this.propNames = propNames;
}

LogTask laa = new LogTask("Reading configuration parameters for agent " + agentName);
laa.addTaskListener (this);
addTask (laa);
// reads from config.xml the '<AGENT_NAME>_config section'
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setNamespaceAware(true);
try {
SAXParser saxParser = spf.newSAXParser();
XMLReader xmlReader = saxParser.getXMLReader();
xmlReader.setContentHandler(this);
xmlReader.setErrorHandler(new MyErrorHandler ());
xmlReader.parse (filename);
LogTask l = new LogTask ("Exception " + e.getMessage());
addTask (l);
}
}

public void taskEnded (TaskEvent te) { succeed (); }

// ContentHandler methods override
public void characters (char buf[], int start, int length) throws SAXException {
String s = new String (buf, start, length);
if (((!key.startsWith("DBCon_config")) &&
(!key.startsWith("DF_config")) &&
(!key.startsWith("Security_config")) &&
(!key.startsWith("Cleaner_config")) &&
(!key.startsWith("Supervisor_config")) && ((DB) || (DF) || (SE) || (CL) || (SU)) &&
(length > 0)))
setProperties (s);
}

private void setProperties (String value) {
StringTokenizer st = new StringTokenizer (key, "_");
String st1 = st.nextToken();

pagina A.43
this.key = st.nextToken ();

if (st1.startsWith ("DBCon"))
setDBConproperties (value);
if (st1.startsWith ("DF"))
setDFproperties (value);
if (st1.startsWith ("Security"))
setSecurityproperties (value);
if (st1.startsWith ("Supervisor"))
setSupervisorproperties (value);
if (st1.startsWith ("Cleaner"))
setCleanerproperties (value);
}

private void setDBConproperties (String val) {
if (key.startsWith ("hostname")) {
getAgentContext().setProperty(propNames[0], val);
return;
}
if (key.startsWith ("dbname")) {
return;
}
if (key.startsWith ("username")) {
return;
}
if (key.startsWith ("password")) {
return;
}
if (key.startsWith ("timeout")) {
return;
}
if (key.startsWith ("retries")) {
return;
}
}

private void setDFproperties (String val) {
if (key.startsWith ("peers")) {
return;
}
if (key.startsWith ("pingtimeout")) {
return;
}
if (key.startsWith ("decrement")) {
return;
}
if (key.startsWith ("searchtimeout")) {
return;
}
}

private void setSecurityproperties (String val) {

pagina A.44
if (key.startsWith ("host")) {
return;
}
if (key.startsWith ("port")) {
return;
}
return;
}
return;
}
if (key.startsWith ("speed")) {
return;
}
if (key.startsWith ("palgorithm")) {
return;
}
}

private void setCleanerproperties (String val) {
if (key.startsWith ("host")) {
return;
}
if (key.startsWith ("port")) {
return;
}
return;
}
return;
}
if (key.startsWith ("speed")) {
return;
}
if (key.startsWith ("palgorithm")) {
return;
}
}

private void setSupervisorproperties (String val) {
return;
}
return;

pagina A.45
}
}

public void endDocument () {}

public void endElement (String namespaceURI, String localName, String qName) throws
SAXException {
this.key = "";
this.DB = false;
this.DF = false;
this.SE = false;
this.CL = false;
this.SU = false;
}

public void endPrefixMapping (String prefix) {}
public void ignorableWhitespace (char[] ch, int start, int lenght) {}
public void processingInstruction (String target, String data) {}
public void setDocumentLocator (Locator locator) {}
public void skippedEntity (String name) {}
public void startDocument () {}

public void startElement(String namespaceURI, String localName, String qName, Attributes atts)
throws SAXException {
this.key = localName;
if (this.key.startsWith ("DBCon") && (this.agentName.startsWith("database-connector")))
this.DB = true;
if (this.key.startsWith ("DF") && (this.agentName.startsWith("directory-facilitator")))
this.DF = true;
if (this.key.startsWith ("Security") && (this.agentName.startsWith ("security-robot")))
this.SE = true;
if (this.key.startsWith ("Cleaner") && (this.agentName.startsWith ("cleaner-robot")))
this.CL = true;
if (this.key.startsWith ("Supervisor") && (this.agentName.startsWith ("super-agent")))
this.SU= true;
}

public void startPrefixMapping (String prefix, String uri) {}

private static class MyErrorHandler extends DefaultTask implements ErrorHandler {

private String getParseExceptionInfo (SAXParseException spe) {
String systemID = spe.getSystemId();
if (systemID == null)
systemID = "null";
String info = "URI=" + systemID + " Line=" + spe.getLineNumber() + ": " +
spe.getMessage();
return info;
}

public void warning (SAXParseException spe) throws SAXException {
addTask (new LogTask ("Warning: " + getParseExceptionInfo (spe)));
}
public void error(SAXParseException spe) throws SAXException {
String message = "Error: " + getParseExceptionInfo (spe);
addTask (new LogTask (message));
throw new SAXException (message);
}
public void fatalError(SAXParseException spe) throws SAXException {
String message = "Fatal Error: " + getParseExceptionInfo (spe);
addTask (new LogTask (message));

pagina A.46
throw new SAXException (message);
}
}

}

t ta as sk ks s/ /L Li is st te en ne er rT Ta as sk k. .j ja av va a

package tasks;

import tryllian.afc.task.ReactiveTask;
import tryllian.afc.message.MessageFilter;

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));
}
}

t ta as sk ks s/ /R Re eq qu ue es st tT Ta as sk k. .j ja av va a

package tasks;

import tryllian.afc.task.ReactiveTask;
import tryllian.afc.message.OutgoingMessage;
import tryllian.afc.task.interaction.SendMessageTask;

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.47
//agent address with a unique static member
//and we synchronize as we shall be called from multiple
//agent threads
synchronized(getClass()) {
req.setMeta("conversation-id","request-" + g
getAgentContext().getMyAddress() + "-" + ++instancesCounter);
}
}

//listen only to the interesting conversation
DefaultMessageFilter filter = new DefaultMessageFilter();
filter.addMetaContentSelector("conversation-id", req.getConversationID());
setMessageFilter(filter);

//init message sending
addTask(new SendMessageTask(req));

timerStart = System.currentTimeMillis();
}

public void handleMessage(IncomingMessage response) {
if (response.getPerformative().equals(Performatives.AGREE))
succeed(response);
else
fail(response);
synchronized(getClass()) { instancesCounter--; }
}

public void handleHeartbeat() {
if (System.currentTimeMillis() - timerStart > timeout * 1000) {
fail(TIMEOUT_FINISH_VALUE);
synchronized(getClass()) { instancesCounter--; }
}
}

public OutgoingMessage getRequest() { return req; }
public int getRequestTimeout() { return timeout; }

}

t ta as sk ks s/ /S Se en nd dR Ro ob bo ot tI In nf fo oT Ta as sk k. .j ja av va a

package tasks;

import extra.Guidelines;
import tryllian.afc.task.interaction.SendMessageTask;

pagina A.48

public class SendRobotInfoTask extends DefaultTask implements TaskListener {

private Set subtasks = new HashSet ();

int X, Y, Head;
String creator, destination;
TruthPlayerDevice truth;
FiducialInterface fiducial;
Beacon[] beacons;
Guidelines[] guides = new Guidelines[50]; // 50 guideline objects should cover it
int beaconCount;

AgentAddress[] receiver = new AgentAddress[100];
ObjectMessage msg;

boolean gotReceiver = false;

public SendRobotInfoTask (String agentName, TruthPlayerDevice t, FiducialInterface f, String r) {
this.creator = agentName;
this.truth = t;
this.fiducial = f;
this.destination = r;
}

gotReceiver = false;
try {
if (creator.startsWith("cleaner")) {
if (destination.startsWith ("data")) {
AgentAddress alfa = (AgentAddress)getAgentContext().getProperty
(Constants.Cleaner.DBCon_ADDRESS);
receiver = new AgentAddress[1];
receiver[0] = alfa;
gotReceiver = true;
}
if (destination.startsWith ("clean")) {
receiver = (AgentAddress[])getAgentContext().getProperty
(Constants.Cleaner.Cleaner_ADDRESSES);
gotReceiver = true;
}
if (destination.startsWith ("secur")) {
(Constants.Cleaner.Security_ADDRESSES);
gotReceiver = true;
}
}
if (creator.startsWith("security")) {
if (destination.startsWith ("data")) {
AgentAddress alfa = (AgentAddress)getAgentContext().getProperty
(Constants.Security.DBCon_ADDRESS);
receiver = new AgentAddress[1];
receiver[0] = alfa;
gotReceiver = true;
}
if (destination.startsWith ("clean")) {
(Constants.Security.Cleaner_ADDRESSES);
gotReceiver = true;
}

pagina A.49
if (destination.startsWith ("secur")) {
(Constants.Security.Security_ADDRESSES);
gotReceiver = true;
}
}
} catch (Exception e) { System.err.println(e.toString());}

if (gotReceiver) {
for (int i=0; i < receiver.length; i++) {
msg = new ObjectMessage ();
msg.setPerformative(Performatives.INFORM);
msg.setSubject ("position-info");
try {
msg.storeObject(new RobotInfo (creator, X, Y, Head, beaconCount,guides));
} catch (Exception e) { }//System.err.println (e.toString()); }
msg.setReceiver(receiver[i]);
subtasks.add(new SendMessageTask (msg));
}

if (subtasks.isEmpty()) succeed ();
else {
Iterator iter = subtasks.iterator();
while (iter.hasNext()) {
Task subTask = (Task)iter.next();
subTask.addTaskListener (this);
addTask (subTask);
}
}
}
}

X = truth.getX();
Y = truth.getY();
Head = truth.getHeading();
if (!creator.startsWith("cleaner")) {
beaconCount = fiducial.getBeaconCount();
beacons = fiducial.getBeacons();
for (int i=0; i < beaconCount; i++) {
guides[i] = new Guidelines (beacons[i].beaconID, beacons[i].range,
beacons[i].bearing, beacons[i].orientation,
beacons[i].rangeUncertain, beacons[i].bearingUncertain,
beacons[i].orientationUncertain);
}
}
}


subtasks.remove(te.getTask ());
if (subtasks.isEmpty ()) succeed ();
}
}

t ta as sk ks s/ /S Se er rv vi ic ce eS Se ea ar rc ch hT Ta as sk k. .j ja av va a

package tasks;


pagina A.50

public class ServiceSearchTask extends TaskRetryTask {

public ServiceSearchTask (String serviceName, int maxResults, int searchDepth, int maxRetries, int
retryTimeout) {
super (
new SingleSearchTask (DFRequestTask.createSearchTask(serviceName, maxResults,
searchDepth, retryTimeout)),
maxRetries);
}

public Object getFinishValue() {
if (getState().isSucceeded())
return getRetryTask().getFinishValue();
return super.getFinishValue();
}

public static class SingleSearchTask extends DefaultTask implements TaskListener {

private DFRequestTask searchTask;

public SingleSearchTask (DFRequestTask searchTask) {
this.searchTask = searchTask;
searchTask.addTaskListener (this);
}

addTask (searchTask);
}


if (searchTask.getState().isFailed()) {
fail (searchTask.getFinishValue());
return;
}

AgentAddress[] results = searchTask.getSearchResults();

if (results == null) {
try {
Thread.sleep (searchTask.getRequestTimeout() * 1000);
} catch (InterruptedException ie) {}
fail ("No results found");
return;
}
succeed (results);
}
}
}

t ta as sk ks s/ /U Up pd da at te eC Cl le ea an ne er rL Li is st tT Ta as sk k. .j ja av va a

package tasks;

pagina A.51


public class UpdateCleanerListTask extends DefaultTask implements TaskListener {

private String Cleaner_addresses = "cleaner-addresses";

public UpdateCleanerListTask (String property) {
this.Cleaner_addresses = property;
}

int timeoutValue = 15;
int maxresults = 3;

DFRequestTask cleanerSearch = DFRequestTask.createSearchTask ("cleaner-robot", -1,
maxresults, timeoutValue);
cleanerSearch.addTaskListener(this);
addTask (cleanerSearch);
}


AgentAddress[] results = ((DFRequestTask)te.getTask()).getSearchResults();
getAgentContext().setProperty(Cleaner_addresses, results == null ? new
AgentAddress[0] : results);
}
}
}

t ta as sk ks s/ /U Up pd da at te eS Se ec cu ur ri it ty yL Li is st tT Ta as sk k. .j ja av va a

package tasks;


public class UpdateSecurityListTask extends DefaultTask implements TaskListener {

private String Security_addresses = "security-addresses";

public UpdateSecurityListTask (String property) {
this.Security_addresses = property;
}

int timeoutValue = 15;
int maxresults = 3;

DFRequestTask cleanerSearch = DFRequestTask.createSearchTask ("security-robot", -1,
maxresults, timeoutValue);

pagina A.52
cleanerSearch.addTaskListener(this);
addTask (cleanerSearch);
}


AgentAddress[] results = ((DFRequestTask)te.getTask()).getSearchResults();
getAgentContext().setProperty(Security_addresses, results == null ? new
AgentAddress[0] : results);
}
}
}
Model fiiere de configurare

pagina B.1
A An ne ex xa a B B. . M Mo od de el le e f fi i i ie er re e d de e c co on nf fi ig gu ur ra ar re e

F Fi i i ie er r d de e c co on nf fi ig gu ur ra ar re e p pe en nt tr ru u p pr ri im mu ul l a ag ge en nt t C Cl le ea an ne er r ( (+ +D DF F) )

<?xml version="1.0" encoding="us-ascii"?>




<Robotux_config>
<DF_config>
</DF_config>

<Cleaner_config>
1 = wall follower
2 = space wanderer
-->
</Cleaner_config>
</Robotux_config>

F Fi i i ie er r d de e c co on nf fi ig gu ur ra ar re e p pe en nt tr ru u a al l d do oi il le ea a a ag ge en nt t C Cl le ea an ne er r ( (+ +D DF F) )




<Robotux_config>
<DF_config>

pagina B.2
</DF_config>

<Cleaner_config>
1 = wall follower
2 = space wanderer
-->
</Cleaner_config>
</Robotux_config>

F Fi i i ie er r d de e c co on nf fi ig gu ur ra ar re e p pe en nt tr ru u p pr ri im mu ul l a ag ge en nt t S Se ec cu ur ri it ty y ( (+ +D DF F) )




<Robotux_config>
<DF_config>
</DF_config>

<Security_config>

2 = wall follower

pagina B.3
-->
</Security_config>
</Robotux_config>

F Fi i i ie er r d de e c co on nf fi ig gu ur ra ar re e p pe en nt tr ru u a al l d do oi il le ea a a ag ge en nt t S Se ec cu ur ri it ty y ( (+ +D DF F) )




<Robotux_config>
<DF_config>
</DF_config>

<Security_config>

2 = wall follower
-->
</Security_config>
</Robotux_config>

F Fi i i ie er r d de e c co on nf fi ig gu ur ra ar re e p pe en nt tr ru u a ag ge en n i ii i D DB BC Co on n i i S Su up pe er rv vi is so or r ( (+ +D DF F) )




<Robotux_config>

<DBCon_config>

pagina B.4

<Supervisor_config>
<Supervisor_timeout>10</Supervisor_timeout>
<Supervisor_retries>6</Supervisor_retries>
<Supervisor_defcon>5</Supervisor_defcon>
</Supervisor_config>

</Robotux_config>
Model fiiere descriere

pagina C.1
A An ne ex xa a C C. . M Mo od de el le e f fi i i ie er re e d de es sc cr ri ie er re e

F Fi i i ie er r d de es sc cr ri ie er re e p pe en nt tr ru u a ag ge en nt tu ul l C Cl le ea an ne er r ( (+ +D DF F) )

<!DOCTYPE habitat SYSTEM "http://www.tryllian.com/xml/habitat_1_0.dtd">
<habitat>
<places>
<room name="/">
<agent dna="agents/cleaner.dna">
</agent>
<agent dna="agents/df.dna">
</agent>
</room>
</places>
</habitat>

F Fi i i ie er r d de es sc cr ri ie er re e p pe en nt tr ru u a ag ge en nt tu ul l S Se ec cu ur ri it ty y ( (+ +D DF F) )

<habitat>
<places>
<room name="/">
<agent dna="agents/security.dna">
</agent>
</agent>
</room>
</places>
</habitat>

F Fi i i ie er r d de es sc cr ri ie er re e p pe en nt tr ru u a ag ge en nt tu ul l S Se ec cu ur ri it ty y ( (+ +D DF F) )

<habitat>
<places>
<room name="/">
<agent dna="agents/supervisor.dna">
</agent>
<agent dna="agents/dbcon.dna">
</agent>
</agent>
</room>
</places>
</habitat>
Fiiere script pentru instalare i rulare

pagina D.1
A An ne ex xa a D D. . F Fi i i ie er re el le e s sc cr ri ip pt t p pe en nt tr ru u i in ns st ta al la ar re e i i r ru ul la ar re e

S Sc cr ri ip pt tu ul l p pe en nt tr ru u c co om mp pi il la ar re ea a a ap pl li ic ca a i ie ei i: : b bu ui il ld d. .s sh h

#!/bin/sh
export JAVA_HOME=/usr/java/j2sdk1.4.2
#export JAVA_HOME=/usr/lib/j2se/1.4
export ADK_ROOT=_buildtools
export ADK_ROOT=/root/eclipse/ZeeRobots/_buildtools
echo $ADK_ROOT

export ANT_HOME=${ADK_ROOT}/ant
${ANT_HOME}/bin/ant -Dadk.root=${ADK_ROOT} -emacs $*

F Fi i i ie er ru ul l c ca ar re e d de ef fi in ne e t te e a ag ge en n i ii i c ce e s se e v vo or r c co om mp pi il la a: : b bu ui il ld d. .x xm ml l

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE project PUBLIC "-//ANT//DTD project//EN" "file:./project.dtd">

<project name="ZeeRobots" default="all" basedir=".">

<taskdef name="dna" classname="com.tryllian.tools.DNAComposerAntTask"/>

<target name="init">
<tstamp/>
<echo message="Starting Ant."/>
<echo message="Using Java ${java.version} (${java.vm.name} ${java.vm.version})"/>
<echo message="Java home is ${java.home}"/>
<echo message="running on ${os.name} ${os.version} (${os.arch})"/>
<property file="build.properties"/>
<mkdir dir="${relative.compiled}"/>
<mkdir dir="${relative.jarfiles}"/>
<echo message="Using CLASSPATH=${project.classpath}"/>
</target>

<target name="all" depends="supervisor, security, cleaner, dbcon, df, clean"/>


<target name="compile" depends="init">
<echo message="compile started"/>

<javac srcdir="${relative.source}"
destdir="${relative.compiled}"
classpath="${project.classpath}"
debug="true"
optimize="false"
/>
</target>


<target name="jar" depends="init, compile">

<jar jarfile="${relative.jarfiles}/block.jar"
basedir="${relative.compiled}"
compress="${options.jarfiles.compress}"
/>
</target>



<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"
<content
name="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"
<content
name="block.jar"
target="standard"
/>
<content
name="Javaclient.jar"
file="${relative.libraries}/Javaclient.jar"

pagina D.3
target="standard"
/>
</dna>
</target>

<target name="dbcon" depends="init, jar">
<dna dna="${agents.dnadir}/dbcon.dna"
agentdescriptor="${relative.descriptors}/dbcon.xml"
<content
name="block.jar"
target="standard"
/>
<content
name="mysql-connector-java-3.0.11-stable-bin.jar"
file="${relative.libraries}/mysql-connector-java-3.0.11-stable-bin.jar"
target="standard"
/>
</dna>
</target>

<target name="df" depends="init, jar">
<dna dna="${agents.dnadir}/df.dna"
agentdescriptor="${relative.descriptors}/df.xml"
<content
name="block.jar"
target="standard"
/>
</dna>
</target>


<target name ="clean" depends="init">

<delete>
<fileset dir="${relative.compiled}" includes="**/*.class"/>
</delete>
<delete dir="${relative.compiled}"/>

<delete>
<fileset dir="${relative.jarfiles}" includes="**/*.jar"/>
</delete>
<delete>
<fileset dir="${relative.jarfiles}" includes="**/*.jar"/>
</delete>
<delete dir="${relative.jarfiles}"/>
<delete dir="${tasks.dir}"/>

</target>

</project>

S Sc cr ri ip pt tu ur ri il le e p pe en nt tr ru u r ru ul la ar re ea a a ap pl li ic ca a i ie ei i: : h ha ab bi it ta at t. .s sh h

#!/bin/sh

PRG=$0
progname=`basename $0`

# Resolve symlinks.
while [ -h "$PRG" ]; do
ls=`/bin/ls -ld "$PRG"`
link=`/usr/bin/expr "$ls" : '.*-> $.*$$'`
if /usr/bin/expr "$link" : '/' > /dev/null; then
PRG="$link"
else
PRG="`/usr/bin/dirname $PRG`/$link"
fi
done

ADK_ROOT=_buildtools

# Set ADK_ROOT to a default value if it was not user-defined before.
if test -z "$ADK_ROOT"; then
ADK_ROOT=`dirname "$PRG"`/..
echo ADK_ROOT was undefined and was set to "$ADK_ROOT"
fi

# set the directory where the security and property files are
CONFIG_PATH=run/config

ADK_PATH=${ADK_ROOT}/lib/are.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/are-runtime.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/are-jxta.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/are-jdbc.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/jxta.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/jxtaptls.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/jxtasecurity.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/cryptix32.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/cryptix-asn1.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/iaik_jce_full.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/jaxp.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/crimson.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/log4j.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/assert.jar
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/runtime/jargs.jar

# HSQLDB database support
ADK_PATH=${ADK_PATH}:${ADK_ROOT}/lib/jdbc/hsqldb.jar

# start habitat
java -Dare.home=${ADK_ROOT} -Dare.configdir=${CONFIG_PATH} -
Djava.security.policy==${CONFIG_PATH}/are-security.policy -Dj2ee.home=${J2EE_HOME} -cp
${ADK_PATH} com.tryllian.mptools.XMLHabitat $*


pagina D.5
S Sc cr ri ip pt tu ur ri il le e p pe en nt tr ru u r ru ul la ar re ea a a ap pl li ic ca a i ie ei i: : r ru un n. .s sh h

#!/bin/sh
#
# Starting script for Robotux v0.1, (c) Radu Bogdan Rusu, 21.05.2004
#

echo
echo " [20;45;20mRobotux [00m security proje ct [31mv0.1 [00m, (c) 2004 [31mRadu Bogdan
Rusu [00m"
echo
rm -rf .jxta
if [ "$1" = "" ]; then
echo "Please specify the name of the agents you would like to start. Guidelines:"
echo "- use ' [04m./run.sh all [00m' to start [31;43mall [00m the agents (for testing purposes
only)"
echo "- use ' [04m./run.sh supervisor [00m' to start a [31;43mSupervisor [00m agent and a
[31;43mDBConnector [00m agent"
echo "- use ' [04m./run.sh security1 [00m' to start a [31;43mSecurity [00m agent
( [20;34;04msecurity 1 [00m)"
echo "- use ' [04m./run.sh security2 [00m' to start a [31;43mSecurity [00m agent
( [20;35;04msecurity 2 [00m)"
echo "- use ' [04m./run.sh cleaner1 [00m' to start a [31;43mCleaner [00m agent
( [20;34;04mcleaner 1 [00m)"
echo "- use ' [04m./run .sh cleaner2 [00m' to start a [31;43mCleaner [00m agent
( [20;35;04mcleaner 2 [00m)"
echo
echo "Please note that a [31;43mDF [00m agent is started automatically in any of the above"
echo "situations."
echo
exit 0
fi

if [ "$1" = "all" ]; then
echo "--- [ Starting up [31;43mALL [00m agents... ]---"
echo
/bin/cp --reply=yes ./run/config.all ./run/config.xml
./habitat.sh run/habitat/_all_.xml
exit 0
fi

if [ "$1" = "supervisor" ]; then
echo "--- [ Starting up a [31;43mSupervisor/DBCon [00m habitat... ]---"
echo
/bin/cp --reply=yes ./run/config.dbsuper ./run/config.xml
./habitat.sh run/habitat/supervisor.xml
exit 0
fi

if [ "$1" = "cleaner1" ]; then
echo "--- [ Starting up a [31;43mCleaner [00m habitat ( [20;34;04mcleaner 1 [00m)... ]---"
echo
/bin/cp --reply=yes ./run/config.cleaner1 ./run/config.xml
./habitat.sh run/habitat/cleaner.xml
exit 0
fi

if [ "$1" = "cleaner2" ]; then
echo "--- [ Starting up a [31;43mCleaner [00m habitat ( [20;35;04mcleaner 2 [00m)... ]---"
echo
/bin/cp --reply=yes ./run/config.cleaner2 ./run/config.xml

pagina D.6
./habitat.sh run/habitat/cleaner.xml
exit 0
fi

if [ "$1" = "security1" ]; then
echo "--- [ Starting up a [31;43mSecurity [00m habitat ( [20;34;04msecurity 1 [00m)... ]---"
echo
/bin/cp --reply=yes ./run/config.security1 ./run/config.xml
./habitat.sh run/habitat/security.xml
exit 0
fi

if [ "$1" = "security2" ]; then
echo "--- [ Starting up a [31;43mSecurity [00m habitat ( [20;35;04msecurity 2 [00m)... ]---"
echo
/bin/cp --reply=yes ./run/config.security2 ./run/config.xml
./habitat.sh run/habitat/security.xml
exit 0
fi

echo "Please specify the name of the agents you would like to start. Guidelines:"
echo "- use ' [04m./run.sh all [00m' to start [31;43mall [00m the agents (for testing purposes only)"
echo "- use ' [04m./run.sh supervisor [00m' to start a [31;43mSupervisor [00m agent and a
[31;43mDBConnector [00m agent"
echo "- use ' [04m./run.sh security1 [00m' to start a [31;43mSecurity [00m agent ( [20;34;04msecurity
1 [00m)"
echo "- use ' [04m./ru n.sh security2 [00m' to start a [31;43mSecurity [00m agent ( [20;35;04msecurity
2 [00m)"
echo "- use ' [04m./run.sh cleaner1 [00m' to start a [31;43mCleaner [00m agent ( [20;34;04mcleaner
1 [00m)"
echo "- use ' [04m./run.sh cleaner2 [00m' to start a [31 ;43mCleaner [00m agent ( [20;35;04mcleaner
2 [00m)"
echo
echo "Please note that a [31;43mDF [00m agent is started automatically in any of the above"
echo "situations."
echo
exit 0

S Sc cr ri ip pt tu ul l p pe en nt tr ru u c cr re ea ar re ea a u un ne ei i c co op pi ii i f fu un nc c i io on na al le e a a p pr ro oi ie ec ct tu ul lu ui i: : n ne ew wi in ns st ta an nc ce e. .s sh h

#!/bin/sh
#
# Creating new instances for Robotux v0.1, (c) Radu Bogdan Rusu, 23.05.2004
#

echo
echo " [20;45;20mRobotux [00m security project [31mv0.1 [00m, (c) 2004 [31mRadu Bogdan
Rusu [00m"
echo
if [ "$1" = "" ]; then
echo "Please specify a desired port number for the new Robotux copy."
echo "eg. use ' [04m./newinstance.sh 3043X [00m', where X=1..9"
echo
exit 0
fi

if [ "$1" != "" ]; then
DIR=../instance-$1
echo "Creating directory $DIR..."
/bin/mkdir -p $DIR

pagina D.7
echo "Copying project files to directory $DIR..."
/bin/cp -rf ./* $DIR
echo "Modifying habitat.properties..."
cd $DIR
/bin/rm -f newinstance.sh
cd ./run/config
TCPPORT="messenger.listen.tcp.port=$1"
/usr/bin/awk -v portnr=$TCPPORT '{sub (/messenger.listen.tcp.port=30430/, portnr); print $0}'
habitat.properties > habitat.properties.new
/bin/mv habitat.properties.new habitat.properties
echo "done!"
exit 0
fi

echo "Please specify a desired port number for the new Robotux copy."
echo "eg. use ' [04m./newinstance.sh 3043X [00m', where X=1..9"
echo
exit 0

Lumea virtual definit pentru Robotux

pagina E.1
A An ne ex xa a E E. . F Fi i i ie er ru ul l c ca ar re e d de ef fi in ne e t te e l lu um me ea a v vi ir rt tu ua al l
f fo ol lo os si it t n n R Ro ob bo ot tu ux x 0 0. .1 1

F Fi i i ie er ru ul l r ro ob bo ot tu ux x. .w wo or rl ld d

#
# World map for the Robotux v0.1 security system project
#
# Radu Bogdan Rusu, 21.05.2004
#
# ID's are given using the following pattern:
# -> 1 - 50 = ---
# -> 51 -100 = guiding marks
# -> 101-150 = boxes, unmovable objects
# -> 151-200 = possible intruders (simulated... sucks, I know :()
# -> 201-210 = cleaner robots
# -> 211-220 = security robots
# -> 221-254 = ---
#
# Used Player ports:
# -> 6000-6999 = cleaner agents
# -> 7000-7999 = security agents
# -> 8000-8999 = simulated intruders

# ---[ Environment resolution ]---
# resolution equals to: 1pixel = 2cm
resolution .02

# ---[ World map bitmap ]---
bitmap (
resolution .02
file "robotux.pnm.gz"
)

# -------------------------[ Entities declarations ]------------------------
#
# ---[ standard Pioneer2 AT 8-sonars array ]---
define p2at_sonar sonar (
scount 8
spose[0] [ 0.115 0.130 90 ]
spose[1] [ 0.155 0.115 50 ]
spose[2] [ 0.190 0.080 30 ]
spose[3] [ 0.210 0.025 10 ]
spose[4] [ 0.210 -0.025 -10 ]
spose[5] [ 0.190 -0.080 -30 ]
spose[6] [ 0.155 -0.115 -50 ]
spose[7] [ 0.115 -0.130 -90 ]
)
# ---[ standard Pioneer2 DX 16-sonars array ]---
define p2dx_sonar sonar (
scount 16
spose[0] [ 0.115 0.130 90 ]
spose[1] [ 0.155 0.115 50 ]
spose[2] [ 0.190 0.080 30 ]
spose[3] [ 0.210 0.025 10 ]
spose[4] [ 0.210 -0.025 -10 ]
spose[5] [ 0.190 -0.080 -30 ]
spose[6] [ 0.155 -0.115 -50 ]

pagina E.2
spose[7] [ 0.115 -0.130 -90 ]
spose[8] [ -0.115 -0.130 -90 ]
spose[9] [ -0.155 -0.115 -130 ]
spose[10] [ -0.190 -0.080 -150 ]
spose[11] [ -0.210 -0.025 -170 ]
spose[12] [ -0.210 0.025 170 ]
spose[13] [ -0.190 0.080 150 ]
spose[14] [ -0.155 0.115 130 ]
spose[15] [ -0.115 0.130 90 ]
)
# ---[ Cleaner Robot agent ]---
define cleaner omniposition (
power ()
p2dx_sonar ()
truth ()
size [0.3 0.3]
color "blue"
interval 0.01
)
# ---[ Security Robot agent ]---
define security position (
power ()
p2at_sonar ()
truth ()
laser (
max_range 80
fiducialfinder (
range_anon 80
range_id 40
)
ptz (lens "wide" blobfinder ())
)
size [0.4 0.4]
color "red"
interval 0.01
)
# ---[ fixed objects ]---
define fixed box (
shape "rect"
size [0.3 0.3]
)
# ---[ movable objects ]---
define movable puck (
shape "circle"
size [0.15 0.15]
obstacle_return "invisible"
sonar_return "invisble"
)

pagina E.3
# ---[ intruders - simulated by smaller robots ]---
define intruder omniposition (
power ()
truth ()
p2at_sonar ()
size [0.3 0.3]
color "dark red"
interval 0.01
)

# ----------------------------[ Existing objects ]---------------------------
#
# Cleaner robot 1
cleaner (
name "cleaner 1"
port 6000
pose [11.960 9.400 -90]
fiducial_id 201
)
#
# Cleaner robot 2
cleaner (
name "cleaner 2"
port 6001
pose [5.440 3.720 -90]
fiducial_id 202
)
#
# Security robot 1
security (
name "security 1"
port 7000
pose [6 10 0]
fiducial_id 211
)
#
# Security robot 2
security (
name "security 2"
port 7001
pose [10 2.2 180]
fiducial_id 212
)
#
# Movable objects
movable ( pose [5.1 2.88 0] color "cyan")
movable ( pose [10 3 0] color "cyan")
movable ( pose [8 9 0] color "cyan")
#
# Fixed objects - guiding marks (IDs from 51 to 99)
fixed ( pose [6.260 10.540 0] size [0.05 0.05] color "white" fiducial_id 51 )
fixed ( pose [10.060 10.72 -90] size [0.05 0.05] color "white" fiducial_id 52 )
fixed ( pose [7.480 4.120 -90] size [0.05 0.05] color "white" fiducial_id 57 )

pagina E.4
#
# Fixed objects - possible intruders
fixed ( pose [2.020 1.980 180.000] size [0.2 0.2] color "black" fiducial_id 101 )
fixed ( pose [14.740 9.840 180.000] size [0.2 0.2] color "black" fiducial_id 102 )
#
# Moving "things" - possible intruders
intruder (
port 8000
pose [5 5 0]
fiducial_id 151
)

# ---------------------------------------------------------------------------

# GUI settings
#gui (
# size [ 800 600 ]
# origin [8.018 6 0]
## scale 0.021 # the size of each bitmap pixel in meters
## scale 0.01
#)

Rusu Diploma Thesis

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rusu Diploma Thesis

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA TEHNIC DIN CLUJ-NAPOCA

FACULTATEA DE AUTOMATIC I CALCULATOARE

S-ar putea să vă placă și