desenvolvimento e análise de comportamentos relacionais ......petri estocásticas generalizadas...

Desenvolvimento e Análise de ComportamentosRelacionais em Robots Futebolistas

Artur Manuel Costa Pinto Prego de Faria

Dissertação para obtenção do Grau de Mestre emEngenharia Electrotécnica e de Computadores

Júri

Presidente: Carlos J. F. Silvestre

Orientador: Pedro M. U. A. Lima

Vogais: Rodrigo M. M. Ventura

Setembro de 2008

Agradecimentos

Há muitas pessoas a quem tenho que agradecer, não só pelo eu académico, mas principalmente

pelo eu pessoal.

Em primeiro lugar agradeço ao professor Pedro Lima, por me ter dado a oportunidade de

poder contactar com a realidade do futeból robótico, pela disponibilidade que demonstrou sempre

que eu tinha dúvidas e por me ter orientado ao longo desta tese.

Agradeço aos membros da equipa SocRob, por estarem sempre dispostos a ajudar e pelo

companheirismo que demonstraram no tempo em que convivi convosco. Espero sinceramente

que tenham muito sucesso na vida pós-IST.

A todos os amigos que fiz em Lisboa. São todos muitos importantes para mim e tornaram a

minha adaptação a esta cidade muito mais fácil, tanto que já adopto como quase minha.

A todos os meus amigos de Guimarães. São uma das minhas grandes pedras basilares, e

que me ajudaram a tornar quem sou. Vivemos muitas aventuras juntos, e sei que iremos viver

muitas mais. Estamos na maior parte das vezes distantes, mas quando me torno a encontrar

convosco, é que se nunca tivesse saído dessa maravilhosa cidade.

À minha Joana. Por todo o teu amor, carinho, ajuda, companheirismo... e sobretudo paciên-

cia!! Fazes parte da minha vida e és muito especial para mim.

À minha família. Fizeram e continuam a fazer de mim quem sou. São acima de tudo um

excelente exemplo a seguir, e serão sempre, todos vocês, meus mentores, dos mais velhos aos

mais jovens. Não queria particularizar neste ponto, mas terá que ser: à minha madrinha, por

todo o amor e carinho que sempre me deu. À minha avó, pela sabedoria das suas palavras e

ensinamentos. Aos meus irmão e meus pais, por terem sempre um exemplo a seguir por mim,

por me ter ajudado a fazer as escolhas certas, por tudo o que me ensinaram, por serem sempre

meus amigos, por serem tudo o que são.

i

Resumo

O objectivo desta tese foi, tendo como base trabalhos anteriores, criar, desenvolver e tes-

tar comportamentos relacionais entre robots futebolistas no âmbito do projecto SocRob. Os

comportamentos foram modelados através de Redes de Petri e foi criado um novo modelo de

Redes de Petri derivado de modelos anteriores, que permite simplificar o projecto de novos

comportamentos relacionais. Passes dinâmicos foram introduzidos no projecto pela primeira

vez.

Foram desenvolvidos dois tipos de passes dinâmicos, passe curto e passe longo, e foi mel-

horado o comportamento individual de um robot apoiante, de modo a poder retirar mais vanta-

gens dos dois passes. Estes comportamentos foram testados num simulador, e demostrados

em robots reais.

Foi feita uma análise qualitativa das Redes de Petri desenvolvidas, e uma análise quantita-

tiva, através de Cadeias de Markov, de resultados obtidos do simulador.

Palavras Chave: Futebol Robótico, Redes de Petri, Comportamentos Relacionais, Análise

Qualitativa, Análise Quantitativa

iii

Abstract

The goal of this thesis was, supported by previous works in the area, to create, develop and

test cooperative behaviors between soccer robots within the SocRob project. The modelling of

the behaviors was based on Petri Nets and a new model of Petri Nets was introduced, based

on previous works, in order to ease the creation of new cooperative behaviors. Dynamic passes

between robots were introduced for the first time in the project.

Two kinds of dynamic passes were developed, short pass and long pass, and the individual

behavior of the supporting robot was improved, in order to take more advantage of the two

passes. This behaviors were tested in a simulator, and demonstrated using real robots.

A qualitative analyze of the developed Petri Nets was made, as well as a quantitative analyze

of the results obtained using the simulator, using Markov Chains.

KeyWords: Robotic Soccer, Petri Nets, Relacional Behaviors, Qualitative Analysis, Quanti-

tative Analysis

v

Conteúdo

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Especificação do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Estado da arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Fundamentos Teóricos 3

2.1 Redes de Petri Ordinárias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Definição formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Regra de Disparo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.3 Exemplo ilustrativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Redes de Petri Estocásticas Generalizadas . . . . . . . . . . . . . . . . . . . . . . 5


2.2.2 Exemplos ilustrativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Planos robóticos representados por Redes de Petri . . . . . . . . . . . . . . . . . . 8

2.4 Teoria dos Compromissos Conjuntos . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


2.5 Comportamentos Relacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 Estabelecimento do compromisso . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.2 Gestão do compromisso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.3 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.4 Sincronização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

vii

3 Implementação 19

3.1 Projecto SocRob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Redes de Petri no SocRob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Porquê Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.2 Execução e nomenclaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.3 Níveis das redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Implementação de novos comportamentos . . . . . . . . . . . . . . . . . . . . . . 25

4 Desenvolvimento de Comportamentos Relacionais 27

4.1 Comportamentos anteriormente desenvolvidos . . . . . . . . . . . . . . . . . . . . 27

4.2 Finalização do desenvolvimento do passe estático . . . . . . . . . . . . . . . . . . 28

4.3 Desenvolvimento de Passes Dinâmicos . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1 Algoritmo de implementação . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.2 Modelos de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.3 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Motivação de desenvolvimento de passes dinâmicos . . . . . . . . . . . . . . . . . 37

4.5 LongPass - Comportamento Relacional Passe Longo . . . . . . . . . . . . . . . . 37

4.5.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5.2 Situação prevista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5.3 Comportamentos desenvolvidos . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5.4 Gestores de compromisso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6 ShortPass - Comportamento Relacional Passe Curto . . . . . . . . . . . . . . . . 41

4.6.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6.2 Situação prevista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

viii

4.6.3 Comportamentos desenvolvidos . . . . . . . . . . . . . . . . . . . . . . . . 42

4.6.4 Gestores de compromisso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.7 BehaviorBaseSupport - Comportamento Individual Apoiante . . . . . . . . . . . . 45

4.7.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.7.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Resultados 48

6 Análise dos Comportamentos 49

6.1 Propriedades das Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Análise Qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2.1 BehaviorBaseSupport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2.2 RoleSupporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2.3 BehaviorLongPassTaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3 Análise do Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3.2 Cadeias de Markov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3.3 BehaviorBaseSupport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.3.4 BehaviorLongPassTaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.3.5 BehaviorShortPassTaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7 Conclusões e trabalho futuro 65

8 Bibliografia 67

A Redes de Petri dos Comportamentos Desenvolvidos 69

A.1 RoleAttacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

ix

A.2 RoleSupporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.3 BehaviorBaseSupport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.4 BehaviorLongPassTaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A.5 BehaviorLongPassReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.6 BehaviorShortPassTaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.7 BehaviorShortPassReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A.8 TakePass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.9 CatchAndDribble2Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.10 AttackerShortPassCommitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A.11 SupporterShortPassCommitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.12 AttackerLongPassCommitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.13 SupporterLongPassCommitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

x

Lista de Figuras

1 Antes de disparo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Depois de disparo de T1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Rede com transições imediatas e estocásticas . . . . . . . . . . . . . . . . . . . . 7

4 Rede com transições estocásticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Rede com transições imediatas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6 Plano robótico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

7 Gestores compromisso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

8 Gestores compromisso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

9 Exemplo sincronização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

10 MeRMaID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

11 Robot que envia pedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

12 Robot que envia aceitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

13 Rede original, e duas redes redesenhadas . . . . . . . . . . . . . . . . . . . . . . 50

14 BehaviorBaseSupport - Grafo de alcance . . . . . . . . . . . . . . . . . . . . . . . 52

15 RoleSupporter - Grafo de alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

16 BehaviorLongPassTaker - Grafo de alcance . . . . . . . . . . . . . . . . . . . . . . 56

17 Modelação LongPassTaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

xi

1 Introdução

1.1 Motivação

Todos os anos é realizada uma competição internacional, organizada pela RoboCup Federation 1,

onde várias equipas disputam entre si diferentes tarefas robóticas, incluindo o futebol. O grande

objectivo do RoboCup é que em 2050 exista uma equipa de robots humanóides autónomos

que possam disputar e vencer um jogo de futebol com a equipa vencedora do Campeonato

Mundial da FIFA, com as regras do futebol disputado por humanos [14]. Para tal, todos os anos

a RoboCup Federation altera as regras, de modo a torná-las cada vez mais semelhantes aos

do futebol humano, o que por si só acelera também os processos de desenvolvimento de novas

tecnologias e algoritmos.

Esta tese surge de modo a desenvolver novos comportamentos relacionais numa equipa de

robots futebolistas através de modelação e programação baseada em Redes de Petri, dando con-

tinuidade a trabalhos anteriores, e enquadra-se no âmbito de um projecto do ISR / IST denomi-

nado por SocRob, acrónimo de Society of Robots ou Soccer Robots, que tem como finalidade o

estudo de equipas de múltiplos robots, neste caso de robots futebolistas.

1.2 Especificação do problema

Em trabalhos anteriores foram desenvolvidos, para a equipa de robots futebolistas da classe

Middle Size League do projecto SocRob, comportamentos organizacionais, individuais e rela-

cionais. Estes últimos debruçavam-se sobre a execução de um passe estático (na marcação

de faltas) entre dois robots. No entanto, o desenvolvimento de passes dinâmicos (com o jogo a

decorrer) ainda não havia sido implementado. Esta tese surge com o intuito de desenvolver uma

metodologia em Redes de Petri derivada de anteriores introduzidas em [2] e [3], de modo a poder

implementar passes dinâmicos entre dois robots futebolistas.

Nesta dissertação, no Capítulo 2 serão explicados os conceitos teóricos aplicados na res-

olução deste problema, nomeadamente Redes de Petri, Teoria dos Compromissos Conjuntos e

metodologias e algoritmos introduzidos em dissertações anteriores. No Capítulo 3 será especifi-

cado o ambiente em que são desenvolvidos os comportamentos, e no Capítulo 4 será explicada

a implementação de passes dinâmicos, no caso desta tese passe curto e passe longo, e será

1http://www.robocup.org/

1

descrito qual o novo comportamento individual para os robots apoiantes do atacante. A análise

dos comportamentos desenvolvidos, qualitativo através das propriedades das Redes de Petri e

quantitativo através de Cadeias de Markov, será feita no Capítulo 6. A dissertação terminca com

as conclusões e contributo do trabalho desenvolvido no Capítulo 7, onde também são dadas

sugestões sobre trabalho futuro.

1.3 Estado da arte

Os robots futebolistas têm de utilizar diferentes componentes e software durante um jogo. Desde

reconhecimento de padrões (formato da bola, da baliza) passando pela navegação até à tomada

de decisões de cada robot inserido na equipa. Esta dissertação de mestrado enquadra-se neste

último ponto, onde é suposto os robots actuarem em conformidade com o estado do mundo e

com informações recebidas dos robots da mesma equipa e da arbitragem. A tecnologia utilizada

nesta dissertação, inserida na equipa de Middle Size League do projecto SocRob são Redes de

Petri.

As Redes de Petri são uma ferramenta de modelação gráfica e matemática. Como ferramenta

gráfica podem ser utilizadas para descrever um determinado sistema, tal como um fluxograma.

Nesta dissertação serão utilizadas as suas propriedades gráficas para descrever certos protoco-

los (ver capítulo 2.5).

Como ferramenta matemática podem ser utilizadas para efectuar simulações de sistemas,

tal como em [16] onde são utilizadas para modelar e simular redes metabólicas em tecnologia

bio-informática, ou utilizadas como agente modelador de determinado sistema, tal como nesta

dissertação e em [18], onde são utilizadas para planear uma tarefa de navegação de um robot

guia, ou para analisar o desempenho de determinado sistema, tal como em [15].

As Redes de Petri Ordinárias, introduzidas por por Carl Adam Petri no ano de 1962, foram

sofrendo alterações desde o seu surgimento. Nesta dissertação serão utilizadas Redes de Petri

Ordinárias para modelar comportamentos cooperativos entre os robots futebolistas e Redes de

Petri Estocásticas Generalizadas para analisar quantitativamente esses comportamentos.

Existem também outras evoluções de Redes de Petri, utilizadas nas situações apropriadas,

tais como Redes de Petri Híbridas ou Redes de Petri Coloridas, de referir, [17] ou [19].

2

2 Fundamentos Teóricos

2.1 Redes de Petri Ordinárias

O conceito de Redes de Petri foi introduzido por Carl Adam Petri em 1962. São uma ferramenta

gráfica e matemática, que permite descrever e estudar sistemas que são concorrentes, assín-

cronos, distribuídos, paralelos, não determinísticos, e/ou estocásticos.

Como ferramenta gráfica podem ser utilizadas como um auxiliar semelhante a diagramas

de blocos, fluxogramas ou máquinas de estados. São úteis para quando se quer descrever ou

analisar a evolução de um sistema dinâmico de eventos discretos. Ao longo desta dissertação

será usada esta capacidade de modo a poder descrever protocolos utilizados.

Como ferramenta matemática, podem ser utilizadas para extrair um sistema de equações

algébricas, ou outros modelos matemáticos, que permitem a análise do sistema modelado pela

Rede de Petri.

2.1.1 Definição formal

Em [8] é apresentada uma definição formal das Redes de Petri. Formalmente, as Redes de Petri

são um quíntuplo PN = (P, T,A,w,M0), onde:

• P = (p1, p2, . . . , pn) - representa o conjunto finito de lugares;

• T = (t1, t2, . . . , tn) - representa o conjunto finito de transições;

• A ⊂ (P x T ) ∪ (T x P ) - representa o conjunto de arcos de lugares para transições, e de

transições para lugares;

• w : A→ N - função de pesos associados a cada arco de P para T;

• M0 - marcação inicial do conjunto de lugares da rede.

2.1.2 Regra de Disparo

As redes evoluem de acordo com a regra de transição, ou regra de disparo. Esta regra é com-

posta pelos três seguintes passos consecutivos:

3

1. Uma transição encontra-se pronta a disparar, ou activa, se todos os seus lugares de en-

trada estiverem marcados com pelo menos w(p, t) tokens, em que w(p, t) denota o peso

associado ao arco dos lugares para a transição. No caso em que o arco não tem indicado

qual o peso associado, significa que o seu peso é de 1;

2. Se o evento associado à transição ocorrer, e se a condição acima referida é cumprida, a

transição dispara. Notar que esta regra não se aplica na definição original das Redes de

Petri, mas apenas quando se está a modelar um sistema de eventos discretos, tal como

nesta dissertação.

3. São então removidos w(p, t) tokens dos lugares de entrada de transição, e adicionados

w(t, p) tokens a cada lugar de saída da transição. No caso em que o arco não tem indicado

qual o peso associado, significa que o seu peso é de 1;

2.1.3 Exemplo ilustrativo

Nas figuras seguintes está ilustrado o exemplo do disparo de uma transição de uma Rede de

Petri. No caso da Figura 1 podemos ver que todos os lugares de entrada da transição T1, P0

e P1, estão marcados com um token, o que significa que esta transição se encontra pronta a

disparar. A transição T0 também se encontra pronta a disparar, visto que não tem qualquer lugar

de entrada, o que leva a que a primeira condição da regra de disparo desta transição também

esteja a ser cumprida.

Figura 1: Antes de disparo

Nesta situação:

• P = (P0, P1, P2);

4

• T = (T0, T1, T2);

• A = (P0, T0), (P1, T0), (P2, T2), (T0, P2), (T1, P1), (T2, P2);

• M = (1, 1, 0).

Se o evento associado à transição T1 ocorre, e se ocorrer antes do evento associado à tran-

sição T0, são removidos os tokens dos lugares de entrada, P0 e P1, e adicionados tokens aos

lugares de saída, neste caso P2. A rede evolui para o estado representado pela Figura 2.

Figura 2: Depois de disparo de T1

Nesta situação:

• P = (P0, P1, P2);

• T = (T0, T1, T2);

• A = (P0, T0), (P1, T0), (P2, T2), (T0, P2), (T1, P1), (T2, P2);

• M = (0, 0, 1).

Em [8] é possível obter mais informação sobre Redes de Petri, onde também são apresen-

tadas as suas propriedades, e que análises que podem ser efectuadas(estas duas últimas serão

apresentadas no Capítulo 6).

2.2 Redes de Petri Estocásticas Generalizadas

Sobre uma Rede de Petri é possível efectuar uma análise qualitativa, tal como saber se é possível

chegar a determinada marcação, ou quais as condições para essa marcação ser alcançada. Mas

5

para fazer uma análise quantitativa de determinado sistema, é necessário introduzir uma variante:

Redes de Petri Estocásticas Generalizadas.

É introduzido o conceito de que existem transições imediatas e transições temporizadas com

um atraso estocástico, que representa o tempo que a transição demora a disparar a partir do

momento em que está activa. Este atraso está associado a uma variável aleatória de distribuição

exponencial, com as seguintes características:

• Valor médio = 1µ ;

• Variância = 1µ2 ;

• Função de densidade de probabilidade = µe−µt .

Os eventos que podem ocorrer no ambiente do futebol robótico podem ser aproximados a

transições que ocorrem associadas a uma variável aleatória de distribuição exponencial, o que

permite que possam ser efectuadas análises qualitativas à Rede de Petri, aproximando-as a uma

Cadeia de Markov. Esta análise será desenvolvida no Capítulo 6.3.

Como o nome indica, as transições imediatas disparam no instante em que se encontram

prontas a disparar. No caso em que existem mais que uma transição imediata pronta a disparar

existe um conflito, pois apenas uma pode disparar. De modo a poder lidar com esta situação

existe um conjunto de Random Switches (interruptores aleatórios), que determina, quando existe

uma situação de conflito entre transições imediatas, qual deve disparar.


Em [9] é apresentada uma definição formal das Redes de Petri Estocásticas Generalizadas.

Formalmente, são um oito-tuplo, PN = (P, T,A,w,M0, F, S) , onde:

• P = (p1, p2, . . . , pn) - representa o conjunto finito de lugares;

• T = (TE, TI) - representa o conjunto finito de transições, que podem ser imediatas (TI)

ou com atraso estocástico (TE);

• A ⊂ (P x T ) ∪ (T x P ) - representa o conjunto de arcos de lugares para transições e de

transições para lugares;

6

• w : A→ N - função de pesos associados a cada arco;

• M0 - marcação inicial do conjunto de lugares da rede;

• F - função do conjunto de transições exponenciais para um conjunto de números reais

F(TEj) = µj, onde µj é a taxa de disparo da transição temporizada exponencial TEj;

• S - conjunto de Random Switches que resolve as situações de conflito entre transições

imediatas.

2.2.2 Exemplos ilustrativos

Observe-se as situações ilustradas nas figuras seguintes, onde estão representados os difer-

entes tipos de conflitos que podem ocorrer numa Rede de Petri Estocástica Generalizada.

Na Figura 3, estão prontas a disparar uma transição imediata (preenchidas a preto), e uma

transição estocástica (preenchidas a branco). Neste caso a transição que dispara é a imediata.

Figura 3: Rede com transições imediatas e estocásticas

Na Figura 4, estão prontas a disparar duas transições estocásticas, onde poderá disparar a

transição T0 ou T1. Neste caso, dispara em média mais vezes a que demora menos tempo a

disparar, dependendo do conjunto F .

Na Figura 5 estão prontas a disparar duas transições imediatas. Nesta situação, o conflito é

resolvido através do conjunto S, conjunto dos RandomSwitches, onde é determinada que tran-

sição deve disparar do conjunto total de transições imediatas activas, neste caso, T0 e T1.

7

Figura 4: Rede com transições estocásticas

Figura 5: Rede com transições imediatas

2.3 Planos robóticos representados por Redes de Petri

Em [12] é apresentado um formalismo de modelação de tarefas robóticas em Redes de Petri, as

quais devem consistir em diferentes camadas, com diferentes graus de abstracção.

São introduzidos os lugares de predicado, que consistem numa avaliação lógica, com valor

verdadeiro ou falso. Um lugar predicado numa Rede de Petri está marcado quando o valor da

avaliação lógica é verdadeiro. Por exemplo, o predicado SeeBall está marcado somente quando

o robot consegue ver a bola. É introduzido também o lugar de predicado negado, que está

marcado quando o valor da avaliação lógica é falso. Por exemplo, o predicado ¬SeeBall está

marcado quando o robot não consegue ver a bola. Este é o nível de menor grau de abstracção

Para cada acção funcionar correctamente, é necessário garantir que estão a ser cumpri-

das pré-condições e condições de execução. Por exemplo, a acção CatchBall tem como pré-

condições SeeBall, e como condição de execução ¬HasBall. É também necessário definir quais

são as condições que ocorrem quando ela termina. A acção CatchBall tem como condições finais

HasBall no caso em que a acção termina com sucesso, e ¬SeeBall ou no caso em que termina

sem sucesso.

8

Por fim, o plano robótico. Consiste numa rede de acções, interligadas através das suas pré-

condições e condições finais. Por exemplo, quando o robot fica na posse da bola, no caso em que

a acção CatchBall termina com sucesso, deve iniciar a acção DribbleToGoal. A condição final da

primeira, HasBall, é a pré-condição da segunda. Este é o nível com maior grau de abstracção.

Como exemplo de plano robótico, observe-se a Rede de Petri representada na Figura 6. É o nível

de maior grau de abstracção.

Figura 6: Plano robótico

2.4 Teoria dos Compromissos Conjuntos

2.4.1 Motivação

Quando um conjunto de agentes se encontra num mesmo ambiente pode ser vantajoso e até

essencial, agir de forma conjunta sobre esse mesmo ambiente. Para tal é necessário introduzir

um conjunto de formalismos e protocolos, de modo a garantir que, durante todo o comportamento

de cada um dos elementos, todos ajam sempre em conformidade uns com os outros e sempre em

cooperação. Em [1], Cohen e Levesque introduzem a Teoria do Compromissos Conjuntos, onde

é definido um formalismo sobre comportamentos relacionais numa equipa de múltiplos agentes.

9

Nesta referência é dado o exemplo de dois condutores na auto-estrada, no qual um necessita do

outro para chegar a determinado local e onde são ilustradas várias situações indesejáveis que

podem acontecer caso não exista um protocolo de compromisso entre ambos, tais como o que

fazer quando deixam de estar ao alcance visual um do outro, ou qual é o destino que cada um

pretende alcançar.


Em [1], são definidos três tipos diferentes de objectivos:

Objectivo persistente:

Um agente tem um objectivo persistente relativo a q para atingir p, se as condições seguintes

se verificarem:

• O agente acredita que p é momentaneamente falso;

• O agente quer que p venha a ser verdadeiro;

• Assume-se como verdade (e o agente sabe disso) que a segunda condição se irá manter

até o agente venha a acreditar que p é verdadeiro, ou que nunca virá a ser verdade, ou que

q é falso.

Portanto, quando um agente adopta um objectivo persistente, este tem de ser falso, e o agente

quer que ele seja verdadeiro. O agente tenta alcançar esse objectivo, até que se verifiquem

condições que indiquem que ele foi alcançado, ou que nunca poderá vir a ser alcançado.

Objectivo de baixa prioridade:

Um agente terá um objectivo de baixa prioridade relativo a q e respeitante a uma equipa que

acredita em p se as condições seguintes se verificarem:

• O agente tem um objectivo normal de modo a acreditar p, isto é, o agente ainda não acredita

que p é verdadeiro mas tem p como um objectivo que se virá a tornar verdadeiro;

• O agente acredita que p é verdadeiro, nunca será verdadeiro, ou é irrelevante (ou seja, q é

falso), mas tem um objectivo que lhe diz que o estado de p é acreditado conjuntamente por

todos os membros da equipa.

10

Neste caso o objectivo é relativo também a outros agentes. O agente acredita que os outros

agentes envolvidos acreditam de igual modo no mesmo objectivo p.

Objectivo persistente relacional:

Uma equipa de agentes tem um objectivo persistente relacional relativo a q para atingir p no

caso de:

• Todos acreditarem que p é momentaneamente falso;

• Todos quererem que p venha a ser verdadeiro;

• Ser verdade (e ser conhecimento comum) que até todos concordarem que p é verdadeiro,

ou que p nunca vai ser verdadeiro, ou que q é falso, todos os agentes irão continuar a

acreditar que cada um deles tem um objectivo de baixa prioridade relativo a q e respeitante

a toda a equipa.

Este objectivo é também relativo a uma equipa de agentes. A diferença principal entre o

objectivo de baixa prioridade e o objectivo persistente relacional, é que num objectivo persistente

relacional é conhecimento comum que todos os agentes envolvidos acreditam nesse objectivo.

2.5 Comportamentos Relacionais

Um comportamento relacional tem lugar quando dois ou mais robots agem em cooperação na

execução de determinado comportamento, de modo a poderem alcançar um objectivo comum

a ambos. De seguida são apresentados os passos e os protocolos que são seguidos no inicio,

durante, e no final de um comportamento relacional.

2.5.1 Estabelecimento do compromisso

Como se pode calcular, um aspecto fundamental para a realização de um comportamento rela-

cional é a comunicação entre os robots. Em [2] e [3] foi definido um protocolo de comunicação

a utilizar. Na descrição deste protocolo, os robots são denominados por R1 e R2, acrónimos de

robot1 e robot2.

O protocolo é composto pelos seguintes passos:

11

1. R1 envia um pedido aos outros robots da sua equipa indicando que pretende realizar um

determinado comportamento relacional e que para tal necessita de um parceiro. O robot

avança para um estado em que aguarda respostas dos seus colegas de equipa, durante

um determinado intervalo de tempo;

2. Na presença de um pedido de compromisso, R2 analisa se tem condições para efectuar o

compromisso em questão, e caso isso seja verdade, envia uma mensagem a R1 indicando

que está em condições de entrar em compromisso;

3. Quando o intervalo de tempo referido em 1 expira, R1 verifica se houve respostas recebidas

dos seus colegas de equipa. Em caso afirmativo, avança para um novo estado onde analisa

as respostas. Em caso de não ter recebido respostas, dá por encerrada a tentativa de

estabelecimento do compromisso;

4. Caso tenha obtido respostas válidas por parte dos seus parceiros, R1 escolhe a mais ad-

equada para o comportamento que pretende realizar. É enviada uma mensagem de Con-

firmação ao parceiro seleccionado (R2) e uma mensagem de Rejeição aos rejeitados. R1

avança para o estado em que aguarda por uma mensagem de R2 indicando que estabele-

ceu com sucesso o compromisso.

5. Do lado dos colegas de equipa de R1, uma de duas situações irá ocorrer:

• Recepção de Rejeição: Neste caso o robot dará por terminado o estabelecimento do

compromisso;

• Recepção de Confirmação: Nesta situação, o robot envia uma mensagem de Com-

prometido para o seu parceiro R1, indicando que se encontra comprometido a realizar

o comportamento em questão.

6. R1 espera, durante um determinado intervalo de tempo, pela mensagem de Comprometido

de R2. Caso esta não chegue durante esse intervalo de tempo, R1 cancela o compromisso.

No caso de recepção da mensagem de Comprometido por parte de R2, R1 envia como

resposta uma mensagem de Comprometido e avança para o estado R2Comprometido;

7. Por fim, e exactamente do mesmo modo que em R1, R2 aguarda durante um intervalo

de tempo fixo, pela mensagem de Comprometido de R1. Caso esta chegue nesse inter-

valo de tempo R2 avança para o estado R1Comprometido, caso contrário, termina o seu

compromisso, e envia mensagens a R1 de que não está Comprometido.

12

Os temporizadores referidos no ponto 3, 5 e 6 e 7 são utilizados de forma a poder evitar

situações de deadlock que poderiam surgir. Por exemplo, caso R2 esteja no ponto 5, à espera

da mensagem de Confirmação ou Rejeição, e caso o suporte de comunicação deixe de poder ser

utilizável, sem o uso de um temporizador o R2 ficaria eternamente à espera de uma mensagem

de R1.

Após a execução deste protocolo, caso ambos os robots tenham chegado a um estado em

que estão comprometidos, e em que têm informação de que o outro robot está comprometido,

poderão iniciar um comportamento relacional. Este protocolo de comunicação foi implementado

numa equipa de robots futebolista com sucesso, em comportamentos relacionais na marcação

de faltas, resultando num passe estático entre dois robots, nas dissertações [3] e [2].

No entanto, para a realização de passes dinâmicos foram necessárias introduzir as seguintes

diferenças neste protocolo:

• Remoção dos temporizadores existentes nos pontos 1 e 3. Isto permite que R1 possa

ficar na situação em que enviou pedido de compromisso, desde que as condições para o

efectuar continuem favoráveis.

• Durante todo o processo de estabelecimento do compromisso ambos os robots continuam

a efectuar os comportamentos individuais anteriores ao inicio do processo;

• Não existe envio de mensagens de Confirmação. As mensagens de Rejeição são enviadas

no mesmo passo que o envio das mensagens de Comprometido.

2.5.2 Gestão do compromisso

Após o estabelecimento do compromisso e inicio do comportamento relacional, é necessário

garantir o funcionamento correcto de ambos. Como se pode recordar da Secção 2.4, um robot

deve abandonar o comportamento quando o objectivo é alcançado, ou quando é impossível de

alcançar. Na gestão de compromisso é necessário garantir que estas condições são verificadas.

Para tal são utilizados gestores de compromisso.

De modo a poder ilustrar o seu funcionamento, observe-se a Rede de Petri 7.

13

Figura 7: Gestores compromisso

No caso da rede apresentada os gestores de compromisso são:

• Commitment<NomeParceiro> - quando este lugar tem um token, significa que o robot com

o qual se está a realizar um comportamento relacional está comprometido;

• EndCommitment<MeuNome> - quando este lugar tem um token, significa que o robot não

tem condições para continuar o compromisso. Ao terminar o compromisso, irá alterar o

valor do lugar commited para NotCommited ;

• NotCommited<NomeParceiro> - quando este lugar tem um token, significa que o robot

com o qual se está a realizar um comportamento relacional não está comprometido, e caso

o robot esteja a realizar uma acção pertencente ao comportamento relacional ele deve

termina-la, terminando também o compromisso.

Para diferentes tipos de comportamentos relacionais podem existir diferentes tipos de proto-

colos e gestores de compromisso. Por exemplo, num caso em que se está a realizar um com-

portamento relacional entre três robots, e um deles enviar mensagem de que não está compro-

metido, em vez dos outros dois terminarem o comportamento relacional e o compromisso, podem

continuar um compromisso entre eles, executando diferentes acções das estipuladas para três

elementos, se tal for possível no comportamento relacional que estavam a efectuar.

14

2.5.3 Comunicação

Na Rede de Petri da Figura 7, estão representados dois robots, R1 e R2. Como se tratam de

robots autónomos, é necessário separar a rede em duas, em que cada uma representa um dos

robots, tal como está representado nas Redes de Petri da Figura 8. A rede da Figura 7 só seria

válida na situação em que ambos os robots estão a executar uma rede comum, mas nesse caso

eles não seriam autónomos.

Figura 8: Gestores compromisso

A transição <NomeParceiro>StoppedCommitment dispara quando é lançado o evento com

o mesmo nome, quando o robot parceiro em questão termina o seu compromisso, e repre-

senta uma comunicação feita por um robot para outro indicando que terminou o compromisso.

Por exemplo, quando R1 tem um token no lugar EndCommitmentR1, deverá ser lançado o

evento R1StoppedCommitment da rede de R2, garantido através de um suporte de comunicação.

Através dos gestores de compromisso e método de comunicação acima descritos é possível gerir

um compromisso entre dois robots autónomos.

No caso descrito, um robot sabe qual o estado do outro através de mensagens que este

lhe envia. Se, por exemplo, um robot quiser obter informação de onde o outro está, a única

maneira de o saber é através de mensagens comunicadas entre eles. Este tipo de comunicação

é denominada por explícita, porque requer que ambos os robots transmitam mensagens entre

15

eles para estarem informados sobre o estado em que se encontra o outro.

Por oposição existe também comunicação implícita. A principal diferença para a explícita, é

que neste caso a avaliação feita do estado de outros robots, é através de observações feitas por

ele, sem haver qualquer outro suporte de comunicações. Por exemplo, no caso acima referido,

um robot saberia onde o outro está utilizando apenas uma câmara e utilizando algoritmos de pro-

cessamento de imagem e visão. Na actualidade este tipo de abordagem é ainda muito limitada,

mas com o evoluir da tecnologia e dos protocolos de comunicação, espera-se que possa vir a ser

implementada no futuro.

2.5.4 Sincronização

Outro aspecto a ter em conta durante a realização de uma tarefa cooperativa, é a sincronização

entre os robots. A sincronização é necessária de modo a garantir que os robots estão a executar

tarefas em consonância entre eles. Para tal observe-se a rede da figura 9.

Figura 9: Exemplo sincronização

Como se pode verificar, para R1 executar a acção Pa1 necessita de saber que R2 terminou

a acção Pa2. Por sua vez, após terminar Pa2, R2 ficará num estado onde espera que R1 lhe

comunique que terminou Pa1 de modo a poder terminar o seu comportamento. Os lugares R2

16

Finished Pa2 e R1 Finished Pa1 garantem que a sincronização está a ser cumprida.

Sem assegurar esta sincronização, os resultados dos comportamentos relacionais não seriam

os desejados. Imagine-se o caso de transporte conjunto do móvel. Se os robots não tiverem a

desempenhar a tarefa em sincronização, dificilmente a será cumprida com sucesso. Por exemplo,

caso um robot não espere pelo outro para carregar o móvel, antes de ter informação de que o

outro está pronto para o carregar, um deles irá começar a transportar o móvel sozinho, o que

poderá danificar o móvel, ou o robot.

2.5.5 Conclusão

Conclui-se que através dos protocolos descritos é possível implementar a execução de compor-

tamentos relacionais entre robots autónomos, bastando para isso assegurar:

• Correcto estabelecimento de compromisso, através de um protocolo e avaliações do estado

do mundo adequados;

• Correcta manutenção de compromisso através de gestores de compromisso, também eles

adequados à tarefa;

• Suporte de comunicação fiável entre os robots;

• Actuação sincronizada entre os robots.

17

3 Implementação

3.1 Projecto SocRob

O projecto SocRob 2(acrónimo de Sociedade de Robots ou Soccer Robots) teve o seu inicio em

1997 e tem como finalidade o estudo e a investigação em robótica cooperativa (na qual esta

tese está inserida), ensino de Engenharia Electrotécnica a estudantes do ensino superior e di-

vulgação de ciência e tecnologia. A investigação neste domínio é importante em problemas de

maior impacto social onde a robótica pode ter um papel decisivo, tais como o socorro a sobre-

viventes de catástrofes (um projecto do ISR/IST nesta área, com o apoio da Fundação para a

Ciência e a Tecnologia, decorre desde 2000 e faz parte de um dos temas do Laboratório Associ-

ado), detecção de fogos em florestas, transporte de objectos de grandes dimensões, indústria e

construção civil.

Desde 1998 o SocRob tem participado regularmente num encontro científico internacional

denominado de RoboCup. No encontro, que engloba um conjunto de conferências e uma com-

petição entre equipas de robots móveis, investigadores das áreas de Inteligência Artificial e

Robótica apresentam o seu trabalho em Robótica Cooperativa e Sistemas Multi-Agente, sendo

a sua aplicação em robots futebolistas um tema motivador. Investigadores internacionais partic-

ipam regularmente nesta reunião, sendo presentemente organizada por um conjunto de investi-

gadores ligados a universidades e empresas internacionais de nomeada, através da Federação

Internacional RoboCup.

Desde 2004, o projecto é financiado pela FCT, no âmbito do programa de apoio a projectos

de equipas portuguesas participantes no RoboCup2004, tendo sido construídos 5 novos robots

omnidireccionais, inteiramente concebidos, desenhados e implementados em Portugal.

A equipa do IST tem sido constituída por professores e alunos de Doutoramento, Mestrado e

Licenciatura do IST. O projecto goza de prestígio junto da Federação RoboCup, sendo o respon-

sável pela equipa do ISR/IST, professor Pedro Lima, seu Trustee, bem como junto do governo

português, que decidiu apoiar a realização da edição do RoboCup2004 em Lisboa, simultanea-

mente com o Europeu de Futebol de 2004.

2http://socrob.isr.ist.utl.pt/

19

3.2 Plataforma

Em [4] e [5] foi desenvolvida a MeRMaID (Multiple-Robot Middleware for Intelligent Decisionmak-

ing), uma arquitectura com a finalidade de facilitar a implementação de novos comportamentos

robóticos. Isto foi conseguido através de integração de middleware que permite aos investi-

gadores abstrair-se dos detalhes de mais baixo-nível.

A arquitectura é descrita através do diagrama 10.

Figura 10: MeRMaID

A MeRMaID é constituída por quatro blocos distintos:

• Atlas : Bloco onde é gerida a interacção do robot com o ambiente em redor. É dividido nos

seguintes sub-blocos:

– Devices: Hardware básico de interacção com o ambiente, tanto de acção como de

percepção (ex: motores, câmara, etc.);

– Sensors : Derivação da informação dos Devices (ex: odometria, posição da bola,

etc.)

20

– Information Fusion : Fusão entre a informação retirada pelos sensores (ex: utilizar

odometria + visão para uma melhor auto-localização);

– Primitive Actions : Acções primitivas dos comportamentos dos robots e que não po-

dem ser decompostas em outras acções. Normalmente consistem em alguns cálculos

e no envio de comandos para os Devices.(Ex: chutar a bola. Seguir a bola);

– Navigation Primitives : Funções de controlo auxiliares das Primitive Actions que

usam a informação da posição inicial e final do robot, dos obstáculos, da bola, etc. De

modo a permitir o robot a deslocar-se correctamente (ex: seguir a bola desviando-se

dos obstáculos).

• Wisdom : Bloco onde estão as informações relevantes sobre o robot e sobre o ambiente.

(ex: robot vê a bola, jogo está parado);

• Cortex : Bloco onde são tomadas as decisões necessárias para que o robot exiba um

comportamento inteligente. Através da informação obtida através do bloco Wisdom executa

os comportamentos e as acções primitivas. Estes comportamentos são modelados em

Redes de Petri ou em máquinas de estados. Está dividido em três níveis de decisão: Team

Organizer, Behavior Coordinator e Behavior Executor ;

• Communication : Bloco que gere a transmissão de mensagens entre robots, e da Refer-

eeBox para os robots.

3.3 Redes de Petri no SocRob

3.3.1 Porquê Redes de Petri

Um sistema de eventos discreto pode ser definido como um sistema dinâmico com espaço de

estados discretos cuja evolução é definida pela ocorrência de eventos assíncronos ao longo do

tempo que alteram o seu estado. As Redes de Petri são uma ferramenta bastante útil para este

tipo de soluções devido às suas capacidades já descritas e devido ao facto de poderem modelar

um sistema de eventos discretos, daí a sua aplicação no projecto SocRob. Em [12] é feita uma

comparação entre Redes de Petri e máquinas de estados (o outro tipo de modelação que se

pode adoptar no projecto SocRob), onde explica que as Redes de Petri permitem uma melhor

modelação, feita através de uma linguagem mais vasta e que torna os comportamentos mais

expressivos para o programador, pois o seu tamanho é graficamente mais reduzido, devido ao

21

facto de se poder distribuir o estado do mundo pelos diferentes lugares, e que permite modelar

sistemas com lugares de entrada e saída, de modo a poderem ser conectados como circuitos.

3.3.2 Execução e nomenclaturas

Como foi referido, é no Cortex que se programam as Redes de Petri. São executadas através

de uma framework desenvolvida na MeRMaID denominada de PetriNetExecutor. De modo a

permitir um correcto funcionamento desta framework, é preciso definir o que deve ser executado

quando um lugar está marcado, e quando se devem disparar as transições. Para tal existe uma

nomenclatura de prefixos para os lugares:

• action - quando um lugar com o prefixo action tem um lugar marcado, significa que está a

ser executada a acção primitiva correspondente ou a Rede de Petri do nível abaixo corre-

spondente. Consoante o nível em que se encontra, as terminologias são diferentes:

– Team Organizer - os lugares com prefixo action têm a seguinte terminologia: ac-

tion.Role{A}. Quando este lugar está marcado, a rede do nível Behavior Coordinator

com nome {A} está a ser executada. As redes deste nível representam a táctica da

equipa;

– Behavior Coordinator - os lugares com prefixo action têm a seguinte terminologia:

action.Behavior{B}. Quando este lugar está marcado, a rede do nível Behavior Execu-

tor com nome {B} está a ser executada. As redes deste nível representam um papel a

ser desempenhado por um robot;

– Behavior Executor - os lugares com prefixo action têm a seguinte terminologia: ac-

tion.{PA}. Quando este lugar está marcado, a acção primitiva com o nome {PA} está a

ser executada. As redes deste nível representam um comportamento que está a ser

desempenhado pelo robot.

• predicate - quando um lugar com o prefixo predicate está marcado, significa que a avali-

ação feita pelo predicado é verdadeira. Por exemplo, se o lugar predicate.SeeBall tem um

token, significa que o robot está a ver a bola. Existe também a possibilidade de um predi-

cado ser verdadeiro quando a avaliação é falsa, através de uma expansão do prefixo para

predicate.NOT_. Por exemplo, se o lugar predicate.NOT_SeeBall tem um token, significa

que o robot não está a ver a bola;

22

Na framework PetriNetExecutor os predicados da Rede de Petri alteram o seu valor inter-

namente, através de uma avaliação feita do estado do mundo, não sendo lugares de saída

de nenhuma transição para além daquela em que são também lugares de entrada. Isto

faz com que no processo de análise da Rede de Petri se tenha o cuidado de representar

também um modelo da dinâmica do meio envolvente dos robots.

De modo a garantir uma correcta execução da rede, é necessário ter em atenção que

quando uma transição tem como lugar de entrada um predicado, tem que ter como lugar

de saída esse mesmo predicado, pois um predicado é apenas testado e não alterado.

• macro - quando um lugar com o prefixo macro está marcado, significa que dentro da rede

em questão está a ser executada também uma outra rede. As macros permitem reduzir a

complexidade das Redes de Petri, facilitando ao utilizador uma análise mais rápida da rede.

Têm dois lugares específicos, GOAL_REACHED e GOAL_NOT_REACHED, que quando

têm um token lançam um evento com o mesmo nome e fazem retornar a rede ao seu

estado inicial. É necessário garantir que a rede em questão onde está a ser executada a

macro tem as transições de saída da macro associadas aos eventos GOAL_REACHED e

GOAL_NOT_REACHED;

• sem prefixo - quando um lugar sem prefixo está marcado, nada é executado. Estes lugares

são utilizados principalmente como memórias internas das redes.

Outra nomenclatura para as transições:

• T# - Este tipo de transições disparam mal estejam activas. Estão geralmente associadas a

alterações de predicados;

• event - Este tipo de transições apenas disparam quando um evento com o mesmo nome é

lançado por um Robot. Por exemplo, a acção SendPassDone lança o evento PASS_DONE,

logo a transição event.PASS_DONE dispara, no caso de estar permitida;

• GOAL_REACHED - Este tipo de transições dispara se a macro associada tiver o lugar

GOAL_REACHED marcado;

• GOAL_NOT_REACHED - Este tipo de transições dispara se a macro associada tiver o

lugar GOAL_NOT_REACHED marcado.

Existe uma característica importante do PetriNetExecutor a ter em conta. Todas as Redes de

Petri do Cortex evoluem ao mesmo tempo, através da variação de predicados, ou ocorrência de

23

eventos. No entanto apenas as redes que estão activas são executadas pelo robot. Isto leva a

que, por exemplo, o robot atacante esteja a executar o comportamento individual de atacante,

que evolui com a rede BehaviorBaseAttack, e que paralelamente a rede BehaviorBaseSupport

também esteja a ser executada pelo PetriNetExecutor. Esta importante característica torna mais

cuidadosa a criação de novas Redes de Petri, pois a execução de certas redes pode levar à

evolução para um certo estado de outras redes. Para evitar esta situação, é necessário adicionar

predicados que permitam que certas redes só possam evoluir quando estão a correr exclusi-

vamente. Embora adicionem alguma redundância, permitem um correcto funcionamento dos

comportamentos.

3.3.3 Níveis das redes

No projecto SocRob as Redes de Petri estão diferenciadas em três níveis: Team Organizer,

Behavior Coordinator e Behavior Executor.

No nível Team Organizer são tomadas as decisões tácticas da equipa. É atribuído a cada

robot um papel (Role) que ele deve executar. Estes papéis podem ser de atacante, apoiante,

defesa, marcador de falta e recebedor de falta. As transições entre os diferentes papéis são es-

colhidas de acordo com a sua posição relativa em campo, com a posição da bola, e se uma bola

parada tem de ser marcada (informação recebida da RefereeBox). Como uma equipa apenas

tem uma táctica, e como se trata do nível mais alto de Redes de Petri do Cortex, apenas uma

rede é executada.

No nível Behavior Coordinator são escolhidos quais os comportamentos (Behaviors) a de-

sempenhar pelo Robot. Este comportamentos podem ser atacar, defender, posicionar-se relati-

vamente à bola, comprometer-se com outro robot, etc. As transições entre os diferentes com-

portamentos são escolhidos em situações específicas do estado do ambiente, que podem ser

definidas através de informações trocadas entre os robots, por exemplo, para passar a bola, ou

através de informações recebidas da RefereeBox, tal como, para parar o jogo ou falta adversária.

No nível Behavior Executor são escolhidas quais as acções primitivas (Primitive Actions)que

o robot deve executar. Estas podem ser seguir a bola, chuta-la, deslocar-se para determinado

local, driblar para outro, etc. As transições entre as diferentes acções primitivas a executar são

escolhidas através de posições relativas dos robots e da bola em campo. Neste nível, a co-

ordenação dos comportamentos com a RefereeBox é muito reduzida. Devem ser os tipos de

comportamento mais básicos que o robot pode desempenhar.

24

3.4 Implementação de novos comportamentos

Em trabalhos de grande volume a utilização de um algoritmo de implementação permite ao pro-

gramador um mais rápido desenvolvimento, e permite a um futuro programador, através do algo-

ritmo de implementação, compreender mais facilmente trabalhos anteriormente desenvolvidos.

Em [2] e [3] foi apresentado um algoritmo de implementação de novas redes, tendo como base

um outro algoritmo desenvolvido em [6], que é apresentado de seguida:

1. Identificação do objectivo do comportamento;

2. Desenho da Rede de Petri;

3. Identificação dos pontos de sincronismo, levantamento dos eventos e mecanismos de time-

out necessários;

4. Identificação dos pontos de gestão de compromisso necessários;

5. Identificação das acções primitivas, predicados e eventos necessários ao comportamento

e respectiva passagem para código dos elementos inexistentes;

6. Teste do comportamento correndo cada robot individualmente no simulador;

7. Teste do comportamento correndo dois ou mais robots no simulador (caso se trate de um

comportamento não individual);

8. Teste do comportamento correndo cada robot real individualmente;

9. Teste do comportamento correndo dois ou mais robots reais simultaneamente (caso se

trate de um comportamento não individual).

25

4 Desenvolvimento de Comportamentos Relacionais

4.1 Comportamentos anteriormente desenvolvidos

Em [2] e [3] foram utilizadas Redes de Petri para modelar comportamentos robóticos do SocRob.

Foram desenvolvidos comportamentos individuais de atacante, defesa e apoiante, e foram desen-

volvidos comportamentos relacionais na marcação de faltas e bolas paradas. Visto que o desen-

volvimento do projecto SocRob é continuo e construído sucessivamente, este trabalho assenta

nos trabalhos anteriormente desenvolvidos de modo a não criar roturas, procurando completar

redes que não estavam totalmente funcionais, e acrescentando novos comportamentos aos já

existentes.

Por estas razões torna-se pertinente fazer um breve resumo de comportamentos desenvolvi-

dos em [2] e [3]. De modo a não tornar o resumo demasiado extenso, apenas serão referencia-

dos os comportamentos relacionados com esta tese:

• RoleAttacker - nesta rede são escolhidos 4 diferentes tipos de comportamentos individu-

ais por coordenação com arbitragem: BehaviorBaseAttack, BehaviorMove2HomePosition,

BehaviorStop, BehaviorFoulAttacker ;

• RoleSupporter - nesta rede são escolhidos 4 diferentes tipos de comportamentos individu-

ais por coordenação com arbitragem: BehaviorBaseSupport, BehaviorMove2HomePosition,

BehaviorStop, BehaviorFoulDefend ;

• BehaviorBaseSupport - esta rede executa o comportamento individual de apoiante. As

únicas acções primitivas que executa são procurar a bola e seguir a bola a uma determi-

nada distância. A procura da bola é efectuada ao deslocar-se consecutivamente até quatro

pontos pré-estabelecidos do campo;

• BehaviorBaseAttack - esta rede executa o comportamento individual de atacante. É su-

posto o atacante apanhar a bola, driblar até perto da baliza, e depois chutar para uma de

duas zonas pré-determinadas da baliza adversária. Caso não veja a bola, o robot deve

dirigir-se para uma zona pré-definida do campo;

• RoleTaker - nesta rede é estabelecido o compromisso na marcação de uma falta, e depois

é escolhido um comportamento relacional de passe da bola na marcação de faltas, caso

o compromisso tenha sido estabelecido com sucesso, ou individual caso contrário. Esta

27

rede tem uma macro de nome CommitmentEstablishmentRequestBC que implementa o

protocolo mencionado em 2.5.1;

• RoleReceiver 3 - nesta rede é estabelecido o compromisso na marcação de uma falta, e

depois é escolhido um comportamento relacional de recepção da bola na marcação de fal-

tas, dual do escolhido pelo robot que executa a rede RoleTaker, caso o compromisso tenha

sido estabelecido com sucesso, ou individual caso contrário. Esta rede tem uma macro de

nome CommitmentEstablishmentAcceptBC que implementa o protocolo mencionado em

2.5.1.

4.2 Finalização do desenvolvimento do passe estático

Como foi referido, apenas estavam desenvolvidas Redes de Petri para modelar o comportamento

de marcação de uma falta, do conjunto total de bolas paradas. No entanto existia já uma forte

orientação de modo a poder com alguma facilidade modelar comportamentos para a marcação

relacional dos outros tipos de bolas paradas: pontapé de canto, lançamento lateral, pontapé de

saída, pontapé de baliza. Já estavam esboçados quais os comportamentos que ambos os robots

(marcador e receptor da falta) deveriam executar, que, no entanto, não estavam devidamente

implementados.

Foram também resolvidos bugs pontuais em Redes de Petri, acções primitivas e predicados,

que embora tenham demorado o seu tempo a resolver, não serão aqui mencionados por não

serem relevantes no que a esta dissertação diz respeito.

O estabelecimento do compromisso para este tipo de bolas paradas é exactamente o mesmo

que para a marcação de faltas. A diferenciação entre os diferentes tipos de bolas paradas é ape-

nas feito após o estabelecimento do compromisso, caso este tenha sido atingido com sucesso.

Ao nível das redes RoleTaker e RoleReceiver foi introduzido o predicado StopFoulCommit-

ment, que quando tem o valor verdadeiro significa que se deve terminar o comportamento rela-

cional. Isto permite reduzir a complexidade das redes relacionais e facilitar a sua rápida per-

cepção. Este predicado é uma associação dos predicados: GameIsStopped, PartnerNotCom-

mited e FoulTimeExpiring.

3Estas duas últimas redes também poderiam ser consideradas como comportamentos, mas tendo em conta que énecessário distinguir o comportamento de passe, por exemplo na marcação de uma falta ou de um pontapé de saída,foram implementados como papéis

28

Ao nível das redes relacionais, BehaviorFoulTakerDirect, BehaviorFoulReceiverDirect, Behav-

iorFoulTakerDirect2, BehaviorFoulReceiverDirect2, BehaviorFoulTakerTouch, BehaviorFoulRecei-

verTouch, BehaviorKickOffTaker e BehaviorKickOffReceiver foi possível remover os predicados

que agora estão associados a StopFoulCommitment, os aspectos de comunicação entre o mar-

cador e o receptor da falta, nomeadamente, no que aos lugares de memória interna da rede diz

respeito, foram tratados com maior cuidado. Esta redes têm como finalidade posicionar os robots

em duas posições do campo relativas à bola, de modo a que o robot que recebe o passe esteja

na tragetória desta quando o outro a chuta.

A finalização da implementação destes comportamentos, para além de ser essencial para o

projecto SocRob de modo a que a sua equipa de robots futebolistas seja competitiva e inovadora

num torneio de futebol robótico, permite também que futuros programadores possam implemen-

tar novos comportamentos, sabendo que os anteriores funcionam na sua plenitude, e que podem

usá-los como guia.

Para mais informações sobre estes comportamentos consultar [2] e [3].

29

4.3 Desenvolvimento de Passes Dinâmicos

4.3.1 Algoritmo de implementação

Em 3.4 foi introduzido um algoritmo cuja finalidade é estruturar quais os passos que se devem

seguir durante o desenvolvimento de um comportamento robótico. No entanto, para o desen-

volvimento de comportamentos relacionais, o primeiro ponto desse algoritmo ("Identificação do

objectivo do comportamento") tem de ser ampliado, contemplando os seguintes passos:

1. Que robots devem ser os actores do comportamento relacional? (Por actor entende-se o

robot envolvido num comportamento relacional.)

2. Como devem os robots actuar durante a execução do comportamento relacional?

3. Qual a vantagem do comportamento relacional em questão em relação a comportamentos

individuais?

4. Em que situação deve um robot efectuar o pedido de comportamento relacional (request)?

5. Em que situação deve um robot aceitar o pedido de comportamento relacional (accept)?

6. No caso de haver mais do que um robot a aceitar o pedido, e o robot que fez o pedido

apenas pode efectuar o compromisso com um deles, quais são os factores de escolha?

7. Após o estabelecimento do compromisso, quais são os gestores de compromisso?

Após a clarificação de todos estes pontos, pode-se então continuar a aplicar o algoritmo de

implementação de comportamentos anteriormente introduzido.

4.3.2 Modelos de redes

No Capítulo 3.3 estão explicadas as funções de cada um dos três níveis de decisão. Foi referido

que é no nível Behavior Coordinator que são escolhidos quais são os comportamentos que o

robot tem que desempenhar, executados pelo Behavior Executor. Através desta diferenciação

dos objectivos podemos dizer que os comportamentos do Behavior Executor podem ser dividi-

dos em dois grandes grupos: individuais e relacionais. A transição entre estes tipos de compor-

tamentos tem que ser gerida pelo nível Behavior Coordinator.

30

Idealmente a gestão da transição entre os tipos de comportamentos deveria ser feita através

de análises de predicados em cada um dos robots, que depois comunicariam entre si enviando

aceitações e rejeições através do bloco dedicado da MeRMaID Communications. Contudo neste

bloco não existe uma secção dedicada a este tipo de análises pelo que a análise dos predicados

e as comunicações têm que estar também modeladas na Rede de Petri do Behavior Coordinator.

Portanto nesta rede para além de estar a ser executada a escolha de comportamentos, estão

também ser geridas, numa outra secção da rede, as comunicações.

A comunicação é efectuada através de um par acção / predicado. Considerando que temos

a situação em que um robot envia um pedido a outro, o par seria action.SendRequest / pred-

icate.ReceivedRequest. O que na realidade se passa é que um robot, ao executar a acção

SendRequest, está a mudar o valor a variável Request no seu bloco Wisdom, mais concreta-

mente no WorldInfo, para true. Esta variável é constantemente enviada para os outros robots

através do bloco Communications. O valor desta variável será depois avaliado num predicado do

robot que recebe a informação. É necessário ter em atenção de que como a acção SendRequest

deve ser executada apenas uma vez por pedido, a própria acção tem de gerar um evento para a

Rede de Petri informando que já mudou a variável na Wisdom. Este evento ( event.STOP_SEND_-

REQUEST) corresponderá a uma transição que fará mudar o token do lugar action.SendRequest

para o lugar de memória memRequestSent, que quando está marcado significa que neste mo-

mento o robot está a enviar mensagens pedindo um compromisso com outro robot.

É preciso então ter o cuidado de ter os seguintes elementos nas Redes de Petri para gerir a

fase de setup do comportamento relacional:

• predicado a avaliar quando se deve efectuar pedido: predicate.ConditionsToRequestOK ;

• acção de envio de pedido, que lançará um evento para disparar a transição de saída do lu-

gar onde está a ser executada a acção primitiva: action.SendRequest / event.STOP_SEND_-

REQUEST;

• predicado a avaliar quando se deve anular pedido: predicate.NOT_ConditionsToRequestOK ;

• acção de anulamento de pedido: action.SendNOTRequest / event.STOP_SEND_NOT_RE-

QUEST;

• predicado de avaliação de estado de pedido dos outros robots: predicate.ReceivedRequest ;

• avaliação de quando se deve enviar a aceitação: predicate.ConditionsToAcceptOK ;

31

• caso os predicados ReceivedRequest e ConditionsToAcceptOK estejam marcados, enviar

aceitação: action.SendAccept / event.STOP_SEND_ACCEPT;

• predicado de avaliação do estado de aceitação dos outros robots: predicate.ReceivedAccept.

Cumprindo estes pontos garante-se que o protocolo de estabelecimento de compromisso está

a ser seguido. No entanto, é necessário garantir que existem memórias internas na rede para

garantir que o pedido é executado apenas uma vez. Isto é feito através de lugares sem prefixo

através da seguinte forma: inicialmente o lugar memNotRequestSent está marcado. Quando o

predicado ConditionsToRequestOK tem o valor de true é disparada uma transição que remove

um token do lugar memNotRequestSent e adiciona um a action.SendRequest. Após esta acção

fazer disparar a transição associada ao evento STOP_SEND_REQUEST, será removido um to-

ken de memNotRequestSent e adicionado um token a memRequestSent. Caso ConditionsToRe-

questOK mude o seu valor para false, ocorrerá a sucessão de eventos inversa, mudando apenas

o par acção / transição para action.SendNOTRequest / event.STOP_SEND_NOT_REQUEST.

No final a marcação desta secção da rede será a inicial. No caso em que é aceite o pedido é

necessário garantir que o token do lugar de memRequestSent seja removido, e que um token

seja adicionado ao lugar memNotRequestSent quando termina o comportamento relacional, de

modo a garantir que a rede volta à marcação inicial.

Para fazer a transição entre o comportamento relacional e o individual, são utilizadas tran-

sições associadas aos eventos BEHAVIOR_ENDED_SUCCESSFULLY e BEHAVIOR_ENDED_-

UNSUCCESSFULLY. Estes eventos são lançados pelo próprio comportamento relacional, com a

informação de que é altura de o terminar, com a informação adicional de que o comportamento

foi concluído com sucesso ou insucesso.

Também do lado do robot que manda aceitação é necessário existir o lugar de memória mem-

NotAcceptSent, de modo a poderem ser analisados os predicados ReceivedRequest e Condition-

sToAcceptOK e a ser executada apenas uma vez a acção SendAccept.

Através das regras descritas, a transição entre o comportamento individual e cooperativo

é diferente para o robot que envia pedido e para o que envia aceitação: a transição do robot

que envia pedido dispara quando o lugar memRequestSent estiver marcado e o predicato Re-

ceivedAccept for verdadeiro, enquanto que a transição do robot que envia aceitação dispara

quando é terminada a acção SendAccept.

Todo este processo pode ser ilustrado através das Figuras 11 e 12.

32

Figura 11: Robot que envia pedido

4.3.3 Comunicação

Como foi referido, as comunicações são efectuadas por um par acção/predicado, no qual a acção

muda uma variável do WorldInfo do robot em questão, e o predicado de outro robot avalia o valor

dessa variável. As comunicações das variáveis do WorldInfo são geridas pelo bloco Communi-

cations. Em [2] e [3] foi implementado um método no bloco Communications, mais propriamente

no CommunicationManager, no qual é feita uma avaliação de quais destinatários devem receber

o real valor da variável, de modo a que apenas seja enviado o valor verdadeiro da variável ao

seu parceiro. Este método evita que R1, estando comprometido com R2, envie mensagens de

comprometido a R3.

Neste trabalho foi efectuada uma variante deste processo. O valor da variável é transmitida a

todos os robots, no entanto, estes apenas a utilizarão dependendo da avaliação dos predicados.

Isto permite que os robots tenham mais informações relativamente aos outros robots, apenas as

utilizando se necessário.

Nesta secção são demonstrados segmentos de código que exemplificam todo este processo

de comunicação, desde a alteração da variável pela acção primitiva, passando pelo envio do

valor dessa variável através do CommunicationsManager, terminando na análise da variável pelo

outro robot através de um predicado.

33

Figura 12: Robot que envia aceitação

Tomemos o exemplo de um robot que quer enviar aos outros robots informação a solicitar um

compromisso. A acção SendRequest, implementada pelo seguinte código:

Listing 1: SendRequest.cpp - alteração da variável Request no WorldInfo e lançamento do evento

STOP_SEND_REQUEST

RequestValue = true;

PutDataWI("Request",RequestValue);

SendEventToPN("STOP\_SEND\_REQUEST");

De notar o lançamento do evento STOP_SEND_REQUEST, para poder terminar a acção na

Rede de Petri. O resultado é a mudança do valor da variável RequestBoolean para true no World-

Info. O envio do valor da variável está da seguinte forma no código do CommunicationsManager:

34

Listing 2: CommunicationsManager.cpp - envio da informação da variável Request

RequestValue = GetDataWI("Request");

SendData(RequestValue,0);

E a recepção está neste segmento de código:

Listing 3: CommunicationsManager.cpp - recepção da informação da variável Request

//se a mensagem tem como destino todos os robots, ou o robot em questão

if(RequestData.to[0] || RequestData.to[MyID]){

//actualiza o valor da variável

RequestValue = RequestData.Value;

RequestTimedData = TimedData(RequestValue,timeNow);

robotInfo->addElement("Request",RequestTimedData);

//caso contrário mantém o valor de falso

}else{

RequestTimedData = TimedData(false,timeNow);

robotInfo->addElement("Request",RequestTimedData);

}

Repare-se que com o envio do valor de Request segue o valor 0, significando que o valor da

variável é enviada para todos os robots. Outro valor corresponderia a qual robot deve ser enviada

a mensagem. Por exemplo, se R1 quisesse enviar o valor da variável somente para R2, não se

utilizaria o número 0, mas o número 2.

A análise por parte do predicado é feita da seguinte forma:

35

Listing 4: ReceivedRequest.cpp - predicado de avaliação do valor da variável Request de outro

robot

RequestTimedData = robotInfo->getElement("Request");

timeRequest = RequestTimedData->getTimeStamp();

//se o valor da variável não tiver sido enviado há mais de 2seg.

if( timeDiff(timeRequest,timeNow) < 2000 ){

//actualiza valor

RequestBoolean = RequestTimedData->RequestValue();

}else{

//caso contrário o valor é considerado falso

RequestBoolean = false;

}

Os timeStamps introduzidos no código são utilizados para descartar informações antigas e

que não devem ser utilizadas. Neste caso, timeNow representa o tempo actual de análise do

predicado, e timeBall representa o tempo em que foi enviada a informação. Se o desfasamento

entre estes tempos for superior a dois segundos, a informação deve ser descartada. Por estas

razões é imprescindível que os robots estejam constantemente a comunicar entre si, para que

esta situação não aconteça demasiadas vezes, o que poderá comprometer os comportamentos

relacionais. Numa situação em que os robots estejam comprometidos um com o outro, e em

que a última mensagem de comprometido que um deles recebeu foi há mais de dois segundos,

entende que perdeu comunicação com o outro e abandona o compromisso, embora o outro robot

possa estar a enviar mensagens de que está comprometido. Isto permite evitar situações de

deadlocks nos comportamentos relacionais, por perda de suporte de comunicações.

36

4.4 Motivação de desenvolvimento de passes dinâmicos

Em [2] e [3] foram desenvolvidos comportamentos individuais e organizacionais para todas as

situações de jogo, e foi introduzido um protocolo de estabelecimento de compromisso para

comportamentos relacionais resultando num passe estático entre dois robots. Foi lançado tam-

bém um repto para o desenvolvimento de comportamentos relacionais resultando num passe

dinâmico.

Nesta tese foram desenvolvidos dois tipos de passes dinâmicos, passe curto e passe longo,

os quais serão apresentados de seguida.

4.5 LongPass - Comportamento Relacional Passe Longo

4.5.1 Motivação

Durante o jogo de futebol robótico, podem existir situações em que o robot que controla a bola

está longe da baliza adversária, enquanto que um colega seu está perto. Através de um passe

dinâmico entre os dois robots, seria possível criar uma situação de perigo rapidamente. Para

esse efeito foi implementado o passe longo (LongPass).

4.5.2 Situação prevista

Para poder resumir o procedimento de estabelecimento de compromisso para o comportamento

relacional de passe longo, observe-se a Tabela 1:

Neste comportamento, em vez de ser enviado um pedido para passar a bola, é enviada

uma disponibilidade para receber a bola por parte do apoiante. O robot apoiante envia a sua

disponibilidade, alterando o valor da variável LongPassAvailable para verdadeiro no seu World-

Info, quando as pré-condições descritas na Tabela 1 estão cumpridas. O robot atacante aceita

efectuar o passe se as pré-condições descritas na mesma tabela estiverem a ser cumpridas,

alterando o valor da variável LongPassAccept para verdadeiro no seu WorldInfo. Repare-se que

as pré-condições de um robot são também as do outro, isto deve-se ao facto de não existir uma

avaliação geral partilhada pelos robots, mas sim uma avaliação individual feita por cada um.

Durante o comportamento relacional, o robot atacante deve driblar a bola até ficar virado para

37

Tabela 1: Estabelecimento de compromisso LongPass - Tabela de apoioActor Robot apoiante

Pré-Condições baliza está livre de obstáculosé o robot mais próximo da balizaatacante longe da balizaatacante na posse da bola

Acção de Comunicação envio da variável LongPassAvailable com valor verdadeiro

Actor Robot atacante

Pré-Condições está longe da balizaestá a driblar a bolarobot apoiante tem LongPassAvailable com valor verdadeiro

Acção de Comunicação envio da variável LongPassAccept com valor verdadeiro

o colega (reparar que foi introduzido o posicionamento em relação aos companheiros de equipa,

por oposição ao posicionamento em relação à bola) e chutar a bola quando estiver virado para

ele. Se quando o atacante está virado para o colega existirem obstáculos entre eles, ou se o

robot atacante já estiver próximo da baliza, o passe longo deve ser terminado. A vantagem que

se obtém deste comportamento é uma rápida transição de uma situação defensiva para uma

situação ofensiva, em que o robot que vai receber a bola se encontra numa situação boa para

rematar á baliza, pois não tem obstáculos no sítio para onde vai rematar.

4.5.3 Comportamentos desenvolvidos

Para modelar este comportamento, foram acrescentadas as secções de comunicações apresen-

tadas nas Figuras 11 e 12 às redes já existentes RoleAttacker e RoleSupporter, e foi seguida

a mesma estrutura de implementação. Notar que, paralelamente às secções de comunicações,

estão a correr também os comportamentos individuais de um robot atacante ou apoiante, Behav-

iorBaseAttack ou BehaviorBaseSupport.

O pedido de compromisso é enviado através da acção BehaviorSendLongPassAvailable 4, o

qual deve ser enviado caso ainda não tenha enviado esse pedido (memNotLongPassAvailable)

e caso as condições para poder declarar disponibilidade de receber um passe longo se verifi-

4no nível BehaviorCoordinator não são executadas acções primitivas. Para poder ultrapassar isto, são criados com-portamentos só com uma acção primitiva, a que se deseja que seja executada pelo nível BehaviorCoordinator. Nestecaso o comportamento BehaviorSendLongPassAvailable executará apenas a acção SendLongPassAvailable

38

carem pelo predicado LongPassAvailableConditionsOK (avaliação das pré-condições descritas

na Tabela 1 ).

Após o envio da disponibilidade do apoiante para receber um passe longo, o token do lugar

de memória memNotLongPassAvailable está no lugar memLongPassAvailable, e a variável do

WorldInfo LongPassAvailable tem o valor true. Do lado do robot atacante, o predicado LongPas-

sAvailable tem valor verdadeiro.

Nesta situação, caso se verifique que o robot atacante tem vantagem em aceitar o pedido

de compromisso, avaliado através do predicado LongPassAcceptConditionsOK (avaliação das

pré-condições descritas na Tabela 1), é removido um token do lugar de memória memNotLong-

PassAccept e adicionado um ao lugar de acção BehaviorSendLongPassAccept, que enviará essa

informação, mudando o valor do WorldInfo da variável LongPassAccept para true. Ao lançar esta

acção é lançado o evento STOP_LONG_PASS_ACCEPT, que fará disparar o evento da transição

associada. Esta transição irá remover o token do lugar action.BehaviorSendLongPassAccept, e

também do lugar action.BehaviorBaseAttack e irá adicionar um ao lugar action.BehaviorLongPass-

Taker. É neste ponto que se passa de um comportamento individual (BehaviorBaseAttack) para

um comportamento relacional (BehaviorLongPassTaker).

Do lado do robot apoiante o predicado LongPassAccept passa a ter valor verdadeiro, o que

significa que o robot atacante enviou a aceitação de compromisso. É disparada a transição que

irá remover um token do lugar memLongPassAvailable, e também do lugar action.BehaviorBase-

Support, adicionando um ao lugar action.LongPassReceiver, passando do comportamento indi-

vidual para o relacional.

Nas redes BehaviorLongPassTaker e BehaviorLongPassReceiver serão executados os com-

portamentos relacionais. Estas redes têm uma estrutura comum, que começa por uma macro

onde os robots acertam quem vai ser o parceiro do comportamento relacional, e em que iniciam

a troca de mensagens de comprometimento. Se o compromisso for estabelecido com sucesso,

irão ser executadas as macros TakePass, do lado do robot atacante, e ReceivePass, do lado do

apoiante. A primeira termina com sucesso caso o robot tenha conseguido direccionar-se para o

colega (macro CatchAndDribble2Partner), não tenha encontrado obstáculos entre eles, e tenha

chutado a bola, enquanto a segunda termina com sucesso caso o robot atacante tenha con-

seguido passar-lhe a bola. O comportamento não termina com sucesso apenas no caso em

que tenha conseguido apanhar a bola, pois a partir do momento em que se torna o robot mais

próximo da bola, a rede organizacional TeamOrganizer mudaria o papel do robot apoiante para

39

atacante e vice-versa, o que resultaria numa má finalização do compromissso, pois os robots

não teriam mudado a variável de comprometido para falso. Depois desta macro será terminado

o compromisso entre eles, e lançado o evento BEHAVIOR_ENDED_SUCCESSFULLY.

Caso uma das macros não tenha terminado com sucesso, ou caso o gestor de compro-

misso StopLongPass tenha valor verdadeiro, o compromisso será também terminado, e lançado

o evento BEHAVIOR_ENDED_UNSUCCESSFULLY.

Quando é terminado o comportamento relacional através do lançamento do evento BEHAV-

IOR_ENDED_SUCCESSFULLY ou BEHAVIOR_ENDED_UNSUCCESSFULLY, correspondentes

ao fim do comportamento relacional com o objectivo desejado alcançado, ou não alcançável,

do lado do apoiante será removido um token do lugar action.BehaviorLongPassReceiver e adi-

cionado aos lugares action.BehaviorBaseSupport e memNotLongPassAvailable. Do lado do ata-

cante será removido um token do lugar action.BehaviorLongPassTaker, e adicionado aos lugares

action.BehaviorBaseAttack e memNotLongPassAccept.

As equivalências à rede apresentada em 4.3.2 são descritas nas tabela seguintes.

Tabela 2: Equivalência de lugares do apoiante para o LongPassLugares Protocolo Lugares LongPassaction.BehaviorIndividual action.BehaviorBaseSupportaction.BehaviorCooperative action.BehaviorLongPassReceiveraction.BehaviorSendRequest action.SendLongPassAvailablepredicate.ConditionsToRequestOK action.LongPassAvailableConditionsOKpredicate.NOT_ConditionsToRequestOK predicate.NOT_LongPassAvailableConditionsOKpredicate.ReceivedAccept predicate.LongPassAcceptmemNotRequestSent memNotLongPassAvailablememRequestSent memLongPassAvailable

Tabela 3: Equivalência de lugares do atacante para o LongPassLugares Protocolo Lugares LongPassaction.BehaviorIndividual action.BehaviorBaseAttackaction.BehaviorCooperative action.BehaviorLongPassTakeraction.BehaviorSendAccept action.SendLongPassAcceptpredicate.ConditionsToAcceptOK action.LongPassAcceptConditionsOKpredicate.ReceivedRequest predicate.LongPassAvailablememNotAcceptSent memNotLongPassAccept

As redes desenvolvidas encontram-se na secção anexos.

40

4.5.4 Gestores de compromisso

Ao longo do comportamento relacional de passe longo existem pontos de gestão de compro-

misso. Quando se estabelece o compromisso, caso se receba a mensagem da RefereeBox de

que o jogo ficou parado, ou caso o outro robot demore demasiado tempo a responder que tam-

bém está comprometido, é terminado o comportamento relacional.

Durante a execução do passe, os gestores do compromisso realizam uma avaliação no mo-

mento em que o robot está virado para o parceiro, sobre se existem obstáculos entre eles. O

predicado StopLongPass é outro gestor de compromisso que avalia se o outro robot continua

comprometido, se o jogo não parou, se o robot atacante está já próximo da baliza ou se já pas-

sou um determinado período de tempo. Esta última avaliação é efectuada para poder evitar a

situação em que o robot não consegue direccionar-se para o parceiro, evitando uma situação de

deadlock.

4.6 ShortPass - Comportamento Relacional Passe Curto

4.6.1 Motivação

Durante o jogo de futebol robótico, podem existir situações em que o robot que controla a bola

está perto da baliza adversária, mas tem obstáculos entre ele e a baliza, nomeadamente robots

adversários. Seria vantajoso o robot passar a bola a outro que também esteja perto da baliza,

mas que não tenha obstáculos entre ele e a baliza. Para esse efeito foi criado o passe curto

(ShortPass).

4.6.2 Situação prevista

Neste comportamento, quando o robot atacante está a driblar a bola e se apercebe que tem ob-

stáculos pelo caminho, envia um pedido para passar a bola a outro robot que esteja em melhores

circunstâncias para chutar à baliza. Se um dos robots apoiantes estiver nessa situação, envia

uma mensagem de que aceitou o passe, e será iniciado o comportamento relacional de passe e

recepção da bola.

Para poder resumir o procedimento de estabelecimento de compromisso para o comporta-

mento relacional de passe longo, observe-se a Tabela 4.

41

Tabela 4: Estabelecimento de compromisso ShortPass - Tabela de apoioActor Robot apoiante

Pré-Condições baliza livre de obstáculosrobot atacante tem ShortPassRequest com valor verdadeiroatacante próximo da baliza da balizaatacante na posse da bolanão está proximo do robot atacante

Acção de Comunicação envio da variável ShortPassAccept com valor verdadeiro

Actor Robot atacante

Pré-Condições perto da balizaestá a driblar a bolabaliza ocupada com obstáculos

Acção de Comunicação envio da variável ShortPassRequest com valor verdadeiro

O comportamento de execução do passe cooperativo é semelhante ao do LongPass, existindo

apenas a diferença de neste caso existir a possibilidade de haver dois robots apoiantes a aceitar

o pedido do atacante ao mesmo tempo. Por esta razão, no estabelecimento de compromisso

está implementado um mecanismo de envio/recepção de rejeições. Ao receber a rejeição, o

robot apoiante irá terminar o seu compromisso.

4.6.3 Comportamentos desenvolvidos

Para modelar este comportamento, foram acrescentadas as secções de comunicações apresen-

tadas nas figuras 11 e 12 às redes já existentes RoleAttacker e RoleSupporter, e foi seguida a

mesma estrutura de implementação.

O pedido de compromisso é enviado através da acção BehaviorSendShortPassRequest, o

qual deve ser enviado caso ainda não tenha enviado esse pedido (memNotShortPassRequest)

e caso as condições para poder declarar disponibilidade de receber um passe curto se verifi-

carem pelo predicado ShortPassRequestConditionsOK (avaliação das pré-condições descritas

na Tabela 4 ).

Após o envio do pedido do atacante, o token do lugar de memória que anteriormente es-

tava em memNotShortPassRequest está agora no lugar memShortPassRequest, e a variável do

WorldInfo ShortPassRequest tem o valor true. Do lado do robot apoiante, o predicado Short-

42

PassRequest tem valor verdadeiro.

Nesta situação, caso se verifique que o robot apoiante está em condições para receber a bola,

avaliado através do predicado ShortPassAcceptConditionsOK (avaliação das pré-condições de-

scritas na Tabela 4), é removido um token do lugar de memória memNotShortPassRequest e

adicionado um ao lugar action.BehaviorSendShortPassAccept, que enviará essa informação, mu-

dando o valor do WorldInfo da variável ShortPassAccept para true. Nesta acção é lançado o

evento STOP_SHORT_PASS_ACCEPT, que fará disparar a transição associada. Será removido

o token do lugar action.BehaviorSendShortPassAccept e do lugar action.BehaviorBaseSupport

e será adicionado um token ao lugar action.BehaviorShortPassReceiver, passando de um com-

portamento individual para um relacional.

Do lado do robot atacante o predicado ShortPassAccept passa a ter valor verdadeiro, o que

significa que o robot apoiante enviou a aceitação de compromisso. É disparada uma transição

que irá remover um token do lugar memShortPassRequest, e do lugar action.BehaviorBaseAttack,

adicionando um ao lugar action.ShortPassTaker, passando do comportamento individual para o

relacional.

Nas redes BehaviorShortPassTaker e BehaviorShortPassReceiver serão executados os com-

portamentos semelhantes aos das redes BehaviorLongPassTaker e BehaviorLongPassReceiver,

pelo que apenas se falará aqui das diferenças entre eles.

No estabelecimento do compromisso é adicionada uma secção para lidar com rejeições por

parte do atacante, visto que os dois apoiantes podem aceitar o pedido de compromisso por

parte do atacante, bastando para isso estarem ambos numa situação em que não encontram

obstáculos na baliza. Para resolver este conflito, o atacante envia uma mensagem de compro-

metido ao robot que estiver mais próximo dele, enviando rejeições para o outro, que ao receber

esta mensagem, irá terminar o comportamento relacional. No robot que recebeu mensagem de

comprometido, a estrutura do comportamento de passe curto é igual à do passe longo.

Quando é terminado o comportamento relacional através do lançamento do evento BEHAV-

IOR_ENDED_SUCCESSFULLY ou BEHAVIOR_ENDED_UNSUCCESSFULLY, do lado do apoian-

te será removido um token do lugar action.BehaviorShortPassReceiver e adicionado aos lugares

action.BehaviorBaseSupport e memNotShortPassRequest. Do lado do atacante será removido

um token do lugar action.BehaviorShortPassTaker, e adicionado aos lugares action.BehaviorBase-

Attack e memNotShortPassRequest.

43

As equivalências à rede apresentada em 4.3.2 são descritas nas tabela seguintes.

Tabela 5: Equivalência de lugares do atacante para o ShortPassLugares Protocolo Lugares ShortPassaction.BehaviorIndividual action.BehaviorBaseAttackaction.BehaviorCooperative action.BehaviorShortPassTakeraction.BehaviorSendRequest action.SendShortPassRequestpredicate.ConditionsToRequestOK action.ShortPassRequestConditionsOKpredicate.NOT_ConditionsToRequestOK predicate.StopShortPassRequestpredicate.ReceivedAccept predicate.ShortPassAcceptmemNotRequestSent memNotRequestedShortPassmemRequestSent memRequestedShortPass

Tabela 6: Equivalência de lugares do apoiante para o ShortPassLugares Protocolo Lugares ShortPassaction.BehaviorIndividual action.BehaviorBaseSupportaction.BehaviorCooperative action.BehaviorShortPassReceiveraction.BehaviorSendAccept action.SendShortPassAcceptpredicate.ConditionsToAcceptOK action.ShortPassAcceptConditionsOKpredicate.ReceivedRequest predicate.ShortPassRequestmemNotAcceptSent memNotShortPassAccept

As redes desenvolvidas encontram-se na secção anexos.

4.6.4 Gestores de compromisso

Ao longo do comportamento relacional de passe curto existem pontos de gestão de compromisso.

Quando se estabelece o compromisso, caso se receba a mensagem da RefereeBox de que

o jogo ficou parado, caso o outro robot demore demasiado tempo a responder que também

está comprometido, ou caso o robot apoiante receba rejeição do robot atacante, é terminado o

comportamento relacional.

Durante a execução do passe, os gestores do compromisso realizam uma avaliação no mo-

mento em que o robot está virado para o parceiro, sobre se existem obstáculos entre eles. O

predicado StopShortPass é o outro gestor de compromisso, que avalia se o outro robot continua

comprometido, se o jogo não parou, se o robot atacante está demasiado próximo do parceiro (não

havendo vantagem em efectuar o passe) ou se já passou um determinado período de tempo.

44

4.7 BehaviorBaseSupport - Comportamento Individual Apoiante

4.7.1 Motivação

A rede BehaviorBaseSupport, comportamento individual de base do robot apoiante, foi modifi-

cada com a intenção de poder tirar o melhor partido dos comportamentos relacionais desenvolvi-

dos para o passe longo e o passe curto, e de modo a poder dar aos robots com este papel um

comportamento mais complexo, completo e ao mesmo tempo vantajoso para os outros elemen-

tos da equipa, nomeadamente, o atacante.

Até aqui, o comportamento associado ao apoiante no projecto SocRob era aproximar-se da

bola até uma determinada distância, caso a visse, e procurar a bola em pontos pré-definidos,

caso não a visse. Nesta nova implementação foram contempladas duas novas situações, ambas

relacionadas com o robot que possui a bola, o atacante.

4.7.2 Implementação

Na primeira situação, caso o robot que possui a bola esteja longe da baliza, e o robot apoiante

é o robot que se encontra mais perto da baliza, em vez de continuar a seguir a bola, dirige-se

para a baliza contrária através da primitiva Move2OppGoal. Esta primitiva consiste em deslocar

o robot para um de dois pontos pré-definidos no campo, pertos da baliza adversária. A escolha

do ponto para onde vai depende da sua posição actual. Quando se encontra perto da baliza

adversária (predicado NearGoal), procura uma posição em que não existam obstáculos entre

ele e a baliza adversária, através da primitiva SearchShootingSpot. Nesta primitiva o robot tem

que se deslocar para três pontos pré-definidos num vector, que são próximos da baliza. O robot

segue os pontos consecutivamente, sendo que a posição inicial do vector é iniciada aleatori-

amente de cada vez que é chamada a primitiva. Quando encontra essa posição (predicado

ObstaclesAtGoal com o valor falso) é executada a primitiva Stop, para que o robot permaneça

no local. Caso voltem a existir obstáculos entre ele e a baliza (predicado ObstaclesAtGoal com

o valor verdadeiro) procura outra vez um local sem os obstáculos entre ele e baliza executando

a primitiva SearchShootingSpot.

Esta secção do comportamento foi criada de modo a poder aumentar as probabilidades de

ocorrência do predicado LongPassAvailableConditionsOK, o que permite mais rapidamente e

mais vezes ocorrer a situação em que o robot atacante tem um robot a quem passar a bola

45

porque está numa melhor posição.

Na segunda situação, caso o robot que possui a bola esteja perto da baliza, e caso o robot

apoiante esteja também perto da baliza, o robot apoiante procura um sítio onde não estejam

obstáculos entre ele e a baliza, executando novamente a acção SearchShootingSpot. Caso o

encontre, executa a primitiva Stop e permanece nesse local, e caso voltem a existir obstáculos,

é procurado um outro local.

Esta secção do comportamento foi criada de modo a poder aumentar as probabilidades de

ocorrência do predicado ShortPassAcceptConditionsOK, o que permite que, caso o robot at-

acante tenha enviado um pedido de compromisso para efectuar um passe curto, este robot

apoiante em questão esteja em condições de receber a bola.

Se nenhuma das condições necessárias para executar os comportamentos relativos aos ca-

sos necessários for cumprida, o robot apoiante continua a seguir a bola a uma determinada

distância caso a veja, ou corre uma primitiva de busca de bola caso não a veja. De notar que em

ambas as situações implementadas, não é necessário ao robot saber onde está a bola, basta-

lhe saber, através de mensagens recebidas do robot atacante, que este possui a bola, o que

aumenta a fluidez de jogo, e diminui a quantidade de tempo que os robots estão à procura da

bola.

46

5 Resultados

Os comportamentos desenvolvidos foram testados com sucesso num simulador do ambiente de

futebol robótico, o Webots 5. A grande vantagem em utilizar este simulador, é que o código que é

executado é exactamente o mesmo que o código executado pelos robots, pelo que facilita o teste

de novos comportamentos e permite reduzir o tempo de desenvolvimento, evitando também os

problemas de hardware inerentes a qualquer máquina. Este programa simula a interacção entre

o robot e o ambiente que o rodeia, o que significa que são simulados todos os processos de

actuação e percepção com o ambiente.

Os comportamentos desenvolvidos foram também demonstrados nos robots reais, embora

num ambiente controlado. Devido ao campo reduzido (condições para fazer passe longo reduzi-

das), associada ao facto de o atacante perder várias vezes a bola durante o drible (predicado

AttackerDribbling2Goal), não foi possível demonstrar como se queria os comportamentos desen-

volvidos, nomeadamente do estabelecimento de compromisso. No entanto foi possível demon-

strar que o comportamento do apoiante é o pretendido, e que o robot atacante consegue passar

a bola para uma posição próxima do robot apoiante. Foi também necessário alterar secções de

código, devido ao facto da percepção dos obstáculos ser diferente do simulador para a realidade,

para contemplar as duas situações.

Foram feitas filmagens e gravações dos comportamentos desenvolvidos, tanto nos robos reais

como no simulador, que podem ser observados numa página criada para este propósito, em

http://socrob.isr.ist.utl.pt/videos/behaviors/behaviors.html.

5http://www.cyberbotics.com/

47

6 Análise dos Comportamentos

6.1 Propriedades das Redes de Petri

Sobre as Redes de Petri desenvolvidas pode ser feita uma análise qualitativa e quantitativa. A

primeira implica uma análise das propriedades das redes, permitindo classifica-las, verificar se

têm deadlocks ou se dada marcação é alcançável. A segunda implica uma análise através de

resultados obtidos experimentalmente para os comportamentos desenvolvidos, fazendo a equiv-

alência da Rede de Petri a uma Cadeia de Markov, tal como explicado em [12]. Existem outros

métodos que podem ser utilizados para analisar o desempenho da rede, tais como associar

funções de custo a cada acção primitiva, introduzidos em [10].

Como qualquer ferramenta de modelação, uma Rede de Petri tem as suas propriedades.

Existem dois grandes grupos de propriedades: comportamentais e estruturais. As primeiras

dependem da marcação inicial, enquanto as segundas não.

Neste capítulo apenas irão ser apresentadas e estudadas certas propriedades comportamen-

tais, consideradas essenciais para o desempenho de robots futebolistas. Para uma apresentação

mais aprofundada sobre as propriedades das Redes de Petri deve-se consultar [8].

As propriedades que se pretendem verificar nas Redes de Petri desenvolvidas são:

• Limitação - Uma Rede de Petri é k-limitada, ou simplesmente limitada, se o número de

tokens em cada lugar for menor ou igual a k, para qualquer marcação a partir da marcação

inicial. Ou seja, M(p) ≤ k para qualquer lugar p e qualquer marcação M ∈ R(M0), onde

R(M0) é o conjunto de todas as marcações alcançáveis a partir da marcação inicial M0;

Quando uma Rede de Petri é 1-limitada, diz-se que é uma rede segura.

• Vivacidade - O conceito de vivacidade está relacionado com a ausência de deadlocks na

rede. Uma Rede de Petri diz-se viva se, em qualquer marcação alcançável pela marcação

inicial, for possível disparar qualquer transição, através de uma sequência de disparos. Isto

significa que uma Rede de Petri viva não apresenta qualquer deadlock, qualquer que seja

a sequência de disparo;

• Alcançabilidade - o conjunto alcançável é o conjunto total de marcações que se pode

alcançar a partir da marcação inicial. Uma das formas de analisar se uma dada marcação é

49

alcançável é através do grafo de alcançabilidade, onde se representam todas as marcações

alcançáveis a partir da marcação inicial, que será utilizado nos próximos capítulos.

Conforme é explicado no Capítulo 3.3, é necessário redesenhar as redes desenvolvidas, de

modo a poderem ser analisadas as suas propriedades. Existem duas formas possíveis de re-

desenhar a rede: representar o par predicado / transição por uma só transição, que dispararia

quando o predicado fosse verdadeiro, sendo a transição temporizada, ou representar o predicado

como um par predicado / NOT_predicado, com transições temporizadas entre eles, que disparam

quando o predicado muda de valor.

Estas alternativas podem ser observadas na Figura 13:

Figura 13: Rede original, e duas redes redesenhadas

Ambas as representações são válidas, embora, como se pode rapidamente concluir, a se-

gunda permita retirar mais informação sobre o estado do sistema, para além de proporcionar

informação sobre qual a acção que o robot está a desempenhar. No entanto, ao utilizar este

redesenhamento, o número de estados alcançáveis aumenta consideravelmente. Por exemplo,

a rede BehaviorBaseSupport, redesenhada pelo primeiro método tem apenas 7 marcações al-

cançáveis, enquanto que no segundo tem 67. Este número elevado deve-se ao facto de que

durante a execução de cada acção existem predicados que não estão relacionados com a acção

que está desempenhar, e que podem mudar de estado sendo a acção a mesma, correspondendo

a cada variação de predicado uma marcação alcançável.

Nesta dissertação, ambos os métodos serão usados, mas para diferentes situações. O

primeiro será utilizado na Secção 6.2 para analisar qualitativamente a rede, ou seja, verificar

50

as propriedades acima descritas da Rede de Petri. O segundo será utilizado para analisar quan-

titativamente a rede, ou seja, quantificar a probabilidade de uma dada marcação. Esta análise

será feita na Secção 6.3.

6.2 Análise Qualitativa

A escolha da primeira representação para esta secção é feita tendo em conta que é mais intuitivo

para o leitor ou para o programador observar quais as primitivas que o comportamento executa

e ao mesmo tempo verificar as propriedades da Rede de Petri. Já foi utilizada na dissertação [3]

efectuada também no projecto SocRob.

Das redes desenvolvidas ou melhoradas ao longo desta dissertação serão analisadas qual-

itativamente as BehaviorBaseSupport, RoleSupporter e BehaviorLongPassTaker. Esta escolha

foi feita porque as restantes redes têm uma estrutura semelhante, pelo que estudá-las seria re-

dundante.

6.2.1 BehaviorBaseSupport

A rede BehaviorBaseSupport é o comportamento individual do robot apoiante introduzida em

4.7. Redesenhando a rede obtém-se o grafo de alcance representado na Figura 14.

Tabela 7: BehaviorBaseSupport - Tabela das Marcações alcançáveisMarcação LugaresM0 (1,0,0,0,0,0,0)M1 (0,1,0,0,0,0,0)M2 (0,0,1,0,0,0,0)M3 (0,0,0,1,0,0,0)M4 (0,0,0,0,1,0,0)M5 (0,0,0,0,0,1,0)M6 (0,0,0,0,0,0,1)

Conclui-se que todos os lugares estão marcados no máximo por apenas um token, o que

significa que a rede é 1-limitada, e portanto segura. Não contém deadlocks pelo que se considera

uma rede viva, e o conjunto alcançável pode ser observado através da tabela de apoio ao grafo

de alcance.

O conjunto das marcações alcançáveis está represento na Tabela 7, onde o vector Mi tem o

seguinte signficado: (FollowBallOnDistance, SearchBall, Move2OppGoal, SearchShootingSpot1,

51

Figura 14: BehaviorBaseSupport - Grafo de alcance

Stop1, SearchShootingSpot2, Stop2). Tomando como exemplo, a marcação (1, 1, 0, 0, 0, 0) sig-

nifica que robot tem o lugar correspondente à acção FollowBallOnDistance e à acção SearchBall

marcados. Como se pode visualizar na tabela referida, esta marcação não faz parte do conjunto

alcançável.

Uma curiosidade desta rede é o facto de existirem quatro marcações que, sendo diferentes,

executam o mesmo tipo de acções: M2 e M5, M3 e M6. Isto deve-se ao facto de que emb-

ora se tratem de diferentes tipos de situação (na primeira tenta-se aumentar a probabilidade de

utilização do passe longo e na segunda do passe curto), ambas terminam com o robot a desem-

penhar o mesmo tipo de comportamento: procurar um local livre de obstáculos e permanecer ai.

São necessárias diferentes marcações, porque têm transições de entrada e de saída diferentes,

sendo algumas a negação da outra (exemplo de AttackerNearGoal e NOTAttackerNearGoal).

Para as diferenciar é utilizado um índice: 1 ou 2.

Deve-se também observar a tabela de apoio das transições, Tabela 8, onde estão descritas

quais as condições que são necessárias satisfazer para uma transição disparar, caso esteja

activa. Repare-se na utilização dos operadores lógicos ∧ e ∨. ∧ significa que para a avaliação

ter valor verdadeiro, todos os seus elementos têm que ser verdadeiros, e ∨ significa que para a

avaliação ter valor verdadeiro, basta um elemento ter valor verdadeiro.

52

Tabela 8: BehaviorBaseSupport - Tabela das TransiçõesTransições AvaliaçõesT0 NOTSeeBallT1 SeeBallT2 AttackerDribbling2Goal ∧ ClosestToOppGoal ∧ NOTAttackerNearGoalT3 NOTAttackerDribbling2Goal ∨ NOTClosestToOppGoal ∨ AttackerNearGoalT4 NearGoalT5 NOTNearGoalT6 NOTObstaclesAtGoalT7 ObstaclesAtGoalT8 AttackerDribbling2Goal ∧ NearGoal ∧ AttackerNearGoalT9 NOTAttackerDribbling2Goal ∨ NOTNearGoal ∨ NOTAttackerNearGoal

6.2.2 RoleSupporter

A rede RoleSupporter gere quais os comportamentos que o robot deve efectuar, que podem ser

individuais (ex. BehaviorBaseSupport) ou relacionais (ex. ReceiveShortPass). Redesenhando

a rede obtém-se o grafo representado na Figura 15.

Tabela 9: RoleSupporter - Tabela das Marcações alcançáveisMarcação LugaresM0 (1,0,0,0,1,0,1,0,0,0,0,0)M1 (0,1,0,0,1,0,1,0,0,0,0,0)M2 (0,0,1,0,1,0,1,0,0,0,0,0)M3 (0,0,0,1,1,0,1,0,0,0,0,0)M4 (0,1,0,0,0,1,1,0,0,0,0,0)M5 (0,0,0,0,0,0,1,0,0,0,1,0)M6 (0,1,0,0,1,0,0,0,1,0,0,0)M7 (0,1,0,0,1,0,0,1,0,0,0,0)M8 (0,1,0,0,1,0,0,0,0,1,0,0)M9 (0,0,0,0,1,0,0,0,0,0,0,1)

Nesta rede, ao contrário da rede BehaviorBaseSupport, as marcações alcançáveis têm dois,

três ou quatro lugares marcados. Isto deve-se à necessidade de existirem lugares cuja função é

garantir uma boa gestão do compromisso. Não contém deadlocks logo é uma rede viva, e cada

lugar está marcado no máximo por um token, logo a rede é 1-limitada, portanto segura.

O conjunto das marcações alcançáveis encontra-se na Tabela 9, onde cada marcação Mi

tem o seguinte significado: (BehaviorStop, BehaviorBaseSupport, BehaviorFoulDefend, Behav-

iorMove2HomePosition, memNotShortPassAccept, BehaviorSendShortPassAccepted, memNot-

LongPassAvailable memLongPassAvailable, BehaviorSendLongPassAvailable, BehaviorSendLong-

PassNotAvailable, BehaviorShortPassReceiver, BehaviorLongPassReceiver).

53

Figura 15: RoleSupporter - Grafo de alcance

O comportamento BehaviorMove2HomePosition é executado quando é marcado um golo

(sinalizado pela RefereeBox), que contém apenas uma acção primitiva, Move2HomePosition,

cuja finalidade é o robot retornar à sua posição inicial para o jogo poder ser reiniciado. O com-

portamento BehaviorFoulDefend é executado quando é assinalada uma falta, cuja finalidade é

o robot assumir um posicionamento entre a bola e a baliza. Quando é terminado o tempo para

marcar a falta, inicia-se o comportamento BehaviorBaseSupport. Os estados M4, M6, M7 e

M8 correspondem a gestões entre o comportamento individual, M1, e os comportamentos rela-

cionais, M5 e M9, por isso embora a marcação seja diferente da marcação M1, o comportamento

que o robot efectua é o mesmo. Como seria de esperar, após a execução do comportamento

relacional volta-se imediatamente para um comportamento individual.

A tabela de apoio às transições encontra-se na Tabela 10. Repare-se que a transição T8 é

igual para o comportamento de passe longo e passe curto, que é recepção do evento BEHAV-

IOR_ENDED_SUCCESSFULLY ou BEHAVIOR_ENDED_UNSUCCESSFULLY, pois é suposto

terminar o comportamento relacional com a recepção destes eventos. As avaliaçãoes feitas

nesta rede são de ordem diferente das da Tabela 8, pois nesta rede apenas se tem em conta

avaliações organizacionais.

54

Tabela 10: RoleSupporter - Tabela das TransiçõesTransições AvaliaçõesT0 GameIsStartedT1 GameIsStoppedT2 GoalScoredT3 FoulOurs ∨ FoulOpponentT4 FoulTimeExpiringT5 ShortPassRequested ∧ ShortPassAcceptConditionsOKT6 STOP_SendShortPassAcceptT7 BEHAVIOR_ENDEDT8 LongPassAvailableConditionsOKT9 STOP_SendLongPassAvailableT10 LongpassAcceptedT11 NOT_LongPassAvailableConditionsOKT12 STOP_SendNotLongPassAvailable

6.2.3 BehaviorLongPassTaker

A rede LongPassTaker executa, para além de acções primitivas, macros. Estas macros são

AttackerLongPassCommitment e TakePass, executando também esta última a macro CatchAnd-

Dribble2Partner. Como as macros têm como finalidade a redução da complexidade da rede,

serão representadas apenas por um lugar. Redesenhando a rede obtém-se o grafo de alcance

para todas as marcações alcançáveis representado na Figura 16:

Tabela 11: BehaviorLongPassTaker - Tabela das Marcações alcançáveisMarcação LugaresM0 (1,0,0,0,0,0,0,0)M1 (0,1,0,0,0,0,0,0)M2 (0,0,1,0,0,0,0,0)M3 (0,0,0,1,1,0,0,0)M4 (0,0,0,0,0,1,0,0)M5 (0,0,0,1,0,0,1,0)M6 (0,0,0,0,0,0,0,1)

Conclui-se que a rede não contém deadlocks, logo é viva, e que cada lugar está marcado

no máximo com um token, logo é segura. Nesta rede existem marcações alcançáveis com

dois lugares marcados. A existência de haver um segundo lugar marcado quando se termina

o compromisso, M3 e M5, deve-se ao facto ser necessária a existência de um lugar de memória

interna da rede, para se saber se após o fim de compromisso deve ser lançado o evento BEHAV-

IOR_ENDED_SUCCESSFULLY ou BEHAVIOR_ENDED_SUCCESSFULLY. A marcação inicial é

a acção primitiva Stop, no entanto esta primitiva não será executada pelo robot, pois quando esta

rede é executada através de RoleAttacker, a sua marcação é M1, e quando é lançado o evento

55

Figura 16: BehaviorLongPassTaker - Grafo de alcance

de terminar o comportamento relacional, na marcação M4 ou M6, esta rede deixará de ser exe-

cutada pelo RoleAttacker. Foi escolhida a acção Stop, por ser uma acção neutra, cuja finalidade

é somente o robot não sair do sitio. A rede não contém deadlocks, portanto viva, e cada lugar

está marcado no máximo com um token, pelo que é segura.

O conjunto das marcações alcançáveis encontra-se na Tabela 11, onde cada marcação Mi

tem o seguinte significado: (Stop, AttackerLongPassCommitment, TakePass, BreakCommitment,

memBehaviorSucessful, SendBehaviorSuccessful, memBehaviorUnsucessful, SendBehaviorUn-

successful ).

A tabela de apoio das transições encontra-se na Tabela 12. A transição STOP_LONG_PASS_-

ACCEPT dispara quando ocorre o evento com o mesmo nome, lançado por um comportamento

da rede RoleAttacker, que permite que esta rede apenas evolua quando está a ser executada.

Existem duas transições com o mesmo nome, GOAL_REACHED e GOAL_NOT_REACHED, que

são lançadas pelas macros, no entanto como são lançadas por macros diferentes não são inter-

pretadas pelo PetriNetExecutor como a mesma transição. Na tabela referida, estão com índices

diferentes, 1 ou 2.

56

Tabela 12: BehaviorLongPassTaker - Tabela das TransiçõesTransições AvaliaçõesT0 STOP_LONG_PASS_ACCEPTT1 GOAL_REACHED1T2 GOAL_REACHED2T3 COMMITMENT_BROKENT4 BEHAVIOR_ENDED_SUCCESSFULLYT5 GOAL_NOT_REACHED1T6 GOAL_NOT_REACHED2 ∨ StopLongPassT7 BEHAVIOR_ENDED_UNSUCCESSFULLY

6.3 Análise do Desempenho

6.3.1 Motivação

Num ambiente dinâmico como um jogo de futebol robótico, é impossível prever com toda a

certeza como decorrerão os acontecimentos do jogo, pois a probabilidade de qualquer evento

futuro depende apenas do estado presente. Portanto, qualquer que seja o número de jogos

que duas equipas realizem, é impossível prever como decorrerá o jogo. A aproximação deste

ambiente a um sistema de eventos discretos, seguida ao longo desta dissertação, possibilita a

utilização de ferramentas de análise deste tipo de sistemas, nomeadamente Cadeias de Markov,

que permitem, entre outras coisas, calcular qual o estado seguinte mais provável dado o estado

actual do sistema. Na análise a efectuar nesta secção será determinada qual a probabilidade de

cada acção e predicado, durante a execução de um comportamento.

6.3.2 Cadeias de Markov

Em [9] é explicado que uma Rede de Petri Estocástica Generalizada é equivalente a uma Cadeia

de Markov, quando se associa a cada transição temporizada uma taxa de disparo, baseada numa

distribuição probabilística de tempo exponencial. Quando existe mais do que uma transição

pronta a disparar, a probabilidade de uma transição disparar é dada pela seguinte fórmula:

F (M, tj)∑TtkF (M, tk)

(1)

Onde M é o lugar marcado, T o conjunto de transições prontas a disparar, tj é a transição em

questão e F (M, tj) é a taxa de disparo da transição. Por exemplo, sejam T1 e T2 duas transições

57

em conflito prontas a disparar, seja µ1 a taxa de disparo da transição T1, e µ2 a taxa de disparo

da transição T2. A probabilidade da transição T1 disparar é dada por:

µ1

µ1 + µ2(2)

Enquanto que a probabilidade da transição T2 disparar é dada por:

µ2

µ1 + µ2(3)

Depressa se conclui que a soma das probabilidades de pelo menos uma das transições dis-

parar é de 1:

µ1

µ1 + µ2+

µ2

µ1 + µ2= 1 (4)

Através dos valores das taxas de transição é possível calcular o vector das probabilidades

de estado estacionário, do qual se pode analisar quais são as marcações mais prováveis do

comportamento. Este vector pode servir de guia ao desenvolvimento de novos comportamentos,

pois é possível calcular qual a probabilidade de cada acção durante o comportamento.

6.3.3 BehaviorBaseSupport

O primeiro passo para poder avaliar o desempenho do comportamento é redesenhar a Rede de

Petri em questão através da segunda forma apresentada na Secção 6.1. Os valores das taxas

de disparo foram retirados experimentalmente do simulador do ambiente de futebol robótico,

executando várias vezes o comportamento em questão. O valor da taxa de disparo de cada

transição foi retirado pela seguinte fórmula:

TaxaDisparo =1

TempoMedioDisparo(5)

Os valores dos tempos médios de disparo foram obtidos com dois robots, estando um a execu-

tar o comportamento BehaviorBaseAttack, e outro a executar o comportamento em análise, Be-

haviorBaseSupport e podem ser observados na Tabela 13. As transições têm o seguinte formato:

LugarEntrada->LugarSaída. Por exemplo, a transição AttackerDribbling2Goal->NOTAttackerDri-

58

bbling2Goal tem como lugar de entrada AttackerDribbling2Goal e lugar de saída NOTAttacker-

Dribbling2Goal. Quando o evento associado à transição ocorre significa que o robot atacante

deixou de driblar a bola.

Tabela 13: BehaviorBaseSupport - Taxas de TransiçãoTransições Taxas(eventos/un.tempo)AttackerDribbling2Goal->NOTAttackerDribbling2Goal 0.118NOTAttackerDribbling2Goal->AttackerDribbling2Goal 0.0984AttackerNearGoal->NOTAttackerNearGoal 0.0711NOTAttackerNearGoal->AttackerNearGoal 0.0349NearGoal->NOTNearGoal 0.0183NOTNearGoal->NearGoal 0.0924SeeBall->NOTSeeBall 0.0456NOTSeeBall->SeeBall 0.0951ObstaclesAtGoal->NOTObstaclesAtGoal 0.065NOTObstaclesAtGoal->ObstaclesAtGoal 0.0744ClosestToOppGoal->NOTClosestToOppGoal 0.0806NOTClosestToOppGoal->ClosestToOppGoal 0.109

O vector de estado estacionário foi calculado através de um programa de análise de Re-

des de Petri, denominado PIPE 6 (Platafrom Independent Petri Net Editor, que calcula todas as

marcações alcançáveis a partir da marcação inicial, e qual a sua probabilidade. Neste compor-

tamento os predicados não têm avaliações em comum, o que significa que cada transição está

associada apenas à mudança de um predicado. Se dois predicados tivessem avaliações em

comum seria necessário utilizar um diferente método para o cálculo dos valores das taxas de

transição, dependente de caso para caso.

Existem 67 marcações alcançáveis neste comportamento, e de seguida são apresentadas

duas tabelas que contêm os dados cruzados entre as marcações alcançáveis e a probabilidade

de cada marcação do vector de estado estacionário, calculados somando a probalidade de todas

as marcações em que o lugar em questão está marcado. Na Tabela 14 encontra-se a probabili-

dade de cada acção, e na Tabela 15 a probabilidade de cada predicado. Existem dois pares de

acção que são repetidos, no entanto serão apresentados com um diferente nome, tal como em

6.2.1, e pelas mesmas razões: têm como finalidade aumentar as probabilidades de acontecerem

os dois diferentes tipos de passe.

Através destas tabelas podem-se retirar conclusões relevantes:

• Durante 32.4% do tempo o robot não vê a bola (NOTSeeBal), no entanto apenas a procura

6http://pipe2.sourceforge.net

59

Tabela 14: BehaviorBaseSupport - Probabilidades das acçõesAcções ProbabilidadesFollowBallOnDistance 0.473SearchBall 0.256Move2OppGoal 0.0265SearchShootingSpot1 0.0624Stop1 0.057SearchShootingSpot2 0.0667Stop2 0.0583

Tabela 15: BehaviorBaseSupport - Probabilidades dos predicadosPredicados ProbabilidadesAttackerDribbling2Goal 0.454NOTAttackerDribbling2Goal 0.546AttackerNearGoal 0.33NOTAttackerNearGoal 0.67NearGoal 0.834NOTNearGoal 0.166SeeBall 0.676NOTSeeBall 0.324ObstaclesAtGoal 0.533NOTObstaclesAtGoal 0.467ClosestToOppGoal 0.576NOTClosestToOppGoal 0.424

25.6% do tempo. Através do desenvolvimento deste comportamento, o tempo de procura

da bola diminui, tornando o jogo mais fluido;

• Durante 5.83% do tempo o robot está em condições de receber um passe curto, e durante

5.7% do tempo está em condições de receber um passe longo;

• Durante grande parte do tempo, 47.3%, o robot limita-se a seguir a bola, o que significa que

ainda podem ser acrescentados melhoramentos a este comportamento de modo a poder

trazer mais benefícios à equipa e ao jogo;

• Como os valores das taxas de transição foram retirados em simulação com dois robots, um

atacante e um apoiante, e como os adversários eram estáticos, é normal uma tão grande

quantidade de tempo em que o atacante possui a bola, 45.4% do tempo;

• A percentagem de tempo em que o robot está parado numa posição livre de obstáculos na

baliza, 5.7% + 5.83% = 11.53%, é inferior ao tempo total em que não encontra obstáculos

na baliza, 46.7%. Isto deve-se ao facto de que embora o robot não esteja à procura de

um local livre de obstáculos, devido às suas movimentações encontra-se em posições com

60

estas características.

É necessário ter em conta que estes valores de taxas de transição são apenas verdadeiros

para estas acções primitivas e predicados e apenas no simulador. Havendo a mudança de uma

acção primitiva ou de um predicado é normal que os valores das taxas de transição se alterem,

tal como os resultados, sendo que se pode chegar a conclusões mais, ou menos, satisfatórias.

6.3.4 BehaviorLongPassTaker

A análise desta rede não pode ser feita através do mesmo método da rede BehaviorBaseSup-

port, pois não evolui apenas com a mudança de valor dos predicados, mas também através de

eventos lançados pelo próprio comportamento, ou pelo comportamento do robot ao qual está

comprometido: quando termina uma macro, correspondendo ao evento GOAL_REACHED ou

GOAL_NOT_REACHED, ou quando uma acção primitiva lança um evento para a poder terminar.

Existem lugares com mais do que uma transição temporizada pronta a disparar, portanto os val-

ores das taxas de transição não estão relacionados apenas com o tempo médio de disparo, mas

estão também associados a uma probabilidade.

Existem duas macros nesta rede, AttackerLongPassCommitment e TakePass, que podem

terminar com o disparo de transições com o mesmo nome, GOAL_REACHED ou GOAL_NOT_-

REACHED. As transições serão distinguidas com a utilização de um índice 1 ou 2, para a macro

AttackerLongPassCommitment e a TakePass, respectivamente.

Foi necessário modelar a utilização do predicado StopLongPass de maneira diferente dos

predicados de BehaviorBaseSupport. Como o lugar NOT_StopLongPass apenas pode estar

marcado quando o lugar macro.TakePass está marcado, ambos terão a mesma transição de

entrada. É também necessário garantir que caso seja lançado o evento GOAL_REACHED2 ou

GOAL_NOT_REACHED2 o lugar NOT_StopLongPass perca o seu token. Isto levou a que a Rede

de Petri fosse modelada do modo ilustrado na Figura 17.

Os valores foram obtidos com dois robots no simulador, com um a executar o comportamento

BehaviorLongPassReceiver e outro o comportamento a analisar, BehaviorLongPassTaker. Na

atribuição dos valores das taxas de transição partiu-se dos seguintes pressupostos:

• As transições associadas a eventos lançados pela própria rede, são lançados quase in-

stantaneamente e têm um valor elevado. É o caso das transições COMMITMENT_BREAK,

61

Figura 17: Modelação LongPassTaker

BEHAVIOR_ENDED_SUCCESSFULLY e BEHAVIOR_ENDED_UNSUCCESSFULLY. Não

sendo possível calcular efectivamente o valor da taxa de disparo, foi o valor de 3.0, por se

tratar de um disparo quase instantâneo;

• As transições associadas a eventos lançados após comunicações entre robots, têm uma

taxa de transição menor que as mencionada do ponto acima, pois a troca de mensagens

induz um ligeiro atraso, mas mesmo assim são elevadas. É o caso da transição GOAL_-

REACHED1. Foi atribuído a esta transição uma taxa de disparo de 1.5, por demorar mais

tempo que as transições citadas no ponto acima, visto que implica comunicações entre

robots, mas sendo o seu disparo também quase instantâneo;

• A taxa de disparo de START_LONG_PASS foi determinado supondo que existem sempre

condições para efectuar o passe. Visto que pressupõe comunicações entre os dois robots,

foi atribuído também o valor de 1.5, e pelas mesmas razões;

• Os valores das taxas de disparo das transições GOAL_NOT_REACHED1, GOAL_NOT_-

REACHED2 e NOT_StopLongPass->StopLongPass foram determinados probabilisticamente,

62

em comparação com o número de vezes que dispararam as transições GOAL_REACHED1

e GOAL_REACHED2.

Nos resultados obtidos, para cada onze lançamentos do evento GOAL_REACHED1 da macro

AttackerLongPassCommitment foi lançado um evento de GOAL_NOT_REACHED1. Em cada

seis lançamentos do evento GOAL_REACHED2, foram lançados quatro GOAL_NOT_REACHED2

e dois NOTStopLongPass->StopLongPass.

O valor da taxa de disparo da transição GOAL_REACHED2 foi determinado através da fórmula

5, introduzida na Secção 6.3.3.

Os valores das taxas de disparo podem ser observados na tabela 16.

Tabela 16: BehaviorLongPassTaker - Taxas de TransiçãoTransições Taxas(eventos/un.tempo)START_LONG_PASS 1.5GOAL_REACHED1 1.5GOAL_REACHED2 0.167COMMITMENT_BREAK 3.0BEHAVIOR_ENDED_SUCCESSFULLY 3.0GOAL_NOT_REACHED1 0.1GOAL_NOT_REACHED2 0.111NOTStopLongPass->StopLongPass 0.0556BEHAVIOR_ENDED_UNSUCCESSFULLY 3.0

Os valores obtidos do vector de estado estacionário estão na tabela 17.

Tabela 17: BehaviorLongPassTaker - ProbabilidadesAcções ProbabilidadesStop 0,14201AttackerLongPassCommitment 0,1302TakePass 0,58579BreakCommitment 0,071SendBehaviorSuccessful 0,03255SendBehaviorUnsuccessful 0,03845

Como se pode observar, a macro TakePass tem a maior probabilidade, o que é o esperado,

pois é o único lugar onde são executadas primitivas de interacção com o ambiente, os outros

só executam primitivas de comunicação (ex. AttackerLongPassCommitment), ou apenas lançam

um evento de modo a permitir que a rede evolua (ex. SendBehaviorSuccessful). Através dos

resultados obtidos conclui-se também que a probabilidade de um passe longo terminar com

sucesso é de aproximadamente 45.9%. Isto deve-se sobretudo à probabilidade de existirem

63

obstáculos entre os dois robots, de o jogo ficar parado, de o outro robot desistir de fazer o passe,

ou de surgirem perdas de comunicação.

6.3.5 BehaviorShortPassTaker

A análise do comportamento BehaviorShortPassTaker obedece aos mesmos pressupostos que

o comportamento BehaviorLongPassTaker, pelo que não serão explicados quais os significados

das taxas de transição.

A principal diferença, é que neste caso, para cada sete lançamentos do evento GOAL_REA-

CHED2 foram lançados três eventos de GOAL_NOT_REACHED2 e dois eventos de NOTStop-

ShortPass->StopShortPass. Os valores obtidos encontram-se na tabela 18:

Tabela 18: BehaviorShortPassTaker - Taxas de TransiçãoTransições Taxas(eventos/un.tempo)START_SHORT_PASS 1.5GOAL_REACHED1 1.5GOAL_REACHED2 0.184COMMITMENT_BREAK 3.0BEHAVIOR_ENDED_SUCCESSFULLY 3.0GOAL_NOT_REACHED1 0.136GOAL_NOT_REACHED2 0.0789NOTStopShortPass->StopShortPass 0.0526BEHAVIOR_ENDED_UNSUCCESSFULLY 3.0

Os valores obtidos do vector de estado estacionário estão na tabela 19.

Tabela 19: BehaviorShortPassTaker - ProbabilidadesAcções ProbabilidadesStop 0,13744AttackerShortPassCommitment 0,12601TakePass 0,59911BreakCommitment 0.0687SendBehaviorSuccessful 0,03675SendBehaviorUnsuccessful 0,03197

Tal como esperado, a acção TakePass tem neste comportamento a maior probabilidade, pela

mesma razão que no comportamento de passe longo. Através dos resultados obtidos conclui-se

também que a probabilidade de um passe curto terminar com sucesso é de aproximadamente

53%. Este valor é maior que o do passe longo, pois, como será lógico, havendo um menor espaço

entre os dois robots, a probabilidade de existirem obstáculos entre eles é também menor.

64

7 Conclusões e trabalho futuro

Olhando para a análise dos comportamentos, conclui-se que os objectivos propostos para esta

dissertação, desenvolvimento de passes dinâmicos entre robots futebolistas, foi alcançado com

sucesso. Por outro lado constatou-se que a modelação de comportamentos relacionais através

de Redes de Petri tem um vasto potencial, e que a continuação de desenvolvimento de novos

comportamentos nesta linguagem é uma aposta segura, e que tem um grande valor científico,

pois permite aplicar esta solução a outras áreas da robótica.

Foi possível verificar que a arquitectura onde está inserido o código tem enormes capaci-

dades, mas que seria vantajoso que as comunicações pudessem permitir ao programador das

Redes de Petri abstrair-se da modelação de todo o processo de comunicação que antecede um

comportamento relacional, pelo que um melhoramento neste bloco seria, sem dúvida, uma mais

valia, e permitiria que as redes se tornassem menos complexas.

O principal contributo desta dissertação foi a introdução de uma metodologia para o desen-

volvimento de novos tipos de passes, para além do passe longo e do passe curto e a implemen-

tação destes novos comportamentos com sucesso no simulador. Também nos robots reais foi

possível demonstrar o seu funcionamento, embora em situações controladas, visto que existem

algumas limitações na percepção dos obstáculos e no drible do robot, sendo estas as principais

limitações do trabalho. Com o desenvolvimento de novas tecnologias e algoritmos, e devido ao

facto de o projecto SocRob estar em constante desenvolvimento e melhoramento, a execução de

comportamentos relacionais sistematicamente nos robots reais é algo que poderá ser alcançado

em breve.

Pode ainda concluir-se que uma análise do desempenho dos comportamentos através de

Cadeias de Markov permite retirar conclusões sobre as reais vantagens dos comportamentos

desenvolvidos, comparar comportamentos, e verificar onde podem ser efectuadas melhorias.

Sabendo quais as taxas de disparo de cada transição para cada acção, seria também possível

estimar qual o desempenho de novos comportamentos modelados.

Os resultados numéricos utilizados nesta dissertação foram obtidos apenas no simulador. Se-

ria vantajoso que fossem retirados resultados experimentais dos robots reais, de modo a serem

comparados com os do simulador, o que permitiria concluir sobre a qualidade e realismo do

simulador.

De futuro espera-se a continuação de desenvolvimento de novos passes dinâmicos entre

65

dois robots futebolistas, nomeadamente na situação em que o robot que possui a bola analisa

que não consegue driblar para a baliza contrária devido a obstáculos que encontra em frente

(robots adversários), ou mesmo implementar um compromisso entre três robots através de dois

passes consecutivos. Estes novos comportamentos, para além de poderem trazer vantagens

competitivas, seriam de grande valor científico, nomeadamente a última, pois necessitaria de

uma variante da metodologia utilizada nesta dissertação.

66

8 Bibliografia

Referências

[1] P. R. Cohen and H. J. Levesque. Teamwork. Nous, 35:487-512, 1991

[2] João Gonçalo Delgado Torres, Comportamentos Relacionais Para Robots Futebolistas:

Análise de Incerteza, Dissertação para obtenção do Grau de Mestre em Engenharia Elec-

trotécnica e de Computadores, Instituto Superior Técnico, 2007

[3] Tiago Miguel Baltazar Coelho de Moura Antunes, Comportamentos Relacionais Para Robots

Futebolistas: Análise Lógica, Dissertação para obtenção do Grau de Mestre em Engenharia

Electrotécnica e de Computadores, Instituto Superior Técnico, 2007

[4] Marco Alexandre Fagulha Barbosa, Development Environment for a Multi-Robot Team, Dis-

sertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores,

Instituto Superior Técnico, 2007

[5] Nelson Miguel Silva Ramos, Arquitectura de Comportamentos para Equipa Multi-Robot com

Coordenação por Arbitragem, Dissertação para obtenção do Grau de Mestre em Mestrado

em Engenharia Informática e de Computadores, Instituto Superior Técnico, 2007

[6] João Rafael Risso Milhinhos e Gonçalo Pais de Mouro Vaz, Comportamentos Relacionais

para Robots Futebolistas, Relatório de Trabalho Final de Curso da Licenciatura em Engen-

haria Informática e de Computadores, Instituto Superior Técnico, 2005

[7] Bob van der Vecht, Behaviour Coordination for Cooperative Multi-Robot Systems, Instituto

Superior Técnico, 2004

[8] T. Murata, Petri Nets: Properties, Analysis and Applications, Proc. of the IEEE, Vol. 77, No.

4, pp 541-580. 1989.

[9] N. Viswanadham and Y. Narahari., Performance Modeling of Automated Manufacturing Sys-

tems, Prentice Hall, New Jersey, 1992, 487-512

[10] Dejan Milutinovic e Pedro Lima, Petri net Models of Robotic Tasks, Proc. of the ICRA - IEEE,

Vol. 4, pp 4059- 4064. 2002

67

[11] Pedro Lima e Luis Custodio, Artificial Intelligence and Systems Theory: Applied to Coopera-

tive Robots, International Journal of Advanced Robotic Systems, Vol. 1, No. 3, pp 141-148,

2004

[12] Hugo Costelha e Pedro Lima, Modelling, Analysis and Execution of Robotic Tasks using Petri

Nets, Proc. of IROS - IEEE, 2007

[13] Hugo Costelha et al, ISocRob 2007 Team Description Paper, Instituto Superior Técnico, 2007

[14] Hans-Dieter Burkhard, Dominique Duhaut, Masahiro Fujita, Pedro Lima, Robin Murphy e

Raul Rojas, Past Progress Brings Us Towards a Research Road Map for Further Compe-

titions and Developments,IEEE robotics & automation magazine, Vol. 9, No. 2, pp. 31-38,

2002

[15] Mamoru Carlos Yamada, Arthur José Vieira Porto, Ricardo Yassushi Inamasu, Aplicação dos

conceitos de modelagem e de redes de Petri na análise do processo produtivo da indústria

sucroalcooleira, In: Pesquisa Agropecuária Brasileira, vol.37, no.6, p.809-820, 2002,

[16] Ming Chen, Andreas Freier, Jacob Köhler, Alexander Rüegg, The Biology Petri Net Markup

Language, Lecture Notes in Informatics - proceedings of Promise’2002, Vol. 21: 150-161

(2002)

[17] Alexandre Vidal Riso, Ricardo Vicente de Paula Rezende, Eugênio Simão, Luismar Marques

Porto, Modelagem de Vias Metabólicas com Redes de petri Híbridas, In: XIV Simpósio

Nacional de Fermentações - SINAFERM2003, Florianópolis/SC. 2003.

[18] Gunhee Kim, Woojin Chung, Sung-Kee Park, Munsang Kim, Experimental research of nav-

igation behavior selection using generalized stochastic Petri nets (GSPN) for a tour-guide

robot, IROS 2005, 2-6 Aug. 2005 Page(s): 2259 - 2265.

[19] Kurt Jensen: An Introduction to the Practical Use of Coloured Petri Nets. In: Lectures on Petri

Nets II: Applications, Lecture Notes in Computer Science vol. 1492, pp 237-292, Springer-

Verlag 1998.

68

A Redes de Petri dos Comportamentos Desenvolvidos

A.1 RoleAttacker

69

A.2 RoleSupporter

70

A.3 BehaviorBaseSupport

71

A.4 BehaviorLongPassTaker

72

A.5 BehaviorLongPassReceiver

73

A.6 BehaviorShortPassTaker

74

A.7 BehaviorShortPassReceiver

75

A.8 TakePass

76

A.9 CatchAndDribble2Partner

77

A.10 AttackerShortPassCommitment

78

A.11 SupporterShortPassCommitment

79

A.12 AttackerLongPassCommitment

80

A.13 SupporterLongPassCommitment

81

desenvolvimento e análise de comportamentos relacionais ......petri estocásticas generalizadas...

Documents