Inteligenta Artificiala

INGINERIE SOFTWARE
ȘI TEHNICI DE INTELIGENȚĂ ARTIFICIALĂ

Contribuția autorilor la realizarea cărții
Cercetător științific gr. 1

Dr.ing. Lucian Ștefăniță GRIGORE
Cap. 3: Subcapitolele: 3.2.6
Cap. 4: Subcapitolele: 4.4; 4.5; 4.6; 4.7; 4.8
Cap. 5: Subcapitolele: 5.3; 5.4
Cap. 6: Subcapitolele: 6.2; 6.3; 6.9
Conferențiar universitar
Dr.ing. Iustin PRIESCU
Cap. 1: Subcapitolele: 1.7; 1.8.2.
Cap. 2: Subcapitolele: 2.1
Cap. 3: Subcapitolele: 3.2.3; 3.2.5
Cap. 5: Subcapitolele: 5.5; 5.6
Cap. 6: Subcapitolele: 6.5; 6.6; 6.7; 6.8
Lector universitar
Dr.ing. Dan-Laurențiu GRECU
Cap. 1: Subcapitolele: 1.8.3; 1.8.4
Conferențiar universitar
Dr.inf. Ana-Cristina DĂSCĂLESCU
Cap. 2: Subcapitolele: 2.2.
Cap. 3: Subcapitolele: 3.1; 3.2.
Asistent universitar
Drd. Violeta-Nicoleta OPRIȘ
Cap. 1: Subcapitolele: 1.1; 1.2; 1.3; 1.4; 1.5; 1.6.
Cap. 6: Subcapitolele: 6.1;
Lucian Ștefăniță GRIGORE
Iustin PRIESCU Dan-Laurențiu GRECU
Ana-Cristina DĂSCĂLESCU Violeta OPRIȘ
INGINERIE SOFTWARE
ȘI
TEHNICI DE INTELIGENȚĂ
ARTIFICIALĂ
Seria „Inteligență artificială”
Editura AGIR
București, 2021
ASOCIAȚIA GENERALĂ A INGINERILOR DIN ROMÂNIA
Copyright © Editura AGIR şi autorii, 2021
Toate drepturile asupra acestei ediții sunt rezervate.
Editura AGIR este recunoscută de CNCSIS
Editura AGIR
Calea Victoriei, nr. 118, sector 1,
010093 București,
tel: 4021-316 89 92, 4021-316 89 93
4021- 319 49 45 (difuzare); fax 4021-312 55 31
e-mail: editura@agir.ro; www.agir.ro
Descrierea CIP a Bibliotecii Naţionale a României

Inginerie software şi tehnici de inteligenţă artificială /
Lucian Ştefăniţă Grigore, Iustin Priescu, Dan-Laurenţiu Grecu, .... -
Bucureşti : Editura A.G.I.R., 2022
Conţine bibliografie
ISBN 978-973-720-833-0
I. Grigore, Lucian Ştefăniţă
II. Priescu, Iustin
III. Grecu, Dan Laurenţiu
004
Îngrijire editorială: ing. Dan Bogdan

Copertă: ing. Ion Marin
Bun de tipar: 20.12.2021

ISBN 978-973-720-833-0
Lucian Ștefăniță GRIGORE este CS I în Academia
Tehnică Militară ˮFerdinand Iˮ și conf.univ.dr.ing. la
Universitatea „Titu Maiorescu”, Facultatea de Informatică,
fiind titularul disciplinelor „Inteligență Artificială”,
„Interfața Om-Mașină și Robotică”. Este autorul a 7 cărți,
22 de articole publicate în jurnale și a 57 de articole
științifice prezentate cu ocazia diferitelor sesiuni de
comunicări științifice. A participat în cadrul a peste 50 de
proiecte de cercetare ca director de proiect și membru în
echipele de cercetare. Are o experiență didactică de peste
25 de ani și de peste 18 ani în managementul proiectelor și
în industrie.
Iustin PRIESCU este conf. univ. dr. ing. la Universitatea

„Titu Maiorescu”, decan al Facultății de Informatică.
Activitatea didactică desfășurată la cursuri și seminarii
pentru disciplinele: „Cloud Computing”, „Securitate
Cibernetică”, „Comerț Electronic” și „Managementul și
certificarea securității sistemelor informatice”. Are
preocupări în dezvoltarea de aplicații de tip open source, în
securitatea cibernetică, e-learning și inginerie software.
Este autorul a 4 cărți în domeniu, peste 30 de articole de
cercetare științifică indexate ISI și BDI. A
coordonat/membru 9 proiecte cu finanțare Europeană și 5
proiecte/grant-uri de cercetare la nivel național/
internațional.
Dan-Laurențiu GRECU este este lector univ.dr.ing. la

Universitatea „Titu Maiorescu”, Facultatea de Informatică.
Activitatea didactică desfășurată la cursuri, laboratoare și
seminarii pentru disciplinele: „Criptografie și Securitatea
Informației”, „Teoria Transmiterii și Codificării
Informației”, „Securitatea Rețelelor Mobile și Wireless”,
„Securitatea Rețelelor de Comunicații”. Este autorul a 4
manuale, 34 de articole și publicații științifice indexate ISI
și BDI. A participat în cadrul a 12 proiecte de cercetare ca
director de proiect și membru în echipele de cercetare.
Ana-Cristina DĂSCĂLESCU este conf.univ.dr. în cadrul
Universității „Titu Maiorescu” din București, Facultatea de
Informatică. Are titlul de Doctor în Informatică, teza sa
având titlul „Sisteme cripotgrafice hibride bazate pe funcții
haotice unidimensionaleˮ. Are expertiză în domeniul
securității informatice, a sistemelor dinamice neliniare,
precum și în domeniul programării. Este autor / coautor a
peste 30 de articole de cercetare științifică indexate ISI și
BDI. A participat ca membru în mai multe proiecte de
cercetare.
Violeta-Nicoleta OPRIȘ este asistent univ drd. la

Universitatea „Titu Maiorescu”, Facultatea de Informatică.
Activitatea didactică desfășurată pentru laboratoarele și
seminariile la disciplinele: „Criptografie și Securitatea
Informației”, „Inginerie software” și „Securitatea
sistemelor informatice”. Este autoarea a 19 articole
publicate în jurnale de specialitate, având o experiență
de 10 ani în domeniul IT&C, în prezent ocupând funcția
de inginer de securitate și calitate la o companie
multinațională.
PREFAȚĂ
În ziua de azi, ne aflăm în plin avânt de dezvoltare a ingineriei software cu

implicații în domeniul inteligenței artificiale. Din această perspectivă, rolul cărții
de față este de a prezenta noțiuni de bază, modele și aplicații din aceste două
domenii conexe.
În acest context, cartea este în general concepută pentru informaticieni,
ingineri automatiști, experți în domeniul IT, programatori, manageri IT, având
noțiuni despre inteligența artificială aplicată în inginerie software. Lucrarea se
adresează în special specialiștilor cu preocupări în domeniul inteligenței artificiale
(machine learning și deep learning).
De asemenea, cartea se adresează studenților, masteranzilor și doctoranzilor,
prezentând, atât concepte teoretice ale inteligenței artificiale aplicată în inginerie
software, cât, mai ales, aspecte și soluții practice de implementare și programare.
În fiecare capitol, lucrarea exemplifică aspecte de implementare și prezintă cele mai
cunoscute realizări apărute la nivel mondial.
Cartea trebuie percepută și înțeleasă și ca un compendiu de bune practici în
domeniul inteligenței artificiale aplicate în inginerie software.
În elaborarea lucrării, autorii au consultat o bibliografie vastă pentru a pune
la dispoziția cititorilor o paletă mare de informații și cunoștințe din domeniile
ingineriei software și inteligenței artificiale.
În final, autorii doresc să aducă mulțumiri tuturor colaboratorilor pentru
sugestiile și îndrumările primite, fără de care realizarea acestei cărți poate nu ar fi
fost posibilă.
București, 20 decembrie 2021
Autorii
INGINERIE SOFTWARE ȘI
TEHNICI DE INTELIGENȚĂ ARTIFICIALĂ
Ingineria Software și Inteligența Artificială sunt două domenii, care în zilele

noastre se întrepătrund din ce în ce mai mult. Prin acest prim demers, autorii
completează seria de cărți care ating problematica Tehnicilor de Inteligență
Artificială, de această dată fiind vorba despre Ingineria Software.
Cartea pune la dispoziția cititorilor noțiuni și informații referitoare la:
– ingineria software (IS), care este un domeniu care privește proiectarea,
crearea și întreținerea de software, aplicând tehnologii și
cunoștințe/tehnici din informatică, managementul proiectelor, inginerie,
proiectarea interfețelor și a altor domenii conexe;
– inteligența artificială (IA), considerată ca parte a tehnologiilor viitorului,
reprezintă capacitatea unei mașini de a imita funcții umane, cum ar fi
raționamentul, învățarea, planificarea și creativitatea.
Provocările tehnologice ale zilelor noastre, cum ar fi nevoia de automatizare
din ce în ce mai mare a activităților umane, digitalizarea informațiilor și nivelul
ridicat de disponibilitate al acestora, volumul mare de date de procesat etc., au
impus noi abordări în ceea ce privește modul de implementare al viitoarelor sisteme
tehnice, realizarea de hardware & software a acestora, precum și integrarea pe
scară largă a noilor algoritmi și abordări specifice din domeniul inteligenței
artificiale.
Având în vedere cele spuse mai sus, autorii au organizat cuprinsul cărții pe 6
capitole, astfel:
1. În primul capitol sunt descrise noțiunile introductive privind ingineria
software. Sunt prezentate principalele obiective ale ingineriei software,
paradigmele de dezvoltare a sistemelor software, programele utilizate în
acest domeniu, precum și abordarea ingineriei software în domeniul
roboticii.
2. Capitolul 2 se referă la inteligența artificială și cuprinde pe lângă
noțiunile introductive specifice domeniului referițe privind inteligența
artificială distribuită și agenții inteligenți.
3. Un capitol important al cărții este capitolul 3 care tratează modul de
implementare al IA. Sunt definiți agenții de rezolvare a problemelor și
tipul acestora, procesul de formulare a problemei împreună cu definirea
spațiilor de căutare. Tot aici, sunt prezentate strategiile de căutare a
INGINERIA SOFTWARE ȘI TEHNICI DE INTELIGENȚĂ ARTIFICIALĂ 10
soluțiilor, împreună cu algoritmii asociați, cum ar fi: căutarea în lățime,

căutarea în adâncime, căutarea cu cost uniform, căutarea cu adâncime
limitată, căutarea cu adâncime incrementală, căutarea bidirecțională. De
asemenea, un subcapitol este dedicat sistemelor multiagent care folosesc
noțiuni și abordări din teoria jocurilor.
4. Capitolul 4 tratează două aspecte importante ale IA și anume cunoașterea
și raționamentul. Un agent inteligent are nevoie de cunoștințe despre
lumea reală pentru a lua decizii și raționamente pentru a acționa eficient.
Agenții bazați pe cunoaștere sunt acei agenți care au capacitatea de a
menține o stare internă a cunoașterii, raționează asupra acelor
cunoștințe, își actualizează cunoștințele după observații și iau măsuri.
Acești agenți pot reprezenta lumea cu o anumită reprezentare formală și
pot acționa inteligent. Sunt prezentate aspecte privind raționamentele
logice și clarificarea percepției la roboți, funcțiile de deliberare,
planificare, acțiune și recunoașterea obiectelor.
5. Capitolul 5 tratează problematica machine learning, care este un
subdomeniu al informaticii și o ramură a inteligenței artificiale, al cărui
obiectiv este de a dezvolta tehnici care dau roboților posibilitatea de a
învăța. Sunt prezentate aspecte privind navigația roboților mobili,
învățarea reperelor vizuale, modele deformabile și structura sistemului.
6. În capitolul 6 este tratată o altă ramură a IA, respectiv deep learning –
învățarea profundă. Până în anul 2010 nu am știut cum să pregătim
rețelele neuronale pentru a depăși abordările mai tradiționale, cu
excepția câtorva probleme specializate. Ceea ce s-a schimbat în 2010 a
fost descoperirea tehnicilor de învățare în așa-numitele rețele neuronale
profunde. Aceste tehnici sunt acum cunoscute sub numele de învățare
profundă. Învățarea profundă este știința formării unor rețele neuronale
artificiale mari. Rețelele neuronale profunde (Deep Neural Networks -
DNN) pot avea sute de milioane de parametri, permițându-le să modeleze
funcții complexe, cum ar fi dinamica neliniară. Metodele prezentate în
acest capitol se referă la învățarea profundă în robotică, modele
generative și nesupravegheate, metode de învățare a politicilor, învățarea
reperelor pentru apucarea unor obiecte.
SOFTWARE ENGINEERING AND ARTIFICIAL
INTELLIGENCE TECHNIQUES
Software Engineering and Artificial Intelligence are two fields that are
increasingly intertwined nowadays. Through this first step, the authors complete a
series of books that address the issue of Artificial Intelligence Techniques, this time
being Software Engineering.
The book provides readers with notions and information regarding:
– software engineering, which is a field related to the design, creation and
maintenance of software applying technologies and knowledge / techniques in
computer science, project management, engineering, interface design and other
related fields;
– artificial intelligence (AI), considered part of the technologies of the future,
is the ability of a machine to mimic human functions, such as reasoning, learning,
planning and creativity.
Today's technological challenges, such as the need to increasingly automate
human activities, the digitization of information and its high level of availability, the
large volume of data to be processed, etc., have imposed new approaches to how
implementation of future technical systems, their hardware & software development,
as well as the large-scale integration of new algorithms and specific approaches in
the field of artificial intelligence.
In view of the above, the authors organized the contents of the book into 6
chapters, as follows:
1. The first chapter describes the introductory notions of software engineering.
The main objectives of software engineering, the paradigms of software systems
development, the programs used in this field, as well as the approach of software
engineering in the field of robotics are presented.
2. Chapter 2 deals with artificial intelligence and includes, in addition to the
introductory concepts specific to the field, references to distributed artificial
intelligence and intelligent agents.
3. An important chapter of the book is Chapter 3 which deals with how to
implement AI. Problem-solving agents and their type are defined, the process of
formulating the problem together with the definition of the search spaces.
Here, too, solution search strategies are presented, along with associated
algorithms, such as: width search, depth search, uniform cost search, limited depth
search, incremental depth search, bidirectional search. Also, a subchapter is
dedicated to multiagent systems that use notions and approaches from game theory.
4. Chapter 4 deals with two important aspects of AI, namely knowledge and
reasoning. A smart agent needs real world knowledge to make decisions and
reasoning to act effectively.
Knowledge-based agents are those agents who have the ability to maintain an
internal state of knowledge, reason on that knowledge, update their knowledge after
observations and take action. These agents can represent the world with a certain
formal representation and can act intelligently. Aspects regarding logical reasoning
and clarification of robot perception, deliberation, planning, action and object
recognition functions are presented.
5. Chapter 5 deals with machine learning, which is a subdomain of computer
science and a branch of artificial intelligence, whose goal is to develop techniques
that give robots the opportunity to learn. Aspects regarding the navigation of mobile
robots, learning visual cues, deformable models and the structure of the system are
presented.
6. Chapter 6 deals with another branch of AI, namely deep learning. Until
2010, we did not know how to prepare neural networks to overcome the more
traditional approaches, except for a few specialized issues. What changed in 2010
was the discovery of learning techniques in so-called deep neural networks. These
techniques are now known as deep learning. Deep learning is the science of forming
large artificial neural networks Deep Neural Networks (DNNs) can have hundreds
of millions of parameters, allowing them to model complex functions, such as
nonlinear dynamics. The methods presented in this chapter refer to deep learning in
robotics, generative and unsupervised models, methods of learning policies,
learning landmarks for grabbing objects.
CUPRINS
PREFAȚĂ ................................................................................................................ 7
INGINERIE SOFTWARE ȘI TEHNICI DE INTELIGENȚĂ ARTIFICIALĂ .. 9
SOFTWARE ENGINEERING AND ARTIFICIAL INTELLIGENCE
TECHNIQUES....................................................................................................... 11
CUPRINS ............................................................................................................... 13
1. INTRODUCERE ÎN INGINERIA SOFTWARE....................................... 19
1.1 Obiectivele Ingineriei Software .................................................... 23
1.2 Paradigme de dezvoltare a sistemelor software ............................ 24
1.2.1. Paradigma procedurală ....................................................... 26
1.2.2. Paradigma bazată pe date.................................................... 27
1.2.3. Paradigma orientată pe obiecte ........................................... 28
1.3 Introducere în UML ...................................................................... 29
1.4 Introducere în SysML ................................................................... 34
1.4.1. Abordarea modelării ........................................................... 35
1.4.2. Scopul ................................................................................. 35
1.4.3. Procesul de modelare .......................................................... 36
1.5 Cicluri de viață software ............................................................... 37
1.5.1. Modelul SDLC tip cascadă ................................................. 38
1.5.2. Modelul de prototipare rapidă ............................................ 39
1.5.3. Modelul tip spirală .............................................................. 41
1.5.4. Model de dezvoltare software bazat pe piață ...................... 43
1.5.5. Model de dezvoltare Open-Source ..................................... 44
1.5.6 Model de dezvoltare Agile.................................................. 44
1.6 Metodologia Agile bazată pe UML ............................................... 45
1.7 Principiile proiectării orientate pe obiect ...................................... 50
1.7.1 Principiile de proiectare ...................................................... 54
1.7.2 Lucrări conexe .................................................................... 56
INGINERIA SOFTWARE FOLOSIND TEHNICI DE INTELIGENȚĂ ARTIFICIALĂ 14
1.7.3 Librăria numerică................................................................ 57

1.7.4 Funcții matematice.............................................................. 57
1.7.4.1 Formularea funcției algebrice: .......................................... 57
1.7.4.2 Formulare vectorială spațială ........................................... 59
1.7.5 Layerul privind abstractizarea Hardware ............................ 59
1.7.5.1 Implementarea ierarhică a driverului hardware ............... 59
1.7.5.2 Abstractizarea sistemului de operare ................................ 61
1.7.6 Cinematica și Dinamica RL ................................................ 62
1.7.7 Abstractizarea elementelor grafice ..................................... 63
1.7.6 Planificarea traseului .......................................................... 65
1.8 Inginerie Software bazată pe modele în robotică .......................... 67
1.8.1 Sisteme de control software pentru roboți autonomi .......... 67
1.8.1.1 Sisteme software încorporate în timp real ....................... 67
1.8.1.2 Sisteme software distribuite .............................................. 67
1.8.1.3 Funcționalități ................................................................... 68
1.8.1.4 Mașini versatile ................................................................. 68
1.8.2 Modelarea și analiza arhitecturii sistemelor ....................... 69
1.8.2.1 UML pentru sisteme software încorporate în timp real ... 70
1.8.2.2 Analiza arhitecturii și limbajului de proiectare .................... 72
1.8.2.3 Cadrul prioritar al interacțiunii comportamentale ............ 74
1.8.3 Implementarea și integrarea sistemelor .............................. 75
1.8.3.1 SmartSoft .......................................................................... 76
1.8.3.2 Proteus ............................................................................. 79
1.8.3.3 Modelarea comportamentului componentelor ................. 80
1.8.4 Configurarea de sistem ....................................................... 81
1.8.4.1 Software pentru robotică................................................... 82
1.8.4.2 Modelarea resurselor robotizate ....................................... 83
Bibliografie – Capitolul 1 ...................................................................... 84
Abrevieri – Capitolul 1 .......................................................................... 88
2. INTELIGENȚA ARTIFICIALĂ .................................................................. 91
2.1 Noțiuni introductive ...................................................................... 91
2.1.1 State of the Art .................................................................... 96
2.1.2 Operatorul Harris .............................................................. 100
2.1.3 Detectorul SIFT ................................................................ 103
15 Cuprins
2.2 Inteligența artificială distribuită .................................................. 107

2.3 Agenți inteligenți ......................................................................... 113
Anexa 2.1. Ce este inteligența artificială ............................................. 121
Bibliografie – Capitolul 2 .................................................................... 124
Abrevieri – Capitolul 2 ........................................................................ 125
3. REZOLVAREA PROBLEMELOR ........................................................... 126
3.1 Agenți de rezolvare a problemelor .............................................. 126
3.1.1 Formularea problemei ....................................................... 127
3.1.2 Spații de căutare ................................................................ 128
3.1.2.1 Căutarea în lățime - Breadth-First .................................. 130
3.1.2.2 Căutarea în adâncime - Depth-First: ............................... 134
3.1.2.3 Căutarea cu cost uniform – Uniform Cost ..................... 139
3.1.2.4 Căutarea cu adâncime limitată – Depth-Limited ........ 140
3.1.2.5 Căutarea cu adâncime incrementală - Iterative-Deepening
....................................................................................... 142
3.1.2.6 Căutarea bidirecțională – Bidirectional search ............... 146
3.2 Sisteme multiagent ...................................................................... 150
3.2.1 Multiagent Framework ..................................................... 150
3.2.2 Reprezentarea jocurilor ..................................................... 151
3.2.2.1 Forma de interacțiune normală a jocurilor...................... 151
3.2.2.2 Forma extinsă a unui joc ................................................. 152
3.2.2.3 Rețele decizionale multiagent ......................................... 155
3.2.3 Strategii de calcul cu informații perfecte .......................... 155
3.2.4 Raționamentul multiagentului - parțial observabil ........... 158
3.2.4.1 Calcularea echilibrului Nash........................................... 163
3.2.4.1.1 Eliminarea strategiilor dominante............................... 164
3.2.4.1.2 Calcularea strategiilor aleatorii .................................... 165
3.2.4.2 Învățarea coordonării ...................................................... 166
3.2.5 Luarea deciziilor în grup ................................................... 170
3.2.6 Proiectarea mecanismului ................................................. 171
Anexa 3.1 – Tehnici de Inteligență Artificială ................................... 174
4. CUNOAȘTERE ȘI RAȚIONAMENTE ..................................................... 181

4.1 Agenți logici ................................................................................ 181
4.2 Consistența raționamentelor logice la roboți ............................... 192
4.2.1 Clarificarea percepției și logica robotului ...................... 192
4.2.1.1 Descoperirea inconsecvenței ......................................... 193
4.2.1.2 Exemplu de raționament la un robot .............................. 194
4.2.1.3 Sisteme de evoluție Booleană ........................................ 196
4.2.1.4 Modelarea sistemelor de evoluție booleană ................... 199
4.2.1.4.1 Sisteme de tranziție ..................................................... 200
4.2.1.4.2 Implementare .............................................................. 202
4.2.1.5 Verificarea stabilității și a inconsecvenței ..................... 204
4.2.1.5.1 CTL și LTL ................................................................. 204
4.2.1.5.2 Formularea stabilității și inconsecvenței prin formule
logice.............................................................................. 206
4.2.1.5.3 Algoritmi eficienți pentru verificarea stabilității și a
inconsistenței ................................................................. 208
4.2.1.5.4 Implementare .............................................................. 210
4.2.1.5.5 Generarea contraexemplului ........................................ 210
4.3 Funcțiile de deliberare ale roboților autonomi ............................ 212
4.4 Proiectarea unui sistem de deliberare robotică ............................ 212
4.4.1Funcții de deliberare ....................................................... 212
4.4.2Caracteristicile și cerințele de deliberare ale aplicațiilor
robotice .......................................................................... 215
4.4.3 Opțiuni de proiectare a unui sistem de deliberare .......... 217
4.5 Planificarea .................................................................................. 220
4.5.1 Planificarea mișcării și sarcinilor ................................... 222
4.5.2 Planificarea temporală .................................................... 224
4.5.3 Planificare probabilistică ................................................ 225
4.5.4 Planificare în domenii deschise ...................................... 226
4.6 Acțiune ........................................................................................ 228
4.7 Monitorizarea și raționamentul obiectivelor ............................... 229
4.8 Observarea/Percepția ................................................................... 230
4.8.1 Planificarea de a percepe ................................................ 231
17 Cuprins
4.8.2 Recunoașterea obiectelor și ancorarea simbolurilor ....... 231

5. MACHINE LEARNING ............................................................................. 238
5.1 Realizarea unei curbe polinomiale ............................................... 240
5.2 Învățarea reperelor vizuale de către un robot mobil ..................... 248
5.3 Stadiul actual privind navigația roboților mobili ......................... 250
5.4 Modele deformabile ..................................................................... 251
5.5 Parametrii de recunoaștere a învățării pentru obiecte noi ............ 256
5.6 Structura sistemului ...................................................................... 266
6. DEEP LEARNING – ÎNVĂȚAREA PROFUNDĂ .................................. 274
6.1 Introducere ................................................................................... 275
6.2 Straturi convoluționale ................................................................. 277
6.3 Traiectorie la nivel înalt de învățare profundă pentru robotică ... 278
6.4 Deep Learning / Învățarea profundă în robotică .......................... 279
6.5 Clasificatori și modele discriminative (structura A) în robotică .. 280
6.5.1 Rolul structurii A în robotică ............................................ 280
6.5.2 Exemple ............................................................................ 280
6.5.3 Recomandări practice pentru lucrul cu structura A .......... 283
6.6 Modele generative și nesupravegheate (structura B) în robotică 285
6.6.1 Rolul structurii B în robotică ............................................ 285
6.6.2 Exemple ............................................................................ 285
6.7 Modele de învățare a politicilor (structura D) în robotică ............ 286
6.7.1 Rolul structurii D în robotică ............................................ 286
6.7.2 Exemple ............................................................................ 287
6.7.3 Recomandări practice pentru lucrul cu structura D .......... 288
6.8 Dezavantajele actuale ale DNN-urilor pentru robotică ................ 288
6.9 Deep Learning pentru prinderea unor obiecte .............................. 289

1. INTRODUCERE
ÎN INGINERIA SOFTWARE
Termenul de inginerie software1, a fost utilizat prima dată, în anul 1968, la o

conferință NATO (North Atlantic Treaty Organization) [1.1]. Termenul de inginerie
software este atribuit lui Margaret Hamilton2. Odată cu schimbările programelor
informatice, se constată schimbări accelerate în privința Ingineriei Software, care
începând cu anul 2013 s-a maturizat, formând un organism comun de cunoștințe de
inginerie software SWEBOK (Software Engineering Body of Knowledge).
Consultați articolul „Corpul de cunoștințe software” [1.2].
Ingineria software, ca disciplină, este un element esențial pentru studenți și
practicieni pentru a înțelege când anumite tehnologii și metodologii sunt sau nu sunt
adecvate.
Odată cu apariția PC (Personal Computer) au început să apară documentații care
descriau modul de determinare a conținutului locațiilor de memorie specifice utilizate de
sistemele de operare ale calculatorului. De asemenea alte publicații au început să descrie
algoritmi și implementarea lor într-un dialect al limbajului de programare BASIC. Apoi
Software-ul a crescut foarte mult ca dimensiune și a devenit extrem de complex, spre
exemplu software-ul de procesare a cuvintelor [1.3].
Toate acestea au condus la apariția de programe software cum ar fi Microsoft
Word și WordStar. Versiunile mai vechi permiteau: inserarea și ștergerea textului,
să taie și să lipească blocuri de text, folosirea de caractere cursive și aldine pentru a
seta textul, schimbarea dimensiunii caracterelor etc. A urmat apariția corectorului
ortografic, combinații de taste privind executarea unor comenzi și opțiunile
disponibile ale fiecărei comenzi. Astăzi software-ul de procesare a textului are de
obicei următoarele caracteristici:
• interfață grafică care utilizează un mouse sau un alt dispozitiv de indicare,
sau touch-screen;
• seturi de formate de fișiere în care un document poate fi deschis;
• seturi de formate de fișiere în care un document poate fi salvat;
• seturi de rutine de conversie care să permită transferul fișierelor către și din
diferite aplicații;
• set de fonturi admise;
• facilități de a decupa și insera elemente de grafică;
• capacitatea de a insera și modifica tabele importate;
1
Ingineria software reprezintă aplicarea sistematică a abordărilor inginerești pentru
dezvoltarea de software. Ingineria software este o ramură a informaticii.
2
https://www.computer.org/publications/tech-news/events/what-to-know-about-the-
scientist-who-invented-the-term-software-engineering
20 1 – Introducere în Ingineria Software
• capacitatea de a insera și modifica alte materiale non-textuale;

• facilități pentru determinarea numărului de cuvinte și a altor statistici despre
document;
• facilități opționale pentru verificarea gramaticală;
• capacitatea de a crea automat tabele de conținut și indici;
• capacitatea de a formata ieșirea pentru diferite dimensiuni ale hârtiei;
• capacitatea de a imprima plicuri;
• capacitatea de a compune și de a formata paginile pentru a fi publicate pe
desktop;
• capacitatea de backup a documentelor și cea de recuperare a unui fișier dacă
apare o eroare neașteptată în software-ul de procesare a cuvintelor sau în
blocarea sistemului.
Interfața poate fi creată pentru fiecare pereche de aplicații interoperabile posibile
(procesor de texte și pachet grafic, procesor de text și foaie de calcul, browser de internet
etc.). În mod alternativ, poate exista o singură interfață standard între fiecare aplicație
(procesor de text, pachet grafic, foaie de calcul etc.) și sistemul de operare sau un alt
software comun. Cele două abordări se regăsesc reprezentate în Fig. 1.1 și Fig. 1.2.
Fig. 1.1 Exemplu de sistem complex de interconectare.
Fig. 1.2 Un sistem de interconectare conceptual mai simplu.
Software-ul de procesare al textului trebuie să adere la o interfață specificată

anterior. Acest lucru este tipic, deoarece nu prea există software, care să nu
interacționeaze cu un software existent. Abordarea sistematică a unei probleme de

sistem este extrem de utilă, întrucât sistemele software sunt foarte complexe, lucru
care poate afecta proiectarea acestora.
De aceea orice versiune de software testată necorespunzător (ortografie,
inserare/întrerupere de pagină etc.) în vederea lansării mai rapide pe piață, conduce
în fapt la o respingere a produsului respectiv. Astfel, este de preferat ca la achiziția
unui software nou să i se solicite producătorului carcateristicile noi, cum ar fi acces
direct la Internet sau facilitati Cloud.
Există probleme evidente de securitate dacă datele critice sau confidențiale ale
unui utilizator sunt stocate pe un server la distanță, care nu este gestionat de către
utilizator și nu sunt luate măsuri de securitate a acestora. Pe viitor, software-urile de
procesare a textelor vor deveni mai complexe, ceea ce însemană că vor trebuie să
interfațeze cu mai multe aplicații pentru a putea partaja:
• cu diferite periferice și implicit cu multe funcții de utilitate;
• diferite date cu alte aplicații.
În cazul software-urilor destinate transporturilor (aeriene, terestre, căi ferate,
maritime etc.) partajarea aceluiași sistem de cale este interfațată cu alte software-uri
utilizate în același scopuri, doar că acelea pot face parte din alte țări sau areale
geografice. Aceasta este o provoare reală, fiecare sistem local are dezvoltate sisteme
independente. Un exemplu de coordonare deficitară este cel al traficului feroviar din
Australia. Din această cauză – diverse funcții spyware (software nedorit) care se
instalează pe calculator pentru a monitoriza și obține informații – au apărut probleme
și la elaborarea și respectarea standardelor din domeniu (viteza, aliniamentele etc.).
Un alt set de probleme apar și din cauza modului în care este abordată
proiectarea și realizarea de software-uri particulare și private (Microsoft, Apple etc.).
Software-ul privat este controlat de cel care deține aplicația software. Există Digital
Restrictions Management (DRM)3 prin care se pot introduce diverse funcții spyware.
Pentru a putea devolta un software liber sau particular, trebuie îndeplinite patru
cerințe majore:
• programul să poată fi rulat în formula care este necesară/dorită;
• codul sursă să poată fi accesat și modificat în funcție de cerințele
individuale;
• să se poată redistribui sub forma unei copii exacte;
• să fie redistribuite în mod automat toate versiunile modificate (upgrade).
Software as a Service (SaaS) este noua denumire a software-urilor private,
respectiv avem o nouă definiție/paradigmă și anume aceea de software de serviciu. SaaS
se evidențiază prin aceea că proprietarul software-ului instalează un server de rețea, care
face toate operațiile: procesare text, traduceri de text, calcule analitico-numerice etc.
Utilizatorii putând doar să ruleze pe acel server. Ei își trimit datele la server, care execută
calculele conform datelor furnizate, trimițând înapoi rezultatele, existând posibilitatea
ca să se poată interveni asupra calculelor respective în mod direct.
3
https://www.defectivebydesign.org/
Aceste servere nu permit controlul utilizatorilor asupra lor, ele livrează doar
niște rezultate fără a pune la dispoziție codul sursă.
Spre exemplu, aplicația Microsoft Windows poate trimite fără aprobare
informațiile derulate direct la deținătorul aplicației Microsoft (Windows Media
Player, RealPlayer)4.
Orice dezvoltator de aplicații independente trebuie să respecte o serie întreagă
de formalități/reglementări/standardizări. Spre exemplu multitudinea de aplicații
pentru iPhone și iPad, care se pot descărca de pe AppStore, sunt greu de localizat din
punct de vedere al deținătorului.
Dintre sistemele de operare existente, amintim de următoarele:
• MS-DOS a fost dezvoltat în mare măsură de Bill Gates și Paul Allen –
Microsoft. PC-DOS a funcționat pe o mașină cu 64K de acces aleatoriu,
citire-scriere a memoriei, acum rulează doar ca aplicație într-o fereastră
terminal a cărei pictogramă se găsește în folderul accesorii de pe
calculatoare. Cu timpul a devenit Windows 8/10;
• Apple DOS pentru familia de computere Apple II a fost creat de Steve Jobs
și Steve Wozniak. Apple-DOS folosea mai puțină memorie și a funcționat
pe Apple II cu doar 16K. Cu timpul a devenit MacOS, OS X, Yosemite;
• UNIX a fost dezvoltat inițial de Dennis Ritchie și Kenneth Thompson5
pentru seria PDP-11 de minicomputere pe 16 biți. Dimensiunea kernel-ului
UNIX l-a determinat pe Linus Torvalds să dezvolte un kernel mai mic, care
a devenit sistemul de operare Linux;
• VisiCalc, a fost în mare parte scris de o singură persoană, Dan Bricklin.
Versiunile VisiCalc au funcționat pe Apple II și pe IBM8086. VisiCalc nu
mai există ca produs comercial, fiind înlocuit de Excel și Numbers.
Versiunea curentă a Excel constă din milioane de linii de cod sursă scrise în
C și limbaje conexe.
Testarea este esențială în dezvoltarea software-ului modern și este necesară o
organizație de asistență tehnică pentru a răspunde la cerințele clienților, cum ar fi
Application Lifecycle Management (ALM).
Dezvoltarea Sistemelor Software Agile a fost posibilă datorită faptului că
dezvoltarea unui produs software, care satisface o nevoie, necesită șase luni,
multiplicarea cu factorul conservator de Brooks de opt ori înseamnă că software-ul
va dura cel puțin patru ani pentru a fi gata pentru lansare. Presupunând că timpul
necesar și efortul necesar - în ceea ce privește persoana - cresc în același mod.
Desigur, produsul poate fi irelevant în patru ani, deoarece restul industriei software
nu stă pe loc.
Cele mai multe proiecte de succes, care au dat naștere companiilor de software
au devenit mult mai mari în ceea ce privește numărul de persoane pe care le
4
https://www.nytimes.com/2009/07/18/technology/companies/18amazon.html
5
https://www.historyofinformation.com/detail.php?id=872
angajează. Chiar și software-ul, care a fost inițial dezvoltat de unul sau doi
antreprenori este acum dezvoltat de echipe. Companiile și organizațiile de mare
succes care realizează browsere de internet, ale căror versiuni inițiale s-au datorat în
mare măsură eforturilor unei echipe mici, sunt acum angajatori ai multor ingineri
software pentru a crește numărul de caracteristici disponibile, pentru a asigura
portabilitatea către toate mediile și de îmbunătățire a gradului de utilizare de către o
clasă largă de utilizatori și chiar pentru a furniza suficiente documente.
1.1 Obiectivele Ingineriei Software
Organizațiile implicate în producerea de software au un interes puternic în a

se asigura că software-ul este dezvoltat în conformitate cu practicile acceptate din
industrie, cu un bun control al calității, respectarea standardelor și într-un mod
eficient și în timp util. Ingineria software este termenul folosit pentru a descrie
dezvoltarea software care urmează aceste principii.
Termenul de inginerie software se referă la o procedură sistematică care este
utilizată în contextul unui set general acceptat de obiective pentru: analiza,
proiectarea, implementarea, testarea și întreținerea software-ului. Software-ul produs
ar trebui să fie eficient, fiabil, utilizabil, modificabil, portabil, testabil, reutilizabil,
mentenabil, interoperabil și corect. Acești termeni se referă atât la sisteme, cât și la
componentele lor. Chiar dacă mulți dintre termeni se explică de la sine, vom defini
termenii, în baza standardului IEEE 19906 și a Software Engineering Body of
Knowledge (SWEBOK)7 pentru definiții conexe [1.4].
Eficiență - software-ul este produs în timpul așteptat și în limitele resurselor
disponibile și este rulat în timpul așteptat pentru a finaliza diferite calcule.
Fiabilitate - software-ul funcționează conform așteptărilor. În sistemele multi-
utilizatori, sistemul își îndeplinește funcțiile chiar și cu alte sarcini ale
sistemului.
Utilizare - software-ul poate fi utilizat corect. Aceasta se referă, în general, la
ușurința utilizării interfeței cu utilizatorul, dar se referă și la aplicabilitatea
software-ului atât la sistemul de operare al computerului, cât și la funcțiile de
utilitate și la mediul aplicației.
Modificabilitate — software-ul poate fi ușor schimbat dacă se modifică
cerințele sistemului.
Portabilitate – software-ul poate fi portat pe alte computere sau sisteme fără
rescrierea majoră a software-ului, el poate fi recompilat doar pentru a avea un
sistem de funcționare corespunzător pe noua mașină este considerat a fi foarte
portabil.
Testabilitate - software-ul poate fi testat cu ușurință, ceea ce înseamnă, că
software-ul este scris într-un mod modular.
6
https://standards.ieee.org/standard/610_12-1990.html
7
https://www.computer.org/education/bodies-of-knowledge/software-engineering
Reutilizare - software-urile pot fi utilizate din nou în alte proiecte. Aceasta

înseamnă că software-ul este modular, fiecare modul software individual are
o interfață bine definită și un rezultat clar definit de la executarea acestuia.
Acest lucru înseamnă că există un nivel substanțial de abstractizare și
generalitate în module care vor fi refolosite cel mai des.
Mentenabilitate - software-ul poate fi ușor de înțeles și schimbat în timp dacă
apar probleme. Acest termen este adesea folosit pentru a descrie durata de
viață a sistemelor cu durată lungă de viață, cum ar fi sistemul de control al
traficului aerian care trebuie să funcționeze zeci de ani.
Interoperabilitate – software-ul poate interacționa corect cu alte sisteme.
Acest lucru se poate aplica software-ului de pe un singur computer
independent sau software-ului utilizat într-o rețea.
Corectitudine - programul produce ieșirea corectă.
Aceste obiective nu ajută la dezvoltarea de software care îndeplinește aceste
obiective, ele permit descrierea proceselor și tehnicilor sistematice, care pot ajuta la
dezvoltarea eficientă a software-ului de înaltă calitate.
Ingineria software poate satisface următoarele sarcini aferente unui proiect:
• analiza problemei;
• determinarea cerințelor;
• proiectarea software-ului;
• codificarea soluției software;
• testarea și integrarea codului;
• instalarea și livrarea software-ului;
• documentație;
• întreținere;
• asigurarea calității;
• instruire;
• estimarea resurselor;
• management de proiect.
Un alt aspect important este cel legat de Asigurarea calității sau QA (Quality
Assurance) se referă la asigurarea faptului că atât produsul software produs, cât și
procesul prin care este dezvoltat software-ul îndeplinesc standardele de calitate ale
organizației. Echipa QA este adesea responsabilă pentru stabilirea standardelor de
calitate. Echipa QA trebuie să fie separată de restul echipei de dezvoltare software.
Calitatea trebuie să fie rezultatul procesului de inginerie utilizat pentru crearea
software-ului.
1.2 Paradigme de dezvoltare a sistemelor software
O paradigmă este un exemplu sau model care poate fi copiat. Paradigmele

constau într-un „set de presupuneri, concepte, valori și practici care constituie un
mod de a vedea realitatea pentru comunitatea care le împarte, mai ales într-o
disciplină intelectuală”. Atunci când este aplicat dezvoltării de software, o
paradigmă ghidează modul în care dezvoltatorii văd o anumită problemă și
organizează soluția. Pentru a dezvolta sisteme software mari și complexe,

dezvoltatorii împart procesul general de dezvoltare în pași sau faze mai mici și mai
ușor de gestionat. Alegerea procesului de dezvoltare software are o influență
semnificativă asupra succesului proiectului [1.5].
Procesul adecvat poate duce la finalizarea mai rapidă, costuri reduse, calitate
îmbunătățită și risc mai mic.
Procesul greșit poate duce la duplicarea eforturilor și creează probleme de
gestionare continuă.
Procesele de dezvoltare software, deși diferite, încorporează frecvent faze
diferite sau faze similare, iar unele faze sunt comune majorității proceselor. În
continuare se prezintă trei faze comune, în al căror acronim se regăsește OO (Object-
Oriented – Orientate pe Obiect):
1. Analiză (OOA - Object-Oriented-Analysis): În timpul analizei, se pune
accent pe problemă, nu pe soluție. Un model inițial este creat prin
abstractizarea aspectelor sau caracteristicilor esențiale ale problemei.
Modelul este exprimat printr-o notație care poate fi înțeleasă de clienți,
experți din domeniu și implementatori. Cu toate acestea, modelul este, în
general, independent de orice limbaj de programare sau sistem în acest
moment;
2. Proiectare (OOD - Object-Oriented-Design): Un design acoperă distanța
dintre analiză și implementare prin formarea unei arhitecturi de soluții.
Arhitectura reflectă cunoștințele de domeniu care au fost descoperite și
înregistrate în timpul fazei de analiză și oferă cadrul pe care este construită
soluția finală. Este adesea necesar să adăugați structuri de date și
operațiunile asociate acestora la model care nu apar în problema inițială,
dar care sunt cerute de o soluție software. De asemenea, este ceva obișnuit
ca detaliile care au fost trecute cu vederea în timpul analizei să fie adăugate
în timpul fazei de proiectare, în timp ce detaliile care se dovedesc a fi
străine sunt eliminate. Proiectarea este adesea partiționată în mai multe
sub-modele axate pe sarcini specifice, conexe. Unele comune sunt:
a. Interfața cu utilizatorul;
b. Management de date;
c. Managementul sarcinilor;
d. Managementul comunicațiilor;
3. Implementare/Programare (OOP - Object-Oriented-Programming) Faza de
implementare produce un instrument sau sistem utilizabil. Un proiect
software oferă în cele din urmă un program sau un sistem de programe. O
combinație de hardware și software este livrată dacă software-ul este
încorporat într-un produs fizic (mașină, robot, aeronavă).
Dezvoltatorii de software au experimentat patru paradigme majore de
dezvoltare software:
▪ procedurală;
▪ bazată pe date;
▪ orientată pe obiecte;
▪ ad-hoc.
O mare parte din cele mai vechi software produse au fost dezvoltate pe baza
unor paradigme ad-hoc sau improvizate. Fiecare dintre aceste paradigme încearcă să
rezolve o problemă din lumea reală cu o soluție software. Ilustrația (Fig. 1.3)
sugerează în plus că fiecare paradigmă este capabilă să facă acest lucru.
Fig. 1.3 Patru paradigme de dezvoltare software
1.2.1. Paradigma procedurală
Paradigma procedurală se concentrează pe algoritmii sau pașii necesari pentru

rezolvarea unei probleme. Se descompune problema în subprobleme mai simple
reprezentate de proceduri, funcții sau metode. Descompunerea procedurală a fost
descrisă de obicei ca o ierarhie, fie o listă, fie un arbore.
Informaticienii desenează de obicei arbori ierarhici cu rădăcina (care indică
programul complet în acest caz) în partea de sus și frunzele (care indică proceduri
sau funcții individuale) în partea de jos. Nu au existat reguli bine definite pentru
efectuarea unei descompuneri sau pentru a determina când funcțiile au fost suficient
de simple pentru a permite ca programarea să înceapă. Aceasta înseamnă că doi
practicanți programatori diferiți, dar cu experiență, ar putea crea două modele destul
de diferite. Este relativ ușoară, urmând această paradigmă, trecerea de la proiectare
și analiză la implementare. Cu toate acestea, pe măsură ce dimensiunea și
complexitatea problemei crește, paradigma procedurală începe să sufere de un
decalaj mare între domeniul problemei (adică lumea reală) și analiză și proiectare.
Conexiunea dintre problemă și arborele funcțiilor este arbitrară și în mare parte
intangibilă și, ca rezultat, paradigma procedurală produce o înțelegere slabă a
domeniului problemei. În plus, arborii funcționali rezultați sunt dificil de urmărit de
clienți, iar modificările descompunerii (adică arborii ) au efecte pe scară largă care
se scurg imprevizibil printre arbori. În cele din urmă, paradigma procedurală și
arborii ei de descompunere asociați duc adesea la date globale și funcții cuplate

(discutate mai târziu). Cu toate acestea, modelul procedural este încă adecvat pentru
programe mici și simple, iar ceea ce învățăm în timp ce studiem modelul procedural
se va putea trece la studiul paradigmei orientate obiect [1.6].
Fig. 1.4 Paradigma procedurală de dezvoltare software
1.2.2. Paradigma bazată pe date
Paradigma bazată pe date presupune un element dintr-o diagramă a fluxului

de date: date (săgeți) care intră și ies dintr-un proces (un cerc sau o bulă). Numeroase
paradigme bazate pe date au fost utilizate, dar fiecare dintre aceste sub-paradigme
avea o caracteristică esențială în comun: au urmărit datele pe măsură ce au intrat în
sistem, au trecut prin procese care au transformat datele și a continuat să urmărească
datele până când au părăsit sistemul.
Fluxurile de date au fost modelate ca săgeți de date care intră și ies din bule
de proces. Uneori, mai multe săgeți intrau într-un balon și erau îmbinate într-un
singur flux de ieșire; uneori, un singur flux a intrat doar pentru a fi separat în fluxuri
multiple părăsind procesul. Rezultatul final a fost o rețea de date și procese care a
descris o anumită problemă. O analiză bazată pe oricare dintre paradigmele bazate
pe date a dus la o mai bună înțelegere a domeniului problemelor decât o analiză bazată
pe o descompunere procedurală. Mai mult, modelele problemei create în timpul

analizei și elaborate în timpul proiectării au fost mai utile în majoritatea contextelor
decât modelele corespunzătoare bazate pe paradigma procedurală. Mai exact,
modelele bazate pe fluxul de date au oferit un suport mai bun pentru testarea, validarea
și documentarea software-ului, iar diagramele fluxului de date au fost mai ușor de citit
pentru clienții familiarizați cu o problemă decât decompozițiile procedurale. Din
păcate, a existat un decalaj mare între diagramele fluxului de date și programele scrise
în faza de implementare [1.7]. Acest decalaj mare a făcut programarea dificilă și a
redus foarte mult utilitatea paradigmei bazate pe date (Fig. 1.5).
Fig. 1.5 Paradigma de dezvoltare software bazată pe date
1.2.3. Paradigma orientată pe obiecte
Paradigma orientată obiect (Fig. 1.6) încapsulează datele și procedurile sau

operațiunile care pot accesa și opera pe aceste date într-o entitate numită obiect. Un
grup de obiecte similare sunt descrise de o clasă. Clasele sunt de obicei documentate
cu o notație grafică; ilustrația de mai jos include patru clase aranjate într-o diagramă
de clase utilizând notația UML (Unified Modeling Language) [1.8].
Un dispozitiv de tăiat cookie și cookie-urile pe care le creează este o analogie
frecvent utilizată cu clasele și obiectele: clasa este ca un dispozitiv de tăiat cookie și
obiectele sunt ca cookie-urile.
La fel cum dimensiunea și forma fiecărui cookie sunt determinate de
dispozitivul de tăiere a cookie-urilor, tot așa „dimensiunea” și „forma” unui obiect
sunt determinate de clasă: clasa determină ce date și operațiuni va suporta fiecare
obiect, dar valorile stocate pentru fiecare element de date al unui obiect este
independent de celelalte obiecte.
Obiectele existente în lumea reală sunt identificate în timpul analizei și sunt
abstractizate în clase. În timpul fazei de proiectare, detaliile sunt adăugate la clase,
pot fi adăugate noi clase și unele clase pot fi eliminate, dar, în cea mai mare parte,
clasele descoperite în timpul analizei sunt reportate la proiectare. Mai mult, clasele
rafinate în timpul proiectării sunt reportate în faza de implementare.
Implementarea claselor necesită traducerea diagramelor de clasă UML într-un
limbaj de programare adecvat. Din fericire, procesul de traducere este bine definit și
unul la unu (ceea ce înseamnă că, în afară de nuanțele cosmetice, există o singură
modalitate de a face traducerea). Mai fundamental, conceptele de clase și obiecte nu
se schimbă de la o fază la alta. Această consistență conceptuală formează punți între
lumea reală, analiză și proiectare și implementare.
Fig. 1.6 Paradigma de dezvoltare software orientată pe obiecte
Abilitatea paradigmei orientate pe obiecte de a acoperi decalajele dintre faze și

de a netezi procesul de dezvoltare este doar unul dintre atuurile sale. Păstrează cele
mai bune caracteristici ale paradigmelor procedurale și bazate pe date în timp ce
depășește sau minimizează cele mai grave caracteristici ale acestora. De exemplu,
deoarece obiectele reprezintă date, modelele create în timpul analizei oferă aceeași
înțelegere a domeniului problemei ca și paradigmele bazate pe date. Dar, deoarece
clasele denotă și operațiuni sau proceduri, trecerea de la proiectare la implementare
este mult mai ușoară. Mai mult, întrucât fiecare clasă definește un nou domeniu
intermediar (regiunea unui program în care o variabilă este vizibilă și accesibilă),
paradigma orientată obiect permite, de asemenea, unor proceduri dintr-un program,
dar nu toate, să acceseze datele. Controlul accesului la date reduce cuplarea funcțională
care, în cele din urmă, stabilește o limită superioară pentru dimensiunea și
complexitatea sistemelor software care ar putea fi create practic pe baza paradigmei
procedurale. Numeroasele puncte forte ale paradigmei orientate obiect fac din aceasta
cea mai bună practică actuală pentru crearea de sisteme software mari și complexe.
1.3 Introducere în UML
Unified Modeling Language (UML) este un limbaj vizual pentru

reprezentarea proiectelor și modelelor software. Dacă detaliem un pic mai adânc,
veți descoperi că UML poate fi aplicat la câteva domenii diferite și poate capta și
comunica totul, de la organizarea companiei la procesele de afaceri, până la
software-ul distribuit al întreprinderii.
Se intenționează a fi un mod obișnuit de a capta și exprima relații,
comportamente și idei la nivel înalt într-o notație ușor de învățat și eficient de scris.
UML este vizual; cam tot ce conține are o reprezentare grafică. De-a lungul acestei
cărți vom discuta despre semnificația diferitelor elemente UML, precum și despre
reprezentările lor [1.9].
UML este legat de proiectarea și analiza orientată pe obiecte [1.10]. UML
utilizează elemente și formează asociații între ele pentru a forma diagrame (Fig. 1.7).
Diagramele din UML pot fi clasificate în general ca:
▪ diagrame structurale, care includ:
o diagrame componente;
o diagrame obiecte;
o diagrame de clasă;
o diagrame de desfășurare;
▪ diagrame de comportament, care includ:
o diagrame de caz de utilizare;
o diagrame de stare;
o diagrame de activitate;
o diagrame de interacțiune.
Fig. 1.7 Ierarhia diagramelor conform UML
I. Conceptele orientate pe obiecte utilizate în UML:

▪ clasa - definește tiparul albastru, adică structura și funcțiile unui obiect.
▪ obiect – se ocupă cu descompunerea și modularizarea sistemelor mari,
prin modularizare sistemul se poate împărți în componente ușor de înțeles,
astfel încât, sistemul se poate construi bucată cu bucată. Un obiect este

unitatea fundamentală (element de construcție) al unui sistem care este
utilizat pentru a descrie o entitate;
▪ moștenire - este un mecanism prin care clasele mici moștenesc
proprietățile claselor de bază;
▪ abstracție – este mecanism prin care detaliile de implementare sunt
ascunse utilizatorului;
▪ încapsulare – este procesul prin care datele sunt legate împreună și
protejate de mediul exterior;
▪ polimorfism – este mecanismul prin care funcțiile sau entitățile sunt
capabile să existe sub diferite forme.
II. Diagrame structurale UML:
▪ diagrama de clasă - este cea mai utilizată, reprezintă elementul de bază al
tuturor sistemelor software orientate obiect. Diagramele de clasă sunt
folosite pentru:
o a descrie structura statică a unui sistem, arătând clasele sistemului,
metodele și atributele acestora;
o identificarea relațiilor dintre diferite clase sau obiecte;
▪ diagrama structurii compozite – se folosește pentru a reprezenta structura
internă a unei clase și punctele sale de interacțiune cu alte părți ale
sistemului. O diagramă de structură compusă reprezintă relația dintre părți
și configurația lor care determină modul în care se comportă clasificatorul.
Ele reprezintă structura internă a unui clasificator structurat care utilizează
piese, porturi și conectori. De asemenea, se pot modela colaborări folosind
diagrame structurale compozite. Acestea sunt similare cu diagramele de
clasă, cu excepția faptului că reprezintă părți individuale în detaliu
comparativ cu întreaga clasă;
▪ diagrama obiectelor - poate fi menționată ca o captură de ecran a
instanțelor dintr-un sistem și a relației care există între ele. Deoarece
diagramele de obiecte descriu comportamentul atunci când obiectele au
fost instanțiate, apare și posibilitatea studierii comportamentului
sistemului la un anumit moment. O diagramă obiect este similară cu o
diagramă de clase, cu excepția cazului în care arată instanțele claselor din
sistem. Prezentăm clasificatori actuali și relațiile lor folosind diagrame de
clasă. Pe de altă parte, o diagramă de obiecte reprezintă instanțe specifice
de clase și relații între ele la un moment dat;
▪ diagrama componentelor - sunt utilizate pentru a reprezenta modul în care
au fost organizate componentele fizice dintr-un sistem. Se pot folosi
pentru modelarea detaliilor de implementare. Diagramele componente
descriu relația structurală dintre elementele sistemului software și dacă
cerințele funcționale au fost acoperite de dezvoltarea planificată.
Diagramele componente devin esențiale de utilizat atunci când se
proiectează și se construiesc sisteme complexe. Interfețele sunt utilizate
de componentele sistemului pentru a comunica între ele;
▪ diagrama de implementare - este folosită pentru a reprezenta hardware-ul

sistemului și software-ul său. Ne spune ce componente hardware există și
ce componente software rulează pe ele. Permite ilustrarea arhitecturii
sistemului ca distribuție a artefactelor software peste țintele distribuite.
Un artefact este informația generată de software-ul sistemului. Acestea
sunt utilizate în principal atunci când un software este utilizat, distribuit
sau implementat pe mai multe mașini cu configurații diferite.
▪ diagrama pachet – se folosesc pentru a descrie modul în care pachetele și
elementele lor au fost organizate. O diagramă a pachetelor arată pur și
simplu dependențele dintre diferite pachete și compoziția internă a
pachetelor. Pachetele permit organizarea diagramelor UML în grupuri
semnificative și să faciliteze înțelegerea diagramelor. Ele sunt utilizate în
principal pentru a organiza clase și pentru a utiliza diagrame de cazuri.
III. Diagrame de comportament8:
▪ diagrame ale mașinilor de stare - sunt utilizate pentru a reprezenta starea
sistemului sau a unei părți a sistemului în instanțe de timp finite. Este o
diagramă comportamentală și reprezintă comportamentul utilizând
tranziții în stare finită. O diagramă de stare este utilizată pentru a modela
comportamentul dinamic al unei clase ca răspuns la timp și la schimbarea
stimulilor externi.
▪ diagrame de activitate – sunt folosite pentru a ilustra fluxul de control într-
un sistem. Se pot folosi pentru a ne referi la pașii implicați în executarea
unui caz de utilizare. Se pot utiliza pentru a modela activități secvențiale și
concurente folosind diagrame de activitate. Fluxurile de lucru vizual se pot
reprezenta folosind o diagramă de activitate. O diagramă de activitate se
concentrează pe starea fluxului și secvența în care se întâmplă;
▪ diagramele de caz de utilizare - sunt utilizate pentru a descrie
funcționalitatea unui sistem sau a unei părți a unui sistem. Acestea sunt
utilizate pe scară largă pentru a ilustra cerințele funcționale ale sistemului
și interacțiunea acestuia cu agenți externi. Un caz de utilizare este practic o
diagramă care reprezintă diferite scenarii în care sistemul poate fi utilizat.
O diagramă de caz de utilizare ne oferă o vizualizare la nivel înalt a ceea ce
face sistemul sau o parte a sistemului fără a intra în detaliile implementării;
▪ diagrama de secvență - descrie pur și simplu interacțiunea dintre obiecte
într-o ordine secvențială, adică ordinea în care au loc aceste interacțiuni.
De asemenea, putem folosi termenii diagrame de evenimente sau scenarii
de evenimente pentru a face referire la o diagramă de secvență.
Diagramele secvențiale descriu cum și în ce ordine funcționează obiectele
dintr-un sistem. Aceste diagrame sunt utilizate pe scară largă în business
și de către dezvoltatorii de software pentru a documenta și a înțelege
cerințele sistemelor noi și existente;
8
https://developer.ibm.com/articles/an-introduction-to-uml/
▪ diagrama de comunicare - este utilizată pentru a afișa mesaje secvențiale

schimbate între obiecte. O diagramă de comunicare se concentrează în
principal pe obiecte și relațiile lor. Poate reprezenta informații similare
folosind diagrame de secvență, cu toate acestea, diagramele de
comunicare reprezintă obiecte și legături într-o formă liberă;
▪ diagrama de sincronizare - este o formă specială de diagrame de secvență,
care sunt utilizate pentru a descrie comportamentul obiectelor pe o
perioadă de timp. Se folosesc pentru a arăta constrângerile de timp și de
durată, care guvernează schimbările de stări și comportamentul
obiectelor;
▪ diagrama generală a interacțiunii - modelează o succesiune de acțiuni și
simplifică interacțiunile complexe în apariții mai simple. Este un amestec
de diagrame de activitate și secvență.
La nivel global una dintre problemele care prezintă interes o reprezintă
creșterea numărului persoanelor cu dizabilități și vârstnici, care necesită vehicule de
transport personal: autoturisme, scaune pe roți etc. În general oamenii au capacități
limitate de a opera cu asmenea dispozitive în medii complexe: spații comerciale,
centre de atracție turistică, spații publice care presupun parcurgerea unor trasee prin
zone cu circulație rutieră, etc.
Aplicațiile pentru roboți mobili necesită o abordare de proiectare bazată pe
modele întregi de procese de dezvoltare. Proiectele dezvoltate au urmărit ca
software-ul să permită creșterea mobilității persoanelor vârstnice și cu dizabilități.
În acest sens [1.11], AIST (The National Institute of Advanced Industrial Science
and Technology - Institutul Național de Științe și Tehnologii Industriale Avansate),
din a dezvoltat RTM (Robot Technology Middleware – Tehnologie Robotică
Middleware) pentru a obține eficiență în dezvoltarea de componente software pentru
robot. Ideea este de a dezvolta module software robotizate privind din analiza
ingineriei de sistem. Acest lucru se datorează faptului că majoritatea sistemelor
robotizate sunt sisteme integrate încorporate. Abordările de inginerie a sistemului se
concentrează pe proiectare și construirea sistemului complet și pe furnizarea de
capacități de reutilizare a modelului. Aceste abordări pot îmbunătăți comunicarea
între echipele de dezvoltare, specificații și calități de proiectare și reutilizarea
specificațiilor sistemului și artefacte de proiectare.
Arhitectura bazată pe modele, adoptă o abordare MDA (Model Driven
Architecture) pentru utilizarea modelelor în dezvoltarea de software robot. Acesta
prescrie anumite tipuri de modele care trebuie utilizate, modul în care sunt pregătite
aceste modele și asocierea relațiilor celorlalte tipuri de modele. Abordarea MDA este
o abordare de proiectare software pentru dezvoltarea sistemelor software care descrie
conținutul modelelor prin dezvoltarea unui limbaj neutru și separat de software-ul de
proiectare a implementării. Scopul MDA este de a schimba informațiile de proiectare
din software-ul implementat în software independent prin descrierea conținutului
codat al unui model specific de limbaj. Acest lucru permite dezvoltarea informațiilor
de proiectare în mod independent, făcând posibilă schimbarea lor fără utilizarea
software-ului de implementare. În MDA, modelul abstract de informații se numește
Model Independent de Platformă (PIM - Platform Independent Model), iar modelul

care corespunde unui limbaj de programare specific se numește Model Specific
Platformei (PSM - Platform Specific Model). Nevoia de MDA în dezvoltarea de
software robotizat MDA este considerat foarte util în dezvoltarea de software
robotizat. Grupul de lucru OMG Robotics Domain (OMG Robotics DTF, 2005) care
își propune să promoveze și să integreze standardele robotului OMG, a prezentat un
exemplu de MDA, care a fost conceput pentru sisteme robotice, ar trebui introdus și
extins în întregul domeniu robotizat.
MDA este considerat foarte eficient în gestionarea problemelor funcționale de
descompunere în modulul de informații. Problemele de descompunere funcțională
sunt probleme care apar în timpul divizării unui sistem robotizat datorită diferitelor
modalități de a împărți funcționalitatea în componente[1.11]. Rezolvarea acestei
probleme s-a făcut prin standardizarea unității de diviziune în funcție de misiunile
robotului. Descompinerea din punct de vedere funcțional a modulelor cu o cooperare
reciprocă, ajută la schimbul și continuitatea realizării de noi module. Acest lucru este
similar cu modul de implementare a Arhitecturii Orientate către Servicii (Service-
Oriented Architecture - SOA), care depinde de modul de partiționare a serviciilor.
Astfel, problemele datorate reutilizării pot fi rezolvate atât MDA, cât și SOA. Cu
toate acestea din cauza modului în care se împart funcționalitățile în componente se
preferă o abordare MDA în locul celei SOA.
1.4 Introducere în SysML
Limbajul de Modelare al Sistemelor (Systems Modeling Language –

SysML) are un scop general, care este asociat doar cu semantica descriptivă. A fost
dezvoltat pentru a sprijini specificarea, analiza, proiectarea, verificarea și validarea
unei game largi de sisteme complexe (OMG SysML, 2010). <<block>> este unitatea
de bază a structurii în SysML și poate fi utilizat pentru a reprezenta sistemele care
pot include hardware, software, informații, procese, personal și facilități. SysML are
rolul de a uni diversele limbaje de modelare utilizate în prezent de inginerii de sistem.
SysML reutilizează un subset de limbaj de modelare unificat (OMG UML) și oferă
extensii suplimentare necesare pentru a aborda aspecte de inginerie a sistemelor care
nu sunt acoperite de UML2. În Fig. 1.1 se poate observa cum SysML este utilizat
pentru a specifica cerințele sistemului, comportamentul, structura și relațiile
parametrice. Diagrama cerințelor și diagramele parametrice sunt noile tipuri de
diagrame propuse de SysML.
SysML oferă construcții de modelare pentru a reprezenta cerințele bazate pe
text și pentru a le raporta la alte elemente de modelare. Diagrama cerințelor poate fi
utilizată pentru a reprezenta relațiile care există între cerințe și pentru a le vizualiza.
Oferă o punte între instrumentele tradiționale de gestionare a cerințelor și alte modele
SysML. Poate fi folosit pentru a descrie cerințele în format grafic, tabelar sau de
structură arborescentă și pentru a evidenția relațiile dintre cerințe și alte elemente
model care le satisfac sau le verifică.
Fig. 1.8 Taxonomia diagramelor SysML și comparația sa cu UML

(OMG SysML
1.4.1. Abordarea modelării
Progresul abordării bazate pe model este prezentat prin adoptarea limbajului

de modelare standard internațional SysML pe tot parcursul procesului de proiectare.
Studierea diagramelor realizate din construcții SysML, ridică două probleme privind
îmbunătățirea reutilizării modulelor, cum ar fi divizarea inteligentă a modulelor și
dezvoltarea de sisteme bazate pe modulele inteligente.
1.4.2. Scopul
Adoptarea unei abordări bazate pe model pentru a face modelele de robot

independente de orice platformă hardware și software specifică, derivă dintr-un
model de robot reutilizabil și versatil. Pentru a face tranziția fără efort de la modele
la sistem real, se folosesc componente RT existente. Există trei direcții principale:
1. construirea unui modelul pentru fiecare proces pentru a putea dezvolta,
ulterior, modelele reutilizabile, adoptând abordarea bazată pe model
pentru fiecare proces de proiectare, de la analiza funcțională de bază a

robotului mobil inteligent până la analiza finală a sistemului, în funcție de
implementare. Astfel, se va putea alege o decizie de proiectare adecvată,
exprimată ca modele. Spre exemplu:
a. dacă cerința este aceeași, dezvoltatorii vor reutiliza diagrama de cerințe
existentă;
b. în caz contrar, numai fluxul de lucru de proiectare ar trebui reutilizat;
2. proiectarea separată la nivelul PIM și PSM. Procesul de modelare constă
în proiectarea modelului independent de platformă și proiectarea
modelului specificat de platformă;
3. îmbunătățirea reutilizării PSM se face prin utilizarea RT-Middleware în
dezvoltarea platformei software pentru a putea îmbunătăți reutilizarea
modulului software și a sistemului.
1.4.3. Procesul de modelare
Activitatea de modelare constă în Fig. 1.9:

• proiectarea de bază a inteligenței mișcării – caseta roșie;
• proiectarea sistemului de inteligență a mișcării – caseta albastră;
• proiectarea sistemelor software interne – caseta verde
1) analiza contextului: relevă mediul presupus și este utilizată pentru
derivarea analizei cerințelor și a analizei funcționale, rezultând o
diagramă de context;
2) analiza cerințelor; organizeză cerințele funcționale și nefuncționale
bazate pe mediul presupus și limitările, realizând cerințele și se stabilesc
legăturile între cerințele conexe obținând soluția pentru fiecare cerință;
3) analiza cazurilor: sunt descrise funcțiile necesare pe baza cerinței
funcționale, utilizând în această fază diagrama cazului de utilizare;
4) analiza structurii hardware: permite organizarea conexiunilor hardware
abstractizate datorită utilizării diagramelor de definiție a blocurilor;
5) analiza funcțională a software-ului; afișează software-ul, inclusiv relațiile
sale, fiecare bloc software fiind extras din funcțiile necesare;
6) analiza structurii software: definește interfața fiecărui modul utilizând
Diagrame Blocare Interne (IBD);
7) analiza specificațiilor software: arată cum este definit comportamentul
său intern;
8) analiza comportamentală: comportamentele sistemului software sunt
proiectate folosind Diagrama secvenței (SD) și State Machine (STM);
9) selectarea RTC: blocurile RTC sunt alese pentru a fi mapate din modulele
software proiectate;
10) implementarea sistemului: pasul final pentru testarea și evaluarea unor
părți ale modulelor proiectate implementate pe o platformă reală a
robotului.
Fig. 1.9 Procesul general de proiectare și fluxurile de lucru de modelare.
1.5 Cicluri de viață software
Activitățile care fac de obicei parte din procesul sistematic de inginerie

software vor avea loc pe durata de viață a unui produs software. Aceste activități pot
avea loc într-o succesiune rigidă. Înainte de începerea următoarei activități sau a mai
multor activități simultan, trebuie finalizată fiecare activitate anterioară. Activitățile
pot fi efectuate o singură dată sau de mai multe ori, caz în care cerințele sunt
finalizate numai după ce au fost realizate mai multe proiecte și implementări ale
codului sursă. Momentul acestor activități și alegerea între metodele iterative și
noniterative sunt adesea descrise de ceea ce sunt cunoscute sub numele de modele
de dezvoltare software (SDLC - The Software Development Life Cycle).
Există șapte modele de bază ale ciclurilor de viață pentru dezvoltare software:
• model clasic tip cascadă;
• model de prototipare rapidă;
• model în spirală;
• model bazat pe piață;
• model de dezvoltare open source;
• model de dezvoltare agil;
• model de dezvoltare simultană hardware și software, sau cod de dezvoltare.
Descrierea, în continuare, modelelor este corespunzătoare unor procese ideale.
În realitate existe multe variații ale proceselor în aproape orice proiect real de
dezvoltare software.
1.5.1. Modelul SDLC tip cascadă
Unul dintre cele mai comune modele ale procesului de dezvoltare software se
numește ,,model clasic de cascadăˮ și este ilustrat în Fig. 1.10. Acest model este
utilizat aproape exclusiv în situațiile în care există un client pentru care este creat
software-ul.
Fig. 1.10 Modelul clasic tip cascadă.
Modelul nu se aplică în esență niciodată în situații în care nu există un client

cunoscut, cum ar fi cazul software-ului conceput pentru piața comercială pentru mai
mulți cumpărători cu amănuntul.
Acest model tip cascadă clasică, consideră că diferitele activități din ciclul de
viață al software-ului au loc secvențial. Singura excepție este că două activități care
sunt adiacente (Fig. 1.10) au voie să comunice prin feedback. Acest artificiu a
determinat ca modelul cascadă să nu mai fie utilizat pe scară largă în industrie. Un
alt motiv este acela că schimbările tehnologice pot face ca setul original de cerințe
să devină depășit. Cu toate acestea, modelul poate fi informativ ca o ilustrare a unui
model al ciclului de viață al dezvoltării software.
Un model al ciclului de viață (Fig. 1.10) ilustrează succesiunea multor
activități majore de dezvoltare software. Spre exemplu, specificațiile cerințelor unui
sistem vor avea loc înainte de testarea modulelor individuale. De asemenea,
feedback-ul există doar între anumite perechi de activități:
• specificații cerințe și proiectare software;
• proiectarea și implementarea codului sursă;
• codificare și testare;
• testare și întreținere.
Din Fig. 1.10 nu rezultă în schimb relația dintre diferitele activități și momentul
în care o activitate se termină și începe următoarea. Prin urmare modelul clasic tip
cascadă este o secvență de repere în care fiecare două faze adiacente ale interfeței
ciclului de viață au un feedback. Un exemplu simplu de diagramă de referință pentru
un proces de dezvoltare software care se bazează pe modelul clasic de cascadă este
dat în Fig. 1.11.
Fig. 1.11 Diagramă de referință pentru un proces de dezvoltare software cascadă.
Cerințele pentru sistem sunt de obicei prezentate într-o serie de revizuiri ale
cerințelor: preliminare, intermediare și finale sau critice. Toți cei care utilizează de
pentru dezvoltarea software modelul clasic tip cascadă, consideră revizuirea
cerințelor critice acceptate de către proiectanți și clienți ca sfârșitul „oficial” al fazei
cerințelor.
Orice activitate desfășurată în perioada dintre revizuirea preliminară și cea
finală, poate fi refăcută dacă nu mai este în concordanță cu modificările
cerințelor.
Granița dintre specificațiile cerințelor și fazele de proiectare ale modelului
clasic tip cascadă nu au nimic special. Același lucru este valabil și pentru fazele de
proiectare și implementare, întrucât proiectarea sistemului este aprobată după cum
urmează: o revizuire preliminară, una intermediară și una finală. Modelul se aplică
și celorlalte interfețe ale fazelor oricărui ciclu de viață.
Acest model clasic tip cascadă este utili pentru proiectele de dezvoltare
software la care cerințele sistemului trebuie determinate într-o perioadă rezonabilă
și, în plus, aceste cerințe nu se vor schimba foarte mult în perioada de dezvoltare.
1.5.2. Modelul de prototipare rapidă
Întrucât modelul clasic tip cascadă necesita un timp îndelungat între

stabilirea cerințelor și livrarea unui produs, s-a dezvoltat modelul de prototipare
rapidă. Acest model este iterativ și necesită crearea unuia sau mai multor
prototipuri ca parte a procesului de dezvoltare software. Modelul se poate aplicat
indiferent dacă există sau nu un client cunoscut. Prototiparea rapidă este ilustrată în
Fig. 1.12.
Fig. 1.12 Modelul de prototipare rapidă.
Modelul de prototipare rapidă a dezvoltării software-ului se bazează pe faptul

că specificația completă a cerințelor software-ului nu este cunoscută înainte ca
software-ul să fie proiectat și implementat. Dezvoltarea software-ului fiind realizată
treptat, specificațiile sunt dezvoltate împreună cu software-ul în sine. Punctul central
al metodei de prototipare rapidă este că proiectul software final produs este
considerat cel mai acceptabil dintr-o secvență de prototipuri software.
În general un sistem (spre exemplu de operare) nu a poate fi specificat complet
în avans, deoarece interfața cu utilizatorul ar trebui să fie testată mai înainte de a
exista produsul. Iterațiile succesive ale software-ului permit de fapt intervenția
utilizatorilor pe interfața specializată. În acest fel caracteristicile cu o anumită
valoare vor fi percepute, astfel încât, utilizatorii potențiali să poată interveni de pe
browserele lor de Internet. Există multe pachete software și suite întregi de
instrumente pentru dezvoltarea site-urilor web.
Oricine creează site-uri web complexe, cu intensitate grafică, trebuie să fie
conștient de diferențele dintre modul în care aceste browsere afișează unele tipuri de
informații. De aceea există multe stiluri de codificare a paginilor web care odată erau
populare, dar care au devenit învechite. Un exemplu îl reprezintă efectul stilurilor de
codare, în contextul unui proiect de inginerie software care ilustrează utilizarea
continuă a mai multor prototipuri.
Metoda presupune o separare mică a obiectelor și atributelor, care este o temă
obișnuită a programării orientate pe obiecte. Problema care se ridică (pentru acest
model) este că retururi în întregul cod se introduc manual, deoarece instrucțiunile
HTML sunt produse, în general, fără pauze.
Unul dintre primii pași ai procesului de modificare a unui cod îl reprezintă
introducerea retururilor de transport dur și verificarea faptului că fiecare inserție lasă
neschimbată funcționalitatea paginii web relevante. Odată remediate întreruperile de
linie, astfel încât, să se poată fi citi inteligent codul, se pot dezvolta câteva convenții
de denumire pentru numele fișierelor. Apoi se încarcă paginile web pe rând,
verificând toate hyperlinkurile și schimbând numele fișierelor în convențiile
standard de denumire pe măsură ce procesul evoluează. De reținut că trebuie creată

o foaie de calcul, care să precizeze toate modificările efectuate și dacă acestea au
rezolvat problemele.
Ultimii doi pași constau în instalarea unui sistem de baze de date care a fost
construit deasupra unei baze de date (spre exemplu mySQL) și crearea unei zone
protejate numai pentru accesul membrilor.
Pentru ca un ciclu de viață iterativ să fie eficient, trebuie să existe un pas inițial
pentru a începe procesul. În modelul de prototipare rapidă descris în , este necesar
un set inițial de specificații pentru a începe procesul de prototipare. În exemplul
nostru de reproiectare a unui site web, specificațiile au fost să reproducă cât mai mult
posibil funcționalitatea site-ului original.
De asemenea, trebuie să existe un ciclu iterativ pentru a actualiza și revizui
prototipurile Fig. 1.12. În cele din urmă, trebuie să existe o modalitate de a ieși din
ciclul de iterație. Acest pas este indicat în Fig. 1.12 prin pasul „evaluare prototip”.
Baza evaluării este completitudinea percepută, corectitudinea, funcționalitatea și
utilizabilitatea prototipului. Această evaluare este variabilă de la organizație la
organizație. În multe cazuri, prototipul final este livrat ca produs final; în altele,
prototipul final servește doar ca bază pentru produsul final livrat.
O diagramă de referință poate fi, de asemenea, dezvoltată pentru metoda de
prototipare rapidă a dezvoltării unui software. Un grafic de eșantion pentru modelul
procesului de prototipare rapidă este ilustrat în Fig. 1.13.
Fig. 1.13 Diagramă de referință pentru un proces de prototipare rapidă.
1.5.3. Modelul tip spirală
Modelul spiralat pentru dezvoltarea software-ului este un ciclu de viață

iterativ. Modelul în spirală (Fig. 1.14) diferă de modelul de prototipare rapidă
prin accentul explicit pe evaluarea riscului al prototipului în timpul perioadei de
evaluare.
Pentru a descrie potențialul dezastru al unui proiect de software s-a introdus
termenul de risc.
Fig. 1.14 Modelul tip spirală.
Acest model nu se aplică aproape niciodată proiectelor pentru care nu există

un client cunoscut. Există mai multe niveluri de dezastre, de organizații și proiecte
total diferite, care pot vedea situațiile identice în mod diferit.
Dintre situațiile considerate dezastruoase amintim:
▪ echipa de dezvoltare software nu este capabilă să producă software-ul în
limita bugetului și programului alocat;
▪ echipa de dezvoltare software este capabilă să producă software-ul dar
depășește bugetul;
▪ echipa de dezvoltare software după cheltuieli considerabile de timp și
resurse, stabilește că cerințele stabilite pentru software nu pot fi îndeplinite.
Planificarea face parte, de asemenea, din procesul iterativ utilizat în modelul
de dezvoltare spirală.
Fig. 1.15 Diagramă de referință pentru un proces tip spirală.

Diagrama de referință utilizată pentru procesul de dezvoltare spirală re

regășește în Fig. 1.15. Pentru simplitate, este inclusă doar o mică parte a unei
diagrame de referință.
Atât modelele de prototipare rapidă, cât și modelele în spirală sunt clasificate
ca fiind iterative, deoarece există mai multe cazuri de software intermediar care pot
fi evaluate înainte ca produsul final să fie produs.
Este ușor de observat diferența dintre abordările iterative și modelul clasic de
cascadă. Modelul tip cascadă nu are nici o prevedere pentru iterație și interacțiune
cu un potențial client după finalizarea cerințelor.
1.5.4. Model de dezvoltare software bazat pe piață
Oricare dintre modelele ciclului de viață al dezvoltării software descris

anterior nu se aplică direct dezvoltării moderne a software-ului pentru piața generală
de consum. Modelele discutate anterior au plecat de la premiza că a existat timp
pentru o analiză relativ completă a cerințelor inițiale.
Aceste modele nu abordează realitățile dezvoltării de software pentru calculatoare
personale și diferite dispozitive mobile. În realitate cerințele sunt generate de
consumatori, care caracteristici noi pentru a-și putea menține sau chiar crește cota de
piață.
Aceasta este o abordare relativ nouă a dezvoltării de software și care nu se
bazează pe elemente standardizate (precise) acceptate în mod obișnuit.
Se poate aprecia, astfel, că marketing-ul fiecărei organizații adaugă noi
caracteristici, chiar dacă produsul se apropie de data țintei de lansare. Astfel, nu
există un concept de „înghețare a cerințelor”, care era o presupunere comună,
nescrisă, a tuturor modelelor anterioare în diferite etape de dezvoltare. Astfel, a
apărut noțiunea de „inginerie concurentă” bazată pe piață (Fig. 1.16).
Chiar și aplicațiile mici, scrise de un singur programator, au un ciclu de
întreținere așteptat, ceea ce duce la lansări noi. Spre exemplu, o aplicație pentru un
telefon mobil, care a avut un număr destul de mare de descărcări. Dacă se constată o
eroare sau se schimbă tehnologia de bază, aplicația trebuie actualizată. Dacă
dezvoltatorul nu face acest lucru sau este lent în efectuarea modificărilor, rezultă
recenzii proaste, iar vânzările vor scădea.
Fig. 1.16 Diagramă de referință pentru un proces bazat pe piață.

Astăzi, dezvoltarea de software pentru o piață de clienți necunoscuți este mult

mai rentabilă și mult mai ușor de distribuit.
1.5.5. Model de dezvoltare Open-Source
Dezvoltarea de software open source se bazează pe convingerea fundamentală

că din punct de vedere al proprietății intelectuale software-ul ar trebui să fie
disponibil pentru oricine în mod gratuit. Prin urmare, codul sursă pentru orice proiect
ar trebui să fie disponibil public pentru ca oricine să îl poată accesa și modifica.
Punerea la dispoziție a codului sursă este partea ușoară. Dificultatea constă în
obținerea diverselor componente ale codului sursă dezvoltate de o mare varietate de
persoane adesea separate geografic pentru a fi organizate, clasificate, întreținute și
de o calitate suficientă pentru a putea fi utilizate.
Se pune întrebarea: Cum se face acest lucru? Pentru a răspunde la această
întrebare, se definesc două categorii de proiecte open source:
1) limbaje de calculator noi, compilatoare, biblioteci de software și funcții de
utilitate care sunt create pentru binele comun;
2) reutilizarea versiunilor open source ale acestor limbaje de calculator,
compilatoare, biblioteci software și funcții utilitare pentru a crea un nou
sistem software pentru un scop specific.
O persoană sau un grup cu autoritate decide că ar trebui creat un anumit tip de
aplicație software sau utilitar. Cerințele inițiale sunt stabilite și se dezvoltă un număr
relativ mic de module software. Acestea sunt puse la dispoziția publicului
comunității open source prin intermediul publicării pe un site web, posibil unul
separat de cel care conține proiecte relativ complete. Ideea este că există o
comunitate de dezvoltatori care doresc să contribuie la proiect. Acești dezvoltatori
lucrează la unul sau mai multe module relevante de cod sursă și testează performanța
modulelor, apoi trimit modulele spre aprobare către persoana sau grupul care au pus
la dispoziție codul sursă. După o nouă testare modulele care par satisfăcătoare sunt
încărcate pe un site web de unde oricine le poate descărca, citi și testa codul sursă.
Oricine poate face comentarii despre cod și oricine îl poate modifica. Singura regulă
este că modificările trebuie să fie puse la dispoziția oricui, atâta timp cât codul sursă
este întotdeauna disponibil, fără taxe.
1.5.6 Model de dezvoltare Agile
Conceptul de dezvoltare agilă pot fi atribuit eforturilor „Skunk Works” de a

proiecta software pentru Lockheed Martin. Termenul „Skunk Works” „este un alias
oficial pentru programele avansate de dezvoltare ADP (Advanced Development
Projects) ale lui Lockheed Martin, denumite anterior Lockheed Advanced
Development Projects”. „Skunk Works” a ieșit în prim plan la începutul anilor 1940
, în timpul celui de-al doilea război mondial. Termenul este încă folosit pentru a
descrie atât echipele foarte autonome, cât și proiectele lor, care sunt de obicei foarte
avansate. Multe dintre proiectele „Skunk Works” au folosit tehnologiile existente,
un precursor în dezvoltarea de software bazat pe componente, cu utilizarea eficientă
a componentelor software existente, care pot fi la fel de mari ca subsisteme întregi.

Principiile a ceea ce este acum cunoscut sub numele de programare agilă sunt cel
mai bine descrise prin „Manifestul agil”9. De reținut câteva dintre aceste principii:
• prioritatea cea mai mare o reprezintă satisfacerea clientului prin livrarea la
timp și continuă a unui software;
• clienții sunt încurajață să participe la schimbarea cerințelor, chiar și în
etapele mai înaintate ale procesului de dezvoltare;
• procesele agile valorifică schimbarea în favoarea unui avantaj competitiv
pentru client;
• reducerea timpului de livrare a software-ului;
• clienții și dezvoltatorii de software trebuie să lucreze împreună pe tot
parcursul proiectului;
• proiectele trebuie construite în jurul unor indivizi motivați, oferind-ule un
mediu și un sprijin de care au nevoie și mai laes să li se confere gradul
necesar de încredere în ei pentru a putea performa;
• aplicarea ședințelor pe principiul ,,față în fațăˮ;
• principala măsură a progresului o reprezintă rezultatul finit;
• rocesele agile promovează o dezvoltare durabilă;
• sponsorii, dezvoltatorii și utilizatorii ar trebui să poată menține un ritm
constant;
• se urmărește excelența tehnică și designul bun;
• simplitatea este esențială, ea permițând maximizarea cantității de muncă
neefectuată;
• cele mai bune arhitecturi, cerințe și designuri apar din echipele de auto-
organizare;
• la intervale regulate, echipa reflectă la modul de a deveni mai eficient, apoi
își reglează și își ajustează comportamentul în consecință
Unele dintre aceste principii pot părea evidente:
• dezvoltarea agilă este o formă de prototipare;
• depinde de un corp mare existent de componente de înaltă calitate;
• datorită disponibilității seturilor de instrumente, acest model funcționează bine
și pentru software-ul sub formă de aplicații destinate dispozitivelor mobile.
Un exemplu principal în acest sens este disponibilitatea cadrelor gratuite
pentru dezvoltarea jocurilor pe computer. Termenul ,,SCRUMˮ este adesea folosit
în contextul dezvoltării agile. Termenul a fost motivat de sportul rugby. Acest termen
este scris cu majuscule și este modelul cel mai utilizat.
1.6 Metodologia Agile bazată pe UML
UML-ul reprezintă o soluție deosebit de potrivită pentru dezvoltarea software.

Un element central îl constituie MBD (Model-Based Development – Dezvoltarea
9 http://agilemanifesto.org/principles.html
bazată pe model). Astfel, s-au putut dezvolta tehnici pentru generarea de coduri și de
testare de foring-factor UML/Pmodels [1.12].
Standardul UML trebuie să satisfacă o multitudine de cerințe de la o varietate
de influențe și, prin urmare, este în mod inevitabil supraîncărcat cu multitudinea
diferitelor diagrame de modelare cu o semantică largă și semi-clară. Multe elemente
ale standardului nu sunt adecvate, sau cel puțin nu în forma lor dată, iar alte concepte
lingvistice lipsesc în întregime.
Metodele agile, în mod special programarea extremă, au o serie de tehnici și
principii, care îmbogățesc portofoliul de inginerie software pentru anumite tipuri de
proiecte. Aceste tehnici nu implică în mod obișnuit vreo documentație creată. Ele se
concentrează asupra flexibilității, optimizând timpul de comercializare și
minimizând cantitatea de resurse utilizate.
UML este utilizat în principal în proiecte bazate pe planuri care implică un
nivel relativ ridicat de documentare și inflexibilitatea pe care aceasta o cauzează. Cu
toate acestea, comparativ cu un limbaj de programare normal, UML este mai
compact, mai cuprinzător din punct de vedere semantic și mai potrivit pentru
reprezentarea conținutului complex. Oferă avantaje semnificative pentru modelarea
cazurilor de testare și pentru evoluția transformării sistemelor software.
Scopul dezvoltării software-ului de transformare este de a descompune
procesul de dezvoltare a software-ului în pași mici, aplicabili sistematic, care sunt
gestionabili datorită efectelor lor limitate la mediul local. Refactorizarea descrie o
colecție extinsă de tehnici de transformare pentru limbajul de programare Java.
Tehnicile de refactorizare ne permit să migram codul în conformitate cu o ierarhie
de clase. De asemenea, ne permit să împărțim sau să împărțim clase, să schimbăm
atributele, să extindem sau să externalizăm părți de cod în metode separate și multe
altele. Punctul forte al tehnicilor de refactorizare se bazează pe gestionarea etapelor
de transformare individuale (denumite „mecanisme”) și capacitatea de a le combina
flexibil, ceea ce duce la îmbunătățiri mari, orientate spre obiective, în structura
software-ului. Scopul refactorizării este de a transforma un program existent, dar de
a păstra semantica. Refactorizarea este utilizată pentru a îmbunătăți calitatea
designului, păstrând în același timp funcționalitatea, mai degrabă decât pentru a
extinde funcționalitatea. Refactorizarea și evoluția funcționalității sunt activități
complementare care se pot alterna rapid în procesul de dezvoltare. Cursul unui
proiect poate fi astfel conturat așa cum se arată în Fig. 1.17. Cu toate acestea, nu
există un criteriu obiectiv pentru măsurarea „calității designului”. Abordările inițiale,
de exemplu, măsoară conformitatea cu standardele de codare, dar sunt insuficiente
pentru evaluarea mentenabilității și testabilității arhitecturii și implementării.
Pentru a verifica dacă transformările care păstrează semantica sunt corecte se
utilizează metodele de testare existente. Cu cât nivelul de calitate al metodelor de
testare este mai ridicat, crește probabilitatea de a detecta modificările defecte. Prin
refactorizare se modifică semnăturile interne ale unui subsistem. De aceea anumite
teste trebuie adaptate împreună cu codu.l Tehnicile de refactorizare vizează diferite
niveluri ale sistemului. Posibilitatea îmbunătățirii unei arhitecturi de sistem care a
fost deja realizată în cod înseamnă că a devenit mai puțin necesară definirea unei
arhitecturi de sistem corecte și stabile a priori.
Fig. 1.17 Evoluția și refactorizarea sunt complementare.
În timp ce multe tehnici de refactorizare pentru Java [1.13] sunt în prezent în curs
de dezvoltare, în prezent există doar câteva tehnici similare pentru diagramele UML.
Eficiența metodelor agile se poate îmbunătăți prin omiterea inteligentă a
lucrărilor inutile și printr-o implementare eficientă. Nu este neapărat cazul ca toate
tehnicile unei metode agile să se concentreze pe calitatea produsului dezvoltat. Cu
toate acestea, anumite elemente ale unei metode agile, cum ar fi concentrarea asupra
simplității proiectării și dezvoltarea extinsă a testelor automate, susțin îmbunătățirea
calității. Alte practici aplicate prin unele metode agile, cum ar fi lipsa specificațiilor
detaliate și a recenziilor, descurajează utilizarea metodei pentru sisteme extrem de
critice. În acest caz, trebuie selectat un proces alternativ sau o extensie adecvată.
Dacă un model este utilizat exclusiv pentru comunicare, atunci există în mod
normal doar ca desen informal. Un model creat de un instrument are o reprezentare
formală a sintaxei10 și poate fi utilizat pentru prelucrarea ulterioară susținută de
instrumente. Există două variante principale de generare a codului:
i. generarea codului produsului;
ii. generarea codului de testare.
Necesitatea adaptării software-ului pe baza schimbării cerințelor înseamnă, de
asemenea, că trebuie să fie disponibile tehnici pentru transformarea sau refacerea
modelelor. Adaptarea sistematică a modelelor la funcționalități noi și modificate într-
un proces validat în fiecare etapă prin teste automate și invarianți permite această
ajustare dinamică. Deoarece un model creat conform cerințelor date este mai
compact și, prin urmare, mai ușor de înțeles decât codul, acest lucru îmbunătățește
și adaptabilitatea modelelor. De exemplu, putem adapta structura într-o diagramă de
clasă, care este răspândită într-un număr de fișiere din cod. În același timp,
flexibilitatea pentru integrarea noilor funcționalități și, prin urmare, agilitatea
10
XML Metadata Interchange Format (XMI) este un standard pentru reprezentarea modelelor
UML și, prin urmare, acest tip de reprezentare formală a sintaxei
proiectului continuă să crească. Prin urmare, putem identifica următoarele tehnici

importante în manipularea modelelor [1.9]:
▪ generarea codului produsului;
▪ generarea codului de testare;
▪ modele de refactorizare.
Un alt factor care este util în crearea eficientă a testelor este derivarea multor
cazuri de testare din specificații universale, cum ar fi constrângerile OCL sau
Statecharts. Tehnici speciale, de exemplu, pentru generarea de tabele de baze de date,
generarea unei interfețe grafice simple din modele de date sau pentru migrarea seturilor
de date care se conformează modelului vechi într-un model nou sunt de asemenea
importante și trebuie să fie susținute de un generator de cod cu parametri adecvați.
Dezvoltarea software Agile, bazată pe UML prezintă unele dezavantaje care
ar trebui luate în considerare:
▪ avantajul că aproape aceeași notație poate fi utilizată pentru modelarea și
implementarea abstractă se poate dovedi a fi o revenire. În practică,
abordările anterioare pentru o modelare abstractă a proprietăților esențiale,
cum ar fi SDL sau specificațiile algebrice, au fost utilizate adesea ca limbaje
de programare la nivel înalt de îndată ce executabilitatea lor a fost
disponibilă printr-un instrument. Dacă UML este utilizat pentru specificații,
acest lucru poate duce la completarea detaliilor inutile pentru specificație,
deoarece o utilizare ulterioară a specificației ca implementare a fost
anticipată până devreme. Acest fenomen este denumit și „suprainginerie”;
▪ efortul de predare pentru utilizarea UML/P trebuie presupus ca fiind ridicat.
În ceea ce privește sintaxa, UML/P este semnificativ mai complex decât
Java, ceea ce înseamnă că aici se recomandă o abordare de învățare
incrementală. Ca un pas inițial, se poate învăța utilizarea UML/P pentru
descrierea structurilor cu diagrame de clase și obiecte. Aceasta poate fi
urmată de diagrame de secvență pentru modelarea cazurilor de test și,
bazându-se pe aceasta, OCL pentru definirea condițiilor, invarianților și
specificațiilor metodei. Utilizarea Statecharts pentru modelarea
comportamentului necesită de obicei cea mai mare practică. Cu toate
acestea, în mod similar cu Java, nu numai sintaxa trebuie stăpânită, ci mai
ales utilizarea standardelor de modelare și a modelelor de proiectare, care
trebuie învățate și ele;
▪ în prezent, nu există suficient suport pentru instrumente care să acopere
complet toate aspectele generării de cod dorite. În special, generarea
eficientă de cod este esențială pentru crearea rapidă a sistemului, care la
rândul său permite executarea eficientă a testelor și feedback-ul rezultat. Cu
toate acestea, un număr de dezvoltatori de instrumente lucrează la realizarea
acestei viziuni a suportului complet al instrumentelor și sunt deja în măsură
să demonstreze rezultate
Metodele agile reprezintă o abordare relativ nouă care, prin mai multe
caracteristici, se distinge în mod explicit de metodele utilizate anterior în dezvoltarea
de software. Instrumentele, tehnicile și înțelegerea problemelor de dezvoltare
software s-au îmbunătățit semnificativ. Prin urmare, aceste metode pot oferi abordări
mai eficiente și mai flexibile pentru un subdomeniu de proiecte de dezvoltare

software prin, de exemplu, consolidarea concentrării pe rezultatul primar, sistemul
executabil și o reducere a activităților secundare. În același timp, motivația și
angajamentul participanților la proiect pentru executarea riguroasă a activitățile lor
vin în prim plan și iterațiile scurte permit un control flexibil, dependent de situație,
al dezvoltării software-ului. Dintre factorii importanți pentru determinarea
dimensiunii unui proiect amintim:
▪ dimensiunea problemei;
▪ eficiența dezvoltatorilor.
Acești factori ajută la obținerea dimensiunii necesară a metodei, care constă
în principal din elementele metodologice care trebuie executate, formalitatea
necesară pentru documente și efortul suplimentar pentru comunicare și gestionare.
Datorită cheltuielilor suplimentare de comunicare și gestionare, eficiența
dezvoltatorilor este disproporționată în determinarea dimensiunii proiectului, adică
numărul de dezvoltatori necesari și durata de execuție a proiectului. Prin urmare,
îmbunătățirea eficienței dezvoltatorului este o pârghie semnificativă pentru
reducerea costurilor de dezvoltare. Ca limbaj de modelare pentru modelarea,
proiectarea și implementarea arhitecturii, UML/P oferă un cadru de limbaj
standardizat care ne permite să modelăm sistemul executabil și testele complet.
Dimensiunea compactă a reprezentării duce la o eficiență mai mare și are ca rezultat
scalarea efectelor pentru dimensiunea proiectului. Cadrul standardizat previne o
încălcare a noțiunii altfel adesea observată între modelare, implementare și testare.
Limbajul de modelarea UML se poate aplica roboticii. Rrobotica modernă
include și domeniul sistemelor cibernetice, care este definit de o eterogenitate inerentă
a domeniilor implicate, platformelor relevante și provocărilor din lumea reală.
Ingineria aplicațiilor robotice necesită compunerea și interacțiunea multor
module software. Acest lucru duce de obicei la soluții software monolitice complexe
greu de reutilizat, de întreținut și de înțeles, ceea ce împiedică propagarea largă a
aplicațiilor robotice. Cercetările în ingineria software bazată pe modele pentru
robotică, pe de o parte, se concentrează pe arhitecturile software pentru a structura
unitățile de comportament reutilizabile. Pe de altă parte, se utilizează limbaje de
modelare (DSL) pentru sarcini de asamblare a produselor robotizate în contexte
industriale, precum și sarcini logistice planificate și neplanificate. Acest lucru se poat
aplica roboților care interacționează cu oamenii, roboților industriali, precum și
roboților autonomi.
Descrierea arhitecturii software a unui robot și comportamentul său în modele
integrate, oferă multe avantaje pentru a face față acestei complexități:
▪ modelele sunt independente de platformă;
▪ pot fi descompuse pentru a fi dezvoltate independent;
▪ sunt reutilizabile;
▪ pot fi supuse la analiza formală.
Dintre aplicațiile software utilizate în robotică amintim: Festo Robotino
Roboți, ROS și Python.
Un alt domeniu îl reprezintă fabricarea automatizată flexibilă, a cărui dinamică
crește continuu pe măsură ce produsele devin din ce în ce mai individualizate. Procesele
de asamblare flexibile cu brațele robotului conforme sunt încă greu de dezvoltat din
cauza multor incertitudini cauzate - printre altele - de toleranțele obiectelor,
incertitudinile de poziție și toleranțele de la senzorii externi și interni. Reutilizarea acestor
programe depinde de fiecare expert individual și lipsesc instrumentele care permit
reutilizarea și modelele de compunere la diferite niveluri de detaliu.
Ca urmare a colaborării dintre B.Rumpe [1.9] și Institutul DLR pentru
Robotică și Mecatronică s-a introdus cadrul LightRocks (Light Weight Robot
Coding for Skills) [1.14] care permite experților în robotică și începătorilor să
modeleze sarcini de asamblare robotică pe diferite niveluri de abstractizare, și
anume: sarcini de asamblare, abilități și acțiuni elementare.
Experții în robotică oferă un model de domeniu al mediului de asamblare și
acțiuni elementare care fac referire la acest model. Lucrătorii din fabrică le combină cu
abilitățile și sarcina de a implementa procesele de asamblare furnizate de experți. Acest
lucru permite separarea preocupărilor, crește reutilizarea și permite producția flexibilă.
Cadrul este implementat pe baza profilurilor de limbaj MontiCore pentru diagramele de
clasă UML/P și diagramele de clasă UML/P, ceea ce permite reutilizarea multor cadre
UML/P pentru modelare, validare model, generare cod și generare editor.
1.7 Principiile proiectării orientate pe obiect
Dezvoltarea de metode, instrumente și tehnici pentru producerea de software

implică utilizarea de tehnologii, practici și procedee, care să răspundă nevoilor
clienților, calităților conform normativelor în vigoare, costuri corespunzătoare
cerințelor și termenelor de livrare.
Atunci când facem referire la ingineria software trebuie să amintim de
următoarele tehnici:
1. tehnici de specificare – respectiv descrierea unor caracteristici ale
produsului final, care trebuie realízate în mod obligatoriu de către
proiectant, astfel încât, acesta să fie acceptat și utilizat de beneficiar:
o tehnici de specificare a cerințelor sau a exigențelor funcționale/
nefuncționale;
o tehnici de specificare a sistemului se referă la natura funcțiilor oferite,
comportamentul și datele necesare funcțiilor;
o tehnici de specificare a arhitecturii sistemului, se aplică în faza de
concepție generală și definesc modulele arhitecturale ale produsului
software care urmeaza sa fie realizat;
o tehnici de specificare tehnica, de detaliu, se aplică în faza de proiectare
detaliată a modulelor, programelor și structurilor de date care compun
produsul software;
2. tehnici de concepție – constau în construirea formei primare a produsului
și există două paradigme:
o tehnici funcționale, care se referă la modelarea proceselor
informaționale, dintre care amintim:
▪ SADT – Structured Analysis and Design Technique;
▪ JSD – Jackson Software Development;
▪ MERISE pentru modelarea și reprezentarea sistemelor tranzacționale,

care utilizează volumen mari de date;
o tehnici obiectuale orientate pe obiect, concepute pentru dezvoltarea unor
componente reutilizabile ale produselor software, care încorporează
datele, funcțiunile și logica de control a modulelor programabile:
▪ metoda OMT – Object Modeling Technique (static, dinamic,
funcțional), propune separarea procesului de dezvoltare a produselor
software, astfel:
• analiza;
• concepția sistemului;
• concepția obiectelor;
• implementarea;
▪ metoda Booch – propune abordarea incrementală și iterativă a
dezvoltării produselor software, bazată pe ierarhizarea sistemului în
subsisteme, fără reguli de ascendență/descendență și constă în patru
etape de dezvoltare:
• identificarea claselor și obiectelor prin abstractizarea datelor;
• identificarea conținutului semantic al claselor și obiectelor cu
precizarea interfețelor;
• identificarea relațiilor între clase cu distingerea aspectelor statice
și dinamice;
• implementarea claselor și obiectelor;
▪ metoda OOSE – Object Oriented Software Engineering, bazată pe
folosirea diagramelor cazurilor de utilizare pentru descrierea
interacțiunilor om-mașină:
3. tehnici de validare/verificare – acoperă toate produsele specifice fazelor
ciclului de viață al unui proiect. Se caută anomaliile posible, iar identificarea
defecțiunilor este limitată mai ales în cazul unor programe de mari
dimensiuni. Anomaliile căutate se referă la:
o erorile de concepție care pot influența comportamentul produsului ;
o defecțiunile curente, care generează un rezultat anormal în raport cu
anumite standarde sau prin apariția unor pene/blocaje la nivelul
sistemului gazdă.
Procesele de verificare pot fi:
o experimentale (dinamice):
- teste unitare;
- teste de integrare;
- teste de recepție;
- teste de regresiune;
o simulate (statice):
- tehnici informale pentru descoperirea erorilor tipice, pe baza unor
liste predefinite (check list);
- tehnici formale pentru a proba corectitudinea unui program
punând condiția de respectare a datelor inițiale ale Programului și
postcondiția ca rezultatul să fie adevărat;
4. gestiunea proiectelor;
5. aspectele socio-economice ale proiectelor de dezvoltare a produselor
software.
Proiectarea orientată pe obiect este foarte importante și pentru sistemele de
fabricație automatizate flexibile, domeniu care este în continuă dezvoltare, mai ales
că asistăm astăzi la o individualizare a produselor, conform specificațiilor clienților
finali. Procesele sistemelor de fabricație automatizate sunt, încă, destul de greu de
programat din cauza multitudinii incertitudinilor cauzate printre altele de toleranțe,
de poziționare și chiar și a celor datorate senzorilor interni și externi. Calibrarea
senzorilor, într-un sistem cu buclă închisă este făcută pas cu pas, deocamdată.
După cum se știe, o linie de asamblare automatizată este echipată cu brațe
robotizate. Un astfel de braț îl reprezintă Brațul Ușor pentru Robot (Light Weight
Robot Arm LWR), care permite efectuarea de mișcări conforme, astfel încât, se pot
rezolva incertitudinile [1.14]. De ce programarea LWR este mai complicată decât
programarea roboților industriali? Pentru că (Fig. 1.18) trebuie ținut cont de poziții,
rigiditate, feedback de amortizare etc., care trebuie ajustate la fiecare comandă dată
pentru ca brațul robotizat să efectueze o mișcare. Complexitatea crește atunci când
feedback-ul necesită implicarea mai multor senzori. Astfel, reutilizarea acestor
programe depinde până la urmă de fiecare specialist. Exemplul amintit se referă la
un caz în care instrumentele care permit reutilizarea și compoziția modelelor la
diferite niveluri de detaliu lipsesc cu desăvârșire. De aceea, există o cerere puternică
de a dezvolta astfel de instrumente și de a permite programarea robotului bazată pe
abilități pentru nespecialiști, respectiv care să fie ușor de accesat de către utilizatorii
finali (lucrătorii de pe linia de montaj).
Fig. 1.18 Exemplu de arhitectură software pentru controlul

și monitorizarea unor sisteme robotizate.
Fiecare abilitate, cum ar fi apucarea unui obiect, împerecherea a două obiecte,

înșurubarea etc., poate fi codificată într-un nou limbaj de programare al robotului,
programare bazată pe abilități. Abilitățile pot fi selectate și combinate de către personalul
care utilizează în mod direct robotul. Sistemul de planificare a ansamblului poate fi
utilizat pentru a genera automat secvențe de asamblare. Fiecare secvență este stabilită de
un identificator de sarcini. Fiecare sarcină poate fi modelată iar abilitățile sunt combinate
cu sarcinile robotului pe baza unor tipare prestabilite.
Concluzia care se desprinde este că trebuie realizate programe flexibile și
eficiente totodată. Soluția cea mai simplă este dată de adoptarea unui Limbaj
Specific Domeniului (Domain Specific Language - DSL) programarea robotului.
Un asemenea limbaj de programare al robotului se bazează pe UML/P Statecharts
[1.12]. Familia de limbaj de modelare UML/P este o variantă orientată spre
implementare a UML care permite generarea de cod din mai multe limbaje UML/P,
diagrame de clasă OCL/P (Object Constraint Language/Programming) și altele. Modele
ale acestui limbaj sunt generate în programe Java, care pot fi executate pe o anumită
interfață de programare a robotului folosind limbajul de lucru MontiCore [1.15] și
infrastructura de generare a codului UML/P [1.16]. DSL în sine este separat de definiția
interfeței robotului folosit. Prin urmare, modificările interfeței robotului de bază
afectează doar modelele. Pentru a-și îmbunătăți utilizabilitatea, dezvoltarea modelelor în
LightRocks este susținută de un cadru generic de editare grafică sub forma unui plugin
Eclipse.
Fig. 1.19 Exemplu de abstractizare a programării

sistemelor robotizate industriale.
Dezvoltarea de software pentru controlul roboților inteligenți este o

provocare în mai multe moduri: configurările robotului implică de obicei piese
hardware extrem de diferite care rulează pe diferite platforme, unele dintre ele cu
comunicare dură în timp real [1.17]. Algoritmii de planificare a mișcării și
calculele dinamicii corpului multibody sunt extrem de complicați și necesită
implementări eficiente, ușor de utilizat pentru programatorul mediu. Alte obiective
de proiectare, cu caracter conflictual, pot fi atinse numai prin compromisuri atente,
motiv pentru care preferăm o abordare pură a bibliotecii C ++, care acoperă
întreaga gamă de la abstractizarea hardware până la planificarea mișcării Robotics
Library - RL.
1.7.1 Principiile de proiectare
Stabilirea principalelor principii de proiectare aplicate în întreaga Robotics

Library, este bine să fie făcută de la început, întrucât multe dintre ele prezintă
diferențe notabile față de abordările conexe [1.17].
1. librăria cu un singur API, interfețele sunt consistente în toate
componentele bibliotecii și toate clasele moștenesc din clasele de bază
definite. Spre deosebire de multe alte sisteme robotizate, RL nu este un
middleware și este independent de orice abordare de comunicare
distribuită care ar putea fi utilizată.
2. Implementare consecventă și completă, toți algoritmii importanți din
domeniul principal al roboticii, inclusiv cinematica, dinamica, generarea
traiectoriei și planificarea traseului, sunt disponibili și utilizează notații și
interfețe identice. Cinematica și dinamica robotului susțin tipuri de
articulații generice într-o structură ierarhică și care sunt implementate
folosind algebra vectorială spațială [1.18]. Driverele hardware pentru
senzori și roboți, precum și diferite tipuri de algoritmi de planificare a
mișcării, sunt unificate într-o ierarhie de clase.
3. Reutilizarea bibliotecii este posibilă deoarece bibliotecile sunt bine
proiectate și provin din câmpuri conexe. Spre exemplu se referă la modul
cum pot fi detectate coliziunile sau cum efectuează vizualizarea. Toate
acestea sunt puse la dispoziție prin împachetări. Un subiect sensibil este
cel care privește detectarea coliziunilor, există deja mai multe biblioteci de
înaltă calitate, chiar dacă ele conțin o serie de compromisuri diferite în ceea
ce privește performanța, precizia și funcționalitatea avansată (cum ar fi
interogările la distanță sau difuzările de imagini). RL oferă acces la acestea
sub o structură comună de date a graficului de scenă și încapsulează
funcțiile acestora într-un strat de abstractizare.
4. Independența platformei implică implementarea ISO C ++ pură, prin
utilizarea de biblioteci multiplatformă, astfel încât, avem o compilare pe o
gamă largă de sisteme de operare, de la un QNX încorporat, la Raspberry
Pi bazat pe Debian și până la un PC care rulează Windows.
Trebuie remarcat faptul că RL este open source și este licențiat sub o

licență BSD cu 2 clauze permisive. Altfel spus, este gratuit pentru aplicații
necomerciale și comerciale. Sistemul Open source permite depanarea întregului
pachet de software de la interfața utilizatorului până la controlul hardware-ului
în timp real [1.19].
Sistemul de Operare al unui Robot (Robot Operating System - ROS) este
probabil cel mai activ middleware și cadru software din cercetarea în domeniul
roboticii [1.20]. ROS este în mare parte motivat de integrarea sistemelor de roboți
de serviciu și are un accent puternic pe o topologie peer-to-peer între multe procese
(numite noduri) și un set comun bogat de instrumente pentru integrarea software-
ului (cum ar fi sistemul de construire, date și topologie vizualizare, complotare sau
documentare). Design-ul ROS a fost adaptat la o gamă mult mai largă de roboți
umanoizi, roboți mobili și vehicule aeriene. În prezent planurile de a sprijini
platformele încorporate și în timp real au ajuns la o altă versiune API (Application
Programming Interface) [1.21]. Funcționalitatea de bază din interiorul nodurilor se
bazează pe o serie de cadre existente, cum ar fi biblioteca cinematică pentru un
Skeleton. Spre deosebire de colecția de pachete ROS, RL este o bibliotecă omogenă
cu suport complet în timp real.
Printre cele mai vechi abordări ale software-ului de planificare a căilor
orientate pe obiecte se numără biblioteca Componente pentru planificarea căii -
Components for Path Planning library [1.22], care a fost refactorizată la un cadru de
componente (Fig. 1.21).
RL oferă suport în timp real. Pentru planificarea căilor fără coliziuni, Open
Motion Planning Library [1.23] oferă o colecție largă de algoritmi de ultimă
generație, dar nu există mijloace pentru executarea acestor căi pe roboți fizici.
Fig. 1.20 Prezentarea generală a pachetelor Robotics Library’

și a interdependențelor [1.19], fig. 1.
1.7.2 Lucrări conexe
Sistemul de Operare al unui Robot (Robot Operating System - ROS) este

probabil cel mai activ middleware și cadru software din cercetarea în domeniul
roboticii [1.20]. ROS este în mare parte motivat de integrarea sistemelor de roboți
de serviciu și are un accent puternic pe o topologie peer-to-peer între multe procese
(numite noduri) și un set comun bogat de instrumente pentru integrarea software-
ului (cum ar fi sistemul de construire, date și topologie vizualizare, complotare sau
documentare). Design-ul ROS a fost adaptat la o gamă mult mai largă de roboți
umanoizi, roboți mobili și vehicule aeriene. În prezent planurile de a sprijini
platformele încorporate și în timp real au ajuns la o altă versiune API (Application
Programming Interface) [1.21]. Funcționalitatea de bază din interiorul nodurilor se
bazează pe o serie de cadre existente, cum ar fi biblioteca cinematică pentru un
Skeleton. Spre deosebire de colecția de pachete ROS, RL este o bibliotecă omogenă
cu suport complet în timp real.
Printre cele mai vechi abordări ale software-ului de planificare a căilor
orientate pe obiecte se numără biblioteca Componente pentru planificarea căii -
Components for Path Planning library [1.22], care a fost refactorizată la un cadru de
componente (Fig. 1.21).
Fig. 1.21 Principalelor componente care sunt implicate pentru

rezolvarea unei probleme de planificare a căilor.
RL oferă suport în timp real. Pentru planificarea căilor fără coliziuni, Open
Motion Planning Library [1.23] oferă o colecție largă de algoritmi de ultimă
generație, dar nu există mijloace pentru executarea acestor căi pe roboți fizici.
1.7.3 Librăria numerică
Rolul unei librăii matematico-numerice are o influențăare mare asupra tuturor

celorlalte părți ale unei biblioteci de robotică. Aproape toți algoritmii specifici roboticii
referitori la cinematica și dinamica robotului, la planificarea traseului, generarea
traiectoriei și evitarea coliziunilor necesită operații vectoriale și matriceale. De
asemenea trebuie efectuate calcule numerice pentru stabilitate, calcule matriciale
avansate cu valorii proprii ale compozițiilor. Astfel, nu putem merge mai departe fără
alegerea unor rutine numerice puternice, stabile și eficiente. Prin urmare analiza
numerică are un impact mare asupra performanței generale a întregii biblioteci. În afară
de eficiență, alte cerințe ale API sunt lizibilitatea, ușurința în aplicare și consistența.
Biblioteca RL, are implementat codul Eigen [1.24], care este un cod rapid și
lizibil deoarece utilizează șabloane de expresie și vectorizare explicită. RL face o serie
de extensii la tipurile native Eigen și adaugă caracteristici suplimentare, în special la
implementarea cuaternionului [1.24]. Aceste caracteristici includ puterea și funcțiile
exponențiale ale tipurilor de cuaternion, precum și conversia la viteza unghiulară și
accelerație. Pentru o interpolare lină a rotațiilor robotului, RL implementează funcția
SLERP (Spherical Linear Interpolation) și derivata acesteia, așa cum este definit de
[1.26]. Când sunt date condiții de rezistență pentru o interpolare de rotație, funcția de
echipă poate satisface o interpolare lină cu cuaternionii valabili, RL implementează
funcția de echipă și interpolația cuaternionului cubic.
1.7.4 Funcții matematice
Multe tipuri de calcule geometrice sunt utilizate frecvent în aplicații de

robotică, variind de la transformări 3D de bază, diferite tipuri de rotații, la interpolare
de traiectorie și calcule vectoriale spațiale. Pentru a avea o separare clară a
preocupărilor, trebuie implementate funcții geometrice generice din componenta
matematică, care sunt independente de modelul cinematic sau dinamic al unui robot
și care sunt păstrate liber de orice dependență de software.
RL face două alegeri importante care caracterizează proiectarea componentelor
sale matematice:
• generarea traiectoriei – care adoptă o abordare algebrică în care traiectoriile
sunt reprezentate ca funcții algebrice, permițând interpolare și diferențiere;
• toate funcțiile dinamicii corpului rigid sunt formulate în termeni vectoriali
spațiali, care permit o formulare deosebit de concisă și un calcul extrem de
eficient.
1.7.4.1 Formularea funcției algebrice:
Reprezintă o provocare majoră în generarea traiectoriei de a evita discontinuitățile

în: spațiu, viteză și accelerație. Doar traiectoriile netede cu derivate continue permit o
mișcare robotică sigură, rapidă și precisă. Cu toate acestea, atunci când se definește o
cale în spațiul operațional sau se comută între spațiul comun sau mișcarea operațională,
elementele robotice recurg în mod obișnuit la: eșantionare simplă, filtrare sau aproximare
prin polinoame de nivel scăzut.
RL evită această aproximare și oferă un cadru pentru construirea de piese, funcții

algebrice cu valoare vectorială, permițând reprezentarea tuturor tipurilor de traiectorii la
nivel algebric (Fig. 1.22). Clasa funcției abstracte definește o mapare de la o valoare
reală (de obicei timpul) la un vector (de obicei, dar nu limitat la o configurație spațială
comună sau spațiu operațional), ale cărei valori și valori derivate pot fi evaluate eficient.
Clasele concrete sunt implementate pentru toate tipurile de bază ale mișcării: polinoame
pentru poziții spațiale comune și operaționale, polinoame cuaternare pentru rotații și
orientări spațiale operaționale și mișcare de-a lungul segmentelor circulare. Funcțiile și
splinele în bucăți (polinomii în bucăți) sunt organizate sub forma unui model compozit,
permițând construirea unor traiectorii complexe atât în spațiul comun, cât și în spațiul
operațional.
Fig. 1.22 Ierarhia de clase a funcțiilor matematice. O funcție este o mapare cu valoare
vectorială care poate fi evaluată eficient și stabil, inclusiv derivatele sale.
Avantajul acestei abordări este:

• continuitatea și netezimea pot fi garantate și verificate exact și pentru mai
multe ordine de instrumente derivate, inclusiv accelerație / supraacelerație;
• traiectoriile sunt formulate la un nivel semantic, abstract, la același nivel cu
un mediu tipic de proiectare asistată de computer, permițând integrarea
ușoară cu interfețele utilizator avansate de programare a robotului.
În componenta matematică, clasele Function oferă implementări generice care
nu necesită nici un model cinematic. În special, funcțiile statice sunt disponibile
pentru construirea funcțiilor algebrice pentru condiții limită date, inclusiv interpolare
spline de ordin superior (cuaternion) și mișcare de-a lungul segmentelor circulare.
Când o astfel de funcție urmează să fie executată ca o traiectorie pentru un anumit
robot, pachetul cinematic din secțiunea II-D va rezolva cartarea cinematică inversă
pentru traiectorii în spațiul operațional, va verifica limitele matematice kine și va
permite executarea prin evaluarea pieselor funcția de traiectorie în raport cu ciclul
de control al robotului.
1.7.4.2 Formulare vectorială spațială
Dinamica corpului rigid a fost implementată de multe cadre robotice, cu toate

acestea, RL alege o formulare diferită de acestea și folosește algebra vectorială
spațială, așa cum a propus Fersterstone [1.26]. Un vector spațial este definit ca un
vector șase dimensional (6DOF) care poate să fie un vector de mișcare care să
reprezinte o viteză sau o accelerație, fie un vector de forță care să reprezinte impulsul
sau doar impulsul. Vectorii spațiali nu fac parte din spațiul euclidian, produsul fiind
definit doar între un vector de mișcare și o forță. În această notație, o transformare
spațială poate fi exprimată ca o matrice 6-pe-6.
În timp ce algoritmii de dinamică sunt destul de complicați atunci când sunt
scrise folosind matrici de transformare 4-pe-4, vectorii spațiali permit o formulare
foarte concisă a algoritmului recursiv Newton-Euler într-o singură formulă pentru
toate tipurile de articulații. Cele n grade de libertate ale unei articulații sunt definite
de o matrice 6n pentru toate tipurile generale de articulații, incluzând articulațiile
revolute, prismatice, sferice și elicoidale.
Pe lângă concizie în notare și generalitate ridicată pentru toate tipurile de
articulații, implementarea vectorului spațial are avantajul important al unei eficiențe
computaționale mai mari, această implementare minimizează numărul de operații în
virgulă mobilă pentru calculul dinamicii înainte și inversă pentru lanțurile cinematice.
1.7.5 Layerul privind abstractizarea Hardware
Suportul pentru controlul diferitelor tipuri de dispozitive hardware este o

caracteristică majoră a unui cadru de robotică. Astăzi, configurațiile robotului se
bazează pe mai multe tipuri de senzori, inclusiv camere foto, senzori de distanță sau
senzori de cuplu forțat. Pe partea actuatorului, roboții industriali și mânerele
utilizează o gamă largă de protocoale industriale diferite, inclusiv diverse protocoale
specifice dar și protocoale Ethernet personalizate. Implementările driverului open-
source sunt destul de rare. În multe cazuri, documentațiile de protocol precise nu fac
parte din manual și nu sunt deschise publicului.
1.7.5.1 Implementarea ierarhică a driverului hardware
Dispozitivele hardware se pretează bine pentru o implementare ierarhică

orientată pe obiecte. În timp ce dispozitivele de tipuri similare, cum ar fi dispozitivele
de acționare, senzorii cuplului de forță, dispozitivele de prindere sau camerele,
împărtășesc un set comun de caracteristici de bază, iar dispozitivele individuale pot
oferi caracteristici suplimentare specifice unui anumit producător. Aceste interfețe
comune sunt organizate ca o ierarhie de clase într-un strat de abstractizare a
obiectelor orientate pe obiect (Fig. 1.23).
Pentru dispozitivele cu un set de caracteristici extrem de divers și extrem de
fin, structurarea lor în mai multe straturi este întotdeauna o opțiune. De exemplu, un
robot umanoid poate fi modelat ca un dispozitiv cu acces plat la toate articulațiile
controlate de poziție, dar poate fi, de asemenea, proiectat ca o clasă cu acces la brațe
individuale, picioare etc. Un manipulator robot poate oferi o interfață pentru

controlul poziției, dar oferă și acces la motoare simple cu interfețe, inclusiv accesul
la componente individuale și la citirile temperaturii și valorile de control ale acestora.
Fig. 1.23 Extras de clase pentru abstractizarea hardware-ului. Dispozitive similare oferă
metode comune, cum ar fi citirea valorilor distanței pentru un RangeSensor sau citirea
valorilor poziției unui manipulator pentru fiecare axă a unui JointPositionSensor.
În partea de sus a ierarhiei se află clasa de dispozitive abstracte, care definește

metode comune tuturor dispozitivelor: deschiderea și închiderea conexiunii la
dispozitivul hardware, pornirea și oprirea operațiunilor, precum și metoda pasului,
care efectuează toate comunicările către și de la dispozitiv.
Spre deosebire de alte cadre de robotică, care aleg să încapsuleze complet
comunicarea cu un dispozitiv hardware și să implementeze apeluri funcționale
asincrone și apeluri la recepția datelor, RL alege să evite orice tip de concurență
ascunsă. În ceea ce privește componenta hardware, este o alegere importantă de
proiectare a bibliotecii să nu creeze fire sau procese (în afară de clasa efectivă în timp
real de abstractizare a firelor destinată acestui scop).
Comportamentul simultan este un aspect critic în interfațarea hardware-ului
cu constrângeri în timp real și, prin urmare, ar trebui să fie una din preocupările
programatorului. Dimpotrivă, RL solicită aplicației să apeleze periodic metoda etapă
a dispozitivului în cadrul ciclului său de control.
Stările și tranzițiile de stare ale unui obiect dispozitiv (Fig. 1.24) definesc
comunicarea către un dispozitiv nou construit și este inițiată prin apelul cu metodă
deschisă. Pentru dispozitivele în timp real, apelurile succesive ale metodei pas sunt
necesare în cadrul constrângerilor în timp real. Operațiunile sale încep după un apel
privind metoda de pornire și se termină cu oprire. Important, toate comunicările cu
dispozitivul sunt realizate prin această metodă și sunt amplasate în obiect. Programatorul
accesează datele senzorului cache sau pozițiile țintă ale actuatorului prin metode getter
și setter.
Acest design de interfață hardware permite toate tipurile de implementări de fire,
inclusiv thread-uri în timp real specifice platformei. Cu toate acestea, designul presupune
ca programatorul să aleagă în mod activ modul în care sunt garantate apelurile de metodă
în timp real și nu ascunde această alegere importantă. Un programator își poate proiecta
aplicația ca un singur proces cu un fir sau fire individuale de timp de ciclu diferit pentru
fiecare dispozitiv hardware. De asemenea poate alege un proces pentru fiecare dispozitiv
împreună cu o comunicare de memorie partajată bazată pe API-ul său preferat. Pentru a
echilibra sarcina de calcul, programatorul poate muta dispozitivele și procesele care
efectuează calcule grele către un computer separat și prin utilizarea de comunicații de
bază de TCP / UDP, un bus specific dintre multele middleware disponibile.
Fig. 1.24 Stările (a) Device și (b) CyclicDevice. Acesta din urmă schimbă toate mesajele
către și de la dispozitiv, funcție care trebuie apelată într-o buclă în timp real.
1.7.5.2 Abstractizarea sistemului de operare
Înainte de introducerea noului standard C ++ - 11 cu interfețe pentru

descărcare, excludere reciprocă, variabile de condiție, ceasuri și programare
asincronă, RL a furnizat soluții abstracte, semafor și clase de timer pentru un thread
obișnuit în Windows sau implementări RTAI și Xenomai. În cea mai recentă
versiune, RL este construit deasupra standardului C ++ - 11, dar oferă și extensii
pentru setarea priorităților de proces și thread, ca o interfață standard compatibilă
pentru interfața nativă RTAI și Xenomai [1.28].
RTAI și Xenomai sunt extensii de kernel open-source pentru Linux și

gestionează programarea în timp real. Cu ambele provenind din același proiect,
RTAI se comportă diferit în sensul că interceptează notificările de întrerupere directe
și evită unele cheltuieli de timp de gestionare a întreruperilor. Unele sisteme de
operare native în timp real, cum ar fi QNX, oferă firele POSIX regulate prin interfața
pthread. Toate aceste cadre în timp real sunt suficient de rapide și fiabile pentru toate
cele implementate, cu întârzieri TCP dus-întors cu mult sub 100 µs, măsurate. Cu
această clasă de fire abstracte, programatorii pot dezvolta aplicații care să compileze
pe mai multe sisteme de operare în timp real sau extensie de kernel în timp real.
1.7.6 Cinematica și Dinamica RL
Modelarea structurii cinematice este o parte integrantă a controlului unui sistem

robot. Împreună cu proprietățile dinamice ale robotului, aceasta include calculul
cadrelor de legătură pe baza valorilor comune, a matricei Jacobian și a derivatei sale,
precum și a matricei de masă, a vectorului Coriolis și a compensării gravitației.
Algoritmii obișnuiți includ algoritmul recursiv Newton-Euler pentru dinamica
inversă și corpul articulat al goritmului pentru dinamica directă. Notarea clasică
Denavit-Hartenberg este utilizată pentru a descrie sistemele cu o serie de articulații
revolute și prismatice care mișcă legăturile robotului.
Pentru fiecare tip de articulație sunt necesare diferite formule pentru a descrie
acești algoritmi. Modelarea orientată pe obiecte a sistemelor multicorp [1.29], poate fi
utilizată pentru modelarea articulațiilor și a altor componente de transformare ca
obiecte care influențează elemente precum cadre, viteze, accelerații sau forțe.
Prin combinarea acestor două abordări, sistemul vectorial spațial poate fi utilizat
pentru a modela tipuri de articulații cum ar fi articulații elicoidale, cilindrice, plane,
sferice sau 6-DOF cu o singură notație. Algoritmii sunt modelați într-un mod în care
aceste obiecte de transformare modifică valorile de intrare și ieșire corespunzătoare.
Îmbinările și transformările fixe dintre corpuri pot fi văzute ca muchii într-un grafic,
în timp ce corpurile, referința mondială și cadrele intermediare reprezintă vârfurile în
acest grafic (Fig. 1.25).
De exemplu, algoritmul recursiv Newton-Euler folosește două iterații: (i)
propagarea înainte a vitezei și accelerațiilor, (ii) propagarea înapoi a forțelor. În
implementarea orientată obiect, aceasta este reprezentată de două funcții
inverseDynamics1 () și inverseDynamics2 () implementate diferit pentru fiecare obiect
(Fig. 6). Prima iterație calculează viteza curentului v și accelerațiile a în cadrele
corpului pe baza vitezelor articulare q și a accelerațiilor q . Apoi determină forțele
nete f i B în coordonatele corpului generate de aceste accelerații și inerția rigidă a
corpului I .
Transformările Plucker X definesc transformarea spațială de la cadrul i-1 la i.
Direcțiile de mișcare liberă ale unei articulații sunt modelate de o matrice S și
derivata sa S . A doua iterație / funcție propagă forțele f generate de legăturile
individuale din cadru la efectorul final înapoi la bază și le mapează cuplurile  i în

articulațiile individuale ale sistemului robot.
Fig. 1.25 Cinematica și dinamica unui pendul dublu: pământul (albastru),

corp rigid (gri), vârfurile cadrului (negru), translatarea/rotația fixă (negru),
marginile articulației rotite (roșu).
Alți algoritmi recursivi, cum ar fi algoritmul corpului articulat pentru

dinamica directă, sunt modelați în mod similar. Pentru a calcula matricea iacobiană
sau de masă pentru o stare dată, pot fi utilizate mai multe interogări către acești
algoritmi pentru a crea o reprezentare completă a unei stări. Structurile asemănătoare
arborilor sunt ușor de susținut. În combinație cu câmpul Jacobian, [1.30] prezintă o
aplicație a acestei părți a RL pentru roboții conduși de tendon.
1.7.7 Abstractizarea elementelor grafice
Abstractizarea elementelor grafice are rolul de a valorifica datele geometrice,

care sunt necesare pentru vizualizarea 3D, verificarea coliziunilor, calculul distanței
și emisia de radiații laser, acustice etc.
În timp ce geometria este adesea modelată ca reprezentare la graniță

(Boundary Reprezentation B-Rep) în programele CAD, vizualizarea și interogările
listate necesită de obicei o reprezentare poligonală.
Pentru schimbul de date poligonale, RL folosește un Limbaj de Modelare a
Realității Virtuale (VRML - Virtual Reality Modeling Language), un format
comun acceptat de multe programe CAD și editori 3D. Discretizarea uzuală este de
tip triunghiular, deoarece oferă suport pentru primitivele de bază, cum ar fi cuburi,
sfere, cilindri și conuri, care pot fi utilizate în motoarele de detectare a coliziunilor.
Nodurile denumite pot fi utilizate pentru a face referire la modele individuale de
roboți și la corpurile lor în mișcare.
O reprezentare a spațiului de lucru constă dintr-un număr de corpuri în mișcare
care pot fi grupate în modele pentru a putea scana roboții și obstacolele (
Fig. 1.26). În reprezentarea grafică, corpurile sunt amplasate într-un formaat
cadru pentru a susține orice fel de conexiuni cu modelele cinematice și dinamice, cu
simulările fizice și intrările/ieșirile pentru senzori. În fizică, corpurile sunt conectate
prin constrângeri cum ar fi articulații sau arcuri care pot fi îndepărtate sau se pot rupe
în timpul interacțiunii. Fiecare corp constă dintr-un număr de forme geometrice cu
transformări statice. Pentru a actualiza modelul geometric al unui robot având o
configurație comună, cadrele individuale sunt calculate prin reprezentarea
cinematică corespunzătoare robotului.
Importul de fișiere și vizualizarea 3D sunt implementate folosind Open
Inventor API, o implementare orientată pe obiect a graficului de scenă. VRML este
creditat cu performanțe excelente de încărcare, deoarece este o extensie la formatul
de fișier nativ Inventor. Pentru a grupa corpurile în modele, un fișier suplimentar de
descriere a scenei specifică numele modelelor și corpurilor individuale din fișierul
VRML. Fișierele VRML separate pot fi utilizate pentru vizualizare și detectarea
coliziunilor pentru a modela forme primitive, cum ar fi cutii, sfere sau corpuri
convexe, pentru o performanță îmbunătățită [1.31].
Pentru a compara diferite motoare de coliziune, API-ul definește interfețe
pentru interogări simple de coliziune / distanță / emisie de raze și calcul de adâncime
de penetrare. Funcțiile includ interogări între forme, corpuri, modele sau întreaga
scenă.
O ramură a RL a explorat înlocuirea VRML cu COLLADA (COLLAborative
Design Activity) [1.33], deoarece aceasta oferă o descriere pentru o scenă vizuală
(grafică detaliată) și fizică (forme de coliziune și proprietăți dinamice) într-un singur
fișier. COLLADA 1.5.0 oferă chiar și suport pentru descrierile geometriei B-rep.
Suportul pentru exportul de fișiere geometrice în acest format este totuși încă
limitat în programele software 3D curente. În timp ce scenele vizuale în formatul
versiunii 1.4.0 pot fi exportate în unele programe, suportul pentru modelare și
exportul scenelor fizice este încă foarte slab. În plus, API-ul oficial COLLADA
DOM oferă doar o reprezentare obișnuită de bază C ++ a schemei COLLADA XML
și lasă majoritatea lucrării în sarcina utilizatorului.
Fig. 1.26 Reprezentare generală a clasei de abstractizare pentru grafice, cu biblioteci de

verificare a coliziunilor acceptate.
1.7.6 Planificarea traseului
Găsirea unei căi fără coliziuni de la o configurație de robot la alta este o sarcină
obișnuită în robotică. Au fost dezvoltați diferiți algoritmi de planificare, cu abordări
bazate pe eșantionare, cum ar fi foi de parcurs probabilistice (PRM) și arbori de
decizie aleatori cu explorare rapidă (RRT) și variațiile acestora.
O comparație a diferiților algoritmi de planificare și a performanței acestora
utilizând RL poate fi găsită în [1.33]. Planificarea traseului necesită o reprezentare
cinematică a robotului împreună cu un model geometric și un motor pentru detectarea
coliziunilor (Fig. 9). Pentru a determina dacă o stare se ciocnește, cinematica mapează
o configurație articulară imens -dimensională la cadre pentru geometria din spațiul de
lucru tridimensional și motorul de coliziune calculează rezultatul.
Cinematica definește, de asemenea, un spațiu metric ca o combinație a
varietăților articulațiilor sale individuale. O articulație prismatică sau revolută cu limite
superioare și inferioare este reprezentată de 1 , o articulație revolută fără limite, însă
1
de S .
3
Îmbinările sferice reprezintă spațiul proiectiv real P și colectorul corect
pentru obiectele care zboară liber este dat de 3  P3 . Aceste valori trebuie luate
în considerare la calcularea unei funcții de distanță globală și la interpolare între
configurații. În afară de complexitatea geometriei și performanțele motorului de
coliziune, calculul celui mai apropiat vecin este cea mai scumpă operație într-o
mulțime de algoritmi de planificare. Căutarea liniară devine din ce în ce mai scumpă
cu numărul de vârfuri dintr-un arbore sau grafic. Structuri, cum ar fi arborele k-

dimensional, se ridică doar la cinematică cu aproximativ 20 DOF și necesită ajustări
speciale pentru alte metrici decât Euclidean. Cu restricții similare cu privire la
numărul de DOF, Geometric Near-Neighbor Access Trees (GNAT) necesită doar o
funcție globală la distanță și reprezintă o alternativă pentru alte valori. Paralelizarea
(OpenMP) poate fi utilizată într-o oarecare măsură pentru a îmbunătăți performanța
acestor interogări costisitoare.
Fig. 1.27 Extras de clase relevante pentru planificarea traseului, cu modele pentru
detectarea coliziunilor și calculul cinematic, precum și structuri de date pentru calculul
celui mai apropiat vecin.
Planificările pe bază de eșantionare se bazează pe un generator de numere

pseudorandom adecvat. În afară de eșantionarea uniformă, se pot introduce diverse
alte tehnici de eșantionare - în special pentru planificatorii de tip PRM - și pot fi
alese pentru un astfel de algoritm. În mod similar, sunt disponibile diferite strategii
pentru verificarea rapidă a marginilor graficului. După ce a fost generată o cale,
utilizatorul poate selecta dintr-o serie de abordări de optimizare pentru a minimiza
lungimea căii.
1.8 Inginerie Software bazată pe modele în robotică
1.8.1 Sisteme de control software pentru roboți autonomi
Roboții autonomi sunt mașini versatile echipate cu un set de funcționalități

software, desfășurate pe o infrastructură de calcul distribuită cu constrângeri de
resurse stricte, pentru a interacționa în mod intenționat și în timp real cu un mediu
deschis cu senzori și actuatori [1.34].
Utilizarea modelelor și a limbajelor de modelare poate avea un impact mare
asupra ciclului de viață al produselor sistemelor software robotizate, mai ales pentru
că pot încorpora cunoștințele experților în mai multe domenii științifice și
tehnologice (mecanică, control, științe cognitive) și pot sprijini automatizarea
tranziția de la spațiul problematic (cerințele robotice) la spațiul soluției
(implementarea software-ului).
1.8.1.1 Sisteme software încorporate în timp real
O aplicație de control al robotului este un sistem software specializat și

încorporat pe un hardware, care rulează și are constrângeri de memorie și de timp.
În general, pentru un sistem încorporat, suntem interesați să modelăm interacțiunea
sistemului cu mediul înconjurător. Această interacțiune se caracterizează prin
executarea în timp real a activităților de control care ar trebui să reacționeze în timp
util la stimulii senzoriali și să producă comenzi către actuatori. De obicei, în orice
sistem încorporat la scară largă, mai multe activități de control sunt executate
simultan pe aceeași unitate de calcul sau pe un sistem distribuit în rețea.
Concurența implică comunicarea între activitățile de control, care schimbă
date și evenimente, și necesită o proiectare atentă a intercalării și sincronizării
acestora pentru a evita comportamentele anormale.
1.8.1.2 Sisteme software distribuite
Hardware-ul de calcul al unui robot autonom este interfațat cu o multitudine

de senzori și actuatori și are constrângeri severe asupra: resurselor de calcul, stocării
de informație și putere consumată. Performanța computațională este o cerință
majoră, deoarece roboții autonomi procesează volume mari de informații senzoriale
și trebuie să reacționeze în timp util la evenimentele care au loc în mediul uman.
Pentru a îndeplini aceste cerințe extrem de solicitante, infrastructurile de calcul ale
roboților autonomi avansați au evoluat de la sisteme cu un singur procesor la rețele
de calculatoare de uz general, microcontrolere, senzori și actuatori inteligenți din
rețea, introducând o mare flexibilitate în construcția capacităților robotului, dar, la
nivelul în același timp, făcând dezvoltarea software-ului mai provocatoare.
Contextual, o varietate de cadre software au fost concepute special pentru
simplificarea implementării sistemelor de control al robotului. Acestea oferă
mecanisme pentru execuție în timp real, comunicare sincronă și asincronă, fluxul de
date și gestionarea fluxului de control. Aceste cadre sunt susținute de lanțuri de
instrumente MDE (Model-Driven Engineering) care permit tranziția semi-

automată de la proiectarea la nivel înalt a funcționalităților sistemului la
implementarea lor efectivă pe infrastructuri specifice.
1.8.1.3 Funcționalități
Spre deosebire de alte sisteme încorporate (mașini, dispozitive medicale etc.),

sistemul de control al unui robot autonom este caracterizat de o mare varietate de
funcționalități (planificarea și controlul mișcării, percepția, planificarea sarcinilor etc.)
care împreună realizează capabilități complexe ale robotului, precum navigarea și
manipularea.
Funcționalitățile robotului sunt puse în aplicare în mod convenabil de
componente software, care pot fi asamblate în multe moduri diferite, cum ar fi:
blocurile de construcție reutilizabile, în conformitate cu cerințele specifice ale
aplicației. Un sistem de control al robotului este compus din zeci de componente.
Pentru fiecare componentă, pot fi disponibile zeci de implementări diferite, algoritmi
diferiți pentru evitarea obstacolelor etc.
Pentru aceste sisteme, o fază critică de dezvoltare este proiectarea arhitecturii
software, care reprezintă partiționarea sistemului de control în părți, cu relații
specifice între părți și face ca setul de piese să funcționeze împreună ca un întreg
coerent și de succes. Ca atare, arhitecturile software definesc regulile și
constrângerile care determină comportamentul general al sistemului de control și
care garantează fiabilitatea și siguranța sistemului.
Abordările MDE susțin proiectarea arhitecturii prin automatizarea unor
sarcini complexe și predispuse la erori, cum ar fi editarea diagramelor, sisteme vechi
de inginerie inversă și, mai important, validarea ipotezelor făcute de inginerii de
sistem și de inginerii de control cu privire la proprietățile sistemului, cum ar fi
programabilitatea, performanța, receptivitate și comportament sigur.
1.8.1.4 Mașini versatile
Roboții sunt mașini versatile utilizate din ce în ce mai mult nu numai pentru a
îndeplini sarcini murdare, periculoase și anoste în industriile producătoare, ci și
pentru a atinge obiective societale, cum ar fi îmbunătățirea siguranței în transport și
reducerea utilizării pesticidelor în agricultură.
În acest scenariu, costul creării de noi produse robotice este semnificativ legat
de complexitatea dezvoltării sistemelor de control software care sunt suficient de
flexibile pentru a satisface cu ușurință cerințele care se schimbă frecvent: sarcini mai
avansate în medii extrem de dinamice, în colaborare cu utilizatori necalificați și în
conformitate cu schimbarea reglementărilor.
Inițiativele recente vizează dezvoltarea abordărilor MDE care simplifică
reconfigurarea statică și dinamică a unui sistem de control al robotului în funcție de
cerințele specifice ale aplicației și condițiile operaționale.
1.8.2 Modelarea și analiza arhitecturii sistemelor
Proiectarea arhitecturii software este un proces de luare a deciziilor

multidimensional și sunt necesare diferite modele software pentru a descrie sistemul din
perspective multiple, cum ar fi structura, comportamentul și proprietățile nefuncționale.
Grupul de gestionare a obiectelor (Object Management Group - OMG11),
un consorțiu non-profit pentru standarde tehnologice, care amendează și menține
specificațiile UML, care este compus din paisprezece tipuri de diagrame standard,
clasificate ca diagrame de structură sau diagrame de comportament.
Diagramele de structură arată structura statică a unui sistem în ceea ce privește
părțile și relațiile dintre părți la diferite niveluri de abstractizare și implementare.
Diagramele de comportament arată comportamentul dinamic al unui sistem,
adică modul în care acesta se schimbă în timp.
Diagrama componentă UML 2.5 definește o notație grafică standard pentru
documentarea reprezentărilor arhitecturale care subliniază elementele de calcul în
timp de execuție (aka componente) ale unui sistem software și canalele lor de
comunicație (aka conectori). Aceste reprezentări sunt denumite tipul de vizualizare
arhitecturală „componentă și conector” [1.35].
În Fig. 1.28 avem o descriere a unei versiuni simplificate a unei arhitecturi
software pentru navigația robotului mobil. Este compus din componente elementare și
componente compozite. Componentele elementare (GlobalPlanner, BaseController)
sunt reprezentate grafic prin casete marcate cu stereotipul <<component>>. În mod
similar, componentele compozite (Equipment) sunt marcate cu stereotipul
<<subsystem>>.
Fiecare componentă este caracterizată de un set de porturi, care reprezintă
puncte de interacțiune distincte cu alte componente.
Fiecare port poate fi asociat cu o serie de interfețe. O interfață furnizată descrie
caracteristicile care constituie un serviciu coerent furnizat de o componentă. În mod
similar, o interfață necesară descrie dependența unei componente de un tip de
serviciu care ar trebui furnizat de o altă componentă.
Un conector reprezintă o legătură de comunicație între două sau mai multe
componente. Diferite tipuri de conectori se pot distinge prin etichetarea legăturii de
asociere cu un stereotip.
În Fig. 1.28, stereotipul << C / P >> se referă la paradigma de comunicare
Apelant / Furnizor (adică componentele interacționează prin invocarea sincronă a
serviciilor), în timp ce << P / S >> se referă la Editor / Abonat paradigma comunicării
(adică componentele interacționează prin mesaje asincrone). Liniile directoare
pentru documentarea tipului de vizualizare arhitecturală „componentă și conector”
în UML [1.36]. Scopul principal al acestui tip de diagramă este de a documenta
arhitectura software-ului dintr-un punct de vedere funcțional și servește drept navă
de comunicare între lumile variate ale părților interesate, adesea non-tehnice, pe de
o parte, și inginerii de software, pe de altă parte. De aemenea permite refolosirea
11
http://www.omg.org/
software-ului prin prezentarea unor structuri stabile recurente în multe sisteme și

facilitează întreținerea prin clarificarea impactului schimbărilor [1.37].
Fig. 1.28 Modelul UML Component al arhitecturii de navigare.
O mare varietate de instrumente software compatibile UML acceptă editarea

diagramelor, diferențierea, îmbinarea pentru proiectarea și documentarea sistemului.
Din păcate, diagramele UML nu sunt eficiente în captarea și reprezentarea
proprietăților nefuncționale ale sistemului software încorporat, concurent și în timp
real, cum ar fi constrângerile de timp ale funcționalităților sistemului, capabilitățile
infrastructurii de comunicații (adesea distribuite) , și alocarea de fire și procese
diferitelor procesoare.
1.8.2.1 UML pentru sisteme software încorporate în timp real
Profilurile UML sunt un mecanism de extensie furnizat pentru a permite

adaptarea și personalizarea notației UML prin adăugarea de semantic și constrângeri
ad-hoc și introducerea unei terminologii specifice unui anumit domeniu, platformă
sau metodă.
În special, OMG a dezvoltat profilul de modelare și analiză a sistemelor
încorporate în timp real (Modeling and Analysis of Real-Time Embedded
Systems - MARTE), care se concentrează pe analiza performanței și a
programabilității și oferă stereotipuri pentru adnotarea modelului arhitectural și

maparea acestora în conceptele de domeniu de analiză corespunzătoare.
Subprofilul HLAM (High-Level Application Modeling) definește un set de
stereotipuri pentru a adnota modelul funcțional cu caracteristici în timp real, ceea ce
denotă o utilizare a stereotipului <<rtUnit>> pentru a adnota două unități de calcul
(adică ObstacleAvoider și TrajectoryFollower) ale componentei Lo calNavigator,
care efectuează activități concurente, adică adaptarea traiectoriei roverului atunci
când este detectat un obstacol și calculând răsucirea pentru a lăsa roverul să urmeze
traiectoria.
O adnotare specifică faptul că activitatea anterioară este aperiodică și că
termenul său relativ este egal cu 10 milisecunde.
Subprofilul SRM (Software Resource Modeling) furnizează artefacte de
modelare pentru a descrie interfețele de programare a aplicațiilor software (API)
multi-tasking. O utilizare a stereotipului <<schedulableResource>> pentru a adnota
două sarcini concurente (adică FollowerTask și ObstacleTask) cu specificarea
priorității lor (Fig. 1.29).
Fig. 1.29 Exemplu de utilizare a stereotipurilor MARTE

pentru analiza programabilității.
Stereotipul <<entryPoint>> indică rutina (adică operația) executată în contextul

fiecărei sarcini.
Subprofilul SAM (Schedulability Analysis Modeling) definește stereotipurile
pentru a adnota elementele modelului de platformă (de exemplu, un procesor sau un alt
dispozitiv, care execută pași funcționali) cu proprietăți nefuncționale, cum ar fi indicatori
de programare, overhead-uri de întrerupere și utilizarea procesării programării. În
special, stereotipul <<SaExecutionHost>> reprezintă orice tip de resursă de procesare
(de ex. Fire POSIX) și conține o proprietate ISRswitchTime care poate fi utilizată pentru
a reprezenta cel mai slab timp de comutare a contextului.
Odată ce modelul aplicației a fost adnotat cu stereotipuri MARTE pentru
caracteristici în timp real, trebuie convertit într-un model software care poate fi procesat
de instrumente pentru programabilitate și analiza performanței.
În [1.38] autorul propune o tehnică de traducere automată din modelele MARTE
în intrare pentru MAST (Modelare și analiză Suite pentru aplicații în timp real), care este
un instrument de analiză de programare de ultimă generație utilizat mediul academic.
1.8.2.2 Analiza arhitecturii și limbajului de proiectare
Pentru sistemele ciberfizice și, în special, pentru sistemele robotizate, analiza

timpului de răspuns este de o importanță capitală. Timpul de răspuns al unui sistem
încorporat depinde de latența dintre primirea unei intrări de la senzori și producerea unei
ieșiri către actuatori. De exemplu, siguranța depinde de latența răspunsului la detectarea
unui obstacol de-a lungul traseului robotului.
O astfel de analiză necesită modelarea unei aplicații atât din punct de vedere al
unităților de calcul, cât și al canalelor de comunicare. În special, într-un sistem distribuit
în timp real încorporat (Distributed Embedded Real-Time - DERT), comunicarea
poate fi periodică sau aperiodică, declanșată de evenimente sau bazată pe eșantionarea
datelor. Reprezentarea tuturor acestor tipuri de comunicări în MARTE este o provocare.
În mai multe domenii de aplicații, Limbajul de analiză și proiectare a arhitecturii
(Architecture Analysis and Design Language - AADL) [1.39] s-a dovedit a fi o un
limbaj bun de modelare pentru sistemele DERT.
AADL este un limbaj textual și grafic cu semantică de execuție precisă pentru
modelarea arhitecturii sistemelor software încorporate și a platformelor țintă ale acestora.
AADL oferă concepte de modelare pentru a descrie arhitectura de rulare a sistemelor
DERT în ceea ce privește componentele, conectorii, sarcinile concurente, interacțiunile
acestora și maparea lor pe o platformă de execuție. Recent, OMG a furnizat
specificațiilor MARTE instrucțiuni pentru maparea entităților sale de modelare la
conceptele AADL.
AADL este susținut de Open Source AADL Tool Environment (OSATE), care
vine cu o suită de instrumente de analiză automată. În special, OSATE include un
instrument de analiză a latenței fluxului care calculează automat latența de la un capăt la
altul, adică timpul necesar unui semnal pentru a călători de la sursă la chiuvetă și pentru
a verifica dacă sunt îndeplinite cerințele de latență.
În Fig. 1.30 este exemplificată specificația unui flux pentru componenta
LocalNavigator descrisă în Fig. 1.29. Interacțiunile dintre componente constau în fluxuri
direcționale de la un eveniment sau o sursă de date (scanerul laser), printr-o cale de

comunicare și procesare (adaptați traiectoria și refaceti calculul), la sistem de comandă
(rover).
Fig. 1.30 Specificația fluxului pentru LocalNavigator.
Pentru fiecare element de modelare, caracteristicile etichetei specifică interfața

componentei în ceea ce privește porturile de intrare și ieșire.
Modelul specifică timpul de latență legat de achiziționarea unui ”nor” de puncte,
adaptarea traiectoriei curente pentru a evita un obstacol, generarea unei comenzi de
răsucire și transmiterea comenzii către actuatoarele rover.
AADL mai este folosit și pentru a modela arhitectura sistemului de control pentru
un scaun cu rotile motorizat de monitorizare a siguranței. Analiza de latență end-to-end
este efectuată pentru a determina factori precum latența în răspunsul la apariția unui
obstacol, timpul de răspuns la o defecțiune și alegerea hardware-ului pentru
microcontroler.
1.8.2.3 Cadrul prioritar al interacțiunii comportamentale
Misiunile scumpe ale roboților, precum explorarea pe Marte și sistemele

critice de siguranță, cum ar fi mașinile fără șofer, cer dovezi formale ale
comportamentului lor corect, adică garantează că robotul nu va efectua acțiuni care
să ducă la consecințe catastrofale.
În mod informal, o proprietate de siguranță stipulează că „lucrurile rele” nu se
întâmplă în timpul executării unui program. De obicei, în contextul ingineriei
software, se aplică abordări de stare discrete pentru a explica comportamentul unui
sistem în ceea ce privește siguranța. Exemple sunt Statecharts, Petri Nets și Sistemele
de tranziție etichetate (Labelled Transition Systems - LTS). În acest context, o
proprietate de siguranță afirmă că programul nu prezintă comportamente rele, de ex.
nu intră niciodată într-o stare nedorită.
O problemă relevantă este compoziția „siguranței” proprietății în sistemele
simultane și distribuite. Abordările de ultimă generație se bazează pe definirea
modelelor LTS ale proceselor concurente, care sunt sincronizate prin acțiuni care
împart aceleași etichete. De exemplu, let drop reprezintă acțiunea în care un
manipulator robot plasează un obiect într-un coș transportat de un robot mobil.
Procesul software care controlează manipulatorul robotului trebuie să emită
comanda de a deschide mânerul numai atunci când brațul și rover-ul sunt în poziția
de cădere. În ceea ce privește LTS, scăderea este modelată ca o posibilă acțiune în
comportamentul independent atât al procesului care controlează manipulatorul
robotului, cât și al procesului care controlează robotul mobil. Executarea acestuia
necesită participarea simultană a ambelor procese.
Cadrul BIP (Behavior Interaction Priority) [1.40] este un limbaj de definiție a
arhitecturii pentru sistemele bazate pe componente, care utilizează LTS pentru
modelarea comportamentului (B) componentelor elementare și a interacțiunii dintre
componente. Tranzițiile dintre stările discrete ale comportamentului componentei
sunt declanșate de evenimente primite prin porturile componente (nume de acțiuni).
Componentele atomice pot fi asamblate pentru a forma componente compuse prin
intermediul unor conectori, care specifică posibila politică de interacțiune (I) între
porturile componentelor atomice. Comportamentul unei componente compuse este
formal descris ca fiind compoziția comportamentelor componentelor sale atomice.
La nivelul componentelor compuse, un set de reguli de prioritate (P) descrie politicile
de planificare a interacțiunilor dintre componentele atomice.
Cadrul BIP este susținut de un set de instrumente pentru analiza offline și un
motor pentru monitorizarea online a proprietăților de siguranță ale unui sistem bazat
pe componente. Pentru a dezvolta controlere software corecte prin construcție bazate
pe componente pentru roboți autonomi prin integrarea cadrului BIP cu arhitectura

LAAS. Abordarea propusă constă în:
• dezvoltarea componentelor funcționale ale unui control robot sisteme care
utilizează instrumentele arhitecturii LAAS,
• definirea unui model BIP corespunzător pentru componentele funcționale;
• adăugarea de constrângeri de siguranță în modelul BIP.
Constrângerile de siguranță pot fi codificate ca conectori BIP. De exemplu, să
luăm în considerare un robot mobil care să ghideze pacienții unui spital către un
cabinet medical la cerere. Vrem să exprimăm constrângerea că robotul poate executa
un singur serviciu de ghidare la un moment dat, adică nu lasă pacientul în mijlocul
unui coridor pentru a servi o cerere primită.
Acest lucru se poate face prin definirea unei constrângeri asupra valorilor
porturilor de intrare și ieșire ale componentei TrajectoryPlanner și ale componentei
LocalNavigator. Primul primește cereri GoTo și generează NewTrajectories. Acesta
din urmă notifică starea execuției curente a traiectoriei.
Pentru a pune în aplicare această constrângere, dacă LocalNavigator nu a
finalizat traiectoria curentă când se primește o nouă solicitare, noua cerere GoTo
este respinsă cu un mesaj de eroare specific (de ex. NOT-IDLE). În Fig. 1.31
avem o ilustrare a unei versiuni simplificate a sintaxei BIP pentru această
constrângere.
Fig. 1.31 Conector BIP.
La rulare, motorul BIP acționează ca controler al componentelor funcționale.

Împiedică robotul să ajungă la stări nesigure, chiar dacă există bug-uri la nivelul
decizional al arhitecturii de control și raportează defecțiuni la nivelul decizional.
1.8.3 Implementarea și integrarea sistemelor
MDE a devenit popular în multe domenii de inginerie datorită promisiunii sale

de a aduce beneficii în dezvoltarea de software, cum ar fi creșterea productivității și
a calității, datorită generării automate de cod din modele abstracte ale unei aplicații.
Ideea din spate este că modelul este mult mai simplu și, astfel, mai ușor de scris și
evaluat decât codul rezultat. Această idee este valabilă în principiu, dar în practică
rămâne o provocare să dezvoltăm medii MDE, care automatizează pe deplin
generarea de cod din modele, așa cum este ilustrat în [1.41]. Multe abordări MDE de
ultimă generație [1.42] constau în utilizarea unor generatoare de cod specifice
domeniului pentru transformarea modelelor abstracte în cod executabil. De obicei,
un generator de cod este specific pentru un limbaj de modelare și încorporează
cunoștințele unei platforme tehnologice specifice (un limbaj de programare, un cadru
middleware, o infrastructură de execuție, un mediu de simulare). Implementarea
generatoarelor de cod este cu greu o competență de bază pentru majoritatea
organizațiilor academice și industriale care dezvoltă tehnologii software pentru
domenii specifice de aplicații, cum ar fi robotica. Mai mult, robotica este un domeniu
extrem de centrat pe schimbări și noi platforme tehnologice (software și hardware)
sunt dezvoltate continuu. Aceasta înseamnă că generatorul de cod devine rapid
depășit.
Model Driven Architecture (MDA) și alte standarde asociate de la OMG sunt
o încercare de a reduce impactul modificărilor platformelor tehnologice asupra
ciclului de viață al sistemelor software. MDA impune o separare clară a arhitecturii
funcționale, denumită Model Independent Platform (PIM) al unui sistem software,
de detaliile tehnologice ale platformei specifice utilizate pentru implementarea
acestuia. Acest lucru se realizează folosind tehnici de transformare a modelelor care
convertesc PIM într-unul sau mai multe modele specifice platformei (PSM), care
specifică detaliile modului în care funcționalitatea sistemului folosește capacitățile
software-ului sau platformelor hardware pentru a-și asigura operațiunile. În ultimii
ani, industria de dezvoltare software a dezvoltat o varietate semnificativă de
instrumente care automatizează transformările de la model la model și de la model
la cod. Folosesc limbaje standard de transformare, care oferă construcții și
mecanisme pentru exprimarea, compunerea și aplicarea transformărilor [1.43].
Transformarea ulterioară a PSM în cod executabil necesită maparea
conceptelor de model arhitectural la anumite fragmente de cod fix (șabloane)
furnizate de un cadru de domeniu și o bibliotecă de componente care reprezintă
interfața cu platforma subiacentă (de exemplu, un middleware de calcul distribuit).
Șabloanele de cod au nevoie de dezvoltator de software pentru a completa detalii,
adică implementarea structurilor de date și a algoritmilor care oferă funcționalități
robotice specifice. În unele cazuri, acest cod poate fi generat automat din modele
comportamentale definite cu limbaje de modelare cu scop general, cum ar fi
diagrame de stare și rețele Petri, sau limbaje de modelare specifice domeniului, cum
ar fi diagrame bloc și grafice de legătură.
Următoarele secțiuni exemplifică trei abordări ale generării de cod, care sunt
în primul rând preocupate de reducerea decalajului dintre domeniul problemei și
domeniul implementării software-ului, prin captarea diferitelor aspecte ale
sistemelor de robotică.
1.8.3.1 SmartSoft
Proiectul SmartSoft [1.44] a dezvoltat un cadru de componente software, care

are ca scop simplificarea dezvoltării sistemelor de control distribuite în timp real și
prin standardizarea structurii componentelor și a conectorilor. Cadrul oferă

mecanisme pentru:
• implementarea componentelor software în conformitate cu principiile
calculului orientat spre servicii [1.45];
• interconectarea componentelor prin intermediul unor conectori care
implementați un set limitat de modele de comunicare care se găsesc de
obicei în aplicațiile de control robotizat;
• reconfigurarea dinamică a comportamentului componentelor și
interconectări în funcție de sarcina aplicației.
Fiecare componentă SmartSoft poate încapsula unul sau mai multe fire, care sunt
executate în contextul unui singur proces.
Fig. 1.32 Modelarea transformărilor în SmartSoft MDE Toolchain.

Componentele furnizează servicii și necesită servicii de la alte componente.

Serviciile componente schimbă date tastate numite obiecte de comunicare. În prezent
sunt disponibile două implementări de referință ale cadrului de componente
SmartSoft, una pentru sistemele de control în timp real bazate pe Linux cu extensia
RTAI și cealaltă pentru sistemele distribuite bazate pe CORBA.
Cadrul SmartSoft este însoțit de o bogată bibliotecă de componente, care
implementează cele mai comune funcționalități ale robotului. Lanțul de instrumente
SmartSoft MDE oferă editori grafici pentru proiectarea componentelor individuale,
serviciilor și interconectărilor și pentru specificarea proprietăților nefuncționale,
cum ar fi timpul de execuție a sarcinilor, perioada și utilizarea resurselor. Editorii
grafici se bazează pe profilul UML pentru SmartSoft, care definește stereotipurile
pentru proiectarea modelelor PIM și PSM.
Partea superioară a figurii (Fig. 1.32) descrie componenta LocalNavigator așa
cum este definită în PIM. Dezvoltatorul de software specifică interfața componentei
în ceea ce privește obiectele de comunicare și structura componentei în ceea ce
privește sarcinile concurente.
Pentru fiecare sarcină (identificată prin stereotipul Smart Task) proprietățile
nefuncționale (de exemplu, perioadă și wcet) indică valorile admisibile conform
specificațiilor cerințelor aplicației (de exemplu, wcet nu trebuie să depășească 50
ms). Transformarea PIM în PSM (partea centrală din Figura 3) necesită specificarea
platformei țintă software și hardware. Aici, sarcinile abstracte sunt mapate la fire
RTAI Linux, așa cum este indicat de stereotipul RTAI Task. Proprietățile
nefuncționale indică valori reale, cum ar fi wcet-ul măsurat.
În cele din urmă, codul sursă al LocalNavigator este generat prin
personalizarea șablonului componentei generice SmartSoft cu informațiile modelate
în PIM.
Dezvoltatorul de software trebuie să finalizeze implementarea componentei
prin codarea manuală a funcționalității furnizate. În cel mai simplu caz, codul generat
poate fi utilizat ca o împachetare a unei biblioteci software existente. Interconectările
componentelor sunt specificate la momentul proiectării în PIM, dar pot fi modificate
în timpul rulării pentru a adapta comportamentul robotului la condițiile operaționale
efective. Sarcina ObstacleAvoider necesită informații senzoriale (de exemplu, un nor
de puncte) pentru a detecta obstacolele. La timpul de rulare, diferiți senzori pot
furniza norul de puncte pe baza iluminării mediului (de exemplu, un scaner laser sau
o cameră stereo RGB).
SmartSoft MDE include Limbajul de coordonare a sarcinilor (SmartTCL)
pentru specificarea sarcinilor la nivel înalt ale aplicației (să aducă cafea vizitatorilor)
pe care robotul le poate îndeplini și modul în care aceste sarcini sunt rafinate în
timpul executării sarcinii în ceea ce privește serviciile furnizate de componente
individuale („navigați spre aparatul de cafea”).
Cadrul SmartSoft oferă motorul SmartTCL care se ocupă de orchestrarea
sistemului de control prin activarea, dezactivarea și interconectarea componentelor
conform planului de acțiune.
1.8.3.2 Proteus
Proiectul Proteus [36] (Platform for RObotic Modeling and Transformation

for End-Users and Scientific Communities) este o inițiativă a comunității robotizate
franceze (GDR Robotique) care a dezvoltat un set de instrumente MDE pentru
proiectarea și implementarea sistemului robotizat.
Trăsătura distinctivă a Proteus Toolkit este utilizarea unui set de ontologii [37]
pentru reprezentarea cunoștințelor despre sistemele robotizate, mediile operaționale
și aplicațiile.
Ontologiile Proteus sunt o încercare de a formaliza vocabularul inginerilor de
sisteme robotizate, pentru a le permite să modeleze arhitecturile de control ale
robotului direct în termeni de concepte de domeniu (de exemplu, senzor, planificator
de mișcare, rover etc.) și nu numai în ceea ce privește software-ul concepte (de
exemplu, componentă, port, algoritm etc.) Inițiative similare sunt sponsorizate de
IEEE Standard Association, care a stabilit grupul de lucru Ontologii pentru robotică
și automatizare.
Fig. 1.33 Profilul RobotML pentru senzorii robotului.
Ontologiile Proteus stau la baza limbajului specific domeniului Proteus

(RobotML) [38], care include entități de modelare pentru elemente arhitecturale
specifice (de exemplu, Robot, SesorSystem, ActuatorSystem, LocalizationSystem)
și stiluri arhitecturale (de exemplu, reactiv, deliberativ, hibrid).
În mod similar cu SmartSoft (a se vedea secțiunea III-A), lanțul de instrumente

Proteus se bazează pe un profil UML pentru definirea PIM a arhitecturii funcționale a
robotului. În Fig. 1.33 prezintă un extras din profilul RobotML pentru senzorii
robotului, în care entitățile de modelare CameraSystem și LidarSystem sunt definite ca
stereotipuri care pot fi utilizate pentru a adnota componentele arhitecturii de control a
robotului.
Pentru generarea de cod, elementele modelului PIM trebuie alocate unei
platforme de execuție, cum ar fi un middleware și un simulator. De exemplu,
elementul care reprezintă funcționalitatea robotului și activitățile de control sunt
alocate unui middleware bazat pe componente, în timp ce elementul care reprezintă
echipamentul robot este alocat unui simulator.
1.8.3.3 Modelarea comportamentului componentelor
Generarea de coduri din modele de comportament este un domeniu de interes

în creștere datorită beneficiilor sale de a verifica modelele prin simulare și de a
reduce eforturile de codare manuală predispuse la erori. Mai multe instrumente
generează specificații UML din codul sursă pentru limbaje obișnuite, cum ar fi C, C
+, Java și pentru limbaje de simulare, cum ar fi SystemC. De obicei, mediile MDE
care acceptă modelarea arhitecturală bazată pe componente (a se vedea secțiunea II)
oferă, limbaje pentru modelarea comportamentului discret al componentelor
individuale, cum ar fi UML Statecharts și Petri Nets.
Atunci când dezvoltă software de control încorporat, inginerii de sisteme de
control modelează atât algoritmul de control, cât și sistemul de controlat, așa-numita
instalație, împreună pentru a asigura performanțe optime ale proceselor cu dinamică
continuă [1.46]. De obicei, funcționalitățile de control ale robotului sunt modelate în
mod convenabil ca sisteme hibride, deoarece pot specifica schimbarea continuă a
stării sistemului, precum și tranziția discretă a stărilor. Comportamentul continuu
poate fi specificat folosind ecuații diferențiale și ecuații algebrice.
Generarea de coduri din modele de sisteme hibride implică în cele din urmă
simularea schimbării continue a unei variabile prin actualizarea treptată a variabilei
pe baza metodelor numerice. Acest lucru necesită proiectantului modelului să aloce
o rată prin care evoluează starea continuă.
Mai multe medii de modelare și simulare pentru sisteme încorporate (Matlab
/ Simulink și SimScape) acceptă generarea de coduri de la modele continue și
hibride, definite cu limbaje specifice domeniului, cum ar fi Bond Graphs, Block
Diagrams și Modelica. Aceste instrumente permit definirea de șabloane
personalizate pentru generarea de cod pentru a simplifica integrarea codului
comportamental cu cadrele componente.
În [1.47] autorii exemplifică modelarea, generarea codului și procesul de
integrare pentru sistemul de control al mișcării manipulatorului mobil KUKA
youBot. Proiectarea algoritmului necesită un model al sistemului care va fi controlat.
Au folosit lanțul de instrumente SimScape pentru a modela lanțul cinematic youBot
ca grafic de legătură și lanțul de instrumente bazat pe model BRIDE [44] pentru a

modela sistemul de control bazat pe componente.
Proiectarea algoritmului de control se realizează în paralel cu proiectarea
arhitecturii componentei. Aceste două faze de proiectare au dependențe reciproce și
necesită o abordare iterativă.
Algoritmul este partiționat în blocuri de funcționalități elementare cu interfețe
bine definite, în așa fel încât să poată fi modificate independent (de exemplu, pentru
îmbunătățirea performanței lor) fără a afecta proiectarea și implementarea restului
sistemului.
Pe de altă parte, transmiterea mesajelor între componente poate introduce
pierderi de mesaj și întârzieri în actualizări și comunicare între senzori, controler și
actuatoare care trebuie să fie reprezentate în mod explicit în modelul algoritmului de
control. Cerințele nerezonabile de comunicare (astfel de bandă extremă sau o latență
mică inaccesibilă) pot duce la restructurarea arhitecturii componentei.
1.8.4 Configurarea de sistem
Practica actuală în ingineria software pentru robotică constă în dezvoltarea

componentelor software, care implementează funcționalități robotice unice. Această
abordare este întruchipată de o mantră repetată în rândul dezvoltatorilor ROS [9]:
„Nu vă înfășurăm principalul”. Punctul forte al acestei abordări este posibilitatea de
a dezvolta o mare varietate de sisteme de control diferite prin compunerea în mai
multe moduri a blocurilor software reutilizabile. Punctul său slab este lipsa de sprijin
pentru reutilizarea soluțiilor eficiente la problemele recurente de proiectare
arhitecturală.
În consecință, dezvoltatorii de aplicații și integratorii de sistem trebuie să
rezolve problemele de proiectare arhitecturală întotdeauna de la zero. Provocarea
dificilă constă în selectarea, integrarea și configurarea unui set coerent de
componente care furnizează funcționalitatea necesară ținând cont de dependențele
lor reciproce și de nepotrivirile arhitecturale.
Această provocare este exacerbată de particularitatea domeniului roboticii:
roboții pot avea multe scopuri, multe forme și multe funcții. În consecință, fiecare
sistem robotizat trebuie să fie configurat cu un amestec specific de funcționalități și
care depinde puternic de structura mecanică a robotului (un rover cu brațe zero sau
multiple), sarcina care trebuie îndeplinită (curățarea unei pardoseli, salvarea
oamenilor după un dezastru) , precum și condițiile de mediu (interior, exterior,
subteran).
În diverse domenii de aplicații, dezvoltarea liniei de produse software
(Software Product Line - SPL) s-a dovedit a fi cea mai eficientă abordare pentru a
face față acestui tip de provocări. Un SPL este o familie de aplicații (produse) care
împărtășesc multe aspecte comune (structurale, comportamentale etc.) și care se
adresează împreună unui anumit domeniu.
De obicei, un SPL este o investiție strategică pentru o companie de inginerie
care dorește să obțină valoarea clienților printr-o mare diversitate comercială a
produselor sale (de exemplu, diferite sisteme de control pentru logistica depozitelor)
cu o diversitate tehnică minimă la un cost minim.
Miezul unui SPL este o arhitectură software stabilă, care separă în mod clar
caracteristicile comune de variațiile reflectate în produse și prescrie modul în care
componentele software pot fi asamblate pentru a obține produse individuale. Fiecare
aplicație nouă este construită prin configurarea SPL, adică prin selectarea variantelor
(de exemplu, funcționalități, resurse software) care îndeplinesc cerințele specifice
ale aplicației.
Mediile MDE simplifică configurația sistemului oferind limbaje specifice
domeniului pentru a modela variabilitatea robotului și transformări de la model la
model pentru a rezolva variabilitatea în sistemul de control al software-ului.
1.8.4.1 Software pentru robotică
Lanțul de instrumente HyperFlex [1.48] este un mediu MDE pentru

dezvoltarea și configurarea liniilor de produs software (SPL) pentru robotică. Oferă
limbaje specifice domeniului și editori grafici pentru definirea a trei tipuri de modele.
Modelul arhitectural șablon reprezintă arhitectura software (așa cum este discutat în
secțiunea II) a unei familii de sisteme software similare. Ca atare, reprezintă în mod
explicit toate componentele (variantele) posibile care implementează o
funcționalitate dată (punctul de variație). De exemplu, funcționalitatea de evitare a
obstacolelor ar putea fi asigurată de două componente alternative care
implementează abordarea cu histogramă vectorială sau abordarea cu fereastră
dinamică.
Modelul de caracteristici [1.49] reprezintă simbolic caracteristicile variante
ale unui sistem de control; simbolurile pot indica funcționalitatea individuală a
robotului (de exemplu, localizarea bazată pe marker) sau concepte relevante în
domeniul aplicației, cum ar fi tipul de articole pe care robotul trebuie să le transporte
(de exemplu, lichide, materiale fragile etc.), care afectează configurația sistemul de
control. Modelul de rezoluție definește transformările de la model la model, care
permit configurarea automată a arhitecturii și funcționalității unui sistem de control
pe baza caracteristicilor necesare. În acest context, configurația arhitecturii înseamnă
rezolvarea variabilității funcționale a unui sistem selectând o variantă pentru fiecare
punct de variație.
O transformare model-text generează fișierul de configurare (fișier de lansare)
corespunzător arhitecturii sistemului de control configurat În prezent, HypeFlex
acceptă configurarea sistemelor bazate pe componente bazate pe cadrele ROS și
OROCOS.
Exemplul de SPL (Fig. 1.34) legat de sistemul simplu are o componenta
compusă LocalNavigator încapsulează componenta TrajectoryFollower (a se vedea
Figurafig: UML-MARTE), care implementează algoritmul de generare a comenzilor
de răsucire la componenta BaseController pentru a urmează o traiectorie dată.
Fig. 1.34 Modelul de caracteristici HyperFlex al sistemului de navigare.
Analizând acum o altă aplicație în care robotul trebuie să urmeze o țintă în

mișcare (de exemplu, un alt robot). Componenta TrajectoryFollower este înlocuită
cu componenta LeaderFollower care generează periodic comenzi de răsucire pentru
robot în funcție de poziția țintei estimate de senzori.
HyperFlex permite să reprezinte strategia de navigație ca un punct de variație
care poate fi rezolvat selectând la momentul implementării fie componenta
LeaderFollower, fie componenta TrajectoryFollower. În Fig. 1.34 se prezintă
modelul de caracteristici al sistemului de navigare. Căsuțele verzi reprezintă
caracteristicile selectate. Triunghiurile de sub casete indică cardinalitatea punctului
de variație. În special, indică faptul că pentru fiecare punct de variație poate fi
selectată o singură variantă. Cercurile negre indică faptul că caracteristica copil este
obligatorie.
1.8.4.2 Modelarea resurselor robotizate
Un model al întruchipării robotului (structura cinematică, caracteristicile

dispozitivului etc.) și un model al mediului operațional (obiectele de recunoscut,
evitat, înțeles etc.) sunt cruciale pentru manipularea și navigarea obiectelor. Acestea
acționează ca resurse comune între mai multe funcționalități ale robotului, cum ar fi
percepția, planificarea și controlul. Majoritatea algoritmilor care implementează
aceste funcționalități sunt parametrice în ceea ce privește întruchiparea și modelele
mondiale. Aceasta înseamnă că sistemul de control al robotului poate fi configurat
la momentul implementării în conformitate cu cerințele specifice ale aplicației și
poate fi reutilizate fără modificări pentru diferite sarcini și diferite sisteme robotizate.
În [1.50] autorii prezintă un limbaj de modelare specific domeniului textual
pentru modelarea aspectelor structurale ale întruchipării și mediului robotului ca un
grafic de scenă, adică o descriere a obiectelor relevante și a relațiilor dintre acestea.
Aceste relații sunt organizate într-un grafic aciclic direct (DAG). Scene Graph poate
exprima cunoștințe semantice anterioare despre o scenă, cum ar fi morfologia și
aspectul unui obiect (de exemplu, un tabel) pe care robotul ar trebui să îl recunoască
și să îl localizeze în mediu.
Un alt exemplu de limbaj de modelare textuală este prezentat în [1.51].
Permite descrierea constrângerilor diferențiale găsite în mod obișnuit în problemele
de planificare a mișcării pentru roboții mobili. ), x, y și theta reprezintă configurația
robotului (vectorul de stare), r este raza roții și L este distanța dintre cele două roți
(Fig. 1.35).
Fig. 1.35 Specificarea unei constrângeri diferențiale.
Aceste modele sunt utilizate pe scară largă în algoritmi de simulare (care,

având în vedere configurația de pornire și vectorul de acțiune, calculează
configurația finală a robotului) și algoritmi de planificare a mișcării bazate pe
eșantionare (care eșantionează configurații fără coliziuni care trebuie să fie
compatibile cu constrângerile diferențiale ). Pentru a calcula configurațiile finale este
necesar să se rezolve ecuațiile diferențiale și acest lucru se poate face prin
intermediul unor rezolutori, care utilizează tehnici de aproximare numerică.
Bibliografie – Capitolul 1
1.1. A. Rayl, „NASA engineers and scientists—Transforming dreams into

reality.,” NASA 50th Anniversary Magazine, 16 October 2008.
1.2. SWEBOK, “Software Engineering Body of Knowledge,” swebok.pdf,
available from http://www .computer.org/web/swebok/v3, IEEE, 2013.
1.3. R. J. Leach, Introduction to Software Engineering, Second edition, Ed. CRC
Press - Taylor & Francis Group, Chapman & Hall/CRC, September 2016,
ISBN: 978-1-4987-0527-1, pp. 390.
1.4. P. Bourque, R.E. Fairley, IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK(R)): Version 3.0, IEEE
Computer Society Press, Washington DC, United States, ISBN:978-0-7695-
5166-1, 2014, pp. 346, https://dl.acm.org/doi/book/10.5555/2616205 .
1.5. P. Ralph, The two Paradigms of Software Development Research, Science of
Computer Programming SSRN Electronic Journal January 2018, pp. 24,
https://doi.org/10.1016/j.scico.2018.01.002 .
1.6. J. Bartoníček, Programming Language Paradigms & the Main Principles of

Object-Oriented Programming, CRIS - Bulletin of the Centre for Research and
Interdisciplinary Study 2014, pp. 93-99, http://doi.org/10.2478/cris-2014-
0006 .
1.7. B. Adhikari, Object Oriented Programming Vs Procedural Programming,
2016, pp.4, https://doi.org/10.13140/RG.2.2.33443.45604 .
1.8. F.U. Onu, M.O. Ezeji, Comparative Study of Structured and OOP Paradigms,
International Journal of Advanced Research in Computer Science and
Software Engineering, ISSN: 2277 128x, 2016, 6(8), pp. 30-39.
1.9. B. Rumpe, Executable Modeling with UML - A Vision or a Nightmare? In T.
Clark and J. Warmer, editors, Issues & Trends of Information Technology
Management in Contemporary Associations, Seattle 2002, pp. 697–701.
1.10. J. Erickson, K. Siau, Unified Modeling Language: The Teen Years and
Growing Pains, Conference: Proceedings of the 15th international conference
on Human Interface and the Management of Information: information and
interaction design - Volume Part I, 2013, pp. 10, http://doi.org/10.1007/978-
3-642-39209-2_34 .
1.11. M.A.A. Abdul Rahman, K. Mayama, T. Takasu, A. Yasuda, M. Mizukawa,
Model-Driven Development of Intelligent Mobile Robot Using Systems
Modeling Language (SysML), Mobile Robots - Control Architectures, Bio-
Interfacing, Navigation, Multi Robot Motion Planning and Operator Training,
2011, pp. 21-38, http://doi.org/10.5772/26906 .
1.12. B. Rumpe, Agile Modeling with UML. Code Generation, Testing,
Refactoring, Ed. Springer, 3rd Edition, February 2017, ISBN: 978-3-319-
58861-2, pp. 388, https://doi.org/10,1007/978-3-319-58862-9 .
1.13. M. Fowler. Refactoring. Improving the Design of Existing Code. Second
Edition, AddisonWesley, 2018, ISBN: 978-0-13-475759-9, pp.455.
1.14. U. Thomas, G. Hirzinger, B. Rumpe, C. Schulze, and A. Wortmann. A New
Skill Based Robot Programming Language Using UML/P Statecharts, In
Conference on Robotics and Automation (ICRA’13) IEEE, 2013, pp. 461–
466. IEEE, http://doi.org/10.1109/ICRA.2013.6630615 .
1.15. H. Krahn, B. Rumpe, S. Volkel, “MontiCore: a framework ¨ for compositional
development of domain specific languages,” Int J Softw Tools Technol
Transfer - STTT 2010, vol. 12, no. 5, pp. 353–372, https://doi.org/
10.1007/s10009-010-0142-1.
1.16. M. Schindler, Eine Werkzeuginfrastruktur zur agilen Entwicklung mit der
UML/P, ser. Aachener Informatik-Berichte, Software Engineering, Band 11.
Shaker Verlag, 2012, http://publications.rwth-aachen.de/record/63044?ln=de.
1.17. M. Rickert, A. Gaschler, Robotics Library: An Object-Oriented Approach to
Robot Applications, Robotics Library 2017, https://www.roboticslibrary.org/
, https://www.roboticslibrary.org/Rickert2017a.pdf.
1.18. R. Featherstone, "A Beginner's Guide to 6-D Vectors (Part 2) [Tutorial]," in
IEEE Robotics & Automation Magazine, vol. 17, no. 4, pp. 88-99, Dec. 2010,
https://doi.org/10.1109/MRA.2010.939560..
1.19. M. Rickert, “Efficient motion planning for intuitive task execution in modular
manipulation systems,” Dissertation, Technische Universitat¨ Munchen,
2011, https://mediatum.ub.tum.de/doc/981979/981979.pdf .
1.20. M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler,
and A. Y. Ng, “ROS: An open-source robot operating system,” in Proc. of the
IEEE Intl. Conf. on Robotics and Automation, Workshop on Open Source
Software in Robotics, 2009.
1.21. Y. Maruyama, S. Kato, T. Azumi, Exploring the Performance of ROS2,
EMSOFT’16, October 01-07, 2016, Pittsburgh, PA, USA, ISBN 978-1-4503-
4485-2/16/10.https://dx.doi.org/10.1145/2968478.2968502.
1.22. M. Strandberg, “Robot path planning: An object-oriented approach,” Ph.D.
dissertation, School of Electrical Engineering, Royal Institute of Technology,
2004.
1.23. I. A. Sucan, M. Moll, and E. Kavraki, “The open motion planning library,”
IEEE Robotics & Automation Magazine, vol. 19, no. 4, pp. 72–82, 2012,
https://doi.org/10.1109/MRA.2012.2205651 .
1.24. G. Guennebaud, B. Jacob, et al., “Eigen v3,” https://eigen.tuxfamily.org/
index.php?title=Main_Page, accesat 08.03.2021.
1.25. Fred Brackx, The exponential function of a quaternion variable, Applicable
Analysis, 1979 January, 8(3): 265-276, https://doi.org/ 10.1080/
00036817908839234 .
1.26. B. Dam, M. Koch, M. Lillholm, “Quaternions, interpolation and animation,”
Department of Computer Science, University of Copenhagen, Tech. Rep.
DIKU-TR-98/5, 1998.
1.27. R. Featherstone, Rigid Body Dynamics Algorithms. A comprehensive
collection of the best rigid-body dynamics algorithms Springer, 2008, eBook
ISBN 978-1-4899-7560-7, https://doi.org/10.1007/978-1-4899-7560-7 .
1.28. A. Barbalace, A. Luchetta, G. Manduchi, M. Moro, A. Soppelsa, and C.
Taliercio, “Performance comparison of VxWorks, Linux, RTAI and Xenomai
in a hard real-time application,” in Proc. of the IEEE-NPSS Real-Time Conf.,
2007, pp. 1–5.
1.29. A. Kecskemethy and M. Hiller, “An object-oriented approach for an effective
formulation of multibody dynamics,” Computer Methods in Applied
Mechanics and Engineering, vol. 115, no. 3–4, pp. 287–314, 1994.
1.30. Andreas Scholz, Ian Stavness, Michael Sherman, Scott Delp and Andrés
Kecskeméthy, Improved Muscle Wrapping Algorithms Using Explicit Path-
Error Jacobians, F. Thomas and A. Pérez Gracia (eds.), Computational
Kinematics, 395 Mechanisms and Machine Science 15, © Springer
Science+Business Media Dordrecht 2014, https://doi.org/10.1007/978-94-
007-7214-4_44 .
1.31. A. Gaschler, Q. Fischer, and A. Knoll, “The bounding mesh algorithm,”
Technische Universitat Munchen, Germany, Tech. Rep. TUM-I1522,
Published 2015 Mathematics, ID: 14538041.
1.32. Collada – Digital Asset Schema Release 1.5.0, Specification, Ed. M. Barnes,
E.L. Finch, Sony Computer Entertainment Inc., 2-6-21 Minami-Aoyama,
Minato-ku, Tokyo 107-0062 Japan, April 2008.
1.33. M. Rickert, A. Sieverling and O. Brock, "Balancing Exploration and
Exploitation in Sampling-Based Motion Planning," in IEEE Transactions on
Robotics, vol. 30, no. 6, pp. 1305-1317, Dec. 2014,
https://doi.org/10.1109/TRO.2014.2340191.
1.34. D. Brugali, Model-Driven Software Engineering in Robotics, IEEE Robotics
& Automation Magazine 2015, 22(3), pp. 155-166,
http://doi.org/10.1109/MRA.2015.2452201 .
1.35. P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and
J. Stafford, Documenting Software Architectures: Views and Beyond. Boston,
MA: Addison-Wesley, 2003.
1.36. J. Ivers, P. Clements, D. Garlan, R. Nord, B. Schmerl, and O. Silva,
“Documenting component and connector views with uml 2.0,” Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, Tech. Rep.
CMU/SEI-2004-TR-008, 2004. http://resources.sei.cmu.edu/library/asset-
view.cfm?AssetID=7095.
1.37. D. Garlan, “Formal modeling and analysis of software architecture:
Components, connectors, and events.” in SFM, ser. Lecture Notes in
Computer Science, M. Bernardo and P. Inverardi, Eds., vol. 2804. Springer,
2003, pp. 1–24, http://dblp.unitrier.de/db/conf/sfm/sfm2003.htmlGarlan03.
1.38. J. Medina and A. Garcia Cuesta, “Model-based analysis and design of real-
time distributed systems with ada and the uml profile for marte,” in Reliable
Software Technologies - Ada-Europe 2011, ser. Lecture Notes in Computer
Science, A. Romanovsky and T. Vardanega, Eds. Springer Berlin Heidelberg,
2011, vol. 6652, pp. 89–102.
1.39. P. H. Feiler and D. P. Gluch, Model-Based Engineering with AADL: An
Introduction to the SAE Architecture Analysis & Design Language, 1st ed.
Addison-Wesley Professional, 2012.
1.40. A. Basu, M. Bozga, and J. Sifakis, “Modeling heterogeneous real-time
components in bip,” in Proceedings of the Fourth IEEE International
Conference on Software Engineering and Formal Methods, ser. SEFM ’06.
Washington, DC, USA: IEEE Computer Society, 2006, pp. 3–12,
http://dx.doi.org/10.1109/SEFM.2006.27.
1.41. R. France, B. Rumpe, and M. Schindler, “Why it is so hard to use models in
software development: observations,” Software Systems Modeling, vol. 12,
no. 4, pp. 665–668, 2013, http://dx.doi.org/10.1007/s10270-013-0383-z.
1.42. Y. Zheng and R. N. Taylor, “A classification and rationalization of model-
based software development,” Softw. Syst. Model., vol. 12, no. 4, pp. 669–
678, Oct. 2013, http://dx.doi.org/10.1007/s10270-013-0355-3.
1.43. S. Sendall and W. Kozaczynski, “Model transformation: The heart and soul
of model-driven software development,” IEEE Softw., vol. 20, no. 5, pp. 42–
45, Sep. 2003, http://dx.doi.org/10.1109/MS.2003.1231150.
1.44. A. Lotz, J. F. Ingles-Romero, D. Stampfer, M. Lutz, C. Vicente-Chicote, and

C. Schlegel, “Towards a stepwise variability management process for
complex systems: A robotics perspective,” Int. J. Inf. Syst. Model. Des., 5(3),
pp. 55–74, Jul. 2014, http://dx.doi.org/10.4018/ijismd.2014070103.
1.45. M. Huhns and M. Singh, “Service-oriented computing: key concepts and
principles,” Internet Computing, IEEE, vol. 9, no. 1, pp. 75–81, Jan 2005.
1.46. J. Palczynski and S. Kowalewski, “Early behaviour modelling for control
systems,” in Computer Modeling and Simulation, 2009. EMS ’09. Third
UKSim European Symposium on, Nov 2009, pp. 148–153.
1.47. Y. Brodskiy, R. Wilterdink, S. Stramigioli, and J. Broenink, “Fault avoidance
in development of robot motion-control software by modeling the
computation,” in 4th International Conference on Simulation, Modeling, and
Programming for Autonomous Robots, SIMPAR 2014, ser. Lecture notes in
computer science, D. Brugali, J. Broenink, T. Kroeger, and B. MacDonald,
Eds., vol. 8810. Springer International Publishing, October 2014, pp. 158–
169.
1.48. L. Gherardi and D. Brugali, “Modeling and Reusing Robotic Software
Architectures: the HyperFlex toolchain,” in IEEE International Conference on
Robotics and Automation (ICRA 2014). Hong Kong, China: IEEE, May 31 -
June 5 2014.
1.49. K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson, “Feature-oriented
domain analysis (foda) feasibility study,” Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, PA, Tech. Rep. CMU/SEI-90-TR-021,
1990. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=11231.
1.50. S. Blumenthal and H. Bruyninckx, “Towards a Domain Specific Language for
a Scene Graph based Robotic World Model,” in 4th International Workshop
on Domain-Specific Languages and models for ROBotic systems (DSLRob-
13), Tokyo University, Japan, Nov. 2013..
1.51. M. Guarnieri, E. Magri, D. Brugali, and L. Gherardi, “A Domain Specific
Language for Modeling Differential Constraints of Mobile Robots,” in
International Conference on Autonomous Robot Systems and Competitions
(Robotica 2012), Guimares, Portugal, 2012, http://hdl.handle.net/1822/18887.
Abrevieri – Capitolul 1
Abrevierea Explicație
DRM Digital Restrictions Management – Gestiunea
Restricțiilor Digitale
SaaS Software as a Service – Software Ca Serviciu
ALM Application Lifecycle Management
DOS Disk Operating System
MS-DOS Microsoft - Disk Operating System
PC Personal Computer
PDP Programmed Data Processor
IBM International Business Machines
Mac OS Mac Operating System, Mac - Macintosh
OS X Este a zecea versiune a Mac OS
iOS Sistem de operare pentru Apple și este un sistem de
operare tip UNIX
UNIX Este un sistem standard deschis, bazat pe sistemul IBM
AIX
QA Quality assurance
SDLC The Software Development Life Cycle
NATO Organizația Atlanticului de Nord
SWEBOK Software Engineering Body of Knowledge
BASIC Limbaj de programare
DRM Digital Restrictions Management
UNIX Sistem de operare
ALM Application Lifecycle Management
QA Quality Assurance
OO Orientată pe Obiect
UML Unified Modeling Language
RTM Robot Technology Middleware – Tehnologie Robotică
Middleware)
AIST The National Institute of Advanced Industrial Science and
Technology
MDA Model Driven Architecture
PIM Platform Independent Model
PSM Platform Specific Model
SysML Systems Modeling Language
SDLC The Software Development Life Cycle
ADP Advanced Development Projects
OMT Object Modeling Technique
ROS Robot Operating System
API Application Programming Interface
RL Robotics Library
VRLM Virtual Reality Modeling Language

MDE Model-Driven Engineering
MDA Model Driven Architecture
OMG Object Management Group
MARTE Modeling and Analysis of Real-Time Embedded Systems
HLAM High-Level Application Modeling
SRM Software Resource Modeling
LTS Labelled Transition Systems
BIP Behavior Interaction Priority
LAAS Architecture for Autonomous System
Proteus Platform for RObotic Modeling and Transformation for
End-Users and Scientific Communities
2. INTELIGENȚA ARTIFICIALĂ
2.1 Noțiuni introductive
Inteligența artificială (IA) este un ansamblu de reprezentări, tehnici și arhitecturi

folosite pentru a construi sisteme aplicate din punct de vedere computațional. IA
studiază regulile de înlănțuire, căutare euristică, logică, propagare a constrângerilor,
căutare constrânsă și alte paradigme de rezolvare a problemelor. În plus, utilizează
arbori de decizie, rețele neuronale, SVMs și alte paradigme de învățare.
Definirea noțiunii de IA are în vedere modul în care funcționează procesele
de gândire umană, raționamentele și comportamentele. Deși există multe orientări
din punct de vedere semantic, IA este o formă artificială de percepție, analiză și
acțiune față de stimulii introduși în ecuație.
Literatura de specialitate folosește în acest moment câteva clase de definiții:
• sisteme bazate pe gândirea umană;
• sisteme bazate pe un mod de gândire rațional;
• sisteme similare ca mod de acțiune cu cel uman;
• sisteme al căror mod de acțiune are la bază algoritmi raționali.
Fig. 2.1 Reprezentarea experimentului Turing.

http://id.inf.ucv.ro/~cstoean/courses/ia/c1.pdf
Aceste clase de „interpretare” a realității funcționează în baza unor algoritmi

polinomiali, care reprezintă aproximări ale unor probleme pentru care nu există
soluţii polinomiale, a unor sisteme fizic bazate pe testul Turing, a modul în care
interacționează o mașină și a tehnicilor computaționale.
Testul Turing1 este în fapt un proces simplu de verificare a modului în care un
interlocutor uman poartă un dialog cu un om și cu un calculator. Dacă interlocutorul
1
http://www.psych.utoronto.ca/users/reingold/courses/ai/turing.html
2 – Inteligența Artificială 92
este separat de om și de calculatorul autonom este posibil ca operatorul să nu știe de

la cine primește răspunsul. Carcateristicile calculatorului trebuie să poată procesa
limbajul utilizat, să poată efectua o reprezentare a informației, să raționeze
independent și mai ales să poată învăța, astfel încât să se poată adapta.
Domeniile inteligenței artificiale şi roboticii mobile au fost întotdeauna strâns
legate. Chiar înainte de conferinţa de la Dartmouth College2, din anul 1956, când
termenul de inteligență artificială a fost utilizat în mod oficial, se cunoştea faptul că
roboţii mobili pot fi programaţi să îndeplinească taskuri complexe şi să înveţe.
Marvin Minsky şi John McCarthy, pionieri în studiul inteligenței artificiale, au fost
interesaţi de robotica mobilă imediat după aceasta conferinţă şi, la sfârşitul anilor
'50, împreună cu Richard Greenblood şi William Gosper, încearcă să construiască
un robot care să poată juca ping-pong. Dificultăţile tehnice datorate unui hardware
neadecvat fac însă ca robotul să poată prinde doar mingea într-un coş de baschet.
În foarte multe cazuri, roboţii mobile, sunt utilizați sub forma unor vehicule
capabile să opereze autonom și/sau semiautonom, după cum urmează:
• tereștri - UGV - Unmanned Ground Vehicle;
• aerieni - UAV - Unmanned Aerial Vehicle;
• acvatici/maritime - UUV - Unmanned Undersea Vehicle.
În prezent, sistemele robotizate mobile se află la intersecţia mai multor
domenii ale ştiinţei. Remarcăm dintre acestea:
• Knowledge Representation - Reprezentarea cunoştinţelor: este domeniul
inteligenței artificiale care ajută la obţinerea unui model intern al lumii
asociat taskului pe care îl execută robotul. Se folosesc structuri de date şi
algoritmi specifici pentru reprezentarea caracteristicilor obiectelor din
mediu;
• Natural language understanding (NLU) - înţelegerea limbajului natural:
limbajul natural se schimbă cu o frecvenţă destul de mare, astfel încât,
simpla recunoaştere a cuvintelor nu mai este suficientă pentru înţelegerea
sensului real al unui text prelucrat;
• Learning - Învăţarea: în mod ideal, un robot ar putea învăţa task-urile pe
care le are de îndeplinit prin simpla repetare a acţiunilor similare executate
de un operator uman;
• Planning and problem solving - Planificare şi soluţionare de probleme:
inteligenţa artificială este în mod inerent asociată abilităţii de a planifica
acţiunile necesare pentru a îndeplini un anumit obiectiv, precum şi abilităţii
de a rezolva probleme apărute în cazul nefuncţionării acestor planuri de
acţiune;
• Inference - Inferență: prin inferenţă, este posibilă completarea informaţiei
care lipseşte pentru soluţionarea unei anumite probleme;
• Search - Căutare: în termenii inteligenței artificiale, prin căutare se înţelege
examinarea eficientă a unei reprezentări a cunoştinţelor, specifică unei anumite
probleme (căutare într-un „spațiu”), în scopul determinării unei soluţii;
2
https://en.wikipedia.org/wiki/Dartmouth_Conferences ;
http://www-formal.stanford.edu/jmc/history/dartmouth/dartmouth.html
• Vision - Vedere artificială: prin realizarea sistemelor de vedere artificială,

acţiunile robotului mobil pot deveni mai precise şi mai complexe.
Roboţii mobili semiautonomi/autonomi reprezintă în viziunea actuală cea mai
apropiată aproximare a agenţilor inteligenţi. Oamenii au fost interesaţi întotdeauna
de construirea unor maşini care să imite fiinţele biologice. Începând cu realizările
mecanice ale vechilor orologii şi până la agenţi software şi agenţi fizici actuali,
căutarea răspunsului la eterna întrebare „Ce este viața?” a constituit întotdeauna un
motiv de impulsionare a cercetărilor ştiinţifice. În prezent, pentru a interacţiona cu
mediul înconjurător, astfel de sisteme inteligente anticipează rezultatul propriilor
acţiuni şi fac predicţii asupra comportamentului altor obiecte. Această strânsă
conexiune între percepţie şi acţiune motivează investigarea comportării inteligente
prin intermediul roboţilor mobili. Ne situăm aici la intersecţia ştiinţelor cognitive,
psihologiei şi inteligenţei artificiale. Din acest punct de vedere, roboţii mobili care
operează în mod autonom/semiautonom oferă o excelentă soluţie de testare a
ipotezelor referitoare la comportarea inteligentă, percepţie şi cunoaştere. O mare
parte a roboţilor utilizaţi astăzi în industrie sunt de tip manipulator (denumiţi şi roboţi
de asamblare), care operează într-un spațiu mărginit şi nu se pot mişca. Spre
deosebire de aceştia, roboţii mobili îşi pot schimba locaţia prin locomoţie.
În sensul larg al definiţiei, un robot mobil este un sistem de integrat timp-
real (embedded real-time system), echipat cu senzori pentru:
▪ percepţia mediului;
▪ elemente de execuţie;
▪ un sistem de conducere pentru maparea percepţiei în acţiune.
Percepţia, acţiunea şi aplicaţia între ele sunt cele trei aspecte majore care
definesc un robot mobil. În funcţie de modul de organizare a acestor trei aspecte
funcţionale, se poate considera că robotul mobil are un grad mai mare sau mai redus
de autonomie.
Cel mai cunoscut tip de robot mobil este vehiculul ghidat automat AGV -
Automated Guided Vehicle. AGV3 utilizate pe scară larga în industrie pentru
transportul materialelor, se pot deplasa prin mijloace proprii, traseul parcurs de
acestea fiind în mod tipic pre-programat. Deoarece astfel de vehicule mobile
operează în medii pre-programate, ele sunt inflexibile şi „fragile” în operare, orice
modificare neprevăzută a traseului (de exemplu, obiecte aflate pe calea de rulare)
putând conduce la o compromitere a întregii misiuni.
Alternativa o reprezintă construirea unor roboţi mobili cu autonomie în
mişcare. Autonomia se traduce prin următoarele caracteristici:
• abilitatea robotului mobil de a se deplasa în mediul înconjurător:
o pentru a îndeplini diferite taskuri;
• abilitatea de a se adapta modificărilor din mediu;
• de a învăţa din experienţă;
• de a-și modifica în mod corespunzător comportamentul;
3
http://www.egemin-automation.com/en/automation/material-handling-automation_ha-
solutions/agv-systems
• abilitatea de a-și construi reprezentări interne ale lumii înconjurătoare care

să poată fi utilizate pentru procese de luare de decizie (ex. navigaţia).
Aceste caracteristici permit utilizarea acestor structuri în aplicaţii specifice,
dintre care pot fi amintite operaţiuni de transport, explorare, supraveghere, orientare,
inspectare, evoluţie în medii inaccesibile sau ostile operatorului uman (de exemplu:
roboţi destinaţi combaterii acţiunilor teroriste, roboţii care operează în medii
contaminate, roboţii subacvatici, vehiculele de explorare planetară), etc.
Fig. 2.2 Google autonomous vehicle

http://www.comunic.ro/article/sistemele-de-inteligen%C5%A3%C4%83-
artificial%C4%83-ale-ma%C5%9Finilor-autonome-ale-google-pot-fi-considerate
IA este un domeniu complex bazat pe sisteme expert, algoritmi genetici,

sisteme fuzzy, sisteme hibride și neuronale. Întrucât sistemele de azi utilizează date
și informații care trebuie analizate în timp real, IA vine în întâmpinarea acestui
fenomen. Apariția mașinilor care învață, înțeleg și trag concluzii ne determină să
acceptăm faptul că IA este deja un lucru fără de care azi nu se mai poate evolua.
Deontologia inginerilor nu mai este suficientă azi. Domeniul este unul deja
transdisciplinar. Cunoașterea în domeniu este depozitată pe mașini inteligente care
pot funcționa în mod autonom, astfel încât accesul la informație trebuie să fie
efectuat pe baza unor proceduri foarte clare.
Componentele care permit sistemului inteligent să efectueze inferențe și să
elaboreze concluzii, soluții, decizii etc. necesită algoritmi care să permită IA să
rașioneze pe baza datelor deja adunate.
Pe lângă puterea de calcul, capacitatea de stocare, de căutare sistemele trebuie
să reproducă într-un anumit fel capacitățile omului: să văadă, să audă, să miroasă, să
vorbească, să înțeleagă, să valideze etc. Prin urmare domeniul IA migrează spre
sisteme robotizate. Acestea din urmă fiind cele mai vizibile din punct de vedere al
modului de operare. Spre exemplu sistemele expert din domeniul economic sunt
utilizate, în schimb ele nu sunt percepute ca niște elemente de IA, mai mult ca un
sistem de calcul și atât.
Atât timp cât roboții sunt cosntruiți să poată învăța, să lucreze în mod
autonom, înseamnă că principiile educaționale ale omului trebuie să sufere
transformări radicale. Dinamica acestor sisteme dotate cu IA vor suplini nevoile de

creație ale omului, fapt deja evident, a devenit un profesor virtual pentru multe
domenii economice, dar mai ales s-a reușit stabilirea unei legături între reprezentarea
acestor procese, prin intermediul calculatorului, robotilor sau a altor masini
inteligente și percepția umană asupra mediului real.
Domeniile științifice care stau la baza conceptului de IA sunt următoarele (Fig.
2.3):
1. Filosofia: logica, metode de raționament, mintea ca sistem fizic bazat pe
învățare, limbaj, rațiune;
2. Matematica: reprezentare formală și algoritmi de dezvoltare, calcule,
incertitudine, probabilități;
3. Economia: utilizare, arbori de decizie;
4. Neurologia: substrat fizic pentru activitatea mentală;
5. Psihologia: fenomenul de percepție, tehnici de experimentare;
6. Ingineria calculatoarelor: construcția de calculatoare hiper-rapide;
7. Teoria controlului: sisteme de maximizare a unei funcții obiectiv de timp;
8. Lingvistica: gramatică, reprezentarea cunoștințelor.
Fig. 2.3 Domenii de bază ale IA
IA se bazează pe un aparat matematic foarte bine dezvoltat. Utilizează noțiuni

precum:
• logica matematică:
o calculul propoziţional;
o calculul cu predicate;
o teoria inferenţelor logice;
• teoria probabilităţilor, reprezentarea cunoaşterii incerte spre exemplu cu

ajutorul reţelele Bayesiene prin explicitarea dependenţelor condiţionale între
diferite componente;
• teoria algorimilor de căutare, de control;
• reţele neuronale:
o recunoaşterea formelor;
o sinteza vorbirii;
• lingvistica matematică înţelegerea limbajului natural, traduceri;
• teoria grafurilor:
o reprezentarea tip arbore.
2.1.1 State of the Art
În [2.1] este prezentată evoluția principiilor de Inteligență Artificială, plecând

de la primul soft care a putut învinge într-o partidă de șah un maestru de șah (Fig.
2.4) – concurs orgnizat în anul 1989 între maestrul intenațional Arnold Denker și
robotul HITECH. Detalii au fost publicate de H.J. Berlner4.
Un alt exemplu de utilizare a IA în folos comunitar îl reprezintă programul de
vorbire PEGASUS, folosit în vederea punerii în vânzare a biletelor de tren. Clientul
vorbește la un microfon și solicită un bilet pentru o destinație:
𝑠𝑜𝑠𝑖𝑟𝑒 |𝑣𝑎𝑙𝑜𝑎𝑟𝑒:
{𝐴 → 𝐵|𝑜𝑟𝑎 . 𝑧𝑖. 𝑙𝑢𝑛𝑎. 𝑎𝑛𝑝𝑙𝑒𝑐𝑎𝑟𝑒 𝑚𝑖𝑛 ⋯ 𝑚𝑎𝑥}.
Robotul funcționează astfel:

• analiza vorbirii;
• răspuns pentru înțelegere;
• căutare baze de date;
• oferta propusă.
Algoritmul aparent este simplu, dar este posibil să ofere un preț foarte mare,
sau un preț mic și un timp foarte lung. Software-ul de analiză a vocii introduce un
set de erori, astfel încât este posibil să se interpreteze greșit informația primită de la
om. Elaborarea, dezvoltarea și analiza secvențială (pe segmente) a problemelor de
Identificare Automată Lingvistică (ALI - Automatic Language Identification) se
bazează pe analiză fonetică, acustică, informații prosodice asamblate cu un model
matematic pe baze probabilistice unificat. Apoi pe baze empirice se stabilesc
contribuțiile relative ale diferitelor surse de informații concomitent cu stabilirea și
asigurarea mecanismului de combinare a acestora.
Există o altă situație, cum ar fi, centrul de comandă a zborului pentru avioane
de linie. Apariția unui semnal de atenționare (culoare roșie ex.) sugerând ideea unei
defecțiuni. Faptul că analistul programator este atent, el va putea interveni preluând
comanda automată și trecând pe modul manual.
4
http://www.aaai.org/ojs/index.php/aimagazine/article/view/739/657
Fig. 2.4 Arnold Denker în competiție cu robotul HITECH

https://chessprogramming.wikispaces.com/HiTech.
Astăzi se utilizează sistemul expert în timp real MARVEL (Multimission

Automation for Real-time Verification of spacecraft Engineering Link), care este
capabil să monitorizeze un flux masiv de date.
Vehiculele autonome cu personal uman la bord, reprezintă o altă formă de
aplicație a IA. În acest caz viteza de transfer a datelor trebuie să fie foarte mare, iar
capacitatea de calcul de asemenea foarte mare, întrucâ sistemele de senzori trebuie
să acumuleze cât mai multe date din mediul exterior și să poată interpreta imaginile:
stopuri, intersecții, linie continuă, pietoni, mașinile din trafic, prognozarea diferitlor
posibile traiectorii ale celorlalte mașini etc.
Roboții echipați cu vedere artificială5, utilizează așa zisele sisteme „servoing
visual”. Acestea folosesc aplicații de proiectare în timp real pentru a putea controla
traiectoriile mișcării roboților cu funcții de manipulare. Imaginile recepționate sunt
definite ca proprietăți ale obiectelor care compun o imagine și se pot achiziționa cu
ajutorul unor senzori de vedere EO/IR, senzori montați fie pe brațul robotizat fie pe
mecanismul efector al brațului (Fig. 2.5). Din această configurație se nasc două
arhitecturi fundamentale ale tehnicii „servoing visual”:
• arhitectură bazată pe poziţie – bazată pe calculul erorilor reprezentate în
sistemul cartezian și care necesită obligatoriu un model virtual al obiectului;
5
http://www.ace.tuiasi.ro/users/103/2011-Copot%20Cosmin.pdf
• arhitectură bazată pe imagine – bazată pe utilizarea unei camere perfect

calibrate pentru a obține poziția și orientarea obiectului.
Tehnica „servoing visual” este de fapt o soluție hibridă, flexibilă și robustă
pentru a crește acuratețea și versatilitatea unei arhitecturi de control, bazată pe
feedback visual [2.2].
Fig. 2.5 Controlerul robotului: un PLC master și două PLC slave

http://www.vision-systems.com/articles/print/volume-20/issue-8/features/robot-vision-
automates-connector-assembly.html.
Controlul mișcării brațului unui robot manipulator, dintr-o poziție inițială într-
una finală, prin intermediul unui sistem „servoing visual” se face având ca informații
datele provenite de la senzori vizuali. Mișcarea, din punct de vedere matematic,
implică definirea unui spațiu de configurare al task-urilor (stărilor) [2.3]:
{𝑒|𝑒 ∈ ℝ3 |ℝ3 − 𝑠𝑝𝑎𝑡𝑖𝑢 𝑐𝑎𝑟𝑡𝑒𝑧𝑖𝑎𝑛 3𝐷}.
Adaptarea mișcării brațului la un sistem de referință se efectuează prin
transformarea cordonatelor (vectoriale de cele mai multe ori) de la un sistem de
referință la altul.
Ulterior, achiziționării de imagini, începe procedura de extragere a

caracteristicilor vizuale. Senzorii de achiziție date sunt de mai multe tipuri:
convenționale, cu ultrasunte și omnidirecționale (Fig. 2.6).
Fig. 2.6 Schema funcțională a unei camere omnidirecționale

1. Camera; 2. Oglinda superioară; 3. Oglinda inferioară; 4. Pata neagră;
5. Câmpul visual.
Descompunerea imaginilor în vectori specifici unor trăsături, reprezintă cheia

de boltă a introducerii IA în prelucrarea imaginilor. Întrucât noțiunea de IA a fost
împinsă către roboții autonomi, înseamnă că trebuie realizată o corelație între
preluarea imaginilor, mișcările senzorului, mișcările robotului și trăsăturile care se
doresc a fi sintetizate. Trăsăturile pot fi 2D sau 3D și în funcție de senzor se apelează
la instrumente matematice diferite. Cea mai convenabilă soluție o reprezintă soluția
hibridă 2D/3D. Se extrag trăsăturile 2D pentru care se definesc: coordonatele față de
sistemul de referință a căror reprezentare geometrică poate fi sub forma unor linii,
elipse contururi. De asemenea pentru o acuratețe mai mare a prelucrării se introduce
și noțiunea de trăsătură de moment. Astfel se introduce și a patra dimensiune –
timpul. Proiectarea unui sistem servoing pe baza celor descrise mai înainte, permite
minimizatrea neliniarităților introduse de matricea de interacțiune.
Trăsătura geometrică a unui punct de interes se poate asimila unui punct dintr-
o imagine, care este bine definit geometric, astfel încât, el poate fi integrat sau izolat
față de linia, curba, elipsa etc. din care a fost preluat. Pe de altă parte dacă imaginea
prelevată reprezintă doar un mic colț din ansamblu, acest colț se va defini ca o
intersecție a două muchii. Instrumentele de detectare (aparatul matematic) nu este
foarte robust, de aceea analiza implică suprapunerea de date care diferă prin:
luminozitate, translație, rotație sau altele. Două dintre cele mai uzuale sisteme de
detectare a trăsăturilor sunt: operatorul Harris și detectorul SIFT.
2.1.2 Operatorul Harris
IA urmărește ca elementele de achiziție date, de prelucrare și de interpretare a

acestora să permită unui sistem (fie el robotizat) să poată prelua o parte din funcțiile
omului și de a le transpune în elemente ce pot facilita unui operator uman decelarea
informațiilor despre un fenomen (Fig. 2.7).
Fig. 2.7 Schema funcțională a unui system servoing

http://www.ace.tuiasi.ro/users/103/2009-Burlacu_Adrian_PhD.pdf , fig. 2.1, pg. 20.
Operatorul Harris se bazează pe utilizarea funcţiei de auto-corelaţie. Acest

algoritm a fost propus pentru prima dată de Moravec6, îmbunătăţit de către Harris şi
Stephens (1988).
Algoritmul Harris (Fig. 2.8) de detecție a punctelor de interes este format din
două etape:
• prima constă în calcularea valorilor funcţiilor de autocorelaţie pentru fiecare
pixel din imagine;
• a doua constă în determinarea valoarilor de maxim local a acestei funcţii
intr-o vecinătate definită de utilizator.
6
https://en.wikipedia.org/wiki/Moravec's_paradox
Identificarea unor puncte de interes (pixelii asociaţi valorilor de maxim local)

cu anumite proprietăţi bine definite:
• număr redus în comparaţie cu trăsăturile tip muchie;
• invarianţă la:
o rotaţie şi a unor mici fluctuaţii de iluminare;
o modificări liniare ale factorului de scalare;
o transformări afine.
Fig. 2.8 Principiul funcției de autocorelație

http://opticalengineering.spiedigitallibrary.org/article.aspx?articleid=2595182.
Principiul de detecţie se bazează pe analiza proprietăţilor funcţiei de

autocorelaţie locală pentru o poziţie generică (𝑥, 𝑦) și a unei funcții imagine 𝐼(𝑥, 𝑦),
a cărei matrici de auto-corelație se determină astfel:
𝐼𝑥2 𝐼𝑥 𝐼𝑦 〈𝐼𝑥2 〉 〈𝐼𝑥 𝐼𝑦 〉

𝐴 = ∑𝑥 ∑𝑦 𝑔(𝑥, 𝑦) [ ] = [ ],
𝐼𝑥 𝐼𝑦 𝐼𝑦2 〈𝐼𝑥 𝐼𝑦 〉 〈𝐼𝑦2 〉
−(𝑥2 +𝑦2 )
unde: 𝑔(𝑥, 𝑦) = 𝑒 𝜎2 – reprezintă nucleul Gaussian; 𝐼𝑥 , 𝐼𝑦 – reprezintă gradienții
funcției imagine pe direcțiile (〈𝑥〉, 〈𝑦〉):
𝜕𝐼
𝐼𝑥 = 𝜕𝑥 = 𝐼 ∙ (−1,0,1)
{ 𝜕𝐼 .
𝐼𝑦 = 𝜕𝑦 = 𝐼 ∙ (−1,0,1)𝑇
Prin urmare detecția punctelor de interes se va efectua cu ajutorul relației
următoare:
𝐶(𝐴) = det(𝐴) − 𝛿 ∙ trace2 (𝐴) ,

unde: det(𝐴) = 𝛼 ∙ 𝛽 – determinantul matricei A; {𝛿 ∈ ℝ} - parametru de acordare;

trace(𝐴) = 𝛼 + 𝛽 – urma matricei A.
În Fig. 2.8 se disting trei cazuri:
• regiunea omogenă – valori proprii mici;
• regiunea marginilor - valorile proprii una mare iar cealaltă mică;
• regiunea colțurilor - dacă ambele valori proprii sunt mari.
Valoarea „de colț” pentru fiecare pixel în parte se calculează cu relația:
trace(𝐴) 〈𝐼2 〉+〈𝐼2 〉

𝑐𝑣 = = 〈𝐼2 〉∙〈𝐼𝑥2 〉−〈𝐼𝑦 2 ,
det(𝐴) 𝑥 𝑦 𝑥 𝐼𝑦 〉
unde: 〈𝐼𝑥 〉, 〈𝐼𝑦 〉 – sunt gradienții funcției imagine pe direcțiile (〈𝑥〉, 〈𝑦〉), gradienți
supuși unui filtru cu nucleu Gaussian:
1 𝑟2 𝐹 1 𝜔2 ∙𝜎 2
𝑔2𝐷 (𝑟, 𝜎) = 2∙π∙𝜎2 exp (− 2∙𝜎2 ) ↔ 𝐺2𝐷 (𝑓, 𝜎) = 2∙π∙𝜎2 exp (− 2
) .
Fig. 2.9 Aplicarea filtrului cu nucleu Gaussian pentru |𝜎 = 5|.
Se poate constata la o primă evaluare, că o valoare mare a punctului de interes

corespunde unor valori mari ale valorilor proprii. Un colț este detectat dacă matricea
A este de rang 2 și ar valori semnificative (Fig. 2.9).
2.1.3 Detectorul SIFT
Trăsăturile punctiforme extrase cu algoritmul Harris își păstrează proprietățile

doar în cazul secvențelor de imagini cu același factor de scalare7. Secvențele de
imagini au în general un factor de scalare variabil astfel, punctele de interes detectate
trebuie să includă proprietăți de invariață la scalare.
Fig. 2.10 Aplicarea unui filtru liniar și Gaussian

https://www.researchgate.net/figure/5392508_fig3_Figure-3-Linear-filtering-and-Gaussian-
filter-a-Kernel-of-a-2D-linear-filter.
Algoritmul SIFT (Scale Invariant Features Transform) propus de Lowe

(Lowe, 1999; 2003), se compune din patru etape:
1. detectarea extremelor în spaţiul scalării;
2. localizarea trăsăturilor;
3. determinarea magnitudinii și a orientării pentru fiecare trăsătură;
4. crearea descriptorului.
7
distanța dintre planul de mișcare a obiectelor și cameră este constant
În (Fig. 2.10) avem reprezentarea unor filtrări liniare și Gaussiene:

a) filtru liniar 2D - intensitatea unui pixel (marcat cu roșu) în imaginea de
ieșire este determinată de intensitățile acesteia și a pixelilor învecinați
(marcați cu roșu) în imaginea de intrare. Matricea din partea stângă
prezintă ponderile pentru pixeli. Intensitatea de ieșire a pixelilor țintă este
suma intensităților ponderate ale pixelilor acoperite de către nucleu;
b) filtru gaussian - filtrarea Gauss pentru înlăturarea neclarității presupune
o nouă focalizare a imaginii, netezirea față de distribuția Gauss și o
reducere a zgomotului, astfel încât se poate obține o anume claritate, dar
detaliile fine sunt eliminate.
De aceea s-a propus o altă metodă de filtare SIFT, care după cum se observă
în paragrefele anterioare, urmează următorul algoritm: primele două etape detectează
expremele din spațiul scalărilor și localizează cu acuratețe trăsăturile, iar următoarele
două etape asignează orientarea și descrierea trăsăturilor.
Identificarea unor poziţii în spaţiul scalărilor ce reprezintă puncte de extrem
ale unei anumite funcţii se bazează pe găsirea trăsăturilor stabile în toate nivelurile
de scalare. Spațiul scalărilor se construieşte folosind o succesiune de filtrări cu un
anumit nucleu [2.4]. S-a demonstrat că singurul nucleu care se poate folosi pentru
generarea unui spațiu tridimensional al scalărilor este nucleul Gaussian [2.5]:
𝑥2 +𝑦2
1 −
𝐺(𝑥, 𝑦, 𝜎) = ∙𝑒 2∙𝜎2 ,
2∙π∙𝜎 2
unde: 𝑔𝜎 2 – reprezintă dispersia nucleului Gaussian.

Astfel, spațiul scalărilor 𝐿(𝑥, 𝑦, 𝜎), este definit ca un produs dintre funcția
imagine 𝐼(𝑥, 𝑦) și nucleul Gaussian 𝐺(𝑥, 𝑦, 𝜎):
𝐿(𝑥, 𝑦, 𝜎) = 𝐺(𝑥, 𝑦, 𝜎) ∙ 𝐼(𝑥, 𝑦) .
Prin urmare, funcția spațiului scalărilor va genera o succesiune de filtrări ale

imaginii dependente de parametrul 𝜎 considerat a fi o funcție 𝜎: [𝑜𝑚𝑖𝑛 , 𝑜𝑚𝑎𝑥 ] ×
[0, 𝑆 − 1] → ℝ, definită:
𝑜+𝑠
𝜎(𝑜, 𝑠) = 𝜎0 ∙ 2 𝑆 ,
unde: {𝑜} – una dintre octavele axei din spațiul scalărilor; {𝑆} – numărul de niveluri
ale fiecărei octave; {𝑠} – indexul nivelului din octava {𝑜} care se poate defini ca
spațiul al scalărilor.
Spațiul scalărilor pentru o imagine 𝐼(𝑥, 𝑦) se obține în urma unor filtrări
succesive și a unor modficări de asemenea succesive ale dimensiunilor imaginii:
i. se consideră imaginea 𝐿(𝑥, 𝑦, 𝜎(𝑜, 𝑠));
ii. se calculează 𝜎(𝑜, 𝑠 + 1);
iii. se determină imaginea 𝐿(𝑥, 𝑦, 𝜎(𝑜, 𝑠 + 1));
iv. atunci când {𝑠 + 1 = 𝑆}, imaginea în noua octavă se redimensionează.
În momentul în care {𝑜 = 𝑜𝑚𝑎𝑥 } spațiul scalărilor este complet. În continuare

se urmărește constuirea spațiului diferențelor de filtrări Gaussiene DoG:
𝐷(𝑥, 𝑦, 𝜎) = [𝐺(𝑥, 𝑦, 𝑘𝜎) − 𝐺(𝑥, 𝑦, 𝜎)] ∙ 𝐼(𝑥, 𝑦) = 𝐿(𝑥, 𝑦, 𝑘𝜎) − 𝐿(𝑥, 𝑦, 𝜎) .
Din punct de vedere matematic DoG este obținut prin derivarea spațiului
scalarilor. În acest spațiu DoG se vor identifica poziții {𝑃(𝑥𝑝 , 𝑦𝑝 , 𝜎𝑝 )}.
Fig. 2.11 (a) Reprezentarea scalei pentru 3 niveluri ale unei octave; (b) Fereastra de 3x3x3
din jurul punctului P. Pg. 15, fig. 2.2 [2.3].
Totalitatea punctelor de extrem formează mulțimea extremelor locale ale

funcției 𝐷(𝑃):
Λ = {𝑃(𝑥, 𝑦, 𝜎)}|∀𝑃′ ∈ 𝑉3𝑥3𝑥3 (𝑥, 𝑦, 𝜎), |𝐷(𝑃)| > |𝐷(𝑃′ )| .
Dezvoltarea Taylor până la elementul pătratic permite determinarea prin SIFT

a offset-ului funcției 𝐷(𝑥, 𝑦, 𝜎):
𝜕𝐷 𝑇 1 𝜕2 𝐷
𝐷(𝑃) = 𝐷 + 𝜕𝑃
∙ 𝑃 + 2 ∙ 𝑃𝑇 ∙ 𝜕𝑃2 ∙ 𝑃 ,
unde: 𝑃 = (𝑥, 𝑦, 𝜎)𝑇 , iar determinarea extremelor funcției 𝐷(𝑃) se obține prin
egalarea cu zero a derivatei acestei funcții:
𝜕 2 𝐷 −1 𝜕𝐷
𝑃̂ = − ∙ ,
𝜕𝑃2 𝜕𝑃
de unde rezultă:
1 𝜕𝐷 𝑇
𝐷(𝑃̂) = 𝐷 + ∙ ∙ 𝑃̂ .
2 𝜕𝑃
Pentru implementarea algoritmului de eliminare a muchiilor se aplică matricea

Hessian:
𝐷𝑥𝑥 𝐷𝑥𝑦
𝐻 =[ ].
𝐷𝑥𝑦 𝐷𝑦𝑦
Odată ce au fost detectate extremele în spațiul scalărilor și sau localizat

trăsăturile pentru determinarea punctelor de interes, cu ajutorul descriptorului SIFT
se vor determina orientarea și magnitudinea gradientului, pe baza proprietăților
locale ale funcției imagine.
2 2
𝑀(𝑥, 𝑦) = √(𝐿𝑥+1,𝑦 − 𝐿𝑥−1,𝑦 ) + (𝐿𝑥,𝑦+1 − 𝐿𝑥,𝑦−1 )
{ .
𝐿 −𝐿
𝜃(𝑥, 𝑦) = tan−1 ( 𝑥,𝑦+1 𝑥,𝑦−1 )
𝐿𝑥+1,𝑦 −𝐿𝑥−1,𝑦
Fig. 2.12 (a) Histograma orientărilor;

(b) Orientările fundamentale. Pg. 18, fig. 2.3 [2.3].
Fig. 2.13 (a) Trăsăturile obiectului detectat cu SIFT; (b) Orientarea și magnitudinea; (c)
Descriptorul trăsăturii pg. 18, fig. 2.4 [2.3].
Fig. 2.14 Sistem visual servoing pentru controlul roboților.
Putem aprecia că histograma orientărilor este formată din valorile gradientului

orientărilor punctelor de interes (Fig. 2.12, Fig. 2.13, Fig. 2.14).
2.2 Inteligența artificială distribuită
Definiția largă a IA consideră că pentru a putea dezvolta sisteme

complementare inteligenței umane este necesară crearea de sisteme S/W
(Software/Hardware) autonome, sisteme asimilate agenților inteligenți. Altfel spus
IA presupune interconectarea agenților inteligenți ca părți ale unui sistem. Se poate
afirma, în baza celor spuse, că IA este proprietatea agenților inteligenți de a se
interconecta.
Inteligenţa artificială distribuită se ocupă de studierea, dezvoltarea şi utilizarea
de sisteme S/W în care mai mulţi agenţi inteligenţi urmăresc o mulţime de scopuri şi
execută o mulţime de sarcini pentru a atinge respectivele scopuri.
Astăzi paradigmele, cum ar fi de descompunere a problemele în subprobleme
și apoi de repartizare pe module de intereracțiune, sau care utilizau metoda
BlackBoard, au fost înlocuite de următoarele sisteme:
• sisteme multiagent în care mai mulţi agenţi îşi coordonează cunoştinţele şi
activităţile, raţionând asupra procesului de soluţionare a unei probleme;
• sisteme distribuite pentru rezolvarea de probleme, în care o problemă
particulară este soluţionată prin împărţirea ei în mai multe sarcini mai multor
noduri similare, care îşi divid şi partajează cunoaşterea despre problemă.
O altă preocupare a Inteligenţei Artificiale Distribuite constă în proiectarea de
arhitecturi paralele dedicate, care permit creşterea performanţei sistemelor
inteligente distribuite, în care fiecare agent este privit ca un nod fizic dintr-o reţea de
calculatoare.
Dezvoltarea infrastructurii informaţionale, permite sistemelor informatice să fie
distribuite, mari, deschise, eterogene şi complexe.
IA distribuită se poate asimila (Fig. 2.15), în funcție de mediul de lucru, cu o
inteligenţă colectivă:
• agenți inteligenți nu pot interacţiona cu mediul lor şi cu alte programe
inteligente;
• problemele reale sunt extrem de complexe;

• complexitatea programelor este simplificată prin module cuplate;
• programarea orientată pe obiecte.
Fig. 2.15 Diagrama schematică a clasificării IA

https://www.researchgate.net/publication/232914399_Artificial_intelligence_for_energy_c
onservation_in_buildings.
Generarea de sisteme de agenți software, roboți, senzori, sisteme de

calculatoare, care lucrează împreună cu aceeași eficiență și expertiză este foarte utilă
în vederea rezolvării multiplelor provocări ale omului:
• căutare și salvare;
• activități militare;
• tehnologia jocurilor;
• securitatea calculatoarelor;
• securitatea comunicațiilor;
• transport;
• logistică;
• etc.
Sistemele formate din entități multiple, uneori redundante, oferă posibilități
de creștere a robusteței și fiabilității soluțiilor, datorită abilității pe care o singură
entitate poate să o preia de la o altă entitate lipsă. Putem spune că se creează entități
monolitice capabile să rezolve probleme cu costrui reduse și de reducere a
complexității entităților individuale. Inteligența distribuită [2.6] are și unele
dezavantaje (Fig. 2.16), cum ar fi, în acest moment:
• lipsa unui control centralizat sau al unui depozit centralizat de informații la
nivel mondial;
• necesită mai multă comunicare pentru a coordona toate entitățile din

sistem;
• creșterea numărului de entități poate duce la creșterea interferenței între
entități, deoarece acestea trebuie să acționeze fără o cunoaștere completă a
intențiilor celorlalte entități;
• sistemele de mai multe entități experimentează o incertitudine crescută cu
privire la starea sistemului în ansamblul său.
Fig. 2.16 Diagrama schematică a clasificării IA distribuite.

http://www.slideshare.net/JeromeGlenn/wfs-pdf-july-2015.
Provocarea este de a proiecta un sistem, astfel încât, să se obțină o coerență

globală prin interacțiunile locale ale entităților individuale.
Fig. 2.17 Tipuri de interacțiuni în sistemele de inteligență

distribuite [2.6] fig 2. pag. 7.
Paradigmele inteligenței artificiale distribuite diferă de la un tip de interacțiuni

la altele, acționând conform reprezentării din Fig. 2.17, dacă entitățile au gradul de
conștientizare a altora cu privire la ansmablu și dacă acțiunile unei entități au un

avans față de obiectivele altor entități. Tipurile de obiective sunt:
• fiecare entitate are scopuri individuale;
• entitățile au obiective comune.
Conștientizarea axei altor entități se realizează prin împărțirea sistemelor în
entități conștiente și care nu sunt conștiente. Conștiența se referă la fapul că motivul
de acțiune și intențiile entităților diferă. Roboți care nu au conștiența mediului pot
sesiza prezența entităților locale și astfel pot acționa fără să înțeleagă intenția sau
planurile de viitor ale sistemului. Această metodă de funcționare se numește
„stigmergy”8 (mecanism de coordonare indirectă, prin intermediul mediului, între
agenți sau acțiuni - este o forma de auto-organizare, produce structuri complexe,
aparent inteligente, fără să fie nevoie de planificare, de control sau de comunicare
chiar directă între agenți, sprijină colaborarea eficientă între agenți, care nu dispun
de memorie, inteligență sau chiar conștiență individuală).
Segmentările spațiului de domeniu sunt aproximative, dar utile în înțelegerea
tipurilor primare de interacțiuni care pot apărea în aplicațiile tipice. Diferite zone ale
acestui subspațiu reprezintă tipuri comune de interacțiuni observate în sistemele de
inteligență distribuite:
a) colectiv;
b) cooperativa;
c) colaborativ;
d) coordonator.
Paradigmele pentru inteligența artificială diferă prin modul de abstractizare a
spațiului, astfel încât vizualizarea sistemului să poată genera strategii de proiectare-
dezvoltare adecvate. Paradigmele diferă și din punct de vedere al semanticii, putând
spune că nu toate pot fi aplicate în orice domeniu. Spre exemplu cele specifice
interacțiunilor dinamice nu pot fi aplicate în domeniul lingvistic, etc.
Cele mai comune paradigme pentru inteligență distribuită sunt:
• bioinspired - sisteme emergente, algoritmi genetici etc.;
• organizaționale și sociale;
• bazate pe cunoaștere - ontologice, semantice.
Ca exemplu se prezintă cooperarea unor roboți mobili [2.7]. În Fig. 2.18
grupul de UTVs se află în proximitatea unui obiectiv în vederea obținerii de
informații și date privind: dimensiunile, localizarea terestră etc. UTVs comunică
între ele printr-un LAN, fiecărui robot fiind-ui atribuit un interval de timp pentru a
transmite date.
Dacă un vehicul devine inoperant, sistemul LAN relochează către unul dintre
roboții aflați în funcțiune, ativitățile robotului devenit inoperant. UTVs operaționale
continuă comunicarea și sarcinile de generare a traiectoriilor și de control [2.8].
Diferitele tipuri de comportament coordonat includ dispersie, lucrare în rețea de
8
https://en.wikipedia.org/wiki/Stigmergy
calculatoare (clustering), orbitare în jurul unui punct de referință, până la o nouă

reorientare și așa mai departe.
Fig. 2.18 Robotic All Terrain Lunar Exploration Rovers fig. 1, pag 17.
https://www.osti.gov/scitech/servlets/purl/10196260/.
Cooperare între UTVs (Fig. 2.18), există și sub o formă de organizare tip
progresie liniară. Acest model de cooperare se utilizează pentru acțiuni complee de
identificare terestră, care includ: dispersia, orbita/traiectoria, clustere cu reguli
predefinite. Cele de mai înainte permit informațiilor adunate de fiecare robot să fie
distribuite și celorlalți roboți.
Fig. 2.19 Exemplu de căutare a unui grup de Robotic All Terrain Lunar
Exploration Rovers fig. 2, pag 17
Configurările, spațiale, trebuie modelate numeric, astfel încât, (Fig. 2.19)

algoritmul IA cu care este înzestrat controlerul să poată efectua simulări
continue. Necesitatea acestui algoritm este data de faptul că roboții trebuie să se
distribuie în arealul de interes, până la acoperirea acestuia – conform

posibilităților date de senzorii cu care sunt echipate UTVs-urile. Comunicația RF
cu fiecare robot (considerat slave) cât și cu cel (considerat master). Aceasta nu
este tot, oricare dintre UTVs poate deveni master, dacă cel anterior suferă vreo
defecțiune.
Fig. 2.20 Modelarea numerică a dispersiei unui grup de Robotic All Terrain Lunar
Exploration Rovers fig. 3, pag 18
Importanța modelării și simulări este data de considerentele ce decurg din

realizarea fizică a unui cluster, deoarece cu cât numărul elementelor (roboți) din
cadrul sistemului este mai mare cu atât numărul de erori crește. Pe de altă parte există
dificultăți tehnice multiple, cheltuielimari privind testarea dinamicii cât și a celei
H&W care ar face utilizarea acestor sisteme prohibită.
Simularea (Fig. 2.20) poate arăta cum anume pot fi implementate strategiile
de control și de comunicare, precum și posibilele probleme de stabilitate și
convergență. Fiecare robot este echipat cu un controler care are o strategie proprie și
care îl include pe respectivul robot într-o ierarhie comportamentală de grup, după
cum urmează:
• menținerea canalului de comunicație RF;
• triangularea locației cu două sisteme de localizare:
o GPS;
o senzor de accelerație pe trei direcții;
• detecție pentru evitarea obstacolelor;
• respectarea traiectoriei prestabilite
• etc.
În plus, ansamblul de vehicule are ca strategie de control, preprogramată,

comunicarea printr-un master. Simularea oferă de asemenea rezultate grafice ale
mișcărilor grupului , precum și date care pot fi analizate.
2.3 Agenți inteligenți
Agenţii inteligenți reprezintă entităţi computerizate care acţionează în locul

operatorilor umani, care adună și stochează informații, care trimit sau filtrează
mesaje de e-mail. Utilizează noțiunea de cuvânt „cheie” care în viitorul foarte
apropriat va deveni foarte utilă, ajutând la identificarea informațiilor, articolelor,
imaginilor sau a unor pachete de date ce pot conține elemente de similitudine.
Agentul inteligent9 reprezintă acel ceva care acționează într-un mediu. Un
agent poate, de exemplu, să fie o persoană, un robot, un câine, un vierme, vântul,
gravitația, o lampă sau un program de calculator ce cumpără și vinde. Uneori, agenții
acționează numai într-un spațiu de informații și ei sunt numiți tot roboți.
Agenții interacționează cu mediul și aceștia de regulă au o structură fizică
(Fig. 2.21). Un robot este un agent care are de îndeplinit o misiune. Agenții primesc
informații prin intermediul senzorilor lor. acțiunile agentului depind de informațiile
pe care le primește de la senzorii săi. Acești senzori pot, sau nu pot, reflecta
realitatea. Senzorii pot produce zgomote, pot fi deteriorați, au anumite limitări fizico-
chimice-mecanice, astfel încât utilizarea lor la modul general nu este recomandată.
Fig. 2.21 Interacțiunea între un agent și mediul real.
Un agent trebuie să acționeze pe informațiile pe care le are la dispoziție.

Adesea, aceste informații sunt foarte slabe, respectiv mărimea fizică, care este de
regulă un semnal electric, nu conține destulă informație pentru ca senzorul și
elementele de traducere să descrie fenomenul fizic urmărit. Agenții acționează prin
intermediul dispozitivelor de acționare – efectori sau actuatori.
9
http://artint.info/html/ArtInt.html
Un agent de control este mesajul/comanda pe care agentul o trimite elementelor

de acționare. Agenții de multe ori efectuează acțiuni pentru a aduna mai multe informații.
Agenții inteligenți sunt înzestrați cu „rațiune” pentru a putea fi utilizați să
efectueze lucruri utile. Determinarea elementelor de relaționare este dată de ceea ce
considerăm a fi o „acțiune corectă”. Implementarea rațiunii conferă agentului un anumit
grad de decizie. Fiecare agent are o măsură privind criteriile de performanță. De aceea
măsurarea performanței se va stabili conform unor proceduri ale unor autorități.
Standardele sunt definite în funcție de o multitudine de aspecte: mediu natural,
mediu social, intervenții de urmărir, de decizie, economic etc. Toate fiind
cuantificate în unități de timp, ținând cont de efectul urmărit și cauzele care pot
conduce la diferite strategii.
O altă problemă pe care agenții inteligenți trebuie să o rezolve, o reprezintă
distincția dintre „raționalitate” și „omnisciență10”. Efectuarea unei acțiuni este
rațională, dar lipsa unor elemente de decriptare a elementelor mediului de lucru,
conduce la ideea că agentul respectiv nu poate „să știe tot”.
Definirea noțiunii de „corect” pentru algoritmul de funcționare al unui agent
este similară cu noțiunile de abstractizare ce se regăsesc în: „jocul cu bile de sticlă11”,
„GO12” sau „Labirint13” și depinde de patru elemente:
i. gradul de succes – măsura performanței;
ii. percepția completă de la începutul unei acțiuni, până la momentul finalizării
acțiunii;
iii. ce știe despre mediul înconjurător;
iv. ce acțiuni poate efectua.
Agentul rațional ideal trebuie să efectueze fiecare acțiune prin maximizarea
performanțelor sale, pe baza datelor furnizate de sistemul de percepție (Fig. 2.22).
Aparent el respectă „rațiunea” cu care este înzestrat, dar el nu știe să se
orienteze dual (stânga/dreapta, sus/jos). Raționând, prima etapă este de evaluarea
riscurilor - este de fapt un alt element de construcție al unui agent inteligent. Apoi
trebuie să „caute” pe baza algoritmului de maximizare a performanței. Toate se
subordonează „analizei” care are implementat un contor de timp.
În [2.9] se prezintă formatul ideal al unui agent inteligent:
1. biologic – asumarea elementelor din mediu;
2. comunicare;
3. arhitectură, planificarea task-urilor și control;
4. localizare, mapare14 și explorare;
5. transport și manipulare obiecte;
6. coordonarea mișcării;
10
https://dexonline.ro/intrare/omniscien%C8%9B%C4%83/39032 - calitatea de a ști tot
11
https://merlinstore.ro/jucarii/257-joc-cu-bile-de-sticla-standard-solitaire.html
12
http://www.netinform.ro/blog/2016/03/10/inteligenta-artificiala-il-invinge-pe-campionul-
jocului-go/
13
http://www.scritub.com/sociologie/psihologie/Strategii-de-rezolvare-a-
probl2332213815.php
14
https://dexonline.ro/intrare/mapare/216699 - cartografiere
7. roboți reconfigurabili;
8. învățare – deep learning, machine learning;
9. probleme distribuite adiționale pentru sisteme de roboți mobili autonomi.
Fig. 2.22 Maparea ideală și rezolvarea ei

prin aplicarea metodei celor mai mici pătrate.
Inițiatorul mediului de testare al mediului Inteligenței Artificiale, Alan

Turing15, a considerat că agenții reali și artificiali sunt identici, chiar dacă în lucrare
consideră că agenții artificiali trebuie să dețină un algoritm (H&S) care să îi permită
imitarea comportamentului uman.
Datele interne din structura unui agent inteligent (Fig. 2.23) se actualizează
pe măsură ce informațiile care provin din sistemul de percepție ajund să fie
interpretate de elementele cognitive ale agentului. Agenții primiesc informația în
mod secvențial, respectiv, informație după informație, astfel încât la intrare
există adusă doar o singură percepție. Care este secvența pe care o va primi
agentul ține de proiectant.
Fig. 2.23 Structura unui agent inteligent.
15
http://www.turing.org.uk/scrapbook/test.html
În continuare, măsurarea performanței din Fig. 2.23 se face aplicând din

exterior un mod de comparare al unui comportament.
Fig. 2.24 Tabel de căutare predifinit pentru un anumit agent.
Se scriu astfel datele într-un tabel de căutare (Fig. 2.24) , tabel care
funcționează prin menținerea, în memorie, a întregii secvențe de percepție cu ajutorul
unui indice, care conține acțiunea corespunzătoare pentru toate secvențele posibile
provenite din sistemul de precepție. Tabelul descrie de fapt valorile de risc:
1) numărul de intrări necesare pentru jocul de șah - 1043 ÷ 1047 – care pot fi
asociate unei competiții normale, iar dacă se ia în calcul complexitatea
jocului (game-tree complexity), din punct de vedere combinatoric, numărul
estimat este în jur de 10120 (Shannon number16);
2) timpul pentru construirea tablei de joc;
3) faptul că agentul nu are autonomie deloc, deoarece calculul celor mai bune
acțiuni este în întregime încorporat, în cazul în care mediul va suferi
schimbări, într-un mod neașteptat, agentul va fi pus în dificultate și nu va
putea învinge un competitor uman;
4) agentul dispune de un mecanism tip machine-learning, astfel încât, să aibă o
anumită autonomie, însă timpul de învățare al tuturor mișcărilor posibile ar
fi prohibit.
Pentru a putea rezolva problema de mai înainte s-a apelat la noțiunea de
„Structură de Control Ierarhică – Hierarchical Control17”. Agentul este împărțit în
senzori și un sistem de percepție complex, care trimite informațiile către un controler
din care vor pleca informațiile pentru sistemul de acționare. Această structură este
deficitară, întrucât este foarte lentă. De exemplu în cazul unui robot care trebuie să
16
https://en.wikipedia.org/wiki/Claude_Shannon
17
http://artint.info/html/ArtInt_37.html
parcurgă un labirint ar trebui să dureze un timp foarte mare. De asemenea capacitatea

de a descrie mediul înconjurător este limitată.
Arhitectura alternativă este o structură ierarhică de controlere (Fig. 2.25),
fiecare layer (strat) vede layerele de mai jos, ca pe un corp virtual care provine din
sistemul de percepție și care apoi trimite informațiile către sistemul de acționare.
Straturile de nivel inferior sunt capabile să ruleze mult mai rapid și oferă o vedere
mai simplă către straturile superioare, concomitent cu ascunderea informațiilor
neesențiale.
Fig. 2.25 Structura idealizată a unui agent cu control ierarhic.
Există trei tipuri de intrări pentru fiecare strat, la fiecare dată:

• caracteristicile stării de certitudine, denumite valori sau caracteristici
anterioare;
• caracteristicile reprezentând precepțiile din stratul ierarhic de mai jos;
• caracteristicile reprezentând comenzile din stratul ierarhic de mai sus.
Există trei tipuri de ieșiri din fiecare strat, la fiecare dată:
• precepțiile de nivel superior pentru stratul de mai sus;
• comenzile de nivel inferior pentru stratul de dedesubt;
• următoarele valori pentru caracteristicile stării de certitudine.
Pentru a pune în aplicare un controler, fiecare intrare de la un strat trebuie să
obțină valoarea sa de undeva. Fiecare comandă de intrare sau de precepție trebuie să
fie conectată la o ieșire a unui alt strat. Analiza informațiilor în layerele superioare
utilizează metode discrete și robuste, pe când în layerle inferioare analiza este de
continuu și robust. Controlerul care are implementate ambele sisteme de analiză
discret/robust și continuu/robust se numesc controlere hibride.
Raționamentele cantitaive folosește un aparat matematic ce utilizează analiza

numerică prin metode integro-diferențiale. Raționamentele calitative folosec în plus
logica. Raționamentul calitativ determină legile cantitative ce trebuie aplicate.
Valorile discrete pot lua forme de reprezentare diverse: obiective, comenzi cu
termeni fuzzy, motivații calitative.
Fig. 2.26 Descompunerea structurii idealizate a unui robot

în agenți supuși unui control ierarhic.
În cazul unui robot, care se deplasează, obiectivele, comenzile și motivațiile

sunt date de spațiul, viteza, accelerația și obstacolele ce pot apare în traseul robotului.
Bracarea roților poate fi gestionată ca fiind o acțiune instantanee, dar care trebuie
ajustată permanent în funcție de timp, destinație, hartă și traiectorie. Senzorii de
poziție oferă coordonatele (prin suprapunere GPS și cel triaxial), dacă este echipat
cu ambele sisteme de poziționare. Dacă nu, la întâlnirea unui obstacol va efectua un
viral la stânga și apoi la dreapta (spațiu/timp). Altfel spus harta este o secvență de
locații citite într-o anumită ordine prestabilită (Fig. 2.26).
În interiorul unui layer avem caracteristici ce sunt funcții ale altor
carcateristici (cinematică, dinamică, curent consumat, absorbit, sisteme
termodinamice, hidraulice etc.) și ale intrărilor provenite de la alte layere. Dacă
informațiile ajung într-un centru de prelucrare (Fig. 2.27) pentru a se lua o decizie
privind ocolirea unor obstacole, atunci elementele efectoare (motoarele electrice)
vor primi comenzile de modificare a turației astfel încât dinamica robotului să
fie modificată.
Fig. 2.27 Layerul de mijloc în cadrul structurii ierarhice.
Acest layer nu menține starea de certitudine internă, astfel încât, funcția de

tranziție să fie o mulțime nevidă. Funcția de comandă va specifica direcția robotului
în funcție de intrările sale. Faptul că robotul atinge punctul stabilit, atribuie o valoare
(care este dată de Funcția de antrenament) ținând cont de valoarea anterioară și de o
valoare prag predefinită:
arrived ←distance(previous_target_pos,robot_pos)<threshold
if whisker_sensor=on
then steer←left
else if straight_ahead(robot_pos,robot_dir,current_target_pos)
then steer←straight
else if left_of(robot_position,robot_dir,current_target_pos)
then steer←left
else steer←right
end if
if arrived and not empty(to_do)
then
target_pos' ←coordinates(head(to_do))
to_do'←tail(to_do)
end if
Fig. 2.28 Layerul de deasupra în cadrul structurii ierarhice.
Fig. 2.29 Simularea deplasării robotului.
Explicitarea elementelor din liniile de cod anterioare:

• arrived ← înseamnă atribuire, distanța este distanța euclidiană, iar pragul
este o distanță în unitățile corespunzătoare;
• straight_ahead (robot_pos, robot_dir, current_target_pos) este adevărat
atunci când robotul este la robot_pos;
• robot_dir reprezintă direcția când poziția este țintă actuală;
• current_target_pos este stabilită ca direcție în sensul longitudinal al
robotului (valoare prag);
• left_of este funcția de testare în cazul în care obiectivul este spre stânga
robotului.
Anexa 2.1. Ce este inteligența artificială
Inteligența Artificială18 poate avea o multitudine de clasificări. Una dintre

acestea se referă la modul în care se poziționează față de stimulii exteriori. Astfel,
vom prezenta în continuare un punct de vedere:
1. Mașini reactive
Este un model de bază, în care sistemele AI nu au:
▪ abilitatea de a memora lucruri;
▪ posibilitatea de a se folosi de experiențe anterioare pentru a rezolva
probleme actuale;
▪ capabilitatea de a lua decizii noi.
Spre exemplu supercomputerul Deep Blue19, care l-a la sfârșitul anilor ’90
reușește să îl învingă pentru prima oară pe maestrul internațional de șah Garry
Kasparov.
2. Memoria limitată
Reprezintă acele sisteme AI, care pot reține informații despre evenimente care
au fost deja înfăptuite. Sunt sisteme cu o memorie pe termen scurt. Dintre acestea
putem aminti vehiculele autonome. Aceste sisteme se utilizează în telematică putând
să urmărească alte vehicule aflate în trafic, având acces la informații despre
cinematica respectivelor vehicule. Acest lucru se poate face de-a lungul timpului, nu
doar la un anumit moment dat.
3. Teoria minții – ToM (Theory of Mind) [2.10]

În psihologie, teoria minții se referă la capacitatea oamenilor de a deduce
gândurile, intențiile și dorințele altor oameni și la abilitatea de a folosi aceste
informații pentru a interpreta și a înțelege comportamentul lor. În cazul AI, acest tip
de Inteligență Artificială face același lucru: nu vor crea doar modele ale lumii
înconjurătoare, ci și despre entitățile care o populează. În cazul nostru, oamenii.
4. Conștiința de sine
Se poate spune că este, în acest moment, ultimul criteriu de clasificare. Spre
deosebire de IA corespunzătoare Teoriei minții, ar trebui ca IA să permită sistemelor
inteligente/robotizate să își poată forma o imagine despre ele însele, nu doar despre
lumea înconjurătoare sau despre oameni: respectiv abilitatea sistemului IA de a se
autoidentifica față de mediul înconjurător și față de celelalte entități care fac parte
din ea.
18
https://gotech.world/inteligenta-artificiala-definitie-tipuri-de-ai-cum-invata-si-ce-
aplicatii-are/
19
https://interestingengineering.com/deep-blue-vs-kasparov-the-historic-contest-that-
sparked-the-ai-revolution
5. Cum învață un sistem inteligent

Sistemele inteligente în afară de programarea propriu-zisă sunt înzestrate cu
mecanisme care să le permită să învețe singure.
5.1. Învățarea mecanică - Machine Learning

Învățarea mecanică este o parte importantă a Inteligenței Artificiale. Este un
tip de cercetare prin care roboții/automatele/sistemele inteligente pot dobândi
abilități sau cunoștințe din experiență. Mașinile primesc o cantitate uriașă de date pe
care le analizează, din care învață și în baza cărora (re)acționează, fără să aibă nevoie
de programare specifică. Întrucât obiectivul domeniului învățării automate este
„învățarea”, există multe tipuri de învățare care pot descrie domenii întregi de studiu
cuprinse din mai multe tipuri diferite de algoritmi. Există poate 14 tipuri de
învățare20:
I. Probleme de învățare
1. Învățare supravegheată
2. Învățare nesupravegheată
3. Învățare de consolidare
II. Probleme de învățare hibridă
4. Învățare semi-supravegheată
5. Învățare autoconservată
6. Învățare în mai multe instanțe
III. Inferența statistică
7. Învățare inductivă
8. Inferența deductivă
9. Învățare transductivă
IV. Tehnici de învățare
10. Învățarea cu mai multe sarcini
11. Învățare activă
12. Învățare online
13. Transfer de învățare
14. Ansamblu de învățarea
5.1.1. Metode de învățare mecanică

Învățarea mecanică este un element-cheie al inteligenței artificiale și este, în
mod obișnuit, împărțită în două mari categorii:
5.1.1.1. Învățarea mecanică asistată

O metodă comună de „învățare” a unui sistem IA este antrenarea lui cu
ajutorul unei cantități uriașe de date etichetate în prealabil21. Aceste date sunt
introduse în sistem, iar IA se folosește de ele pentru a analiza date noi. De exemplu,
IA primește o cantitate uriașă de fotografii cu animale. Odată ce imaginile au fost
20
https://machinelearningmastery.com/types-of-learning-in-machine-learning/
21
https://robotex.international/competitions/starship-animal-rescue/
procesate, IA (Jetson22) poate să decidă dacă o fotografie nou încărcată în sistem

conține sau nu un anumit animal.
Această metodă de învățare mecanică are nevoie de cantități uriașe de
informații. În cazul fotografiilor, unele sisteme AI au în baza de date milioane de
imagini pe care le verifică pentru a învăța cum să ducă la îndeplinire un task. De
exemplu, Open Images Dataset de la Google conține în jur de 9 milioane de imagini
de referință, toate catalogate.
5.1.1.2. Învățarea mecanică parțial asistată

Tehnologia fiind în continuă evoluție și accesul la baze uriașe de date s-ar
putea dovedi mai puțin eficient ca accesul la surse masive de putere de calcul
(blockchain). Astfel, noile tehnologii permit unui sistem de învățare mecanică să
genereze o cantitate uriașă de date noi folosind cantități reduse de informații de bază.
5.1.1.3. Învățarea mecanică neasistată

Învățarea mecanică neasistată folosește următoarea abordare
• sistemul încearcă să identifice anumite tipare sau șabloane în informațiile
pe care le primește;
• apoi le categorisește, folosind anumite similarități.
5.2. Învățarea profundă - Deep Learning

Învățarea profundă este o metodă de învățare mecanică din experiență.
Deep-Learning este utilizată, spre exemplu, la vehiculele autonome, astfel
încât, acestea sun capabile să identifice semnele de circulație, să facă diferența dintre
un pieton sau un stâlp de iluminat. Deep-Learning permite învețarea direct din datele
oferite de senzori: zgomote, imagini, text etc.
5.3. Rețelele neurale

Rețelele neurale sunt nucleul Inteligenței Artificiale și sunt esențiale pentru
învățarea mecanică. Acestea sunt rețele interconectate de algoritmi, inspirate de
rețelele neurale biologice, existente în creierul uman. Aceste rețele fac schimb de
date și pot fi programate pentru a îndeplini anumite sarcini într-un mod complex care
încearcă să imite gândirea umană.
Sistemele neurale învață să îndeplinească obiective și procese analizând
exemplele pe care le primesc din afară, de obicei fără să fie programate. Algoritmul
care analizează tot setul de date nu este programat în avans să aleagă un anumit tip
de informații sau de particularități, ci caută date care pot fi grupate în funcție de
detalii comune. Un exemplu este modul în care funcționează Google News: grupează
pe categorii, în funcție de topicuri comune, toate știrile apărute în cursul unei zile.
22
https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-agx-
xavier/
2.1. Stuart J. Russell și Peter Norvig, Artificial Intelligence a Modern Approach,

New Jersey 07632: Prentice Hall, Englewood Cliffs, 1995.
2.2. Nicolas Andreff și Brahim Tamadazte, „Laser Steering using Virtual Trifocal
Visual Servoing,” FEMTO-ST Institute, UMR CNRS 6174 - UFC / ENSMM
/ UTBM., 24 rue Alain Savary, 25000 Besan¸con, France.
2.3. C. Copoț, „Tehnici de control pentru sistemele servoing vizuale,”
Politehnium, Iași, 2011.
2.4. M. Brown și D. G. Lowe, „Recognising Panoramas,” în Proceedings Ninth
IEEE International Conference on Computer Vision, Nice, France, october,
2003.
2.5. L. Tony și B. Lars, „Scale-Space Theory in Computer Vision,” Kluwer
Academic Publishers, Dordrecht, The Netherlands, 1994.
2.6. P. Lynne E., „Distributed Intelligence: Overview of the Field and its
Application in Multi-Robot Systems,” în AAAI Fall Symposium on Regarding
the Intelligence in Distributed Intelligent Systems, 2007., Alicante, march
2008.
2.7. D. A. Schoenwald, „AUVs: In Space, Air, Water, and on the Ground,” în
Autonomous Unnmed Vehicles, Albuquerque, NM 87185, U.S.A., P.O. Box
5800, MS 1004, , December 2000.
2.8. I. Nuță, „Contribuţii la dezvoltarea și perfecționarea tehnicii de intervenție în
situații de urgență.,” Military Technical Academy, București, 2015.
2.9. L. E. Parker, „Curent State of the Art in Distributed Autonomous Mobile
Robotics,” Springer-Verlag, Tokyo, 2000.
2.10. H. Gweon și R. Saxe, „Chapter 20 - Developmental Cognitive Neuroscience
of Theory of Mind,” în Neural Circuit Development and Function in the
Brain, Elsevier Inc. All, 2013, pp. 367-377.
2.11. A. M. Florea, „Elemente de Inteligență Artifificială. Volumul 1 - Proncipii și
Modele,” M.T.IL ROM, București, 1993.
2.12. B. Groza, Introducere în Inteligența Artificială – Aplicații cu strategii de
căutare neinformate și Iinformate, Timișoara: Universitatea Politehnica
Timişoara, Facultatea de Automatică şi Calculatoare.
2.13. Christopher M. Bishop,, Pattern Recognition and Machine Learning,
Springer, 2006.
2.14. R. R. Murphy, Introduction to AI Robotics, Massachusetts London, England:
A bradford Book The MIT Press Cambridge, 2000.
2.15. „http://aima.cs.berkeley.edu/,” [Interactiv].
2.16. Mihai Drăgănescu, Adrian Davidoviciu și Ioan Georgescu, Inteligența
artificială și robotica, Vol. %1 din %2Biblioteca „Avram Filipaș” a
Universității Titu Maiorescu, III2029TN, București: Editura Academiei
Române, 1983, p. 397p.
2.17. J. a. M. O. Neumann, Theory of Games and Economic Behavior, Princeton:
Princeton University Press, 1953.
2.18. A. Samuel, Some studies in machine learning using the game of checkers,
IBM Journal on Research and Development, 1959, pp. 210-229.
2.19. Y. Shoham și K. Leyton-Brown, Multiagent Systems: Algorithmic, Game
Theoretic, and Logical Foundations, First ed., Cambridge University Press,
2008, p. 504.
Abrevierea Explicația
AC Alternative Current / Curent alternativ
ACL Advanced CMOS Logic
ADC Analog to Digital Conversion A → D
AO (op- Amplificator Operațional
AMP)
SVMs Support Vector Machines
UGV Unmanned Ground Vehicle
UAV Unmanned Aerial Vehicle
UUV Unmanned Undersea Vehicle
AGV Automated Guided Vehicle
PEGASUS Prototype EGNOS Analysis System Using Sapphire
ALI Automatic Language Identification
MARVEL Multimission Automation for Real-time Verification of
spacecraft Engineering Link
SIFT Scale-invariant feature transform
UTV Vehicul cu sarcini utilitare
3. REZOLVAREA PROBLEMELOR
Inteligența artificială include scopuri, obiective, acțiuni etc. Un alt tip de agent
este cel care trebuie să rezolve probleme (Problem Solving). Este un agent bazat pe
obiective. El caută secvențe ale unor acțiuni corespunzătoare unor spații dorite.
Agentul formulează o vizualizare a problemei, ce decurge din procesul de formulare
ce are la dispoziție cunoașterea actuală și rezultatele acțiunilor. Procedural, dacă
avem definițiile exacte ale problemelor, se poate construi un proces de căutare pentru
găsirea soluțiilor:
▪ formularea problemei:
o tipuri de cunoștințe;
o probleme și soluții bine definite;
o măsurarea performanței de rezolvare a problemelor;
o alegerea spațiilor și a acțiunilor;
▪ probleme:
o virtuale;
o reale;
▪ căutarea soluțiilor:
o generarea unor secvențe de acțiune;
o structurarea datelor sub forma arborilor de decizie;
▪ strategii de căutare:
o lățimea primei benzi de căutare;
o respectarea unui cost al căutării;
o adâncimea primei benzi de căutare;
o limita adâncimii primei benzi de căutare;
o căutare iterativă;
o căutare bidirecțională;
▪ evitarea repetării spațiilor;
▪ constrângeri.
3.1 Agenți de rezolvare a problemelor
Agenții inteligenți acționează astfel încât activitatea de rezolvare a

problemelor să presupună ca procesele de identificare sau de construire a unui obiect
cu anumite caracteristici, să reprezinte soluția problemei. Această acțiune
parcurgerea unor succesiuni de stări, pentru a fi maximizată performanța. Cerințele
unei Activități de Rezolvare a Problemelor (ARP) sunt:
• structurarea simbolică: a descrierii problemei inițiale și a fiecărui obiect
implicat – baza de date;
• descrierea instrumentelor computaționale: necesare investigării sistematice

a obiectelor – operatori de transformare;
• metoda de planificare: care indică ordinea de aplicare a transformarilor,
astfel încât (a.î.) soluția problemei să fie găsită, iar costurile să fie reduse –
strategia de control;
Un agent cu mai multe opțiuni imediate de valori necunoscute poate decide ce
să facă dacă analizează diferite secvențe posibile care duc la o stare cu valoare
cunoscută.
Tipuri de probleme ce pot fi definite, în funcție de domeniul de științe aplicat:
▪ deterministă:
o observabilă ⟹ 𝑠𝑖𝑛𝑔𝑙𝑒 − 𝑠𝑡𝑎𝑡𝑒 𝑝𝑟𝑜𝑏𝑙𝑒𝑚 - agentul știe starea iar soluția
e o secvență;
o neobservabilă ⟹ 𝑐𝑜𝑛𝑓𝑜𝑟𝑚𝑎𝑛𝑡 𝑝𝑟𝑜𝑏𝑙𝑒𝑚 (nu există senzori) - agentul
știe/știe unde se aﬂă soluția, care dacă (∃) este la fel o secvență;
▪ nedeterministă:
o observabilă parțial/parțial ⟹ 𝑐𝑜𝑛𝑡𝑖𝑛𝑔𝑒𝑛𝑐𝑦 𝑝𝑟𝑜𝑏𝑙𝑒𝑚 problema de
contingență:
- percepțiile oferă informații despre starea curentă;
- soluția este un plan contingent sau o strategie;
- căutarea și execuția se îmbină.
Fig. 3.1 Agent de rezolvare a problemelor.
3.1.1 Formularea problemei
Procesul de formulare a problemei, în detaliu, se referă la cunoștințele

acumulate, statutul și acțiunile agentului. Lucruri care depind de modul de conectare
la mediu, la percepții și iarăși acțiuni. Conform [3.1] există patru tipuri de probleme:
i. single-state problems (probeleme simple);
128 3 – Rezolvarea problemelor
ii. multiple–state probelms (probleme multiple);

iii. contingency-problems (probleme urgente);
iv. exploration-problems (probleme exploratorii).
Introducerea noțiunilor de determinism/nedeterminism aduce în discuție faptul
că acțiunile agenților inteligenți pot fi de ignorare a efectelor acestor acțiuni.
Probabilitățiile de înfăptuire a unui scenariu sau altuia devin, astfel, elementul care
trebuie introdus în formulele de calcul a deciziilor. Senzorii cu care sunt echipați
roboții (mașinile, etc.) trimit informații precise (accurate perceptions), dar nu trimit
nici un fel de logică privind utilizarea acestora. Problema nu mai este una simplă
(single-problems) ea este deja una complexă (multiple-problems). Prin urmare se
trece la următorul nivel de abordare: agenți de urgență, care sunt nevoiți să despartă
informațiile în funcție de caracterul lor. Design-ul deja este multi-layer, iar
intercalarea (ierarhizarea) diferitelor layere specializate reprezintă cheia rezolvării
problemelor propuse, probleme concrete punctuale. Un robot nu poate rezolva orice
problemă. Un exemplu de algoritm stabilește ca prioritate situația cea mai dificilă.
Urmând ca prin repetarea într-o buclă închisă a datelor să le transforme într-o hartă
a mediului de lucru. Problema începe să fie cunoscută de agent specificând ce
informații are nevoie pentru a putea defini o problemă într-un singur spațiu de stare.
Elementele de bază sunt stările și acțiunile și pentru a folosi datele se urmărește
algoritmul:
• starea inițială;
• setul de acțiuni posibile;
• testul obiectiv;
• funcția de cost.
Instanțele acestui tip de date vor fi datele de intrare pentru algoritm. Ieșirea
este căutarea soluției, care, devine o stare inițială pentru testul obiectiv. Apar în acest
fel stări multiple, automat probleme multiple, care necesită intervenții în algoritmul
de analiză. Operatorul introduce stările corespunzătoare pentru a putea analiza doar
acele date pe care le solicită controler-ul.
Realitatea este diferită de abstract, de aceea acțiunile în domeniul abstract
trebuie să fie cât mai simple și să fie cât mai simple față de acțiunea reală.
Fig. 3.2 Reprezentarea problemei.
3.1.2 Spații de căutare
Spațiile de căutare sunt asimilate cu mulțimea de stări [3.2]. Mulțimea

operatorilor de transformare indică modul în care are loc transformarea
〈𝑠𝑡𝑎𝑟𝑒𝑎 𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑎 → 𝑠𝑡𝑎𝑟𝑒𝑎 𝑓𝑖𝑛𝑎𝑙𝑎〉:
- starea inițială – descrie condițiile inițiale ale problemei;
- starea finală – reprezintă soluția problemei, a cărei reprezentare poate fi

explicită sau implicită, sau traseul prin care se ajunge dintr-o stare în alta.
Mulțimea stărilor investigate reprezintă spațiul de căutare. Spre exemplu (în
cazul jocului de șah) problema celor 8 regine poziționate pe tabla de joc, astfel încât,
să nu se poată ataca reciproc. Acest lucru înseamnă că cerința se traduce, astfel:
• nici o linie, coloană sau diagonală să nu conțină mai mult de o regină;
• starea inițială o reprezintă configurația inițială a tablei de șah, fără regine;
• starea finală o reprezintă configurația tablei cu reginele amplasate.
Din punct de vedere nedeterminist obținerea soluției se face printr-un proces
de căutare fără aplicarea unei secvențe de transformări. Selectarea transformărilor și
memorarea transformărilor efectuate constituie strategia de control. O strategie de
control nu este doar o secvență de acțiuni, ci o modalitate de descriere a selecției
unei acțiuni ca răspuns la un eveniment extern, cum ar fi rezultatul unui test,
rezultatul aplicării unei proceduri complicate de calcul, care trebuie să fie
sistematică:
• efectuează fiecare acțiune – cerința de completitudine;
• nu efectua de mai multe ori aceeași acțiune – cerința de protejare.
Aceste tip de căutare se mai numește euristic. Strategia utilizează
metodologii/proceduri de căutare, iar informațiile sunt reprezentate sub forma unor
funcții euristice asociate fiecărei stări. Există strategii de căutare care nu folosesc
funcții euristice, acestea se numesc strategii de căutare neinformate (în orb - blind-
search). Dintre acestea strategii amintim:
▪ strategia de căutare pe nivel (Breadth-First)1;
▪ strategia de căutare în adâncime (Depth-First)2,3,4;
▪ strategia de căutare cu cost uniform (Uniform Cost)5,6,7;
▪ strategia de căutare limitată în adâncime (Depth-Limited)8,9;
▪ strategia de căutare iterativă în adâncime (Iterative-Deepening);
▪ strategia de căutare bidirecţională (Bidirectional search).
Aplicarea strategiilor blind-search caută să răspundă la următoarele
întrebări:
i. care este complexitatea de timp a strategiei?;
1
https://www.hackerearth.com/practice/algorithms/graphs/breadth-first-search/tutorial/
2
https://www.geeksforgeeks.org/depth-first-search-or-dfs-for-a-graph/
3
https://www.educative.io/edpresso/what-is-depth-first-search
4
https://brilliant.org/wiki/depth-first-search-dfs/
5
http://cs-gw.utcluj.ro/~anca/iia/slide03.pdf
6
https://www.educba.com/uniform-cost-search/
7
https://cse.iitrpr.ac.in/ckn/courses/s2017/csl302/w3.pdf
8
https://www.javatpoint.com/ai-uninformed-search-algorithms
9
https://www.analyticsvidhya.com/blog/2021/02/uninformed-search-algorithms-in-ai/
ii. care este complexitatea de spațiu a strategiei?

iii. este strategia completă?
iv. este strategia optimală?
v. cum se implementează?
vi. ce avantaje şi dezavataje are?
Orice tip de căutare funcționează pe principiul unei cozi de așteptare, sau tip
stivă/listă de sortare. Fiecare strategie are particularitatea ei.
Particularizarile sunt date de modul în care se răspunde la întrebările de mai
sus, întrebări care sunt accesate într-o ordine generată de tipul structurii de date în
care se rețin nodurile arboelui de căutare.
Pentru a face o alegere a unei strategii de căutare, astfel încât, să obținem un
rezultat optim la rezolvarea unei probleme, trebuie să efectuăm o evaluare a
eficienţei rezolvării problemei. Acest lucru se poate face ținând cont de câteva puncte
de vedere. O strategie de căutare poate fi un compromis între calitatea soluţiei (costul
căii Stare iniţială – Stare finală) şi costul căutarii (timp, memorie, costuri de
implementare etc.). Pe lângă principiile orientative, se impune să fie aplicate și
măsuri cantitative şi calitative exacte pentru a estima eficienţa unei strategii de
căutare. Acestea sunt următoarele:
• măsuri cantitative:
o complexitatea de timp a strategiei T - în cât timp (măsurat ca număr
de paşi ai algoritmului) este găsită soluţia;
o complexitatea de spațiu a strategiei S – de cât spațiu (este vorba de
memorie) este nevoie pentru găsirea soluţiei;
• măsuri calitative:
o completitudine – o strategie se numeşte completă dacă garantează
găsirea unei soluţii ;
o optimalitate – o strategie se numeşte optimală dacă garantează
găsirea celei mai bune soluţii din punctul de vedere al costului căii
între starea iniţială şi starea finală.
Aprecierile care se referă la ce complexităţile de timp şi spațiu sunt aprecieri
pur cantitative, măsurate cu ajutorul indicatorului de complexitate O.
Completitudinea este întotdeuna o proprietate binară, altfel spus, se apreciază dacă
o strategie este sau nu este completă. În ceea ce priveşte optimalitatea, aceasta este
în general tot o proprietate binară. O strategie este sau nu este optimală, dar, există
şi strategii, numite sub-optimale, care nu găsesc cea mai bună soluţie dar găsesc o
soluţie foarte apropiată ca şi cost față de cea mai bună soluţie.
3.1.2.1 Căutarea în lățime - Breadth-First
Cea mai simplă strategie de căutare este, pe nivel, explorează nodurile în

ordinea nivelelor, altfel spus nodurile de pe nivelul x sunt explorate înaintea
nodurilor de pe nivelul x+1, exemplu din Fig. 3.3 pentru un arbore binar (doi
operatori).
Strategia parcurgerii în lăţime (BF- breadth first) funcţionează respectând
mecanismul de tip FIFO (first in first out). Ea se bazează pe traversarea tuturor
muchiilor disponibile din nodul curent către noduri nedescoperite, care vor fi astfel
vizitate. După acest proces, nodul explorat este scos din coadă, prelucrându-se
succesiv toate nodurile ajunse în vârful cozii.
Fig. 3.3 Reprezentarea strategiei de căutare Breadth-First.
Acest mecanism permite identificarea drumurilor de lungime minimă (ca

număr de muchii) de la nodul de start către toate vârfurile accesibile lui din graf.
Arborele BF, ce cuprinde muchii traversate în parcurgerea în lăţime, are proprietatea
de a fi format doar din drumuri de lungime minimă ce pornesc din nodul considerat
ca rădăcină. În parcurgerea BF, pentru fiecare nod se reţin mai multe informaţii şi
anume:
- nodul predecesor în parcurgere: TP[nod]
- lungimea drumului minim către nodul de start: DMIN[nod]
- ordinea de parcurgere a nodurilor în BF: vectorul C
- muchiile arborelui MABF: matricea a cu k linii şi 2 coloane
Vectorul va avea forma:
COADA = (1,2,4,5,3)
DMIN = (0,1,2,1,1)
|
TP = (0,1,2,1,1)
MABF = [1,2], [1,4], [1,5], [2,3]
Complexitatea algoritmului este O(n+m). Programul următor realizează
implementarea algoritmului BF pentru un graf reprezentat prin liste de adiacenţă
alocate dinamic.
#include<iostream.h>
#include<ifstream.h>
#define N 50
typedef struct nod{
int inf;
nod *leg;
}AD;
AD *L[N]; //listele vecinilor
int VIZ[N],C[N],DMIN[N],TATA[N]; // C-vectorul coada
int n,k,prim,ultim;
int a[2*N][3]; //a retine muchiile arborelui BF
void citire()
{
int i,j; AD *x;
Ifstream f(“graf.in”);
f>>n;
for(i=1;i<=n;i++) //aloca adrese pentru listele de vecini
{
L[i]=new AD; L[i]->leg=0;
}
while(!feof(f))
{
f>>i>>j;
x=new AD; x->inf=j; x->leg=L[i]->leg; L[i]->leg=x;
//adaug j in lista vecinilor lui i
x=new AD; x->inf=i; x->leg=L[j]->leg; L[j]->leg=x;
//adaug i in lista vecinilor lui j
}
f.close();
}
void BF(int nod)
{
AD *x;
VIZ[nod]=1; TATA[nod]=0; DMIN[nod]=0;
prim=ultim=1; C[prim]=nod;
while(prim<=ultim)
{
nod=C[prim]; //extrag nodul din varful cozii
x=L[nod]->leg; //lista vecinilor lui nod
while(x)
{
if(!VIZ[x->inf])
{
TATA[x->inf]=nod; VIZ[x->inf]=1;
DMIN[x->inf]=DMIN[nod]+1;
C[++ultim]=x->inf; //adaug x->inf in coada
k++; a[k][1]=nod; a[k][2]=x->inf;
//memorez muchia de arbore [nod,x->inf]
}
x=x->leg;
}
prim++; //avansez la urmatorul nod din coada
}
}
void afisare_coada() //afiseaza nodurile dintr-un arbore BF
{
int i;
for(i=1;i<=ultim;i++) cout<<C[i]<<” ”;
cout<<“\n”;
}
void drum(int i,int nod) //afiseaza nodurile dintr-un lant minim
{
if(i!=nod) drum(TATA[i],nod);
cout<<i<<“ “;
}
void parcurgere_bf()
{
int nod,i;
for(nod=1;nod<=n;nod++) VIZ[nod]=0;
for(nod=1;nod<=n;nod++)
if(!VIZ[nod])
{
k=0; BF(nod); afisare_coada();
cout<<"Muchiile arborelui BF: ";
for(i=1;i<=k;i++)
cout<<"[ a[“<<i<<”][1],a[“<<i<<”][2]] ";
cout<<“\n”;
for(i=1;i<=ultim;i++)
if(C[i]!=nod)
{
cout<<"de la <<nod<<” la “<<C[i]<<” lantul este: ";
drum(TATA[C[i]],nod);
cout<< C[i],<<" lungime \n"<< DMIN[C[i]]<<” ”;
}
}
}
void main()
{
int i;
citire();
cout<<"Parcurgere BF: \n";
parcurgere_bf();
cout<<"TATA_DF=("; for(i=1;i<=n;i++) cout<<TATA[i]<< " ",;
cout<<")\n";
}
3.1.2.2 Căutarea în adâncime - Depth-First:
La strategia de căutare în adâncime frontiera acționează ca o ultimă

intrare/ieșire dintr-o stivă. Elementele sunt adăugate în stivă, una câte una, iar cel
selectat pentru extragere, este și ultimul intrat.
Fig. 3.4 Reprezentarea strategiei de căutare Depth-First.
Strategia de căutare în adâncime, este similară cu a grafurilor, care

presupune traversarea unei muchii a nodului curent spre un nod ce urmează să
fie descoperit.
Fig. 3.5 Reprezentarea strategiei cu mecanism LIFO,

parcurgerea în ordinea cronologică.
Când se termină de explorat muchiile nodului curent se revine în nodul din

care s-a produs explorarea nodului curent. Procesul iterativ continuă până când toate
nodurile au fost explorate. Strategia DF (Depth-First) respectă mecanismul LIFO
(Last In First Out). Nodurile care sunt eliminate din stivă, nu mai au nici o muchie
disponibilă pentru traversare. Muchiile grafului se împart în:
• muchii de avans – muchii de arbore;
• muchii de întoarcere – unesc un nod cu predecesorul.
Fig. 3.6 Reprezentarea arborelui/grafului parțial.
În cadrul reprezentării din

Fig. 3.6, muchiile de întoarcere sunt (1 ↔ 4) și (1 ↔ 5):
• nodul predecesor TP [nod];
• intorducerea nodului curent în stivă TI [nod];
• finalul explorării TF [nod];
• muchii de avansare MA, matrice cu k – linii și 2 coloane;
• muchii de întoarcere MI, matrice cu t – linii și 2 coloane.
Cei trei vectori vor avea formele:

TI = (1,2,3,4,6)
TF = (10,9,8,5,7)
|
TP = (0,1,2,3,3)
|
MA = [1,2], [2,3], [3,4], [3,5],
MI = [1,4], [1,5]
Determinarea muchiilor arborelui BF (de avansare), precum și a celor de
întoarcere. Graful este G(V,E), unde V – mulțimea celor n noduri, E este mulțimea
muchiilor și graful privind complexitatea algoritmului este O(n+m).
Este posibil să determinăm şi muchiile arborelui BF (de avansare), precum şi
muchiile de întoarcere. Considerând graful G(V,E), unde V este mulţimea celor n
noduri şi E este mulţimea celor m muchii, şi graful reprezentat prin listele de
adiacenţă alocate dinamic, complexitatea algoritmului este O(n+m). Vectorul VIZ
indică la fiecare pas ce vârf a fost explorat. Iniţial, toate vârfurile sunt nevizitate şi
acest vector este iniţializat cu 0.
Fig. 3.7 Reprezentarea vectorilor de căutare.
În vectorul TI se memorează pentru fiecare nod timpul la care începe

explorarea, iar în vectorul TF când se încheie explorarea unui nod.
În vectorul TP se memorează pentru fiecare nod predecesorul în
parcurgerea DF. Muchile de avansare se memorează pe liniile matricii a, numărul
acestor muchii fiind k. Când un nod j este parcurs plecând din nodul i, muchia
[i,j] este de avansare.
Când un vecin j al lui i este deja vizitat, muchia [i,j] este de întoarcere.
Afişarea muchiilor de avansare, respectiv de întoarcere se realizează cu ajutorul a
două funcţii recursive care folosesc matricea de adiacenţă construită simultan cu
construirea listele de adiacenţă. După afişarea unei muchii, aceasta se elimină din
graf.
#include<iostream.h>
#include<ifstream.h>
#define N 50
typedef struct nod{
int inf;
nod *leg;
}AD;
AD *L[N]; //listele vecinilor
int VIZ[N],TI[N],TF[N],TP[N],n,timp,k,t;
int a[N][N]; //matricea de adiacenta
void citire()
{
int i,j; AD *x;
Ifstream f(“graf.in”);
f>>n;
for(i=1;i<=n;i++) //aloca adrese pentru listele de vecini
{
L[i]=new AD; L[i]->leg=0;
}
while(!feof(f))
{
f>>i>>j; a[i][j]=a[j][i]=1;
x=new AD; x->inf=j; x->leg=L[i]->leg; L[i]->leg=x;
//adaug j in lista vecinilor lui i
x=new AD; x->inf=i; x->leg=L[j]->leg; L[j]->leg=x;
//adaug i in lista vecinilor lui j
}
f.close();
}
void parcurge_df(int nod)
{
AD *x=L[nod]->leg;
VIZ[nod]=1; timp++; TI[nod]=timp; //timpul de incepere
cout<<"%d ",nod);
while(x)
{
if(!VIZ[x->inf])
{
TP[x->inf]=nod;
parcurge_df(x->inf);
}
x=x->leg;
}
timp++; TF[nod]=timp; //timp de terminare
}
void muchii_intoarcere(int nod)
{
int i;
for(i=1;i<=n;i++)
if(a[nod][i])
if(TATA[nod]!=i && nod!=TP[i])
{
cout<<“[“<<nod<<“,”<<i<<“] “;
a[nod][i]=a[i][nod]=0;
muchii_intoarcere(i);
}
}
void muchii_avans(int nod)
{
int i;
for(i=1;i<=n;i++)
if(a[nod][i])
{
cout<<“[“<<nod<<“,”<<i<<“] “;
a[nod][i]=a[i][nod]=0;
muchii_avans(i);
}
}
void DF()
{
int nod;
for(nod=1;nod<=n;nod++) VIZ[nod]=0;
timp=0;
for(nod=1;nod<=n;nod++)
if(!VIZ[nod])
{
parcurge_df(nod); cout<<“\n”;
cout<<"Muchii de intoarcere: "; muchii_intoarcere(nod);
cout<<“\n”;
cout<<"Muchii de avans: "; muchii_avans(nod);
cout<<“\n”;
}
}
void main()
{
int i;
citire();
cout<<"Parcurgerea DF: \n"); DF(); cout<<“\n”;
cout<<"\nTI=("); for(i=1;i<=n;i++) cout<<TI[i]<<” ”; cout<<")";
cout<<"\nTF=("); for(i=1;i<=n;i++) cout<<TF[i]<<” ”; cout<<")";
cout<<"\nTATA_DF=("; for(i=1;i<=n;i++) cout<<"%d ",TP[i];
cout<<")\n";
}
3.1.2.3 Căutarea cu cost uniform – Uniform Cost
Strategiile de căutare anterioare nu pot rezolva optimalitatea pentru cazul

în care operatorii nu au costuri egale, respectiv costul unor noduri de pe un nivel
mai mare nu este mai mare decât costul unor noduri de pe un nivel mai mic.
Strategia de căutare cu cost uniform sau algoritmul lui Dijkstra,
funcţioneză similar cu strategia de căutare pe nivel doar că de această dată
nodurile sunt explorate în ordinea costurilor. În cazul în care costul operatorilor
este egal, strategia de căutare cu cost uniform se comportă identic cu strategia de
căutare pe nivel.
Fie graful orientat aciclic din Fig. 3.8, se dorește găsirea celui mai scurt
drum de la A la E, caz în care nodurile sunt explorate în ordinea costurilor. Se
observă că traseul A-D-E este cel mai ieftin.
Fig. 3.8 Reprezentarea căutării cu cost uniform.
Căutările pot fi informate sau neinformate, caz în care complexitățilese

desfășoară fie după timp și spațiu fie după completitudine și optimalitate.
În continuare se prezintă un exemplu de cum se definește o clasă pentru
nodul arborelui de căutare cu costuri minime [3.3] (pag. 45-53)., pentru
determinarea căii optime la deplasarea pe un traseu cu obstacole.
class SearchTreeNode
{
public SearchTreeNode parrent = null;
public int cost;
public int level;
public long id = 0;
public int coordX = 0;
public int coordY = 0;
public int nodeOperator = 0; //degreess from 90 to
360
}
Apoi se definesc costurile pentru deplasarea în linie dreaptă şi în diagonală:
// costul miscarii in linie dreapta

private const int straigthMovement = 100;
// costul miscarii in diagonala sqrt(2) =
1.4142135623730950488016887242097
private const int diagonalMovement = 141;
Căutarea cu cost uniform, așa cum am amintit mai devreme, se referă la

completitudine, la optimal și la costuri. Nu se iau în calcul căutările ghidate, care
cresc complexitatea spațiului și timpului față de căutarea în adâncime.
3.1.2.4 Căutarea cu adâncime limitată – Depth-Limited
Un algoritm de căutare cu adâncime limitată este similar cu o căutare în

adâncime, cu o limită predeterminată. Căutarea limitată în adâncime poate
rezolva dezavantajul căii infinite în căutarea în adâncime. În acest algoritm,
nodul de la limita de adâncime va fi tratat deoarece nu mai are noduri succesive.
Căutarea limitată în adâncime poate fi încheiată cu două condiții de eșec:
• valoare standard de eșec: indică faptul că problema nu are nicio soluție;
• valoare de eșec de tăiere: nu definește nici o soluție pentru o problemă
într-o anumită limită de adâncime.
Avantajele căutării limitate în adâncime este eficientă prin faptul că nu
solicită resurse de memorie.
Dezavantajele căutării limitate în adâncime îl constituie incompletitudinea.
Este posibil să nu obținem un optim dacă problema are mai multe soluții.
Fig. 3.9 Reprezentarea căutării cu adâncime limitată Depth-Limited10.
function DEPTH-LIMITED-SEARCH(problem, limit) returns

a solution, or failure/cutoff
return RECURSIVE-DLS(MAKE-NODE(problem.
INITIAL-STATE), problem, limit)
function RECURSIVE-DLS(node, problem, limit) returns
a solution, or failure/cutoff
if problem.GOAL-TEST(node.STATE) then return
SOLUTION(node)
else if limit = 0 then return cutoff
else
cutoff_occurred? ← false
for each action in problem.ACTIONS(node.STATE) do
child ← CHILD-NODE(problem, node, action)
result ← RECURSIVE-DLS(child,problem,limit-1)
if result = cutoff then cutoff_occurred? ← true
else if result 6= failure then return result
if cutoff_occurred? then return cutoff else return
failure
“depth limited search in python with a graph”11
###############
10
https://www.javatpoint.com/ai-uninformed-search-algorithms
11
https://www.codegrepper.com/code-examples/python/depth+limited+search+in+python+
with+a+graph
#The Algorithm (In English):

# 1) Pick any node.
# 2) If it is unvisited, mark it as visited and recur on all its
# adjacent nodes.
# 3) Repeat until all the nodes are visited, or the node to be
# searched is found.
# The graph below (declared as a Python dictionary)
# is from the linked website and is used for the sake of
# testing the algorithm. Obviously, you will have your own
# graph to iterate through.
graph = {
'A' : ['B','C'],
'B' : ['D', 'E'],
'C' : ['F'],
'D' : [],
'E' : ['F'],
'F' : []
}
visited = set() # Set to keep track of visited nodes.
##################
# The Algorithm (In Code)
def dfs(visited, graph, node):

if node not in visited:
print (node)
visited.add(node)
for neighbour in graph[node]:
dfs(visited, graph, neighbour)
# Driver Code to test in python yourself.

# Note that when calling this, you need to
# call the starting node. In this case it is 'A'.
dfs(visited, graph, 'A')
# NOTE: There are a few ways to do DFS, depending on what your
# variables are and/or what you want returned. This specific
# example is the most fleshed-out, yet still understandable,
# explanation I could find.
3.1.2.5 Căutarea cu adâncime incrementală - Iterative-Deepening
Căutarea cu adâncime incrementală Iterative -Deepening (IDDFS) combină

eficiența spațială a căutării în profunzime și a căutării rapide în prima amploare
(pentru noduri mai apropiate de rădăcină).
Ca principiu de funcționare se apelează Depth First Search (DFS) pentru

diferite adâncimi începând de la o valoare inițială. În fiecare apel, DFS este
restricționat să depășească profunzimea dată. Deci, practic facem DFS într-un mod
Basic First Search (BFS).
Exemplificare de algoritm12:
// Returns true if target is reachable from

// src within max_depth
bool IDDFS(src, target, max_depth)
for limit from 0 to max_depth
if DLS(src, target, limit) == true
return true
return false
bool DLS(src, target, limit)

if (src == target)
return true;
// If reached the maximum depth,

// stop recursing.
if (limit <= 0)
return false;
foreach adjacent i of src

if DLS(i, target, limit?1)
return true
return false
Cel mai important lucru este că se vizitează noduri de nivel superior de mai
multe ori. Ultimul nivel (sau adâncimea maximă) este vizitat o singură dată, al doilea
ultim nivel este vizitat de două ori și așa mai departe. Poate părea scump, dar se pare
că nu este atât de costisitor, deoarece într-un arbore decizional majoritatea nodurilor
se află la nivelul inferior. Deci, nu contează prea mult dacă nivelurile superioare sunt
vizitate de mai multe ori.
12
https://www.geeksforgeeks.org/iterative-deepening-searchids-iterative-deepening-depth-
first-searchiddfs/
Fig. 3.10 Reprezentarea căutării cu adâncime incrementală Iterative Depening13.
Mai jos este implementarea algoritmului de mai sus în Python
// C++ program to search if a target node is reachable from

// a source with given max depth.
#include<bits/stdc++.h>
using namespace std;
// Graph class represents a directed graph using adjacency

// list representation.
class Graph
{
int V; // No. of vertices
// Pointer to an array containing

// adjacency lists
list<int> *adj;
// A function used by IDDFS

bool DLS(int v, int target, int limit);
public:
Graph(int V); // Constructor
void addEdge(int v, int w);
// IDDFS traversal of the vertices reachable from v
bool IDDFS(int v, int target, int max_depth);
};
Graph::Graph(int V)
13
https://www.geeksforgeeks.org/iterative-deepening-searchids-iterative-deepening-depth-
first-searchiddfs/
{
this->V = V;
adj = new list<int>[V];
}
void Graph::addEdge(int v, int w)

{
adj[v].push_back(w); // Add w to v’s list.
}
// A function to perform a Depth-Limited search

// from given source 'src'
bool Graph::DLS(int src, int target, int limit)
{
if (src == target)
return true;
// If reached the maximum depth, stop recursing.

if (limit <= 0)
return false;
// Recur for all the vertices adjacent to source vertex

for (auto i = adj[src].begin(); i != adj[src].end(); ++i)
if (DLS(*i, target, limit-1) == true)
return true;
return false;
}
// IDDFS to search if target is reachable from v.

// It uses recursive DFSUtil().
bool Graph::IDDFS(int src, int target, int max_depth)
{
// Repeatedly depth-limit search till the
// maximum depth.
for (int i = 0; i <= max_depth; i++)
if (DLS(src, target, i) == true)
return true;
return false;
}
// Driver code
int main()
{
// Let us create a Directed graph with 7 nodes
Graph g(7);
g.addEdge(0, 1);
g.addEdge(0, 2);
g.addEdge(1, 3);
g.addEdge(1, 4);
g.addEdge(2, 5);
g.addEdge(2, 6);
int target = 6, maxDepth = 3, src = 0;

if (g.IDDFS(src, target, maxDepth) == true)
cout << "Target is reachable from source "
"within max depth";
else
cout << "Target is NOT reachable from source "
"within max depth";
return 0;
}
3.1.2.6 Căutarea bidirecțională – Bidirectional search
Îmbunătăţirea strategiei de căutare pe lățime poate fi realizată prin demararea

a două căutări simultane:
• una de la starea iniţială către starea finală;
• una în sens invers.
Acest lucru duce în mod evident la înjumătăţirea resurselor de timp şi memorie
necesare având ca singură cerinţă suplimentară aceea de a păstra o listă a frontierelor
pentru cele două căutări în care să se verifice periodic dacă nu există noduri care
coincid,
Fig. 3.11. Această strategie poartă numele de strategia de căutare
bidirecţională şi menţionăm încă de acum că pentru economie de memorie pe una
dintre direcţii poate fi aplicată şi altă strategie precum strategia de căutare în
adâncime.
Conform celor amintite în cap. 0 aprecierea acestei strategii se prezintă astfel:
a) complexitate de timp şi spațiu:
Deoarece adâncimea arborelui de căutare se înjumătăţeşte, complexităţile de
timp şi spaţiu vor deveni:
 d
  d
T = 2  1 + b + b 2 + + b 2  = O b 2  ,
   
respectiv,
d
 d
S = 2  b 2 = O b 2  ,
 
Acest lucru este sugerat şi în Fig. 3.11. La complexitatea de timp trebuie

adăugat şi timpul de calcul necesar pentru verificarea coliziunilor între cele două
frontiere. Deoarece acest lucru implică o căutare binară, sub indicatorul O
complexitatea nu se schimbă, mai exact însă timpul de calcul va fi:
d d
 d
T = 1 + b + b2 + + b d + 1 + b  log 2 b + b 2  log 2 b 2 + + b 2  log 2 b 2 = O  b 2  ,
 
în cazul în care presupunem că la fiecare nod nou explorat se verifică dacă acesta nu
cumva există în lista de frontiere a căutării pornite din cealaltă parte.
Fig. 3.11 Reprezentarea strategiei de căutare bidirecțională.

Fig. 2.4 [3.3]
b) completitudine şi optimalitate:
Căutarea bidirecţională este completă şi optimală după cum sunt cele două
strategii care le implică. Astfel, pentru cazul în care se foloseşte breadth-first, este
completă tot timpul (atunci când factorul de ramificaţie este finit) şi este optimală pe
toate cazurile unde este şi breadth-first optimală.
c) implementare:
Se implementează cele două strategii de căutare, astfel, se porneşte cu breadth-
first simultan de la starea iniţială şi de la starea finală. Pe lângă aceasta se păstrează
şi două liste ale frontierelor între care se verifică periodic dacă nu există coliziuni.
Se poate alege breadth-first dintr-o parte şi o căutare diferită din cealaltă parte, având
grijă la riscurile ca nodurile din cele două frontiere să nu coincidă.
d) avantaje şi dezavantaje:
Avantajul major este că reduce semnificativ costurile căutării Breath-First, dar
mai ales datorită faptului că este mult mai rapidă decât orice altă strategie neinformată.
Ca dezavantaje amintim:
• consumul de memorie care este tot exponenţial;
• faptul că nu poate fi implementată dacă nu este cunoscută starea finală sau
dacă operatorii de generare a stărilor nu sunt inversabili sau sunt greu de
calculat predecesorii.
Metode de căutare14, [3.4,3.5].
Fig. 3.12 Reprezentarea spațiului stărilor.
Fig. 3.13 Reprezentarea Grafurilor de căutare.
14
http://aima.cs.berkeley.edu/
⟨o103, o109, o119, o123, r123⟩
⟨o103, b3, b4, o109, o119, o123, r123⟩
⟨o103, b3, b1, b2, b4, o109, o119, o123, r123⟩
Algoritmi de căutare generică.
Fig. 3.14 Reprezentarea Algoritmilor de căutare generică.
1:Procedure Search(G,S,goal)
2: Inputs
3: G: graph with nodes N and arcs A
4: S: set of start nodes
5: goal: Boolean function of states
6: Output
7: path from a member of S to a node for which goal is true
8: or ⊥ if there are no solution paths
9: Local
10: Frontier: set of paths
11: Frontier ←{⟨s⟩: s∈S}
12: while (Frontier ≠{})
13: select and remove ⟨s0,...,sk⟩ from Frontier
14: if (goal(sk)) then
15: return ⟨s0,...,sk⟩

16: Frontier ←Frontier ∪{⟨s0,...,sk,s⟩: ⟨sk,s⟩∈A}
17: return ⊥
3.2 Sisteme multiagent
3.2.1 Multiagent Framework
În acest subcapitol este prezentat cazul în care există mai mulți agenți. Agenții
pot acționa autonom, fiecare având propriile informații despre ceilalți agenți. De
asemenea, rezultatul depinde de acțiunile tuturor agenților iar un mecanism specifică
modul în care acțiunile agenților duc la rezultate. Totodata, fiecare agent poate avea
propria utilitate, care depinde de rezultat (Fig. 3.15).
Fig. 3.15 Reprezentarea unui agent care interacționează cu un mediu.
Fiecare agent decide ce să facă pe baza propriilor sale utilități interacționând

și cu alți agenți. Un agent acționează strategic atunci când decide ce să facă în funcție
de obiectivele sau utilitățile sale. Câteodată tratăm natura ca un agent, fiind definită
ca un agent special care nu are valori și nu acționează strategic. Natura poate fi văzută
ca incluzând toți agenții care nu acționează strategic. În ceea ce privește arhitectura
agentului prezentată în Fig. 3.15, natura și ceilalți agenți formează mediul pentru un
agent. Un agent strategic nu poate trata alți agenți strategici ca parte a naturii,
deoarece ar trebui să motiveze utilitatea și acțiunile lor.
Există două limite opuse în cercetarea sistemelor multiagent. Prima este pe
deplin cooperantă, agenții au aceeași funcție de utilitate. A doua este pe deplin
competitivă, un agent poate câștiga doar atunci când altul pierde. Acestea sunt
numite jocuri cu sumă zero, utilitatea poate fi exprimată într-o formă astfel încât
suma utilităților pentru agenți să fie zero pentru fiecare rezultat.
Majoritatea interacțiunilor sunt între aceste două limite opuse, unde utilitățile
agenților sunt sinergice în unele aspecte iar în alte aspecte sunt independente. De
exemplu, doi agenți comerciali, cu magazine unul lângă celălalt, pot împărtăși
obiectivul de a avea zona străzii curată. Aceștia pot concura pentru clienți. Totodată
este posibil să nu aibă preferințe cu privire la detaliile magazinului celuilalt agent.
Adesea agenții pot fi mai buni dacă își coordonează acțiunile prin cooperare și
negociere.
Interacțiunile multiagent au fost studiate folosind terminologia jocurilor în
urma lucrărilor ale lui Neumann și Morgenstern (Neumann, 1953). Multe probleme
de interacțiune între agenți pot fi studiate în ceea ce privește jocurile. Studiul
jocurilor este menit să fie despre interacțiuni multiagent generale, nu doar despre
jocuri artificiale.
Sistemele multiagent sunt omniprezente în inteligența artificială, jocurile fiind
primele aplicații ale AI. Unul dintre primele sisteme de învățare a fost pentru jocul
de damă de Samuel (Samuel, 1959). Calculatoarele au avut succes la checker și
backgammon, mai puțin la joc Go din cauza dimensiunii spațiului de căutare. Aceste
jocuri sunt mari dar conceptual simple iar agenții pot observa starea lumii.
În majoritatea interacțiunilor din lumea reală, starea lumii nu este observabilă
iar interesul pentru jocurile parțial observabile a crescut.
3.2.2 Reprezentarea jocurilor
Pentru a putea argumenta despre o interacțiune multiagent, în acest subcapitol

sunt reprezentate opțiunile disponibile agenților și rambursările pentru acțiunile lor.
În literatura de specialitate există multe scheme de reprezentare pentru jocuri și
interacțiuni multiagent. Aceste scheme de reprezentare încearcă să reprezinte un
aspect al jocurilor care pot fi exploatate pentru câștig de calcul.
În această secțiune sunt prezentate trei modalități de interacțiuni. Primele
rezumă toată structura politicilor agenților. Al doilea modelează structura secvențială
a jocurilor iar a treia reprezentare se îndepărtează de reprezentarea bazată pe stare.
3.2.2.1 Forma de interacțiune normală a jocurilor
Cea mai de bază reprezentare a jocurilor este forma strategică a unui joc sau
un joc cu formă normală, fiind alcătuită din:
• Un set finit de agenți I, identificat cu numerele întregi I = {1, ..., n};
• Un set de acțiuni A pentru fiecare agent i∈I. O alocare a unei acțiuni în Ai
fiecărui agent i∈I este un profil de acțiune. Putem vizualiza un profil de
acțiune ca un tuple ⟨a1, ..., an⟩, care specifică faptul că agentul I desfășoară
acțiunea ai;
• Funcție de utilitate ui pentru fiecare agent i∈I, returnează utilitatea așteptată
pentru agentul dat profilului de acțiune.
Acțiunea comună a tuturor agenților produce un rezultat, un agent are o
utilitate asupra fiecărui rezultat. Utilitatea pentru un agent este menită să cuprindă
tot ceea ce este interesat, inclusiv corectitudinea și bunăstarea societății.
Exemplu: Jocul „piatră, hârtie, foarfecă” (rock, paper, scissors) este un joc
obișnuit, existând chiar un campionat mondial. Să presupunem că există doi agenți
A și B. Există trei acțiuni pentru fiecare agent, astfel încât:
AA=AB={piatră, hârtie, foarfecă}.
Pentru fiecare combinație de o acțiune pentru A și o acțiune pentru B există o
utilitate pentru A și o utilitate pentru B.
B
piatră hârtie foarfecă
piatră 0,0 -1,1 1,-1
A hârtie 1,-1 0,0 -1,1
foarfecă -1,1 1,-1 0,0
Fig. 3.16 Forma strategică pentru jocul piatră-hârtie-foarfecă.
Acest lucru este reprezentat într-un tabel ca în Fig. 3.16, având denumirea de
matrice de plată. Alice alege un rând și Bob alege o coloană, simultan. Acest lucru
oferă o pereche de numere: primul număr este rambursarea către jucătorul de rând
(A), iar cel de-al doilea dă plata jucătorului de coloană (B).
Utilitatea pentru fiecare dintre ei depinde de ceea ce fac ambii jucători. Un
exemplu de profil de acțiune este ⟨foarfecăA, piatrăB⟩, unde (A) alege „foarfecă” și
(B) alege „piatră”. În acest profil de acțiune, (A) primește utilitatea (-1) și (B)
utilitatea (1). Acest joc este un joc cu sumă zero, practic o persoană câștigă doar
atunci când cealaltă pierde. O „acțiune” nu este doar o simplă alegere, este o
strategie, o specificație a ceea ce va face agentul în cadrul diferitelor situații. Forma
normală este o specificație a utilităților, date fiind strategiile posibile ale agenților.
Această formă reprezintă și motivul pentru care se numește „forma strategică” a unui
joc.
Acțiunea din definiția unui joc de formă normală poate fi un controler pentru
agent. Astfel, fiecare agent alege un controler, iar utilitatea oferă rezultatul scontat
al controlerelor rulate pentru fiecare agent dintr-un mediu.
3.2.2.2 Forma extinsă a unui joc
Această metodă de reprezentare a unui joc nu oferă decât o rambursare unică

pentru fiecare agent pe baza unor acțiuni unice, alese simultan, pentru fiecare agent
iar interpretarea unei acțiuni în definiție este foarte generală.
În timp ce forma normală a unui joc reprezintă controlerele ca unități unice,
este firesc să specificăm desfășurarea unui joc în timp. Forma extinsă a unui joc este
o extensie a unui arbore de decizie cu un singur agent.
Un joc de informații perfect în formă extinsă sau un arbore de joc (Fig. 3.17)
este un arbore finit în care nodurile sunt stări și ramurile corespund acțiunilor
agenților:
• fiecare nod intern este etichetat cu un agent care controlează nodul;
• fiecare ramură care intră într-un nod marcat cu agentul i corespunde unei
acțiuni pentru agentul i;
• fiecare nod intern etichetat cu un agent are o distribuție a probabilității
asupra rezultatelor sale;
• nodurile de final reprezintă rezultatele finale și sunt etichetate cu o utilitate
pentru fiecare agent.
Fig. 3.17 Forma extinsă a jocului de partajare.
Forma extinsă a unui joc specifică o desfășurare detaliată. Fiecare cale către
un nod final, numită rulare, specifică o modalitate particulară prin care jocul ar putea
continua în funcție de alegerile agenților și de natura aplicațiilor.
O strategie pură pentru agentul i este o funcție de la nodurile controlate de
agentul i în acțiuni, se selectează un rezultat pentru fiecare nod pe care îl controlează
agentul i.
Exemplu: Luând în considerare un joc de partajare unde există doi agenți, (A)
și (B). Există două elemente identice care trebuie împărțite între ei. (A) selectează
mai întâi modul în care se vor distribui cei doi agenți: (A) păstrează ambele articole,
le distribuiee și fiecare persoană primește câte un articol, sau dă ambele articole lui
(B). Apoi, (B) ajunge să respingă alocarea și amândoi nu obțin nimic, sau acceptă
alocarea și amândoi primesc suma alocată.
Forma extinsă a jocului de partajare este prezentată în Fig. 3.17. (A) are 3
strategii. (B) are 8 strategii pure, câte una pentru fiecare combinație de atribuții
la nodurile pe care le controlează. Drept urmare, există 24 de profiluri de
strategie.
Având în vedere un profil de strategie, fiecare nod are o utilitate pentru fiecare
agent. Utilitatea pentru un agent la un nod este definită recursiv de jos în sus:
• utilitatea pentru fiecare agent la un nod final este dată ca parte a nodului;
• utilitatea pentru agentul j al unui nod controlat de agentul i este utilitatea
pentru agentul j al nodului rezultat, care este selectat prin strategia
agentului i.
• utilitatea pentru agentul i pentru un nod controlat de agent, este valoarea
așteptată a utilității pentru agentul i al rezultatelor. Adică, ui (n) = ∑c P (c) ui
(c), unde suma este peste rezultatele c ale nodului n și P (c) este probabilitatea
ca agentul să aleagă rezultatul c.
Exemplu: În jocul de partajare, să presupunem că avem următorul profil de

strategie: (A) alege păstrează și (B) alege (nu), (da), (da) pentru fiecare dintre
nodurile pentru care alege. Sub acest profil de strategie, utilitatea pentru (A) la nodul
intern din stânga este „0”, utilitatea pentru (A) la nodul intern din centru este „1”, iar
utilitatea pentru (A) la cel mai drept nod intern este „0”. Utilitatea pentru (A) la
rădăcină este „0”.
Definiția precedentă a formei extinse a unui joc presupune că agenții pot

observa starea sistemului, concluzionând că starea jocului trebuie să fie pe deplin
observabilă. Într-un joc parțial observabil agenții nu cunosc neapărat starea jocului.
Astfel pentru a modela aceste jocuri într-o formă extinsă, se introduce noțiunea de
„seturi de informații”.
Un „set de informații” este un set de noduri, controlate de același agent și un
set de acțiuni disponibile. Un aspect important este faptul că agentul nu poate
distinge elementele setului de informații, știe doar că starea jocului se află la unul
dintre nodurile setului de informații, nu la acel nod. Într-o strategie, agentul alege o
acțiune pentru fiecare set de informații. Aceeași acțiune se realizează la fiecare nod
din setul de informații. Astfel, într-o formă extinsă, o strategie specifică o funcție de
la „seturi de informații” la „acțiuni”.
Fig. 3.18 Forma extinsă a jocului „piatră-hârtie-foarfecă”.

Exemplu: Fig. 3.18 oferă forma extinsă a jocului rock,paper,scissors.

Elementele setului de informații se află într-un dreptunghi rotunjit. (B) trebuie să
aleagă aceeași acțiune pentru fiecare nod din setul de informații.
3.2.2.3 Rețele decizionale multiagent
Forma extinsă a unui joc poate fi o reprezentare bazată pe stat a unui joc. O
rețea de decizie multiagent este o reprezentare factorizată a unei probleme, este ca o
rețea de decizie, cu excepția faptului că fiecare nod de decizie este etichetat cu un agent
care ajunge să aleagă o valoare pentru nod. Există un nod de utilitate pentru fiecare
agent care specifică utilitatea pentru acel agent. Părinții unui nod de decizie specifică
informațiile care vor fi disponibile agentului atunci când acesta trebuie să acționeze.
Fig. 3.19 Rețea de decizie multiagent pentru exemplul de incendiu.
Exemplu: Fig. 3.19 oferă o rețea de decizie multiagent pentru un exemplu de

pompieri. În acest exemplu, există doi agenți, agentul U1 și agentul U2. Fiecare are
propriul senzor pentru identificarea și anunțarea unui incendiu. Dacă apelează
amândoi este posibil ca apelurile lor să intervină între ele și nici un apel să nu
funcționeze. Agentul U1 alege o valoare pentru variabila de decizie Apelul 1 și poate
observa doar valoarea pentru variabila Alarma 1. Agentul U2 ajunge să aleagă o
valoare pentru variabila de decizie Apelul 2 și poate observa doar valoarea pentru
variabila Alarma 2. Dacă funcționarea apelului depinde de valorile Apelul 1 și
Apelul 2. Dacă vin pompieri depinde dacă funcționează apelul. Utilitatea agentului
U1 depinde dacă a existat un incendiu, dacă vin pompieri și dacă au apelat - în mod
similar pentru Agentul U2. Utilitatea unui agent poate depinde de numărul de alți
agenți care fac unele acțiuni, dar nu de identitățile acestora. Utilitatea unui agent
poate depinde de ceea ce fac câțiva alți agenți, nu direct de acțiunile tuturor celorlalți
agenți.
3.2.3 Strategii de calcul cu informații perfecte
Echivalentul observabilității cu mai mulți agenți poartă numele de informație

perfectă, unde agenții acționează secvențial. Un agent trebuie să acționeze observând
starea lumii înainte de a decide ce să facă. De asemenea, fiecare agent acționează

pentru a-și maximiza propria utilitate.
Un joc de informații perfect poate fi reprezentat ca un joc de formă extins în
care seturile de informații conțin toate un singur nod. Acestea pot fi de asemenea,
reprezentate ca o rețea de decizie multiagent. Nodurile de decizie sunt complet
ordonate și pentru fiecare nod de decizie, părinții acelui nod de decizie includ nodul
de decizie precedent și toți părinții lor.
Jocurile de informații perfecte pot fi rezolvate într-o modalitate similară cu
sistemele cu un singur agent complet observabile. Se realizează folosind o
programare dinamică sau utilizând căutarea. Diferența față de cazul cu un singur
agent este că algoritmul multiagent menține o utilitate pentru fiecare agent și pentru
fiecare mișcare. Varianta de programare dinamică, numită inducție înapoi, urmărește
definiția utilității unui nod pentru fiecare agent.
Fig. 3.20 Un arbore de joc cu sumă zero care indică nodurile ce pot fi tăiate.
Exemplu: Luând în considerare jocul de partajare din Fig. 3.20.

Pentru fiecare dintre nodurile etichetate cu (B), ea ajunge să aleagă valoarea
care îi maximizează utilitatea. Astfel, ea va alege „da” pentru cele două noduri
corecte pe care le controlează și va alege fie pentru cel din stânga nod pe care îl
controlează. Să presupunem că alege „nu” pentru acest nod, atunci (A) ajunge să
aleagă una dintre acțiunile sale:
– „păstrează” are utilitatea „0” pentru el;
– „distribuie” are utilitatea „1”;
– „alocă” are utilitatea „0”, deci alege să share.
În cazul în care sunt doi agenți de concurează, astfel încât să se recompenseze
pozitiv pentru unul dintre aceștia sau să se recompenseze negativ agentul celălalt,
avem un joc cu sumă zero cu doi agenți. Valoarea unui astfel de joc poate fi
caracterizată de un singur număr pe care un agent poate să-și maximizeze, iar agentul
celălalt încearcă să reducă minim. O valoare sau unică pentru un joc cu doi agenții
cu suma zero reduce o minima strategie. Fiecare nod este fie un nod „MAX”, dacă
este controlat de agentul care încearcă maximizarea, fie este un nod „MIN” dacă este
controlat de agentul care încearcă să reducă la minim.
Inducerea înapoi poate fi utilizată pentru o strategie optimă de minimă. De jos

în sus, indusă înapoi se poate maximiza nodurile „MAX” și se pot minimiza nodurile
„MIN”. Inducerea înapoi a fost necesară sau traversează un întreg arbore de joc.
Exemplu: Luând în considerare căutarea în arborele de joc din Fig. 3.20.

În ceea ce privește imaginea, nodurile „MAX” sunt controlate de agentul
maximizant, iar nodurile „MIN” rotunde sunt controlate de agentul de minimizare.
Să presupunem că valorile nodurilor nodurilor finale sunt date sau pot fi calculate.
Numerele din partea de jos arată unele dintre aceste valori, celelalte valori sunt
irelevante. Să presupunem că se realizeză o primă traversare din stânga a primului
arbore.
Valoarea nodului „h” este „7”, deoarece este minimă de „7” și „9”. Doar
considerând cel mai stânga agent al lui „i” cu o valoare de „6”, știm că valoarea lui
„i” este mai mică sau egală cu „6”. Prin urmare, la nodul „d”, agentul maximizator
va merge la stânga. Nu trebuie să evaluăm celălalt agent din „i”. În mod similar,
valoarea lui „0” j este „0” 11, deci valoarea lui „0” e este de cel puțin „0” 11, deci
agentul de minimizare la nodul „0” b va alege să plece la stânga.
Valoarea lui „0” l este mai mică sau egală cu „0” 5, iar valoarea lui „0” m este
mai mică sau egală cu „0” 4; astfel, valoarea lui „0” f este mai mică sau egală cu „0”
5, deci valoarea lui „0” c va fi mai mică sau egală cu „0” 5. Deci, la „0” a, agentul
maximizant va alege să plece la stânga. Observați că acest argument nu depinde de
valorile frunzelor nenumerotate. Mai mult, nu depindea de mărimea subramificație
care nu a fost explorată.
Exemplul anterior a analizat ce poate fi tăiat. MIN/MAX cu tăiere „alfa-beta”

(α-β) este un algoritm de căutare în profunzime care se scufundă prin transmiterea
informațiilor de tăiere în termeni de parametri „α” și „β”. În această căutare în
profunzime, un nod are o valoare „curentă”, care a fost obținută de la unii dintre
descendenții săi. Această poate fi actualizată pe măsură ce primește mai multe
informații despre valoarea celorlalți descendenți ai acesteia.
Parametrul „α” poate fi utilizat pentru a tăia nodurile MIN. Inițial, este cea
mai mare valoare curentă pentru toți strămoșii MAX ai nodului curent. Orice nod
MIN a cărui valoare curentă este mai mică sau egală cu valoarea sa „α” nu trebuie
explorat în continuare. Această întrerupere a fost utilizată pentru a-i putea prona pe
ceilalți descendenți ai nodurilor „l”, „m” și „c” în exemplul precedent.
Dual este parametrul „β”, care poate fi, utilizat pentru a tăia nodurile MAX.
1: Procedure MinimaxAlphaBeta(N,α,β)
2: Inputs
3: N a node in a game tree
4: α,β real numbers
5: Output
6: The value for node N
7: if (N is a leaf node) then

8: return value of N
9: else if (N is a MAX node) then
10: for each child C of N do
11: Set α←max(α,MinimaxAlphaBeta(C,α,β))
12: if (α ≥ β) then
13: return β
14: return α
15: else
16: for each child C of N do
17: Set β←min(β,MinimaxAlphaBeta(C,α,β))
18: if (α ≥ β) then
19: return α
20: return β
3.2.4 Raționamentul multiagentului - parțial observabil
Observabilitatea parțială înseamnă că un agent nu cunoaște starea lumii sau că

agenții acționează simultan, iar pentru cazul multiagent este mai complicată decât
cazul multiagent complet observabil sau cazul cu un singur agent parțial observabil.
Următoarele exemple sublinează câteva probleme importante care apar chiar și în
cazul a doi agenți, fiecare având câteva opțiuni.
Exemplu: Luând în considerare cazul unei lovituri de pedeapsă în fotbal așa

cum este descris în Fig. 3.21. Dacă lovește în dreapta sa și portarul sare la dreapta,
probabilitatea unui gol este de (0.9). Ce ar trebui să facă cel care lovește mingea,
având în vedere că vrea să maximizeze probabilitatea unui gol și că portarul vrea să
minimizeze probabilitatea unui gol?. Ar putea crede că este mai bine să lovească în
dreapta sa, deoarece perechea de numere pentru lovitura sa dreaptă este mai mare
decât perechea din stânga.
jucător
stânga dreapta
stanga 0.6 0.2
portar
dreapta 0.3 0.9
probabilitatea de a înscrie un gol
Fig. 3.21 Lovitură de la fotbal, poate să lovească la stânga sau la dreapta sa. Portarul poate
sări la stânga sau la dreapta.
Portarul ar putea apoi să creadă că, dacă jucătorul va lovi dreapta, atunci ar
trebui să sară la stânga. Dacă cel care lovește mingea crede că portarul va sări la
stânga, atunci ar trebui să dea lovitura stânga. Dar atunci, portarul ar trebui să sară
pe dreapta.
Fiecare agent este potențial confruntat cu o regresie infinită a raționării despre
ceea ce va face celălalt agent. În fiecare etapă în raționamentul lor, agenții își
inversează decizia. Dacă cel care lovește mingea ar cunoaște limita de adâncime a
raționamentului pentru portar, el ar putea exploata această cunoaștere pentru a
determina ce va face cel care lovește mingea și să-și aleagă în mod corespunzător
acțiunea.
Fig. 3.22 Probabilitatea unui obiectiv în funcție de probabilitățile de acțiune.
O alternativă este ca agenții să aleagă acțiuni stocastic (stohastic). Ne putem

imagina că cel care lovește mingea și portarul aruncă fiecare, în secret, o monedă
pentru a decide ce să facă. Atunci ar trebui să ne gândim dacă monedele ar trebui să
fie părtinitoare. Să presupunem că cel care lovește mingea decide să dea lovitura la
dreapta cu probabilitatea pk și că portarul decide să sară la dreapta cu probabilitatea
pj. Probabilitatea unui obiectiv este atunci:
0.9 0.9  p k  pi + 0.3  p k  (1 − pi) + 0.2  (1 − p k )  pi + 0.6  (1 − p k )  (1 − pi )
În Fig. 3.22 se arată probabilitatea unui obiectiv în funcție de pk. Liniile

diferite corespund valorilor diferite ale pj. Există ceva special în ceea ce privește
valoarea p k = 0.4 . La această valoare, probabilitatea unui obiectiv este 0.48,
independent de valoarea pj. Adică, indiferent de ce face portarul, executantul se
așteaptă să obțină un gol cu probabilitatea de 0.48. Dacă executantul se abate de la
p k = 0.4 ar putea face mai bine sau ar putea face mai rău, în funcție de ceea ce face
portarul.
Diagrama pentru pj este similară, toate liniile întâlnindu-se la p j = 0.3 . Din
nou, când p j = 0.3 , probabilitatea unui gol este 0,48. Strategia cu p k = 0.4 și
p j = 0.3 este specială în sensul că nici un agent nu poate merge mai bine prin
abaterea unilaterală de la strategie.
Acest echilibru este sigur pentru un agent, în sensul că, chiar dacă celălalt
agent a cunoscut strategia agentului, celălalt agent nu poate forța un rezultat mai rău
pentru agent. Această strategie înseamnă că un agent nu trebuie să se preocupe de
ghicirea dublă a celuilalt agent. El va obține cel mai bun profit pe care îl poate
garanta pentru a obține. Să extindem acum definiția unei strategii pentru a include
strategii randomizate.
Luând în considerare forma normală a unui joc în care fiecare agent ajunge să
aleagă o acțiune simultan. Fiecare agent alege o acțiune fără să știe ce aleg ceilalți
agenți.
O strategie pentru un agent este distribuirea probabilității peste acțiunile
pentru acest agent:
• dacă agentul acționează determinist, una dintre probabilități va fi „1”, iar
restul va fi „0” - aceasta este numită strategie pură;
• dacă agentul nu urmărește o strategie pură, nici una dintre probabilități nu
va fi „1” și mai multe acțiuni vor avea o probabilitate nulă - aceasta se
numește strategie stocastică.
Ansamblul de acțiuni cu o probabilitate diferită de zero într-o strategie se
numește set de suport al strategiei.
Un profil de strategie este o alocare a unei strategii fiecărui agent. Dacă σ este
un profil de strategie, să fie „σi” strategia de agent „i” în „σ” și să fie „σ-i” strategiile
celorlalți agenți. Atunci „σ” este ( i   −i) . Dacă profilul strategiei este format din
strategii pure, este adesea numit profil de acțiune, deoarece fiecare agent joacă o
anumită acțiune.
Un profil de strategie „σ” are o utilitate pentru fiecare agent. Fie utilitatea (σ,
i) utilitatea profilului de strategie „σ” pentru agentul „i”. Utilitatea unui profil de
strategie stocastică poate fi calculată prin calcularea utilității preconizate, având în
vedere utilitățile acțiunilor de bază care alcătuiesc profilul și probabilitățile
acțiunilor.
Un cel mai bun răspuns pentru un agent „i” la strategiile „σ-i” ale celorlalți
agenți este o strategie care are utilitate maximă pentru acel agent. Adică, „σ-i” este
cel mai bun răspuns la σ-i dacă, pentru toate celelalte strategii σi pentru agentul i,
utility ( i   −i , i )  utility ( i   −i , i )
Exemplu: Să presupunem că există o resursă pe care doi agenți ar putea dori

să o combată. Fiecare agent poate alege să acționeze ca un șoim sau ca un porumbel.
Să presupunem că resursa valorează unități R, unde R>0. Dacă ambii agenți
acționează ca porumbeii, aceștia împărtășesc resursa. Dacă un agent acționează ca
un șoim, iar celălalt ca un porumbel, agentul șoim primește resursa, iar agentul
porumbel nu primește nimic. Dacă ambii acționează ca șoimii, există distrugerea
resursei, iar răsplata pentru ambele este -D, unde D> 0. Aceasta poate fi descrisă de
următoarea matrice de plată.
Agent 2
porumbel șoim
porumbel R/2,R/2 0,R
Agent 1
șoim R,0 -D,-D
În această matrice, „agentul 1” ajunge să aleagă rândul, „agentul 2” ajunge să

aleagă coloana, iar rambursarea din celulă este o pereche constând din recompensa
către „agentul 1” și recompensa către „agentul 2”, iar fiecare agent încearcă să-și
maximizeze răsplata proprie.
În acest joc există trei echilibre Nash:
• „agentul 1” acționează ca șoim și „agentul 2” ca porumbel:
o „agentul 1” nu dorește să se abată, deoarece atunci trebuie să partajeze
resursa;
o „agentul 2” nu vrea să se abată, deoarece atunci există distrugere.
• „agentul 1” acționează ca un porumbel și „agentul 2” ca un șoim.
• ambii agenți acționează stocastic: în acest echilibru, există o șansă de
distrugere, probabilitatea de a acționa ca un șoim crește cu valoarea „R” a resursei și
scade pe măsură ce valoarea „D” de distrugere crește.
În acest exemplu, fiecare agent face anumite posturi pentru a indica ce va face
pentru a încerca să forțeze un echilibru care îi este avantajos. A avea mai multe
echilibre „Nash” nu provine din a fi adversari, după cum arată exemplul următor.
Exemplu: Să presupunem că există două persoane care vor să fie împreună.

„Agentul 1” preferă să meargă amândoi la jocul de fotbal, iar „agentul 2” preferă să
plece la cumpărături. Amândoi ar fi nefericiți dacă nu sunt împreună. Să presupunem
că amândoi trebuie să aleagă simultan ce activitate să facă. Aceasta poate fi descrisă
de următoarea matrice de rambursare:
Agent 2
fotbal cumpărături
fotbal 2,1 0,0
Agent 1
cumpărături 0,0 1,2
În această matrice, „agentul 1” alege rândul, iar „agentul 2” alege coloana.

În acest joc, există trei echilibre Nash:
Un echilibru este acela în care merg amândoi la cumpărături, unul este acela
unde merg amândoi la jocul de fotbal și unul este o strategie randomizată.
Aceasta este o problemă de coordonare. Cunoașterea setului de echilibre nu
spune de fapt niciunui agent ce trebuie să facă, deoarece ceea ce ar trebui să facă un
agent depinde de ceea ce va face celălalt agent. În acest exemplu, vă puteți imagina
conversații pentru a determina ce echilibru ar alege.
Chiar și atunci când există un echilibru unic Nash, acel echilibru Nash nu
garantează plata maximă pentru fiecare agent. Următorul exemplu este o variantă a
ceea ce este cunoscut sub numele de dilema prizonierului.
Exemplu: Ne imaginăm ca ne aflăm într-o emisiune de joc cu un străin pe

care nu îl vei mai vedea niciodată. Fiecare dintre ele ai de ales luând 100 USD pentru
tine sau oferind 1.000 de dolari celeilalte persoane. Aceasta poate fi descrisă ca
următoarea matrice de plată:
jucător 2
a primi a da
a primi 100,100 1100,0
jucător 1
a da 0,1100 1000,1000
Indiferent ce face celălalt agent, fiecare agent este mai bun dacă ia mai degrabă
decât să dea. Cu toate acestea, ambii agenți sunt mai buni dacă dau amândoi mai
degrabă decât dacă iau amândoi.
Astfel, există un echilibru Nash unic, în care ambii agenți iau. Acest profil de
strategie are ca rezultat că fiecare jucător primește 100 USD. Profilul de strategie în
care ambii jucători dau rezultate la fiecare jucător care primește 1.000 $.
Există un număr mare de cercetări cu privire la dilema prizonierului, deoarece
nu pare să fie atât de rațional să fie lacom, în care fiecare agent încearcă să facă tot
posibilul pentru sine, rezultând că toată lumea este înrăutățită. Un caz în care
acordarea devine preferată este atunci când jocul este jucat de mai multe ori. Aceasta
este cunoscută sub numele de dilema secvențială a prizonierului. O strategie pentru
dilema secvențială a prizonierului este tit-for-tat15 (represalii echivalente):
• fiecare jucător dă inițial, apoi acțiunea anterioară a celuilalt agent la fiecare
pas.
Această strategie este un echilibru Nash atâta timp cât nu există o ultimă
acțiune despre care ambii jucători știu.
Având un echilibru Nash multiplu, nu numai că rezultă din observarea
parțială. Este chiar posibil să existe mai multe tipuri de echilibru cu un joc de
15
https://dictionary.cambridge.org/dictionary/english/tit-for-tat
informații perfecte și este chiar posibil să existe infinit de multe tipuri de echilibru
Nash, după cum arată exemplul următor.
Exemplu: Luând în considerare jocul de partajare. În acest joc există infinit

de multe echilibre Nash. Există un set de echilibre în care (A) pune la dispoziție, iar
(B) spune „da” pentru a partaja pentru alegerea de centru și poate randomiza între
celelalte alegeri, atât timp cât probabilitatea de a spune „da” în alegerea din stânga
este mai mică decât egală cu „0,5”.
În aceste tipuri de echilibru Nash, ambii obțin „1”. Există un alt set de tipuri
de echilibru Nash în care (A) păstrează, iar (B) randomizează printre alegerile sale,
astfel încât probabilitatea de a spune da în ramura stângă este mai mare sau egală cu
„0,5”. În aceste tipuri de echilibru, (B) primește „0”, iar (A) obține o anumită valoare
în intervalul [1,2] în funcție de probabilitatea lui (B). Există un al treilea set de tipuri
de echilibru Nash, unde (B) are o probabilitate de „0,5” de a selecta „da” în nodul
cel mai din stânga, selectează da la nodul central și (A) randomizează între a păstra
și a împărtăși cu orice probabilitate.
Să presupunem că jocul de partajare a fost modificat ușor, astfel încât, (A) a
oferit un mic mită pentru (B) să spună „da”. Acest lucru se poate realiza modificând
valoarea „2,0” la (1,9,0,1). (A) s-ar putea gândi, „Având în vedere alegerea între 0,1
și 0, (B) va alege 0,1, așa că ar trebui să păstrez”. Dar (B) s-ar putea gândi: „Ar
trebui să spun nu la 0.1, pentru ca Andy să se împărtășească și eu primim 1”. În
acest exemplu există mai multe tipuri de echilibru Nash pur, una în care (A)
păstrează, iar (B) spune că da în ramura din stânga. În acest echilibru, (A) obține 1,9,
iar (B) primește „0,1”. Există un alt echilibru Nash în care (B) spune că nu la cel mai
stânga nod de alegere și da la sucursala centrală, iar (A) alege distribuire. În acest
echilibru, amândoi obțin „1”. S-ar părea că acesta este cel preferat de (B). Cu toate
acestea, (A) ar putea crede că (B) face o amenințare goală. Dacă de fapt ar fi decis
să păstreze, (B), acționând pentru a-și maximiza utilitatea, nu ar spune „nu”.
Algoritmul de inducție înapoi găsește doar unul dintre echilibre în jocul de
partajare modificat. Calculează un echilibru perfect subgame, unde se presupune că
agenții aleg acțiunea cu cea mai mare utilitate pentru ei la fiecare nod în care ajung
să aleagă. Se presupune că agenții nu efectuează amenințări pe care nu le interesează
să le efectueze la momentul respectiv. În jocul de partajare modificat din exemplul
precedent, se presupune că (B) va spune „da”. Cu toate acestea, atunci când avem
de-a face cu oponenți reali, trebuie să fim atenți dacă vor face față amenințărilor pe
care poate nu le considerăm raționale.
3.2.4.1 Calcularea echilibrului Nash
Pentru a calcula un echilibru Nash pentru un joc în formă strategică, există trei
pași:
• eliminarea strategiilor dominate;
• determinarea unor acțiuni care vor avea probabilități nule, care se numește
set de suport;
• determinarea probabilității acțiunilor din setul de suport a fost dovedită ca a

doua dintre acestea, fiind cea mai dificilă.
3.2.4.1.1 Eliminarea strategiilor dominante
O strategie s1 pentru un agent (A) domină strategia s2 pentru (A) dacă, pentru
fiecare acțiune a celorlalți agenți, utilitatea s1 pentru agentul (A) este mai mare decât
utilitatea s2 pentru agent (A). Orice strategie pură dominată de o altă strategie poate
fi eliminată din considerație. Strategia dominantă poate fi o strategie randomizată.
Acest lucru se poate face în mod repetat.
Exemplu: Luând în considerare următoarea matrice de rambursare, unde

primul agent alege rândul și al doilea agent alege coloana. În fiecare celulă există o
pereche de rambursări: plata pentru agentul 1 și plata pentru agentul 2. Agentul 1 are
acțiuni {a1, b1, c1}. Agentul 2 are posibile acțiuni {d2, e2, f2}.
agent 2
d2 e2 f2
a1 3,5 5,1 1,2
agent 1 b1 1,1 2,9 6,4
c1 2,6 4,7 0,8
Acțiunea c1 poate fi eliminată, deoarece este dominată de acțiunea a1:

• agentul 1 nu va face niciodată c1, dacă acțiunea a1 este disponibilă pentru
aceasta;
• rambursarea pentru agentul 1 este mai mare cu a1 decât cu c1, indiferent de
ce face celălalt agent.
Odată ce acțiunea c1 este eliminată, acțiunea f2 poate fi eliminată, deoarece
este dominată de strategia randomizată 0,5  d 2 + 0,5  e2 .
Odată ce c1 și f2 au fost eliminate, b1 este dominat de a1 și astfel agentul 1 va
face acțiunea a1. Având în vedere că agentul 1 va face a1, agentul 2 va face d2. Astfel,
plata în acest joc va fi 3 pentru agentul 1 și 5 pentru agentul 2.
Strategia s1 domină strict strategia s2 pentru agentul i dacă, pentru toate
profilurile de acțiune σ-i ale celorlalți agenți:
utility ( s1   −i , i ) >utility ( s2   −i , i )
Este clar că, dacă s2 este o strategie pură, care este strict dominată de o
strategie s1, atunci s2 nu poate fi niciodată în setul de sprijin al echilibrului Nash.
Acest lucru este valabil chiar dacă s1 este o strategie stocastică. Eliminarea repetată
a strategiilor strict dominate dă același rezultat, indiferent de ordinea în care
strategiile strict dominate sunt eliminate.
Există, de asemenea, noțiuni de dominație mai slabe, în care simbolul „>” în

formula precedentă este înlocuit cu „”. Dacă se folosește noțiunea mai slabă de
dominație, există întotdeauna un echilibru Nash. Unele echilibre Nash pot fi
pierdute. Mai mult, echilibrele care se pierd pot depinde de ordinea în care strategiile
dominate sunt eliminate.
3.2.4.1.2 Calcularea strategiilor aleatorii
Ne utem folosi faptul că un agent va avea un caracter aleator între acțiuni, doar
dacă toate acțiunile au aceeași utilitate pentru agent (având în vedere strategiile
celuilalt agent). Aceasta formează un set de constrângeri care pot fi rezolvate pentru
a oferi un echilibru Nash. Dacă aceste constrângeri pot fi rezolvate cu numere în
intervalul (0,1) și strategiile mixte calculate pentru fiecare agent nu sunt dominate
de o altă strategie pentru agent, atunci acest profil16 de strategie este un echilibru
Nash. După ce strategiile dominate au fost eliminate, putem căuta peste seturi de
suport pentru a determina dacă seturile de suport formează un echilibru Nash. Dacă
există „n” acțiuni disponibile pentru un agent, există „2n-1” subseturi care nu sunt
goale și trebuie să căutăm combinații de seturi de asistență pentru diverși agenți.
Acest lucru este posibil, doar în cazul în care există puține acțiuni care nu sunt
dominate sau există echilibre Nash cu mici seturi de sprijin. Pentru a găsi echilibrul
simplu (în ceea ce privește numărul de acțiuni din setul de suport), putem căuta de
la seturi de asistență mai mici la seturi mai mari.
Presupunem că agentul i este aleator între acțiunile (a ,..., a ) , într-un
1
i
ki
i
j
echilibru Nash. Fie pi probabilitatea ca agentul să facă acțiunea ai . Fie
j
 − i ( p − i1 )
strategiile pentru ceilalți agenți, în funcție de probabilitățile lor. Faptul că acesta este

ki
un echilibru Nash dă următoarele constrângeri: pij  0, j =1
pij = 1 și pentru
oricare ar fi j , j  vom avea:
utility (aij   −i ( pi ) , i ) =utility (aij   −i ( pi ) , i ) .
Dacă utilitatea (utility) ai  a de a face o acțiune în afara setului de suport,

j
 
atunci, pentru () a  ai ,..., ai i , vom avea:
1 k
utility (aij   −i ( pi ) , i )  utility (a   −i ( pi ) , i ) .
16
Un set de suport este un set de strategii pure care au probabilitate diferită de zero într-un
echilibru Nash.
Exemplu: Într-unul din exemplele anterioare, sa presupus că portarul sare în

partea dreaptă cu probabilitatea pj și executantul lovește în partea dreapta cu
probabilitatea pk. Dacă portarul sare în partea dreaptă, probabilitatea de a primi un
gol este:
0.9  pk + 0.2  (1 − pk ) .
Dacă portarul sare în partea stângă, probabilitatea de a primi un gol este:
0.3  pk + 0.6  (1 − pk ) .
Singura dată când portarul ar sări aleator se întâmplă dacă cele două
probabilități sunt egale, adică dacă:
0.9  pk + 0.2  (1 − pk ) = 0.3  pk + 0.6  (1 − pk ) .

Rezolvarea pentru ecuației de mai sus în funcție de pk conduce la următoarea
valoare: pk = 0,4. În mod similar, pentru ca executantul să șuteze aleator conduce la
ideea că probabilitatea de a da gol trebuie să fie aceeași, indiferent dacă acesta
șutează în partea stângă sau dreaptă:
0.2  p j + 0.6  (1 − p j ) = 0.9  p j + 0.3  (1 − p j ) .

Rezolvarea pentru ecuației de mai sus în funcție de pj conduce la următoarea
valoare: pj = 0,3.
Astfel, singurul echilibru Nash se întâmplă pentru:
 pk = 0.4
p j = 0.3 .
3.2.4.2 Învățarea coordonării
Datorită existenței mai multor echilibre, în multe cazuri nu este clar ce ar

trebui să facă de fapt un agent, chiar dacă cunoaște toate rezultatele jocului și
utilitățile agenților. Cele mai multe întâlniri strategice reale sunt mult mai dificile
deoarece agenții nu cunosc rezultatele sau utilitățile celorlalți agenți.
O alternativă la rațiunile strategice profunde implicate de calcularea
echilibrului Nash este încercarea de a învăța ce acțiuni trebuie efectuate.
Vom prezenta în continuare un algoritm simplu care poate fi utilizat pentru a
îmbunătăți iterativ politica unui agent [17]. Se presupune că:
• agenții joacă în mod repetat același joc și învață cum să obțină rezultate cât
mai bune;
• fiecare agent joacă întotdeauna o strategie mixtă, adică, agentul actualizează

probabilitățile acțiunilor pe baza profiturilor obținute.
Putem simplifica, considerând o singură stare și anume faptul că singurul lucru
care se schimbă între timp îl reprezintă politicile de acționare aleatorie ale celorlalți
agenți.
1: Procedure PolicyImprovement(A,α,δ)
2: Inputs
3: A a set of actions
4: α step size for action estimate
5: δ step size for probability change
6: Local
7: n the number of elements of A
8: P[A] a probability distribution over A
9: Q[A] an estimate of the value of doing A
10: a_best the current best action
11:
12: n ←|A|
13: P[A] assigned randomly such that P[a]>0 and ∑a∈AP[a]=1
14: Q[a] ←0 for each a∈A
15: repeat
16: select action a based on distribution P
17: do a
18: observe payoff
19: Q[a]←Q[a]+ α(payoff-Q[a])
20: a_best ←argmax(Q)
21: P[a_best]←P[a_best]+n×δ
22: for each a'∈A do
23: P[a']←P[a']-δ
24: if (P[a']<0) then
25: P[a_best]←P[a_best]+P[a']
26: P[a']←0
27:
28:
29: until termination
Algoritmul PolicyImprovement prezentat mai sus oferă un controler pentru un

agent de învățare. Își menține politica curentă stocastică în tabloul P și o estimare a
profitului pentru fiecare acțiune din Q array. Agentul desfășoară o acțiune bazată pe
politica sa actuală și observă rambursarea acțiunii. Acesta își actualizează apoi
estimarea valorii acțiunii respective și își modifică strategia actuală prin creșterea
probabilității celei mai bune acțiuni a acesteia.
În acest algoritm, n este numărul de acțiuni. În primul rând, inițializează P la
întâmplare, astfel încât să fie o distribuție a probabilităților; Q este inițializat în mod
arbitrar la zero.
În fiecare etapă, agentul alege o acțiune „a” bazată pe distribuția curentă P. El

desfășoară acțiunea „a” și observă rambursarea pe care o primește. Apoi, își
actualizează estimarea de rambursare de la „a”. Efectuează o diminuare a
gradientului de învățare „α” pentru a reduce la minimum eroarea în estimarea sa de
recuperare a acțiunii „a”. Dacă rambursarea este mai mare decât estimarea
anterioară, aceasta își mărește estimarea proporțional cu eroarea. Dacă rambursarea
este mai mică decât estimarea sa, aceasta își reduce estimarea.
Apoi calculează „a_best”, care este cea mai bună acțiune curentă în funcție de
valorile sale Q-estimate. Dacă presupunem că există mai mult de o acțiune cea mai
bună, una este aleasă la întâmplare pentru „a_best”. Crește probabilitatea celei mai
bune acțiuni cu (n − 1)   și reduce probabilitatea celorlalte acțiuni cu δ. Condiția if
.... de pe linia 24 este acolo pentru a se asigura că probabilitățile nu sunt negative și
se ridică la 1.
Chiar și atunci când P are o acțiune cu probabilitatea „0”, este utilă această
acțiune pentru a putea actualiza valoarea curentă. În următoarele exemple, se
presupune că agentul alege o acțiune aleatorie cu probabilitate 0.05 la fiecare etapă
și altfel alege fiecare acțiune în funcție de probabilitatea acțiunii respective în P.
Fig. 3.23 Învățarea pentru exemplul de coordonare fotbal-cumpărături.

Exemplu: În Fig. 3.23 se prezintă o diagramă a algoritmului de învățare.

Valorile din grafic descriu probabilitățile relative pentru agentul 1 care alege fotbalul
și agentul 2 care alege cumpărăturile pentru 7 runde ale algoritmului de învățare.
Fiecare linie reprezintă o singură rulare. Fiecare dintre rulaje se termină în colțul din
stânga sus sau din colțul din dreapta jos. În aceste rulaje, politicile sunt inițializate
aleatoriu, α = 0.1 și δ = 0.01.
Dacă ceilalți agenți joacă o strategie fixă, acest algoritm converge la cel mai
bun răspuns pentru această strategie.
Exemplu: În Fig. 3.24 avem o reprezentare grafică a doi jucători care

utilizează algoritmul de învățare pentru exemplul în care este descris modulde calcul
al probabilității portar/jucător. Această cifră descrie probabilitățile relative pentru ca
portarul să sară spre dreapta și jucătorul să lovească minge spre stânga, pentru o
rulare a algoritmului de învățare. În această execuție, α = 0,1 și δ = 0,001. Algoritmul
de învățare circulă în jurul stării de echilibru, fără a ajunge vreodată la echilibru.
Luăm în considerare jocul competitiv cu doi agenți, unde există doar un

echilibru aleator de tip Nash. Dacă un agent A joacă un alt agent, B, în paradigma
unui echilibru Nash, atunic nu contează ce acțiune în setul său de suport este efectuat
de agentul A, deoarece toate au aceeași valoare pentru A. Astfel, agentul A va tinde
să piardă echilibrul. Atunci când A se abate de la strategia de echilibru, cel mai bun
răspuns pentru agentul B este să joace cu determinare. Acest algoritm, atunci când
este utilizat de agentul B în cele din urmă, ne permite să observăm că A s-a abătut de
la echilibru și agentul B își schimbă starea.
Fig. 3.24 Învățarea exemplului loviturii de pedeapsă din fotbal.

De asemenea, agentul B se va abate de la echilibru. Atunci agentul A poate
încerca să exploateze această abatere. Când ambii agenți utilizează acest controler,
abaterea fiecărui agent poate fi exploatată, întrucât tind să se învârte în jurul unei
valori. Nu există nimic în acest algoritm care să mențină agenții într-un echilibru
aleator. O modalitate de a încerca ca agenții să nu se rătăcească prea departe de un
echilibru este să se adopte o strategie de tipul WoLF „câștigă sau să învață rapid”
(win or learn fast): când agentul câștigă, face pași mici (δ este mic), iar când agentul
pierde, este nevoie de trepte mai mari (δ este crescut). În timp ce câștigă, tinde să
rămână cu aceeași politică și, în timp ce ea pierde, încearcă să treacă rapid la o
politică mai bună. Pentru a defini câștigul, o strategie simplă este ca un agent să vadă
dacă merge mai bine decât valoarea medie pe care a primit-o până acum.
Nu există o strategie perfectă de învățare. Dacă un agent care se opune știa
strategia exactă, agentul A folosea și ar putea prezice ce va face agentul A, ar putea
exploata această cunoaștere.
3.2.5 Luarea deciziilor în grup
Adesea, grupuri de oameni trebuie să ia decizii cu privire la ceea ce va face

grupul. Societățile sunt exemplul clasic, în care votul este folosit pentru a stabili ce
vrea grupul. Poate părea că votarea este o modalitate bună de a determina ce dorește
un grup și, atunci când există o alegere clară, cea mai preferată. Cu toate acestea,
există probleme majore cu votarea atunci când nu există o alegere preferată clară,
așa cum se arată în exemplul următor.
Exemplu: Luând în considerare un agent de achiziții care trebuie să decidă

asupra unei destinații de vacanță pentru un grup de oameni, pe baza preferințelor lor.
Să presupunem că există trei persoane, A, B și C și trei destinații X, Y și Z. Să
presupunem că agenții au următoarele preferințe, unde simbolul „>” reprezintă
preferința strictă:
A : X  Y  Z

B : Y    X
C : Z  X  Y

Având în vedere aceste preferințe, într-un vot în pereche, X  Y pentru că
doi din cei trei preferă X pe Y. În mod similar, la vot, Y  Z și Z  X . Astfel,
preferințele obținute prin vot nu sunt tranzitive. Acest exemplu este cunoscut sub
numele de paradoxul Condorcet17.
Într-adevăr, nu este clar care ar trebui să fie rezultatul grupului în acest caz,
deoarece este simetric între rezultate.
17
https://www.oxfordreference.com/view/10.1093/oi/authority.20110803095631211
O funcție, de preferință socială [17], oferă o relație de preferințe pentru un

grup. Însă o funcție, de preferință socială, trebuie să depindă de preferințele
indivizilor din grup. Se poate părea că paradoxul Condorcet este o problemă cu votul
în perechi, cu toate acestea, următorul rezultat arată că astfel de paradoxuri apar cu
orice funcție de preferință socială.
Propoziție18: Teorema imposibilității săgeții19 - dacă există trei sau mai multe
rezultate, următoarele proprietăți nu pot conține simultan nici o funcție de preferință
socială:
• funcția preferinței sociale este completă și tranzitivă;
• fiecare preferință individuală completă și tranzitivă este permisă;
• dacă fiecare element preferă rezultatul o1 sau o2, grupul preferă o1 până la o2;
• preferința grupului dintre rezultatele o1 și o2 depinde doar de preferințele
individuale de la o1 și o2 și nu de preferințele indivizilor față de alte rezultate;
• nimeni nu ajunge să decidă unilateral rezultatul (nictictia).
Atunci când construim un agent care ia preferințele individuale și conferă o
preferință socială, trebuie să fim conștienți că nu putem avea toate aceste proprietăți
intuitive și dezirabile. În loc să acorde o preferință de grup care să aibă proprietăți
nedorite, poate fi mai bine să indice persoanelor cum preferințele lor nu pot fi
reconciliate.
3.2.6 Proiectarea mecanismului
Discuțiile anterioare despre agenții care aleg acțiunile lor au presupus că fiecare
agent trebuie să joace într-un joc predefinit. Problema proiectării mecanismului este
de a realiza un joc cu proprietăți dezirabile pentru diferiți agenți, în vederea participării
la jocul respectiv.
Un mecanism specifică acțiunile disponibile pentru fiecare agent și distribuția
rezultatelor fiecărui profil de acțiune. Presupunem că agenții au utilități peste rezultate.
Există două proprietăți comune care sunt de dorit pentru un mecanism:
• un mecanism ar trebui să fie ușor de utilizat pentru agenți. Având în vedere
utilitatea unui agent, ar trebui să fie ușor pentru agent să determine ce să facă;
• un mecanism ar trebui să ofere cel mai bun rezultat agregat asupra tuturor
agenților. Un exemplu este un mecanism eficient din punct de vedere economic
dacă rezultatul ales este unul care maximizează suma utilităților agenților.
Exemplu: În cazul unui planificator de ședințe, utilizatorii trebuie să introducă

orele disponibile și programatorul va alege un timp pentru întâlnire:
18
https://ro.scribd.com/doc/224188250/7-8-No%C5%A3iunea-de-Propozi%C5%A3ie-
Matematic%C4%83-Axiom%C4%83-Teorem%C4%83-Condi%C5%A3ii-Necesare-
%C5%9Ei-Suficiente-Metoda-Reducerii-La-Absurd
19
https://math.hmc.edu/funfacts/arrows-impossibility-theorem/
• un mecanism presupune ca utilizatorii să precizeze când sunt disponibili

sau nu, iar programatorul să selecteze ora la care cea mai mare parte a
persoanelor sunt disponibile;
• un al doilea mecanism este ca utilizatorii să-și specifice utilitatea pentru
diferitele ore, iar programatorul alege timpul care maximizează suma
utilităților. Niciunul dintre aceste mecanisme nu este veridic cu strategia
dominantă.
Pentru primul mecanism, utilizatorii pot declara că sunt indisponibili la un
moment dat pentru a forța un timp pe care îl preferă. Nu este clar că a fi disponibil
la un moment dat este bine definit; la un moment dat, utilizatorii trebuie să decidă
dacă este mai ușor să planificați ceea ce altfel ar fi făcut la un moment dat. Diferite
persoane pot avea praguri diferite în ceea ce privește ce alte activități pot fi mutate.
Pentru al doilea mecanism, să presupunem că există trei persoane, A, B și C,
trebuie să decidă dacă se vor întâlni luni, marți sau miercuri. Să presupunem că au
următoarele utilități pentru zilele de întâlnire:
Luni Marți Miercuri

A 0 8 10
B 3 4 0
C 11 7 6
Rezultatul eficient din punct de vedere economic este să se întâlnească marți.

Cu toate acestea, dacă A ar schimba evaluarea de marți pentru a fi 2, mecanismul
ales trebuie să fie miercuri. Astfel, A are un stimulent să-și prezinte greșit valorile.
Nu este în interesul lui A să fim sinceri.
Astfel, dacă există un mecanism care are strategii dominante, va exista
neapărat un mecanism care să reprezinte strategia dominantă. Acesta este cunoscut
sub numele de „principiul revelației” [18]. Pentru a implementa un mecanism veridic
de strategie dominantă, putem, în principiu, scrie un program care acceptă de la un
agent preferințele sale reale și oferă mecanismului inițial inputul optim pentru acel
agent. În esență, acest program poate fi optim pentru agent.
Se dovedește că este esențial imposibil să proiectăm un mecanism rezonabil care
să fie dominant din punct de vedere al unei strategii veridice. Atâta timp cât există trei
sau mai multe rezultate care pot fi alese, singurele mecanisme cu strategii dominante
au un element care va dicta/impune o cale de urmat: există un agent ale cărui preferințe
determină rezultatul. Aceasta este teorema Gibbard-Satterthwaite [19].
O modalitate de a obține mecanisme veridice cu strategie dominantă este
introducerea banilor. Presupunem că banii pot fi adăugați la utilitate, astfel încât,
pentru orice două rezultate o1 și o2, pentru fiecare agent există o anumită cantitate
astfel încât agentul să fie indiferent între rezultatele o1 și o2 + d. Dacă permitem unui
agent să fie plătit să accepte un rezultat pe care altfel nu l-ar prefera, sau să plătească
pentru un rezultat pe care și-l doresc, putem asigura că agentul nu câștigă mințind.
Într-un mecanism VCG sau un mecanism Vickrey-Clarke-Groves [20], agenții
ajung să își declare valorile pentru fiecare dintre rezultatele obținute. Se alege
rezultatul care maximizează suma valorilor declarate. Agenții plătesc în funcție de

cât afectează participarea lor la rezultat. Agentul plătește suma valorii pentru ceilalți
agenți pentru rezultatul ales minus suma valorilor celorlalți agenți dacă nu am
participat. Mecanismul VCG este atât eficient, cât și eficient, din punct de vedere al
strategiei dominante, presupunând că agenților le pasă doar de utilitatea lor și nu de
utilitățile altor agenți sau de plățile altor agenți.
Exemplu: Să presupunem că valorile date sunt asociate unor valori financaire

în dolari. A este indiferentă între întâlnirea de luni sau întâlnirea de marți și plata
unei sume 8,00 USD (este pregătită să plătească 7,99 USD pentru a muta întâlnirea
de luni până marți, dar nu 8,01 USD). Având în vedere aceste valori declarate, marți
este aleasă ca zi a ședinței. Dacă A nu ar fi participat, ziua de luni ar fi fost aleasă și
astfel ceilalți agenți ar înregistra pierderi nete de 3, caz în care A trebuie să plătească
3,00 USD. Valoarea netă pentru ea este atunci 5, utilitatea de 8 pentru marți minus
plata de 3. Declarațiile, plățile și valorile nete sunt prezentate în următorul tabel:
Valoarea
Luni Marți Miercuri Plata
netă
A 0 8 10 3 5
B 3 4 0 1 3
C 11 7 6 0 7
Total 14 19 16
Luând în considerare ce s-ar întâmpla dacă A și-ar fi schimbat evaluarea de

marți la 2. În acest caz, miercuri ar fi ziua aleasă, dar A ar fi trebuit să plătească 8,00
USD, cu o valoare nouă de 2 și astfel ar fi mai rău. A nu poate câștiga un avantaj
păcălind mecanismul.
Un mecanism comun de vânzare a unui articol sau a unui set de articole este
licitația. Un tip comun de licitație pentru vânzarea unui singur articol este o licitație
ascendentă, unde există un preț de ofertă curent pentru articolul care crește cu o
creștere predeterminată atunci când prețul de ofertă anterior a fost îndeplinit. Oferta
de a cumpăra articolul la prețul curent se numește ofertă. O singură persoană poate
depune o ofertă pentru un anumit preț. Articolul se adresează persoanei care a depus
cea mai mare ofertă, iar persoana plătește suma acelei oferte.
Luând în considerare un mecanism VCG pentru vânzarea unui singur articol.
Presupunem că există o serie de agenți care au depus fiecare o ofertă pentru cât
valorează un articol. Rezultatul care maximizează rambursările este de a oferi
articolul persoanei care a avut cea mai mare ofertă. Dacă nu ar fi participat, articolul
ar fi trecut de la cel mai mare ofertant la al doilea. Prin urmare, în conformitate cu
mecanismul VCG, cel mai bun ofertant ar trebui să obțină articolul și să plătească
valoarea celei de-a doua cele mai mari oferte. Aceasta este cunoscută sub numele de
licitație cu al doilea preț SPA (second-price auction). Cea de-a doua licitație de preț
este echivalentă pentru a avea o licitație ascendentă, unde oamenii utilizează o ofertă
proxy și există un agent pentru a converti oferta proxy în oferte reale. Licitarea într-
o licitație cu SPA este simplă, deoarece agenții nu trebuie să facă raționamente

strategice complexe. De asemenea, este ușor să fie determinat un câștigător și plata
corespunzătoare.
Anexa 3.1 – Tehnici de Inteligență Artificială
Problemele de inteligență artificială20 fac parte din diverse domenii si par sa

nu aiba in comun alta caracteristica decit aceea ca sunt dificil de rezolvat. Exista insa
tehnici specifice rezolvarii problemelor in inteligență artificială. Cum se pot
caracteriza aceste tehnici si cum se poate decide dacă aceste tehnici pot fi utilizate si
in rezolvarea unor probleme care nu sunt considerate a fi probleme de inteligență
artificială?
Asa cum s-a discutat in sectiunile anterioare, rezultatul cel mai important al
cercetarilor de inteligență artificială din ultimele decenii este punerea in evidenta a
rolului fundamental al cunostintelor intr-un sistem inteligent. Caracteristicile
cunostintelor impun necesitatea gasirii unor modalitati adecvate de reprezentare si
prelucrare a cunostintelor in sistem. Textul de fata are ca scop tocmai prezentarea
acestor modalitati de prelucrare a cunostintelor si raspunsul la intrebarea de mai sus.
In aceasta sectiune insa, se discuta trei rezolvari ale unei probleme, rezolvarile fiind
prezentate in ordine crescatoare a urmatoarelor caracteristici:
• generalitate
• claritatea exprimarii cunostintelor
• extensibilitatea abordarii.
In acest mod, cea de a treia rezolvare ajunge sa devina ceea ce se intelege de
obicei printr-o tehnica de rezolvare a problemelor in inteligență artificială si
reprezinta pentru cititor primul pas de atac al domeniului.
Se considera urmatorul joc, cunoscut sub numele de "Tic-Tac-Toe": pe o tabla
de trei linii si trei coloane, care conține deci noua patrate, doi jucatori pot plasa X
sau O. Cistiga jucatorul care reuseste sa formeze o secventa de trei simboluri (X,
respectiv O) pe orizontala, verticala sau diagonala. Se cere sa se construiasca schema
unui program care sa simuleze acest joc, program care sa poata juca pe postul
jucatorului X sau pe postul jucatorului O si, evident, care sa incerce sa cistige jocul.
Cele trei rezolvari ale problemei sunt descrise in termenii reprezentarii
universului problemei si ai algoritmului utilizat.
Rezolvarea 1
Se folosesc următoarele structuri de date:
• Tabla este un vector de 9 elemente care reprezintă tabla de joc, tabla fiind
liniarizată pe linii. Valorile elementelor acestui vector sunt 0 pentru spațiu
liber (blanc), 1 pentru X si 2 pentru O.
20
http://muhaz.org/partea-i-rezolvarea-problemelor-in-inteligenta-artificiala.html
9
• Tabela_de_mutări este un vector de 19.683 elemente (3 ), fiecare element
al acestui vector fiind la rindul lui un vector de 9 elemente. Fiecărei poziții
posibile de pe tabla de joc îi corespunde o intrare în această tabelă de mutări
care conține noua poziție obtinuta prin executarea mutării respective.
Algoritmul de rezolvare este prezentat in continuare.
Algoritm: Problema "Tic-Tac-Toe". Rezolvarea 1
1. Initializeaza Tabla cu blanc si Tabela_de_mutări cu toate pozițiile posibile
2. Cit timp nici un jucator nu a cistigat executa
2.1. Considera Tabla ca un numar ternar (in baza 3) si converteste-l in baza 10
obtinind M
2.2. Utilizeaza M ca index in Tabela_de_mutări si obtine
PozNoua  Tabela_ de_ mutari[M]
2.3. Tabla  PozNoua
2.4. dacă PozNoua este poziție cistigatoare atunci intrerupe ciclul
2.5. Citeste mutare adversar si modifica Tabla in consecinta
3. Anunta jucatorul cistigator
sfirsit.
Acest algoritm este foarte eficient din punct de vedere al timpului și, teoretic,
ar putea să joace un joc optim de "Tic-Tac-Toe." Algoritmul prezintă însă mai multe
dezavantaje. În primul rând această abordare necesită un spațiu foarte mare pentru
memorarea tabelei de mutări care specifică mișcările corecte asociate fiecărei
configurații a tablei. În al doilea rând este greu să se stabilească și să se introducă
valorile corecte în tabela de mutări. În final, dacă se dorește extinderea jocului pentru
un caz mai general, de exemplu cazul în trei dimensiuni, trebuie refăcută toată tabela
de mutări de la început. În particular, pentru cazul jocului în trei dimensiuni această
27
abordare nu mai funcționează de loc deoarece ar trebui memorate (3 ) poziții în
tabela de mutări. Tehnica folosită în această rezolvare nu respectă nici una din
cerințele unei tehnici de inteligență artificială.
Rezolvarea 2
Se folosesc următoarele structuri de date:
• Tabla este un vector similar cu cel prezentat în Rezolvarea 1 dar folosește
următoarea codificare a simbolurilor de pe tablă: 2 pentru blanc, 3 pentru X
si 5 pentru O.
• Mutare este o variabilă cu valori întregi care indică numărul mutării ce urmează
a se face. Valoarea 1 indică prima mutare iar valoarea 9 indică ultima mutare.
Algoritmul de rezolvare are o strategie predefinită pentru mișcările pe care trebuie
să le execute. Algoritmul execută numai mișcările impare dacă joacă pe postul
jucatorului X sau mișcările pare dacă joacă pe postul jucătorului O. Se folosesc trei
subprograme: Muta(N) efectuează o mutare în pătratul N, PosCistig(P) evaluează
posibilitatea de câștig a jucătorului P cu următoarea mișcare în funcție de configurația
curentă a tablei și Scop implementează o euristică de alegere a unui pătrat în cazul în

care există mai multe mișcări posibile care nu periclitează câșstigul jucătorului curent.
Subprogramul PosCistig(P) trebuie să verifice pe rând fiecare linie, coloană și
diagonală a tablei pentru a investiga posibilitatea de câștig a lui P în următoarea
mișcare. Datorită modului în care sunt codificate simbolurile de pe tablă se poate
testa posibilitatea de câștig a unei linii, coloane, respectiv diagonale prin înmulțirea
celor trei valori din secvență. Dacă produsul este 27 (3  3  3) atunci jucătorul X
poate să cîștige. Dacă produsul este 50 (5  5  2) atunci jucătorul O poate să
câștige. În momentul în care se găsește o linie, coloană sau diagonală din care se
poate câștiga, se caută poziția liberă din aceasta și se întoarce ca valoare a
subprogramului PosCistig(P) această poziție.

1. Initializeaza Tabla cu blanc
2. Mutare  1
3. cit timp nici un jucator nu a cistigat executa
3.1. alege Mutare dintre
Mutare = 1: Muta(1)
Mutare = 2: dacă Tabla[5] = 2
atunci Muta (5)
altfel Muta(1)
Mutare = 3: dacă Tabla[9] = 2
atunci Muta(9)
altfel Muta (3)
Mutare = 4: dacă PosCistg(X)  0
atunci Muta(PosCistig(X)) /* blocheaza cistig
adversar */
altfel Muta(Scop)
atunci
(i) Muta(PosCistig(X)) /* deci cistiga X */
(ii) intrerupe ciclul
altfel dacă PosCistig(O)  0
atunci Muta(PosCistig(O)) /* blocheaza cistig
adversar */
altfel dacă Tabla[7] = 2
atunci Muta(7)
altfel Muta (3)
Mutare = 6: dacă PosCistig(O)  0
atunci
(i) Muta(PosCistig(O)) /* deci cistiga O */

altfel dacă PosCistg(X)  0
atunci Muta(PosCistig(X)) /* blocheaza cistig
adversar */
altfel Muta(Scop)
atunci
atunci Muta(PosCistig(O))
altfel muta in orice patrat liber
Mutare = 8: dacă PosCistig(O)  0
atunci
(i) Muta(PosCistig(O)) /* deci cistiga O */
altfel dacă PosCistg(X)  0
atunci Muta(PosCistig(X))
Mutare = 9: dacă PosCistig(O)  0 /* identic cu
Mutare 7 */
atunci
atunci Muta(PosCistig(O))
3.2. Mutare  Mutare +1
sfirsit.
Muta(N)
1. dacă Mutare are valoare impara
atunci Tabla[N]  3
2. dacă Mutare are valoare para
atunci Tabla[N]  5
sfirsit.
PosCistig(P)
1. dacă jucatorul P nu poate cistiga in mutarea urmatoare
atunci intoarce 0
2. intoarce pozitia patratului cu miscare cistigatoare
sfirsit.
Scop
1. dacă patratul din mijloc este gol /* patratul cu indicele 5 */

atunci intoarce 5
2. intoarce pozitia unui patrat care nu se afla in colturi, i.e.
pozitia  2,4,6,8 , care este liber
sfirsit.
Din punct de vedere al timpului acest algoritm nu este la fel de eficient ca
primul deoarece trebuie sa verifice mai multe conditii inainte de a executa o miscare,
dar este mai eficient din punct de vedere al spațiului. Algoritmul prezinta avantajul
utilizarii unei strategii relativ explicite care poate fi inteleasa si modificata mult mai
usor decit in cazul primei rezolvari. Cu toate acestea strategia generala este stabilita
de programator apriori, este codificata direct in program si nu prezinta generalitatea
necesara. Dacă se dorește extinderea jocului, de exemplu la "Tic-Tac-Toe" in trei
dimensiuni, intregul algoritm trebuie schimbat. Urmatoarea rezolvare va elimina
aceste inconveniente.
Rezolvarea 3
Se folosesc urmatoarele structuri de date:
• Tabla este un vector similar cu cel prezentat in Rezolvarea 2.
• Urm este o lista cu toate configuratiile urmatoare posibile care se obtin din
configuratia curenta a tablei prin executia mutărilor permise din configuratia
curenta.
• Merit este un numar intreg care reprezinta o estimare a posibilitatii de cistig
din configuratia curenta a tablei prin una sau mai multe mutări. Deci meritul
unei configuratii reprezinta cit de promitatoare este configuratia curenta
pentru cistig.
Algoritmul de rezolvare este prezentat in continuare.

1. Initializeaza Tabla cu blanc
2. cit timp nici un jucator nu a cistigat executa
2.1. Urm  { }
2.2. pentru fiecare mutare posibila din configuratia curenta C executa
2.2.1. Determina configuratia urmatoare C1 a tablei
2.2.2. Urm  Urm  C1
2.3. pentru fiecare configuratie C1 din lista Urm executa
2.3.1. Merit  DetMerit (C1 )
2.3.2. Retine in MeritMaxim valoarea maxima a variabilei Merit
2.4. Executa mutarea asociata configuratiei cu meritul MeritMaxim si obtine
PozNoua
2.5. dacă PozNoua este poziție cistigatoare
atunci intrerupe ciclul
2.6. Citeste mutare adversar si modifica Tabla in consecinta
sfirsit.
DetMerit(C1)
1. dacă configuratia C1 este cistigatoare
atunci intoarce valoarea maxima predefinita a meritului
2. Considera toate mutările posibile ale adversarului din configuratia C1
3. Calculeaza meritul Mi al fiecărei configuratii rezultate prin aceste mutări
4. Alege configuratia cu meritul cel mai mic, Mmin, considerind ca adversarul
va face
cea mai defavorabila miscare pentru opozant
5. intoarce Mmin
sfirsit.
Algoritmul poate inspecta in avans mai multe secvente de miscari pentru a

determina secventa care va duce la câștig și, deci, a obține o estimare mai buna
a configuratiilor urmatoare. Algoritmul incearca sa maximizeze sansele de a
cistiga presupunind ca adversarul va incerca sa minimizeze aceste sanse pentru
oponent. Din acest motiv algoritmul este cunoscut sub numele de strategia
"MinMax" si este utilizat frecvent in implementarea problemelor de jocuri in
inteligență artificială.
In cazul unor jocuri mai complicate decit "Tic-Tac-Toe", formularea
subprogramului DetMerit(C1) din algoritmul de mai sus poate implica un apel
recursiv infinit in pasul 3. In realitate se introduce o limita a miscarilor urmatoare
investigate, platind insa pretul scaderii acuratetei estimarii meritului.
Rezolvarea 3 necesita un timp de calcul mai mare decit primele doua
rezolvari deoarece trebuie sa inspecteze inaintea fiecărei mutări o parte din
arborele de configuratii urmatoare posibile. Pentru probleme simple, cum ar fi cea
discutata, primele doua abordari sunt evident mai eficiente. Ultima rezolvare este
superioara insa celorlalte doua din urmatoarele motive:
a) poate fi extinsa la jocuri mai complicate decit "Tic-Tac-Toe", jocuri
pentru care enumerarea exhaustiva a tuturor posibilitatilor de mutare este
imposibila,
b) strategia de joc poate fi imbunatatita sau schimbata prin modul de calcul
al meritului.
Aceasta ultima abordare este un exemplu tipic de tehnica de inteligență
artificială. Ea ilustreaza trei aspecte caracteristice ale rezolvarii problemelor in
inteligență artificială: obtinerea solutiei prin cautare, utilizarea cunostintelor
specifice domeniului si abstractizarea, i.e. separarea caracteristicilor importante
ale problemei de aspectele de detaliu.
3.1. Albus, J. S. și Barbera, A. J. „RCS: A cognitive architecture for intelligent

multi-agent systems”, Annual Reviews in Control, vol. 29, no. 1, pp. 87-99,
2005.
3.2. Bruyninckx, H., P. Soetens, și B. Koninckx. 2003. „The real-time motion
control core of the Orocos project.” IEEE Int. Conf. on Robotics and
Automation. Accesat 06 25, 2018. doi:10.1109/ROBOT.2003.1242011.
3.3. Groza, B. „Introducere în inteligența artificială. Aplicații cu strategii de căutare
neinformate și informate”, Editura Universității Politehnica Timișoara, pp. 87,
Facultatea de Automatică şi Calculatoare, Bd. Vasile Pârvan nr. 2, Room
A304, 300223, Timişoara, România, e-mail: bogdan.groza@aut.upt.ro,
web: www.aut.upt.ro/~bgroza.
3.4. Murphy, Robin R. Introduction to AI Robotics, Massachusetts London,
England, Massachusetts London, England, ISBN 0-262-13383-0.
3.5. Mihai Drăgănescu; Adrian Davidoviciu; Ioan Georgescu, Inteligența artificială
și robotica, 1983, Bucure;ti, Editura Academiei Române, Biblioteca „Avram
Filipaș” a Universității Titu Maiorescu, III2029TN, pp. 397, http://
biblioteca.utm.ro/cgi.
3.6. Shoham, Y.; Leyton-Brown, K., Multiagent Systems: Algorithmic, Game
Theoretic, and Logical Foundations, 2008, Cambridge University Press, ISBN
978-0521899437, http://www.masfoundations.org.
3.7. Poole, D. L.; Mackworth, A. K., Artificial Intelligence: Foundations of
Computational Agents., Cambridge University Press, ISBN 978-0-521-51900-
7, pp. 661.
3.8. Benoı̂ t, J. P., The Gibbard–Satterthwaite theorem: a simple proof, Economics
Letters, 2000, pp. 319-322, Elsevier, 69(3), 10.1016/S0165-1765(00)00312-8.
Abreviere Explicație
AA Appropriate Anchoring – Ancorarea Adecvată
ACM Allowed Collision Matrix
ADC Analog to Digital Conversion A → D
AI Artificial Intelligence
ATP Add Time Parametrization
BF breadth first
FIFO First In First Out
LIFO Last In First Out
VCG Mecanismul Vickrey-Clarke-Groves
4. CUNOAȘTERE ȘI RAȚIONAMENTE
4.1 Agenți logici
Un agent inteligent are nevoie de cunoștințe despre lumea reală pentru a lua
decizii și raționamente pentru a acționa eficient.
Agenții bazați pe cunoaștere sunt acei agenți care au capacitatea de a menține
o stare internă a cunoașterii, raționează asupra acelor cunoștințe, își actualizează
cunoștințele după observații și iau măsuri. Acești agenți pot reprezenta lumea cu o
anumită reprezentare formală și pot acționa inteligent.
Agenții bazați pe cunoaștere sunt compuși din două părți principale:
• baza de cunoștințe;
• sistemul de inferență.
Un agent bazat pe cunoștințe trebuie să poată face următoarele:
• reprezenta stări, acțiuni etc.;
• încorpora noi percepții;
• actualiza reprezentarea internă a lumii;
• deduce reprezentarea internă a lumii;
• deduce acțiunile adecvate.
Un agent este orice lucru care poate fi privit ca percepându-și mediul prin
senzori și acționând asupra acelui mediu prin efectori. Un agent uman are ochi,
urechi și alte organe pentru senzori și mâini, picioare, gură și alte părți ale corpului
pentru efectori. Un agent robot înlocuiește sistemul senzorial vizula cu camere video,
telemetrie în infraroșu. Iar pentru acțiune cu diverse motoare pentru efectoare. Un
agent software are codat șiruri de biți pentru percepții și acțiuni [4.1].
Fig. 4.1 Exemplificarea unui agent inteligent-logic. [4.1], pp.32, fig. 2.1
Un agent logic-rațional (Fig. 4.1) este cel care face ceea ce trebuie. Evident,
acest lucru este mai bun decât să faci un lucru greșit, dar ce înseamnă? Ca primă
182 4 – Cunoaștere și Raționamente
aproximare, vom spune că acțiunea corectă este cea care va determina agentul să
aibă cel mai mare succes. Acest lucru ne lasă cu problema de a decide cum și când
să evaluăm succesul agentului.
Folosim termenul măsură de performanță pentru cum - criteriile care
determină cât de reușit este un agent. Evident, nu există o singură măsură fixă
potrivită pentru toți agenții. Am putea cere agentului o opinie subiectivă despre cât
de fericit este cu propria sa performanță, dar unii agenți nu ar putea răspunde, iar alții
s-ar înșela. (Agenții umani în special sunt cunoscuți pentru „struguri acri” - spunând
că nu și-au dorit cu adevărat ceva după ce nu au reușit să-l obțină.) Prin urmare, vom
insista asupra unei măsuri obiective de performanță impuse de o anumită autoritate.
Cu alte cuvinte, noi, ca observatori externi, stabilim un standard a ceea ce înseamnă
să ai succes într-un mediu și îl folosim pentru a măsura performanța agenților.
Considerăm că un agent care ar trebui să efectueze o sarcină, are ca factor de
îndeplinire o măsură cantitativă. Complicând algoritmul putem solicta și un criteriu
de performanță, cum ar fi cantitatea de energie electrică consumată și cantitatea de
zgomot generată. Se poate introduce și a treia măsură de performanță să lucreze în
liniște și eficient.
Ce putem aprecia acum este important să fie definit momentul evaluării
performanței. Fie pe o scară temporală fie pe una cantitativă indiferent de timp. Un
alt element care poate fi introdus este cel comparativ, în care agentul trebuie să
precizeze (pe baza datelor de la senzori) care este evoluția fiecărui parametru în timp,
de la o zi la lata sau similar. Astfel, operatorii pot măsuram performanța pe termen
lung, fie că este vorba de un schimb de opt ore sau de o lună etc..
Putem defini, astfel, arhitectura (Fig. 4.2) agentului bazat pe cunoaștere1:
Fig. 4.2 Arhitectura simplificată a unui agent bazat pe cunoaștere.
1
https://www.javatpoint.com/knowledge-based-agent-in-ai
Diagrama de mai sus reprezintă o arhitectură generalizată pentru un agent

bazat pe cunoaștere. Agentul bazat pe cunoaștere (KBA) ia contribuții din mediu
percepând mediul. Intrarea este luată de motorul de inferență al agentului și care
comunică, de asemenea, cu KB pentru a decide în conformitate cu depozitul de
cunoștințe din KB. Elementul de învățare al KBA actualizează regulat KB prin
învățarea de noi cunoștințe.
Baza de cunoștințe este o componentă centrală a unui agent bazat pe
cunoaștere, este, de asemenea, cunoscut sub numele de KB. Este o colecție de
propoziții (aici „propoziție” este un termen tehnic și nu este identic cu propoziția
gramaticală utilizată de un om). Aceste propoziții sunt exprimate într-un limbaj de
reprezentare a cunoștințelor. Baza de cunoștințe a KBA stochează informații despre
lume.
Baza de cunoștințe este necesară pentru actualizarea cunoștințelor pentru ca
un agent să învețe din experiențe și să acționeze conform cunoștințelor.
Printr-un sistem de inferență înțelegem derivarea unor propoziții noi dintr-
unele vechi. Sistemul de inferență ne permite să adăugăm o nouă propoziție la baza
de cunoștințe. O propoziție este o propunere despre lume. Sistemul de inferență
aplică reguli logice KB pentru a deduce informații noi.
Sistemul de inferență generează fapte noi, astfel încât un agent să poată
actualiza KB. Un sistem de inferență funcționează în principal în două reguli care
sunt date ca:
• înlănțuire înainte
• înlănțuire înapoi
Operațiunile efectuate de KBA au rolul de a genera un comportament
inteligent:
1. TELL: această operațiune spune bazei de cunoștințe ceea ce percepe din
mediu.
2. ASK: această operație întreabă baza de cunoștințe ce acțiune ar trebui să
efectueze.
3. Perform: realizează acțiunea selectată.
Un agent generic bazat pe cunoștințe urmează schema structurii unui program
generic de agenți bazat pe cunoaștere:
function KB-AGENT(percept):
persistent: KB, a knowledge base
t, a counter, initially 0, indicating time
TELL(KB, MAKE-PERCEPT-SENTENCE(percept, t))
Action = ASK(KB, MAKE-ACTION-QUERY(t))
TELL(KB, MAKE-ACTION-SENTENCE(action, t))
t=t+1
return action
Agentul bazat pe cunoștințe ia percepția ca intrare și returnează o acțiune ca

ieșire. Agentul menține baza de cunoștințe, KB și are inițial cunoștințe de bază
despre lumea reală. De asemenea, are un contor pentru a indica timpul pentru întregul
proces, iar acest contor este inițializat cu zero.
De fiecare dată când funcția este apelată, își efectuează cele trei operații:
• îi spune KB-ului ceea ce percepe MAKE-PERCEPT-SENTENCE;
• îl întreabă pe KB ce măsuri ar trebui să ia MAKE-ACTION-QUERY;
• îi spune SPUNE KB ce acțiune a fost aleasă MAKE-ACTION-SENTENCE.
Există mai multe niveluri de agent bazat pe cunoaștere:
1. Nivelul de cunoștințe este primul nivel al agentului bazat pe cunoaștere și,
la acest nivel, trebuie specificat ce știe agentul și care sunt obiectivele
agentului. Cu aceste specificații, i se poate rezolva comportamentul. De
exemplu, să presupunem că un agent de taxi automat trebuie să meargă
dintr-o stație A în stația B și știe drumul de la A la B, deci acest lucru vine
la nivelul cunoștințelor;
2. Nivel logic, la acest nivel, înțelegem cum este stocată reprezentarea
cunoașterii cunoștințelor. Propozițiile sunt codificate în diferite logici. La
nivel logic, apare o codificare a cunoștințelor în propoziții logice. La nivel
logic, ne putem aștepta ca agentul de taxi automat să ajungă la destinația
B.
3. Nivelul de implementare, este reprezentarea fizică a logicii și cunoașterii.
La nivelul implementării agentul efectuează acțiuni conform nivelului
logic și de cunoștințe. La acest nivel, un agent de taxi automat își
implementează de fapt cunoștințele și logica astfel încât să poată ajunge la
destinație.
Există în principal două abordări pentru a construi un agent bazat pe
cunoaștere:
i. abordarea declarativă: se poate crea un agent bazat pe cunoaștere inițializând
cu o bază de cunoștințe goală și spunându-i agentului toate propozițiile cu
care dorim să începem. Această abordare se numește abordare declarativă.
ii. abordarea procedurală: se codifică direct comportamentul dorit ca un cod de
program. Ceea ce înseamnă că trebuie doar scris un program care codifică
deja comportamentul sau agentul dorit.
Cu toate acestea, în lumea reală, un agent de succes poate fi construit
combinând atât abordări declarative, cât și abordări procedurale, iar cunoștințele
declarative pot fi deseori compilate într-un cod procedural mai eficient.
Reprezentarea cunoașterii pentru oamenii se referă la înțelegerea,
raționamentul și interpretarea cunoștințelor, dar modul în care fac mașinile toate
aceste lucruri intră sub reprezentarea și raționamentul cunoașterii? De aceea vom
descrie reprezentarea cunoștințelor, astfel:
▪ reprezentarea și raționamentul cunoașterii (KR, KRR) este partea
inteligenței artificiale care se referă la gândirea agenților AI și modul în care
gândirea contribuie la comportamentul inteligent al agenților;
▪ reprezentarea informațiilor despre lumea reală, astfel încât un computer să
poată înțelege și să poată utiliza aceste cunoștințe pentru a rezolva
problemele complexe din lumea reală și mai laes să poată comunica cu

oamenii în limbaj natural;
▪ descrie modul în care se poate reprezenta cunoașterea în inteligența
artificială, respectiv stocarea datelor într-o anumită bază de date, și modul
în care mașina să învețe din aceste cunoștințe și experiențe, astfel încât să se
poată comporta inteligent, conform modului în care o face un om.
Având definită noțiunea de reprezentare, acum trebuie precizate ce se poate
reprezenta, deocamdată fără a defini și cum să se întâmple acest lucru. La nivel basic
se consideră următoarele tipurile de cunoștințe care trebuie reprezentate în sistemele
de IA:
▪ obiect: toate elementele, noțiunile despre un obiect oarecare din domeniul
de interes;
▪ evenimente: acțiunile care au loc în lumea reală și fac parte din domeniul de
interes;
▪ performanță: descrie comportamentul care implică cunoștințe despre cum
trebuie să se facă lucrurile de interes;
▪ meta-cunoaștere: este cunoaștere despre ceea ce știm;
▪ fapte: sunt adevărurile despre lumea reală și ceea ce reprezentăm în
domeniul de interes;
▪ baza de cunoștințe: componenta centrală a agenților bazați pe cunoaștere
este baza de cunoștințe. Este reprezentat ca KB. Baza de cunoștințe este un
grup de propoziții (aici, propozițiile sunt folosite ca termen tehnic și nu sunt
identice cu limbajul curent al omului).
Cunoașterea este conștientizarea sau familiaritatea dobândită prin experiențe
datorate: faptelor, datelor și situațiilor.
Fig. 4.3 Arhitectura simplificată a cunoașterii.

Ca și în cazul reprezentării, avem o multitudine de tipuri de cunoștințe în

inteligența artificială:
1. cunoștințe declarative:
a. cunoașterea declarativă este să știi despre ceva;
b. include concepte, fapte și obiecte;
c. se mai numește cunoaștere descriptivă și exprimată în sentințe
declarative;
d. este mai simplu decât limbajul procedural;
2. cunoștințe procedurale:
a. cunoscute sub numele de cunoaștere imperativă;
b. sunt cunoștințe responsabile de a ști cum să se facă ceva;
c. se aplică direct oricărei sarcini;
d. include reguli, strategii, proceduri, agende etc.;
e. depind de sarcina pe care pot fi aplicate;
3. meta-cunoaștere:
a. cunoașterea despre celelalte tipuri de cunoștințe;
4. cunoștințe euristice:
a. reprezintă cunoștințele unor experți într-un domeniu sau subiect;
b. sunt reguli generale bazate pe experiențe anterioare, conștientizarea
abordărilor și care sunt bune de funcționat, dar nu sunt garantate;
5. cunoștințe structurale:
a. sunt cunoștințe de bază pentru rezolvarea problemelor;
b. descriu relațiile dintre diferite concepte, cum ar fi felul, o parte din
și gruparea a ceva;
c. descriu relația care există între concepte sau obiecte.
Relația dintre cunoștințe și inteligență este demonstrată de comportamentul
inteligent aferent agenților AI. Un agent este capabil să acționeze cu precizie asupra
unor date de intrare numai atunci când are anumite cunoștințe sau experiență despre
acea intrare, doar dacă există un factor de decizie care acționează prin detectarea
mediului și folosirea cunoștințelor. Dar dacă partea de cunoaștere nu va fi prezentată,
atunci nu poate afișa un comportament inteligent (Fig. 4.4).
Fig. 4.4 Arhitectura relațională dintre cunoștințe și inteligență [4.2].

Un sistem de inteligență artificială are următoarele componente pentru

afișarea unui comportament inteligent (Fig. 4.5):
• Percepţie
• Învăţare
• Reprezentarea și raționamentul cunoștințelor
• Planificare
• Execuţie
Fig. 4.5 Reprezentarea ciclului cunoașterii AI.
Conform diagramei din Fig. 4.5 putem aprecia cum un sistem AI

interacționează cu lumea reală:
• componenta “Percepțieˮ preia informații din mediul înconjurător prin
intermediul senzorilor;
• componenta de învățare este responsabilă pentru învățarea din datele captate
de comportamentul percepției;
• componentele privind “Reprezentarea cunoștințelorˮ și “Raționamentulˮ, au
rolul de a face ca reprezentările unui robot să fie similare cu cele ale
oamenilor, deși sunt independente trebuie să lucreze împreună (simulatan);
• componentele “Planificareaˮ și “Execuțiaˮ depind de analiza reprezentării și
raționamentului cunoașterii.
Există în principal patru abordări ale reprezentării cunoștințelor:

1. Cunoștințe relaționale simple:
Este cel mai simplu mod de stocare a faptelor care folosește metoda relațională
și fiecare fapt despre un set de obiecte este prezentat sistematic în coloane. Această
abordare a reprezentării cunoștințelor se folosește în sistemele de baze de date în
care este reprezentată relația dintre diferite entități și are puține posibilități de
deducție.
2. Cunoștințe ereditare:
În abordarea de cunoaștere moștenită, toate datele trebuie stocate într-o
ierarhie de clase. Toate clasele trebuie aranjate într-o formă generalizată sau
ierarhică. Elementele moștenesc valori de la alte elemente ale unei clase. Abordarea
conține cunoștințe moștenite care arată o relație între instanță și clasă și se numește
relație de instanță. Fiecare cadru individual poate reprezenta colecția de atribute și
valoarea acestuia.
3. Cunoștințe inferențiale:
Abordarea inferențială a cunoașterii reprezintă cunoașterea sub forma logicii
formale. Această abordare poate fi utilizată pentru a obține mai multe fapte și
garantează corectitudinea informațiilor.
Exemplu: Să presupunem că există două afirmații:
DUSTER este o mașină
Toate mașinile au motoare
Atunci poate reprezenta ca;
DUSTER (mașină)
(∀) x = DUSTER (x) ----------> motor (x) s
4. Cunoștințe procedurale:
Abordarea procedurală a cunoștințelor utilizează programe și coduri mici care
descriu cum să fie făcute diverse lucruri specifice și cum se procedează pentru acest
lucru. Abordarea, utilizează regula If-Then.
În aceste cunoștințe, putem folosi diverse limbaje de codificare, cum ar fi
limbajul LISP și limbajul Prolog.
Se pot reprezenta cunoștințe euristice sau specifice domeniului folosind
această abordare.
Sistemul de reprezentare a cunoștințelor trebuie să posede următoarele proprietăți.

1. Acuratețe reprezentativă: sistemul KR ar trebui să aibă capacitatea de a
reprezenta toate tipurile de cunoștințe necesare.
2. Adecvarea inferențială: sistemul KR ar trebui să aibă capacitatea de a
manipula structurile reprezentative pentru a produce noi cunoștințe
corespunzătoare structurii existente.
3. Eficiență inferențială: capacitatea de a direcționa mecanismul de
cunoaștere inferențial în cele mai productive direcții prin stocarea
ghidurilor adecvate.
4. Eficiență de achiziție - capacitatea de a dobândi cu ușurință noile
cunoștințe folosind metode automate.
Există în principal patru moduri de reprezentare a cunoștințelor care sunt
prezentate după cum urmează:
I. reprezentare logică;
II. reprezentarea semantică a rețelei;
III. reprezentare cadru;
IV. reguli de producție.
Fig. 4.6 Tehnici de reprezentare a cunoașterii AI.
I. Reprezentare logică
Reprezentarea logică este un limbaj cu câteva reguli concrete care se ocupă de
propoziții și nu are nicio ambiguitate în reprezentare. Reprezentarea logică înseamnă
tragerea unei concluzii bazate pe diferite condiții. Această reprezentare stabilește
câteva reguli importante de comunicare. Acesta constă din sintaxă și semantică
definite cu precizie, care susțin inferența sunetului. Fiecare propoziție poate fi
tradusă în logică folosind sintaxa și semantica.
a. Sintaxă:
• sintaxele sunt regulile care decid cum se pot construi propoziții juridice în
logică;
• determină ce simbol se pate folosi în reprezentarea cunoașterii;
• cum trebuie scrise aceste simboluri.
b. Semantică:
• semantica reprezintă regulile prin care se poate interpreta propoziția în
logică.
• semantica implică atribuirea unui sens fiecărei propoziții.
c. Reprezentarea logică:
• logică propozițională;
• logică predicat.
Reprezentările logice prezintă următoarele avantaje și dezavantaje:
▪ avantaje:
o permite efectuarea de raționamente logice;
o se constituie ca bază a limbajelor de programare;
▪ dezavantaje:
o prezintă restricții și sunt dificile să lucreze cu acestea;
o este posibil să nu fie foarte naturală, iar inferența să nu fie atât de
eficientă.
II. Reprezentarea rețelelor semantice

Rețelele semantice sunt o alternativă a logicii predicate pentru reprezentarea
cunoașterii. În rețelele semantice, se pot reprezenta cunoștințele sub formă de rețele
grafice. Această rețea este formată din noduri care reprezintă obiecte și arce care
descriu relația dintre aceste obiecte [4.3]. Rețelele semantice pot clasifica obiectul în
diferite forme și, de asemenea, pot lega aceste obiecte. Rețelele semantice sunt ușor
de înțeles și pot fi ușor extinse. Această reprezentare constă în principal în două tipuri
de relații:
• relația IS-A (Moștenire);
• tipul de relație.
Reprezentările rețelelor semantice prezintă următoarele avantaje și
dezavantaje:
▪ avantaje:
o sunt o reprezentare naturală a cunoașterii;
o transmit sens într-un mod transparent;
o sunt simple și ușor de înțeles;
▪ dezavantaje:
o necesită mai mult timp de calcul în timpul rulării, deoarece trebuie
să traverseze arborele complet al rețelei pentru a răspunde unor
întrebări. În cel mai rău caz, ar putea fi posibil ca, după parcurgerea
întregului arbore, să se constate că soluția nu există în această rețea;
o încearcă să modeleze memoria asemănătoare omului (care are 1015
neuroni și fiecare neuron are aproximativ 105 legături) pentru a stoca
informațiile, lucru care, în practică, nu este posibil de construit ca o
rețea semantică atât de vastă;
o sunt inadecvate, deoarece nu au nici un cuantificator echivalent, de
exemplu, pentru toate, pentru unii, nici unul etc.;
o nu au nicio definiție standard pentru numele linkurilor;
o aceste rețele nu sunt inteligente și depind de creatorul sistemului.
III. Reprezentare cadru

Un cadru este o structură asemănătoare unei înregistrări care constă dintr-o
colecție de atribute și valorile sale pentru a descrie o entitate din lume. Cadrele sunt
structura de date AI care împarte cunoștințele în substructuri reprezentând situații de
stereotipuri. Acesta constă dintr-o colecție de sloturi și valori ale sloturilor. Aceste
sloturi pot fi de orice tip și dimensiune. Sloturile au nume și valori care se numesc
fațete.
Fațete: diferitele aspecte ale unui slot sunt cunoscute sub numele de fațete.
Fațetele sunt caracteristici ale cadrelor care ne permit să punem constrângeri pe
cadre. Un cadru poate consta din orice număr de sloturi, iar un slot poate include
orice număr de fațete, iar fațetele pot avea orice număr de valori. Un cadru este, de
asemenea, cunoscut sub numele de reprezentare a cunoștințelor cu filtru de slot în
inteligența artificială.
Cadrele sunt derivate din rețelele semantice și ulterior au evoluat în clasele și
obiectele noastre din zilele noastre. Un singur cadru nu este foarte util. Sistemul de
cadre constă dintr-o colecție de cadre conectate. În cadru, cunoștințele despre un
obiect sau eveniment pot fi stocate împreună în baza de cunoștințe. Cadrul este un
tip de tehnologie care este utilizat pe scară largă în diverse aplicații, inclusiv
procesarea limbajului natural și viziunile mașinilor.
Reprezentările cadru prezintă următoarele avantaje și dezavantaje:
▪ avantaje:
o face programarea mai ușoară prin gruparea datelor aferente;
o este comparabil flexibilă și utilizată de multe aplicații în AI;
o este foarte ușor să fie adăugatei sloturi pentru noi atribute și relații;
o este ușor de inclus date implicite și să fie căutate valorile lipsă;
o este ușor de înțeles și vizualizat;
▪ dezavantaje:
o mecanismul de inferență nu este ușor de procesat;
o mecanismul de inferență nu poate fi continuat fără probleme prin
reprezentarea cadrului;
o are o abordare mult mai generalizată.
IV. Reprezentarea regulilor de producție
Sistemul de reguli de producție constă din (condiție, acțiune) perechi care
înseamnă „dacă condiție → atunci acțiune”. Are în principal trei părți:
1. setul de reguli de producție;
2. memorie de lucru;
3. ciclul de recunoaștere-act.
În regulile de producție agentul verifică starea și dacă starea există, atunci
regula de producție se declanșează și se efectuează acțiunea corespunzătoare. Partea
de condiție a regulii determină care regulă poate fi aplicată unei probleme. Iar partea
de acțiune efectuează etapele de rezolvare a problemelor asociate. Acest proces
complet este numit un ciclu de recunoaștere-act.
Memoria de lucru conține descrierea stării actuale de rezolvare a problemelor
și regula poate scrie cunoștințe în memoria de lucru. Această cunoaștere se potrivește
și poate declanșa alte reguli.
Dacă se generează o nouă situație (stare), atunci mai multe reguli de producție
vor fi declanșate împreună, aceasta se numește set de conflicte. În această situație,
agentul trebuie să selecteze o regulă din aceste seturi și se numește rezoluție de
conflict.
Reprezentările regulilor de producție prezintă următoarele avantaje și
dezavantaje:
▪ avantaje:
o sunt exprimate în limbaj natural;
o sunt extrem de modulare, deci putem elimina, adăuga sau modifica
cu ușurință o regulă individuală;
▪ dezavantaje:
o nu prezintă nicio capacitate de învățare, deoarece nu stochează
rezultatul problemei pentru utilizările viitoare;
o în timpul executării programului, multe reguli pot fi active, prin
urmare, sistemele de producție bazate pe reguli sunt ineficiente.
4.2 Consistența raționamentelor logice la roboți
Majoritatea agenților robotici autonomi folosesc inferența logică pentru a se

menține la un comportament sigur și permis [4.4]. Având în vedere un set de reguli,
este important ca robotul să poată stabili coerența dintre regulile sale, convingerile
sale bazate pe percepție, acțiunile planificate și consecințele acestora. Un set de
reguli este modelat de un sistem de evoluție boolean cu semantică sincronă, care
poate fi tradus într-un sistem de tranziție etichetat (Labelled Transition System -
LTS). Este dovedit că stabilitatea și consistența pot fi formulate ca proprietăți de
logică a arborelui de calcul (Computation Tree Logic - CTL) și logică temporală
liniară (Linear Temporal Logic - LTL).
Procesul de luare a deciziilor unui sistem robotizat are nevoie uneori de luarea
unor decizii dificile. Capacitatea de a lua decizii rapide cu privire la consistența logică și
capacitatea robotului de a detecta când apare inconsecvența este o problemă importantă.
Este, de asemenea, de o importanță deosebită pentru sistemele de control al robotului
bazate pe logică, de exemplu. Un sistem robotic tipic bazat pe logică conține de obicei
un set de proceduri, care oferă baza raționamentului pentru comportamentul unui robot
[4.5]. Un set de proceduri incoerente ar putea duce la un plan greșit care să provoace un
rezultat neașteptat, de exemplu, o dronă poate lovi un obstacol, în loc să-l evite, dacă
consideră greșit că orice cale de evitare ar putea provoca mai multe daune, din cauza
percepției greșite a mediului. Percepția greșită ar putea fi corectată dacă ar fi fost capabil
să combine cunoștințele anterioare de mediu cu detectarea curentă.
Pentru identificarea și urmărirea mișcării obiectelor și mai ales pentru a stabili
relațiile de funcționalitate se utilizează de regulă metodele bayesiene [4.6]. Atunci când
se confruntă cu probabilități echilibrate pentru două relații ipotetice și concurente în
mediul robotului, poate fi necesar să ia o decizie bazată pe aplicarea logicii folosind
cunoștințe anterioare. Descoperirea inconsecvenței logice în relațiile geometrice și fizice
într-un model de mediu ar trebui să determine un agent robotizat să-și revizuiască
modelul de percepție a lumii. De exemplu, agenții credință-dorință-intenție (Belief-
Desire-Intention - BDI) ar trebui să efectueze verificări de consistență în ciclul lor de
raționament în limbaje de programare, precum Jason, 2AP L și Jade [4.7-4.11]. În aceste
sisteme, trebuie efectuate verificări de consistență logice și gestionarea neconcordanțelor
în etapa de proiectare a software-ului. Subiectul verificării rapide a consecvenței de către
roboți are implicații și pentru certificarea legală a roboților.
4.2.1 Clarificarea percepției și logica robotului
Reprezentarea cunoașterii bazată pe predicate a unui robot, care este derivată din
detectarea evenimentelor, amintirea trecutului, precum și din predicția unui mediu viitor,
este prezentată schematic în Fig. 4.7. Pentru noile predicate senzoriale se presupune că
robotul este capabil să identifice care sunt incerte în sens probabilistic.
Următoarele probleme specifice trebuie abordate:
1. Dacă apare inconsecvență, trebuie identificat ce predicate incerte noi de
detectare din Ut ⊆ Bt pot fi asigurate în cadrul regulilor RP bazate pe
modele fizice.
2. Agentul consideră un set At ⊆ Bt de acțiuni ca opțiuni. Pentru fiecare

acțiune αk din At simulează un model fizic pe un orizont de timp și
abstractizează un set de evenimente Ft pentru consecințele sale viitoare.
3. Verifică dacă Ft ⊆ Bt și regulile sale de comportament RB sunt bazate pe
consecvență pe 1) și 2).
4. Setul Pt ⊆ At de acțiuni fezabile αk în At, care sunt în concordanță cu RB,
sunt utilizate de robot pentru a face o alegere finală a unei acțiuni utilizând
evaluări non-logice (de exemplu, folosind planificarea).
Fig. 4.7 Tipuri de predicate în raționamentul unui robot la momentul t.
4.2.1.1 Descoperirea inconsecvenței
În Fig. 4.7, romburile indică locațiile procedurale ale verificărilor logice de

consistență, bazate pe predicate și seturi de reguli (implicații logice). Cu toate
acestea, se poate întâmpla ca o parte din detectarea probabilistică a evenimentelor să
rămână nerezolvată pe baza modelelor fizice și a regulilor asociate: să notăm D t ⊆
U setul percepțiilor indecise. Agentul robotic trebuie să verifice pentru fiecare dintre
acțiunile sale posibile ce s-ar întâmpla dacă diferite combinații ale percepțiilor sale
incerte în Dt ar fi adevărate sau false. În situații critice de siguranță, un robot nu poate

întreprinde nicio acțiune, ceea ce ar putea duce la încălcarea regulilor sale într-o
combinație de valori de adevăr în Dt. Verificarea acestui lucru poate necesita
verificarea complexă a consecvenței în timp ce robotul interacționează cu mediul
său, prin urmare metodele eficiente propuse în această lucrare sunt cheia pentru
deciziile în timp util ale unui robot.
La un anumit ciclu de raționament al agentului robotizat, indexat cu timpul t,
agentul deține un set de predicate Bt ⊂ B în memoria sa, posibil unele dintre acestea
cu semne de negație. Aceasta înseamnă că predicatele din Bt se împart în două seturi
disjuncte ca Bt = Bttrue  Btfalse constând din cele atribuite valoare true în timp ce
restul este valoarea booleană f alse. O astfel de atribuire a valorilor booleene în Bt se
numește o evaluare a variabilelor booleene în Bt și notate cu Bt .Agentul are, de
asemenea, un set de reguli la momentul t notate cu Rt = r1t , 
, rmt . Setul de reguli
Rt poate conține mai multe variabile decât Bt.
Cei care nu sunt în Bt sunt necunoscuți agentului și raționamentul său logic
este apoi interesat de problema satisfacției tuturor regulilor logice prin atribuiri
adecvate variabilelor necunoscute. În cele ce urmează vom renunța la indicele de
timp t, deoarece vom fi interesați de consistența regulilor logice în orice moment,
având în vedere unele evaluări booleene. Termenii „variabilă” și „predicat” vor fi
folosiți în mod interschimbabil. Problema noastră principală este că agentul robotizat
are timp limitat pentru derivări logice, atunci când este necesar un răspuns rapid și
trebuie să evalueze următoarele:
• evaluările sale actuale și baza de reguli sunt coerente în sensul că variabilele
necunoscute pot lua valori pentru a satisface toate regulile?
• după ce a răspuns negativ la întrebarea anterioară, poate modifica unele
dintre propriile sale evaluări booleene astfel încât setul său de predicate să
devină consecvent cu setul său de reguli?
Testarea consistenței unui set de evaluări poate fi realizată prin verificarea
satisfacției conjuncției evaluărilor și a setului de reguli, iar obținerea unor valori
consistente pentru variabilele necunoscute se poate face începând să se aplice regulile
până când evaluarea booleană devine stabilă, adică logica - valoarea nici o variabilă
nu se mai modifică. Cu toate acestea, poate fi ineficientă utilizarea acestei metode,
deoarece numărul de evaluări poate crește exponențial cu numărul de variabile.
4.2.1.2 Exemplu de raționament la un robot
Prin analogie cu definițiile anterioare [4.12-4.14] ale arhitecturilor

asemănătoare AgentSpeak pentru agenți robotici de tipul credință-dorință-intenție
de, se poate defini sistemul de raționament, astfel:
 = F , B, L,  , A
unde:

▪ F = p1 , p2 , 
, pnp - este ansamblul tuturor predicatelor;
▪ B ⊂ F - este setul total de convingeri la nivel atomic. Baza de convingeri
curentă la momentul t este definită ca Bt ⊂ B. La momentul t convingerile
care sunt adăugate, șterse sau modificate sunt considerate evenimente și sunt
incluse în setul Et ⊂ B, care se numește setul de evenimente. Evenimentele
pot fi interne sau externe, în funcție de faptul că sunt generate de o acțiune
internă, caz în care sunt denumite „note mentale”, sau o intrare externă, caz
în care se numesc „percepții”;

▪ L = R P  R B = l1 , l2 , 
, lnl - este un set de reguli de implicare;

▪  = 1 , 2 , 
, n - este setul de planuri executabile sau biblioteca de
planuri. Planurile curente aplicabile la momentul t fac parte din subsetul Πt
⊂ Π, acest set este numit și setul Desire. De asemenea, este definit un set I
⊂ Π de intenții, care conține planuri pe care agentul este angajat să le
execute;

▪ A = a1 , a2 , 
, ana  F \ B - este un set care cuprinde toate acțiunile
disponibile. Acțiunile pot fi interne, când modifică baza convingerilor sau
generează evenimente interne, fie externe, atunci când sunt legate de funcții
externe care operează în mediu.
Limbajul de programare de tip AgentSpeak, inclusiv Arhitectură limitată de
seturi de instrucțiuni (Limited Instruction Set Architecture - LISA) [4.15,4.16], pot
fi complet definite și implementate prin enumerarea următoarelor caracteristici:
▪ convingeri inițiale: convingerile și obiectivele inițiale B0 ⊂ F sunt un set de
litere care sunt copiate automat în baza de credințe Bt (care este setul de
convingeri actuale) atunci când mintea agentului este lansată pentru prima
dată;
▪ acțiunile inițiale: acțiunile inițiale A0 ⊂ A sunt un set de acțiuni care sunt
executate atunci când mintea agentului este executată pentru prima dată.
Acțiunile sunt în general obiective care activează planuri specifice;
▪ reguli logice: un set de reguli de implicare bazate pe logică L = R  R
P B
descriu raționamentele teoretice despre fizică și despre regulile de

comportament pentru a redefini cunoștințele actuale ale robotului despre
mediul înconjurător și pentru a influența decizia acestuia cu privire la
acțiunile care trebuie întreprinse;
▪ planuri executabile: un set de planuri executabile sau bibliotecă de planuri
Π. Fiecare plan π j este descris sub forma:
p j : c j  a1 , a2 , , anj
unde: p j  Pt este un predicat declanșator obținut prin consistența în

Ut  Ft  Pt  Bt și posibila evaluare pentru cea mai bună alegere a pj din Pt.
Apoi, p j  Pt permite recuperarea planului din biblioteca planului ori de câte ori
devine adevărat; c j  B se numește context, care permite agentului să verifice

starea lumii, descrisă de setul de credințe actual Bt, înainte de a aplica un anumit
plan; a1 , a2 , , an  A formează o listă de acțiuni care trebuie executate.
j
Pașii de mai sus se repetă ciclic pentru a rula procesul de raționament al unui
agent robotizat.
4.2.1.3 Sisteme de evoluție Booleană
O Diagramă de Decizie Binară (Binary-Decision-Diagram - BDD) [4.17] este

o reprezentare succintă a unui set de evaluări booleene și, motivat de aceasta,
examinăm posibilitatea aplicării verificării modelului simbolic prin intermediul
BDD-urilor pentru a verifica consistența și stabilitatea. În acest fel, evităm explozia
combinatorie a evaluărilor. Vom arăta că verificarea modelului bazat pe BDD este
foarte eficientă pentru ca o sarcină să fie realizată în timp real, în timp ce agentul
trebuie să ofere răspunsuri rapide mediului său. Deoarece procesele de percepție ale
agenților sunt adesea predispuse la erori într-o lume fizică din cauza senzorilor sau
a condițiilor de mediu nefavorabile, aceasta este o problemă importantă a sistemelor
robotizate.
Definiție 1 - Sistem de evoluție booleană

Un sistem de evoluție booleană (Boolean Evolution System) BES = B, R
este compus dintr-un set de variabile booleene B = b1 ,  , bn și un set de reguli de


evoluție R = r1 , , rm definit peste B. O regulă ri este de forma g → X, unde g
este garda, adică o formulă booleană peste B și X este o atribuire care atribuie
adevărat („1”) sau f alse („0”) La o variabilă booleană b ∈ B. Pentru simplitate,
scriem o regulă de forma g → b := true ca g → b și scriem g → b := false ca
g → b . De asemenea, grupăm regulile cu aceeași gardă într-una. De exemplu,
două reguli g → b și g → c pot fi scrise ca g → b  c .
În practică, setul B este de obicei împărțit în 2 subseturi: Bcunoscut/known și

Bnecunoscut/unknown, unde variabilele din prima sunt inițializate fie la true, fie la false, iar
variabilele din cea de-a doua inițializate la necunoscut. În consecință, garanția unei
reguli poate fi evaluată la true, false și unknown. Ultimul caz poate apărea atunci
unknown
când garanția conține o variabilă în B .
Pentru a modela un sistem de raționare și reprezentare a cunoașterii bazat pe

predicate în Fig. 4.7 de către un BES, traducem fiecare predicat în Bt, acțiune în At
și eveniment viitor în Ft într-o variabilă booleană și fiecare regulă de raționament din
R P  R B într-o formulă booleană . În special, predicatele de detectare incerte din
Ut  Bt și evenimentele viitoare din Ft sunt plasate în B necunoscut, iar cele din
Bt \Ut și acțiunile din At sunt plasate în B known .
()
Fie B o evaluare a variabilelor booleene, iar B b valoarea variabilei b în B
. Spunem că o regulă r  R este activată dacă garda sa g este evaluată la true pe B
. Noua evaluare, după aplicarea regulilor de evoluție la B , sunt definite de semantica
de evoluție sincronă după cum urmează.
Definiție 2 - Semantica de evoluție sincronă

Fie R B  R setul de reguli care sunt activate. Noua evaluare B este
rezultatul aplicării simultane a tuturor regulilor din R B la B . Adică, fiecare valoare

a lui b în B este definită după cum urmează.
 true dacă există regula g → b în R B

B (b) =  false dacă există regula g → b în R B
 B (b) în caz contrar
Evoluția de la B la B este scrisă ca B → B . Presupunem că pentru fiecare
evaluare există un set ne-gol de reguli activate.
Definiție 3 - Stabilitate
Un sistem de evoluție boolean este stabil dacă, din orice evaluare și aplicând
recursiv regulile, ajunge în cele din urmă la o evaluare B în care nu se poate obține nicio
altă evaluare, adică B = B . Spunem că B este o evaluare stabilă, scrisă ca BS .
Dacă stabilitatea se întâmplă ea este decisă de agent: doar dacă două etape
consecutive în evoluție au evaluări identice.
Definiție 4 - Inconsistență
Trei probleme pot apărea în timpul evoluției unui BES:
1. două reguli activate încearcă să actualizeze aceeași variabilă booleană cu
valori opuse la un moment dat;
known
2. o variabilă în B este actualizată la valoarea opusă valorii sale inițiale
la un moment dat;
unknown
3. o variabilă din B este actualizată la valoarea opusă la un moment
dat după ce valoarea sa a fost determinată1.
Dacă se întâmplă oricare dintre aceste probleme, spunem că sistemul este

inconsistent. În caz contrar, sistemul este consecvent.
Aceste probleme ar trebui identificate atunci când este programat un software
robotizat.
De exemplu, implementările de agenți raționali credință-dorință-intenție
aplică regulile logice în fiecare ciclu de raționament în Jason, 2AP L și Jade [4.7-
known
4.9]. În cadrul unui ciclu de raționament, unde intrarea variabilelor din B se
menține constant. Acest lucru justifică a doua și a treia problemă din Definiția 4.
Exemplu 1:
a → b  c
b → c
Acest exemplu demonstrează inconsecvența sub semantica sincronă. Pentru
evaluarea inițială a = true  b = c = unknown , atât prima, cât și a doua regulă sunt
activate, ceea ce face ca b = false și c = true . În următoarea iterație de evoluție,
a doua regulă stabilește c = true , în timp ce a treia stabilește c = false . În Fig. 4.8
este ilustrată evaluarea în aceste evoluții a iterațiilor.
Fig. 4.8 Procesul de evoluție care arată inconsecvență.
Următorul rezultat poate fi utilizat pentru a furniza un algoritm simplu pentru

rezolvarea problemei (1) a agentului.
Teorema 1:
Fie B o evaluare booleană a variabilelor din setul de reguli R. Dacă sistemul
de evoluție boolean nu este stabil atunci B și R sunt inconsistențe pe care agentul le
poate detecta din aceeași evaluare reapărând în timpul evoluției booleene.
Demonstrație: dacă evoluția nu este stabilă, atunci în timpul etapelor de

tranziție între o recurență a aceleiași evaluări, unele evaluări trebuie să fie diferite,
altfel evoluția ar fi stabilă cu evaluarea t care a avut loc la două evaluări identice
consecutive. Pe măsură ce o evaluare reapare, acest lucru înseamnă că unele valori
variabile în acea evaluare sunt schimbate între cele două apariții identice ale
evaluărilor. Să fie o astfel de variabilă. Regulile logice aplicate, care au dus la
reapariția evaluării, au forțat, de fapt, cel puțin o dată să se schimbe la valoarea sa
opusă și ulterior să se schimbe înapoi. Aceasta înseamnă că setul de reguli R pentru
evaluarea inițială este incompatibil cu regulile, adică R nu este satisfăcător pentru
nici o evaluare care este în concordanță cu evaluarea inițială B .
Teorema 1 arată că stabilitatea este garantată în sisteme consistente. Cu

toate acestea, pentru anumite sisteme, condițiile de inconsecvență din Definiția 4
sunt considerate inutile stricte, deoarece valoarea inițială a variabilelor cunoscute
nu poate fi obținută direct din mediu. Prin urmare, aceste valori pot fi uneori
incorecte. Pentru a atenua această problemă, a doua și a treia condiție de
inconsecvență din Definiția 4 pot fi relaxate. Folosind acest principiu, spunem
că a doua și a treia condiție sunt rezolvabile dacă sistemul ajunge în cele din urmă
la o stare stabilă, ignorând aceste două condiții. Acest principiu face ca
verificarea consistenței și stabilității să nu mai fie simplă: unele reguli pot corecta
evaluările unor predicate.
Exemplu 2:
a →bd
b  d → c  a
c  d → b
b  d → c
cd →b
b  c → d
Acest exemplu arată un sistem consistent și stabil, unde B

known
= a și
Bunknown = b, c , d . Folosim o secvență de „0”, „1” și „?” pentru a reprezenta
stările. De exemplu, starea inițială „0 ???” reprezintă
a = false  b = unknown  c = unknown  d = unknown .
• pentru evaluare a = false , evoluția este 0??? - → 0??? - → · · ·;
• pentru evaluare a = true , avem 1??? - → 11?1 - → 0101 - → 0001 - →
0011 - → 0111 - → 0100 - → 0100 - → · · ·.
4.2.1.4 Modelarea sistemelor de evoluție booleană
Pentru a putea înțelege sistemele de evoluție booleene trebuie să descriem

modul de activare a verificării modelelor. În primul rând, se vor introduce sisteme
de tranziție, care sunt un formalism matematic aflat la baza verificării modelului. În
al doilea rând, se prezintă un exemplu de codificare a unui sistem de evoluție boolean

sub semantica sistemelor de tranziție folosind un limbaj de intrare al unui verificator
de model.
4.2.1.4.1 Sisteme de tranziție
Verificarea modelului se efectuează de obicei pe sistemele de tranziție. Aici

se prezintă definiția sistemelor de tranziție și traducerea unui sistem de evoluție
boolean într-un sistem de tranziție.
Definiție 5 – Sistem de tranziție

Se consideră că un sistem de tranziție este un tuplu de felul următor
M S, S0 , T , A, H , în care:
• S - este un set finit de stări;
• S0  S - este un set de stări inițiale;
• T  S  S - este relația de tranziție;
• A este un set de propoziții atomice;
• H : S → 2 A - este o funcție de etichetare care mapează stările la setul atomic
al propoziției A. Notăm ansamblul de propoziții atomice valabile în stare s
de H(s).
( )
Fie S  S un set de stări. Funcția Image S , T calculează stările succesorale
ale lui S sub T . Formal:

Image (S , T ) = s  S s  S astfel încât (s, s)  T 
Dat fiind un sistem de evoluție boolean BES = B, R cu n1 variabile
necunoscute, adică, 
Bunknown = b1 , , bn1  și n2 variabile cunoscute, adică

B known = bn1 +1 , 
, bn1 + n2 , fie 
A = B1 , , Bn1 , Bn1 +1 , 
, Bn1 + n2 

 D1 , , Dn1 , Dn1 +1 ,  
, Dn1 + n2  Kn1 +1 , , Kn1 + n2  , unde B i este o propoziție
atomică reprezentând că o variabilă bi  Bunknown  B known is true , Di reprezentând

că bi este falsă și Kj reprezentând că o variabilă necunoscută bj  B
unknown
are valoare
necunoscută. Un sistem de tranziție (TS) M poate fi generat din BES după cum urmează:
1. S este compusă din toate evaluările 3 1  2
n n2
ale lui B.
n2 known
2. S0 este compusă din toate evaluările 2 în cazul în care variabilele din B
unknown
pot lua fie adevărat, fie fals, iar variabilele din B sunt necunoscute.
( ) ( )
3. O tranziție B , B  T iff B → B . În prezența actualizării incoerente a
unor variabile booleene, evaluarea succesorului este aleasă aleatoriu, ceea
ce duce la stări succesorale multiple. De exemplu, se ia în considerare o
evaluare s de unde o variabilă booleană a poate fi actualizată la adevărat
prin regula r1 și false prin regula r2. În sistemul de tranziție, s are două stări
succesorale, adică evaluare: o stare conține a = true și cealaltă conține
a = false . Dacă există k variabile booleene care sunt actualizate
inconsecvent în s, atunci s are 2k stări succesorale.
( )
4. H B este definit astfel încât pentru fiecare variabilă bi  Bunknown  B known
( ) ( )
, Bi  H B iff bi = true , Di  H B iff bi = false și pentru fiecare
variabilă bj  B
unknown
( )
, K j  H B iff bj = true .
unknown
De reținut că toate valorile de intrare posibile ale variabilelor din B sunt
unknown
capturate de S0, adică fiecare evaluare posibilă a B este codificată într-o stare
inițială în S0.
Setul de stări și relația de tranziție într-un sistem de tranziție pot fi ilustrate ca
( )
un grafic direct, unde o tranziție s1 , s2  T este reprezentată de o săgeată de la s1
la s2. În prezintă graficul direcționat pentru Exemplul 1.
Fig. 4.9 Sistemul de tranziție pentru Exemplul 1.

4.2.1.4.2 Implementare
Un sistem de evoluție boolean poate fi scris ca un program în limbajul de intrare

al unui model de verificare simbolic, cum ar fi NuSMV [4.18]. Programul este apoi
analizat de modelul de verificare pentru a construi un sistem de tranziție. Astfel,
modelarea unui sistem de evoluție boolean printr-un program ISPL (Interpreted System
Programming Language) [4.19], inspirat din semantica Sistemului Interpretat [4.20],
iar sistemul de tranziție corespunzător poate fi generat de verificatorul de model
MCMAS [4.19]. Se folosește Exemplul 1 pentru a ilustra cum se construiește un
program ISPL din sistemul de evoluție boolean BES = Bunknown  B known , R .
Un program ISPL conține un set de agenți, un set de propoziții atomice, o
expresie, care reprezintă stările inițiale și un set de formule logice reprezentând
specificațiile sistemului. Structura programului este următoarea:
Agent 1 … end Agent
Agent n … end Agent

Evaluation end Evaluation
InitStates end InitStates
Formulae end Formulate
unde propozițiile atomice sunt definite în secțiunea „Evaluare” și stările inițiale
definite în „InitStates”. Fiecare agent este compus dintr-un set de variabile de
program, un set de acțiuni pe care agentul le poate executa, un protocol și o funcție
de evoluție. Fiecare agent are un set de stări locale care sunt codificate de variabilele
sale de program: fiecare evaluare a variabilelor este o stare locală. Protocolul său
definește un set de acțiuni activate pentru fiecare stat local, iar funcția sa de evoluție
specifică relația de tranziție între statele sale locale.
Structura unui agent M este mai jos:
Agent M
Vars: … end Vars
Actions =  
Protocol: end Protocol
Evolution: end Evolution
end Agent
Pentru a codifica un BES într-un program ISPL, avem nevoie doar de un
agent, iar acest agent are o singură acțiune, care este activată în fiecare stat local. În
restul acestei secțiuni, oferim detalii despre construcția programului ISPL.
Definiția acțiunilor și a protocolului este omisă, deoarece acestea nu afectează
traducerea BES.
1. După cum s-a explicat mai înainte, nu listăm direct toate stările din spațiul
de stare S al sistemului de tranziție corespunzător. În schimb, definim
variabilele programului pentru a se potrivi cu variabilele din BES. Fiecare
known
variabilă din B este tradusă într-o variabilă booleană în ISPL și fiecare
unknown
variabilă din B într-o variabilă enumerată cu trei valori “True, False
și Unknownˮ. Codul ISPL corespunzător pentru exemplul 1 este după cum
urmează.
Vars
a: boolean;
b: True,False,Unknown
c: True,False,Unknown
end Vars
2. Fiecare regulă de evoluție este tradusă într-o tranziție protejată „c if g” în
ISPL, unde garda g este o expresie booleană peste variabile și c este un set
de atribuții. Într-adevăr, semantica unei tranziții păzite se potrivește exact
cu cea a unei reguli de evoluție. Regulile din Exemplul 1 sunt traduse în
codul ISPL de mai jos.
Evolution
b=false if a=true;
c=true if a=true;
b=false if c=false;
end Evolution
unknown
3. Deoarece fiecare variabilă din B în BES este inițializată la
necunoscută, trebuie să specificăm acest lucru în secțiunea de IniStates
într-un program ISPL. Următorul cod este generat pentru Exemplul 1.
InitStates
M.b=Unknown and M.c=Unknown;
end InitStates
De menționat că M este numele agentului, care încapsulează variabilele și
tranzițiile, iar M.x se referă la variabila x din M.
4. O propoziție atomică în ISPL are forma „x if g”, unde x este numele
propoziției atomice, iar g este o expresie booleană care definește setul de
stări pe care le deține x. Adică, x se păstrează în orice stare a cărei evaluare
corespunzătoare satisface g. Codul ISPL pentru Exemplul 1 este mai jos.
Evolution
a_true if M.a=true;
a_false if M.a=false;
b_true if M.b=true;
b_false if M.b=false;
b_unknown if M.b=unknown;
c_true if M.c=true;
c_false if M.c=false;
c_unknown if M.c=unknown;
end Evolution
Pașii de construcție de mai sus sugerează că un compilator poate fi produs fără
dificultăți la codul ISPL generat automat dintr-un sistem de evoluție boolean dat. Există
posibilitatea de a codifica o evoluție booleană din ISPL, de a construi și compila pentru

alte verificatoare de model simbolic, atunci când este necesar. De exemplu, semantica
limbajului de intrare al NuSMV este similară cu cea a ISPL în această setare, deoarece
nu se folosește capacitatea de a specifica acțiuni și protocoale în ISPL.
4.2.1.5 Verificarea stabilității și a inconsecvenței
Logica arborelui de calcul (Computation Tree Logic - CTL) [4.21] și logica

temporală liniară (Linear time Temporal Logic - LTL) [4.22] sunt cele mai populare
logici adoptate în verificarea sistemelor de tranziție pentru a specifica proprietățile
pe care le poate avea un sistem investigat. CTL este o logică a timpului de ramificare,
care ia în considerare toate posibilitățile de comportament viitor, în timp ce LTL se
ocupă doar de un posibil comportament viitor la un moment dat. În această secțiune,
folosim CTL pentru a formula verificări de stabilitate și incoerență datorită
implementării eficiente a verificării modelului CTL. Dar discutăm și aplicarea LTL
atunci când este posibil.
4.2.1.5.1 CTL și LTL
LTL poate fi specificat prin următoarea gramatică [4.23]:
 ::= p         
CTL, pe de altă parte, este dat de gramatica extinsă [4.23]:
 ::= p     EX EG EF E ( ) AX AG AF A ( )
Atât CTL cât și LTL sunt definite pe căi într-un sistem de tranziție. Având în
vedere un sistem de tranziție M S , S0 , T , A , H o cale  = s0 s1 sk este o
secvență (finită sau infinită) de stări astfel încât pentru fiecare pereche de stări
adiacente, există o tranziție în sistem, adică, si  S pentru toți 0  i  k și
(s , s )  T pentru toate 0  j  k . Notăm starea i în calea ρ, adică, s , prin  (i) .

j j +1 i
Satisfacția CTL și LTL în M este definită după cum urmează.
Definiție 6 – Satisfacția CTL

Având în vedere un sistem de tranziție M S , S0 , T , A , H și o stare s  S ,
satisfacția pentru o formulă CTL  la starea s în M, notată cu s =  , este definită

recursiv după cum urmează:
()
• s = p iff p  H s ;
• s =  dacă nu este cazul s =  ;
• s = 1  2 dacă s = 1 și s = 2 ;
()
• s = EX dacă există o cale ρ începând cu s astfel încât  1 =  ;
• s = EG dacă există o cale ρ începând cu s astfel încât  (i ) =  pentru

orice i  0 ;
()
• s = EF dacă există o cale ρ începând cu s astfel încât  i =  pentru
orice i  0 ;
(
• s = E 1 2 ) dacă există o cale ρ începând cu s astfel încât  (i ) = 2
()
pentru orice i  0 și  j =  pentru orice 0  j  i ;
1
()
• s = AX dacă există o cale ρ începând cu s, astfel încât,  1 =  ;
• s = AG dacă există o cale ρ începând cu s, astfel încât,  (i ) =  pentru

orice i  0 ;
()
• s = AF dacă există o cale ρ începând cu s astfel încât  i =  pentru
orice i  0 ;
• s = A 1( 2 ) dacă există o cale ρ începând cu s astfel încât  (i ) = 2
()
pentru orice i  0 și  j =  pentru orice 0  j  i ;
1
Definiție 7 – Satisfacția LTL

Având în vedere un sistem de tranziție M S , S0 , T , A , H și o stare s  S ,
satisfacția pentru o formulă LTL  la starea s în M, notată cu s =  , este definită

recursiv după cum urmează:
• s = p iff p  H s ;()
• s =  dacă nu este cazul s =  ;
• s = 1  2 dacă s = 1 și s = 2 ;
()
• s =  dacă există o cale ρ începând cu s astfel încât  1 =  ;
• s=  dacă există o cale ρ începând cu s astfel încât  (i) =  pentru orice

i 0;
()
• s =  dacă există o cale ρ începând cu s astfel încât  i =  pentru orice
i 0;
• s = 1 2 dacă există o cale ρ începând cu s astfel încât  (i ) = 2 pentru
()
orice i  0 și  j =  pentru orice 0  j  i ;
1
Când verificăm dacă o formulă CTL/LTL  se menține pe un model, se verifică
dacă această formulă este satisfăcută de toate stările inițiale, notate cu M =  . În
special, când spunem că un LTL  se menține în model, fiecare cale din fiecare
stare inițială trebuie să satisfacă  . Mai multe detalii despre CTL și LTL, precum și
diferența dintre ele, pot fi găsite în [4.23].
4.2.1.5.2 Formularea stabilității și inconsecvenței prin formule logice
Lema 1: Prima categorie de inconsecvență poate fi verificată prin următoarea

formulă CTL:
AG  ( EXB1  EXD1 )    ( EXBn  EXDn )
Demenstrație: Dacă un sistem este inconsistent din cauza primului caz, atunci
trebuie să existe o stare care are două stări succesorale astfel încât o variabilă să fie
evaluată la adevărat într-o stare succesivă și la falsă în cealaltă. Formula CTL
(EXB  EXD )
i i surprinde acest scenariu pentru variabila bi. Negarea  ( )
exclude apariția inconsecvenței cauzate de bi. Operatorul AG garantează că
inconsecvența nu apare în nici un caz. Nu este necesar să fie luat în considerare un
( )
caz precum EXKi  EXBi  EXDi pentru o variabilă necunoscută deoarece nu
poate fi atribuită necunoscutului în timpul evoluției.
Dacă formulele de mai sus sunt evaluate la adevărate, atunci sistemul de evoluție
boolean este consecvent. Această categorie de inconsecvență nu poate fi verificată printr-
o formulă LTL, deoarece LTL poate specifica numai proprietăți liniare.
Cu toate acestea, o mică modificare ar face LTL să funcționeze din nou la
verificarea coerenței. Lema 1 caută apariții de inconsecvență verificând dacă două valori
opuse ale unei variabile pot fi atinse dintr-o stare. Următoarea teoremă se concentrează
pe căutarea unei astfel de stări pentru efectuarea verificărilor de consistență.
Teorema 2: Verificarea primei categorii de inconsecvență poate fi

transformată într-o problemă de accesibilitate, după cum urmează.
1. Pentru fiecare pereche de reguli g1 → X1 și g2 → X2 , verificați dacă X1
și X2 atribuie valori opuse aceleiași variabile booleene. Dacă răspunsul este
da și g1  g2  false , atunci se adăugă o nouă propoziție atomică C care

se menține în stări care satisfac g1  g2 .

2. Fie C = C1 , , Cm setul tuturor propunerilor nou adăugate în pasul
anterior. Prima categorie de inconsecvență poate fi identificată prin formula
CTL:
EF (C1   Cm )
sau formula LTL:
 (C1   Cm )
Demonstrație: dacă o stare îndeplinește o propoziție Ci, care este construită ca
g j1  g j2 , atunci ambii paznici g j1 și g j2 sunt satisfăcuți în starea respectivă. Astfel,
regulile corespunzătoare g j → X j și g j → X j sunt activate în stare. Deoarece
1 1 2 2
aceste două reguli stabilesc valori opuse unei variabile, inconsecvența apare în această
stare dacă este accesibilă dintr-o stare inițială. C surprinde toate statele în care s-ar putea
întâmpla inconsecvență, iar EF și  examinează dacă oricare dintre aceste stări poate fi
atinsă dintr-o stare inițială. De reținut că:
EF (C1   Cm )   ( EFC1   EFCm )

și
 (C1   Cm )   (C1   Cm )

Deși al doilea și al treilea caz nu sunt necesare în condiții de inconsistență relaxate,
se prezintă în continuare proprietățile logice temporale pentru verificarea lor.
Lema 2: A doua categorie de inconsecvență poate fi verificată prin următoarea

formulă CTL:
AG  (
 B  EXD
n1 +1 n1 +1 ) (
  Dn1 +1  EXBn1 +1 

)
   ( Bn  EXDn )   ( Dn  EXBn ) 
sau formula LTL:

(
 B  D
n1 +1 n1 +1 ) (
  Dn1 +1  Bn1 +1 

)
   ( Bn  Dn )   ( Dn  Bn ) 
Demonstrație: dacă apare acest caz, atunci trebuie să existe o stare s care are o
stare de succes s0 astfel încât o variabilă să fie evaluată la adevărat în s și false în s0, sau
(
false în s și adevărat în s0. Formulele CTL Bi  EXDi și Di  EXBi ) ( ) pentru
(n + 1  i  n) surprind acest scenariu pentru variabila b .

1 i Formulele LTL
( B  D ) și ( D  B ) au același efect. Negarea  ( )

i i i i exclude apariția
inconsecvenței cauzate de bi. Operatorul AG (sau ) garantează că inconsecvența nu
apare în nici o stare.
A treia categorie de inconsecvență poate fi verificată în același mod peste
variabilele necunoscute.
Lema 3: Problema stabilității poate fi verificată prin următoarea formulă CTL:
( AGB1  AGD1  AGK1 )  

(
 AGB  AGD  AGK  
AF   )
( )
n1 n1 N1
 AGBn +1  AGDn +1   
 AGB 1  AGD 1 
( n n) 
sau formula LTL
( B1  D1  K1 )  


( Bn1  Dn1  K N1   )


( )
Bn1 +1  Dn1 +1   

( Bn  Dn ) 
Dacă formula LTL sau CTL de mai sus este evaluată la adevărată, atunci sistemul
de evoluție boolean este stabil.
Demonstrație: într-un sistem stabil, fiecare cale duce la o stare stabilă, în care
nicio variabilă necunoscută nu își va mai schimba valoarea. Prin urmare, unul dintre cele
trei cazuri Bi , Di sau Ki pentru variabila necunoscută bi se menține în stare
stabilă.
Ultimul caz înseamnă că variabila necunoscută rămâne necunoscută pe
parcursul evoluției. Variabilele cunoscute nu pot lua valoare necunoscută. Astfel, nu
este nevoie să le considerăm necunoscute în formula LTL. Operatorul specifică că
această stare stabilă va fi atinsă în cele din urmă. Formula CTL poate fi argumentată
într-un mod similar.
4.2.1.5.3 Algoritmi eficienți pentru verificarea stabilității

și a inconsistenței
Deși Teorema 2 oferă o formulă CTL/LTL mai simplă decât Lema 1, în

practică, ea poate fi îmbunătățită în continuare. Pentru a verifica dacă formula EF
este satisfăcută într-un sistem de tranziție M S, S0 , T , A , H prin verificarea
modelului simbolic, trebuie să calculăm setul de stări care îndeplinesc formula EF
()
utilizând un calcul în punct fix . Fie SAT  să reprezinte ansamblul stărilor care
( )
îndeplinesc  . Calculul punctului fix începe cu un set X0 = SAT  și calculează
o succesiune de mulțimi astfel încât X0  X1  Xn  Xn+1 până la Xn = Xn+1 .
Algoritmul detaliat este prezentat în Algoritmul 1.
Algorithm 1 Compute SAT EF ( )

1 : X := SAT () ; Y := 
2 : while Y  X do

3 : Y := X ; X := X  s  S s  X a.î . (s , s)  T 
4 : end while
5 : return X
Algoritmul 1 ar putea consuma mult timp pentru un sistem mare. Din fericire,
putem utiliza o caracteristică a verificării modelului pentru a evita problema
verificării EF. Un model de verificare generează numai stări accesibile, care pot fi
atinse din stări inițiale, și efectuează algoritmi de verificare a modelelor pe stările
accesibile. Pentru a identifica inconsecvența, este suficient să arătăm existența unui
stat accesibil cu două state succesorii conflictului. Întrucât modelele de verificare
funcționează numai pe stări accesibile, existența unei stări proaste poate fi convertită

în non-vid al setului de stări care îndeplinesc C = C1 , , Cm definit în Teorema
2, returnat de un model de verificare. Prin urmare, calculul punctului fix pentru EF
poate fi evitat. Într-adevăr, verificarea existenței stărilor proaste poate fi integrată în
procesul de generare a spațiului statal accesibil. Odată ce se găsește o stare proastă,
procesul poate fi întrerupt pentru a oferi feedback rapid programatorului.
Pentru un sistem de mari dimensiuni, formula CTL specificată în Lema 3 implică
un număr mare de clauze de conjuncție ( AGB  AGD  AGK )
i i i sau
( AGB  AGD ) și fiecare AG necesită un calcul de punct fix fix scump, deoarece
j j
AG = EF () . Prin urmare, verificarea modelului acestei formule ar putea
consuma mult timp. Următoarea teoremă ne spune că verificarea stabilității poate fi
redusă la o problemă de accesibilitate, care cere doar un singur calcul în punct fix.
Teorema 3: Stabilitatea într-un sistem consistent M S, S0 , T , A , H poate fi

verificată în următorii trei pași.
1. Găsiți setul X de stări care au doar tranziții de auto-buclă, adică
 
X = s  S s a.î . ( s , s)  T implică s = s ;
2. Găsiți mulțimea Y a stărilor care pot ajunge la stări în X;
3. Verificați dacă S0  Y . Dacă răspunsul este da, atunci sistemul este stabil
dacă este consecvent.
Demonstrație: Din definiția stabilității, știm că o evaluare stabilă corespunde

unei stări care are doar bucle de sine și invers. Într-un sistem consecvent, o stare nu
poate intra într-o buclă nestabilă dacă poate ajunge la o stare stabilă. În caz contrar,
există un stat care are două stări succesorii, ceea ce contrazice presupunerea că
sistemul este consecvent. Pasul 3 verifică dacă există o stare inițială care nu poate
ajunge la o stare stabilă. Existența unei astfel de stări înseamnă că sistemul conține
o buclă nestabilă.
4.2.1.5.4 Implementare
De exemplu, biblioteca CUDD [4.24] poate fi utilizată pentru a manipula

BDD-urile în MC-MAS. Primul pas poate fi implementat folosind funcția
„Cudd_Xeqy” în CUDD, care construiește un BDD pentru funcția x = y pentru două
seturi de variabile BDD x și y. Atunci când este aplicată relației de tranziție în sistem,
această funcție impune pur și simplu că starea succesorală a unei stări s este ea însăși,
adică o buclă de sine. Al doilea pas poate fi realizat de algoritmul clasic de verificare
a modelului pentru EF. Al treilea pas se face verificând dacă S0 − Y este un BDD
zero, ceea ce înseamnă că rezultatul din scăderea setată S0 − Y este gol.

Prin urmare, acest algoritm rulează mai eficient decât modelul care verifică
formula lungă din Lema 3. În practică, această verificare a stabilității poate fi
combinată cu verificări de consistență. În timpul generării spațiului de stare accesibil,
verificăm dacă sistemul este consecvent utilizând Teorema 2. Dacă generația nu este
întreruptă din cauza apariției unor stări incoerente, atunci se execută o verificare a
stabilității.
4.2.1.5.5 Generarea contraexemplului
O întrebare obișnuită adresată după verificarea modelului unei formule este

dacă se poate genera o execuție a martorului sau un contraexemplu pentru a facilita
înțelegerea profundă a motivului pentru care formula deține sau nu în sistem. În situația
noastră, este firesc să solicităm modelului de verificare să returneze toate urmele
evoluției care duc la inconsecvență sau instabilitate. Vom arăta cum să calculăm
urmele în MCMAS pentru inconsecvență mai întâi și pentru instabilitate după aceea.
De obicei, în practică este bine să se genereze cele mai scurte urme pentru
contraexemple / execuții ale martorilor pentru a reduce dificultatea înțelegerii
acestora. Pentru a realiza acest lucru pentru setarea noastră, utilizăm abordarea
construcției spațiului de stat în MCMAS. Pornind de la setul de stări inițiale S0,
MCMAS poate calcula spațiul de stare în modul următor [4.19].
Algorithm 2 Compute reachable states
1 : S := ; next := S0 ; q := S0
2 : while S  q do
3 : S := q; next := Image (next , T ) : n := next \S; q := S  next ;
4 : end while
5 : return S
În acest algoritm, S este setul de stări accesibile și next , inițializat ca S0, este
setul de stări pe care stările lor succesorii trebuie să fie calculate, ceea ce se face prin
( )
funcția Image next , T . În fiecare iterație, calculăm succesorii next de next și
eliminăm din next stările care au fost procesate anterior de next − S . Această
iterație continuă până când nu se pot adăuga stări noi la S, adică next − S =  .
Modificăm algoritmul de generare a spațiului de stare pentru a stoca fiecare
intermediar next : în fiecare iterație i, ne schimbăm lângă next la nexti
Teorema 4: Cea mai scurtă urmă care duce la o stare inconsistentă prin
activarea regulilor g1 → a și g2 → a , poate fi realizată în pașii următori.
Algorithm 3 Modified state space generation
1 : S := ; next0 := S0 ; q := S0 ; i := 0
2 : while S  q do
3 : i := i + 1
3 : S := q; nexti := Image (nexti −1 , T ) \S; q := S  nexti ;
4 : end while
5 : return S , next0 , , nexti
1. Plecând de la i = 0 , testăm fiecare nexti pentru a căuta cel mai mic indice
k astfel încât nextk  g1  g2   .
2. Preluăm o stare arbitrară sk din nextk  g1  g2 și calculăm predecesorul
său sk − 1 în nextk −1 utilizând relația de tranziție inversă T  , astfel încât,

sk −1 := sk  T . Dacă sk are mai mulți predecesori, atunci vom alege unul

arbitrar pentru a fi sk −1 . În același mod, calculăm un predecesor al lui
sk − 1 în nextk −2 . Acest proces continuă până când găsim o stare s0 în
next0 , care este S0.
Pentru a găsi cele mai scurte contraexemple pentru buclele instabile, trebuie
să identificăm mai întâi toate aceste bucle și, pentru fiecare buclă, testăm fiecare
nexti de la i = 0 dacă conține o stare în buclă, adică dacă ni  Sloop   , unde Sloop
este setul de stări din buclă. Apoi aplicăm al doilea pas din Teorema 4 pentru a
genera cea mai scurtă urmă. Acum ne concentrăm asupra modului de a găsi eficient
toate buclele instabile.
Lema 4: Având în vedere un sistem consecvent, nici unul dintre buclele

instabile nu interferează unul cu celălalt.
Demonstrație: dacă conjuncția a două bucle nu este goală, atunci există o stare
astfel încât să aibă două tranziții de ieșire, una în fiecare buclă. Prin urmare, această
stare duce la apariția inconsecvenței.
Datorită Lemei 4, găsirea buclelor instabile este echivalentă cu găsirea
componentelor puternic conectate (Strongly Connected Components - SCC)
netriviale atunci când sistemul este consistent.
Există mai mulți algoritmi de identificare SCC în literatura de specialitate care
lucrează la reprezentarea BDD a spațiilor de stare [4.25, 4.26]. Cea mai eficientă a
fost raportată în [4.27]. Dar înainte de a aplica acești algoritmi, am putea elimina
stări care nu pot atinge bucle instabile din spațiul de stare pentru a accelera calculul.
Aceste state sunt identificate ca Y în al doilea pas de verificare a stabilității în
Teorema 3.
4.3 Funcțiile de deliberare ale roboților autonomi
Roboții autonomi care se confruntă cu o diversitate de medii deschise și care

efectuează o varietate de sarcini și interacțiuni, pentru care au nevoie de deliberare
explicită, astfel încât, să își poată îndeplini misiunile. Deliberarea este menită să
înzestreze un sistem robot cu funcționalități extinse, mai adaptabile și robuste,
precum și să reducă costurile de implementare [4.28].
Există cinci funcții de deliberare: planificare, acțiune, monitorizare, observare
și învățare.
4.4 Proiectarea unui sistem de deliberare robotică
4.4.1 Funcții de deliberare

O acțiune este un proces care schimbă starea robotului și a mediului său;

aceasta include acțiuni de percepție și colectare a informațiilor. O acțiune poate fi
vizualizată la diferite niveluri ale ierarhiei abstractizării. Este primitiv la un anumit
nivel și compus la nivelul următor. De exemplu, deschis (ușa) este o acțiune
primitivă la nivel abstract și o sarcină compusă care trebuie rafinată, atunci când este
nevoie, într-o colecție de acțiuni concrete. O comandă este o acțiune primitivă la cel
mai jos nivel al ierarhiei. Comenzile pot fi executate direct de platforma robotului.
Platforma este o colecție de dispozitive și funcții senzoriale-motorii care
integrează senzorul și acționarea în buclă închisă. Alegerea comenzii adecvate și
monitorizarea faptului că, din punct de vedere contextual, rămâne în cadrul unui plic
funcțional al comenzii care face parte din deliberare. Executarea unei comenzi nu
are nevoie de capacități de deliberare. De exemplu, apucarea (mânerul) este o
comandă care, în condiții adecvate, poate fi executată direct de o platformă robotică.
Un plan este o colecție organizată de acțiuni. O politică este un plan universal,
adică o mapare de la state la acțiuni.
O abilitate este, de asemenea, o colecție organizată de acțiuni. Acesta diferă
de un plan prin următoarele: acțiunile sale sunt la un nivel inferior; primitivele sale
sunt comenzi; structura sa de control poate fi mai bogată decât cea a unui plan. O
abilitate este recuperată dintr-o bibliotecă de abilități (programate manual sau
învățate) în timp ce un plan este sintetizat de un planificator.
O sarcină este specificarea unei misiuni sau a unor obiective care trebuie
atinse de robot, sub diferite forme și niveluri de abstracții, de exemplu, ca stări de
obiectiv.
Un eveniment este o apariție a unei schimbări a stării robotului și a mediului
său; poate fi controlat sau exogen, așteptat sau neașteptat.
Cea mai mare parte a literaturii privind acțiunea deliberată este axată pe
planificare. Cu toate acestea, planificarea singură nu este suficientă pentru realizarea
unei acțiuni deliberate. Acțiunea se realizează prin exercitarea unor forțe controlate
asupra mediului. Acesta este implementat la cel mai scăzut nivel prin procesarea
online a fluxurilor de semnale, de la senzori la actuatori. Aceste fluxuri realizează
bucle de feedback robuste la discrepanțele dintre lume și modelele sale. Planificarea,
pe de altă parte, implementează o mapare a intrării sale, un model predictiv și o
problemă, într-un plan de ieșire exprimat într-o anumită reprezentare. Fiind cauza
limitării modelelor predictive și a constrângerilor de complexitate, planificarea
trebuie să admită mai multe ipoteze simplificatoare. Ca rezultat, un plan sintetizat
oferă un curs de acțiune proiectat într-o reprezentare abstractă. Este util, dar rareori
este suficient pentru a acționa în mod deliberat.
Există mai multe acțiuni deliberate decât simpla planificare într-un spațiu
abstract. Pentru acționarea deliberată pot fi necesare mai multe funcții distincte.
Limitele dintre aceste funcții sunt neclare și depind de reprezentări, implementări și
arhitecturi specifice. Cu toate acestea, este clar din punct de vedere conceptual să
distingem următoarele șase funcții de deliberare (Fig. 4.10 a)):
1. Planificare: combină predicția și căutarea pentru a sintetiza o traiectorie

într-un spațiu de acțiune abstract, bazat pe modele predictive ale mediului
și acțiuni fezabile pentru a atinge un anumit scop.
2. Acțiune: rafinează acțiunile planificate în comenzi adecvate contextului
curent și reacționează la evenimente; atât rafinarea, cât și reacția se pot
baza pe abilități, adică o colecție de funcții cu buclă închisă. O abilitate
procesează o secvență (sau un flux continuu) de intrare de stimul de la
senzori și generează ieșire către actuatori, pentru a declanșa forțe motorii
și a controla realizarea corectă a acțiunilor alese.
3. Observare: detectează și recunoaște trăsături și relații care caracterizează
starea lumii, precum și evenimente, acțiuni și planuri relevante pentru
sarcină. Observarea combină procesele de jos în sus, de la senzori la date
semnificative, cu activități de sus în jos, cum ar fi mecanisme de focalizare,
acțiuni de detectare și planificare pentru colectarea de informații.
4. Monitorizare: compară ceea ce se prezice cu privire la activitățile
robotului cu ceea ce este observat în lume. Detectează și interpretează
discrepanțele, efectuează diagnosticul și declanșează acțiuni de recuperare
atunci când este necesar.
5. Raționamentul obiectivelor: este monitorizarea la nivelul misiunii.
Păstrează angajamentele și obiectivele în perspectivă; evaluează relevanța
lor din evoluțiile observate din noi oportunități, constrângeri sau eșecuri;
presupune din această evaluare dacă unele angajamente ar trebui
abandonate și când și cum să actualizeze obiectivele actuale.
6. Învățare: permite unui robot să dobândească, să se adapteze și să
îmbunătățească prin experiență modelele necesare deliberării. Învățarea activă
determină un robot să acționeze în mod deliberat pentru a învăța mai bine.
Fig. 4.10 a) Vedere schematică a funcțiilor de deliberare,

interacțiunile dintre funcții sunt simplificate în exces;
b) Bucle închise imbricate care implementează aceste funcții.
Aceste funcții de deliberare sunt interfațate cu platforma robotului. Frontiera
dintre funcțiile senzorial-motorii și funcțiile de deliberare variază foarte mult în funcție
de complexitatea acțiunilor planificate și de variabilitatea mediului. De exemplu, într-
o sarcină de navigație, controlul mișcării de-a lungul unei căi este o funcție senzorial-
motoră atâta timp cât solul este nominal (adică ferm, stabil). Când robotul iese din
bucla unui mod de control nominal, este necesară deliberarea. Funcțiile senzoriale-
motorii nu ar trebui percepute într-o viziune reducționistă ca simple bucle de control
al feedback-ului. Adesea necesită predicție avansată și monitorizare a condițiilor lor
de funcționare (de exemplu, verificarea stării de control rămâne în anvelopă) și
interacțiuni complexe cu funcții de deliberare. Mai mult, capacitățile de învățare
schimbă frontiera când și unde este necesară deliberarea explicită. De exemplu, într-
un mediu bine cunoscut, o abilitate de navigație către aceeași destinație obișnuită poate
fi compilată într-un control de nivel scăzut cu parametri pre-cache.
Deliberarea este în mod necesar limitată la resurse de calcul mărginite. O
funcție de metarationing poate fi necesară pentru schimbarea timpului de deliberare
pentru timpul de acțiune, având în vedere constrângerile și obiectivele actuale în joc.
Activitățile critice necesită o deliberare atentă, în timp ce sarcinile mai puțin
importante sau mai urgente pot să nu aibă nevoie sau să permită soluții aproximative
mai mult decât rapide, cel puțin pentru o primă reacție.
În cele din urmă, Fig. 4.10 a) nu este completă: interacțiunea, în special
interacțiunea om-robot, este în mod clar o funcție de deliberare. Pentru a păstra un
domeniu de aplicare rezonabil, interacțiunea nu este acoperită în această lucrare.
4.4.2 Caracteristicile și cerințele de deliberare ale aplicațiilor robotice

Deliberarea este implicată de autonomie și diversitate; dar acestea nu sunt

proprietăți binare, fie adevărate, fie false. Când este nevoie de deliberare, aceasta
poate avea caracteristici diferite în funcție de cerințele aplicației de robotică la
îndemână. Să ne uităm la câteva clase tipice de aplicații.
Un satelit autonom are un mediu destul de stabil și previzibil. Are un set de
sarcini bine concentrat, de exemplu, să-și folosească dispozitivele de imagistică
eficient pentru a răspunde la întrebările primite, având în vedere acoperirea în cloud
așteptată sau percepută, și pentru a-și gestiona resursele de comunicare, procesare și
energie. Poate planifica și executa planuri stabile pe orizonturi lungi. Implementarea
sa este costisitoare, ceea ce justifică o inginerie extinsă pentru un comportament
optimizat, cu diagnostic și autoreparare.
Un robot autonom de explorare spațială, de exemplu, Curiosity, se confruntă
cu o diversitate mai mare de sarcini (navigare, observare, eșantionare, comunicare).
Mediul său este variabil, dar destul de previzibil; are o complexitate semantică
redusă. Robotul își controlează dispozitivele senzoriale-motor în conformitate cu
propriile sale planuri. Își monitorizează activitatea, își adaptează și repară planul în
situații neprevăzute. Acesta ia în considerare oportunitățile (de exemplu, o piatră
interesantă) și își gestionează misiunea. Toate aceste funcții de deliberare sunt
integrate la bord și programate corespunzător în ceea ce privește resursele de calcul
limitate. Acestea împărtășesc modele (modele de percepție, modele de acțiune,
modele de abilități, modele de monitorizare etc.), care trebuie să fie consecvente unul
față de celălalt. Aici și misiunea își poate permite o inginerie și o dezvoltare extinse.
Un robot de teren pentru misiuni de supraveghere și salvare are caracteristici
similare, dar se confruntă cu medii mai bogate și mai variabile, mai puțin previzibile
și mai puțin ușor de modelat. Cooperarea și interacțiunea cu roboți umani și alți
roboți este o caracteristică importantă în aceste aplicații. Observații similare sunt
valabile și pentru UAV-uri în misiunile de salvare. Mai mult, un UAV poate fi nevoit
să se confrunte cu o dinamică mai rapidă în sarcinile și mediile sale.
O mașină cu conducere automată trebuie să facă față și dinamicii ridicate, dar
pentru o sarcină foarte concentrată în medii bine structurate.
Problemele critice de siguranță sunt o constrângere puternică asupra funcțiilor
de deliberare.
Un robot de serviciu sau de uz casnic nu trebuie să facă față dinamicii ridicate.
Se confruntă cu medii foarte bogate și o mare diversitate de sarcini. Funcțiile sale de
deliberare ar trebui să îi permită să raționeze cu privire la misiunea sa (de exemplu,
asistarea utilizatorului), să își planifice sarcinile (de exemplu, să servească o masă
simplă), să acționeze conform planului său, rafinând acțiunile în comenzi în buclă
închisă și reacționând la evenimente , pentru a percepe mediul său pentru construirea
și întreținerea modelelor sale. Costurile de inginerie ar trebui să rămână reduse.
Învățarea este importantă (de exemplu, adaptarea abilităților sale la particularitățile
mediului). În cele din urmă, interacțiunea om-robot este esențială pentru roboți de
serviciu și domestici.
Roboții de fabricație se aflau în medii neschimbate protejate, fără a fi nevoie
de deliberare. Acest lucru se schimbă progresiv. Există o cerere pentru roboți foarte
flexibili, care se adaptează cu ușurință la o gamă largă de sarcini și se integrează

perfect în orice mediu de lucru. Acest lucru este mai adevărat pentru roboții mobili
industriali priviți ca asistent al unui muncitor în treburile sale zilnice. Această clasă
de aplicații este, în multe aspecte, similară cu roboții de service și domestici, cu un
accent mai mare pe cooperare și un set mai concentrat de mediu și sarcini.
4.4.3 Opțiuni de proiectare a unui sistem de deliberare
Integrarea funcțiilor de planificare și acțiune este o problemă critică în

proiectarea unui sistem de deliberare. Pentru a clarifica gama de opțiuni de
proiectare, să ne opunem la două puncte de vedere principale, care subliniază
respectiv planificarea și acțiunea.
Accent pe planificare. Această opțiune presupune modele predictive complete,

posibil nedeterministe ale lumii, inclusiv dinamica acesteia și posibilele efecte ale
evenimentelor exogene. Are nevoie de modele reversibile ale capabilităților de
detectare ale robotului, adică de modul în care realitatea este mapată în percepții,
precum și de modele reversibile ale capacităților sale de acționare, adică de modul în
care comenzile sunt mapate în forțe și mișcare. Modelele cinematice inverse mapează
configurațiile dorite în comenzi care le realizează; modelele de detectare inversă
trasează caracteristicile detectate în obiecte din lume. Necesită un planificator care să
ia ca intrare aceste modele predictive globale împreună cu specificațiile misiunii și să
furnizeze ca rezultat un plan sau o politică, cartografierea stărilor (sau credințelor)
percepute în comenzi de nivel inferior, posibil cu o garanție de realizare a misiunii. sau
îndeplinirea unor criterii de optimitate. În această perspectivă, acțiunea este o simplă
declanșare a comenzilor date de politica planificată: la fiecare pas robotul detectează,
adică, citește variabilele de observare curente, aplicând comenzile corespunzătoare
specificate de politică. Rețineți că o abordare discretă a unității de timp trebuie extinsă
în continuare pentru tratarea domeniilor care implică constrângeri bogate în timp și în
timp real. Această viziune principială a inspirat proiectarea câtorva sisteme de
deliberare timpurie. Avea meritul de a clarifica, la nivel conceptual, ce se dorea și cât
de departe erau ținta ideală realizările. Cu toate acestea, aplicabilitatea acestei viziuni
idealiste este limitată de predictibilitatea redusă a majorității mediilor, de dificultățile
uriașe de a specifica modelele necesare și de complexitatea de calcul a planificării.
Accentul pus pe acțiune. Proiectanții au abordat problemele anterioare prin

strategia obișnuită de descompunere, adică descompun sarcina deliberării între o fază
de planificare și o fază de acțiune și se bazează pe ipoteze restrictive la un capăt sau
la altul. În spectrul posibilelor descompuneri și presupuneri, planificarea clasică este
cea mai restrictivă. Presupune un robot cu buclă deschisă într-un mediu determinist,
static (fără evenimente exogene), care este pe deplin observabil (pentru starea
inițială, celelalte stări fiind în întregime previzibile). În consecință, acțiunea trebuie
să gestioneze modele de mediu nedeterministe, parțial observabile și dinamice prin
control cu buclă închisă. Această opțiune pune cea mai mare parte a sarcinii
deliberării cu constrângerile lumii reale (senzori și actuatori zgomotoși, modele

imperfecte) asupra acțiunii.
Această viziune a condus la proiectarea mai multor implementări. Rămâne
popular (desigur, în comunitatea de planificare automată, dar mult mai puțin în
comunitatea de robotică). A dus la dezvoltarea unor tehnici de planificare clasice
scalabile. Dar utilitatea sa s-a dovedit a fi limitată de complexitatea sistemului de
acțiune, eficacitatea îngustă a planificării și slăbiciunea planurilor produse.
Descompunere echilibrată. În rezumat, prima viziune se bazează în totalitate

pe planificare, a doua depinde în mare parte de acțiune fără un ajutor eficient de la
planificare. O opțiune majoră de proiectare este cum să descompunem mai bine
problema complexă de deliberare dintre planificare și acțiune, cum să echilibrăm
procesul de alegere și întreprindere a acțiunilor între diferite niveluri de abstractizare
și granularitate, de la nivelul misiunii la nivelul de detectare și comandă. Sunt
necesare cel puțin trei niveluri (inclusiv nivelul platformei însărcinat cu executarea
comenzilor, în afara sferei deliberării). În principiu, pot fi luate în considerare mai
mult de trei niveluri. Majoritatea abordărilor iau în considerare doar trei niveluri,
care corespund funcțiilor pe care le-am etichetat ca planificare și acțiune, în plus față
de platformă.
Fig. 4.11 De la acțiuni la abilități și comenzi.
Planificarea sintetizează o traiectorie într-un spațiu de acțiune abstract

prevăzut să realizeze (o parte din) misiune a. Actingfined mai departe rafinează
fiecare acțiune abstractă în unul sau mai mulți pași, numiți abilități. Abilitățile sunt
planuri cu pași posibil concurenți ale căror primitive sunt comenzi (Fig. 4.11).
Planificarea necesită modele descriptive care să ofere cerințele și posibilele efecte
ale acțiunilor (know-what).
Acțiunea necesită modele operaționale: cum să rafinezi acțiunile, ce abilitate
să alegi și când, cum să reacționezi la evenimente (know-how). Această viziune este
dezvoltată în continuare în [4.29].
O descompunere echilibrată ar trebui să ofere capacități predictive atât
planificării, cât și acțiunii. Ambele pot efectua operațiuni anticipate, cu diverse
tehnici de planificare. Este important ca planificarea și acțiunea să poată funcționa
în spații de stare și spații de acțiune distincte. Cu toate acestea, ambele pot folosi
aceeași reprezentare și, eventual, un model unificat pentru specificarea modelelor de

deliberare a planificării și acțiunii:
▪ abordările modelului unic se bazează pe un model de domeniu unificat care
fuzionează specificația know-how a modelelor descriptive și specificația
know-how a modelelor operaționale. Abstracția și metodele ierarhice sunt
instrumentele obișnuite pentru descompunerea problemei. Planificarea se
realizează până la un anumit nivel de abstractizare. Acțiunile abstracte din
planuri sunt rafinate în continuare în comenzi primitive. Tehnici precum
rețelele de sarcini ierarhice, planificarea ierarhică angelică sau MDP
ierarhice pot sprijini aceste abordări;
▪ abordările cu mai multe modele utilizează modele distincte: un model
descriptiv abstract pentru planificare și unul sau mai multe modele
operaționale pentru a acționa pentru a rafina fiecare pas al planului în
abilități. Aceste abordări pot utiliza:
o o reprezentare uniformă a cunoștințelor pentru specificarea
problemelor de planificare și acțiune la diferite niveluri de
granularitate, de exemplu, limbaje de acțiune formale;
o reprezentări de cunoștințe eterogene la diferite niveluri, de exemplu,
operatori de efect de precondiție pentru planificare, proceduri sau
reguli de acțiune.
Rafinarea de la pașii planului la abilități implică alte câteva considerații:
• cât de aproape de platformă sunt pașii planului sintetizat. Această
proprietate este dependentă de context: aceeași acțiune, de exemplu,
moveto, poate fi o comandă direct executabilă într-un anumit context și
poate necesita o deliberare suplimentară în altul;
• abilitățile programate manual vs. sintetizate automat. Sinteza abilităților
din specificația funcției senzoriale-motorii și / sau cu tehnici de învățare
automată permite o proiectare mai ușoară a ingineriei, pentru proprietăți
verificate și o integrare îmbunătățită între planificare și acțiune;
• cât de specifice sunt competențele misiunii față de mediu. Adaptarea lor
poate varia de la alegerea parametrilor în abilitățile generice, până la sinteza
online a abilităților necesare sarcinii;
• cât de flexibil este planul generat. Un plan parțial specificat lasă libertatea
pentru gestionarea unui anumit nivel de incertitudine și nedeterminism și
adaptarea la contextul de execuție.
Arhitecturi. Alegerea unei arhitecturi adecvate este o altă problemă majoră de
proiectare. Un robot își implementează deliberarea online. Prin urmare, toate
abordările trebuie să intercaleze funcțiile de deliberare printr-o formă de bucle
închise imbricate (Fig. 4.10 b)): acțiunea se efectuează la un nivel de buclă
interioară în timp ce planificarea este procesată la un nivel de buclă exterioară.
Au fost propuse diverse paradigme arhitecturale pentru a aborda problema
integrării [4.30]:
▪ arhitecturile ierarhice sunt probabil cele mai utilizate în robotică [4.31-4.36].

Acestea organizează software-ul în câteva straturi cu cerințe temporale și
niveluri de abstractizare diferite: un strat de platformă care conține modulele
senzoriale-motorii și unul sau mai multe straturi pentru funcții de deliberare.
Adesea, în aceste straturi sunt folosite diferite reprezentări, ceea ce face destul
de dificilă verificarea coerenței globale. Beneficiul lor este că identifică și
organizează în mod clar componentele senzorial-motorii și componentele
deliberării. Cu toate acestea, aceste arhitecturi nu sunt ușor de adaptat
funcțiilor distribuite pe mai multe straturi (de exemplu, percepție, planificare
a mișcării etc.);
▪ arhitecturile reactive sunt compuse din automatele de intrare / ieșire care
implementează bucle de la senzori la efectori. Aceste automate pot fi
organizate ierarhic și se pot inhiba sau pondera reciproc. Instanțele inițiale de
arhitecturi reactive, de exemplu, arhitectura subsumului, au fost în cea mai
mare parte la nivelul platformei, fără prea multe preocupări pentru deliberare,
extensiile mai recente au adăugat funcții de deliberare [4.37-4.39]);
▪ arhitecturile teleo-reactive sunt mai recente [4.40-4.42]. Ei propun o
paradigmă integrată bazată pe componente de planificare-acțiune distribuite
la diferite niveluri, folosind orizonturi și cuante de timp diferite. Ele folosesc
o singură reprezentare și oferă un continuum între componente (de la
planificatorul de nivel înalt care se ocupă de variabilele de stare a misiunii, la
reactorul de nivel scăzut care modelează variabilele de stare fizică). Acestea
oferă un avantaj clar în ceea ce privește consistența sistemului, dar extinderea
lor la un mediu complex și extrem de dinamic rămâne o problemă;
▪ arhitecturile deschise au apărut recent pentru a satisface noile de servicii și
roboți personali în medii deschise cu semantică bogată. Caracteristica lor
distinctivă este aceea de a permite unui robot să deseneze date și modele pe
web, folosind în special tehnici web semantice.
4.5 Planificarea
Planificarea este o funcție de deliberare de bază pentru un robot autonom.

Poate fi privită ca o cuplare a unei probleme de predicție cu a uneia de căutare. Prima
se referă la capacitatea de a prezice efectele unei acțiuni într-un anumit context.
Acesta din urmă caută toate posibilitățile pentru a alege acțiuni fezabile și
pentru a le organiza într-un plan, care este prevăzut, la momentul planificării, să fie
fezabil și pentru a atinge un obiectiv dorit sau pentru a optimiza un criteriu de
performanță.
Modelele predictive specifice unui anumit tip de acțiune pot fi destul de precise.
De exemplu, modelele de fizică cu identificare bună a parametrilor și sisteme de
observare a stării pot prezice foarte bine efectele unei acțiuni. Dimpotrivă, modelele
abstracte ale formei „precondiție-efect” sunt suficient de generale pentru a reprezenta o
varietate de sarcini, dar destul de puțin profunde în capacitățile lor predictive.
De obicei, modelele abstracte sunt ușor de specificat și dezvoltat, în timp ce

modelele specifice necesită eforturi inginerești semnificative. Aceasta este problema
planificării specifice domeniului versus planificarea independentă a domeniului,
pentru care nu există un compromis final.
Opțiunea realistă este de a integra atât: planificarea specifică domeniului
pentru acțiunile esențiale ale unui robot, adică mobilitatea și manipularea, cât și
planificarea sarcinilor independente de domeniu pentru a gestiona adaptarea la o
varietate de sarcini la un nivel mai abstract. Câteva abordări, studiate în continuare,
au fost propuse pentru a face această integrare. Unele abordări de achiziție de modele
extind în continuare domeniul de aplicare al tehnicilor specifice domeniului cu
eforturi inginerești reduse. Două considerații sunt deosebit de relevante în robotică:
▪ revizuirea, repararea și refolosirea planurilor: aceste modalități de
planificare sunt adesea mai importante în practică decât sinteza noilor
planuri dintr-o agendă goală. Considerentele de complexitate în planificarea
clasică a sarcinilor ar favoriza replanificarea pentru a repara și reutiliza
[4.43]. Dar acest lucru nu este susținut de alte considerații, cum ar fi
costurile de acțiune, angajamentele continue ale unui robot și problemele de
stabilitate a planului [4.44-4.46];
▪ simulare și eșantionare: reprezentarea „precondiție-efect” a acțiunilor tinde
să fie superficială. Sistemele de simulare a roboților și mediilor, atunci când
sunt disponibile, pot fi utilizate pentru a realiza predicții fiabile, în special
cu tehnici de eșantionare. Acest lucru este ilustrat în integrarea planificării
mișcării în planificarea sarcinilor, de exemplu, [4.47,4.48], în tehnicile de
planificare probabilistică și în învățarea prin repetare.
Există mai multe alte opțiuni pentru proiectarea planificării unui robot:
▪ planuri cu buclă deschisă versus buclă închisă: acestea din urmă sunt
planuri condiționate care implică percepție (adică, faceți acest lucru, apoi,
depinzând de starea percepută a lumii, faceți asta sau asta), în timp ce
primele sunt planuri necondiționate. În cazul buclei deschise, proiectantul
este în general conștient de faptul că predicțiile unui model determinist și
presupunerea unui mediu static nu se pot realiza. Dar proiectantul are
încredere în funcțiile de monitorizare și acțiune pentru a face față și a corecta
mici variații între stările prezise și observate, și replanificarea pentru a face
față celor mai semnificative;
▪ plan orizont: poate fi un orizont nedefinit al unui plan unic care atinge
obiectivele, un plan parțial orizont retrogradat care va fi progresat în timp
ce acționează sau o politică infinită de orizont care optimizează
comportamentul robotului. În multe cazuri, domeniul aplicației determină
alegerea. De exemplu, o abordare la orizont infinit este adecvată pentru
menținerea unei proprietăți într-un mediu dinamic, de exemplu, menținerea
unei camere curate; în timp ce o misiune țintă în mișcare este mai bine
abordată cu o metodă de orizont în retragere;
▪ modele deterministe versus nedeterministe: acestea din urmă prezic efectele
alternative ale unei acțiuni și, în cazul probabil bilistic, iau în considerare
probabilitatea acestora. Planificarea nedeterministă generează politici, care

sunt planuri condiționate în buclă închisă.
4.5.1 Planificarea mișcării și sarcinilor
Roboții trebuie să-și planifice mișcări precise ale roților, picioarelor, brațelor
și articulațiilor. Planificarea mișcării și planificarea sarcinilor sunt diferite probleme
care utilizează reprezentări distincte și tehnici de căutare. Acesta din urmă a fost
considerat în cea mai mare parte de comunitatea AI, în timp ce primul a fost studiat
de comunitățile de robotică și geometrie de calcul.
În cazuri simple, se pot decupla cele două probleme: planificarea sarcinilor
produce un plan la nivel înalt ale cărui etape care necesită mișcări pot fi gestionate
de un planificator de mișcare specific.
Planificarea mișcării și a manipulării sunt capabilități cheie pentru un robot,
necesitând reprezentări specifice pentru geometrie, cinematică și dinamică. Foile de
parcurs probabilistice (PRM) și arborii aleatori care explorează rapid (RRT) sunt
tehnici bine dezvoltate și mature pentru planificatorii de mișcare, care se extind
eficient și permit numeroase extensii.
Ideea de bază este să eșantionăm aleatoriu spațiul de configurare (spațiul C) al
robotului (adică, spațiul vectorial al parametrilor cinematici ai robotului) într-un grafic
în care fiecare vârf este un punct din spațiul notat Cf al configurațiilor libere (departe
de obstacole) și fiecare margine o legătură directă în spațiul liber între două configurații
libere. La acest grafic se adaugă configurații inițiale și obiective, între care se
calculează o cale. Această cale este apoi transformată într-o traiectorie. Planificarea
manipulării necesită găsirea unor secvențe fezabile de poziții de prindere, fiecare
dintre acestea constituind o constrângere parțială asupra configurației robotului care
își schimbă cinematica. Multe alte probleme deschise rămân în mișcare și în
planificarea manipulării, cum ar fi constrângerile de dinamică și stabilitate, de
exemplu, pentru un robot umanoid, sau constrângerile de vizibilitate, de exemplu,
pentru a permite servoarea vizuală.
Planificarea sarcinilor și planificarea mișcării / manipulării au fost reunite în
câteva abordări. Planificatorul construiește un domeniu de planificare a sarcinilor
dintr-o structură construită de un planificator de mișcare în spațiul C al robotului.
Apoi, planifică simbolic cu un planificator spațial de stat și convertește înapoi
planurile găsite în spațiul C.
Integrarea mișcării la planificarea sarcinilor este, de asemenea, explorată cu
Angelic Hierarchical Planning (AHP). AHP planifică mai multe seturi de stări cu
noțiunea de seturi de stări accesibile. Aceste seturi nu sunt calculate exact, ci
delimitate, de exemplu, de un subset și un superset, sau de o funcție de cost
superioară și inferioară. Aceste costuri sunt obținute prin simulări ale activităților de
bază, inclusiv activități de mișcare, pentru valorile aleatorii ale variabilelor de stare.
O sarcină la nivel înalt are mai multe descompuneri posibile în primitive. Ansamblul
posibilelor descompuneri ale unui plan care conține mai multe sarcini la nivel înalt
este produsul cartezian al tuturor descompunerilor posibile ale acțiunilor sale. Nu
este necesar să se asigure că toate descompunerile sunt fezabile. Un plan este

acceptabil dacă are cel puțin o descompunere fezabilă.
Descompunerea unei sarcini poate fi amânată, de exemplu, până la momentul de
acțiune pentru realizarea acestei sarcini. În acel moment, robotul alege o descompunere
fezabilă (de aici și referința la o semantică angelică a nedeterminismului).
O cuplare diferită a unui planificator ierarhic de sarcini cu sugestori
geometrici rapizi se declanșează atunci când căutarea, în arborele de descompunere,
necesită informații geometrice. Nu rezolvă complet problema geometrică, dar oferă
informații care permit căutarea simbolică să continue până la o frunză a arborelui.
Sistemul alternează între faze de planificare simbolică și executarea reală a acțiunilor
geometrice în mediu.
Planificarea se desfășoară în timp ce acționează. Aceasta permite
planificatorului de sarcini să apeleze planificatorul geometric (nu sugestorii) într-o
stare complet cunoscută. Astfel, această abordare se bazează pe două ipoteze
puternice: precondițiile geometrice ale sarcinilor pot fi calculate rapid și eficient (de
către sugestori), sub obiectivele rezultate dintr-o descompunere a sarcinii care
trebuie executată în ordine (fără paralelism). Autorii recunosc că sistemul lor nu este
complet și că ipoteza secvențializării sub-obiective necesită ca acțiunile să fie
reversibile la un cost rezonabil. Cu toate acestea, pentru problemele în care aceste
ipoteze sunt îndeplinite, sistemul este capabil să producă rapid planuri corecte.
Abordarea de backtracking geometrică a și lucrările ulterioare se bazează pe
sinteza automatizată a constrângerilor geometrice din planul de activitate și
propagarea lor, ca programe liniare, pentru a filtra eșantioanele în spațiul de
configurare. Configurațiile rămase, dacă există, sunt căutate în continuare în ceea ce
privește condițiile suficiente de cinematică inversă, detectarea coliziunilor și
planificarea mișcării pentru a vă asigura că fiecare pas specifică poziții fără coliziune
și realizabile cinematic față de cele anterioare. Abordarea a fost dezvoltată pentru
probleme de manipulare și experimentată cu robotul Justin cu două brațe.
Planificatorii de mișcare PRM și RRT utilizați în abordările citate rezolvă
interogări fezabile foarte eficient, dar gestionează interogări infezabile cu un timp
limită care poate fi un dezavantaj grav în medii constrânse. Algoritmul incremental
I-TMP [97] integrează îndeaproape planificarea sarcinilor și a mișcării cu alocarea
adaptativă a timpului de calcul, unde poate fi cel mai util. A fost testat pe roboți cu
mai multe picioare care navighează pe teren accidentat.
Să menționăm, de asemenea, tehnica bazată pe fizică care cuplează un
simulator de motor de fizică cu metode de căutare asemănătoare RRT pentru
planificarea interacțiunilor unui robot cu corpuri neaccționate cu grade diferite de
controlabilitate pentru a atinge unele obiective. Se bazează pe tehnici de eșantionare
pentru a explora selectiv configurația continuă și spațiul dinamic. Planificarea
sarcinilor oferă acțiuni și regiuni discrete ale spațiului continuu pe care planificarea
mișcării bazată pe eșantionare le poate explora. Cei doi planificatori interacționează
prin estimări privind utilitatea fiecărei acțiuni, care sunt calculate prin tehnici de
învățare profundă.
4.5.2 Planificarea temporală
Majoritatea aplicațiilor de robotică necesită modele de timp explicite

pentru a gestiona acțiuni durative, concurență, sincronizare cu evenimente
exogene și alți roboți și constrângeri temporale, posibil cu limite inferioare și
superioare flexibile.
Diverse abordări gestionează reprezentări explicite ale timpului pentru
planificare. Mai mulți planificatori extind reprezentări bazate pe stări cu acțiuni
durative (de exemplu, TGP , VHPOP sau Crickey) (Fig. 4.12).
Câțiva dintre ei pot gestiona concurența, sau chiar schimbarea continuă liniară
(COLIN), sau pot planifica și repara în timp real. In orice caz, planificatorii temporali
care se bazează pe linii temporale, adică evoluția parțial specificată a variabilelor de
stare în timp, sunt mai flexibili în integrarea planificării și a acțiunii și, în majoritatea
cazurilor, mai expresivi, de exemplu, permițând referința la instanțe dincolo de
momentul de început și de sfârșit al acțiuni. Acești planificatori implementează
algoritmi de căutare plan-spațiu mai des decât tehnici de spațiu de stare.
Ingredientele lor obișnuite de reprezentare sunt:
• primitive temporale: puncte de timp sau intervale (jetoane),
• variabile de stare, posibil parametrizate, de exemplu, poziția (obiect32) și
relații rigide, de exemplu, conectate (loc3, cameră5), invariante în timp,
• afirmații privind persistența valorii unei variabile de stare în timp sau
schimbarea discretă sau continuă a valorilor,
• constrângeri temporale: relații de interval Allen sau rețele temporale simple
în timp,
• constrângeri atemporale asupra valorilor/parametrilor variabilelor de stare.
Fig. 4.12 Modelul unei acțiuni PickUp cu trei variabile de stare: Gripper,
Brațul drept, Planificatorul de manipulare.
Planificarea se desfășoară în spațiul planului prin detectarea defectelor, adică

a modificărilor inexplicabile și a eventualelor neconcordanțe, și repararea acestora
prin acțiuni și constrângeri suplimentare. Se folosește de diverse euristici, propagare
a constrângerilor și mecanisme de retrogradare. Produce planuri parțial specificate,
care nu mai au defecte, dar conțin în continuare variabile temporale și atemporale
constrânse, dar neinstanțiate. Această abordare cu cel mai mic angajament permite o
anumită flexibilitate pentru adaptarea la contextul de execuție. Unii planificatori pot
gestiona timpul de planificare delimitat și îl iau în considerare împreună cu orizontul
de execuție în timpul procesului de planificare.
4.5.3 Planificare probabilistică
Procesele decizionale Markov (Markov Decision Processes - MDP) oferă

un cadru clasic pentru planificare cu incertitudini și efecte probabilistice. Un
planificator calculează o politică optimă, adică un plan universal care mapează stările
în acțiuni aplicabile. Cadrul clasic ia în considerare infinitele probleme de orizont,
de exemplu, pentru a menține o proprietate într-un mediu dinamic. Poate fi extins la
sisteme parțial observabile (Partially Observable Markov Decision Processes -
POMDP). Este eficient atâta timp cât spațiul de stare și parametrii de cost și
probabilitate pot fi achiziționați în totalitate și expliciți și, pentru POMDP, rămân de
dimensiuni mici.2 Cu toate acestea, majoritatea problemelor de deliberare în robotică
nu permit o enumerare explicită a spațiul de stat și, prin urmare, nu își poate permite
un plan universal. Din fericire, multe probleme sunt axate pe atingerea unui obiectiv
dintr-o anumită stare inițială. Algoritmii de căutare euristică pentru problemele
Stochastic Shortest Path (SSP) [4.49] cu reprezentări factorizate și ierarhice [4.50]
abordează această clasă de probleme. Acestea oferă abordări probabilistice ale
deliberării robotice care trebuie încă dezvoltate și implementate pe roboți, dincolo
de problemele de testare clasice.
O problemă SSP se concentrează pe o politică parțială, închisă pentru starea
inițială s0 (adică, o politică π definită pentru toate stările la care se poate ajunge de
la s0 de π), care se termină la stările obiectivului. Un SSP este echivalentul graficelor
And / Or cu problemele de căutare a căilor în grafice deterministe. Pentru spații de
căutare implicite foarte mari cu modele rare (puține acțiuni aplicabile pe stare, puține
efecte nedeterministe pe acțiune, inclusiv acțiuni deterministe), se poate realiza o
amplificare semnificativă în ceea ce privește metodele clasice de programare
dinamică cu tehnici de euristică și eșantionare.
Majoritatea algoritmilor de căutare euristică pentru SSP se bazează pe o
schemă în doi pași, numită Găsire și revizuire: (i) Găsiți o stare în așteptare s printre
descendenții s0 accesibilă cu politica curentă și (ii) Revizuiți valoarea estimată și
politica lui s cu -appelat actualizare Bellman. O stare este în așteptare atunci când
trebuie extinsă sau când valoarea și politica acesteia trebuie să fie actualizate către
cea mai bună (sau bună) politică din s. Acel cadru poate fi implementat în diferite
moduri, de exemplu, cu o căutare cea mai bună, cum ar fi în AO *, LAO * [4.51] și
extensiile acestora, cu o căutare iterativă de aprofundare în prima adâncime, ca în

LDFS [4.52], sau cu o căutare de mers aleatoriu, ca în RTDP [4.53], LRTDP [4.54]
și extensiile acestora.
Acești algoritmi presupun probleme SSP cu o politică adecvată închisă pentru
s0 (adică una care atinge un obiectiv cu probabilitatea 1) și orice politică
necorespunzătoare are un cost infinit. O generalizare a SSP-urilor pentru a relaxa
această ultimă presupunere permite căutarea unei politici care să maximizeze
probabilitatea de a atinge o stare de obiectiv, un criteriu foarte util și de dorit. Alte
probleme, cum ar fi fundăturile (stări din care nu este posibil să se atingă un obiectiv)
trebuie să fie luate în considerare, în special în domeniile critice. Algoritmii de
căutare euristică din SSP sunt mai scalabili decât programarea dinamică, dar totuși
nu pot aborda domenii mari, cu excepția cazului în care aceste domenii sunt atent
concepute și descompuse.
Diverse tehnici de eșantionare și aproximare oferă abordări alternative pentru a
extinde în continuare planificarea probabilistică. Dintre aceste abordări, tehnicile de
determinare transformă fiecare acțiune nedeterministă în mai multe acțiuni de
terministică (cea mai probabilă sau toate posibile), apoi planifică deterministic cu
aceste acțiuni, online și / sau offline. De exemplu, SSiP combină replanificarea atunci
când este necesar cu planificarea pe un orizont parametrizat de la cel puțin k pași care
trebuie garantați fără replanificare. RFF generează un plan determinist inițial, apoi ia
în considerare o stare marginală de-a lungul unei ramuri nedeterministe a planului
respectiv și, atâta timp cât probabilitatea de a ajunge la starea respectivă este peste un
prag, îl extinde cu un alt plan determinist spre un obiectiv sau o stare deja rezolvată.
Idei similare sunt dezvoltate în abordări de eșantionare. Unul dintre avantajele lor este
capacitatea de a lucra fără estimări a priori ale distribuțiilor de probabilitate, atâta timp
cât eșantionarea este extrasă din aceleași distribuții. Au fost concepute mai multe
strategii pentru controlul căutării, de exemplu, eșantionarea mai redusă la nivelul mai
profund al arborelui anticipat. Au fost obținute limite privind calitatea aproximării și
complexitatea căutării, cu rezultate bune la diverse adaptări și extensii ale algoritmilor
LRTDP și UCT, de exemplu.
Deși MDP-urile sunt adesea folosite în robotică la nivel senzorial-motor, în
special în cadrul abordărilor de învățare profundă, tehnicile SSP nu sunt diseminate
la fel de larg la nivel de planificare deliberativă și acțiune.
Un exemplu interesant este planificatorul MDP rar, care cuplează SSP cu
planificarea clasică: atunci când majoritatea acțiunilor sunt deterministe, dar din
câteva probabiliste, el caută și reduce părțile deterministe ale spațiului de planificare
într-un MDP comprimat. Abordarea a fost testată într-o problemă de explorare
robotică.
4.5.4 Planificare în domenii deschise
Majoritatea planificatorilor clasici se bazează pe ipoteza lumii închise: un fapt

care nu este declarat explicit este fals. Această presupunere permite o descriere concisă
a stărilor și un calcul eficient al tranzițiilor de stat. Dar este prea restrictiv și acceptabil
în domeniul roboticii. Câteva tehnici relaxează această presupunere, de exemplu,

planificarea cu variabile de stare și cronologii permite instanțe parțial specificate ale
unui domeniu. Dar alte probleme rămân deschise, printre care următoarele:
• planificarea cu privire la obiectele și proprietățile domeniului care sunt
necunoscute la începerea planificării, dar care pot fi descoperite la momentul
acțiunii, în special prin acțiuni planificate de colectare a informațiilor. Aceste
noi fapte vor fi folosite pentru a rafina în continuare restul planului.
• permiteți planificatorului să interogheze bazele de date pentru fapte de care
are nevoie în mod special pentru a aborda o anumită problemă de planificare
sau să interogheze bazele de cunoștințe pentru modele suplimentare ale
mediului său care sunt relevante pentru sarcina respectivă.
Fosta problemă a planificării cu colectarea de informații este studiată de mai
mulți autori cu programe condiționate, ca în sistemul PKS [4.55]. Abordarea
continuă a planificării MAPL [4.56] amână o parte a procesului de planificare. În
locul său, introduce acțiuni de colectare a informațiilor pentru a dezvolta ulterior
părțile lipsă ale planului. În acest scop, planificatorul folosește afirmații care acțiuni
abstracte pentru a fi rafinate ulterior, după colectarea informațiilor. Această abordare
mixtă de planificare / acțiune este bine adaptată mediilor dinamice în care
planificarea sub obiectivelor care depind de stări încă necunoscute poate fi întârziată
până când informațiile solicitate sunt disponibile (prin acțiuni de colectare a
informațiilor planificate corespunzător). Abordarea a fost extinsă la planificarea /
acțiunea distribuită multi-robot. A fost testat în probleme de navigare simulate.
Ultima problemă a achiziționării de modele și date suplimentare la momentul
planificării este abordată de un număr tot mai mare de proiecte. Ideea motrice este
de a îmbogăți un sistem de deliberare a robotului cu funcționalități asemănătoare cu
web-ul semantic, folosind o ontologie de domeniu asociată unor capacități de
raționament. De exemplu, sistemul ObjectEval din [4.57] achiziționează de pe web
statistici despre posibile locații ale obiectelor din diferite clase. Le folosește într-o
funcție de utilitate pentru găsirea și livrarea obiectelor într-un mediu de birou. Alte
abordări folosesc Description Logic (DL), un fragment de logică de prim ordin,
pentru a gestiona declarații despre obiecte, proprietăți, relații și instanțele acestora
cu algoritmi de inferență pentru interogarea unor stocuri mari de date și modele pe
web. Majoritatea implementărilor se bazează pe OWL, limbajul standard pentru
ontologie web. OWL gestionează o reprezentare a lumii deschise în care faptele pot
fi adevărate, false sau necunoscute.
Abordarea domeniilor deschise cuplează DL cu un planificator HTN. Un robot
necesită un stoc mare de cunoștințe despre mediul său, doar o mică parte fiind relevantă
pentru o anumită problemă de planificare. DL permite planificatorului să sintetizeze o
problemă HTN echivalentă compactă axată pe această parte relevantă. Ontologia
corespunzătoare include concepte de planificare HTN (adică sarcini, metode, stări
etc.), precum și concepte de domeniu. Abordarea a fost testată pe probleme de
navigație. Proiectul RACE [4.58] proiectează un robot de serviciu cu capacități de
învățare a cărui întreagă arhitectură este construită în jurul unei baze de date DL
deschise, asemănătoare cu o arhitectură „Blackboard”. Această caracteristică este

utilizată pentru a combina date despre activitățile robotului de nivel scăzut, necesare
în special pentru învățare, cu descrieri semantice de nivel superior furnizate de
ontologie. Sistemul acceptă o platformă PR2 care îndeplinește sarcinile unui chelner.
Sistemul Open Robot Ontology (ORO) din [4.59] a fost motivat mai mult prin
extinderea bazei de cunoștințe a robotului, apoi prin îmbunătățirea performanțelor
planificatorilor săi. ORO este construit cu aceeași reprezentare și raționament OWL
ca și sistemele anterioare. Oferă interogări și actualizări ale unei baze de cunoștințe
despre mediu. Serviciile ORO sunt utilizate de diferite componente ale robotului, în
special de un sistem de gestionare a dialogului situat și de un planificator. ORO a
fost testat cu câteva platforme pentru sarcini de robotică de service
Această abordare urmăreștec să permită roboților care au platforme diferite să
împărtășească și să reutilizeze cunoștințele prin rețea în scopul îndeplinirii de noi
sarcini și accelerarea învățării și adaptării.
O bibliotecă open source OWL stochează modele comune de obiecte (de
exemplu, imagini, modele CAD), medii (de exemplu, hărți și locații de obiecte) și
acțiuni (de exemplu, rețete și abilități de acțiune), împreună cu relațiile și
proprietățile lor într-o ontologie generală. Fiecare robot este dotat cu mijloace pentru
interogarea și actualizarea acestei baze de date, precum și pentru adaptarea
modelelor sale. Conceptul a fost testat pe câțiva demonstranți pentru explorarea unui
labirint folosind diferite platforme care împărtășesc hărți și informații despre traseu,
pentru servirea unei băuturi sau deschiderea sertarelor fără cunoștințe apriorice
despre mediul înconjurător.
4.6 Acțiune
Planificarea este ușor specificată ca o funcție predictivă offline, decuplată de

complexitățile platformei de executare. În schimb, acțiunea este mai dificil de definit
ca o funcție de deliberare. Referința frecventă la controlul execuției este adesea prea
reductivă. Există mult mai mult decât declanșarea acțiunilor abstracte prescrise de
un plan. Acțiunea trebuie să se ocupe de senzori zgomotoși, actuatoare nesigure și
modele imperfecte. Necesită modele de mediu nedeterministe, parțial observabile și
dinamice, tratate prin comenzi în buclă închisă. Actoria are adesea un rol central în
deliberare. Trebuie să îndeplinească în special următoarele funcții:
• perfecționare: pașii planului (adică acțiuni) date de un planificator de sarcini
sunt rareori executabile direct ca comenzi robot. O acțiune precum open
(door1) este un pas primitiv pentru un planificator, dar necesită o deliberare
semnificativă pentru realizarea sa. Procesul de rafinare depinde de context.
Se bazează pe modele de nivel inferior, pe care le-am numit abilități,
adecvate contextului. Abilitățile pot fi alese și adaptate dintr-o bibliotecă sau
sintetizate online. Abilitatea în care o acțiune este rafinată se poate schimba
în timpul execuției. De exemplu, mai multe abilități de navigare pot oferi
diferite capacități de localizare sau control al mișcării adaptate la context
diferit; prin urmare, acțiunea goto (room1) poate fi rafinată într-o secvență
de mai multe abilități de navigare. Acțiunea trebuie să ia în considerare și

rafinări alternative în caz de eșec.
• reacție la evenimente: există evenimente așteptate, în scopul sincronizării
planului, sau evenimente neașteptate. Evenimentele pot fi tratate la nivel
local cu abilități adecvate. Acestea pot avea consecințe negative sau pozitive
pentru planul actual sau chiar pentru obiectivul actual. În plus față de reacția
locală, pot necesita repararea planului.
• instanțare: dacă nu sunt sintetizate online, abilitățile de actorie sunt aplicabile
pentru o serie de situații. Modelele lor pot utiliza variabile neinstanțiate a căror
valoare poate fi aleasă la momentul execuției sau observată în mediu. Aceste
valori se propagă la comenzi în raport cu contextul perceput.
• managementul timpului: actoria se realizează online. Dinamica mediului trebuie
tratată. Răspunsurile adecvate trebuie date în timp util. Există probleme de timp
ca resursă cu termene, durate și timp de deliberare. Există, de asemenea,
probleme de întâlnire, sincronizare cu evenimente și constrângeri de timp.
• nedeterminism: Aplicarea unei acțiuni poate avea ca rezultat mai multe stări
posibile. Apariția evenimentelor exogene într-un mediu dinamic este rareori
previzibilă deterministic. Mai mult, nu toate variabilele de stare relevante
sunt observabile cu certitudine. Vom vedea că unele dintre tehnicile
prezentate pot gestiona surse de nedeterminism.
• reparația planului: așa cum a fost introdus în secțiunea 3, reparația planului
este în mod clar o activitate de planificare. Cu toate acestea, este strâns legat
de acțiunea care declanșează repararea sau replanificarea în condițiile
adecvate în ceea ce privește executarea comisă. Acțiunea trebuie să susțină
această caracteristică.
Suprapunerea dintre planificare și acțiune lasă deschise numeroase opțiuni de
proiectare. Câțiva autori dezvoltă un cadru în care ambele funcții de deliberare sunt
tratate în același spațiu de căutare, cu aceleași tehnici. Cu toate acestea, majoritatea
abordărilor abordează cerințele distincte ale planificării și acțiunii cu schema de
descompunere în care planificarea motivelor cu modele descriptive abstracte de
acțiuni în timp ce acționează folosește modele operaționale pentru a rafina acțiunile
în proceduri, numite abilități, care sunt perfecționate în continuare în comenzi.
Această schemă de descompunere se poate baza pe reprezentări de cunoștințe
distincte, de exemplu, operatorii STRIPS pentru primul combinat cu procedurile
PRS [4.60] sau RAP [4.61] pentru acesta din urmă. În unele cazuri, o singură
reprezentare este utilizată atât pentru planificare, cât și pentru acțiune.
4.7 Monitorizarea și raționamentul obiectivelor
Monitorizarea este o funcție însărcinată cu:

(i) detectarea discrepanțelor dintre predicții și observații,
(ii) diagnosticarea cauzelor posibile;
(iii) recuperarea acestora.
Monitorizarea este uneori denumită supraveghere sau detectare, identificare și

recuperare a erorilor (FDIR). Mai general, monitorizarea trebuie să detecteze dacă
activitatea robotului rămâne în curs sau dacă este necesară o corecție a cursului.
La cel mai înalt nivel, un sistem de monitorizare trebuie să analizeze dacă
obiectivele actuale ale robotului sunt încă fezabile și relevante pentru misiunea sa și,
eventual, să stabilească noi obiective dacă nu sunt. Deși obiectivele actuale rămân
valabile, monitorizarea trebuie să analizeze previziunile planificatorului care susțin
planul pentru atingerea acestor obiective.
De asemenea, trebuie să analizeze predicțiile făcute la rafinarea acțiunilor
planificate în comenzi și pentru a monitoriza condițiile relevante pentru acțiunile
curente care sunt lăsate implicite în etapele de planificare și rafinare. Acestea din
urmă sunt, de exemplu, starea de funcționare a componentelor hardware: condițiile
de pregătire a senzorilor robotului sau nivelul de încărcare al bateriilor sale. În cele
din urmă, monitorizarea este strâns legată de observare. Informațiile relevante despre
mediu pot fi dificile sau costisitoare și menținute continuu. Ar trebui să se stabilească
o atenție adecvată pentru a detecta condițiile relevante pentru contextul actual și
predicții.
Ca funcție, monitorizarea este clar distinctă de acțiune. În timp ce acesta din
urmă este un proces de transformare, primul trebuie să țină un control asupra acestui
proces, inclusiv a motivațiilor sale, care necesită o observare și o anticipare specifice.
Cu toate acestea, suprapunerea dintre acțiune și monitorizare este adesea mare
în literatură și implementări. De exemplu, sistemul Planex timpuriu a efectuat o
monitorizare foarte simplă prin calculul iterat al nucleului activ curent al unei tabele
triunghiulare [4.62]. În majoritatea cazurilor de sisteme bazate pe proceduri
(Secțiunea 4.2), există proceduri specifice în PRS, RAP, ACT sau TCA, sau o parte
din astfel de proceduri, care gestionează funcțiile de monitorizare. Cu toate acestea,
diagnosticul și funcțiile de recuperare în astfel de sisteme sunt de obicei limitate și
destul de ad-hoc.
Monitorizarea în robotică se inspiră adesea din domeniul controlului
industrial, unde monitorizarea este o problemă critică și bine studiată. Mai multe
sisteme de monitorizare, de-a lungul acestei linii, sunt analizate în [4.63], dintre
care cele mai multe se referă în principal la un nivel senzorial-motor al robotului.
Aceste sisteme se bazează pe modele de teorie a controlului, tehnici de filtrare,
metode statistice, cum ar fi analiza componentelor de principiu, pentru analiza
datelor de instruire a cazurilor normale și de eșecuri și tehnici de recunoaștere a
modelelor pentru diagnostic. Relația dintre monitorizare și planificare nu a fost o
preocupare majoră. Această legătură este esențială din punctul de vedere al
deliberării integrate.
4.8 Observarea/Percepția
Percepția este o componentă critică în robotică, de exemplu, în buclele de

control al feedback-ului, în percepția vizuală sau în Localizare și cartografiere
simultană (SLAM). Aceste tehnici metrice și probabilistice, eventual îmbogățite cu
date topologice și semantice, de exemplu, ca în [4.64-4.66], sunt foarte eficiente
pentru sarcini de navigație și cartografiere.
Dar roboții se confruntă cu alte treburi dincolo de mobilitate. Funcția de
observare oferă capacitatea de a identifica obiecte, stări și secvențe de evenimente
relevante pentru activitatea robotului.
Trebuie să fie strâns integrat cu planificarea, acționarea și monitorizarea.
Combină procesele de jos în sus, de la senzori la date semnificative, cu mecanisme
de sus în jos, cum ar fi focalizarea atenției, raționamentul cu modele de senzori și
planificarea cu acțiuni de detectare.
4.8.1 Planificarea de a percepe
Am discutat deja planificarea sarcinilor cu acțiuni de detectare și colectare a

informațiilor (Sec. 3.4). Planificarea percepției este o problemă distinctă care se
referă la integrarea selecției punctelor de vedere și a modalităților senzorilor cu
recunoașterea, navigarea și alte sarcini. Se bazează pe o muncă extinsă asupra
problemei plasării senzorilor, de obicei abordată ca o căutare a celui mai bun punct
de vedere următor într-o recunoaștere sau o sarcină de modelare, ca în [4.67]. Mai
mulți autori abordează această problemă de planificare integrată cu POMDP, de
exemplu, [4.68,4.69].
Sistemul HiPPo [4.70] oferă o ilustrare bună a plasării senzorilor pentru
recunoașterea obiectelor de pe o masă, așa cum este necesar de obicei într-o sarcină
de manipulare în care problemele de intractabilitate sunt abordate cu o tehnică
ierarhică POMDP. Abordarea pare fezabilă în sarcini de percepție limitate,
implicând câteva regiuni de interes.
O abordare alternativă și mai scalabilă pentru sintetizarea unui plan de
observare în cadrul unei sarcini de navigație este propusă în [4.71]. Această lucrare
urmărește să detecteze și să mapeze obiecte de interes în timp ce ajungeți la o
destinație. Folosește o abordare bayesiană care corelează măsurătorile din
observațiile ulterioare pentru a îmbunătăți detectarea obiectelor; ocolirile sunt
cântărite în raport cu costul mișcării pentru a produce planuri de observație robuste
folosind o schemă de eșantionare care se retrage.
Abordarea a fost testată într-un mediu interior pentru recunoașterea ușilor și
ferestrelor.
4.8.2 Recunoașterea obiectelor și ancorarea simbolurilor
Problema de ancorare oferă o ilustrare excelentă a complexității integrării

metodelor de recunoaștere a modelelor cu acțiune deliberată. Așa cum este definit
în [4.72], ancorarea este problema creării și menținerii în timp a unei

corespondențe între simboluri și datele senzorilor care se referă la același obiect
fizic. Planificarea și alte funcții de eliberare raționează despre obiectele din mediu
prin atribute simbolice și relații care leagă aceste simboluri. Observarea tratează
datele perceptive. Este esențial ca descrierea abstractă a primei și datele celor din
urmă să fie de acord. Ancorarea se referă la obiecte fizice specifice. Poate fi văzut
ca un caz particular al problemei de împământare a simbolurilor, care tratează
categorii largi.
Ancorarea unui obiect de interes poate fi realizată prin stabilirea și păstrarea
unei legături, numită ancoră, între sistemul perceptiv și sistemul de simboluri,
împreună cu o semnătură care estimează unele dintre atributele obiectului la care se
referă. Ancora se bazează pe un model care leagă relațiile și atributele de trăsăturile
perceptive și valorile lor. Stabilirea unei ancore corespunde unei probleme de
recunoaștere a modelelor, cu provocarea obișnuită de a trata incertitudinea în datele
senzorilor și ambiguitatea în modele, o provocare abordată, de exemplu, prin
menținerea mai multor ipoteze. În [4.73], ancorele ambigue sunt tratate cu un
planificator condițional, numit PTL, care explorează un spațiu de stări de credință,
reprezentând cunoștințele incomplete și incerte datorate potrivirii parțiale între
proprietățile simbolice și trăsăturile perceptive observate. Autorii fac distincție între
descrieri simbolice definite, care se potrivesc cu un singur obiect, și descrieri
nedeterminate. Acțiunile au efecte cauzale care modifică proprietățile obiectului.
Observațiile pot schimba partiția unei stări de credință în mai multe ipoteze noi. Au
experimentat cu un robot de interior echipat cu viziune și simțire a mirosului în
sarcinile de recunoaștere a obiectelor.
4.1. Stuart J. Russell and Peter Norvig, Artificial Intelligence. A modern Approach,
Prentice Hall, 1995, Enlewood Cliffs, New Jersey 07632, ISBN 0-13-103805-2.
4.2. Ali Ahmad Malik, Arne Bilberg, Framework ti Implement Collaborative Robots
in Manual Assembly: A Lean Automation Approach, Conference: Proceedings
of the 28th International DAAAM Symposium 2017, doi:
10.2507/28th.daaam.proceedings.160.
4.3. Stuart J. Russell and Peter Norvig, Artificial Intelligence: A modern Approach,
Nils J. Nilsson, Elsevier - Artificial Intelligence 1996, 82, pp. 369-380.
4.4. Hongyang Qu and Sandor M. Veres, Verification of Logical Consistency in
Robotic Reasoning, January 4 2018, pp. 36, arXiv:1611.03322v1.
4.5. S. Maghsoudi, I. Watson, Epistemic logic and planning, in: Proceedings of
Knowledge-Based Intelligent Information and Engineering Systems (KES’04),
Vol. 3214 of Lecture Notes in Computer Science, Springer, 2004, pp. 36–45.
4.6. L. Mihaylova, A. Carmi, F. Septier, A. Gning, S. K. Pang, S. J. Godsill,
Overview of bayesian sequential monte carlo methods for group and extended
object tracking, Digital Signal Processing 25 (2014) 1–16.
4.7. R. H. Bordini, J. F. Hubner, Jason Website, http://jason.sourceforge.net/

wp/description/, 15/07/2013 (2013).
4.8. M. Dastani, B. Testerink, M. Cap, T. Behrans, J.-J. Meyei, 2APL Website,
http://apapl.sourceforge.net/ (2013).
4.9. M. Nikraz1a, G. Caireb, P. A. Bahri, Jade Website, http://jade.tilab.com/doc/,
15/07/2013 (2013).
4.10. N. K. Lincoln, S. M. Veres, Natural language programming of complex robotic
BDI agents, Journal of Intelligent & Robotic Systems (2012) 1–20.
4.11. S. M. Veres, N. K. Lincoln, L. Molnar, C. Morice, Autonomous vehicle control
systems - a review of decision making, Journal of Systems and Control
Engineering 225 (3) (January 2011) 155–195.
4.12. N. K. Lincoln, S. M. Veres, Natural language programming of complex robotic
BDI agents, Intelligent and Robotic Systems 71 (2) (2013) 211– 230.
4.13. M. Wooldridge, An Introduction to MultiAgent Systems, Wiley, Chichester,
2002.
4.14. S. M. Veres, L. Molnar, N. K. Lincoln, C. Morice, Autonomous vehicle control
systems - a review of decision making 225 (2) (2011) 155–195.
4.15. S. M. Veres, L. Molnar, N. K. Lincoln, C. Morice, Autonomous vehicle control
systems - a review of decision making 225 (2) (2011) 155–195.
4.16. P. Izzo, H. Qu, S. M. Veres, Reducing complexity of autonomous control agents
for verifiability, arXiv:1603.01202[cs.SY].
4.17. R. Bryant, Graph-based algorithms for boolean function manipulation, IEEE
Transaction on Computers 35 (8) (1986) 677–691.
4.18. A. Cimatti, E. M. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri,
R. Sebastiani, A. Tacchella, Nusmv 2: An opensource tool for symbolic model
checking, in: Proceedings of CAV 2002, Vol. 2404 of Lecture Notes in
Computer Science, Springer, 2002, pp. 359–364.
4.19. A. Lomuscio, H. Qu, F. Raimondi, MCMAS: An open-source model checker for
the verification of multi-agent systems, International Journal on Software Tools
for Technology Transfer.
4.20. R. Fagin, J. Y. Halpern, Y. Moses, M. Y. Vardi, Reasoning about Knowledge,
MIT Press, Cambridge, 1995.
4.21. E. M. Clarke, E. A. Emerson, A. P. Sistla, Automatic verification of finite-state
concurrent systems using temporal logic specifications, ACM Trans. Program.
Lang. Syst. 8 (2) (1986) 244–263.
4.22. A. Pnueli, The temporal logic of programs, in: Proc of 18th Annual Symposium
on Foundations of Computer Science, IEEE Computer Society, 1977, pp. 46–
57.
4.23. E. M. Clarke, O. Grumberg, D. A. Peled, Model Checking, The MIT Press,
Cambridge, Massachusetts, 1999.
4.24. R. Bryant, Graph-based algorithms for boolean function manipulation, IEEE
Transaction on Computers 35 (8) (1986) 677–691.
4.25. R. Bloem, H. N. Gabow, F. Somenzi, An algorithm for strongly connected
component analysis in log symbolic steps, in: Proc. FMCAD’00, Vol. 1954 of
LNCS, Springer, 2000, pp. 37–54.
4.26. R. Gentilini, C. Piazza, A. Policriti, Computing strongly connected components

in a linear number of symbolic steps, in: Proc. SODA’03, 2003, pp. 573–582.
4.27. M. Kwiatkowska, D. Parker, H. Qu, Incremental quantitative verification for
Markov decision processes, in: Proc. DSN-PDS’11, IEEE, 2011, pp. 359–370.
4.28. Felix Ingrand, Malik Ghallab, DEliberation robots: A survey. Artificial
Intelligence, Elsevier, 2017, 247, pp- 10-44, doi 10.1016/j.artint.2014.11.003.
hal-01137921.
4.29. Ghallab, M., Nau, D. S., Traverso, P., 2014. The actor’s view of automated
planning and acting: A position paper. Artificial Intelligence 208, 1–17.
4.30. Kortenkamp, D., Simmons, R., 2008. Robotic Systems Architectures and
Programming. In: Siciliano, B., Khatib, O. (Eds.), Springer Handbook of
Robotics. Springer, pp. 187–206.
4.31. Carbone, A., Finzi, A., Orlandini, A., Pirri, F., Nov. 2007. Model-based control
architecture for attentive robots in rescue scenarios. Autonomous Robots 24 (1),
87–120.
4.32. Doherty, P., Kvarnstrom, J., Heintz, F., Feb. 2009. A temporal logic-based
planning and execution monitoring framework for unmanned ¨ aircraft systems.
Autonomous Agent and Multi-Agent Systems 19 (3), 332–377.
4.33. Gat, E., 1997. On Three-Layer Architectures. In: Kortenkamp, D., Bonnasso, R.
P., Murphy, R. (Eds.), Artificial Intelligence and Mobile Robots. AAAI Press.
4.34. Ingrand, F., Lacroix, S., Lemai-Chenevier, S., Py, F., 2007. Decisional autonomy
of planetary rovers. JFR 24 (7), 559–580.
4.35. Konolige, K., Myers, K. L., Ruspini, E. H., Saffiotti, A., Apr. 1997. The Saphira
architecture: a design for autonomy. JETAI 9 (2-3), 215–235.
4.36. Nesnas, I. A., Wright, A., Bajracharya, M., Simmons, R., Estlin, T., Oct. 2003.
CLARAty and Challenges of Developing Interoperable Robotic Software. In:
IROS.
4.37. Brooks, R. A., 1986. A Robust Layered Control System for a Mobile Robot.
IEEE Journal of Robotics and Automation 2 (1), 14–23.
4.38. Lamine, K., Kabanza, F., 2000. History checking of temporal fuzzy logic
formulas for monitoring behavior-based mobile robots. In: ICTAI.
4.39. Pettersson, O., Karlsson, L., Saffiotti, A., 2003. Model-free execution
monitoring in behavior-based mobile robotics. In: ICAR.
4.40. Finzi, A., Ingrand, F., Muscettola, N., 2004. Model-based Executive Control
through Reactive Planning for Autonomous Rovers. In: IROS.
4.41. McGann, C., Py, F., Rajan, K., Henthorn, R., McEwen, R., 2008. A deliberative
architecture for AUV control. In: ICRA. pp. 1049–1054.
4.42. Muscettola, N., Dorais, G., Fry, C., Levinson, R., Plaunt, C., 2002. IDEA:
Planning at the Core of Autonomous Reactive Agents. In: IWPSS.
4.43. Nebel, B., Koehler, J., 1995. Plan Reuse Versus Plan Generation: A Theoretical
and Empirical Analysis. Artificial Intelligence 76 (1-2), 427–454.
4.44. Fox, M., Gerevini, A., Long, D., Serina, I., 2006. Plan stability: Replanning
versus plan repair. In: ICAPS.
4.45. Tonino, H., Bos, A., de Weerdt, M., Witteveen, C., 2002. Plan coordination by
revision in collective agent based systems. Artificial Intelligence 142 (2), 121–
145.
4.46. van der Krogt, R., de Weerdt, M., 2005. Plan repair as an extension of planning.
In: ICAPS.
4.47. Alcazar, V., veloso, M. M., Borrajo, D., 2011. Adapting a Rapidly-Exploring
Random Tree for Automated Planning. In: SoCS.
4.48. Burfoot, D., Pineau, J., Dudek, G., 2006. RRT-plan: a randomized algorithm for
strips planning. In: AAAI. pp. 362–365.
4.49. Mausam, Kolobov, A., 2012. Planning with Markov Decision Processes: An AI
Perspective. Morgan & Claypool.
4.50. Boutilier, C., Dean, T., Hanks, S., May 1999. Decision-Theoretic Planning:
Structural Assumptions and Computational Leverage. JAIR 11, 1–94.
4.51. Hansen, E. A., Zilberstein, S., 2001. LAO*: A heuristic search algorithm that
finds solutions with loops. Artificial Intelligence 129 (1), 35–62.
4.52. Bonet, B., Geffner, H., 2006. Learning in Depth-First Search: A Unified
Approach to Heuristic Search in Deterministic, Non-Deterministic,
Probabilistic, and Game Tree Settings. In: ICAPS.
4.53. Barto, A. G., Bradtke, S. J., Singh, S. P., 1995. Learning to Act Using Real-Time
Dynamic Programming. Artificial Intelligence 72 (1-2), 81–138.
4.54. Bonet, B., Geffner, H., 2006. Learning Depth-First Search: A Unified Approach
to Heuristic Search in Deterministic and Non-Deterministic Settings, and Its
Application to MDPs. In: ICAPS.
4.55. Petrick, R., Bacchus, F., 2004. Extending the Knowledge-Based approach to
Planning with Incomplete Information and Sensing. In: ICAPS. pp. 2–11.
4.56. Brenner, M., Nebel, B., Jun. 2009. Continual planning and acting in dynamic
multiagent environments. Autonomous Agent and Multi-Agent Systems 19 (3),
297–331.
4.57. Santana, P. H. R. Q. A., Williams, B. C., Nov. 2014. Chance-Constrained
Consistency for Probabilistic Temporal Plan Networks. In: ICAPS.
4.58. Rockel, S., Neumann, B., Zhang, J., Dubba, K. S. R., Cohn, A. G., Konecny,´ S.,
Mansouri, M., Pecora, F., Sa ˇ ffiotti, A., Gunther, M., Stock, S., Hertzberg, J.,
Tome, A. M., Pinho, A., Seabra Lopes, L., von Riegen, S., Hotz, L., 2013. An
Ontology-Based Multi-Level Robot ´ Architecture for Learning from
Experiences. In: AAAI Spring Symposium. pp. 1–6.
4.59. Lemaignan, S., Espinoza, R. R., Mosenlechner, L., Alami, R., Beetz, M., 2010.
ORO, a knowledge management platform for cognitive ¨ architectures in
robotics. In: IROS.
4.60. Ingrand, F., Chatilla, R., Alami, R., Robert, F., 1996. PRS: a high level supervision
and control language for autonomous mobile robots. In: ICRA. pp. 43–49.
4.61. Firby, R. J., 1987. An investigation into reactive planning in complex domains.
In: AAAI.
4.62. Fikes, R. E., Aug. 1971. Monitored Execution of Robot Plans Produced by
STRIPS. In: IFIP Congress. Ljubljana, Yugoslavia.
4.63. Pettersson, O., 2005. Execution monitoring in robotics: A survey. Robotics and
Autonomous Systems 53 (2), 73–88.
4.64. Kuipers, B., Byun, Y.-T., 1991. A robot exploration and mapping strategy based
on a semantic hierarchy of spatial representations. Robotics and Autonomous
Systems 8 (1-2), 47–63.
4.65. Kuipers, B., Modayil, J., Beeson, P., MacMahon, M., Savelli, F., 2004. Local
Metrical and Global Topological Maps in the Hybrid Spatial Semantic
Hierarchy. In: ICRA. pp. 4845–4851.
4.66. Konolige, K., Marder-Eppstein, E., Marthi, B., 2011. Navigation in Hybrid
Metric-Topological Maps. In: ICRA.
4.67. Laporte, C., Arbel, T., 2006. Efficient discriminant viewpoint selection for active
bayesian recognition. IJRR 68 (3), 267–287.
4.68. Pineau, J., Montemerlo, M., Pollack, M. E., Roy, N., Thrun, S., Mar. 2003.
Towards robotic assistants in nursing homes: Challenges and results. Robotics
and Autonomous Systems 42 (3-4), 271–281.
4.69. Prentice, S., Roy, N., 2009. The belief roadmap: Efficient planning in belief
space by factoring the covariance. IJRR 28 (11–12), 1448–1465.
4.70. Sridharan, M., Wyatt, J. L., Dearden, R., 2008. HiPPo: Hierarchical POMDPs
for Planning Information Processing and Sensing Actions on a Robot. In:
ICAPS. pp. 346–354.
4.71. Velez, J., Hemann, G., Huang, A., Posner, I., Roy, N., 2011. Planning to
perceive: Exploiting mobility for robust object detection. In: ICAPS.
4.72. Coradeschi, S., Saffiotti, A., 2002. Perceptual anchoring: a key concept for plan
execution in embedded systems. In: Beetz, M., Hertzberg, J., Ghallab, M.,
Pollack, M. E. (Eds.), Advances in Plan-Based Control of Robotic Agents.
Springer-Verlag, pp. 89–105.
4.73. Karlsson, L., Bouguerra, A., Broxvall, M., Coradeschi, S., Saffiotti, A., 2008. To
Secure an Anchor – A recovery planning approach to ambiguity in perceptual
anchoring. AI Communications 21 (1), 1–14.
KBA Agentul bazat pe cunoaștere
KB Baza de cunoștințe
LTS Labelled Transition System
CTL Computation Tree Logic
LTL Linear Temporal Logic
BDI Belief-Desire-Intention
AgentSpeak Limbaj de programare
LISA Limited Instruction Set Architecture
BDD Binary-Decision-Diagram
BES Boolean Evolution System
ISPL Interpreted System Programming Language
CUDD CUDD reprezintă diagrama de decizie a Universității

Colorado. Este un pachet pentru manipularea diagramelor de
decizie binare (BDD), a diagramelor de decizie algebrice (ADD)
și diagramelor de decizie binare (ZDD)
MCMAS Limbaj de programare
MDP Procese Markov cu decizie
PRM Modelul relațional probabilistic
RRT Randomized Response Technique
AHP Angelic Hierarchical Planning
VHPOP Planificatorul euristic parțial de comandă euristică
Crickey Planificator care separă raționamentul logic și temporal
COLIN Planificator cu schimbare lineară continuă
POMDP Partially Observable Markov Decision Processes
SSP Stochastic Shortest Path
RTDP RealTime Dynamic Programming
LRTDP Labeled-RTDP
PKS Process Knowledge System
OWL Limbajul standard pentru ontologie web
DL Description logic
HTN Planificarea rețelei de sarcini ierarhice (HTN) este o tehnică de
planificare AI
ORO Open Robot Ontology
Stanford Research Institute Problem Solver este cunoscut și sub
acronimul FOLIE, este un planificator automatizat dezvoltat de
Richard Fikes și Nils Nilsson în 1971 la SRI International
FDIR Detectarea, identificarea și recuperarea erorilor
SLAM Localizare și cartografiere simultană
HiPPo Sistem de mentenanță a activitaților
POMDP Proces decizional Markov parțial observabil
5. MACHINE LEARNING
Problema căutării tiparelor în date este una fundamentală și are o istorie lungă
și de succes. De exemplu, observațiile astronomice extinse ale lui Tycho Brahe din
secolul al XVI-lea i-au permis lui Johannes Kepler să descopere legile empirice ale
mișcării planetare, care, la rândul lor, au oferit o trambulină pentru dezvoltarea
mecanicii clasice. În mod similar, descoperirea regularităților în spectrele atomice a
jucat un rol cheie în dezvoltarea și verificarea fizicii cuantice la începutul secolului
al XX-lea. Domeniul recunoașterii tiparului se referă la descoperirea automată a
regularităților în date prin utilizarea algoritmilor de calculator și la utilizarea acestor
regularități pentru a întreprinde acțiuni precum clasificarea datelor în diferite
categorii. Spre exemplu recunoașterea cifrelor scrise de mână, ilustrat în Figura 5.1.
Fig. 5.1 Exemplu de recunoaștere a cifrelor scrise de mână. [5.1], Figure 1.1, pg. 2
Fiecare cifră corespunde unei imagini de 28 × 28 pixeli și astfel poate fi

reprezentată printr-un vector x cuprinzând 784 de numere reale. Scopul este de a
construi o mașină care va lua un astfel de vector x ca intrare și care va produce
identitatea cifrei 0, ..., 9 ca ieșire.
Aceasta este o problemă netrivială datorită variabilității largi a scrisului de
mână. Ar putea fi abordată folosind reguli artizanale sau euristică pentru a distinge
cifrele pe baza formelor imaginilor, dar în practică o astfel de abordare duce la o
proliferare de reguli și a unor excepții de la reguli și așa mai departe și oferă
invariabil rezultate slabe.
Rezultate mult mai bune pot fi obținute adoptând o abordare de învățare
automată în care un set mare de N cifre x1 , , xN  numit set de antrenament este
utilizat pentru a regla parametrii unui model adaptiv. Categoriile cifrelor din setul de
antrenament sunt cunoscute în avans, de obicei prin inspectarea lor individuală și
etichetarea manuală a acestora. Putem exprima categoria unei cifre folosind vectorul
țintă t, care reprezintă identitatea cifrei corespunzătoare.
Rezultatul executării algoritmului de învățare automată poate fi exprimat ca o

funcție y ( x ) care ia o nouă cifră imagine x ca intrare și care generează un vector
de ieșire y, codificat în același mod ca vectorii țintă. Forma precisă a funcției y ( x)
este determinată în timpul fazei de instruire, cunoscută și sub numele de faza de
învățare, pe baza datelor de instruire. Odată ce modelul este instruit, acesta poate
determina identitatea imaginilor cu cifre noi, despre care se spune că dețin un set de
teste. Abilitatea de a clasifica corect exemplele noi care diferă de cele utilizate pentru
instruire este cunoscută sub numele de generalizare. În aplicații practice,
variabilitatea vectorilor de intrare va fi de așa natură încât datele de antrenament pot
cuprinde doar o mică parte din toți vectorii de intrare posibili, astfel încât
generalizarea este un obiectiv central în recunoașterea tiparului.
Pentru majoritatea aplicațiilor practice, variabilele de intrare originale sunt de
obicei procesate pentru a le transforma într-un spațiu nou de variabile în care, se speră,
problema de recunoaștere a modelelor va fi mai ușor de rezolvat. De exemplu, în
problema recunoașterii cifrelor, imaginile cifrelor sunt de obicei traduse și scalate,
astfel încât, fiecare cifră să fie conținută într-o cutie de dimensiune fixă. Acest lucru
reduce foarte mult variabilitatea în cadrul fiecărei clase de cifre, deoarece locația și
scara tuturor cifrelor sunt acum aceleași, ceea ce face mult mai ușor, pentru un algoritm
de recunoaștere a modelelor, ulterior să se facă distincția între diferitele clase. Această
etapă de pre-procesare se numește uneori și extragerea caracteristicilor. Noile date de
testare trebuie prelucrate în prealabil folosind aceiași pași ca și datele de instruire.
Pre-procesarea ar putea fi, de asemenea, efectuată pentru a accelera calculul.
De exemplu, dacă obiectivul este detectarea feței în timp real într-un flux video de
înaltă rezoluție, computerul trebuie să gestioneze un număr mare de pixeli pe
secundă, iar prezentarea acestora direct la un algoritm complex de recunoaștere a
modelelor poate fi neefectuabilă din punct de vedere al calculului. În schimb, scopul
este de a găsi caracteristici utile care să fie rapide de calculat și să păstreze și
informații utile discriminatorii care să permită distingerea fețelor de non-fețe. Aceste
caracteristici sunt apoi utilizate ca intrări în algoritmul de recunoaștere a modelelor.
Deoarece numărul acestor caracteristici este mai mic decât numărul de pixeli,
acest tip de pre-procesare reprezintă o formă de reducere a dimensionalității. Trebuie
avut grijă în timpul prelucrării prealabile, deoarece deseori informațiile sunt aruncate și,
dacă aceste informații sunt importante pentru soluționarea problemei, atunci acuratețea
generală a sistemului poate avea de suferit.
Aplicațiile în care datele de instruire cuprind exemple de vectori de intrare
împreună cu vectorii țintă corespunzători sunt cunoscute sub numele de probleme de
învățare supravegheate. Cazuri precum exemplul de recunoaștere a cifrelor, în care
scopul este de a atribui fiecare vector de intrare unuia dintr-un număr finit de categorii
discrete, se numesc probleme de clasificare. Dacă ieșirea dorită constă din una sau mai
multe variabile continue, atunci sarcina se numește regresie. Un exemplu de problemă
240 5 – Machine-Learning
de regresie ar fi predicția randamentului într-un proces de fabricație chimică în care

intrările constau în concentrațiile reactanților, temperatura și presiunea.
În alte probleme de recunoaștere a modelelor, datele de formare constau
dintr-un set de vectori de intrare x fără valori țintă corespunzătoare. Scopul unor astfel
de probleme de învățare nesupravegheate poate fi descoperirea grupurilor de exemple
similare în cadrul datelor, unde se numește clustering, sau determinarea distribuției
datelor în spațiul de intrare, cunoscut sub numele de estimare a densității, sau
proiectarea datelor dintr-un spațiu unidimensional până la două sau trei dimensiuni
în scopul vizualizării.
În cele din urmă, tehnica învățării profunde [5.2] este preocupată de problema
găsirii acțiunilor adecvate de întreprins într-o situație dată pentru a maximiza o
recompensă. Aici algoritmului de învățare nu i se oferă exemple de rezultate optime,
spre deosebire de învățarea supravegheată, ci trebuie să le descopere printr-un proces
de încercare și eroare. De obicei, există o secvență de stări și acțiuni în care
algoritmul de învățare interacționează cu mediul său. În multe cazuri, acțiunea
curentă nu numai că afectează recompensa imediată, ci are și un impact asupra
recompensei la toate etapele de timp ulterioare. De exemplu, folosind tehnici
adecvate de învățare profundă, o rețea neuronală poate învăța să joace jocul de table
la un standard înalt [5.3]. Aici rețeaua trebuie să învețe să ia o poziție ca intrare,
împreună cu rezultatul unei aruncări de zaruri și să producă o mișcare ca ieșire. Acest
lucru se realizează prin faptul că rețeaua se joacă împotriva unei copii proprii pentru
probabil un milion de jocuri. O provocare majoră este aceea că un joc de table poate
implica zeci de mișcări și, totuși, doar la sfârșitul jocului se obține recompensa, sub
formă de victorie. Recompensa trebuie apoi atribuită în mod corespunzător tuturor
mișcărilor care au condus la aceasta, chiar dacă unele mișcări vor fi fost bune și altele
mai puțin. Acesta este un exemplu de problemă de atribuire a creditului. O
caracteristică generală a învățării informațiilor este schimbul dintre explorare, în care
sistemul încearcă noi tipuri de acțiuni pentru a vedea cât de eficiente sunt acestea și
exploatare, în care sistemul folosește acțiuni despre care se știe că produc o
recompensă mare. O concentrare prea puternică asupra explorării sau exploatării va
produce rezultate slabe. Învățarea profundă continuă să fie un domeniu activ de
cercetare a învățării automate (machine learning).
5.1 Realizarea unei curbe polinomiale
Se pleacă de la o simplă problemă de regresie, ca exemplu de execuție pentru a

motiva o serie de concepte cheie. Se presupune că există o variabilă de intrare cu valoare
reală x și care să fie folosită pentru a prezice valoarea unei variabile țintă cu valoare reală
t. Se ia în considerare un exemplu artificial folosind date generate sintetic, deoarece se
cunoaște procesul precis care a generat datele pentru comparație cu orice model învățat.
Datele pentru acest exemplu sunt generate din funcția sin ( 2 x) .
În continuare, se presupune că există un set de antrenament care cuprinde N

observații ale lui x, scrise x  ( x1 , , xN ) , împreună cu observațiile corespunzătoare
T
ale valorilor lui t, notate t  (t1 , , t N ) . În Fig. 5.2 se prezintă un grafic al unui set de
T
antrenament cuprinzând N = 10 puncte de date. Setul de date de intrare x a fost generat


prin alegerea valorilor xn n = 1, , N , distanțate uniform în intervalul 0,1 , iar
setul de date țintă t a fost obținut calculând mai întâi valorile funcției sin ( 2 x) și apoi
adăugarea unui nivel mic de zgomot aleatoriu având o distribuție gaussiană la fiecare
astfel de punct pentru a obține valoarea corespunzătoare t n .
Fig. 5.2 Diagrama unui set de date de antrenament de N = 10 puncte, fiecare cuprinzând o
observare a variabilei de intrare x împreună cu variabila țintă corespunzătoare t. Curba arată
funcția sin (2πx) utilizată pentru a genera datele. Scopul este de a prezice valoarea lui t
pentru o valoare nouă a lui x, fără a cunoaște curba. [5.1], Figure 1.2, pg. 4
Prin generarea de date în acest mod, captăm o proprietate a mai multor seturi
de date reale, și anume că acestea posedă o regularitate subiacentă, pe care dorim să
o învățăm, dar că observațiile individuale sunt corupte de zgomot aleatoriu. Acest
zgomot ar putea apărea din procese intrinsec stochastice (adică aleatorii), cum ar fi
dezintegrarea radioactivă, dar mai ales se datorează existenței unor surse de
variabilitate care sunt ele însele neobservate.
Exploatarea setului de instruire pentru a face predicții ale valorii tˆ a variabilei
țintă pentru o nouă valoare x̂ a variabilei de intrare. După cum vom vedea mai târziu,
aceasta implică încercarea de a descoperi funcția sin ( 2 x) .
Acest lucru este dificil, deoarece trebuie realizată o generalizare dintr-un set
de date finite, multe date fiind corupte cu zgomot, astfel încât pentru un x̂ dat există
incertitudine cu privire la valoarea adecvată pentru tˆ . Abordarea privind ajustarea

curbei se face cu ajutorul unei funcții polinomiale:
M
y ( x, w) = w0 + w1 x + w2 x + 2
+ wM x =  w j x j ,
M
j =0
unde: M este ordinea polinomului.

Deși funcția polinomială y ( x, w) este o funcție neliniară în funcție de x, ea
devinie o funcție liniară datorită coeficienților w. Funcțiile, cum ar fi polinomul, care
sunt liniare în parametrii necunoscuți, se numesc modele liniare.
Valorile coeficienților vor fi determinate prin adaptarea polinomului la datele
de antrenament. Acest lucru se poate face prin reducerea la minimum a unei funcții
de eroare care măsoară nepotrivirea dintre funcția y ( x, w) , pentru orice valoare dată
de w și punctele de date ale setului de antrenament.
Fig. 5.3 Funcția de eroare E ( w) corespunde unei jumătăți din suma

pătratelor deplasărilor (prezentate de barele verticale)
a fiecărui punct de date din funcția y ( x, w) . [5.1], Figure 1.3, pg. 6.
O alegere simplă a funcției de eroare, este dată de suma pătratelor erorilor

dintre predicțiile y ( xn , w) :
1 N
E ( w) =   y ( xn , w) − tn  ,
2
2 n =1
unde: factorul 1/2 este inclus pentru comoditate ulterioară. Funcția de eroare este o
cantitate non-negativă care ar fi zero dacă și numai dacă funcția y ( x, w) ar trece
exact prin fiecare punct de date de antrenament (Fig. 5.3).
Problema ajustării curbei se poate rezolva prin alegerea unei valori a lui w pentru
care E ( w) este cât mai mică posibil. Derivatele funcției de eroare în raport cu coeficienții
vor fi liniare în elementele lui w*, astfel încât minimizarea funcției are o soluție unică, care
(
pot fi găsite în formă închisă. Polinomul rezultat este dat de funcția y x, w .
*
)
Problema alegerii ordinii M a polinomului este un concept numit comparație de
model sau selecție de model. În Fig. 5.4, prezentăm patru exemple de rezultate ale adaptării
polinoamelor având ordinele M = 0, 1, 3 și 9 la setul de date prezentat în Fig. 5.2.
Fig. 5.4 Graficele de polinoame având diferite ordine M, prezentate în curbe roșii, adaptate
la setul de date prezentat în Fig. 5.2. [5.1], Figure 1.4, pg. 7
.
Se observă că polinomele constante ( M = 0) și de ordinul întâi ( M = 1) dau
potriviri destul de slabe datelor și, în consecință, reprezentări destul de slabe ale funcției
sin ( 2 x) . Polinomul de ordinul trei ( M = 3) pare să dea cea mai bună potrivire
funcției sin ( 2 x) a exemplelor prezentate în Fig. 5.4. Când mergem la un polinom de
ordin mult mai mare ( M = 9) , obținem o potrivire excelentă la datele de antrenament.

( )
De fapt, polinomul trece exact prin fiecare punct de date și E w = 0 . Cu toate acestea,
*
curba ajustată oscilează și oferă o reprezentare foarte slabă a funcției sin ( 2 x) . Acest
din urmă comportament este cunoscut sub numele de supraadaptare.
O oarecare perspectivă cantitativă asupra dependenței performanței generalizării
în funcție de M se poate obține luând în considerare un set de test separat, care cuprinde
100 de puncte de date generate folosind exact aceeași procedură pentru a genera punctele
set de antrenament. Pentru fiecare alegere a lui M, putem evalua apoi valoarea reziduală
( ) dată de (1.2) pentru datele de antrenament și putem evalua și E (w )
a lui E w
* *
pentru setul de date de testare. Uneori este mai convenabil să se utilizeze rădăcina-medie-
pătratică în care împărțirea la N ne permite să comparăm diferite dimensiuni de seturi de
date pe picior de egalitate, iar rădăcina pătrată asigură faptul că ERMS este măsurat pe
aceeași scară (și în aceleași unități) ca variabila țintă t.
Fig. 5.5 Graficele erorii rădăcină-medie-pătrat, definite de (1.3), evaluate pe setul de

antrenament și pe un set de testare independentă pentru diferite valori ale lui M. [5.1],
Figure 1.5, pg. 8
În Fig. 5.5 sunt prezentate graficele erorilor RMS (root-mean-square /

rădăcina-medie-pătratică) ale setului de antrenament și testare, pentru diferite
valori ale lui M. Eroarea setului de testare este o măsură a cât de bine ne descurcăm
în prezicerea valorilor lui t pentru noi observații de date ale lui x. Observăm din
Fig. 5.5 că valorile mici ale lui M dau valori relativ mari ale erorii setului de testare,
iar acest lucru poate fi atribuit faptului că polinoamele corespunzătoare sunt destul
de inflexibile și sunt incapabile să capteze oscilațiile în funcția sin ( 2x ) . Valorile
lui M în intervalul 3  M  8 dau valori mici pentru eroarea setului de testare și
acestea oferă, de asemenea, reprezentări rezonabile ale funcției generatoare
sin ( 2x ) , după cum se poate vedea, pentru cazul lui M = 3 , din Fig. 5.4.
Pentru M = 9 , eroarea setului de antrenament merge la zero, așa cum ne-am

putea aștepta, deoarece acest polinom conține 10 grade de libertate corespunzătoare
celor 10 coeficienți w0 , w1 , , w9 și astfel poate fi reglat exact la cele 10 puncte
de date din setul de antrenament. Cu toate acestea, eroarea setului de testare a devenit
foarte mare și, așa cum am văzut în Fig. 5.4, funcția corespunzătoare y x, w ( *
)
prezintă oscilații. Acest lucru poate părea paradoxal deoarece un polinom de ordine
dată conține toate polinoamele de ordin inferior fiind cazuri speciale. Prin urmare,
polinomul M = 9 este capabil să genereze rezultate cel puțin la fel de bune ca și
polinomul M = 3 . Mai mult, am putea presupune că cel mai bun predictor al noilor
date ar fi funcția sin ( 2x ) din care au fost generate datele. Știm că o expansiune a
puterii funcției sin ( 2x ) conține termeni ai tuturor ordinelor, așa că ne-am putea
aștepta ca rezultatele să se îmbunătățească monoton pe măsură ce creștem M.
Fig. 5.6 Graficele soluțiilor obținute prin reducerea la minimum a funcției de eroare sumă
de pătrate folosind polinomul M = 9 pentru N = 15 puncte de date (graficul din stânga) și
N = 100 puncte de date (graficul din dreapta). Vedem că mărirea dimensiunii setului de
date reduce problema supraadaptării [5.1], Figure 1.6, pg. 9
De asemenea, este interesant să examinăm comportamentul unui model dat,

deoarece dimensiunea setului de date este variată M = 15 și M = 100 , așa cum se
arată în Fig. 5.6. Vedem că, pentru o anumită complexitate a modelului, problema
supraadaptării devine mai puțin severă pe măsură ce crește dimensiunea setului de
date. O altă modalitate de a spune acest lucru este că, cu cât setul de date este mai
mare, cu atât este mai complex (cu alte cuvinte, mai flexibil) modelul pe care ne
putem permite să îl potrivim datelor.
O altă abordare privind controlul fenomenului de ajustare excesivă este cea a
regularizării, care implică adăugarea unui termen de penalizare la funcția de eroare
pentru a descuraja coeficienții de a atinge valori mari. Cel mai simplu astfel de
termen de penalizare ia forma unei sume de pătrate a tuturor coeficienților, ducând

la o funcție de eroare modificată a formei:
1 N  2
E ( w) =   y ( xn , w) − tn  + w
2
2 n =1 2
w  wT w = w02 + w12 + + wM2 și coeficientul λ guvernează importanța

2
unde:
relativă a termenului de regularizare în comparație cu termenul de eroare suma
pătratelor.
În general coeficientul w0 este omis din regulator, deoarece includerea
acestuia determină rezultatele să depindă de alegerea originii variabilei țintă [5.4]
sau poate fi inclus, dar cu propriul său coeficient de regularizare. Din nou, funcția de
eroare E ( w) poate fi redusă la minimum exact în formă închisă. Tehnici de acest
gen sunt cunoscute în literatura de statistică drept metode de contracție, deoarece
reduc valoarea coeficienților. Cazul particular al unui regulator pătratic se numește
regresie a crestei [5.5]. În contextul rețelelor neuronale, această abordare este
cunoscută sub numele de descompunere în greutate.
Fig. 5.7 Diagramele de M = 9 polinoame montate pe setul de date prezentat în Figura 5.2
folosind funcția de eroare regularizată E ( w) pentru două valori ale parametrului de
regularizare λ corespunzător ln  = −18 și ln  = 0 . Cazul fără regulator, Adică,  = 0 ,
corespunzător ln  = − , este prezentat în partea dreaptă jos a figurii 5.4. [5.1],
Figure 1.7, pg. 10,
În Fig. 5.7 se prezintă rezultatele adaptării polinomului de ordinul M = 9 la

același set de date ca înainte, dar folosind acum funcția de eroare regularizată dată
de E ( w) . Vedem că, pentru o valoare de ln  = −18 supraadaptarea a fost suprimată
și obținem acum o reprezentare mult mai apropiată a funcției subiacente sin ( 2x ) .
Dacă, totuși, folosim o valoare prea mare pentru λ atunci obținem din nou o potrivire
slabă, așa cum se arată în Fig. 5.7 pentru ln  = 0 . Coeficienții corespunzători din
polinoamele potrivite sunt date în Tabelul 1.2, arătând că regularizarea are valoarea
dorită efect de reducere a magnitudinii coeficienților.
Tabelul 5.1. Coeficienții w* pentru polinoamele cu M = 9 cu diferite valori pentru

parametrul de regularizare λ. Unde ln  = − corespunde unui model fără regularizare,
adică graficului din dreapta jos în Figura 5.4. Vedem că, pe măsură ce valoarea lui λ crește,
magnitudinea tipică a coeficienților devine mai mică
ln  = − ln  = −18 ln  = 0
*
w 0
0.35 0.35 0.13
w1* 232.37 4.74 -0.05
w2* -5321.83 -0.77 -0.06
w3* 48568.31 -31.97 -0.05
w4* -231639.30 -3.89 -0.03
w5* 640042.26 55.28 -0.02
w6* -1061800.52 41.32 -0.01
w7* 1042400.18 -45.95 0.00
w8* -557682.99 -91.53 0.00
w9* 125201.43 72.68 0.01
Impactul termenului de regularizare asupra erorii de generalizare poate fi

văzut prin reprezentarea valorii RMSerror atât pentru antrenament, cât și pentru
seturile de testare față de ln  , așa cum se arată în Fig. 5.8. Vedem că, de fapt, λ
controlează acum complexitatea efectivă a modelului și, prin urmare, determină
gradul de supra-montare.
Rezolvarea unei aplicații practice folosind această abordare de minimizare a
unei funcții de eroare, ar trebui să găsească o modalitate de a determina o valoare
adecvată pentru complexitatea modelului. Rezultatele de mai sus sugerează o
modalitate simplă de a realiza acest lucru, și anume luând datele disponibile și
partiționându-le într-un set de instruire, utilizat pentru a determina coeficienții w, și
un set de validare separat, numit și set de rezistență, utilizat pentru a optimiza
complexitatea modelului (fie M, fie λ). Cu toate acestea, în multe cazuri, acest lucru
se va dovedi prea irositor cu date valoroase de instruire și trebuie căutate abordări
mai sofisticate.
Fig. 5.8 Graficul ERMS versus ln 

pentru un polinom cu M = 9. [5.1], Figure 1.8, pg. 11
5.2 Învățarea reperelor vizuale de către un robot mobil
Progrese înregistrate în domeniul roboticii, în sistemele mecanice, actuatoare,

control și planificare, au permis aplicarea pe scară largă a roboților industriali, unde
brațele manipulatoare, roboții cartezieni etc. au înlocuit sau completat personalul
uman. În domeniul roboților mobili autonomi capacitatea de a evolua și îndeplini
sarcini generale în medii necontrolate, este încă departe de realizare. Acest lucru se
datorează, în principal, deoarece roboții mobili autonomi suferă limitările sistemelor
de percepție din zilele noastre. Un robot trebuie să-și perceapă mediul pentru a
interacționa (mișca, găsi și manipula obiecte etc.) cu acesta. Percepția permite
realizarea unei reprezentări interne (model) a mediului, care trebuie utilizat pentru
mișcare, evitarea coliziunii, găsirea poziției și drumul către țintă și găsirea obiectelor
care să le manipuleze. Fără o percepție suficientă asupra mediului, robotul pur și
simplu nu poate face nici o deplasare sau interacțiune sigură, chiar și cu sisteme de
mișcare sau planificare extrem de eficiente. Cu cât un mediu este mai nestructurat,
cu atât robotul este mai dependent de sistemul său senzorial. Succesul roboticii
industriale se bazează pe medii controlate și planificate rigid și pe un control total
asupra poziției robotului în fiecare moment. Dar pe măsură ce gradul structurii
mediului scade, capacitatea robotului devine limitată.
Un anumit tip de mediu de model trebuie utilizat pentru a încorpora percepții și
a lua decizii de control. Din punct de vedere istoric, majoritatea roboților mobili se
bazează pe o reprezentare geometrică a mediului pentru sarcinile de navigație. Acest
lucru facilitează planificarea traseului și reduce dependența de sistemul senzorial, dar
forțează să monitorizeze continuu poziția exactă a robotului și necesită o modelare
precisă a mediului. Problema de navigație este rezolvată cu relocalizarea odometriei1

sau cu un sistem extern de localizare absolută, dar numai în medii foarte structurate.
Cu toate acestea, ființele umane folosesc o reprezentare topologică a mediului pentru
a-și atinge capacitatea de autonomie. Aici, mediul este modelat slab de o serie de
obiecte sau locuri identificabile și de relațiile spațiale dintre ele. Modelele rezultate
sunt potrivite pentru a fi învățate, în loc să fie codificate. Acest lucru este potrivit
pentru medii deschise și dinamice, dar are o dependență mai mare de sistemul de
percepție. Combinația dintre modelarea și viziunea topologică a mediului este cea mai
promițătoare selecție pentru viitorii roboți autonomi. Aceasta implică necesitatea
dezvoltării unor sisteme de percepție vizuală capabile să învețe din mediu.
În urma acestor probleme, un nou sistem de percepție vizuală de învățare
pentru roboți se bazează pe un sistem generic de detectare și recunoaștere a reperelor.
Aici, un reper este o caracteristică fizică localizată pe care robotul o poate simți și
utiliza pentru a-și estima propria poziție în raport cu un fel de „hartă” care conține
poziția relativă a reperului și / sau altă caracterizare a semnelor. Este capabil să învețe
și să utilizeze aproape orice tip de marcaj funciar pe medii structurate și
nestructurate. Folosește modele deformabile ca reprezentare de bază a reperelor și
algoritmi genetici pentru a le căuta în spațiul modelului. Modelele deformabile au
fost studiate în analiza imaginii în ultimul deceniu și sunt utilizate pentru detectarea
și recunoașterea șabloanelor flexibile sau rigide în diverse condiții de vizionare.
În loc să primească definiția modelului de la utilizator, sistemul extrage și
învață automat informațiile din obiecte. Ambele modele 2D și 3D au fost studiate,
deși doar modelele 2D au fost testate pe un robot mobil. Sistemul vizual trebuie să
fie capabil să funcționeze cu orice reper 2D sau 3D. Acest sistem nu este dezvoltat
special pentru un singur obiect.
Modelul deformabil transportă informațiile de referință în interior, astfel încât
aceste informații sunt adaptate la deformarea modelului și pot fi utilizate pentru a
evalua aptitudinea modelului. Acest lucru se realizează folosind un algoritm genetic,
în care fiecare element reprezintă un model deformat. Populația explorează apoi
imaginea în timpul evoluției sale. Algoritmul de căutare genetică este capabil să facă
față problemelor de deformare a perspectivei reperului. Al doilea aspect relevant este
capacitatea sistemului pentru citirea textului sau a icoanelor în reperele concepute
pentru uz uman, astfel încât sistemul poate fi utilizat pentru a găsi și citi semne,
panouri și icoane atât în mediul interior, cât și în exterior. Acest lucru permite
robotului să ia decizii la nivel înalt și are ca rezultat un grad mai ridicat de integrare
a roboticii mobile în viața de zi cu zi. Au fost realizate diferite rezultate
experimentale în medii reale, care arată eficacitatea și capacitatea sistemului de
învățare, detectare și citire a reperelor. Aceste experimente sunt sarcini de navigație
topologică la nivel înalt. Identificarea încăperii din interior, fără nicio inițializare, se
realizează prin semnătura sa de reper. Căutarea camerei de-a lungul unui coridor se
1
Tehnică a măsurării distanțelor parcurse de un vehicul sau de un pieton
face citind conținutul plăcuțelor de identificare a camerei plasate în jur pentru uz

uman; aceasta permite robotului să ia decizii la nivel înalt și are ca rezultat un grad
mai mare de integrare a roboticii mobile în viața reală. În cele din urmă, deși sistemul
prezentat este testat pentru navigația topologică a robotului mobil, acesta este
suficient de general pentru utilizarea sa directă într-o gamă largă de aplicații, cum ar
fi navigația geometrică, sistemele de inspecție și supraveghere etc.
5.3 Stadiul actual privind navigația roboților mobili
Roboții mobili au multe aplicații potențiale în sarcini de rutină sau periculoase,

cum ar fi operațiuni într-o centrală nucleară, livrarea de provizii în spitale și curățarea
birourilor și caselor [5.6]. Un robot autonom mobil trebuie să aibă un sistem de
navigație fiabil pentru a evita obiectele aflate în calea sa și pentru a recunoaște
obiecte importante ale mediului pentru a identifica locurile pentru a înțelege mediul
înconjurător. O condiție prealabilă pentru navigația geometrică a unui robot mobil
este metoda de găsire a poziției. Odometria este cea mai utilizată metodă de
localizare pentru navigarea geometrică a robotului mobil. Problema este că
acumularea de erori de măsură mici va provoca erori mari de poziție, care cresc
proporțional cu distanța parcursă de robot.
Alunecarea roții și diametre inegale ale roții sunt cea mai importantă sursă de
eroare [5.7]. Pe măsură ce un robot mobil se deplasează prin mediul său, poziția și
orientarea sa reală diferă întotdeauna de poziția și orientarea pe care i se poruncește
să o dețină. Erorile se acumulează, iar incertitudinea localizării crește în timp.
O abordare alternativă este navigarea topologică. Permite depășirea unora
dintre problemele clasice ale navigației geometrice la roboții mobili, cum ar fi
reducerea simultană a incertitudinii de localizare și de percepție a mediului [5.8]. Pe
de altă parte, navigația topologică depinde în mare măsură de un sistem puternic de
percepție pentru identificarea elementelor mediului. Elementele alese pentru
recunoaștere sau reperele ar trebui să fie suficient de simple pentru a permite o
identificare ușoară din diferite puncte de vedere și distanțe.
Recunoașterea vizuală este problema determinării identității și poziției unui
element fizic dintr-o proiecție a imaginii acestuia. Această problemă este dificilă în
situații practice din viața reală, din cauza iluminării necontrolate, a distanțelor și a
unghiurilor de vedere față de repere. Tehnicile de învățare automată sunt aplicate cu
succes mai multor probleme de viziune și percepție pe computer [5.9]. Dificultatea
ridicării la sarcini complexe constă în faptul că metodele de învățare inductivă
necesită un număr foarte mare de tipare de antrenament pe baza informațiilor ridicate
de senzorii de densitate mare (cum ar fi camerele video). Cu toate acestea, rezultatele
recente în învățarea robotului mobil au demonstrat că roboții pot învăța obiecte
simple pentru a identifica din foarte puține cunoștințe inițiale în medii restricționate
[5.10].
Există două abordări majore în utilizarea reperelor pentru navigația topologică
în literatura conexă. O abordare folosește ca repere regiunile mediului care pot fi
recunoscute ulterior, deși nu sunt un singur obiect. Alte tehnici de recunoaștere

vizuală consideră obiectele că sunt reprezentate de familii de suprafețe într-un spațiu
de aspect local. Multe sisteme de navigație spațială se bazează pe șabloane vizuale;
șabloanele sunt create selectând un număr de caracteristici cu contrast ridicat în
imagine și stocându-le împreună cu locația lor spațială relativă. Diferite metode de
recunoaștere a locului pentru roboți mobili se bazează pe potrivirea semnăturii de
imagine. În [5.11] prezintă o metodă de reprezentare a locurilor folosind un set de
repere vizuale dintr-un senzor panoramic, permițând o poziționare locală precisă.
[5.12] a dezvoltat un sistem bazat pe viziune pentru navigația topologică în medii
deschise. Acest sistem reprezintă locurile selectate prin vizualizări locale la 360 ° ale
scenelor din jur. A doua abordare utilizează obiectele din mediu ca repere, cu
algoritmi de percepție proiectați special pentru fiecare obiect. Un alt sistem pentru
localizarea topologică a unui robot mobil folosește potrivirea histogramei color a
imaginilor omni direcționale. În [5.13], imaginile sunt codificate ca un set de
caracteristici vizuale. Repere potențiale sunt detectate folosind un mecanism de
atenție implementat ca o măsură a unicității. [5.14] descrie o serie de comportamente
motrice și perceptuale utilizate pentru navigația interioară a roboților mobili; pereții,
ușile și coridoarele sunt utilizate ca repere. În [5.15] este propus un sistem de
navigație interioară, inclusiv predarea mediului său; localizarea vehiculului se face
prin detectarea tuburilor fluorescente cu o cameră.
5.4 Modele deformabile
Majoritatea sistemelor, de detectare a obiectelor vizuale, se bazează pe

reprezentări de obiecte realizate manual și pe reguli de căutare, ceea ce face dificilă
adaptabilitatea sistemului. Este nevoie de sisteme generale și practice de detectare a
obiectelor care pot fi adaptate rapid și ușor la diferite aplicații. Această nevoie de
sisteme practice conduce inexorabil la unele restricții, de obicei opuse generalității:
1. Timpul de calcul nu poate depăși limitele de utilizare. Deși sistemul propus
este suficient de general pentru manipularea obiectelor 3D generale,
restricțiile de timp obligă să se particularizeze pentru obiectele plane sau
fețele individuale ale obiectelor 3D. Cu toate acestea, sistemul este
conceput pentru și poate fi extins cu ușurință la detectarea obiectelor 3D,
dacă se dorește.
2. Flexibilitatea și generalitatea indică sisteme generale care pot învăța și
utiliza obiecte noi cu o intervenție umană minimă.
3. Robustețea este încurajată de capacitatea de învățare. Nicio învățare nu
poate avea loc fără o anumită evaluare a performanței sale.
Sistemul particularizat cu modele deformabile menține suficientă generalitate
pentru a face față detectării aproape a oricărui obiect plan din imagini reale
aglomerate, necontrolate, în timp real, numai prin mijloace software. Utilizează
obiecte de reprezentare simple, dar eficiente prin intermediul unor modele
deformabile și este ușor de adaptat pentru a detecta obiecte noi prin antrenament din
imagini, cu intervenție umană minimă (marcând doar obiectul de învățat în imaginile

de antrenament).
Modelele deformabile [5.16, 5.17] sunt utilizate pentru detectarea și
recunoașterea modelelor flexibile sau rigide în diferite condiții de vizionare [5.18].
Au fost aplicate pentru interogarea unei baze de date, având în vedere forma,
culoarea și textura obiectului [5.19]; segmentarea bazată pe mișcare a structurilor
deformabile care suferă mișcări nerigide prin formă și flux optic [5.20]; pentru
vehiculele inteligente, acestea au fost utilizate pentru a detecta indicatoarele rutiere
[5.21], vehiculele [5.22] și frontierele rutiere [5.23]; după lucrarea lui [5.17], acestea
sunt utilizate în mod obișnuit pentru detectarea și urmărirea feței umane [5.24];
recunoașterea caracterelor și a simbolurilor liniare în desenele scrise de mână [5.25];
în imagini medicale, acestea au fost utilizate pentru segmentarea nucleelor cerebrale
profunde în RMN 3D [5.26], segmentarea celulară [5.27] sau celule canceroase de
melanom uman în imagistica microscopică confocală [5.8].
O schemă de segmentare a imaginii bazată pe un model global format din
următoarele blocuri [5.28]:
1. Modelul inițial, M, un model cu o zonă fixă, situat în centrul imaginii.
2. Modelul deformabil M (Z). Acest model este obținut de la cel anterior prin
parametrii de deformare, Z. Pot fi poziție, scară orizontală și verticală,
rotație și parametru de deformare suplimentar.
3. Funcția densității probabilității de probabilitate, p (I | Z), care înseamnă că
probabilitatea setului de deformare Z apare în imaginea I.
4. Un algoritm de căutare pentru a găsi maximul probabilității posterioare p
(Z | I).
Într-o ultimă etapă, dacă obiectul detectat conține informații simbolice - cum
ar fi text sau pictograme - acesta este interpretat folosind un clasificator bazat pe
rețea neuronală selectat empiric.
Domeniile potențiale de aplicare sunt robotul mobil (repere în sarcinile de
navigație), robotul industrial (detectarea și manipularea obiectelor), sistemele de
asistență la conducere (semne de circulație, panouri informative rutiere, detectarea
vehiculelor) și sarcinile industriale (detectarea și inspecția obiectelor, citirea
etichetelor).
Reprezentările de obiecte bazate pe puncte de vedere decât pe cele centrate pe
obiect pun accentul pe problemele de detectare și reprezentare a obiectelor, cum ar
fi aspectul și combinația de vizualizări. Vizualizările model ale obiectelor sunt un
mod simplu, dar bogat de reprezentare a obiectelor, dar au un dezavantaj major în
sensul schimbării aspectului obiectului cu perspectiva și iluminarea.
În sistemul de deformare a modelului schimbările de iluminare sunt tratate
folosind un sistem adecvat de reprezentare a culorilor, în timp ce modificările de
aspect legate de perspectivă sunt adaptate utilizării modelelor deformabile.
Fig. 5.9 (a) Modelul deformabil de bază și (b) detaliile adăugate s

pecifice obiectului. [5.29], Figure 1.3, pg. 8.
Modelul deformabil constă, de regulă, dintr-o figură geometrică de bază, spre

exemplu un paralelipiped 3D a cărui singură misiune este limitarea sau încadrarea
obiectului considerat, independent de tipul sau forma acestuia ( Fig. 5.9. a).
Parametrii geometrici ai modelului deformabil trebuie să urmeze schimbările de
aspect ale obiectului cu perspectiva. Apoi, un anumit tip de detaliu (date specifice
obiectului) trebuie adăugat peste modelul de bază deformabil pentru a distinge un
obiect de altul și de fundal (Fig. 5.9. b). Singura restricție aici este că acest detaliu
va trebui utilizat într-un mod care să permită urmărirea deformărilor modelului. Deci
fiecare obiect este reprezentat de un set de elemente specifice, care pot fi „lipite” de
un model general deformabil. Căutarea obiectului este apoi tradusă într-o căutare a
parametrilor modelului deformabil care face ca detaliile să se potrivească cu
fundalul.
În situația modelelor 2D, modelul deformabil are nevoie de 6 grade de
libertate (6 DOF) pentru a urmări translațiile și rotațiile obiectului și unele deformări
de perspectivă, definite de (X, Y) DOF (Fig. 5.10 a), reprezentând coordonatele
pixelilor punctului de referință pentru model (colțul din stânga sus). Scalarea
obiectelor (distanța față de cameră) este tratată cu perechea (X, Y), așa cum se arată
în Fig. 5.10.b. Parametrul D din Fig. 5.10.c gestionează rotația obiectului. În cele
din urmă, înclinarea obiectelor datorită deformării perspectivei afine este considerată
doar peste axa verticală, predominantă în imaginile reale; înclinarea generală de-a
lungul axei verticale poate fi descompusă ca o combinație a deformărilor de bază
ilustrate în Fig. 5.10.d și Fig. 5.10.e. În practică, numai componenta din Fig. 5.10.e,
măsurată prin DOF SKY, deformarea din Fig. 5.10.d este dominantă numai pentru
obiectele relativ mari și înguste și atunci când acestea se află la același nivel vertical
al axei optice. Aceste simplificări ale distorsiunilor de perspectivă ar putea fi ușor
evitate, dar oferă o reducere a numărului de grade de libertate luate în considerare,
economisind timp de calcul cu impact redus asupra scenelor reale.
Fig. 5.10 2D grade de libertate pentru modelul de bază deformabil. (a) translație, (b) scalare,
(c) rotație, (d) - (e) înclinare prin deformare în perspectivă. [5.29], Figure 1.4, pg. 9.
Fig. 5.11 Gradele de libertate ale extensiei 3D pentru modelul de bază deformabil.
[5.29], Figure 1.5, pg. 10.
Aceste șase grade de libertate sunt valabile pentru obiectele plane. Când se
lucrează cu obiecte 3D, trebuie adăugate mai multe grade de libertate. În abordarea
propusă, sunt necesare doar două noi grade de libertate, perechea (X', Y') cu
coordonatele pixelilor din partea frontală a modelului 3D deformabil ( Fig. 5.11.a),
acoperind deplasările obiectelor peste planul paralel cu imaginea și rotațiile peste
axa verticală. Rotațiile care nu sunt acoperite de  X’, Y’ pot fi gestionate fără a
adăuga nici un alt DOF, permițând pur și simplu parametrilor X și Y să fie
negativi. Efectul unei valori negative de X este prezentat în Fig. 5.11.b, în timp ce
un Y negativ este prezentat în Fig. 5.11.c.
Acest set de 6 DOF nu acoperă cu precizie toate deformările perceptibile
posibile ale unui obiect, dar permit aproximarea lor suficientă pentru a recunoaște
un obiect generic dacă sunt utilizate detalii adăugate adecvate și oferă o reducere a
spațiului de căutare a parametrilor.
Detectarea obiectului este acum un proces de căutare în spațiul parametrizat
al modelului, comparând detaliile adăugate modelului cu terenul din spate și cu
dimensiunea și deformarea pe care parametrii le determină. Două motive fac din

aceasta o căutare complexă: capacitatea dimensională ridicată a spațiului de căutare
(8 DOF) și funcția comparativă dintre detaliile adăugate și fundal. Această funcție
comparativă (sau cost) nu este predefinită a priori și poate fi foarte complexă și nu
neapărat o funcție parametrică.
Algoritmii evolutivi genetici s-au dovedit a fi un instrument foarte util pentru
aceste tipuri de procese de căutare [5.30, 5.31]. Dacă parametrii geometrici ai
modelului deformabil sunt codificați în genomul datelor dintr-un algoritm genetic,
fiecare element devine un model deformabil care încearcă să potrivească obiectul
dorit prin imagine. Funcția de antrenament pentru fiecare element este locul perfect
pentru a face potrivirea între detaliile adăugate ale modelului și fundal (funcția de
cost). Un algoritm genetic clasic (Genetic Algorithm - GA) este folosit pentru a face
căutarea în spațiul parametrilor modelului, cu codare binară standard, selecție
aleatorie, mutație standard și deplasare cu punct unic. GA este una dintre sarcinile în
așteptare de făcut, astfel căutarea poate fi accelerată considerabil. O realizare a
timpilor de calcul suficient de mici permite utilizarea sistemului în mod practic.
Aceasta presupune că se va efectua o inițializare GA adecvată pentru a accelera
convergența. Dacă inițializarea este suficient de bună, convergența GA este extrem
de rapidă.
Există o mare colecție de tehnici de căutare a modelelor 2D în literatură [5.32].
În această aplicație, se folosește o tehnică clasică: corelația normalizată cu o imagine
a modelului care trebuie găsit (denumit de obicei model). Cel mai puternic
dezavantaj este sensibilitatea ridicată la modificările aspectului modelului (în
principal dimensiunea și perspectiva), ceea ce face ca această metodă să nu fie
practică în majoritatea cazurilor. Se propune o metodă modificată în doi pași pentru
depășirea acestei probleme. În primul rând: etapa de segmentare, regiunile relevante
din imagine sunt evidențiate; apoi regiunile găsite (dacă există) sunt utilizate pentru
inițializarea procesului de căutare a modelului genetic. Principalele probleme atunci
când încercăm să detectăm obiecte pe care oamenii le folosesc ca repere sunt
deformarea și iluminarea perspectivei. Aspectul obiectului se schimbă în imagine cu
distanța și unghiul de vizualizare și în diferite condiții de iluminare. Modelele
deformabile sunt utilizate pentru a face față deformărilor în perspectivă, iar spațiul
de culoare – nuanță, saturație, luminozitate (HSL - Hue Saturation Lightness) și
antrenamentul bazat pe imagini reale fac față iluminării.
Mai înainte de a începe căutarea GA, trebuie inițializat corect algoritmul,
pentru a reduce timpul de convergență de obicei lung al algoritmilor evolutivi; modul
utilizat pentru a selecta regiunile de interes (ROI - Regions Of Interest) poate fi
aproape orice. Și odată ce algoritmul s-a terminat, dacă obiectul a fost găsit în
imagine, trebuie extrase din acesta câteva informații utile. Această linie de lucru duce
la o structură în trei etape pentru sistemul de detectare a obiectelor: inițializare,
căutare de obiecte și extragerea informațiilor, așa cum se arată în Fig. 5.12. Pentru
a accelera detectarea punctelor de reper, se utilizează un algoritm în trei etape. În
primul rând, sunt extrase regiunile de interes (ROI). Apoi, ROI extras este utilizat
pentru a inițializa un algoritm genetic (GA) pentru căutarea reperului prin imagine.
Fiecare element al acestui GA codifică un model deformabil. Starea fizică a unei

persoane este o măsură a potrivirii între modelul deformat pe care îl codifică și
reperul căutat. În cele din urmă, dacă se găsește un reper, simbolurile sunt extrase și
identificate cu o rețea neuronală clasică de propagare înapoi.
Fig. 5.12 Structura în trei etape a sistemului de detectare a obiectelor.
5.5 Parametrii de recunoaștere a învățării pentru obiecte noi
Pentru procesul de învățare, profesorul uman trebuie să ofere mai multe

imagini de instruire, unde obiectul sau reperul de învățat este delimitat de cutii
dreptunghiulare (aceste casete vor fi denumite casete țintă). Nu există restricții a
priori pentru setul de instruire oferit. Cu toate acestea, cu cât sunt mai largi condițiile
pe care le acoperă un set de imagini (iluminare, fundal, distorsiuni de perspectivă
etc.), cu atât cele mai bune rezultate vor obține parametrii învățați în situații reale.
Ca proces de recunoaștere, acesta poate fi împărțit secvențial în două etape:
generarea ipotezelor candidate (prin segmentarea ROI a culorii) și verificarea sau
respingerea ipotezelor (cu căutarea genetică). În consecință, procesul de învățare
pentru un nou reper este, de asemenea, împărțit în două etape. În primul pas, se
găsesc niveluri de prag pentru segmentarea HSL. Al doilea pas este dedicat
determinării locației ferestrelor tipar de corelație în interiorul unui element.
Orice metodă de segmentare a regiunilor imaginii cu probabilități bune de a
aparține obiectului selectat poate fi utilizată aici. Se pot utiliza informații despre
culoarea obiectului pentru a genera regiuni de interes. Viziunea culorilor este un
instrument puternic pentru a gestiona modificările aspectului legate de iluminare ale
obiectelor din imagine. După evaluarea diferitelor spații de culoare (RGB
normalizat, CIE (L * a * b * - Spațiul de culoare CIELAB denumit și L * a * b * este
un spațiu de culoare definit de Comisia internațională pentru iluminare în 1976.
Exprimă culoarea ca trei valori: L * pentru luminozitatea perceptivă și a * și b *
pentru cele patru culori unice ale viziunii umane: roșu, verde, albastru și galben.) și
HSL, spațiul HSL a fost selectat ca spațiu de bază al sistemului (Fig. 5.13).
Fig. 5.13 Interpretarea cilindrică a spațiului HSL.
Conform [5.33], sistemul HSL prezintă câteva proprietăți interesante:

1. Nuanța – Hue: este strâns legată de senzația de culoare umană, așa cum
specifică proprietatea de culoare „perceptuală” a pixelului considerat. Multe
obiecte au culori selectate pentru a fi ușor de distins de oameni, în special cele
potrivite pentru a transporta informații simbolice în interior. În plus, această
componentă este puternic independentă de iluminare și umbre;
2. Saturație – Saturation: indică „puritatea” sau dominația unei culori,
deoarece indică cât de multă culoare are pixelul. O altă semnificație este
cât de departe de scara de gri este pixelul, deoarece scara de gri, de la negru
la alb, are saturație egală cu zero (are aceeași cantitate din toate culorile).
Această componentă este într-un fel insensibilă la schimbările moderate de
iluminare;
3. Luminozitate – Lightness/Luminance: Luminozitatea ia în considerare
toate informațiile de iluminare ale scenei; componenta L este versiunea
alb-negru a scenei, deoarece măsoară cantitatea de lumină care a sosit.
Pe de altă parte, Hue prezintă câteva dezavantaje. În primul rând, este o
componentă unghiulară, deci valorile 0 și 256 sunt exact aceleași (continuitate
circulară); acest lucru trebuie luat în considerare la segmentarea unui interval de
culoare. În al doilea rând, Hue nu este definit pentru valori de saturație scăzute sau
nule; în aceste situații, pixelii sunt acromatici, iar Hue poate lua valori neregulate.
Prima problemă este ușor de depășit segmentarea în doi pași, dar a doua necesită un
tratament mai complex. În această lucrare, valoarea 255 pentru Hue este rezervată și
etichetată ca acromatică. Componenta Hue este redimensionată la 0-254, iar pixelii
cu saturație redusă sunt setați la valoarea acromatică. Pentru restul proceselor, atunci
când un pixel este setat ca acromatic, se folosește doar componenta L pentru acesta.
Fie ca orice imagine color HLS, de dimensiuni Xd  Yd pixeli, să fie I ( x, y ) :
I ( x, y ) = H ( x, y ) , L ( x, y ) , S ( x, y ) , x  0, Xd ) , y  0, Yd )
O modalitate simplă și eficientă de a genera un ROI dependent de obiect este
să selectați o culoare reprezentativă pentru obiect și să segmentați regiunile de
imagine care au această culoare. Pentru a gestiona variațiile de culoare intra-clasă

ale obiectelor, precum și efectele de luminanță, sistemul învață un interval de culoare
reprezentativ pentru fiecare clasă de obiecte de detectat, definit de:
CI = ( H  H , S  S , L  L)
Segmentarea culorilor se face în componente H, S și L ale imaginii I ( x, y )
separat și combinându-le cu o operație logică AND, ducând la imaginea binară
B ( x, y ) :
 ( H − H )  H ( x, y )  ( H + H )

1 AND ( L − L)  L ( x, y )  ( L + L)
B ( x, y ) = 
 AND ( S − S )  S ( x, y )  ( S + S )

0 otherwise
Segmentarea se face prin praguri într-un spațiu HLS corectat urmat de unele
transformări morfologice. În prima etapă de formare, sistemul trebuie să învețe cele mai
bune valori prag pentru segmentarea reperului. Sunt estimate pragurile superioare și
inferioare pentru componentele Hue, Saturation și Luminance. Aceste șase valori
(G = 5) sunt făcute pentru a compune genomul indivizilor unui nou GA, utilizat pentru
căutarea prin spațiul de culoare al imaginii de antrenament: C0  = H , C1 = H ,
C2  = L , C3  = L , C4  = S , C5  = S .
Funcția de antrenament pentru acest GA trebuie să încurajeze regiunile
segmentate, generate de fiecare dată, să se potrivească cu casetele țintă definite în
imaginile de antrenament NT. Fiecare imagine de antrenament I Tn ( x, y ) ,
n  0, N T ) , care va conține tn casete țintă Aj ( x, y ) , j  0, tn ) . Pe de altă parte,
n
regiunile segmentate din afara casetelor țintă nu sunt de dorit. Rezultatul ideal al
segmentării ar trebui să fie o imagine neagră binară cu zonele corespunzătoare ale
casetelor țintă în alb, BTn ( x, y ) :
BTn ( x, y ) = 1, ( x, y ) Aj , j = 0,

 n
, tn − 1
.
0, otherwise
Această „imagine ideală” poate fi asortată cu imaginea binară rezultată din
  ( )
genomul unei date C i , Bi x, y, C i calculat cu ecuația
n
B ( x, y ) cu pragurile purtate
 
în C i , utilizând o funcție logică XOR la nivel de pixel. Pixelii care supraviețuiesc
acestei operațiuni sunt clasificați greșit, deoarece au fost incluși în regiuni segmentate în
timp ce nu trebuie (sau invers). Numărul de pixeli albi după trecerea XOR este apoi o
măsură utilă a erorii de segmentare pentru imaginea de antrenament considerată.
Eroarea totală de segmentare pentru o persoană este obținută prin repetarea acestei
operații pentru toate seturile de imagini de antrenament și acumularea pixelilor clasificați
greșit în fiecare imagine:
Xd −1 Yd −1  n
( ) ( )
NT −1
1
E C  j =     BT ( x, y ) XORB x, y, C  j
n k
NT n =0  x =0 y =0
Funcția de antrenament este apoi aleasă ca funcție inversă a acestei erori

totale.
Înainte de a începe căutarea de învățare, se face o inițializare grosieră a GA
pentru scăderea timpului de căutare. Un set de valori prag inițiale H, L și S sunt
obținute din oricare dintre imaginile de antrenament folosind histograme locale.
Două seturi de histograme pentru H, L și S sunt calculate din regiunile interioare și
exterioare adiacente limitelor casetei țintă (Fig. 5.14). Histogramele interioare
conțin informații despre obiect, fundal și zgomot.
Histogramele exterioare conțin informații din fundal, alte obiecte și zgomot.
Pentru fiecare componentă, histograma exterioară este scăzută din histograma
interioară corespunzătoare, cu valori negative rezultate forțate la zero. Histograma
de diferență locală (LDH - Local Difference Histogram) rezultată va conține doar
informații aparținând obiectului dorit și care nu sunt prezente în regiunile exterioare.
Valorile de inițializare sunt luate dintr-o căutare de vârf peste LDH.
Fig. 5.14 Regiuni utilizate pentru calcularea LDH.
În acest fel sunt estimate mai multe valori pentru pragurile H, L și S și

combinațiile lor posibile generează o bună parte din populația inițială a GA. Restul
populației este generat aleatoriu. Această inițializare accelerează considerabil procesul
de instruire; timpul de antrenament este de ordinul a cinci secunde pentru fiecare imagine
de antrenament. Fig. 5.15 prezintă segmentările învățate pentru diferite obiecte.
Fig. 5.15 Exemple de segmentare învățate: (a) semn de circulație pentru stație de autobuz,
(b) panou informativ de autostradă, c) panou informativ de supermarket, pentru o cameră
color. Iar în imaginea alb-negru s-a considerat o aproximare grosieră, fără a ține cont de
nuanțele de culoare.
Etapa de învățare a intervalului de culoare face calibrarea inutilă a camerei
color, deoarece pragurile sunt selectate folosind imagini capturate de aceeași cameră.
Cu toate acestea, dacă trebuie folosită o cameră nouă cu o bază de date de obiecte
învățată cu o cameră diferită, este suficientă o ajustare grosieră a culorilor prin orice
metodă aproximativă.
Pentru a realiza timpii de procesare practici, o nouă particularizare a fost
făcută sistemului. Multe dintre obiectele de zi cu zi sunt plane, sau a treia dimensiune
a acesteia este mică în comparație cu cealaltă, iar multe dintre obiectele 3D au fețe
aproape plane care pot fi considerate ca obiecte plane separate.
Mai mult, anumite obiecte sunt întotdeauna văzute cu aceeași orientare:
obiecte atașate la pereți sau grinzi, așezate pe podea pe o masă și așa mai departe.
Având în vedere aceste restricții, este necesar să se ia în considerare doar cinci din
cele 6 DOF propus anterior: X, Y, X, Y, SkY. Această reducere a spațiului de
căutare a parametrilor modelului deformabil crește semnificativ timpul de calcul.
Această simplificare reduce aplicabilitatea sistemului la obiectele plane sau
fețele obiectelor 3D, dar aceasta nu este o pierdere de generalitate, ci doar o
operațiune de reducere a timpului: problemele legate de implementarea întregului
sistem 3D vor fi date de-a lungul acestui text. Cu toate acestea, multe obiecte
interesante pentru diferite aplicații pot fi gestionate în ciuda simplificării, în special
a tuturor tipurilor de panouri informative.
Fig. 5.16 Model planar deformabil. [5.29], Figure 1.10, pg. 17
Modelul 2D redus deformabil este prezentat în Fig. 1.10. Cei cinci parametri
ai săi sunt codați binar în genomul oricărui date GA: coordonatele carteziene ale
punctului (dată) (X, Y) în imagine, dimensiunea sa orizontală și verticală în pixeli
(X, Y) și o măsură a distorsiunii perspectivei sale verticale (SkY) , așa cum se
arată în ecuație pentru a zecea persoană, cu G = 5 DOF și q = 10 biți per variabilă
(pentru acoperirea a 640 pixeli). Variațiile acestor parametri fac ca modelul
deformabil să se deplaseze prin imaginea care caută obiectul selectat.
 
 
C j = (b11i , b12i , , b1iq ) ; (b21
i i
, b22 , i
,b
2q ) ; ; (b
i
G1
i
,b ,
G2 , b ) .
i
Gq
 
 Xi Yi SkYi 
Pentru aceste DOF, un punct ( x0 , y0 ) în cadrul de referință al modelului (fără

înclinare, de dimensiunea X 0 , Y0 ), va avea coordonate ( x, y ) în sistemul de
coordonate de imagine pentru un model deformat:
 X 
() ()
0
x =  Y  x  X
y  X  SkY X   y0  + Y .
 0 
 X 2 Y0 
 0 
Este necesară o funcție de antrenament care să compare detaliile specifice
obiectului peste modelul deformat cu fundalul imaginii. Din nou, aproape orice
metodă poate fi utilizată pentru a face acest lucru.
Au fost evaluate câteva seturi de detalii globale: funcția de distribuție a
culorilor și a culorilor, și textura medie, dar s-au dovedit incapabile să facă o potrivire
precisă și au fost excesiv atrași de zonele de imagine incorecte. Au fost apoi evaluate
câteva seturi de detalii locale: detectarea liniei verticale și detectarea colțurilor. Au
dovedit efectul opus: s-au găsit mai multe potriviri foarte precise, dar după o viteză
de convergență foarte mică: a fost dificil să se alinieze exactmodelul peste obiect, iar
antrenament-ul a fost scăzut, dacă da.
Fig. 5.17 Set de detalii specifice obiectului selectat. (a) obiect care trebuie învățat, (b)
locații posibile pentru ferestrele tipărite, (c) ferestre tipărite memorate după deformarea
modelului. [5.29], Figura 1.11, pg. 18
Setul de detalii selectat în cele din urmă este compus din patru „ferestre de
model” de dimensiuni mici, care sunt situate la anumite poziții învățate de-a lungul
diagonalelor modelului, așa cum se arată în Fig. 5.17 b.
Aceste ferestre tipar au o dimensiune cuprinsă între 10 și 20 de pixeli și sunt
memorate de sistem în timpul învățării unui obiect nou, la distanțe învățate
ai (i = 0, ,3) . Distanțele relative di de la colțurile modelului până la ferestrele
tiparului,
ai
di = ,
D
sunt memorate împreună cu ferestrele-model corespunzătoare. Aceste distanțe
relative sunt menținute constante în timpul deformărilor modelului de bază în etapa
de căutare, astfel încât poziția ferestrelor tipar urmează, așa cum se arată în
Fig. 5.17.c. Ferestrele tipar vor fi învățate de sistem în poziții cu informații locale
distincte, cum ar fi marginile interne sau externe ale obiectului.
Corelația normalizată asupra componentei L (conform ecuației următoare)
este utilizată pentru compararea ferestrelor model, M k ( x, y ) , cu fundalul imaginii,
L ( x, y ) , în pozițiile fixate de fiecare parametru individual, pentru furnizarea unui
evaluarea funcției de mișcare:
 L ( x + i, y + j ) − L   M (i, j ) − M

k k 
rk ( x, y ) = i j
;
 L ( x + i, y + j ) − L    M (i, j ) − M
2 2
k k 
i j i j
k ( x, y ) = max rk ( x, y ) , 0 .

2
Corelația normalizată face ca estimarea mișcării să fie robustă la schimbările

de iluminare și oferă mijloace de a combina gama locală și semi-globală pentru
ferestrele tipar. În primul rând, corelația este maximă exact în punctul în care o
fereastră tipar se află peste detaliul corespunzător al obiectului din imagine, după
cum este necesar pentru a realiza o aliniere precisă între model și obiect. În al doilea
rând, corelația scade în timp ce fereastra tiparului depășește poziția exactă, dar
păstrează o valoare medie într-o mică vecinătate al acesteia; acest lucru oferă un scor
de antrenament moderat pentru valorile situate în apropierea unui obiect, dar nu exact
deasupra acestuia, făcând ca GA să convergă mai repede.
În timpul evaluării antrenamentului este introdusă o mică polarizare care
accelerează convergența. Corelația normalizată pentru fiecare fereastră este evaluată
nu numai în pixelul indicat de parametrii individului, ci și într-un cartier mic (în jur
de 7 pixeli) al acestui pixel central, cu aproape același cost de timp. Scorul de
antrenament este apoi calculat și parametrii punctului sunt ușor modificați, astfel
încât modelele individuale se apropie de punctele de corelație mai mari din
vecinătatea evaluată. Această modificare este limitată la cinci pixeli, deci are un efect
redus asupra punctelor aflate mai departe de zonele interesante, dar permite
convergența finală foarte rapidă, promovând o potrivire bună la o aliniere perfectă,
în loc să aștepte o încrucișare sau o mutație pentru a face acest lucru.
( )
Funcția de antrenament F C i utilizată este apoi o funcție a normalizatului
corelației fiecărei ferestre de tipare k (C ) , (0  

i v  1) , plasată peste punctele de
vârstă stabilite de (C ) . Acesta a fost testat empiric, ducând la funcția din ecuația
i
următoare:
( ) ( ) (
3 − 0 C i 2 C i − 1 C i 3 C i ) ( )−
(
E C i = ) 3
−
( ) ( ) (
0 C i 1 C i 2 C i 3 C i ) ( )
3
(
F C i = ) 1
(
0.1 + E C i )
Termenul de eroare E din ecuațiile anterioare este o măsură a cât de diferit de
obiect este modelul deformat. Acesta include un termen global cu produsul corelației
celor patru ferestre tipar și doi termeni cu produsul corelațiilor ferestrelor tipar în
aceeași diagonală. Acești ultimi termeni forțează modelele deformate să se
potrivească cu întinderea completă a obiectului și evită să potrivească doar o parte
din acesta. Rețineți că acești termeni pot avea valori scăzute, dar nu vor fi niciodată
zero în practică, deoarece corelația nu atinge niciodată această valoare. În cele din
urmă, scorul de antrenament în ecuația anterioară este o funcție inversă mărginită a

erorii.
Fig. 5.18 Proces individual de evaluare a antrenamentului.
Întregul proces de evaluare a antrenamentului pentru un proces este ilustrat în

Fig. 5.18. În primul rând, poziția și deformarea modelului deformat (individual) sunt
stabilite de parametrii săi (Fig. 5.18.a) unde punctul alb indică punctul de referință.
Apoi, pozițiile corespunzătoare ale ferestrelor modelului sunt calculate cu
deformarea individuală și cu valorile stocate, în Fig. 5.18.b, marcate cu puncte; în
cele din urmă, corelația normalizată a ferestrelor tipar este calculată într-o vecinătate
mică a pozițiilor sale, individual este ușor părtinitor și antrenamentul este calculat cu
ultima relație.
Corelația normalizată cu modelele memorate nu poate gestiona nici o
modificare geometrică a aspectului. Deci, cum poate funcționa aici? Motivul pentru
aceasta este dimensiunea limitată a ferestrelor tipar. Ele captează doar informații
despre o zonă mică a obiectului. Modificările de aspect afectează în principal
aspectul general al obiectului, dar efectul său asupra detaliilor mici este mult redus.
Acest lucru permite utilizarea aceluiași tipar-ferestre sub o gamă largă de dimensiuni
și înclinări ale obiectelor (și unele rotații, de asemenea), fără o reducere critică a
corelației lor. În aplicația prezentată, pentru fiecare obiect este utilizat un singur set
de ferestre tipar. Extensia pentru a lua în considerare mai multe grade de libertate
(rotație 2D d 3D) se bazează pe utilizarea diferitelor seturi de ferestre tipare pentru
același obiect. Setul de utilizat în timpul corelației este decis direct de parametrii
modelului deformat considerați. Fiecare set va acoperi o anumită gamă de parametri
ai modelului. Ca o concluzie, al doilea pas de instruire se referă la localizarea celor
patru ferestre de corelație (detaliu specific obiectului) peste diagonalele modelului
deformabil, valorile adimensionale d0 , , d3 descris anterior. Un GA este utilizat
pentru a găsi aceste patru valori, care vor compune genomul fiecărei date.
Ferestrele de corelație ar trebui alese astfel încât fiecare să aibă o valoare de
corelație ridicată într-o singură locație din interiorul casetei țintă (pentru a asigura o
aliniere bună) și valori de corelație scăzute în afara acesteia (pentru a evita detectările
false).
Având în vedere acest lucru, pentru fiecare valoare posibilă a di, fereastra de
model corespunzătoare localizată aici este extrasă pentru una dintre casetele țintă.
Performanța acestei ferestre de tipar este evaluată prin definirea unei funcții cu mai
mulți termeni:
1. Un termen pozitiv cu corelația ferestrei într-un vecinătate foarte mică (3-
5 pixeli) a poziției teoretice a centrului ferestrei (dată de valoarea di
selectată peste diagonalele casetelor țintă).
2. Un termen negativ care calculează corelația maximă a ferestrei tipar în
interiorul casetei țintă, dar în afara zonei teoretice anterioare.
3. Un termen negativ cu corelația maximă în zonele aleatorii din afara
casetelor țintă.
Fig. 5.19 Funcția de evaluare a poziției ferestrei tipar.
Din nou, o inițializare grosieră a GA poate fi realizată cu ușurință pentru a

reduce timpul de antrenament. Intuitiv, pozițiile relevante în care ar trebui plasate
ferestrele de corelație sunt cele cu variații locale puternice în componentele imaginii
(H, L și / sau S). O metodă simplă este utilizată pentru a găsi locații ca acestea. Liniile
diagonale ale casetei diagonale a unei imagini de antrenament (care se vor potrivi cu
cele ale unei date teoretice) sunt scanate în vectori H, L și S. În interiorul acestor
vectori, se calculează o estimare locală a derivatei.
Apoi, pixelii având o valoare derivată locală ridicată sunt aleși pentru a calcula
valorile inițiale posibile pentru parametrii di.
Fig. 5.19 prezintă acest proces, în care graficul reprezintă estimarea derivată
pentru diagonala marcată, începând din colțul din stânga sus, în timp ce barele verticale
peste grafic indică valorile inițiale selectate di.
Această funcție oferă o măsură pentru fiecare valoare di; este evaluat de-a
lungul diagonalelor pentru fiecare casetă țintă și mediatizat prin toate casetele țintă
și imaginile de antrenament furnizate, ducând la o matrice „bună” pentru fiecare
valoare di. Datele rezultate sunt o matrice pentru fiecare diagonală. Ferestrele cu
model peste diagonală sunt luate în cele mai bune vârfuri din matrice. Exemple de
ferestre tipar selectate pentru unele obiecte sunt prezentate (mărite) în Fig. 5.19;
dimensiunea sa reală în pixeli poate fi ușor apreciată.
5.6 Structura sistemului
Căutarea modelelor se face folosind un Motorul de căutare a modelelor 2D

conceput pentru aplicații generale. Odată găsit un reper, etapa de extragere a
informațiilor aferente depinde de fiecare semn, deoarece acestea conțin diferite tipuri
și cantități de informații. Cu toate acestea, evenimentul topologic (care este generat cu
recunoașterea cu succes a unui reper) este independent de reperul selectat, cu excepția
oportunității localizării la „nivel înalt” care implică interpretarea conținutului plăcuței
de identificare a unui birou. Adică, odată găsit un reper, informațiile simbolice pe care
le-ar putea conține, cum ar fi text sau icoane, sunt extrase și interpretate cu o rețea
neuronală. Această acțiune oferă oportunitatea unei strategii de localizare și control
topologic de „nivel înalt”. Procesul complet este alcătuit din trei etape secvențiale:
inițializarea algoritmului genetic în jurul Regiunilor de Interes (Region of Interest -
ROI), căutarea obiectului și recuperarea informațiilor dacă obiectul este găsit.
Lăsând GA să exploreze spațiul parametrilor întregului model, sistemul va
deveni inutilizabil în practică, cu capacitatea de calcul disponibilă în prezent. Cel
mai bun mod de a reduce timpul de convergență este inițializarea algoritmului, astfel
încât o parte a populației inițiale să înceapă peste anumite zone ale imaginii care sunt
cumva mai interesante decât altele. Aceste zone sunt denumite frecvent ROI. Dacă
nu se utilizează ROI, atunci populația completă este inițializată aleatoriu. Aceasta nu
este o situație bună, deoarece convergența algoritmului, dacă obiectul este în
imagine, este lent, timpul variază și este atât de nepractic. Mai mult, dacă obiectul
nu este prezent în imagine, singurul mod de a fi sigur de acest lucru este să lăsați
algoritmul să ruleze prea mult timp.
Primul lucru care se face este să fie folosită rentabilitatea investiției generală.
Există zone de imagine cu prezență de margini, linii etc., care sunt plauzibile pentru
a se potrivi cu detaliile specifice ale unui obiect. Inițializarea datelor în aceste zone
crește probabilitatea de a stabili anumite date lângă obiectul dorit. Desigur, pot exista
prea multe zone în imagine care pot fi considerate de interes și nu rezolvă problema de
a decide că obiectul dorit nu este prezent în imagine. În cele din urmă, se pot utiliza
câteva caracteristici ale obiectului dorit pentru a selecta ROI în imagine: culoare,
textură, colțuri, mișcare etc. Acest lucru va avea ca rezultat un ROI redus, dar cu o
mare probabilitate de a aparține obiectului căutat. Acest lucru va accelera căutarea în
două moduri: reducerea numărului de generații până la convergență și reducerea
numărului de date necesare. Dacă o parte a grupului de date este inițializată în jurul
acestor ROI, datele apropiate de un ROI corect vor avea un scor de antrenament ridicat
și vor converge rapid pentru a se potrivi cu obiectul (dacă funcția de antrenament își
face rolul); pe de altă parte, datele inițializate în apropierea unui ROI greșit vor avea
un scor de antrenament scăzut și vor fi eliminate de procesul evolutiv, explorând noi
zone de imagine. Din punct de vedere statistic, ROI selectat folosind cunoștințe
specifice obiectului poate fi interpretat ca ipoteze de prezență a obiectului. Căutarea
GA trebuie apoi să valideze sau să respingă aceste ipoteze, prin rafinarea ajustării la
un ROI corect până când se generează o potrivire validă sau decolorându-se de la un
ROI incorect. S-a demonstrat cu rezultate practice că, dacă rentabilitatea investiției este
corect selectată, GA poate converge în câteva generații. De asemenea, dacă acest lucru
nu se întâmplă, va însemna că obiectul dorit nu a fost prezent în imagine. Acest lucru
accelerează sistemul, astfel încât să poată fi utilizat în aplicații practice.
O segmentare simplă și rapidă se face pe imaginea țintă, pentru a stabili Regiuni
de interes (ROI). Se realizează un prag în imaginea color după ecuația (3) și pragul
învățat în etapa de antrenament. Zonele zonelor în care modelul selectat are o
probabilitate relevantă de a fi găsit. Apoi, unele operații morfologice sunt efectuate în
imaginea binară pentru conectarea contururilor întrerupte. După aceea, regiunile
conectate cu geometrie adecvată sunt selectate ca ROI sau ipoteze de prezență a
obiectelor, aceste ROI pot fi considerate ca ipoteze de localizare a modelului.
Căutarea obiectelor este o căutare evolutivă în spațiul parametrilor modelului
deformabil. Un algoritm genetic (GA) este utilizat pentru a confirma sau respinge
ipotezele ROI. Genomul fiecărui individ este alcătuit din cinci gene (sau variabile):
coordonatele carteziene ale individului (x, y) în imagine, dimensiunea sa orizontală și
verticală în pixeli ( X , Y ) și o măsură a distorsiunii perspectivei sale verticale
(SkewY).
Într-un sens general, funcția de fitness poate utiliza detalii specifice obiectului
global și / sau local. Detaliile globale nu au o locație geometrică precisă în partea
laterală a obiectului, cum ar fi statistici ale nivelurilor sau culorilor de gri, texturi etc.
Detaliile locale sunt situate în anumite puncte din interiorul obiectului, de exemplu
colțuri, patch-uri de culoare sau textură etc. Utilizarea detaliilor globale nu are
nevoie de o aliniere perfectă între modelul deformabil și obiect pentru a obține un
scor mare, în timp ce utilizarea detaliilor locale. Detaliile globale permit convergența
cea mai rapidă, dar detaliile locale permit una mai precisă. Un compromis între
ambele tipuri de detalii va conduce la cel mai bun detaliu.
Estimarea rezultatelor funcției de antrenament, folosește rezultatele corelației
normalizate (pe componenta de luminanță a imaginii țintă). Corelația pentru fiecare
fereastră i este calculată numai într-un areal foarte mic (aproximativ 7 pixeli) al
pixelului din imaginea țintă care se potrivește cu poziția centrală a ferestrei tipar, în
scop de calcul în timp real. Utilizarea a patru mici ferestre de tipar are avantaje
enorme față de utilizarea clasică a unei imagini de tipar mare pentru corelație. Poziția
relativă a ferestrelor tipar în interiorul imaginii poate fi modificată în timpul
procesului de căutare. Această idee este baza algoritmului propus, deoarece face
posibilă găsirea unor repere cu dimensiuni aparente foarte diferite și deformări de
perspectivă în imagine. Mai mult, ferestrele tipar pentru un reper nu trebuie rotite
sau scalate înainte de corelare (presupunând că sunt prezente doar transformări de
perspectivă), datorită dimensiunilor lor mici. În cele din urmă, timpul de calcul
pentru o căutare este mult mai mic pentru corelația celor patru tipare de ferestre decât
pentru corelația unui tipar mare.
Implementarea descrisă a sistemului de detectare a obiectelor va găsi
întotdeauna obiectul dacă este prezent în imagine sub limitele descrise anterior.
Întrebarea critică care trebuie folosită practic este timpul pe care îl alocă. Dacă
sistemul este utilizat numai cu inițializare aleatorie, un număr mare de date (imagini)
trebuie incluse în prupul de testare pentru a asigura explorarea întregii imagini într-
un timp finit. Evaluarea funcției de antrenament selectate și polarizarea individuală
accelerează convergența odată ce o imagine se apropie suficient de mult de obiect,
dar pot fi necesare câteva zecimi și poate câteva sute de iterații. Desigur, există
întotdeauna posibilitatea ca o mutație norocoasă să facă treaba rapid, dar acest lucru
nu ar trebui luat în considerare. În plus, nu există nicio modalitate de a declara că
obiectul selectat nu este prezent în imagine, cu excepția lăsării algoritmului să ruleze
mult timp fără nici un rezultat. Această metodologie ar trebui utilizată numai dacă
este sigur că obiectul este prezent în imagine și nu există restricții de timp pentru
căutare.
Când se utilizează ROI, mai multe imagini sunt concentratei în zone
interesante, astfel încât populația poate fi redusă la un număr mai mic de date și
convergența ar trebui să dureze doar câteva zeci de iterații, deoarece probabilitatea
de a avea unele modele deformate lângă obiect este mare. Cel puțin, ar trebui utilizat
acest mod de lucru, în locul celui anterior. Cu toate acestea, există o mulțime de
indivizi și iterații de rulat, iar timpii de căutare pe un computer sunt încă de ordinul
a câteva minute, în imagini de 640x480 pixeli. Acest lucru restricționează puternic
aplicațiile algoritmului. Și există și problema asigurării absenței obiectului în
imagine.
În cele din urmă, dacă sistemul cu ROI specific obiectului, de exemplu cu
strategia reprezentativă de segmentare a culorii descrisă, lucrurile se schimbă drastic.
Într-un caz real general, ar trebui să existe doar câteva ROI; cele excesiv de mici sunt
respinse deoarece vor fi introduce zgomot sau obiecte situate prea departe pentru a
avea suficientă rezoluție pentru identificarea acestuia. Din aceste ROI, unele ar putea
aparține obiectului căutat (pot exista diferite instanțe ale obiectului în imagine), iar
restul nu. Mai multe obiecte, aproximativ unul sau câteva zeci, sunt inițializate
împrăștiate în jurul ROI selectat, până ajung la 2/3 din populația totală. Restul
populației este inițializată aleatoriu pentru a asigura o diversitate genetică suficientă
pentru operațiunile de încrucișare. Dacă un ROI face parte într-adevăr din obiectul
dorit, imaginile apropiate acestuia vor rafina rapid potrivirea, în timpul evaluării
antrenamentului. Asta înseamnă un ciclu rapid cu foarte puține iterații, de obicei două
sau trei. Dacă rentabilitatea investiției nu face parte din obiect, scorul de antrenament
pentru datele din jurul ROI va fi scăzut, iar derivata genetică îi va muta pe descendenți.
Strategia de aici este de a utiliza doar datele necesare pentru a confirma sau respinge
rentabilitatea investiției prezentă în imagine (plus unele aleatorii în plus); cu numărul
obișnuit de rentabilitate a investiției, este suficientă aproximativ o sută de date. Apoi,
GA funcționează pentru câteva iterații. Dacă obiectul era prezent în imagine, în două
sau trei iterații va fi montat de niște modele deformate. Dacă după cele câteva iterații
nu s-a confirmat nici un ROI, se consideră că obiectul nu este prezent în imagine. Mai
mult, dacă nu s-a găsit ROI pentru etapa de inițializare, probabilitățile ca un obiect să
fie în imagine sunt foarte scăzute (dacă segmentarea a fost învățată corect), iar procesul
de căutare se oprește aici. Timpii de procesare tipici sunt mici (sutimi de secunde) dacă
nu se găsește ROI și mai mic pe iterație dacă există ROI în imagine. Deci, timpul total
pentru un ciclu este mic (sutimie de secunde) și mai puțin pentru a declara că nu există
dacă nu a fost prezent ROI. De reținut că toate procesările sunt realizate prin mijloace
software, programate (C++, Open CV), și nu au fost realizate optimizări în
programarea GA - doar tehnica de polarizare este non-standard -. În aceste condiții,
mutația are o probabilitate foarte mică de a-și asuma un rol relevant, astfel încât
calculul ei ar putea fi evitat. Mutația este esențială numai dacă căutarea este extinsă la
mai multe iterații atunci când obiectul nu este găsit, dacă restricțiile de timp permit
acest lucru.
Dacă obiectul dorit a fost găsit în imagine, vor fi necesare câteva informații
despre acesta. Pentru navigația topologică, adesea singura informație necesară de la
un reper este prezența sau absența sa în mediul imediat al robotului. Cu toate acestea,
pot fi necesare mai multe informații pentru alte strategii de navigație, indiferent de
natura lor topologică sau geometrică. Pentru aplicații generale, sunt extrase locația
obiectului, poziția obiectului, distanța, dimensiunea și distorsiunea în perspectivă a
fiecărui reper. Unele obiecte sunt frecvent utilizate pentru a conține informații
simbolice folosite de oameni. Acesta este cazul semnelor de circulație, panourilor
informative pe drumuri și străzi, semnelor clădirilor interioare, etichetelor și
codurilor de bare etc. Toate acestea au fost învățate și pot fi detectate de sistem,
printre altele. Mai mult, dacă reperul găsit este plăcuța de identificare a unui birou,
următorul pas este citirea conținutului acestuia. Această abilitate este utilizată pe
scară largă de oameni, iar alte abordări de cercetare au fost făcute recent în acest sens
[5.34]. În lucrarea noastră, un algoritm simplu de recunoaștere optică a caracterelor
(OCR) a fost conceput pentru sarcina de citire, discutat pe scurt mai jos.
Sistemul prezentat include o rutină de extragere a simbolurilor pentru
segmentarea caracterelor și a icoanelor prezente în obiectele detectate. Această rutină
este analizată în detectarea fundalului simbolurilor prin analiza histogramei.
Simbolurile sunt extrase mai întâi segmentând regiunea de fundal pentru ele
(selectând ca fundal cea mai mare regiune din obiectul Histograma luminanței), apoi
luând regiunile conectate în interiorul fundalului ca simboluri
Odată ce fundalul este extras și segmentat, găurile din interiorul acestuia sunt
considerate simboluri candidate. Fiecare dintre aceste pete sunt analizate pentru a se
asigura că au dimensiunea potrivită: petele relativ mari (de obicei înseamnă unele
caractere îmbinate în procesul de segmentare) sunt împărțite recursiv în două caractere
noi și pete relativ mici (fragmente de caractere rupte în segmentare (sau semnele de
punctuație) sunt îmbinate cu unul dintre vecinele lor. Apoi, aceste caractere pete sunt
grupate în linii de text și fiecare linie de text este împărțită în cuvinte (fiecare cuvânt
este apoi un grup de unul sau mai multe caractere pete). Simbolurile segmentate sunt
normalizate la imagini binare de 24x24 pixeli și se alimentează către un strat de intrare
a rețelei neuronale de propagare înapoi. Deformările mici ale simbolurilor sunt tratate
de clasificator; deformările mai mari sunt corectate utilizând parametrii de deformare

ai modelului potrivit. Se folosește un singur strat ascuns și o ieșire pentru fiecare
simbol învățat, deci o recunoaștere bună a simbolurilor ar trebui să aibă o singură ieșire
mare. Pentru a evita o dimensiune enormă a rețelei, au fost instruiți seturi separate de
greutăți ale rețelei pentru trei grupuri diferite de simboluri: majuscule, litere mici și
cifre și icoane precum ieșiri de urgență, scări, lifturi, materiale de stingere a incendiilor
etc. seturile sunt încercate secvențial până când se găsește o clasificare bună sau este
respinsă. Ieșirea finală este un șir de caractere care identifică fiecare simbol clasificat;
caracterul ‘?’ este rezervat pentru plasarea în șir a unui simbol nerecunoscut. Procesul
mediu de extragere și citire a simbolului durează aproximativ 0,1 secunde pe simbol,
din nou prin procesarea completă a software-ului. Această rețea de backpropagation s-
a dovedit a avea un raport foarte bun între capacitatea de recunoaștere și viteză în
comparație cu rețelele neuronale mai complexe. De asemenea, s-a dovedit a fi mai
robust decât clasificatoarele convenționale (se face doar normalizarea mărimii
tiparelor de caractere, rețeaua neuronală gestionează posibila rotație și înclinare).
Această rețea este instruită offline folosind algoritmul de propagare rapidă.
Abilitatea de învățare face ca orice sistem să fie flexibil, deoarece este ușor de
adaptat la situații noi și robust (dacă instruirea este alcătuită cu atenție), deoarece
instruirea trebuie să evalueze și să verifice progresul acestuia. În lucrarea prezentată,
obiecte noi pot fi învățate în mod autonom de către sistem, așa cum s-a descris
anterior. Învățarea unui nou obiect constă în extragerea tuturor informațiilor necesare
dependente de obiect utilizate de sistem. Nucleul sistemului, algoritmul de căutare
deformabil bazat pe model cu GA, este independent de obiect. Toate cunoștințele
dependente de obiect sunt localizate în trei puncte:
1. Caracteristicile obiectelor utilizate pentru extragerea ROI (generarea
ipotezelor).
2. Detalii specifice obiectului pentru a fi adăugate la modelul de bază
deformabil.
3. Informații simbolice specifice obiectului (dacă sunt prezente)
Deși instruirea on-line este de dorit pentru capacitatea sa de integrare și
actualizare continuă, adesea o formare off-line, supravegheată și controlată duce la
cele mai bune rezultate; în plus, instruirea online poate face sistemul prea lent pentru
a fi practic. În sistemul propus, instruirea off-line a fost utilizată pentru a evita timpul
suplimentar de calcul în timpul detecțiilor. Învățarea informațiilor simbolice se face
prin propagare înapoi în clasificatorul neuronal.
5.1. Cristopher M. Bishop, Pattern Recognition and Machine Learning, Springer,

ISBN-10: 0-387-31073-8, 2006.
5.2. Sutton, R. S. and A. G. Barto (1998). Reinforcement Learning: An
Introduction. MIT Press.
5.3. Tesauro, G. (1994). TD-Gammon, a self-teaching backgammon program,
achieves master-level play. Neural Computation 6(2), 215–219.
5.4. Hastie, T. and W. Stuetzle (1989). Principal curves. Journal of the American
Statistical Association 84(106), 502–516.
5.5. Hoerl, A. E. and R. Kennard (1970). Ridge regression: biased estimation for
nonorthogonal problems. Technometrics 12, 55–67.
5.6. Liu, Y.; Yamamura, T.; Ohnishi, N.; Surgie, N., (1998) “Characterbased
mobile robot navigation”. 1998 IEEE International Conference on Intelligent
Vehicles, pp. 563-568.
5.7. Borenstein, J. and Feng. L., (1996) "Measurement and correction of systematic
odometry errors in mobile robots". IEEE Journal of Robotics and Automation,
vol. 12, no. 6, pp. 869-880.
5.8. Rue H. and Husby O.K. (1998) “Identification of partly destroyed objects using
deformable templates”. Statistics and Computing, vol.8, nº 3, pp.221-228.
5.9. Sim, R., Dudek, G., “Mobile robot localization from learned landmarks”.
International Conference on Intelligent Robots and Systems, vol. 2. pp. 1060-
1065.
5.10. Iida, M., Sugisaka, M., Shibata, K., (2002) “Application of direct vision based
reinforcement learning to a real mobile robot”. International Conference on
Neural Information Processing, vol. 5 pp. 2556- 2560.
5.11. Thompson, S., Zelinsky, A., (2002) “Accurate local positioning using visual
landmarks from a panoramic sensor”. IEEE International Conference on
Robotics and Automation, pp. 2656-2661.
5.12. Franz, Matthias O. (1998) “Learning view graphs for robot navigation”.
Autonomous robots, vol.5, pp. 111-125.
5.13. Sim, R., Dudek, G., “Mobile robot localization from learned landmarks”.
International Conference on Intelligent Robots and Systems, vol. 2. pp. 1060-
1065.
5.14. Beccari, G.; Caselli, S.; Zanichelli, F. (1998) "Qualitative spatial
representations from task-oriented perception and exploratory behaviors".
Robotics and Autonomous Systems, vol. 25, pp. 165-175.
5.15. Launay, F., Ohya, A., Yuta, S. (2002) “A corridors lights based navigation
system including path definition using topologically corrected map for indoor
mobile robots”. IEEE International Conference on Robotics and Automation,
pp. 3918-3923.
5.16. Cootes, T.F., Taylor, C.J., Lanitis, A., Cooper, D.H., Graham, J. (1993)
“Building and using flexible models incorporating gray level information”.
International Conference on Computer Vision, pp.242- 246.
5.17. Yuille, A., Halliman, P., Cohen, D., (1992) “Feature extraction from faces
using deformable models”, International Journal of Computer Vision, vol.8,
no. 2, pp.99-111.
5.18. Betke, M., Makris, N., (2001) “Recognition, resolution, and complexity of
objects subject to affine transformations”, International Journal of Computer
Vision, vol.44, no. 1, pp. 5-40.
5.19. Yu, Z., Jain, A.K., (2000) “Object localization using color, texture and shape”,
Pattern Recognition, vol.33, no. 4, pp. 671-84..
5.20. Kervrann, C., Heitz, F., (1999) “Statistical deformable model-based

segmentation of image motion”, IEEE Transactions on Image Processing,
vol.8, no. 4, pp.583-8.
5.21. Escalera A. de la, Armingol J. M. and Mata M. (2003) “Traffic sign recognition
and analysis for intelligent vehicles”, Image and Vision Computing, vol. 21,
pp. 247-258.
5.22. Yung, N., Lai, A., (1998) “Detection of vehicle occlusion using a generalized
deformable model”. IEEE International Symposium on Circuits and Systems,
vol. 4, pp. 154-157.
5.23. Kreucher C., Lakshmanan S. (1999) “LANA: a lane extraction algorithm that
uses frequency domain features”, IEEE Transactions on Robotics and
Automation, vol.15, no. 2, pp.343-50.
5.24. Lijun Y., Basu A. (1999) “Integrating active face tracking with model based
coding”, Pattern Recognition Letters, vol.20, no. 6, pp.651-7.
5.25. Tsang, C.K., Fu-Lai Chung., (1998) “Development of a structural deformable
model for handwriting recognition “. 14th Conference on Pattern Recognition,
vol. 2 pp. 1130-1133.
5.26. Poupon F., Mangin J. F., Hasboun D., Poupon C., Magnin I., Frouin V.
(1998)“Multi-object deformable templates dedicated to the segmentation of
brain deep structures”, Medical Image Computing and Computer Assisted
Intervention, First International Conference, pp.1134- 43.
5.27. Liu, L., Sclaroff, S., (2001) “Medical image segmentation and retrieval via
deformable models”. International Conference on Image Processing, vol. 3,
pp. 1071-1074.
5.28. Dubuisson M.P., Lakshmanan S., and Jain A.K. (1996) “Vehicle segmentation
and classification using deformable templates”, IEEE Transaction on Pattern
Analysis and Machine Intelligence, vol.18, no. 3, pp.293-308.
5.29. Bruno Apolloni, Ashish Ghosh, Ferda Alpaslan, Lakhmi C. Jain, Machine
Learning and Robot Perception, Publishing Srikanta Patnaik, Studies in
Computational Intelligence, Volume 7, ISBN 3-540-26549-X, 2005.
5.30. Kubota, N., Hashimoto, S., Kojima, F. (2001) “Genetic programming for life-
time learning of a mobile robot”. IFSA World Congress and 20th NAFIPS
International Conference, vol. 4, pp. 2422-2427.
5.31. Walker, M., Messom, C.H., (2002) “A comparison of genetic programming
and genetic algorithms for auto-tuning mobile robot motion control”. IEEE
International Workshop on Electronic Design, pp. 507- 509.
5.32. Rosenfeld A., (2000) “Image analysis and computer vision 1999 [survey]”.
Computer Vision and Image Understanding, vol. 78 no. 2, pp 222-302.
5.33. Perez, F.; Koch, C. (1994) “Toward color image segmentation in analog VLSI:
algorithm and hardware”. International Journal of Computer Vision, vol. 12,
no. 1 pp. 17-42.
5.34. Tomono M., Yuta, S. (2000) “Mobile robot navigation in indoor environments
using object and character recognition”. IEEE International Conference on
Robotics and Automation, pp. 313-320.
ROI
Region Of Interest
OCROptical Character Recognition
RMSRoot-Mean-Square
NMRNuclear Magnetic Resonance
GA
Genetic Algorithm
HSL
Hue, Saturation, Lightness
RGBRed Green, Blue
CIELAB International Commission Illumination L-lightness, a* și b*
pentru cele patru culori unice ale viziunii umane: roșu, verde,
albastru și galben
LDH Local Difference Histogram
6. DEEP LEARNING –
ÎNVĂȚAREA PROFUNDĂ
Rețelele neuronale sunt una dintre cele mai frumoase paradigme de

programare inventate vreodată. În abordarea convențională a programării, îi spunem
computerului ce trebuie să facă, împărțind problemele mari în multe sarcini mici,
definite cu precizie, pe care acesta le poate îndeplini cu ușurință. În schimb, într-o
rețea neuronală nu spunem computerului cum să ne rezolve problema, ci, învață din
datele ˮobservateˮ, găsind propria soluție la problema în cauză.
Fig. 6.1 Artificial Intelligence vs Machine Learning vs Deep Learning.

https://medium.com/@alanb_73111/artificial-intelligence-vs-machine-
learning-vs-deep-learning-ai-vs-ml-vs-dl-e6afb7177436
Învățarea automată (Deep Learning) dintr-un volum mare de date sună

promițător. Cu toate acestea, până în 2010 nu am știut cum să pregătim rețelele
neuronale pentru a depăși abordările mai tradiționale, cu excepția câtorva probleme
specializate. Ceea ce s-a schimbat în 2010 a fost descoperirea tehnicilor de învățare
în așa-numitele rețele neuronale profunde. Aceste tehnici sunt acum cunoscute sub
numele de învățare profundă. Au fost dezvoltate în continuare, iar astăzi rețelele
neuronale profunde și învățarea profundă realizează performanțe remarcabile în
multe probleme importante din viziunea pe computer, recunoașterea vorbirii și
procesarea limbajului natural. Acestea sunt dezvoltate pe scară largă de companii
precum Google, Microsoft, Amazon etc.
6.1 Introducere
Învățarea profundă este știința formării unor rețele neuronale artificiale mari.
Rețelele neuronale profunde (Deep Neural Networks - DNN) pot avea sute de
milioane de parametri [5,6.2], permițându-le să modeleze funcții complexe, cum ar
fi dinamica neliniară. Ele formează reprezentări compacte ale stării din datele brute,
de înaltă dimensiune, ale senzorilor multimodali care se găsesc în mod obișnuit în
sistemele robotizate [6.3] și, spre deosebire de multe metode de învățare automată,
nu necesită un expert uman care să proiecteze manual vectori de caracteristici din
datele senzorilor la proiectare. timp.
DNN-urile pot, totuși, să prezinte provocări deosebite în sistemele robotizate
fizice, unde generarea de date de antrenament este, în general, costisitoare, iar
performanța sub-optimă în antrenament reprezintă un pericol în unele aplicații. Cu
toate acestea, în ciuda unor astfel de provocări ale roboticii, se găsesc alternative
creative, cum ar fi utilizarea datelor de instruire prin manipulare digitală,
automatizarea antrenamentului și utilizarea mai multor DNN-uri pentru a îmbunătăți
performanța și a reduce timpul de formare.
Aplicarea învățării profunde la robotică este un domeniu activ de cercetare.
Ideea utilizării învățării automate în controlul roboților cere oamenilor să fie
dispuși să renunțe la un anumit control. Acest lucru poate părea contraintuitiv la
început, dar beneficiul pentru acest lucru este că sistemul poate începe apoi să învețe
singur. Acest lucru face ca sistemul să se poată adapta și, prin urmare, are potențialul
de a utiliza în cele din urmă direcția care vine de la oameni.
DNN-urile sunt potrivite pentru utilizarea cu roboți, deoarece sunt flexibile și
pot fi utilizate în structuri pe care alte modele de învățare automată nu le pot suporta.
Fig. 6.2 prezintă patru structuri comune pentru utilizarea DNN-urilor cu roboți.
Fig. 6.2 Diagrama unor structuri comune pentru utilizarea

rețelelor neuronale cu roboți.
A: Modelele de aproximare a funcțiilor sunt instruite pentru a aproxima mapările
reprezentate într-un set de formare de exemple de perechi.
B: Autocodificatorii pot reduce observațiile complexe sau ridicate la o simplă
reprezentare a caracteristicilor, extragând adesea informații intrinseci din imagini.
276 6 – Deep Learning – Învățarea Profundă
C: Modelele recurente sunt specializate în dinamică și temporală predicții.

D: Modelele de politici instruite cu învățarea de consolidare caută să planifice cele
mai bune decizii de luat în posibile condiții viitoare.
Structura A prezintă un DNN pentru regresarea funcțiilor arbitrare. De obicei,

este antrenat prin prezentarea unei colecții mari de exemple de perechi de
 
antrenament: x1 , y1 , x2 , y2 , , xn , yn . O metodă de optimizare este aplicată
pentru a minimiza pierderea de predicție.
Pentru problemele de regresie, pierderea se măsoară în mod obișnuit cu o
n
 (y − yˆ i ) , iar pentru problemele de clasificare este

2
eroare cu suma pătrată, i
i =1
n
adesea măsurată cu cross entropie −  y log yˆ , în special atunci când este utilizat
i =1
i i
un strat softmax (rezultat al aplicării unei regresii logistice multiclasă) pentru stratul
de ieșire al rețelei neuronale [6.4]. În mod tradițional, cea mai populară metodă de
optimizare pentru rețelele neuronale este descendența stocastică de gradient [6.5],
dar metodele îmbunătățite precum RMSProp [6.6] și Adam [6.7] au obținut recent o
utilizare pe scară largă. După ce antrenamentul este terminat, noii vectori pot fi
alimentați ca x pentru a calcula predicțiile corespunzătoare pentru y.
Structura B se numește autoencoder [6.8].
Este un model comun pentru facilitarea „învățării nesupravegheate”, fiind
nevoie de două DNN, numite „codificator” și „decodificator”. În această
configurație, numai x trebuie furnizat de utilizator, iar s este o codificare „latentă”
sau internă generată de DNN. De exemplu, x poate reprezenta imagini observate de
camera unui robot, care conțin mii sau chiar milioane de valori.
Codificatorul ar putea utiliza straturi convoluționale, despre care se știe că sunt
eficiente pentru codarea hash a imaginilor [6.9-6.11].
Învățând să reducă x la s, codificatorul automat își creează în esență propria
codificare internă a „stării”. Nu va folosi neapărat o codificare care are sens pentru
oameni, dar va fi suficient ca DNN să reconstruiască aproximativ x. Cum sunt utile
codificatoarele automate în robotică? Uneori, este posibil ca proiectantul robotului
să nu știe exact ce valori sunt necesare robotului. Autocodificatorii permit sistemului
să descopere acest lucru în mod autonom. Acest lucru devine deosebit de util atunci
când este utilizat un hibrid de învățare supravegheată și nesupravegheată. De
exemplu, utilizatorul poate impune anumite valori în s (coordonate de poziție
unghiuri articulare) și DNN-urile vor învăța să lucreze cu acele valori, folosind
celelalte elemente libere din s în scopuri proprii de codificare.
Autocodificatorii pot fi folosiți și pentru inițializarea unor părți ale structurii
C [6.12] și utilizează doar porțiunea de decodare a modelului pentru a prezice
observațiile dintr-o reprezentare internă a stării.
Structura C este un tip de „rețea neuronală recurentă”.

Ea este concepută pentru a modela sisteme dinamice, inclusiv roboți. Este
adesea instruit cu o abordare numită „propagarea înapoi în timp” [6.13,6.14]. Multe
progrese, cum ar fi „unitățile de memorie pe termen scurt”, au făcut rețelele neuronale
recurente mult mai puternice [6.15,6.16]. În această configurație, u reprezintă un
semnal de control, u poate conține și observații recente, iar s este o reprezentare internă
a stării viitoare și x este un vector al observațiilor viitoare anticipate. Funcția de
tranziție aproximează modul în care semnalul de control va afecta starea în timp. La
fel ca în cazul codificatorilor, reprezentarea stării poate fi complet latentă sau parțial
impusă de utilizator (dacă ar fi impus în totalitate, modelul ar fi împiedicat să învețe).
Dacă x include o estimare a utilității stării s, atunci această configurație este utilizată
în „învățarea profundă bazată pe model” [6.17].
Structura D învață o politică de control.
Poate facilita învățarea profundă „fără model”. Folosește un DNN pentru a
evalua utilitatea sau calitatea q a vectorilor potențiali de control. s este o reprezentare
a stării și u este un vector de control (metodele de gradient pot găsi valorile pentru u
care maximizează q). În cazurile cu vectori de control discreți, u poate fi omis din
intrare și q mărit pentru a conține o evaluare a fiecărui vector de control.
Configurații de genul acesta sunt folosite atunci când este cunoscută o sarcină
obiectivă pentru robot, dar utilizatorul nu știe exact cum să o realizeze.
Recompensând robotul pentru îndeplinirea sarcinii, acesta poate fi instruit să învețe
cum să-și prioritizeze propriile alegeri pentru acțiuni. Ca un exemplu important,
învățarea profundă a fost folosită pentru a învăța o mașină să joace o gamă largă de
jocuri video Atari [6.18].
6.2 Straturi convoluționale
Fiecare dintre diferitele tipuri de modele de învățare profundă sunt realizate

prin stivuirea mai multor straturi de modele de regresie. În cadrul acestor modele,
diferite tipuri de straturi au evoluat în diverse scopuri. Un tip de strat care justifică o
mențiune specială este dat de straturile convoluționale [6.19]. Spre deosebire de
straturile tradiționale complet conectate, straturile convoluționale utilizează aceleași
greutăți pentru a opera pe tot spațiul de intrare. Acest lucru reduce semnificativ
numărul total de greutăți din rețeaua neuronală, ceea ce este deosebit de important
cu imaginile care au de obicei sute de mii până la milioane de pixeli care trebuie
procesate.
Prelucrarea unor astfel de imagini cu straturi complet conectate ar necesita
mai mult de (100K)2 până la (1M)2 greutăți (filtre) care conectează fiecare strat, ceea
ce ar fi complet impracticabil.
Straturile convoluționale au fost inspirate de neuroni corticali din cortexul
vizual, care răspund doar stimulilor cu câmp receptiv. Deoarece convoluția se
apropie de acest comportament, se poate aștepta ca straturile convoluționale să
exceleze în sarcinile de procesare a imaginilor.
Lucrările de pionierat în rețelele neuronale cu straturi convoluționale (CNN) au

aplicat sarcinii de recunoaștere a imaginii [6.19, 6.20]. Multe eforturi ulterioare s-au
bazat pe acestea, dar interesul pe scară largă pentru straturile convoluționale a crescut
în jurul anului 2012, când Krizhevsky le-a folosit pentru a domina în competiția de
recunoaștere a imaginii ImageNet [6.21] și au reușit să obțină recunoașterea super-
umană pe alte repere notabile de recunoaștere a imaginii și concursuri [6.22-6.24]. A
urmat rapid o mulțime de cercetări, încercând să stabilească modele mai profunde cu
capacități îmbunătățite de procesare a imaginilor [6.25,6.26].
Acum, CNN-urile au devenit bine stabilite ca un model de învățare profundă
extrem de eficient pentru o diversitate de aplicații bazate pe imagini. Aceste aplicații
includ segmentarea semantică a imaginii [6.27], localizarea obiectelor în cadrul
imaginilor [6.28], mărirea imaginilor cu super rezoluție [6.29], recunoașterea facială
[6.30, 6.31], recunoașterea scenei de mediu [6.32] și recunoașterea gestului uman
[6.33]. Imaginile nu sunt singurul tip de semnal pentru care CNN excelează.
Capacitățile lor sunt, de asemenea, eficiente cu orice tip de semnal care
prezintă proximitate spațio-temporală, cum ar fi recunoașterea vorbirii [6.34] și
sinteza vorbirii și audio [6.35].
Bineînțeles, au început să domine și în domeniile de procesare a semnalului
utilizate în mare măsură în robotică, cum ar fi detectarea pietonilor folosind
semnăturile LIDAR [6.36] și micro-Doppler [6.37] și estimarea hărții de adâncime
[6.38]. Lucrările recente încep chiar să combine semnale din mai multe modalități și
să le combine pentru recunoaștere și înțelegere unificate [6.39].
6.3 Traiectorie la nivel înalt de învățare profundă

pentru robotică
În cele din urmă, filozofia de bază care predomină în comunitatea de învățare

profundă este că fiecare parte a unui sistem complex poate fi făcută să „învețe”.
Astfel, puterea reală a învățării profunde nu provine din utilizarea doar a uneia dintre
structurile descrise în secțiunea anterioară ca o componentă a unui sistem de
robotică, ci în conectarea părților tuturor acestor structuri împreună pentru a forma
un sistem complet.
Aici începe „profunzimea” învățării profunde să-și facă impactul - când
fiecare parte a unui sistem este capabilă să învețe, sistemul în ansamblu se poate
adapta în moduri sofisticate.
Neurologii încep chiar să recunoască faptul că multe dintre tiparele care
evoluează în comunitatea de învățare profundă și în întreaga inteligență artificială
încep să oglindească unele dintre cele care au evoluat anterior în creier [6.40,6.41].
Doya a identificat că metodele de învățare supravegheate (Structurile A și C)
reflectă funcția cerebelului, metodele nesupravegheate (Structura B) învață într-un
mod comparabil cu cel al cortexului cerebral, iar învățarea profundă este similară cu
ganglionii bazali [6.42].
Astfel, traiectoria actuală a progresului sugerează cu tărie că controlul
roboților conduce către arhitecturi cognitive complete care împart sarcinile de
coordonare într-un mod din ce în ce mai analog cu creierul [6.43-6.45].
6.4 Deep Learning / Învățarea profundă în robotică
Comunitatea robotică a identificat numeroase obiective pentru robotică în

următorii 5÷20 de ani. Acestea includ, dar cu siguranță nu se limitează la mersul și
alergarea de tip uman, predarea prin demonstrație, navigarea mobilă în medii
pietonale, automatizarea colaborativă, alegerea automată a coșurilor / rafturilor,
recuperarea automată a luptei și inspecția și întreținerea automată a aeronavelor
[6.46-6.50].
Această lucrare identifică șapte provocări generale pentru robotică, care sunt
esențiale pentru atingerea acestor obiective și pentru care tehnologia DNN are un
potențial ridicat de impact:
Provocarea 1: Învățarea dinamicii complexe, de înaltă dimensiune și obiecte
noi. Derivarea analitică a dinamicii complexe necesită experți umani, consumă mult
timp și prezintă un compromis între dimensionalitatea stării și trasabilitatea. Este
dificil să faceți astfel de modele robuste până la incertitudine, iar informațiile despre
starea completă sunt adesea necunoscute. Sisteme care se pot adapta rapid și
autonom la dinamica nouă sunt necesare pentru a rezolva probleme precum apucarea
de obiecte noi, deplasarea pe suprafețe cu proprietăți necunoscute sau incerte,
gestionarea interacțiunilor dintre un nou instrument și / sau mediu sau adaptarea la
degradarea și / sau eșecul subsistemelor robotului. De asemenea, sunt necesare
metode pentru a realiza acest lucru pentru sistemele care posedă sute (sau chiar mii)
de grade de libertate, prezintă niveluri ridicate de incertitudine și pentru care sunt
disponibile doar informații de stare parțiale.
Provocarea 2: Politici de control al învățării în medii dinamice. Ca și în cazul
dinamicii, sunt necesare sisteme de control care să permită un grad ridicat de libertate
pentru aplicații precum manipulatoare mobile cu mai multe brațe, mâini
antropomorfe și robotica roiului. Astfel de sisteme vor fi chemate să funcționeze
fiabil și în condiții de siguranță în medii cu incertitudine ridicată și informații de
stare limitate.
Provocarea 3: Manipularea avansată. În ciuda progreselor realizate de-a
lungul a 3 decenii de cercetare activă, rămân soluții robuste și generale pentru sarcini
precum apucarea geometriilor deformabile și / sau complexe, folosirea sculelor și
sistemele de acționare din mediu (rotiți un mâner al supapei, deschideți o ușă și așa
mai departe) evaziv - mai ales în situații noi. Această provocare include planificarea
cinematică, cinetică și înțelegere inerentă unor sarcini precum acestea.
Provocarea 4: recunoașterea avansată a obiectelor. DNN-urile s-au dovedit
deja a fi foarte abile în recunoașterea și clasificarea obiectelor. Exemple de aplicații
avansate includ recunoașterea obiectelor deformabile și estimarea stării și poziției
acestora pentru apucare, sarcini semantice și specificații de cale (de exemplu,
înconjurați masa, sau la mașină deschideți portbagajul) și recunoașterea
proprietăților obiectelor și suprafețelor obiectelor care ar putea reprezenta un pericol
pentru colaboratorii umani sau podele umede / alunecoase.
Provocarea 5: Interpretarea și anticiparea acțiunilor umane. Această
provocare este esențială dacă roboții trebuie să lucreze cu sau printre oameni în
aplicații precum robotica colaborativă pentru producție, îngrijirea persoanelor în

vârstă, vehicule autonome care operează pe căile publice sau navigarea în medii
pietonale. Mai mult, va permite predarea prin demonstrație, care la rândul său va
facilita specificarea sarcinilor de către indivizi fără expertiză în robotică sau
programare. Provocarea poate fi extinsă și la perceperea nevoilor umane și
anticipând când intervenția robotică este adecvată.
Provocarea 6: Fuziunea senzorilor și reducerea dimensionalității.
Proliferarea tehnologiilor de detectare low-cost a fost un avantaj pentru robotică,
oferind o mulțime de date potențial bogate, de înaltă dimensiune și multimodale.
Această provocare se referă la metode pentru a construi reprezentări de stare
semnificative și utile din astfel de date.
Provocarea 7: Planificarea sarcinilor la nivel înalt. Roboții vor trebui să
execute în mod fiabil comenzi de nivel înalt care să combine cele șase provocări
anterioare pentru a atinge un nou nivel de utilitate, mai ales dacă vor aduce beneficii
publicului larg. De exemplu, comanda „luați laptele” trebuie să genereze în mod
autonom sarcinile de nivel inferior de navigare la / de la frigider, deschiderea /
închiderea ușii, identificarea containerului adecvat (recipientele de lapte pot lua mai
multe forme) și apucarea sigură a containerului.
6.5 Clasificatori și modele discriminative (structura A) în robotică
6.5.1 Rolul structurii A în robotică
Structura A implică utilizarea unui model de învățare profundă pentru a

aproxima o funcție din perechile de intrare-ieșire eșantion. Aceasta poate fi cea mai
generală structură de învățare profundă, deoarece există multe funcții diferite în
robotică pe care cercetătorii și practicienii ar putea dori să le aproximeze din
eșantionul de observații. Unele exemple includ maparea de la acțiuni la modificările
corespunzătoare de stare, maparea de la modificările de stare la acțiunile care l-ar
provoca sau maparea de la forțe la mișcări. În timp ce, în unele cazuri, ecuațiile fizice
pentru aceste funcții pot fi deja cunoscute, există multe alte cazuri în care mediul
este prea complex pentru ca aceste ecuații să producă o precizie acceptabilă. În astfel
de situații, învățarea aproximării funcției din observațiile eșantionului poate produce
o precizie semnificativ mai bună.
Funcțiile care sunt aproximate nu trebuie să fie continue. Modelele de
aproximare a funcțiilor excelează, de asemenea, în sarcinile de clasificare, cum ar fi
determinarea tipului de obiect care se află înaintea robotului, a cărui abordare sau
strategia generală de planificare este cea mai potrivită pentru condițiile actuale sau
care este starea unui anumit obiect complex cu care robotul interacționează.
6.5.2 Exemple
Punjani și Abbeel [6.51] au folosit o funcție de aproximare a arhitecturii de

învățare profundă cu redresoare pentru a modela dinamica cuplată a unei drone
controlate prin radio, care este o provocare analitică provocatoare și o problemă

dificilă de identificare a sistemului.
Datele de instruire au fost obținute în timp ce un expert uman a controlat drona
prin diferite manevre acrobatice, iar DNN a obținut o dinamică a dronei aeriene cu
aproximativ 60% mai bună.
Neverova și colab. [6.52] a modelat modul în care timpul dintre mișcarea
capului șoferului și apariția unei manevre variază în funcție de viteza vehiculului.
Sistemul rezultat a făcut predicții la fiecare 0,8 secunde pe baza celor 5 secunde
precedente de date și a anticipat manevre cu aproximativ 3,5 secunde înainte ca
acestea să se producă, cu o precizie de 90,5%.
O mulțime de lucrări au folosit modele de aproximare a funcțiilor în domeniile
(1) detectării și percepției, (2) apucarea și manipularea obiectelor și (3) înțelegerea
scenei și fuziunea senzorilor. Următoarele trei subsecțiuni descriu lucrări recente în
fiecare dintre aceste domenii.
(1) Detectare și percepție. DNN-urile au avansat înaintea altor modele în
domeniul detectării și percepției. Sunt modele capabile să funcționeze
direct pe datele de intrare și nu necesită vectori de caracteristici, care în
mod normal sunt proiectate de către experți. Acest lucru reduce
dependența de experții umani, iar timpul suplimentar de instruire poate fi
parțial compensat prin reducerea efortului inițial de inginerie.
Mariolis, Peleka și Kargakos [6.53] au studiat recunoașterea obiectelor și a
pozelor pentru articolele de îmbrăcăminte prinse de un singur punct, ca și când ar fi
fost alese de un dispozitiv de prindere robotizat. Instruirea a avut loc pe pantaloni,
cămăși și prosoape cu diferite dimensiuni, forme și proprietăți materiale, atât plate,
cât și prinse de diferite puncte de prindere. Pe un set de testare format din șase obiecte
diferite de cele utilizate la antrenament, autorii au obținut o recunoaștere de 100% și
au putut prezice punctul de agățare pe îmbrăcăminte cu o eroare medie de 5,3 cm.
Aceste rezultate au fost mai precise și mai rapide decât suportul mașinilor vectoriale.
Yang, Li și Fermüller [6.54] au instruit un DNN pentru a recunoaște 48 de obiecte
obișnuite din bucătărie și pentru a clasifica gesturile umane pe ele din 88 de
videoclipuri despre gătit de pe YouTube. În special, videoclipurile nu au fost create
având în vedere roboții de antrenament, prezentând variații semnificative în fundal
și peisaj.
Au fost clasificate apucările de putere și precizie și subclasele fiecăruia.
Sistemul a obținut 79% precizie de recunoaștere a obiectelor și 91% precizie de
clasificare. Chen și colab. [6.55] a identificat existența și poziția ușilor cu o rețea
neuronală convoluțională și a transmis aceste informații unui algoritm de navigație
pentru un robot mobil. Ei sugerează că navigarea prin astfel de informații vizuale
poate fi superioară metodelor de construire a hărților în medii dinamice.
Gao, Hendricks, Kuchenbecker și Darrell [6.56] au integrat atât percepția
bazată pe video cât și pe cea de contact pentru a clasifica obiectele cu adjective
haptice (netede, conforme etc.). Dacă un robot ar putea prezice astfel de informații
înainte sau rapid după contactul cu obiectele, acesta poate întreprinde acțiuni
adecvate, cum ar fi ajustarea aderenței sale pe obiecte fragile sau evitarea
suprafețelor alunecoase. Ca și în celelalte studii de cercetare din această lucrare,

metoda lor nu a necesitat proiectarea manuală a vectorilor de caracteristici din
cunoștințe specifice domeniului.
(2) Prinderea și manipularea obiectelor. Yu, Weng, Liang și Xie [6.57] au
folosit o rețea neuronală convoluțională profundă pentru a recunoaște
cinci obiecte cunoscute așezate pe o suprafață plană și a clasifica
orientarea lor în categorii discretizate. Studiul s-a axat pe recunoaștere și
estimare a poziției, astfel încât planificarea înțelegerii s-a limitat la
poziționarea unui gripper paralel în centrul obiectului și aliniat cu unghiul
estimat. Ratele de succes au depășit 90%. Lenz, Lee și Saxena [6.58] au
folosit învățarea profundă pentru a detecta apucări optime pentru obiecte
din imagini RGB-D (culoare + adâncime). Rețeaua evaluează numeroase
apucări potențiale pentru obiect și îl identifică pe cel cu cel mai mare
potențial pentru succes fără nici o cunoaștere prealabilă a geometriei
obiectului. Încercările pe roboții Baxter și PR2 au dus la apucări de succes
84% și, respectiv, 89% din timp, comparativ cu 31% pentru un algoritm
de referință de ultimă generație. În loc să evalueze un set de potențiale
apucări, Redmon și Angelova [6.59] au instruit o rețea neuronală
convoluțională pentru a detecta o înțelegere acceptabilă direct din datele
RGB-D într-o singură trecere. Au obținut o precizie de 88% și pretind
performanțe în timp real, ajungând la o soluție în sub 100 de milisecunde.
Levine, Pastor, Krizhevsky și Quillen [6.60] au instruit o rețea neuronală
convoluțională pentru a evalua potențialul unei anumite mișcări a robotului pentru a
apuca cu succes obiecte obișnuite de birou din datele de imagine și au folosit o a
doua rețea pentru a oferi feedback continuu prin procesul de apucare.
Inspirat de coordonarea ochi-mână la om, sistemul a fost robust la mișcarea
obiectelor și la incertitudinea mecanicii de prindere. În timp ce această cercetare
poate părea similară cu servoarea vizuală la prima vedere, diferă prin faptul că nu au
fost necesari vectori de caracteristici proiectați manual pentru percepție, iar funcțiile
de transfer pentru controlul cu buclă închisă nu au fost modelate analitic.
(3) Înțelegerea scenei și fuziunea senzorilor. Extragerea sensului din
videoclipuri sau scene statice este o altă aplicație în care învățarea
profundă a făcut progrese impresionante.
Neverova, Wolf, Taylor și Nebout [6.52] raportează despre înregistrarea lor
câștigătoare pe primul loc în 2014 ChaLearn Looking at People Challenge
(http://gesture.chalearn.org), care îi provoacă pe participanți să recunoască 20 de
gesturi de conversație italiene diferite din 13.858 de videoclipuri RGB-D separate cu
diferite persoane care efectuează aceste gesturi. Ouyang și Wang [6.61] au abordat
simultan patru aspecte independente ale detectării pietonilor cu un singur DNN:
extragerea caracteristicilor, manipularea articulației și mișcării, manipularea ocluziei
și clasificarea.
Ei susțin că sistemul lor unificat evită interacțiunile suboptime dintre aceste

sisteme de obicei separate. Rețeaua integrată a fost instruită pe peste 60.000 de
eșantioane din două seturi de date disponibile public.
Comparativ cu alte 18 abordări din literatura publicată, sistemul autorilor
depășește performanțele ambelor seturi de date cu până la 9%. Wu, Yildirim, Lim,
Freeman și Tenenbaum [6.62] au încercat să prezică rezultatul fizic al scenelor
dinamice doar prin viziune, bazându-se pe premisa că oamenii pot prezice adesea
rezultatul unei scene dinamice din informațiile vizuale - de exemplu, un bloc
alunecând pe o rampă și impactând un alt bloc. Ei folosesc atât simulări dintr-un
motor de fizică, cât și teste fizice pentru antrenament.
De asemenea, sa descoperit că învățarea profundă este eficientă în tratarea
datelor multimodale generate în aplicații de detectare robotizată. Exemplele
menționate anterior includ integrarea datelor privind senzorii de viziune și haptici și
încorporarea atât a datelor de adâncime, cât și a informațiilor despre imagini din
datele camerei RGB-D (Depth Sensor).
În plus, Schmitz și colab. [6.63] a studiat recunoașterea obiectelor tactile cu o
mână cu mai multe degete TWENDY-ONE, care oferă un set multimodal de 312
valori de la senzorii distribuiți ai pielii, forțele vârfului degetelor, cuplurile articulare,
curenții actuatorului și unghiurile articulațiilor. Sistemul a fost instruit pe un set de
douăzeci de obiecte - unele în mod deliberat similare și altele foarte diferite - predate
robotului în diferite ipostaze. Cercetătorii au atins o rată de recunoaștere de 88%,
comparativ cu 68% care au folosit alte metode de recunoaștere.
6.5.3 Recomandări practice pentru lucrul cu structura A
Datorită numărului mare de meta-parametri, DNN-urile au dezvoltat oarecum

reputația de a fi dificil de utilizat de către non-experți. Cu toate acestea, acești
parametri oferă, de asemenea, o flexibilitate semnificativă, care este un factor major
în succesul lor general. Prin urmare, instruirea DNN-urilor necesită ca utilizatorul să
dezvolte cel puțin un nivel de bază de familiaritate cu mai multe concepte. Această
secțiune rezumă câteva dintre cele mai importante concepte implicate în funcția de
instruire, aproximând DNN-urile. În special, aplicarea acestor tehnici va ajuta la
abordarea Provocării 4 (recunoașterea avansată a obiectelor) și, într-o măsură mai
mică, la toate celelalte provocări.
Deși tendințele recente se înclină către modele mai adânci și mai mari, o rețea
neuronală simplă cu un singur strat ascuns și o funcție de activare standard în formă
de sigmoid se va antrena mult mai repede și va oferi o linie de bază utilă pentru a da
sens oricărei îmbunătățiri din utilizarea modelelor mai profunde . Atunci când se
utilizează modele mai profunde, redresoarele cu scurgeri tind să promoveze o
pregătire mai rapidă prin diminuarea efectelor problemei gradientului de dispariție
și îmbunătățesc precizia având un derivat monoton mai simplu.
Deoarece modelele cu mai multe greutăți au mai multă flexibilitate pentru a
se potrivi cu datele de antrenament, regularizarea este un rol important pentru
instruirea celui mai bun model. Plasa elastică combină metodele bine stabilite de
regularizare L1 și L2 pentru a promova robustețea împotriva saturației în greutate și,
de asemenea, pentru a promova raritatea în greutăți [6.64]. Metode mai noi de
regularizare, inclusiv abandonul [6.65] și drop-connect [6.66] au obținut rezultate
empirice și mai bune. Există, de asemenea, mai multe metode de regularizare special
pentru a îmbunătăți robustețea cu autoencoderi [6.67, 6.68].
Straturile cu destinație specială pot face, de asemenea, o diferență
semnificativă cu DNN-urile. Este o practică obișnuită să alternăm straturile de
convoluție și straturile maxime.
Straturile de grupare reduc numărul total de greutăți din rețea și permit, de
asemenea, modelului să învețe să recunoască obiecte, indiferent de locul în care apar
în câmpul vizual [6.69].
Straturile de normalizare în loturi pot produce îmbunătățiri semnificative ale
ratei de convergență prin menținerea gradientului într-un interval în care acesta va
afecta greutățile tuturor neuronilor [6.70]. Și straturile reziduale pot permite
formarea unor modele mult mai profunde și, prin urmare, mai flexibile [6.71]. Pentru
a utiliza în mod eficient modelele de învățare profundă, este important să vă instruiți
pe una sau mai multe unități de procesare grafică cu scop general (General Purpose
Graphical Processing Units GPGPU) [6.72].
Au fost încercate multe alte modalități de paralelizare a rețelelor neuronale
profunde, dar niciuna dintre ele nu produce încă câștigurile de performanță ale
GPGPU-urilor [6.73].
Deoarece DNN-urile necesită utilizarea a atât de multe tehnici specializate,
folosirea unui set de instrumente existent care oferă implementări gata făcute este un
imperativ. Din fericire, comunitatea de învățare profundă a fost foarte utilă în
lansarea de implementări open source a noilor dezvoltări, așa că multe seturi de
instrumente de învățare profundă open source bine rafinate sunt acum disponibile:
Tensorflow a crescut recent în popularitate [6.74].
Theano este o platformă bazată pe Python, care oferă o paralelizare a unității
de procesare grafică cu scop general (GPGPU) pentru învățarea profundă [6.75].
Câteva seturi de instrumente populare se construiesc deasupra Theano, inclusiv
Lasagne și Pylearn2 [6.76].
Keras este un pachet în jurul Tensorflow și Theano, care caută să simplifice
interfețele pentru învățarea profundă [6.77]. Torch oferă un mediu asemănător
Matlab scris în Lua pentru învățare profundă, cu accent deosebit pe rețelele
neuronale convoluționale [6.78]. În C ++, Caffe este unul dintre cele mai populare
seturi de instrumente pentru rețelele neuronale convoluționale performante [6.79].
De asemenea, oferă legături Python. Sunt disponibile alte seturi de
instrumente C ++ cu suport pentru GPU [6.80, 6.81]. Unele alte seturi de instrumente
cu suport de învățare profundă includ GroundHog, Theanets [6.82], Kaldi [6.83] și
CURRENNT [6.84].
Kustikova oferă un sondaj al multor seturi de instrumente de învățare profundă

pentru recunoașterea imaginii [6.85].
Seturile de instrumente care utilizează alte metode de paralelizare, în afară de
GPGPU-uri, includ Hadoop, Mahout, Spark, DeepLearning4j și Scala.
6.6 Modele generative și nesupravegheate (structura B)

în robotică
6.6.1 Rolul structurii B în robotică
Una dintre capacitățile caracteristice care îi fac pe oameni atât de pricepuți să

opereze în lumea reală este capacitatea lor de a înțelege ceea ce percep. O capacitate
similară este oferită în autoencoderi, un tip de model de învățare profundă care
ambele codifică observațiile într-o reprezentare internă, apoi o decodifică înapoi la
observația inițială.
Aceste modele digeră date de înaltă dimensiune și produc reprezentări interne
compacte, de dimensiuni reduse, care descriu succint semnificația din observațiile
originale [6.86].
Astfel, codificatoarele automate sunt utilizate în principal în cazurile în care
sunt disponibile observații de înaltă dimensiune, dar utilizatorul dorește o
reprezentare a stării în dimensiuni reduse.
Modelele generative sunt strâns legate. Utilizează doar porțiunea de decodare
a unui autoencoder și sunt utile pentru prezicerea observațiilor. Metodele de
inferență pot fi folosite cu modele generative pentru a estima reprezentările interne
ale stării, fără a necesita deloc antrenamentul unui codificator. În multe feluri,
modelele generative pot fi considerate opusul clasificatoarelor sau modelelor
discriminative, deoarece acestea se mapează de la o reprezentare succintă la un set
complet de dimensiuni ridicate, similare cu cele care ar putea fi observate de obicei.
6.6.2 Exemple
Finn și colab. [6.87] a instruit un auto-codificator spațial profund asupra

caracteristicilor vizuale pentru a extrage sensul din observații și, în cele din urmă,
pentru a obține controlul visuomotor. Autocoderul a aflat cum acțiunile robotului au
afectat configurația obiectelor din plicul de lucru și acest model a fost utilizat într-
un controler cu buclă închisă. Sarcinile includeau împingerea a
blocați, lingurați materialul într-un castron, scoateți cu o spatulă și atârnați o buclă
de frânghie pe un cârlig.
Wu și colab. [6.62] a folosit un model generativ pentru a anticipa rezultatele
simulărilor fizice. Watter, Springenberg, Bodecker și Reidmiller [6.88] au aplicat,
de asemenea, un model generativ pentru a modela dinamica neliniară a sistemelor
fizice simple și a le controla. Noda, Arie, Suga și Ogata [6.89] au dezvoltat o nouă
soluție de învățare profundă care implică atât metode nesupravegheate, cât și modele
recurente pentru integrarea datelor senzorimotorii multimodale, inclusiv imagini

RGB, date sonore și unghiuri articulare.
Un alt exemplu de structură B a fost demonstrat de Polydoros, Nalpantidis și
Kruger în modelarea dinamicii inverse a unui manipulator [6.90]. Rețeaua a fost
instruită folosind variabile de stare înregistrate în timpul funcționării sub control
standard în buclă închisă. O caracteristică de „memorie de decolorare” a permis ca
DNN să se adapteze pe măsură ce dinamica sa schimbat cu sarcina utilă și uzura
mecanică. Modelele dinamice analitice au dificultăți în a face față unor astfel de
modificări și sunt greu de obținut pentru manipulatori seriali-elastici foarte conformi,
cum ar fi noua clasă de roboți colaborativi. Autorii raportează că sistemul lor
depășește stadiul tehnicii în evaluările învățării în timp real și converge rapid, chiar
și cu date zgomotoase ale senzorilor.
Autocodificatorii și alte tehnici DNN nesupravegheate sunt deosebit de
potrivite pentru abordarea provocărilor legate de observațiile de înaltă dimensiune.
Ambele reduc dimensionalitatea și extrag reprezentări semnificative ale stării, care
reprezintă primul pas în fuziunea senzorului eficient.
Straturile convoluționale sunt eficiente pentru preucrarea imaginilor.
Deoarece imaginile sunt comune cu roboții, autoencoderii care utilizează straturi
convoluționale în porțiunea de codificare tind să fie deosebit de eficienți pentru
estimarea stării din imagini [6.91].
Pentru porțiunea de decodare a codificatorului auto, straturile convoluționale
oferă un avantaj mic.
O tehnică oarecum mai puțin cunoscută implică antrenarea decodorului pentru
a prezice doar un singur pixel și parametrizarea decodorului pentru a permite
utilizatorului să specifice ce pixel ar trebui să prezică [6.92]. Această abordare are
multe analogii cu convoluția și experimental pare să ducă la timpi de antrenament
mult mai rapizi.
Regularizarea este deosebit de importantă pentru obținerea de rezultate bune
cu autoencoderi, iar metodele specializate de regularizare au fost concepute în
special pentru autoencoderi [6.93]. Cu toate acestea, unele experimente au arătat că,
în loc să regularizăm puternic codificatorul, poate chiar să funcționeze mai bine se
va omite în totalitate codificatorul și se va utiliza un decodor independent.
6.7 Modele de învățare a politicilor (structura D) în robotică
6.7.1 Rolul structurii D în robotică
Învățarea unei politici de control aproape optime (sau cel puțin o acceptare
rezonabilă) este adesea obiectivul principal în combinarea învățării automate cu
robotica. Modelul canonic pentru utilizarea rețelelor neuronale profunde pentru
învățarea unei politici de control este Q-learning profund [6.18]. Folosește un DNN
pentru a modela un tabel de valori Q, care sunt antrenate să convergă la o
reprezentare a valorilor pentru efectuarea fiecărei acțiuni posibile în orice stare. Deși
structura D este destul de similară cu structura A în ceea ce privește modelul în sine,

ele sunt instruite în moduri semnificativ diferite. În loc să minimizeze eroarea de
predicție împotriva unui set de eșantioane de formare, rețelele Q profunde caută să
maximizeze recompensa pe termen lung. Acest lucru se face prin căutarea unui
echilibru între explorare și exploatare care să ducă în cele din urmă la un model
politic eficient.
În cele din urmă, modelele de învățare profundă sunt utile pentru a învăța să
funcționeze sisteme dinamice din informații de stare parțială, iar controlerele bazate
pe învățarea profundă pot fi foarte eficiente din punct de vedere al calculului în
timpul rulării [6.94]. Ele deduc automat priorități pe baza recompenselor care sunt
obținute în timpul antrenamentului. În teorie, ele oferă un sistem complet de învățare
a politicilor de control, dar suferă de perioade de antrenament extrem de lente.
6.7.2 Exemple
Din [6.94] se desprinde metoda de învățare a unor politici de control pentru a

implementa un model de căutare ghidată de control predictiv pentru vehicule aeriene
autonome. Reducerea sarcinii de calcul în robotica mobilă se traduce prin economii
de energie care măresc autonomia și / sau îmbunătățesc performanța. Fără a fi nevoie
de informații complete despre stare, sunt necesari mai puțini senzori la bord,
reducând în continuare consumul de energie, costul și greutatea.
Învățarea profundă a fost, de asemenea, utilizată pentru a controla sistemele
dinamice din video, fără acces direct la informațiile de stare. În [6.95] se poate
observa cum a fost instruit un cursant privind învățarea profundă bazată pe date care
conțin informații sub formă de pixeli din peste 20 de sisteme dinamice simulate și
pe baza cărora s-a dezvoltat un sistem de planificare a mișcării care a funcționat la
fel de bine sau mai bine decât algoritmii care au acces la starea completă a sistemului
dinamic.
O altă metodă [6.96] a folosit videoclipuri cu experți umani care îndeplinesc
diverse sarcini pentru a instrui un DNN pentru a învăța funcții de cost neliniar (cu
structura A). Odată ce aceste funcții de cost au fost învățate, acestea ar putea fi
utilizate pentru a instrui un cursant de consolidare (structura D) pentru planificarea
mișcării. Ei au demonstrat abilitatea de a finaliza sarcini care implicau dinamici
complexe de ordinul 2 și interacțiuni greu de modelat între un manipulator și diverse
obiecte, inclusiv navigație 2D, atingere, inserare a cuierelor, plasarea unui vas și
turnare. Controlul vizomotor necesită o integrare și mai strânsă între percepția
obiectului și apucarea, mapând datele imaginii direct la semnalele de control ale
actuatorului.
Spre deosebire de [6.96], în [6.97] s-a folosit învățarea profundă (Structura D)
pentru a arăta că acest lucru poate fi superior sistemelor separate de percepție și
control. Aplicațiile de testare au inclus sortarea formelor, înșurubarea unui capac pe
o sticlă, montarea unei gheare de ciocan pe un cui și plasarea unui cuier pe un raft.
Sistemul rezultat ar putea îndeplini sarcinile în mod fiabil, chiar și cu distractori
vizuali moderați.
6.7.3 Recomandări practice pentru lucrul cu structura D
Modelele de învățare a politicilor reprezintă în cele din urmă soluția pentru

abordarea Provocărilor 2 (politicile de control al învățării în medii dinamice) și 7
(planificarea sarcinilor la nivel înalt). Poate că cea mai mare dificultate atunci când
lucrezi cu modele de învățare profundă este totuși cantitatea uriașă de timp de calcul
necesară pentru a le instrui. Deși astfel de modele sunt extrem de eficiente după
antrenament, ele tind să necesite mai multe prezentări de tipare de antrenament
înainte de a converge pentru a reprezenta politici de control fiabile. Prin urmare,
având grijă să găsiți o implementare eficientă optimizată prin GPU, puteți face o
mare diferență.
O altă tehnică importantă este antrenarea în simulare înainte de a încerca
antrenarea cu un robot propriu-zis. Acest lucru reduce uzura echipamentelor fizice,
precum și timpul de antrenament.
Chiar dacă este disponibilă doar o simulare brută, un model care a fost pre-
antrenat pentru o provocare similară va converge mult mai repede pentru a se potrivi
provocării reale decât unul care a fost antrenat de la zero.
Deoarece roboții operează adesea într-un spațiu cu acțiuni continue, Q-
learning-ul tradițional nu este direct aplicabil. Cu toate acestea, modelele critice
abordează această problemă. Regresează acțiunile coroborate cu tabelul Q continuu
și conduc la un model final care calculează direct cea mai bună acțiune având în
vedere observația curentă, care este bine potrivită pentru aplicațiile robotice [6.98].
Un alt aspect important este politica de explorare. Politica tradițională de
explorare conduce la cerințe de instruire în calcul mult mai ridicate decât abordările
moderne [6.99, 6.100]. Prin urmare, este avantajos să instruiți structura D într-o
abordare care explorează inteligent stări noi.
6.8 Dezavantajele actuale ale DNN-urilor pentru robotică
Pentru toate beneficiile sale, învățarea profundă prezintă unele dezavantaje.

Poate că cel mai semnificativ este volumul de date de antrenament necesare, care
este deosebit de problematic în robotică, deoarece generarea de date de antrenament
pe sisteme fizice poate fi costisitoare și consumatoare de timp. De exemplu, Levine
și colab. [6.60] au folosit 14 roboți pentru a colecta peste 800.000 de încercări de
strângere pe o perioadă de 2 luni. Într-un alt scenariu s-a instruit sistemul de predicție
a manevrelor de trafic pe 1180 mile de viteză mare și mică cu 10 șoferi diferiți.
Punjani și Abbeel [6.51] au solicitat demonstrații repetate ale manevrelor aerobate
ale elicopterelor de către un expert uman. Neverova și colab. [6.52] au avut acces la
peste 13.000 de videoclipuri de conversații, iar Ouyang și Wang [6.61] au avut acces
la 60.000 de eșantioane pentru detectarea pietonilor. Pinto și Gupta [6.101] au avut
nevoie de 700 de ore de timp pentru a genera un set de date de 50.000 de graps-uri
pentru formarea unei rețele neuronale convoluționale.
În ciuda acestui fapt, literatura conține abordări inteligente pentru a atenua
acest dezavantaj. O abordare presupune utilizarea simulării pentru a genera date de
antrenament virtual. De exemplu, Mariolis și colab. [78] pre-antrenate

îmbrăcămintea lor reprezintă rețele de recunoaștere pe un set mare de date sintetice
create în simulare utilizând software-ul grafic 3D Kappler.
Bohg și Schaal [6.102] au generat o bază de date de peste 300.000 de apucări
cu aproximativ 700 de obiecte în simulare, generând metrici de calitate a înțelegerii
bazate pe fizică pentru fiecare și folosind aceasta pentru a clasifica automat
stabilitatea înțelegerii. Ei au validat prin clasificarea umană a apucărilor și au ajuns
la concluzia că etichetarea generată de computer și de om a avut o corelație bună. O
altă strategie este folosirea datelor de antrenament prin manipulare digitală.
Neverova și colab. [6.52] s-a confruntat cu provocarea conform căreia viteza
gesturilor conversaționale variază semnificativ în funcție de diferite persoane. Au
variat viteza de redare video pentru a simula această varianță temporală, extinzându-
și setul de antrenament fără a fi nevoie să dobândească mostre suplimentare. Alți
cercetători care folosesc învățarea profundă, cum ar fi Polydoros și colab. [6.90] și
Zhang și colab. [6.94], utilizează sisteme de control alternative în faza de învățare.
Timpul de antrenament este o altă provocare asociată cu dimensiunea simplă
a DNN-urilor.
Modelele tipice implică până la milioane de parametri și pot dura câteva zile
pentru a vă antrena pe hardware paralel, lucru practic numai pentru sarcini repetate
frecvent, care oferă o rambursare adecvată a timpului de instruire investit. O
modalitate de a reduce timpul de instruire este distribuirea unei sarcini între mai
multe DNN-uri mai mici. Mariolis și colab. [6.53] a antrenat două DNN-uri: unul a
efectuat clasificarea obiectelor, iar rezultatul său a fost transmis unei a doua rețele
pentru recunoașterea poziției. Această abordare în mai mulți pași a accelerat atât
antrenamentul, cât și clasificarea în timpul rulării. Lenz și colab. [6.58] a folosit un
design de rețea în două etape pentru detectarea înțelegerii. Primul DNN avea relativ
puțini parametri. Sacrificând precizia pentru viteză, a eliminat apucările improbabile.
A doua etapă a avut mai mulți parametri, făcându-l mai precis, dar a fost relativ rapid,
deoarece nu a fost nevoie să ia în considerare apucările improbabile. Ei au găsit
combinația ca fiind robustă și eficientă din punct de vedere al calculului.
Trebuie remarcat, totuși, că această strategie reprezintă un compromis cu
rezultatele altor cercetători conform cărora integrarea mai multor funcții într-o
singură rețea are ca rezultat o performanță mai bună.
Lucrările lui Zhang și colab. [6.94] evidențiază două provocări suplimentare.
În primul rând, învățarea nesupravegheată nu este practică pentru sistemele
robotizate în care o singură defecțiune este catastrofală, ca în cazul vehiculelor
aeriene. În al doilea rând, furnizarea resurselor de calcul necesare pentru învățarea
profundă într-un sistem sensibil la greutate, consum de energie și cost nu este adesea
practic. Autorii și-au instruit sistemele aeriene folosind un sistem de control wireless
cu vehiculul. Acest lucru a făcut ca antrenamentul să fie sigur și automat și le-a
permis să utilizeze resurse de calcul off-board pentru antrenament.
6.9 Deep Learning pentru prinderea unor obiecte

Prinderea unor obiecte de către roboți este o problemă provocatoare care

implică percepția, planificarea și controlul. Unele lucrări recente abordează aspectul
percepției acestei probleme transformându-l într-o problemă de detectare în care,
având o vedere parțială și zgomotoasă a obiectului de la o cameră. Scopul este de a
deduce locațiile optime unde ar putea fi amplasat un dispozitiv de prindere robotizat.
Spre deosebire de problemele de viziune generice bazate pe imagini statice, astfel de
probleme de percepție robotică sunt adesea utilizate în buclă închisă cu controlere,
deoarece există cerințe stricte privind performanța și viteza de calcul. În trecut,
caracteristicile de proiectare manuală au fost cele mai populare metode pentru mai
multe sarcini robotizate. Cu toate acestea, acest lucru este greoi și consumă mult
timp, mai ales atunci când încorporează noi modalități de intrare, cum ar fi camerele
RGB-D.
Majoritatea lucrărilor definesc o „apucare” ca o configurație de efect final care
realizează închiderea parțială sau completă a forței sau a unui obiect dat. Aceasta
este o problemă provocatoare, deoarece depinde de poziția și configurația
dispozitivului de prindere robotizat, precum și de forma și proprietățile fizice ale
obiectului care trebuie înțeles și necesită de obicei o căutare pe un număr mare de
configurații posibile de prindere. În general acest fenomen s-a concentrat pe testarea
închiderii formei și forței și pe sintetizarea apucărilor care îndeplinesc aceste
proprietăți conform unor „scoruri de calitate” proiectate manual [6.103,6.104].
Aceste lucrări presupuneau cunoștințe complete despre forma obiectului și
proprietățile fizice.
Pentru apucarea unui model 3D, de regulă se utilizează o simulare fizică
avansată pentru a găsi apucări optime. Optimizarea apucărilor, pentru un model 3D
al obiectului necesită stabilirea unor puncte de contact dorite pentru prinderea de
către brațul robotizat. În [6.105] se definesc spații de obiecte ușor de înțeles, apoi
cum se pot mapa obiecte noi în aceste spații pentru a descoperi modul cum pot fi
apucate obiectele 3D. Această metodă are un dezavantaj deoarece trebuie cunoscut
modelul 3D al obiectului, ceea ce nu are cum atunci când robotul interacționează cu
un mediu nou.
Detectarea pentru apucare: într-un cadru robotizat din lumea reală, un robot
nu va avea cunoștințe depline despre modelul 3D și poziția unui obiect care trebuie
înțeles, ci mai degrabă doar informații incomplete din unele seturi de senzori, cum
ar fi, nuanțele de culoare sau cele date de adâncime, senzori tactili etc. Acest lucru
face ca problema înțelegerii să fie semnificativ mai dificilă, deoarece algoritmul
trebuie să utilizeze informații mai limitate. O altă soluție o reprezintă estimarea
ipostazele obiectelor cunoscute și apoi să se aplice algoritmi de apucare a modelului
complet pe baza acestor rezultate. Altele evită această presupunere, funcționând pe
baza datelor de la senzori pentru identificarea de obiecte noi pe care algoritmul nu
le-a văzut până acum.
Toate soluțiile au folosit ipoteze simplificate, care presupun că obiectele
aparțin unuia dintr-un set de forme primitive [6.106, 6.107], sau că ele sunt plane
[6.108]. Alte lucrări elimină presupunerea unui model de obiect pe deplin cunoscut,
deoarece regulile de înțelegere codate manual au dificultăți în a face față gamei largi
de obiecte văzute în mediile umane din lumea reală și sunt greu de creat și
consumatoare de timp.
Învățarea pentru apucare - metodele de învățare automată s-au dovedit eficiente
pentru o gamă largă de probleme de percepție [6.109, 6.110], permițând unui sistem
de percepție să învețe o mapare de la un set de caracteristici la diferite proprietăți
vizuale. Abordările de învățare ar putea fi aplicate și problemei de a apucare, având
senzori pentru captarea de imagini, metoda de învățare bazându-se pe scorurile de
calitate.
Utilizarea datelor 3D îmbunătățește semnificativ aceste rezultate grație oferirii
de informații fizice directe despre obiectul în cauză. Odată cu apariția senzorilor
RGB-D cu un preț redus, cum ar fi dispozitivul Kinect, utilizarea datelor de adâncime
pentru apucarea robotică a devenit mult mai facilă.
Localizarea și maparea simultană (Simultaneous Localization and Mapping -
SLAM) pentru datele RGB-D pune accent pe analiza multimodală a datelor,
distingând canalele de culoare și de adâncime.
Învățarea și regularizarea structurată - are ca abordare folosirea unei funcții
de regularizare pentru a impune structura unui set de parametri învățați.
6.1. LeCun Y, Bengio Y, Hinton G. Deep learning. Nature. 2015;521(7553):436-444.

6.2. Jordan MI, Mitchell TM. Machine learning: arends, perspectives, and
prospects. Science. 2015;349(6245):255-260.
6.3. Böhmer W, Springenberg JT, Boedecker J, et al. Autonomous learning of
state representations for control: an emerging field aims to autonomously
learn state representations for reinforcement learning agents from their real-
world sensor observations. KI-Künstliche Intelligenz. 2015;29(4):353-362.
6.4. Dunne RA, & Campbell NA. On the pairing of the softmax activation and
cross-entropy penalty functions and the derivation of the softmax activation
function. In Proc. 8th Aust. Conf. on the Neural Networks, Melbourne
1997;181 (Vol. 185).
6.5. Wilson DR, Martinez TR. The general inefficiency of batch training for
gradient descent learning. Neural Networks. 2003;16(10):1429-1451.
6.6. Tieleman T, Hinton G. (2012). Lecture 6.5-rmsprop: divide the gradient by a
running average of its recent magnitude. COURSERA: Neural Networks for
Machine Learning, 4(2).
6.7. Kingma D, Ba J. (2014). Adam: a method for stochastic optimization. arXiv
preprint arXiv:1412.6980.
6.8. Vincent P, Larochelle H, Lajoie I, et al. Stacked denoising dutoencoders:
learning useful representations in a deep network with a local denoising
criterion. J Mach Learning Research. 2010;11:3371-3408.
6.9. Ciresan D, Meier U, Schmidhuber J. Multi-column deep neural networks for
image classification. Computer Vision and Pattern Recognition (CVPR),
2012 IEEE Conference on; 2012. p. 3642-3649.

6.10. Krizhevsky A, Sutskever I, Hinton GE. Imagenet classification with deep
convolutional neural networks. Advances in Neural Information Processing
Systems 25; 2012.
6.11. LeCun Y, Bengio Y. Convolutional networks for images, speech, and time
series. In M. Arbib, editor. The Handbook of Brain Theory and Neural
Networks. 2nd edition. Cambridge, MA: MIT Press; 2003.
6.12. Gashler M, Martinez T. Temporal nonlinear dimensionality reduction. Neural
Networks (IJCNN), 2011 International Joint Conference on; 2011. p. 1959-1966.
6.13. Werbos PJ. Backpropagation through time: what it does and how to do it.
Proc. IEEE. 1990;78(10):1550-1560.
6.14. Sjöberg J, Zhang Q, Ljung L, et al. Nonlinear black-box modeling in system
identification: a unified overview. Automatica. 1995;31(12):1691-1724.
6.15. Schmidhuber J. Deep learning in neural networks: an overview. Neural
Networks. 2015;6(1)85-117.
6.16. Hochreiter S, Schmidhuber J. Long short-term memory. Neural Computation.
1997;9(8):1735-1780.
6.17. Atkeson CG, Santamaria JC. A comparison of direct and model-based
reinforcement learning. Robotics and Automation, IEEE Int. Conf. on;
Albuquerque, NM. 1997. p. 3557-3564.
6.18. Mnih V, Kavukcuoglu K, Silver D, et al. Human-level control through deep
reinforcement learning. Nature. 2015;518:529-533.
6.19. LeCun Y, Boser B, Denker JS, Henderson D, Howard RE, Hubbard W, Jackel
LD. Backpropagation applied to handwritten zip code recognition. Neural
Computation. 1989;1(4), 541-551.
6.20. LeCun Y, Bottou L, Bengio Y, Haffner P.. Gradient-based learning applied
to document recognition. Proceedings of the IEEE. 1998;86(11):2278-2324.
6.21. Krizhevsky A, Sutskever I, Hinton GE. Imagenet classification with deep
convolutional neural networks. Advances in Neural Information Processing
Systems 25; 2012.
Networks. 2015;6(1)85-117.
6.23. Cireşan D, Meier U, Masci J, et al. A committee of neural networks for traffic
sign classification. Neural Networks (IJCNN), 2011 Int. Joint Conf. on; 2011.
p. 1918-1921.
6.24. Ciresan D, Meier U, Schmidhuber J. Multi-column deep neural networks for
image classification. Computer Vision and Pattern Recognition (CVPR),
2012 IEEE Conference on; 2012. p. 3642-3649.
6.25. Simonyan K, Zisserman A. (2014). Very deep convolutional networks for
largescale image recognition. arXiv preprint arXiv:1409.1556.
6.26. Szegedy C, Liu W, Jia Y, Sermanet P, Reed S, Anguelov D., ... Rabinovich
A. (2015). Going deeper with convolutions. In Proc of the IEEE Conference
on Computer Vision and Pattern Recognition (pp. 1-9).
6.27. Chen LC, Papandreou G, Kokkinos I, Murphy K, & Yuille AL. (2014).
Semantic image segmentation with deep convolutional nets and fully
connected crfs. arXiv preprint arXiv:1412.7062.
6.28. Sermanet P, Eigen D, Zhang X, Mathieu M, Fergus R, LeCun Y. (2013).
Overfeat: integrated recognition, localization and detection using
convolutional networks. arXiv preprint arXiv:1312.6229.
6.29. Dong C, Loy CC, He K, Tang X. (2014, September). Learning a deep
convolutional network for image super-resolution. In European Conf on
Computer Vision (pp. 184-199). Springer International Publishing.
6.30. Sun Y, Wang X, Tang X. (2013). Deep convolutional network cascade for
facial point detection. In Proc of the IEEE Conf on Computer Vision and
Pattern Recognition (pp. 3476-3483).
6.31. Taigman Y, Yang M, Ranzato MA, Wolf L. (2014). Deepface: closing the
gap to human-level performance in face verification. In Proc of the IEEE Conf
on Computer Vision and Pattern Recognition (pp. 1701-1708).
6.32. Zhou B, Lapedriza A, Xiao J, Torralba A, Oliva A. (2014). Learning deep
features for scene recognition using places database. In Advances in Neural
Information Processing Sys (pp. 487-495).
6.33. Ji S, Xu W, Yang M, Yu K.. 3D convolutional neural networks for human
action recognition. IEEE Transactions on Pattern Analysis and Machine
Intelligence. 2013;35(1):221-231.
6.34. Graves A, Mohamed AR, Hinton G. (2013, May). Speech recognition with
deep recurrent neural networks. In Acoustics, Speech and Signal Proc
(ICASSP), 2013 IEEE Int Conf on (pp. 6645-6649). IEEE.
6.35. Bakshi BR, Stephanopoulos G. Wave‐net: a multiresolution, hierarchical
neural network with localized learning. AIChE Journal. 1993;39(1):57-81
6.36. Arel I, Rose DC, Karnowski TP. Deep machine learning - a new frontier in
artificial intelligence research [research frontier]. IEEE Computational
Intelligence Magazine. 2010;5(4);13-18
6.37. Kim Y, Moon T. . Human detection and activity classification based on
microdoppler signatures using deep convolutional neural networks. IEEE
Geoscience and Remote Sensing Letters. 2016;13(1):8-12.
6.38. Liu F, Shen C, Lin G, Reid I.. Learning depth from single monocular images
using deep convolutional neural fields. IEEE Transactions on Pattern
Analysis and Machine Intelligence 2016;38(10):2024-2039.
6.39. Eitel A, Springenberg JT, Spinello L, Riedmiller M, Burgard W. (2015,
September). Multimodal deep learning for robust rgb-d object recognition. In
Intelligent Robots and Sys (IROS), 2015 IEEE/RSJ International Conference on
(pp. 681-687). IEEE.
6.40. Bohannon J. Helping robots see the big picture. Science. 2014;346(6206):186-
187.
6.41. Sweller J. (2008, September). Evolutionary bases of human cognitive
architecture: implications for computing education. In Proc of the Fourth Int
Workshop on Computing Education Research (pp. 1-2). ACM.
6.42. Doya K. What are the computations of the cerebellum, the basal ganglia and
the cerebral cortex? Neural Networks, 1999;12(7):961-974.
6.43. Langley P, Laird JE, Rogers S. Cognitive architectures: research issues and
challenges. Cognitive Sys Research 2009;10(2):141-160.
6.44. Sun R. (2006). Cognition and multi-agent interaction: from cognitive
modeling to social simulation. Cambridge University Press.
6.45. Duch W, Oentaryo RJ, Pasquier M. (2008, June). Cognitive Architectures:
Where do we go from here? In AGI (Vol. 171, pp. 122-136).
6.46. A roadmap for US robotics: from internet to robotics, 2016 edition.
6.47. A roadmap for US robotics: from internet to robotics, 2016 edition.
6.48. FY2009-2034 Unmanned systems integrated roadmap. Washington, DC:
Department of Defence (US); 2009.
6.49. Material Handling Institute. Material handling and logistics U.S. roadmap 2.0.
2017.
6.50. DARPA Robotics Challenge [Internet]. [cited 2017 May 20]. Available from:
http://www.darpa.mil/program/darpa-robotics-challenge.
6.51. Punjani AP, Abbeel P. Deep learning helicopter dynamics models. Robotics
and Automation (ICRA), 2015 IEEE International Conference on; 2015. p.
3223- 3230.
6.52. Neverova N, Wolf C, Taylor GW, et al. Multi-scale deep learning for gesture
detection and localization. Computer Vision-ECCV 2014 Workshops; 2014. p.
474-490.
6.53. Mariolis I, Peleka G, Kargakos A, et al. Pose and category recognition of highly
deformable objects using deep learning. Advanced Robotics (ICAR), 2015
International Conference on; Istanbul. 2015. p. 655-662.
6.54. Yang Y, Li Y, Fermüller C, et al. Robot learning manipulation action plans by
watching unconstrained videos from the world wide web. 29th AAAI
Conference on Artificial Intelligence (AAAI-15); Austin, TX. 2015.
6.55. Chen W, Qu T, Zhou Y, et al. Door recognition and deep learning algorithm for
visual based robot navigation. Robotics and Biomimetics (ROBIO), 2014 IEEE
International Conference on; Bali. 2014. p. 1793-1798.
6.56. Gao Y, Hendricks LA, Kuchenbecker KJ, et al. Deep learning for tactile
understanding from visual and haptic data. 2015. Available:
http://arxiv.org/abs/1511.06065.
6.57. Yu J, Weng K, Liang G, et al. A vision-based robotic grasping system using
deep learning for 3D object recognition and pose estimation. Robotics and
Biomimetics (ROBIO), 2013 IEEE International Conference on; Shenzhen.
2013. p. 1175-1180..
6.58. Lenz I, Lee H, Saxena A. Deep learning for detecting robotic grasps. Int J
Robotics res. 2015;34(4-5):705-724.
6.59. Redmon J, Angelova A. Real-time grasp detection using convolutional neural
networks. 2015 IEEE International Conference on Robotics and Automation
(ICRA); Seattle, WA. 2015. p. 1316-1322.
6.60. Levine S, Pastor P, Krizhevsky A, et al. Learning hand-eye coordination for

robotic grasping with deep learning and large-scale data collection. 2016.
Available: http://arxiv.org/abs/1603.02199.
6.61. Ouyang W, Wang X. Joint deep learning for pedestrian detection. Computer
Vision, 2013 IEEE Int. Conf. on; Sidney, VIC. 2013. p. 2056-2063.
6.62. Wu J, Yildirim I, Lim JJ, et al. Galileo: Perceiving physical object properties
by integrating a physics engine with deep learning. Advances in Neural
Information Processing Systems 28; 2015.
6.63. Schmitz A, Bansho Y, Noda K, et al. Tactile object recognition using deep
learning and dropout. Humanoid Robots, 2014 14th IEEE-RAS Int. Conf. on;
2014. p. 1044-1050.
6.64. Zou H, Hastie T. Regularization and variable selection via the elastic net. J
Royal Statistical Society: Series B (Statistical Methodology), 2005;67(2):301-
320.
6.65. Srivastava N, Hinton GE, Krizhevsky A, Sutskever I, Salakhutdinov R.
Dropout: a simple way to prevent neural networks from overfitting. Journal of
Machine Learning Research, 2014;15(1):1929-1958.
6.66. Wan L, Zeiler M, Zhang S, Cun YL, Fergus R. (2013). Regularization of neural
networks using dropconnect. In Proc of the 30th Int Conf on Machine Learning
(ICML-13) (pp. 1058-1066).
6.67. Rifai S, Vincent P, Muller X, Glorot X, Bengio Y. (2011). Contractive
autoencoders: explicit invariance during feature extraction. In Proc of the 28th
Int Conf on Machine Learning (ICML-11) (pp. 833-840).
6.68. Li Z, Fan Y, Liu W. The effect of whitening transformation on pooling
operations in convolutional autoencoders. EURASIP J on Advances in Signal
Proc, 2015; (1):37.
6.69. Jarrett K, Kavukcuoglu K, LeCun Y. (2009, September). What is the best
multistage architecture for object recognition? In Computer Vision, 2009 IEEE
12th Int Conf on (pp. 2146-2153). IEEE.
6.70. Ioffe S, Szegedy C. (2015). Batch normalization: accelerating deep network.
6.71. He K, Zhang X, Ren S, Sun J. (2016). Deep residual learning for image
recognition. In Proc of the IEEE Conf on Computer Vision and Pattern
Recognition (pp. 770-778).
6.72. Oh K, Jung K. GPU implementation of neural networks. Pattern Recognition.
2004;37(6):1311-1314.
Networks. 2015;6(1)85-117.
6.74. Abadi M, Agarwal A, Barham P, Brevdo E, Chen Z, Citro C, ... Ghemawat S.
(2016). Tensorflow: large-scale machine learning on heterogeneous distributed
systems. arXiv preprint arXiv:1603.04467.
6.75. Abadi M, Agarwal A, Barham P, Brevdo E, Chen Z, Citro C, ... Ghemawat S.
(2016). Tensorflow: large-scale machine learning on heterogeneous distributed
systems. arXiv preprint arXiv:1603.04467.
6.76. Goodfellow IJ, Warde-Farley D, Lamblin P, Dumoulin V, Mirza M, Pascanu

R,... Bengio,Y. (2013). Pylearn2: a machine learning research library. arXiv
preprint arXiv:1308.4214.
6.77. Chollet F. (2015). Keras: deep learning library for theano and tensorflow. URL:
https://keras. io/k.
6.78. Collobert R, Kavukcuoglu K, Farabet C. (2011). Torch7: a matlab-like
environment for machine learning. In BigLearn, NIPS Workshop (No.
EPFLCONF-192376).
6.79. Jia Y, Shelhamer E, Donahue J, Karayev S, Long J, Girshick R, ... Darrell T.
(2014, November). Caffe: convolutional architecture for fast feature
embedding. In Proc 22nd ACM Int Conf on Multimedia (pp. 675-678). ACM.
6.80. Attardi G. (2015, June). Deepnl: a deep learning nlp pipeline. In Proc of
NAACL-HLT (pp. 109-115).
6.81. Gashler M. Waffles: a machine learning toolkit. J Machine Learning Res,
2011;12(Jul):2383-2387.
6.82. Johnson L. Theanets documentation. Url: http://theanets.readthedocs.org/
en/stable/.
6.83. Povey D, Ghoshal A, Boulianne G, Burget L, Glembek O, Goel N,... Silovsky
J. (2011). The Kaldi speech recognition toolkit. In IEEE 2011 workshop on
automatic speech recognition and understanding (No. EPFL-CONF-192584).
IEEE Signal Processing Society.
6.84. Weninger F, Bergmann J, Schuller BW. Introducing CURRENNT: the munich
open-source CUDA recurrent neural network toolkit. J Machine Learning
Research, 2015;16(3):547-551.
6.85. Kustikova VD, Druzhkov PN. (2014). A survey of deep learning methods and
software for image classification and object detection. OGRW2014, 5.
6.86. Harry A. Pierson, Michael S. Gashler, Deep Learnining in Robotics: A Review
of Recent Research, arXiv:1707.07217, July 2017 Advanced Robotics 31(2)
DOI: 10.1080/01691864.2017.1365009.
6.87. Finn C, Tan XY, Duan Y, et al. Deep spatial autoencoders for visuomotor
learning. 2015. Available: http://arxiv.org/abs/1509.06113.
6.88. Watter M, Springenberg J, Boedecker J, et al. Embed to control: a locally linear
latent dynamics model for control from raw images. Advances in Neural
Information Proc Sys 28; 2015.
6.89. Noda K, Arie H, Suga Y, et al. Multimodal integration learning of robot
behavior using deep neural networks. Robotics and Autonomous Sys.
2014;62(6):721- 736.
6.90. Polydoros AS, Nalpantidis L, Kruger V. Real-time deep learning of robotic
manipulator inverse dynamics. Intelligent Robots and Systems (IROS), 2015
IEEE/RSJ International Conference on; 2015. p. 3442-3448.
6.91. Masci J, Meier U, Cireşan D, Schmidhuber J. (2011). Stacked convolutional
autoencoders for hierarchical feature extraction. Artificial Neural Networks and
Machine Learning–ICANN 2011, 52-59.
6.92. Ashmore SC, Gashler MS. (2016, December). Practical techniques for using
neural networks to estimate state from images. In Machine Learning and
Applications (ICMLA), 2016 15th IEEE Int Conf on (pp. 916-919). IEEE.
6.93. Rifai S, Vincent P, Muller X, Glorot X, Bengio Y. (2011). Contractive
autoencoders: explicit invariance during feature extraction. In Proc of the 28th
Int Conf on Machine Learning (ICML-11) (pp. 833-840).
6.94. Zhang T, Kahn G, Levine S, et al. Learning deep control policies for
autonomous aerial vehicles with MPC-guided policy search. 2015. Available:
http://arxiv.org/abs/1509.06791.
6.95. Lillicrap TP, Hunt JJ, Pritzel A, et al. Continuous control with deep reinforcement
learning. 2015. Available: http://arxiv.org/abs/ 1509.02971.
6.96. Finn C, Levine S, Abbeel P. Guided cost learning: deep inverse optimal control
via policy optimization. 2016. Available: http://arxiv.org/ abs/1603.00448.
6.97. Levine S, Finn C, Darrell T, et al. End-to-end training of deep visuomotor
policies. J Mach Learning Research. 2016;17:1-40.
6.98. Rosenstein M, Barto A.(2004). J. 4 supervised actor-critic reinforcement
learning. Handbook of Learning and Approximate dynamic programming, 2,
359.
6.99. Houthooft R, Chen X, Duan Y, Schulman J, De Turck F, Abbeel P. (2016).
VIME: variational information maximizing exploration. In Advances in Neural
Information Processing Systems (pp. 1109-1117).
6.100. Osband I, Blundell C, Pritzel A, Van Roy B. (2016). Deep exploration via
bootstrapped DQN. In Advances in Neural Information Processing Systems
(pp. 4026-4034).
6.101. Pinto L, Gupta A. Supersizing self-supervision: learning to grasp from 50k tries
and 700 robot hours. 2015. Available: http://arxiv.org/abs/ 1509.06825.
6.102. Kappler D, Bohg J, Schaal S. Leveraging big data for grasp planning. 2015
IEEE International Conference on Robotics and Automation (ICRA); Seattle,
WA. 2015. p. 4304-4311.
6.103. C. Ferrari and J. Canny. Planning optimal grasps. ICRA, 1992.
6.104. A. Rodriguez, M. Mason, and S. Ferry. From caging to grasping. In RSS, 2011.
6.105. F. T. Pokorny, K. Hang, and D. Kragic. Grasp moduli spaces. In RSS, 2013.
6.106. J. H. Piater. Learning visual features to predict hand orientations. In ICML, 2002.
6.107. D. Bowers and R. Lumia. Manipulation of unmodeled objects using intelligent
grasping schemes. IEEE Trans Fuzzy Sys, 11(3), 2003.
6.108. A. Morales, P. J. Sanz, and Angel P. del Pobil. Vision-based computation of `
three-finger grasps on unknown planar objects. In IROS, 2002.
6.109. P. Viola and M. Jones. Rapid object detection using a boosted cascade of simple
features. In CVPR, 2001.
6.110. R. Socher, B. Huval, B. Bhat, C. D. Manning, and A. Y. Ng.
Convolutionalrecursive deep learning for 3D object classification. In NIPS, 201.
CNN Rețele neuronale cu straturi convoluționale
DNN Deep Neural Networks - Rețelele neuronale profunde
GPGPU General Purpose Graphical Processing Units
Q-Learning Q-Learning este o tehnică de învățare automată care asociază
o utilitate pentru fiecare pereche stare-acțiune
RGB-D Senzori RGB-D pentru cartografierea și localizarea 3D,
planificarea traseului, navigarea autonomă, recunoașterea
obiectelor și urmărirea persoanelor
RMSProp Root Mean Square Propagation (propagarea rădăcinii medii
pătratice) - Algoritm de optimizare pentru rețelele neuronale
LIDAR Laser imaging, detection, and ranging
GPGPU General Purpose Graphical Processing Units
SLAM Simultaneous Localization and Mapping
Tensorflow Platformă open source end-to-end pentru învățarea automată

Inteligenta Artificiala

Î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

Inteligenta Artificiala

Încărcat de

Drepturi de autor:

Formate disponibile

INGINERIE SOFTWARE

ȘI TEHNICI DE INTELIGENȚĂ ARTIFICIALĂ

Cercetător științific gr. 1

Seria „Inteligență artificială”

Editura AGIR este recunoscută de CNCSIS

Descrierea CIP a Bibliotecii Naţionale a României

Îngrijire editorială: ing. Dan Bogdan

Bun de tipar: 20.12.2021

Iustin PRIESCU este conf. univ. dr. ing. la Universitatea

Dan-Laurențiu GRECU este este lector univ.dr.ing. la

Violeta-Nicoleta OPRIȘ este asistent univ drd. la

În ziua de azi, ne aflăm în plin avânt de dezvoltare a ingineriei software cu

București, 20 decembrie 2021

Ingineria Software și Inteligența Artificială sunt două domenii, care în zilele

soluțiilor, împreună cu algoritmii asociați, cum ar fi: căutarea în lățime,

1.7.3 Librăria numerică................................................................ 57

2.2 Inteligența artificială distribuită .................................................. 107

4. CUNOAȘTERE ȘI RAȚIONAMENTE ..................................................... 181

4.8.2 Recunoașterea obiectelor și ancorarea simbolurilor ....... 231

Abrevieri – Capitolul 6 ........................................................................ 297

Termenul de inginerie software1, a fost utilizat prima dată, în anul 1968, la o

• capacitatea de a insera și modifica alte materiale non-textuale;

Fig. 1.1 Exemplu de sistem complex de interconectare.

Fig. 1.2 Un sistem de interconectare conceptual mai simplu.

Software-ul de procesare al textului trebuie să adere la o interfață specificată

interacționeaze cu un software existent. Abordarea sistematică a unei probleme de

1.1 Obiectivele Ingineriei Software

Organizațiile implicate în producerea de software au un interes puternic în a

Reutilizare - software-urile pot fi utilizate din nou în alte proiecte. Aceasta

1.2 Paradigme de dezvoltare a sistemelor software

O paradigmă este un exemplu sau model care poate fi copiat. Paradigmele

organizează soluția. Pentru a dezvolta sisteme software mari și complexe,

Fig. 1.3 Patru paradigme de dezvoltare software

1.2.1. Paradigma procedurală

Paradigma procedurală se concentrează pe algoritmii sau pașii necesari pentru

arborii ei de descompunere asociați duc adesea la date globale și funcții cuplate

Fig. 1.4 Paradigma procedurală de dezvoltare software

1.2.2. Paradigma bazată pe date

Paradigma bazată pe date presupune un element dintr-o diagramă a fluxului

pe o descompunere procedurală. Mai mult, modelele problemei create în timpul

Fig. 1.5 Paradigma de dezvoltare software bazată pe date

1.2.3. Paradigma orientată pe obiecte

Paradigma orientată obiect (Fig. 1.6) încapsulează datele și procedurile sau

Fig. 1.6 Paradigma de dezvoltare software orientată pe obiecte

Abilitatea paradigmei orientate pe obiecte de a acoperi decalajele dintre faze și

1.3 Introducere în UML

Unified Modeling Language (UML) este un limbaj vizual pentru

Fig. 1.7 Ierarhia diagramelor conform UML

I. Conceptele orientate pe obiecte utilizate în UML:

astfel încât, sistemul se poate construi bucată cu bucată. Un obiect este

▪ diagrama de implementare - este folosită pentru a reprezenta hardware-ul

▪ diagrama de comunicare - este utilizată pentru a afișa mesaje secvențiale

Model Independent de Platformă (PIM - Platform Independent Model), iar modelul

1.4 Introducere în SysML

Limbajul de Modelare al Sistemelor (Systems Modeling Language –

Fig. 1.8 Taxonomia diagramelor SysML și comparația sa cu UML

1.4.1. Abordarea modelării

Progresul abordării bazate pe model este prezentat prin adoptarea limbajului

Adoptarea unei abordări bazate pe model pentru a face modelele de robot

pentru fiecare proces de proiectare, de la analiza funcțională de bază a

1.4.3. Procesul de modelare

Activitatea de modelare constă în Fig. 1.9:

Fig. 1.9 Procesul general de proiectare și fluxurile de lucru de modelare.

1.5 Cicluri de viață software