Faculdade de Engenharia da Universidade do Porto RoboCup 2010 - Criação de uma Equipa para a Liga Mixed Reality do RoboCup Hugo Filipe Pereira de Almeida Sarmento Mendes VERSÃO PROVISÓRIA Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Computadores Major Automação Orientador: Prof. Dr. Luís Paulo Reis 09/06/2010
Hugo Filipe Pereira de Almeida Sarmento Mendes, 2010 ii
Resumo A RoboCup é uma iniciativa internacional que fomenta a investigação em áreas como a inteligência artificial, sistemas multi-agente, agentes autónomos, robótica, fusão sensorial, coordenação de equipas e aquisição de estratégias. Esta federação é responsável por organizar anualmente, uma série de competições e demonstrações que têm lugar, cada ano, num local diferente do mundo. As principais competições dizem respeito ao futebol robótico, onde os agentes/robôs, reais ou virtuais, disputam um jogo de futebol, com regras idênticas às usadas pelos humanos. O terreno de jogo também ele pode ser real ou virtual. Desta forma, dentro do futebol robótico temos as seguintes competições: Simulation 2D League, Simulation 3D League, Small Size Robot League, Middle Size Robot League, Humanoide League, Standard Platform League e Mixed Reality League. Esta tese teve como objectivo criar uma equipa de raiz, para participar na liga Mixed Reality em Singapura no ano de 2010, dentro da equipa FCPortugal. No futebol robótico não só é importante o comportamento de cada agente como indivíduo, mas também o seu papel dentro de um objectivo comum. Para conseguir criar uma equipa é necessário começar pelo mais básico, dotar os agentes com a capacidade de actuarem sobre o mundo onde estão inseridos e dele obterem informação. Foi principalmente sobre estas duas questões que a presente tese teve como tema de estudo. No entanto, todos os temas relacionados com a criação completa de uma equipa de futebol robótico são abordados, incluindo, entre outros: percepção, acção, decisão individual e decisão colectiva (estratégia). iii
iv
Abstract The Robocup is an international initiative that promotes the research in areas such as artificial intelligence, multi-agent systems, autonomous agents, robotics, sensorial fusing and acquisition of strategies. This organization is responsible for organizing annually, a series of competitions and demonstrations that take place, each year, in a different place of the world. The main competitions are robotic soccer leagues, where the agents/robots, real or virtual, dispute a soccer match, using identical rules as for the human soccer. The game field also can be real or virtual. Inside of the robotic soccer we have the following competitions: Simulation 2D League, Simulation 3D League, Small Size Robot League, Middle Size Robot League, Humanoid League, Standard Platform League e Mixed Reality League. This thesis had the objective to create a team from scratch, to participate in the Mixed Reality league in Singapore in the year of 2010, inside the team FCPortugal. In the robotic soccer, the behavior of each agent is not only important as individual, but also its goal inside of a common objective. To create a robotic soccer team, it is necessary to start with the most basic things, to endow the agents with the capacity to act on the world where they are inserted and get information from it. These were mainly the questions that the present thesis studied. However, all the themes related with the complete creation of a robotic soccer team are approached including: perception, action, individual decision and collective decision (strategy). v
vi
Agradecimentos Queria agradecer a todos os elementos constituintes da FCPortugal e em especial, ao Prof. Dr. Luís Paulo Reis, pelo conhecimento que me passou, pela ajuda que me deu e pela oportunidade que me disponibilizou. Foi um prazer conviver e trabalhar com todos os elementos da FCPortugal, tendo sido preciosa a informação que deles pude obter. Recordarei com saudade estes últimos meses. Gostaria também de agradecer à Diana Guimarães pela ajuda e apoio que me deu. Este projecto foi parcialmente suportado pela FEUP/DEI - Departamento de Engenharia Informática e pelo LIACC Laboratório de Inteligência Artificial e Ciência de Computadores da Universidade do Porto. vii
viii
Índice Resumo... iii Abstract... v Agradecimentos... vii Índice... ix Lista de figuras... xii Lista de tabelas... xiv Abreviaturas... xv Capítulo 1- Introdução... 16 1.1 Enquadramento e Motivação... 16 1.2 Objectivos... 18 1.3 Estrutura da tese... 18 Capítulo 2 - Agentes e Sistemas Multi-Agente... 2.1 Agentes... 19 2.1.1 Agentes Autónomos... 19 2.1.1.1 Autonomia... 21 2.1.1.2 Reactividade... 21 2.1.1.3 Pró-Actividade... 22 2.1.1.4 Habilidade Social... 22 2.1.2 Ambiente... 22 2.1.3 Atributos dos Agentes... 23 2.2 Sistemas Multi-Agente... 23 2.3 Conclusões... 25 Capítulo 3 - A Liga "Mixed Reality"... 26 3.1 Introdução... 26 3.2 O terreno de jogo... 27 3.3 Regras do jogo... 27 ix
3.4 O robô real... 30 3.5 O sistema da Mixed Reality... 32 3.6 Simulador... 34 3.6.1 Introdução... 34 3.6.2 MR-Simulator... 35 3.6.2.1 Simulação do ambiente... 35 3.6.2.2 Simulação dos Robôs... 36 3.7 Conclusões... 36 Capítulo 4 - Desenvolvimento do Agente... 38 4.1 - Ficheiros... 38 4.2 - Metodologia para a criação da equipa... 39 4.3 - Ficheiro WorldData... 39 4.3.1 - GetFieldDimensions()... 40 4.3.2 - GetMyPosition()... 41 4.3.3 - GetMyOrientation()... 42 4.3.4 - GetBallPosition()... 43 4.3.5 - GetPlayerPosition()... 44 4.3.6 - IamClosestToBall()... 44 4.3.7 - CentroBaliza()... 45 4.4 - Ficheiro BasicPlayer... 45 4.4.1 - GoToXY(double xx, double yy)... 46 4.4.2 - KickXY(Vector FinalPos)... 47 4.4.3 - Goalie()... 47 4.5 - Ficheiro SampleAgent... 48 4.6 Conclusões... 49 Capítulo 5 - Desenvolvimento da Estratégia da Equipa... 50 5.1 - Ficheiro strategy.conf.mr... 50 5.2 - Posicionamento estratégico... 54 5.3 - Matrizes de fluxo... 56 5.4 - Segurança... 58 5.5 - Conclusões... 58 Capítulo 6 - Testes e análise de resultados obtidos... 59 6.1 Teste das funções do WorldData... 59 6.1.1 Teste da função GetFieIdDimension()... 60 6.1.2 Teste da função GetMyPosition()... 60 6.1.3 Teste da função GetBallPosition()... 61 x
6.1.4 Teste da função GetPlayerPosition()... 61 6.1.5 Teste da função GetMyOrientation()... 62 6.2 Teste das funções do BasicPlayer... 62 6.2.1 Teste da função GoToXY(double xx, double yy)... 62 6.2.2 Teste da função KickXY(Vector FinalPos)... 63 6.3 Análise global aos resultados obtidos... 64 6.3.1 Formação com dois avançados e dois defesas.... 66 6.3.2 Formação com quatro avançados... 69 6.3.3 Formação com três avançados e um defesa... 73 6.4 Análise global aos resultados obtidos... 76 7 Conclusões e Trabalho Futuro... 79 7.1 Conclusões... 79 7.2 Trabalho futuro... 80 Referências... 81 xi
Lista de figuras Figura 1: Esquema Típico de um Agente, [Reis, 2003]... 20 Figura 2: Estrutura genérica de um Sistema Multi-Agente [Reis, 2003].... 25 Figura 3: Terreno de jogo... 27 Figura 4: Robô utilizado na "Mixed Reality" e suas respectivas dimensões (em milímetros)... 31 Figura 5: Discretização das velocidades. [SourceForge, 2010b]... 31 Figura 6: Arquitectura da "Mixed Reality"... 32 Figura 7: Estrutura do sistema da Mixed Reality [Gerndt e Guerra, 2008]... 33 Figura 8: Ciclo principal do MR-Simulator, [Simões, 2010]... 35 Figura 9: Informação básica disponível [Lau e Reis, 2007b]... 40 Figura 10: Cálculo das dimensões do campo... 41 Figura 11: Cálculo da posição do agente... 41 Figura 12: Cálculo da orientação... 42 Figura 13: Cálculo da posição absoluta da bola... 43 Figura 14: Vectores necessários para a função IamClosestToBall()... 44 Figura 15: Cálculo de CentroBaliza()... 45 Figura 16: Vector em coordenadas polares para o destino... 46 Figura 17: Posição ideal para o guarda-redes... 47 Figura 18: Posição dos jogadores com a bola no ponto 1... 55 xii
Figura 19: Posição dos jogadores com a bola no ponto 2... 55 Figura 20: Posição dos jogadores com a bola entre o ponto 1 e 2... 55 Figura 21: Malha para definição de fluxo... 56 Figura 22: Matriz de fluxo... 57 Figura 23: Teste da função GetMyPosition()... 60 Figura 24: Teste da função GetPlayerPosition()... 62 Figura 25: Teste da função GoToXY(double xx, double yy)... 63 Figura 26: BahiaMR ao ataque... 64 Figura 27: BahiaMR à defesa... 65 Figura 28: Matriz de fluxo com preferência pelo centro (fluxo central)... 65 Figura 29: Matriz de fluxo com preferência pelas alas (fluxo lateral)... 66 Figura 30: Equipa à defesa com bola no centro... 66 Figura 31: Equipa à defesa com bola na lateral... 67 Figura 32: Equipa ao ataque com bola no centro... 67 Figura 33: Equipa ao ataque com bola pela lateral... 67 Figura 34: Equipa à defesa com a bola no corredor central... 70 Figura 35: Equipa à defesa com a bola numa posição lateral... 70 Figura 36: Equipa ao ataque com bola pelo corredor central... 70 Figura 37: Equipa ao ataque com bola numa posição lateral... 71 Figura 38: Equipa à defesa com a bola numa posição central... 73 Figura 39: Equipa à defesa com a bola numa posição lateral... 73 Figura 40: Equipa ao ataque com a bola no centro... 74 Figura 41: Equipa ao ataque com a bola junto à linha lateral... 74 xiii
Lista de tabelas Tabela 1 - Dimensões do campo... 60 Tabela 2 - Resultados da função GetBallPosition()... 61 Tabela 3 - Resultados da função KickXY ()... 63 Tabela 4 - Resultados obtidos com dois avançados e fluxo central... 68 Tabela 5 - Estatística com dois avançados e fluxo central... 68 Tabela 6 - Resultados obtidos com dois avançados e fluxo lateral... 69 Tabela 7 - Estatística com dois avançados e fluxo lateral... 69 Tabela 8 - Resultados obtidos com quatro avançados e fluxo central... 71 Tabela 9 - Estatística com quatro avançados e fluxo central... 72 Tabela 10 - Resultados obtidos com quatro avançados e fluxo lateral... 72 Tabela 11 - Estatística com quatro avançados e fluxo lateral... 72 Tabela 12 - Resultados obtidos com três avançados e fluxo central... 75 Tabela 13 - Estatística com três avançados e fluxo central... 75 Tabela 14 - Resultados obtidos com três avançados e fluxo lateral... 76 Tabela 15 - Estatística com três avançados e fluxo lateral... 76 Tabela 16 - Resultados gerais (V - Vitórias; E - Empates; D - Derrotas; GM - Golos Marcados; GS - Golos Sofridos)... 77 xiv
Abreviaturas ARM AVR FEUP ID IEEE IrDA LCD MR ODE USB XML Advanced RISC Machine Advanced Virtual RISC Faculdade de Engenharia da Universidade do Porto Identity Instituto de Engenheiros Electricistas e Electrónicos Infrared Data Association Liquid Crystal Display Mixed Reality Open Dynamics Engine Universal Serial Bus Extensible Markup Language xv
Capítulo 1 Introdução 1.1 Enquadramento e Motivação A Robocup é uma iniciativa internacional que fomenta a pesquisa em áreas como a inteligência artificial, sistemas multi-agente, agentes autónomos, robótica, fusão sensorial e aquisição de estratégias. Esta organização é responsável por organizar anualmente uma série de competições e demonstrações que têm lugar, cada ano, num diferente local do mundo. A principal competição é o futebol robótico onde os agentes/robôs, reais ou virtuais, disputam um jogo de futebol, com regras idênticas às usadas pelos humanos. O terreno de jogo também ele pode ser real ou virtual. A competição RoboCup teve na sua génese o futebol e actualmente está dividida em quatro grandes áreas: RoboCup Soccer, RoboCup Rescue, RoboCup Júnior e RoboCup @Home [RoboCup, 2010]. O RoboCup Soccer (Futebol Robótico) está dividido em dois tipos de ligas: Robótica e Simulação. Por sua vez a liga Robótica subdivide-se em: Robôs Pequenos, Robôs Médios, Robôs com Pernas (robôs quadrúpedes AIBO da Sony) e Humanóides. As ligas de Simulação estão divididas em: Simulação 2D, Simulação 3D (com robôs humanóides) [Boedecker and Asada, 2008], Realidade Mista (robôs Ecobes da Citizen), e outros desafios (incluindo a liga de treinadores e demonstrações) [RoboCup, 2010].
Cada uma destas ligas tem características próprias que oferecem diferentes desafios às equipas participantes. Por exemplo, nas ligas de simulação, especialmente na liga 2D, é dado maior ênfase à coordenação de Sistemas em Multi-Agente; já na liga de robôs pequenos o destaque está no controlo rápido e preciso dos robôs, enquanto que na liga de robôs médios os tópicos mais importantes incluem a visão computacional, projecto electromecânico e auto-localização dos robôs. O RoboCup propõe novos desafios para além do futebol robótico, como o RoboCup Rescue (RoboCup de Salvamento) que tem como finalidade promover a investigação e desenvolvimento em cenários de desastre, muito útil para a actual sociedade. O RoboCup Rescue tem como objectivo integrar informação de desastres em sistemas de decisão de emergência, previsão, planeamento e interface humana. A maior parte dos conceitos do futebol podem ser aplicados neste domínio, pois ambos têm um ambiente multi-agente, as metodologias de coordenação, entre outras similaridades. O RoboCup Rescue compreende três ligas: RoboCup Rescue Simulation (Simulação de desastre), RoboCup Rescue Virtual Competition (Simulação de robôs reais) e o RoboCup Rescue Robot Competition (Robôs reais) [RoboCup, 2010]. O RoboCup Júnior permite que jovens estudantes (de escolas primárias e secundárias) e estudantes universitários possam participar neste projecto, abrangendo também outros domínios além do futebol tal como a dança e acções de salvamento em cenários de desastre [RoboCup, 2010]. No âmbito do RoboCup também foi criada a liga RoboCup@Home cujo objectivo é o uso de metodologias robóticas para o desempenho de tarefas domésticas. Neste contexto as aplicações oriundas do RoboCup inovam outros domínios, como por exemplo o futebol, a dança, o salvamento em cenários de desastre e os edifícios inteligentes. Portugal, desde o ano 2000, participa nas competições internacionais do RoboCup, com o uso de um sistema multi-agente, totalmente funcional, denominado por FC Portugal. Este sistema foi desenvolvido por uma colaboração entre a Universidade do Porto e a Universidade de Aveiro. A equipa FC Portugal tem obtido excelentes resultados na competição RoboCup. Conquistou a vitória em cinco campeonatos da Europa e em três campeonatos do Mundo de Futebol Robótico Simulado [Reis 2003]. Tais conquistas motivaram o uso do FC Portugal para a previsão das formações das equipas no futebol robótico simulado nesta investigação, tendo em vista o desenvolvimento de uma metodologia de classificação. 17
1.2 Objectivos O objectivo geral desta tese consiste em criar uma equipa de futebol robótico para participar no Robocup 2010 - Singapura, na categoria de demonstração Mixed Reality. De forma a atingir este objectivo, foram definidos os seguintes objectivos: Estudo sobre sistemas multi-agente, RoboCup e sobre as diferentes ligas da RoboCup; Estudo da Liga Mixed Reality e do simulador Mixed Reality; Implementação dos movimentos básicos dos agentes; Implementação de um estado do mundo para os agentes contendo a sua localização e orientação absoluta; Implementação do cálculo da velocidade da bola, posições e velocidades dos TeamMates e Oponnents. Implementação do posicionamento estratégico e de formações; Criação do guarda-redes e da primeira equipa base incluíndo algorítmos de decisão para os agentes; Incorporação na Mixed Reality de conceitos definidos pela FC Portugal para outras ligas: Matchflow, Setplays [Conceição et al., 2006] [Lau e Reis, 2006] [Lopes, 2009], Strategy (funções de decisão de alto nível) Pretende-se no final obter uma equipa totalmente funcional para a Mixed Reality, capaz de competir nesta liga no RoboCup. 1.3 Estrutura da tese Esta tese é constituída por seis capítulos, sendo o primeiro composto por esta introdução ao trabalho. No segundo capítulo é feita uma breve explicação sobre o significado do termo Agente e de Sistemas Multi-Agente. O capítulo três aborda a Liga Mixed Reality, como é composto o sistema de jogo e quais as suas regras. O capítulo quatro tem no seu conteúdo a principal parte do trabalho desenvolvido. Estão referenciadas as principais funções de baixo nível que são parte constituinte de todos os agentes. O capítulo cinco apresenta as possibilidades de ajuste nas funções de mais alto nível e como isso pode ser feito. O capítulo seis apresenta os testes efectuados para validar o trabalho feito. São também feitos os comentários aos resultados obtidos. O último capítulo contém as conclusões gerais do trabalho e as perspectivas de desenvolvimento. 18
Capítulo 2 Agentes e Sistemas Multi-Agente 2.1 Agentes Um agente é uma entidade que toma decisões de forma autónoma, recorrendo a sensores para obter informação sobre o mundo onde "habita" e fazendo uso de actuadores para sobre ele agir. 2.1.1 Agentes Autónomos A conceptualização, especificação e implementação de Agentes Autónomos é matéria constituinte de uma disciplina derivada essencialmente da Inteligência Artificial cuja investigação científica teve grandes desenvolvimentos nos últimos anos. Os agentes são aplicados nas mais diversas áreas que variam desde a interacção homem-máquina até complexos processos de controlo industrial. Devido ao elevado número de aplicações e à relativa abertura do conceito, existem diversas definições de Agente e não existe um consenso alargado entre os autores da área sobre esta matéria. No entanto, baseando-nos no trabalho de Pattie Maes [Chavez e Maes, 1996], uma primeira e simples definição de agente é: Um sistema computacional que habita um dado ambiente, sente e age nesse ambiente, e ao fazê-lo realiza um conjunto de objectivos ou tarefas para o qual foi projectado [Reis, 2003]. 19
Embora não exista uma definição consensual do conceito de agente, existe a noção de que a autonomia é essencial num agente. Baseados nesta noção central de autonomia e nos trabalhos de Wooldridge e Jennings [Wooldridge e Jennings, 1995] [Wooldridge, 2002], Pattie Maes [Chavez e Maes, 1996] e Russel e Norvig [Russel e Norvig, 1995], iremos adoptar a seguinte definição de agente: Um Agente é um sistema computacional, situado num dado ambiente, que tem a percepção desse ambiente através de sensores, tem capacidade de decisão, age de forma autónoma nesse ambiente através de actuadores, e possui capacidades de comunicação de alto-nível com outros agentes e/ou humanos, de forma a desempenhar uma dada função para a qual foi projectado. [Reis, 2002] A definição apresentada diz-nos que um agente é um sistema computacional que se encontra situado num dado ambiente. Este ambiente pode ser uma parte do mundo real (universidade, fábrica, hospital, campo de futebol, etc.), um ambiente simulado ou mesmo um computador. Os agentes mais vulgares são os agentes de software. No entanto, os agentes podem ter uma existência física (possuíndo um corpo), designando-se nesse caso por agentes robóticos. Independentemente do tipo de agente e ambiente, essencial na definição de agente que adoptamos, é sempre importante a capacidade do mesmo se aperceber do ambiente e nele agir de forma autónoma. Desta forma, o agente deve possuir sensores e actuadores apropriados ao seu ambiente e à execução das tarefas para as quais foi projectado. A figura 1 apresenta um esquema típico de um agente. Figura 1: Esquema Típico de um Agente, [Reis, 2003] Uma das definições de agente mais conhecidas e aceites na comunidade é apresentada por Wooldridge e Jennings [Wooldridge e Jennings, 1995] que definem um agente como uma peça de hardware ou (mais usual) um sistema computacional baseado em software que goza das seguintes propriedades: Autonomia. Os agentes operam sem a intervenção directa de humanos ou outros agentes e possuem algum tipo de controlo sobre as suas acções e estado interno; Reactividade. Os agentes têm a percepção do seu ambiente e respondem rapidamente às alterações que nele ocorrem; Pró-Actividade. Os agentes não se limitam a agir em resposta ao seu ambiente. Eles são capazes de tomar a iniciativa e exibir comportamento direccionado por objectivos; 20
Habilidade Social. Os agentes são capazes de interagir com outros agentes (e possivelmente com humanos) através de uma dada linguagem de comunicação de agentes. 2.1.1.1 Autonomia Dentro do grupo de investigação na área dos agentes inteligentes, a autonomia é uma das características mais consensuais como forma de definir o conceito de agente. Quanto maior for a autonomia do agente, maior vai ser a sua capacidade de agir por iniciativa própria, não necessitando que haja uma mudança no meio onde ele se insere ou a recepção de instruções por parte de outrém, como um agente ou um humano, para agir. Huhns e Singh [Huhns e Singh, 1997] classificam a autonomia dos agentes em cinco tipos distintos: Autonomia Absoluta. O agente possui controlo completo sobre as suas percepções, raciocínio e acções, e é muito pouco previsível; Autonomia Social. O agente conhece os outros agentes presentes no sistema e é sociável, exercendo no entanto a sua autonomia em certas circunstâncias. A autonomia está em tensão natural com a coordenação ou com outras noções de alto-nível tais como compromissos; Autonomia de Interface. Em grande parte dos sistemas, onde a autonomia absoluta é impossível, a autonomia máxima possível para o agente é a autonomia respeitante à sua forma de interface com o exterior; Autonomia de Execução. Liberdade que o agente possui na execução de acções no ambiente; Autonomia de Projecto. Grau de autonomia dos projectistas do agente na sua construção. Quanto maior for a autonomia de projecto, maior poderá ser a heterogeneidade dos agentes. Segundo Foner [Foner, 1993], existem três requisitos básicos que os agentes devem ter, de forma a obterem um elevado nível de autonomia: capacidade de execução de acções periódicas, execução espontânea e iniciativa própria. Com base nestes requisitos, o agente adquire a capacidade de agir de forma independente, o que poderá trazer benefícios para o utilizador. 2.1.1.2 Reactividade Por reactividade entende-se a capacidade de um agente reagir a mudanças no ambiente que o cercam. Um agente com maior reactividade é aquele que mais rapidamente reage a alterações externas. A única forma de um agente ser reactivo é ser dotado de mecanismos que permitam absorver informação sobre o meio envolvente e ter as ferramentas necessárias para sobre ele agir. Esta é uma 21
característica dos agentes que está presente em quase todas as definições de agente [Wooldridge e Jennings, 1994], [Russel e Norvig, 1995], [Franklin e Graesser, 1996]. No entanto, Russel e Norvig [Russel e Norvig, 1995], definem um agente reactivo quando este utiliza planeamento reactivo e regras de condição-acção para definir o seu comportamento. Apesar de a reactividade ser uma característica desejável num agente, ele não deve ser puramente reactivo, já que iria reagir continuamente às mudanças externas, sem a preocupação com os seus objectivos finais. 2.1.1.3 Pró-Actividade A pro-actividade é a capacidade de iniciativa de que um agente é dotado. Um agente pro-activo toma acções de forma a concretizar os seus objectivos e não exclusivamente resultantes de mudanças do meio externo. 2.1.1.4 Habilidade Social Este atributo representa a capacidade de um agente interagir com os outros agentes. Segundo Genesereth e Ketchpel [Genesereth e Ketchpel, 1994], um agente deve possuir a capacidade de comunicar com os outros agentes, numa linguagem de alto-nível. Para esta comunicação ser possível, torna-se necessário que os agentes compartilhem o mesmo vocabulário com a mesma semântica. Para além desta condição, é necessário também que haja um meio por onde os agentes possam comunicar, ou seja, é necessário fornecer ao agente os actuadores apropriados a esta função. Esta comunicação não está restrita apenas à interacção entre agentes. Segundo Franklin e Graesser [Franklin e Graesser, 1996], os agentes podem inclusive comunicar com humanos. 2.1.2 Ambiente O ambiente é o local onde o agente tem a possibilidade de obter informação e agir. Assim, conforme a acção que o projectista deseja para um determinado agente, é necessário avaliar quais as acções possíveis e que informação pode o agente retirar do ambiente onde "habita". Uma forma de classificar as propriedades de um agente é a sugerida por Russel e Norvig [Russel e Norvig 1995], onde se pode distinguir as seguintes classes: Acessível vs. Inacessível. Um ambiente acessível é aquele onde um agente consegue obter, através dos seus sensores, informação actualizada, precisa e completa sobre o ambiente. Grande parte dos ambientes típicos não são acessíveis neste sentido. Entre os ambientes inacessíveis destacam-se a Internet e todos os ambientes físicos reais. Determinístico vs. Não determinístico. Num ambiente determinístico cada acção tem um efeito único garantido, não existindo qualquer incerteza quanto ao resultado da sua execução. 22
Estático vs. Dinâmico. Um ambiente estático é suposto permanecer inalterado enquanto o agente decide a próxima acção a executar. Em contraste, num ambiente dinâmico outros agentes encontram-se a agir no ambiente ao mesmo tempo. Todos os ambientes físicos do mundo real e a Internet são dinâmicos neste sentido. Discreto vs. Contínuo. Um ambiente diz-se discreto se existe um número finito de percepções e acções possíveis para o agente e contínuo caso contrário. Um ambiente pode ser contínuo no que diz respeito às percepções do agente e discreto no que diz respeito às acções (e vice-versa). A qualidade das decisões por parte dos agentes está fortemente relacionada com a informação que este consegue adquirir do ambiente, tanto em quantidade como em qualidade. Quanto à acessibilidade de um ambiente, não existem apenas duas possibilidades (acessível/não acessível). Num ambiente inacessível, é necessário averiguar qual o grau de acessibilidade. Como vimos, um ambiente físico é inacessível, no entanto é possível obter alguma informação dele, apesar de essa informação poder estar desactualizada e ser pouco precisa. Desta forma, devem ser fornecidos aos agentes metodologias capazes de minimizar estes erros, de forma a não comprometer as suas decisões. 2.1.3 Atributos dos Agentes Um agente pode ser definido a partir de um conjunto de características básicas. Tendo como base este conjunto de características, podemos agrupar os agentes em diferentes classes ou tipologias. No entanto, não é necessário que o agente possua todas as características ou atributos da classe onde está inserido, embora as suas capacidades estejam relacionadas com elas. Assim, conforme a função que o agente irá desempenhar, quem projecta deve escolher os atributos necessários. 2.2 Sistemas Multi-Agente Uma das áreas de incidência da Inteligência Artificial Distribuída e Robótica Inteligente é a construção de sistemas autónomos e cooperativos, com vista à resolução de um problema global. O agente é o elemento computacional activo desses sistemas autónomos. A área da investigação designada por agentes autónomos surgiu inspirada nas áreas científicas da Inteligência Artificial, Engenharia do Software, Sistemas Distribuídos e Redes de Computadores, Sociologia, Teoria dos Jogos e Economia [Reis, 2003]. Aliás é notório na Engenharia de Software a evolução dos paradigmas de programação. Primeiro surgiu a programação monolítica, depois a programação estruturada, depois a programação por objectos e por último, ainda sem grande expressão no mercado, a programação por agentes. 23
Os agentes possuem capacidade de decisão autónoma, são capazes de comportamento reactivo, pró-activo, social e possuem um fluxo de controlo próprio distinto dos restantes agentes que compõem um dado sistema multi-agente [Lesser, 1999]. Para se perceber o conceito de agente é importante a descrição dos atributos, da arquitectura e das suas capacidades. O trabalho em equipa, que os agentes podem desenvolver com outros agentes e/ou humanos, é uma das grandes mais-valias deste paradigma. Daí é fundamental saber como é que eles podem interagir, cooperar e raciocinar em função do ambiente que os rodeia, ou seja, como podem construir sociedades de agentes os sistemas de multi-agente. Os sistemas multi-agente exibem um comportamento autónomo mas ao mesmo tempo interagem com os outros agentes presentes no sistema, e/ou trabalham em conjunto de forma a satisfazer um determinado objectivo. Estes agentes exibem duas características fundamentais: serem capazes de agir de forma autónoma tomando decisões que conduzam à satisfação dos seus objectivos; serem capazes de interagir com outros agentes utilizando protocolos de interacção social inspirados nos humanos e incluindo pelo menos algumas das seguintes funcionalidades: coordenação, cooperação, competição e negociação [Reis, 2003]. A interacção é fundamental numa sociedade de agentes. Para isso é necessário saber coordená-los uns com os outros. Os sistemas multi-agente computacionais contêm agentes que interagem entre si, sejam agentes homogéneos ou agentes heterogéneos, o que permite que seja possível poder transportar para um ambiente de simulação aquilo que se passa no mundo real. Cada agente é um elemento capaz de reagir e ajudar a resolver problemas cooperando com outros agentes. Para que um agente possa ser parte integrante de um sistema é necessária a existência de uma infra-estrutura que permita a comunicação e a interacção entre os vários agentes que compõem o sistema multiagentes, conforme se observa na figura 2 [Reis, 2003]. A figura 2 apresenta a estrutura de um sistema multi-agente com determinados agentes (homogéneos e/ou heterogéneos [Beaudry et al., 2006]). Cada agente tem influência em determinadas zonas do seu ambiente, sendo por vezes necessário verificar qual a interacção entre todos os agentes envolvidos. Essa interacção pode ser um conjunto de relações, de operações, aliás toda a ênfase que o paradigma da orientação por objectos já possuía. Segundo Lesser, [Lesser, 1999] a investigação em sistemas multi-agente desenvolve princípios e modelos computacionais para construir, descrever, implementar e analisar as melhores formas de interacção e coordenação de agentes, em sociedades de reduzida ou de elevada dimensão. Como foi afirmado por Reis [Reis, 2003], um dos grandes desafios nesta área de investigação é a criação de metodologias que permitam que uma equipa de agentes trabalhe harmoniosamente em conjunto, ou seja, que a coordenação entre os diversos agentes seja efectuada de modo eficiente. 24
Figura 2: Estrutura genérica de um Sistema Multi-Agente [Reis, 2003]. 2.3 Conclusões Neste capítulo foi apresentada uma descrição dos conceitos de agente e sistema multi-agente. No âmbito do RoboCup estes conceitos são essenciais. O ambiente de quase todas as ligas do RoboCup e em particular da Mixed-Reality é um ambiente multi-agente, dinâmico, não determinístico e contínuo, muito mais complexo que os ambientes de outros domínios tradicionais tais como o Xadrez. 25
Capítulo 3 A Liga "Mixed Reality" 3.1 Introdução A Liga "Mixed Reality" não é ainda considerada, no presente ano 2010, uma Liga integrante da RoboCup Soccer. Até a esta edição a Liga é considerada uma Liga de Demonstração, ou seja, uma Liga que tenta demonstrar nova ideias e conceitos para futuros torneios e áreas de pesquisa. O objectivo desta Liga é fazer a ponte entre as Ligas simuladas e as Ligas com robôs físicos [Reis, 2003], [Stapleton, 2002] e [Azuma, 1997]. Segundo o continuum real-virtual de Milgram [Milgram, 1994a] [Milgram, 1994b] [Stapleton, 2002], as realidades mistas estão divididas entre a realidade aumentada e a virtualidade aumentada. Enquanto na realidade aumentada temos a inserção de objectos virtuais no mundo real, na virtualidade aumentada temos a inserção de objectos reais no mundo virtual. A competição Mixed Reality da RoboCup é considerada virtualidade aumentada, uma vez que os robôs (objectos reais) são inseridos num ambiente virtual. 26
3.2 O terreno de jogo O campo é projectado num LCD de 42 polegadas. Tem uma dimensão de 80,6cm 46.0cm, tendo as balizas 15cm entre os postes, tal como pode ser observado na figura 3. Figura 3: Terreno de jogo 3.3 Regras do jogo No futebol robótico tenta-se respeitar ao máximo as regras usadas nos jogos disputados por humanos. As regras da "Mixed Reality" para 2010 são: Autonomia. Durante o jogo os robôs devem mover-se de forma autónoma. É proibido o envio de informação para os robôs que não seja enviada através do servidor oficial. Os clientes só podem comunicar com o servidor fornecido pela organização. Comunicação implícita (como um robô rodar sobre si mesmo para demonstrar que está pronto a receber a bola) é permitido. Duração do jogo. O jogo é constituído por duas partes de 10 minutos, com um intervalo de 10 minutos entre cada parte. Quando o jogo pára por ordem do árbitro, o relógio também é parado. Durante o intervalo as equipas podem fazer alterações ao seu código, mas se não se voltarem a conectar até o fim do intervalo, considera-se que a equipa desistiu. Se antes do fim do intervalo ambas as equipas estiverem prontas para recomeçar o jogo, este é recomeçado imediatamente. Máxima diferença de golos. Se a diferença de golos entre as duas equipas for maior que 10, o jogo acaba imediatamente. Escolha de campo. O árbitro irá lançar uma moeda ao ar por forma a decidir qual a equipa a escolher o seu lado do campo de jogo. No intervalo as equipas trocam de posição. 27
Número máximo de jogadores. Cada equipa pode ter um máximo de 5 jogadores. Este valor, assim como o tamanho do campo, pode variar antes do torneio começar. É esperado que as equipas se adaptem a estes contratempos. Bola, pontapé de baliza, pontapé de canto. A bola é virtual e encontra-se representada na superfície de jogo. A bola nunca se considera fora se passar das linhas laterais, mas o jogo irá parar se atravessar as linhas finais. Quando isto acontece, o servidor automaticamente identifica se é uma situação de pontapé de baliza ou pontapé de canto. Quando dois jogadores chutam a bola ao mesmo tempo para fora do campo, o servidor considera pontapé de baliza. Tanto no caso do pontapé de baliza, como no pontapé de canto, a bola é colocada na posição correcta automaticamente. O árbitro irá pedir à equipa atacante para colocar um robô perto da bola e a equipa que defende deve colocar os seus robôs a uma distância mínima de 15cm da bola. No caso do pontapé de baliza a equipa que defende só pode mover um robô e a equipa atacante deve colocar todos os seus robôs atrás da linha de meio campo. Desistência. Em caso de desistência considera-se que a equipa perde por 10:0. Golos. Os golos são contados pelo servidor. O árbitro pode cancelar um golo, se tiver boas e justas razões para isso. Neste caso, o árbitro deve pedir ao operador para proceder ao cancelamento do golo. Timeouts. Cada equipa pode pedir um desconto de tempo de duração máxima de dois minutos. O pedido deve ser feito ao árbitro que o irá conceder numa altura em que o jogo esteja parado (i.e., o jogo não é parado só porque uma equipa pede um timeout). Durante o intervalo de tempo, ambas as equipas podem fazer alterações ao seu código, corrigir problemas de conexão, mudar ids, etc. No entanto, a equipa deve voltar a conectar-se antes do tempo de desconto acabar. Se tal não ocorrer, considera-se que a equipa desistiu do jogo. Movimentação de jogadores. Os operadores e membros da equipa só podem mexer nos seus robôs se tiverem a autorização do árbitro. Este último pode mover manualmente os robôs, caso considere necessário para o bom desenrolar do jogo (dois robôs ficam presos um no outro, por exemplo). Pontos. Por cada jogo, uma vitória oferece 3 pontos, um empate 1 ponto e uma derrota 0 pontos. Preliminares. Nesta primeira fase, todas as equipas vão jogar umas contra as outras. As melhores equipas vão passar à fase seguinte. Comparação de equipas. As equipas são comparadas pela seguinte ordem de factores: Pontuação total, número de vitórias, diferença entre golos marcados e sofridos, golos marcados e comparação do resultado entre duas equipas. Se nesta altura as equipas continuarem empatadas, o desempate é feito por moeda ao ar. 28
Playoffs. O número de equipas que chegam a esta fase irá depender do número total de equipas e da quantidade de campos e tempo disponível. Nos jogos de playoff, em caso de empate, será dado um tempo adicional de 10 minutos, após um intervalo de 5 minutos. Se depois deste tempo extra o resultado continuar empatado passa-se à marcação de grandes penalidades. Cada equipa poderá rematar 5 vezes, sendo a bola colocada no centro do campo. A primeira equipa a rematar será escolhida por moeda ao ar. A equipa que vai rematar pode colocar o seu robô em qualquer ponto do campo, ao passo que a equipa que defende deve colocar o seu robô na linha de golo. O robô que defende pode mover-se livremente, mas não deve tocar na bola antes do adversário, se tal ocorrer, é considerado golo. Se ao fim dos 5 remates por equipa, o jogo continuar empatado, procede-se a mais uma ronda. A equipa que atacou primeiro, é agora a primeira a defender. Nesta segunda fase, as equipas só tem uma hipótese de recuperar o resultado, se falhar, a outra equipa é declarada vencedora. Se depois desta fase o jogo continuar empatado, são usados os mesmos critérios que na fase preliminar. Se mesmo assim o empate continuar, o vencedor será seleccionado por moeda ao ar. Faltas. Compete ao árbitro assinalar qualquer falta. Quando uma falta ocorre, o árbitro irá pedir ao operador que faça uma pausa no jogo. A bola fica no mesmo ponto onde estava quando o jogo foi parado. À equipa que sofreu a falta será dada uma posição privilegiada, isto é, poderão colocar os seus robôs mais perto da bola. Exemplos de faltas são: o Rodear a bola com jogadores de tal forma que a outra equipa não pode aceder a esta. o Segurar ou bloquear a bola contra o limite de campo. o Bloquear a passagem dos jogadores da equipa adversária. o Empurrar um jogador adversário para o tirar do jogo. Sempre que não for claro qual a equipa culpada pela falta, o árbitro irá colocar os robôs envolvidos na situação junto à linha lateral mais próxima. Esta reposição deve ser feita um robô de cada vez e alternando entre equipas. O árbitro deve colocar os robôs de forma a que nenhuma equipa fique em vantagem. Exemplos de faltas neste tipo de situação: o Falta de progresso do jogo. o Quando se forma um aglomerado de jogadores e não é claro qual a equipa responsável. 29
Fair Play. O objectivo do jogo é disputar uma partida de futebol de acordo com o senso comum e com as regras impostas. Tentar contornar as regras é considerado falta de desportivismo e é rigidamente proibído. Se for considerado que uma equipa se serve de métodos menos nobres, essa equipa será desqualificada. Se uma equipa estiver sobre suspeita, os organizadores têm o direito de pedir as informações necessárias de forma a determinar se existiu falta de desportivismo. Exemplos de falta de desportivismo são: o Usar os binários de outras equipas. o Enviar mais que uma mensagem por ciclo. o Uma equipa desligar os seus robôs ou tomar alguma acção de forma a beneficiar a equipa adversária. 3.4 O robô real Na figura 4 pode ser visto o robô obrigatoriamente utilizado por todas as equipas. Este robô foi criado pela CITIZEN e é apenas para uso científico, não tendo uso comercial. Este robô é constituído por duas partes. No seu topo contém uma placa com o controlador, constituído por dois microprocessadores (ARM e AVR), um conector de 80 pinos para variados usos e um receptor de infravermelhos, responsável pela recepção de comandos enviados pelo servidor. Esta placa está embutida no corpo do robô, que contém dois motores (motores de relógio), duas rodas de 10mm de raio e duas baterias de iões de lítio. Com a ajuda do conector de 80 pinos as equipas podem projectar novos equipamentos a acrescentar aos robôs (uma câmara, por exemplo). Durante a competição foi discutida a hipótese de nas competições futuras se vir a usar um novo robô, devido ao/a: Preço elevado do robô (aproximadamente 200 dólares cada). Instabilidade (muitas vezes pára a meio do jogo e tem de ser feito um reset manual no robô para voltar a funcionar). Problemas com a recepção dos comandos (muitas vezes o receptor de infravermelhos fica obstruído devido à posição de outro robô ou devido à etiqueta identificadora colocada sobre o robô). Pensa-se que a melhor solução seja procurar no mercado um robô que tenha algum fim comercial, de forma a que o seu preço seja mais reduzido, mas que mantenha uma boa performance, para que as equipas não percam jogos devido a falhas no robô, o que levaria ao desinteresse por parte dos aficionados pela modalidade. Uma última opção foi ainda tida em conta: a de que no futuro houvesse a possibilidade das equipas poderem criar os seus próprios robôs, retirando à organização a responsabilidade de possíveis falhas durante os jogos. 30
Figura 4: Robô utilizado na "Mixed Reality" e suas respectivas dimensões (em milímetros) Dentro do módulo de controlo do robô (descrição mais à frente), alojado no servidor, foi feita uma discretização das velocidades permitidas pelo robô. Tais valores podem ser observados na figura 5. Figura 5: Discretização das velocidades. [SourceForge, 2010b] 31
3.5 O sistema da Mixed Reality Na figura 6 pode ser visualizada a arquitectura usada para tornar possível o desenrolar dos jogos. A infra-estrutura da Mixed Reality consiste em: Câmara (colocada por cima do campo de jogo) e vision-tracking; Emissores de infravermelhos (localizados à volta do campo), controlados pelo Robot Control; Sistema de projecção, onde é projectado tanto o campo de jogo, como a bola e os robôs. Nesta edição da competição, e nas anteriores, foi usado um televisor LCD, mas não se descarta a possibilidade de se vir a usar uma tela e um projector, de forma a se poder realizar jogos com um maior número de robôs. No entanto, esta possibilidade não será considerada a curto prazo. Figura 6: Arquitectura da "Mixed Reality" O televisor LCD é colocado na horizontal tornando possível que os robôs se movimentem facilmente na sua superfície plana. Estes mesmos robôs interagem com os objectos que são projectados no televisor LCD, podendo por exemplo chutar a bola virtual que está representada no ecrã e não existe no mundo real. Nesta infraestrutura, o servidor (MR-SoccerServer [Silva, 2009]) é responsável pelo ambiente simulado, pelos objectos virtuais e pela supervisão do jogo (saída da bola pelas linhas finais, recolocação da bola, etc). Os robôs são controlados por agentes de software, instalados num computador remoto. Existem dois computadores, um para cada equipa, onde corre o software de cada agente. Não é permitido o uso de computadores pessoais para este efeito, pelo que nos primeiros dias da competição é necessário verificar se os agentes correm sem problemas nos computadores fornecidos. Os emissores de infravermelhos e a câmara são os actuadores e os 32
sensores no ambiente real. A câmara é responsável por detectar a posição dos robôs [Yanagimachi e Guerra, 2007]. A figura 7 pode ajudar a melhor perceber a estrutura do sistema da Mixed Reality, da RoboCup. Figura 7: Estrutura do sistema da Mixed Reality [Gerndt e Guerra, 2008] Este sistema tem um preço elevado, já que para se disputar um jogo 5 vs 5 é necessário [SourceForge, 2010a]: Televisor TFT (42 polegadas) ~ 1350 Euro Conjunto de robôs (pelo menos 10) ~ 2000 Euro Câmara ~ 200 Euro Estrutura metálica ~ 400 Euro Emissor de infravermelhos ~ 50 Euro Luzes de alta frequência ~ 500 Euro Somando o preço de todos os itens chega-se à conclusão que o sistema completo tem um custo aproximado de 4500 Euro, um valor que pode ser elevado para alguns interessados na competição. 33
3.6 Simulador 3.6.1 Introdução Os simuladores são ferramentas muito importantes para o desenvolvimento tanto de equipas para a RoboCup, como para muitas outras aplicações. No âmbito do futebol robótico, o simulador permite às equipas testar a performance do seu conjunto de agentes, antes de o fazerem no ambiente real. Isto faz com que seja mais fácil para uma nova equipa desenvolver os seus agentes, já que fornece um meio prático, rápido e barato de teste. Como vimos, a Mixed-Reality é composta pelos robôs reais e por um ambiente virtual (simulado). Fazem parte deste ambiente simulado o campo de jogo, a bola e as bandeiras de campo. Este ambiente é simulado por um servidor, que comunica com o software dos agentes, fornecendolhes a posição de cada jogador, da bola e das bandeiras. Cada agente processa esta informação e toma uma decisão. Os comandos de acção são depois enviados para os robôs físicos via infravermelhos. No jogo puramente simulado os robôs reais são substituídos por um módulo de software chamado MR-simulator. De forma a facilitar a criação de equipas, principalmente para aqueles que não tem acesso a todo o equipamento para recriar jogos (ecrã LCD, robôs, etc.), foi criado um simulador. Mas antes de falar deste simulador, é importante conhecer o software usado na "Mixed Reality": Soccer Server. Este módulo foi criado com o objectivo de fornecer a conexão e comunicação entre os outros módulos. Por isso este módulo deve ser o primeiro a ser inicializado. Vision Tracking. Permite o reconhecimento dos robôs colocados em campo, retornando a sua posição, para que possa ser representado na imagem. Para o efeito é usada também uma câmara de filmar IEEE1394. Robot Control. Este módulo é responsável por receber os comandos XML, enviados pelos clientes, e transformá-los de forma a poderem ser enviados por um emissor IrDA, conectado por USB. Graphics. Este é o módulo que cria as imagens 2D. Quando está a correr, este módulo espera pelos ficheiros que vêm pela rede e representa os comandos gráficos, codificados em XML. Soccer Operator. Esta aplicação fornece um interface simples para interagir com o Soccer Server, usando uma consola para o efeito. É através desta aplicação que se pode reposicionar a bola, parar o jogo, dar por terminado o jogo, entre outros. Soccer Client. Este é o cérebro por trás do robot. Todo o processamento é feito durante um ciclo e no seu fim a informação deve ser enviada para o Soccer Server. 34
Este é o software usado em competição. No entanto, no caso de não se possuir todo o equipamento, qualquer pessoa pode desenvolver a sua equipa, usando para o efeito o simulador. 3.6.2 MR-Simulator O MR-Simulator é um simulador responsável por simular os módulos Vision Tracking e Robot Control/Infravermelhos, substituindo também os robôs reais por uns simulados. Desta forma, para alguém desenvolver uma equipa apta a participar num torneio mundial de futebol robótico, necessita apenas de um computador, podendo dispensar os robôs, os emissores de infravermelhos, a câmara e o televisor LCD. Este simulador permite às equipas testar as suas tácticas e estratégias, permitindo melhorar as capacidades defensivas e ofensivas, num ambiente que é bastante estável. Este simulador é também uma boa alternativa para quem se está a iniciar na competição, já que fornece um ambiente menos oneroso e dispendioso de tempo, pois não requer aquele decorrente da inicialização de um jogo no sistema completo - cerca de dez minutos, caso não haja problemas. O ciclo principal do MR-Simulator pode ser visto na figura 8. Figura 8: Ciclo principal do MR-Simulator, [Simões, 2010] 3.6.2.1 Simulação do ambiente De forma a simular os módulos Vision Tracking e Robot Control foram criados módulos virtuais para fazer a troca de mensagens com o servidor. O módulo virtual de Vision Tracking baseia-se na posição inicial do robô e em modelos de trajectórias e colisões dos robôs. Este módulo envia mensagens para o servidor, que contém a posição e a orientação dos robôs. O servidor, por sua vez, envia os comandos originados pelos clientes para um Robot Control Simulado, que discretiza a velocidade de acordo com a figura 5 e a envia os robôs virtuais. O servidor não necessita de nenhuma alteração para funcionar com o simulador, pelo que o seu comportamento é o mesmo, se estiver a comunicar com os módulos reais. 35
3.6.2.2 Simulação dos Robôs O robô é simulado como sendo uma figura plana com a dimensão de 25 x 27mm. Cada robô simulado tem um nome, ID, orientação, tamanho e velocidade das rodas, de acordo com a informação que é passada pelos agentes. A simulação dos robôs é feita através do uso de modelos de trajectória e colisão. 3.7 Conclusões A Mixed Reality é uma liga da RoboCup que atravessa um período crítico. Enquanto as outras ligas da RoboCup Soccer já se estabeleceram, a Mixed Reality encontra-se ainda numa posição instável, razão pela qual ainda é considerada uma liga de demonstração. De forma a poder estabelecer-se é importante que todo o sistema de jogo seja mais estável, já que durante os jogos ocorrem inúmeras paragens, tanto por falhas mecânicas dos robôs, como por falhas do sistema de visão. Tais paragens tornam o jogo menos interessante para quem assiste, já que dez minutos de jogo podem chegar a demorar mais de meia hora. Outra consequência das consecutivas falhas é levar muitas vezes a que o jogo se torne injusto, já que se sofrem golos porque um robô teve um problema técnico ou se falham golos certos porque o sistema de visão deixa de conseguir identificar um robô, o que leva a situações de confronto. Uma forma de diminuir as paragens e a interferência humana seria utilizar o reposicionamento automático dos robôs, tal como é feito em algumas ligas de futebol do RoboCup. Ao contrário do que já acontece nas outras ligas de futebol simulado, na Mixed Reality não existe a possibilidade de comunicação, o que remove muitas possibilidades para um jogo mais interessante. Através da comunicação entre agentes seria possível criar um melhor entendimento entre eles, pois como se viu no capítulo 2, a habilidade social de um agente é uma característica importante para a performance tanto do próprio, como do sistema multi-agente. O uso da comunicação traria para a competição a possibilidade das equipas poderem criar melhores jogadas estudadas, passes em desmarcação e muitas outras funcionalidades que actualmente são pouco trabalhadas mas que trariam maior qualidade ao jogo. Existe ainda uma outra característica que leva a que a Mixed Reality não se consiga estabelecer como uma das ligas principais do RoboCup. O principal objectivo da RoboCup Soccer é conseguir derrotar a equipa campeã mundial de futebol humano. Enquanto a Liga 2D permite trabalhar a fundo as características de estratégia e táctica e a Liga 3D permite o desenvolvimento dos movimentos dos robôs humanóides, a Mixed Reality não tem nenhum objectivo principal. Foi sugerido que se introduzisse a possibilidade de se disputar jogos entre humanos e robôs reais, já que este é o principal objectivo da organização e ainda não há nenhuma liga que o faça. Outro campo a ser melhorado é o do simulador. Apesar de ser uma excelente ferramenta para testar a performance da equipa, a sua resposta é um pouco diferente do que se verifica na realidade. Tal situação ocorre porque o ambiente simulado é perfeito. Neste ambiente deveriam ser acrescentados alguns erros, ou talvez ser criado um novo modo de simulação, de forma a que os testes possam ser levados a outros níveis. Tais erros podem consistir em: 36
Velocidade do robô ser diferente da que foi requisitada (devido a derrapagens das rodas, por exemplo); Interferências no sistema de visão. 37
Capítulo 4 Desenvolvimento do Agente O agente criado conta com uma função denominada Strategy, responsável pelas decisões de alto nível. Esta função recebe a informação necessária de um ficheiro de nome WorldData e envia as acções para o ficheiro de nome BasicPlayer, responsável por as executar. Todo este processo é controlado pelo ficheiro SampleAgent. 4.1 - Ficheiros Os principais ficheiros criados para a estrutura do agente da equipa desenvolvida foram: WorldData. Contém o software necessário para a extracção do estado do mundo, isto é, informação sobre o estado do jogo (posições de jogadores, posição da bola, velocidade de um colega de equipa, etc.). BasicPlayer. Contém todas as acções que um jogador pode desempenhar (chutar, passar, parar, driblar, etc.). Algumas acções são mais complexas e podem usar uma ou mais acções contidas no próprio ficheiro. SampleAgent. O agente propriamente dito, que usa a informação obtida pelos métodos intrínsecos a WorldData e toma acções contidas em BasicPlayer. 38
Existem ainda outros ficheiros importantes, muito úteis para a criação dos agentes, a destacar: BasicUtils. Descrição da classe que manipula os vectores em coordenadas polares (classe vector_t). config. Configuração de parâmetros para a conexão dos agentes. Geometry. Definição de várias ferramentas úteis, tal como funções trigonométricas, vectores cartesianos (classe Vector) mais as suas operações e ainda definições de figuras geométricas (classe Circle, classe Line, classe Rectangle). start.sh. Inicia todos os agentes. kill.sh. Remove todos os agentes. 4.2 - Metodologia para a criação da equipa Para criar o código da equipa tentou-se que este fosse o mais genérico possível, de forma a que eventuais alterações (por exemplo modificação do tamanho do campo) não tornassem o código obsoleto, ficando a equipa inviável para a competição. Apesar disto, pouco antes da competição, o servidor de jogo foi alterado, mudando também a dinâmica da bola, fazendo com que algumas funções tivessem de ser ajustadas e outras perdessem o seu valor. Um exemplo claro foi o chuto optimizado, em que se fazia a bola rodar à volta do robô de forma a ganhar mais velocidade. Após a modificação do servidor este tipo de chuto deixou não só de funcionar, como também de ser necessário, uma vez que já era possível rematar a uma distância maior. Outro factor importante é criar um código em que seja fácil a alteração de aspectos básicos, tal como estratégias e posicionamentos. 4.3 - Ficheiro WorldData Neste ficheiro encontra-se o código responsável por averiguar o estado do mundo. Nele podem ser encontradas as funções que permitem a obtenção dos seguintes dados por parte do agente: Vectores em coordenadas polares que unem o agente às diferentes bandeiras do campo de jogo. Vector em coordenadas polares que une o agente a um outro agente, da mesma equipa ou não. Qual o companheiro mais próximo de uma certa zona? Qual o adversário mais próximo de uma certa zona? Qual o adversário mais próximo de um dado companheiro? Qual o companheiro mais próximo de um outro companheiro? Qual o adversário mais próximo de um outro adversário? Qual o companheiro mais próximo da bola? Qual o adversário mais próximo da bola? 39
Qual o estado do jogo, nomeadamente se o jogo está "ON"? Quais as dimensões do campo? Qual a posição da bola? Qual a velocidade da bola? Qual a minha posição no campo? Qual a minha orientação? Quais as posições dos meus colegas? Sou o agente mais perto da bola? Qual o vector que me une ao centro da baliza adversária? Qual o vector que me une ao centro da minha baliza? Posso avançar com a bola? Algumas funções são bastante simples e não necessitam de explicação, outras no entanto, envolvem alguns cálculos matemáticos. Sobre estas será explicado mais à frente qual o raciocínio que está por trás. Na figura 9 pode ser visto o tipo de informação que é fornecida e sobre a qual é necessário manipular, de forma a obter informações de mais alto nível. Figura 9: Informação básica disponível [Lau e Reis, 2007b] 4.3.1 - GetFieldDimensions() Esta função é responsável por adquirir as dimensões do campo. Apesar de durante o jogo o campo não mudar de dimensão, pode ocorrer que pouco antes do torneio começar as medidas oficiais sejam alteradas, pelo que é necessário estar preparado para esta situação. Para isso foi criada esta função que permite averiguar quais as reais dimensões do terreno de jogo. Na figura 10 pode ser visto um esquema do método utilizado. 40
Figura 10: Cálculo das dimensões do campo e e fazendo a Obtendo os vectores que unem o agente aos cantos subtracção desses vectores, podemos obter um vector com o mesmo comprimento do. Um raciocínio semelhante pode ser usado para obter a outra dimensão. campo 4.3.2 - GetMyPosition() O objectivo desta função é obter a localização do agente dentro do terreno de jogo. A figura 11 pode ajudar a perceber o método usado para esta função. Figura 11: Cálculo da posição do agente 41
Obtendo os vectores que unem o agente às bandeiras de canto da sua própria baliza e podemos adquirir as distâncias do agente a essas mesmas bandeiras. Com estes valores podemos escrever que e ã equações podemos chegar ao resultado:, desenvolvendo este sistema de. 2., (1.1), (1.2) Sabendo os valores de h e a, basta realizar as seguintes operações, de forma a ficar com a posição do agente nas coordenadas x e y ilustradas na figura 11. ã 2, (1.3) ã 2, (1.4) 4.3.3 - GetMyOrientation() Esta função é responsável pela aquisição da orientação do agente. Foi definido que se o agente estiver no centro do campo, a olhar para o centro da equipa adversária, terá um ângulo de orientação igual a zero, sendo para a sua esquerda ângulos negativos e para a sua direita ângulos positivos. Esta forma de encarar o lado positivo e negativo dos ângulos foi feita de forma a estar de acordo com as definições do servidor, já que os vectores em coordenadas polares fornecidos pelo servidor são enviados segundo esta convenção. Com os dados da figura 12, podemos calcular a orientação do agente. Figura 12: Cálculo da orientação 42
Na imagem foi considerado o valor absoluto de atan2. Se chamar α ao ângulo do vector para a bandeira de canto, pode-se definir quatro situações: Se α>0 e α > atan2(a,h) α atan2 a, h, (2.1) Se α>0 e α < atan2(a,h) atan2 a, h α, (2.2) Se α<0 e -α+atan2(a,h)>π 2, α, (2.3) Se α<0 e -α+atan2(a,h)<π atan2 a, h α, (2.4) 4.3.4 - GetBallPosition() Com o uso desta função é possível adquirir a posição da bola, em coordenadas x,y. Para tal, é pedido ao servidor o vector em coordenadas polares que une o agente à bola. Na figura 13 está representado esse vector. Figura 13: Cálculo da posição absoluta da bola Sabendo a orientação do agente e o ângulo do vector em coordenadas polares que o une à bola, o ângulo absoluto da bola é facilmente calculado, sendo uma 43
simples soma da orientação(β) com o ângulo visto pelo agente (θ). A posição da bola em relação ao agente será: cos 1 sin 2, (3.1) Onde é o comprimento do vector que une o agente à bola, α1 e α2 são ambos o ângulo absoluto da bola. No caso da orientação ser em valor absoluto maior que π/2, deve ser feita a correcção α2= -α2 - π. A posição absoluta da bola será a soma da posição absoluta do jogador com a posição relativa da bola. 4.3.5 - GetPlayerPosition() Esta função tem como objectivo dotar um agente da capacidade de adquirir a posição absoluta de um outro jogador. O método utilizado é o mesmo que na função GetBallPosition(), com a diferença que o vector considerado será o vector que une o próprio agente ao agente cuja posição se quer calcular. 4.3.6 - IamClosestToBall() Através desta função é possível o agente saber se é, dentro da equipa, aquele que está mais próximo da bola. Usando a função pv_closest_teammate_to_ball() é possível, para o agente, saber quem é o colega mais próximo da bola. A função pv_teammate() permite saber qual o vector que une os dois agentes ( ). Subtraindo o vector que une os dois agentes ao vector que une o agente à bola ( ), o resultado, visível na figura 14, será o vector que une o outro jogador à bola ( ). Comparando o comprimento deste vector com o comprimento do vector que une o agente à bola, pode-se saber qual é o agente que está de facto mais próximo da bola. Figura 14: Vectores necessários para a função IamClosestToBall() 44
4.3.7 - CentroBaliza() Esta função retorna o vector que une o agente ao centro da baliza. Para tal é realizado o cálculo representado na figura 15. Figura 15: Cálculo de CentroBaliza() Sabendo os vectores que unem o agente aos postes da baliza ( ), somando estes dois vectores e dividindo o comprimento do vector resultante por dois, obtemos o vector pretendido ( ). 4.4 - Ficheiro BasicPlayer Neste ficheiro foram definidos alguns movimentos básicos, tais como: Chutar a bola; Rodar para a direita / esquerda; Curvar para a direita / esquerda; Ir para um ponto dado um vector em coordenadas polares; Ir para um ponto dadas as coordenadas x e y; Ir para a posição estratégica; Parar; Passar a bola a um colega; Passar a bola ao colega mais próximo; Rematar à baliza; Chuto melhorado. Para além disso, neste ficheiro também estão definidas algumas funções importantes tal como: Envio de um comando para o servidor; 45
Verificação da capacidade do agente chutar a bola; Tomada de decisões pelos jogadores; Código do guarda-redes. Para criar todos estes movimentos apenas se dispõe de dois comandos básicos aceites pelo servidor, o comando setkick(angle, strength), para chutar a bola com uma dada força e direcção e o comando setvelocity(left,right), para definir as velocidades de cada roda do agente. Todas as outras funções têm de ser desenvolvidas a partir destas duas. Tal como foi feito para o ficheiro WorldData, vai ser dada uma explicação para as funções mais complexas. 4.4.1 - GoToXY(double xx, double yy) O objectivo desta função é enviar um agente para um ponto (x f,y f ) do terreno de jogo. Junto com os ficheiros disponibilizados pela organização já vem incluída uma função para enviar um agente para um ponto definido por um vector em coordenadas polares, com origem no agente. Assim o objectivo desta função é criar esse vector, para se poder utilizar a função fornecida. Na figura 16 é possível observar o problema em causa. Figura 16: Vector em coordenadas polares para o destino Sabendo a localização do agente (X i,y i ), a sua orientação (β) e as coordenadas do ponto de destino (X f,y f ) é possível calcular o vector em coordenadas polares que une o agente ao destino. O comprimento do vector é dado por: X X Y Y, (4.1) Sendo (Xi,Yi) as coordenadas de posição do agente e (Xf,Yf) as coordenadas do ponto de destino, o ângulo do vector (α) pode ser calculado da seguinte forma: 46
2,, (4.2) Por fim, é necessário limitar o ângulo ao intervalo [-π,π], pelo que se deve, caso o ângulo não esteja neste intervalo, proceder à soma ou subtracção de 2π, de forma a que o ângulo se encontre no intervalo pretendido. 4.4.2 - KickXY(Vector FinalPos) Com esta função é possível chutar a bola de forma a que ela pare nas coordenadas X,Y definidas pelo vector FinalPos. Para tal é necessário criar um vector em coordenadas polares que una a bola ao ponto de destino. Esta função é parecida com a anteriormente demonstrada, sendo o ponto de origem a bola e o ponto de destino o local onde se quer colocar a bola. Com este vector criado, o agente já sabe para onde deve chutar, mas necessita também de saber qual a força que deve utilizar. O método que se utilizou foi fazer uma linearização entre a força de chuto e o local onde bola irá parar. Considerando que num remate de força máxima (força=1), a bola percorre a distância Xmax, podemos dividir o comprimento do vector calculado por Xmax, obtendo assim a força de remate. No caso de a força resultante ser maior que 1, significa que o ponto de destino está muito longe, e devemos chutar com a força máxima. 4.4.3 - Goalie() Nesta função está o algoritmo de movimentação do guarda-redes. Na maior parte do tempo o guarda-redes deve localizar-se entre a bola e o centro da baliza, de forma a diminuir as possibilidades de golo do adversário. Para conseguir calcular esse ponto, foi feito o cálculo representado na figura 17. Figura 17: Posição ideal para o guarda-redes 47
Através dos vectores em coordenadas polares que unem o guarda-redes à bola ( ) e ao centro da sua baliza ( ), o ponto onde o guarda-redes se deve colocar é: ) 2, (5.1) Em que é o vector para onde o agente se deve mover, é o vector que une o agente à bola e é o vector que une o agente ao centro da sua baliza. Uma vez que este método pode gerar pontos muito afastados da baliza, foi feito um limite para os valores de posição que o guarda-redes pode tomar. Desta forma o agente continuará a colocar-se entre a bola e o centro da baliza mas sempre nas proximidades desta. No caso de o guarda-redes ter a bola ele pode tomar três decisões: Chutar para a intersecção da linha lateral com a linha de meio campo; Deslocar-se com a bola para a bandeira de canto; Passar a um colega de equipa. O guarda-redes chuta para a intersecção da linha lateral com a do meio campo, sempre que ache que o consegue fazer sem entregar a bola ao adversário. Para tal foi desenvolvida a função CanKickToPointPass. Caso não seja possível chutar para nenhum destes dois pontos, o guarda-redes encaminha-se para a bandeira de canto mais próxima. Se por acaso não houver um adversário próximo, então o guarda-redes passa ao colega mais próximo. Existem ainda duas situações em que o guarda-redes deve tentar interceptar a bola. São elas: A bola estar muito próxima da baliza; Existir um adversário isolado em frente ao guarda-redes. 4.5 - Ficheiro SampleAgent Este ficheiro contém o ciclo principal do agente. As principais e mais importantes instruções contidas nesse ciclo são as seguintes: gworlddata.updatews(); gplayer.fillinwsforstrategy(); gplayer.strategy.callstrategy(); gplayer.strategy.dm_actionpoint = gplayer.strategy.calculatetarget(gworlddata.ws_mypos,gworlddata.ws_ballpos); gplayer.player(); Esta sequência demonstra o funcionamento do agente. A primeira acção do agente é calcular os valores do estado do mundo, os valores adquiridos pelos seus sensores virtuais. De seguida ele actualiza esses valores e chama a função responsável por escolher a melhor estratégia. Chama ainda uma função que calcula o ponto para 48
onde o jogador deve chutar a bola. Por fim é chamada a função Player() contida no ficheiro BasicPlayer. Esta função toma uma de três decisões: Se tem a bola chutável: Chuta para o ponto estratégico; Se é o agente mais perto da bola: Tenta interceptar a bola; Se não é o agente mais perto da bola nem a pode chutar: Desloca-se para a posição estratégica. No caso de se tratar do guarda-redes, então a função Player() chama a função Goalie(), responsável pelos comportamentos dele. 4.6 Conclusões Neste capítulo foi realizada uma descrição resumida do agente desenvolvido para a equipa FC Portugal. Este agente inclui todas as funções de percepção, decisão e acção necessárias para participar na liga de Mixed Reality do RoboCup. 49
Capítulo 5 Desenvolvimento da Estratégia da Equipa A equipa de futebol robótico simulado FCPortugal, implementou uma função responsável por tomar as decisões de alto nível. Esta função tem o nome Strategy. O primeiro passo desta função é proceder à leitura de um ficheiro de configuração denominado strategy.conf.mr. Neste ficheiro de configuração está uma lista de opções que pode ser alterada, de forma a estabelecer o comportamento desejado para a equipa. No ponto 5.1 Para que esta função possa desempenhar o seu papel, é necessário fornecer-lhe a informação sobre o estado do mundo. Esta informação é fornecida pelo ficheiro WorldData (ver ponto 4.3). Após a informação estar actualizada, a função retorna o ponto para onde o jogador se deve mover, ou no caso de estar na posse da bola, o ponto para onde a deve chutar. Estas acções são então desempenhadas pela função BasicPlayer (ver ponto 4.4). 5.1 - Ficheiro strategy.conf.mr Neste ficheiro é possível definir toda a estratégia da equipa tal como formações, posicionamento estratégico, tendências para onde devem os agentes levar a bola e até quando devem mudar estes parâmetros, dependendo do resultado e do tempo de jogo. Este tipo de ficheiro que controla as decisões de alto nível pode ser visto em outras equipas [Lange et al., 2008]. O ficheiro tem o seguinte conteúdo: 50
# Common Framework Strategy Configuration File FC Portugal 2010 - Luis Paulo Reis 3 # 1-2D, 2-3D, 3-MR - Strategy Type 2 5 4 6 4 3 # Num_Tactics Num_Players Formations Player_Types Flux_Matrixes Sets_SetPlays 0 # Opponent Number 0 - default 2 1 # Number of Time Tactics and opponents - tactic depends on result, time and opponent 000 899 0 2 2 2 2 1 # Opp Numb - Losing Bad, Losing, Drawing, Winning, Winning Bad 900 1200 0 2 2 2 2 1 Nesta primeira parte podemos definir: Strategy Type: podemos definir qual a estratégia a usar. Neste caso foi definido o valor 3, que corresponde à estratégia para a Mixed Reality; Na linha seguinte é definido o número de tácticas a usar (duas), o número de jogadores da equipa (cinco), o número de formações (quatro), o número de tipos de jogador (quatro) e o número de matrizes de fluxo (três); Quanto às Set Plays (jogadas estudadas), foram deixados os valores em 0, já que não foram implementadas jogadas estudadas para esta liga; Nas últimas linhas é definido quais as tácticas a usar, dependendo se a equipa se encontra na primeira ou segunda parte do jogo e do resultado actual. Podemos verificar que em ambas as partes são usadas as mesmas tácticas e que a táctica 1 só é usada caso a equipa esteja a ganhar por mais de 3 golos (Winning Bad). Numa segunda parte do ficheiro, é feita a definição das tácticas : # Tactics Definition ------------------------------------------------------------------- ------- 1 # Tactic 1 - Tactic Description - Exp1 4 3 1 1.0 0.0 0.0 0.99 0.01 # Formation, Flux, SetPlans, WFlux, WSafe, WEasy 0 # Form used in each situation (Att/Def, KickOff(O/T), CornKickIn, FKick, GFKick, Pen 2 # Tactic 2 - Tactic Description - Exp2 3 3 1 1.0 0.0 0.0 0.99 0.01 # Formation, Flux, SetPlans, WFlux, WSafe, WEasy 0 # Form used in each situation (Att/Def, KickOff(O/T), CornKickIn, FKick, GFKick, Pen Tomando como exemplo a táctica 1, podemos definir: Formação - 4 Matriz de fluxo - 3 Movimentação devido ao fluxo - 0.99 Movimentação de segurança - 0.01 (Este valor define para onde o jogador deve chutar a bola, tendo em conta a posição do adversário, ver ponto 5.4) Os restantes valores não foram usados 51
Numa fase seguinte podemos definir algumas características dos jogadores: # Player Types Definition -------------------------------------------------------------- -------- 1 2 3 4 5 6 # PT Number 0.1 0.8 0.8 1.0 0.8 0.8 # AttractionX 1 0.8 0.8 0.8 0.9 0.9 # AttractionY 0.0 0.2 0.2 0.2 0.2 0.2 # AreaAttrAttack (last 1/4) not used 0.0 0.2 0.2 0.2 0.2 0.2 # AreaAttrDefense (last 1/4 of field) not used 1 1 1 0 0 0 # BehindBall -480.0-310.0-330.0-330.0-330.0-330.0 # MinX -400.0 100 416.5 416.5 416.5 416.5 # MaxX -26.35-237.0-237.0-237.0-237.0-237.0 # MinY 26.35 237.0 237.0 237.0 237.0 237.0 # MaxY 1 2 2 3 3 2 # Decision Algorithm 1-Goa, 2-Def, 3-Att Tomando como exemplo o jogador 1, podemos verificar que: AttractionX: Sofre uma atracção pela bola de 0.1, segundo o eixo X AttractionY: Sofre uma atracção pela bola de 1, segundo o eixo y BehindBall: 1 (deve manter-se sempre atrás da bola) MinX: -480.0 ( posição mínima segundo X que pode ocupar) MaxX: -400.0 ( posição máxima segundo X que pode ocupar) MinY: -26.35 ( posição mínima segundo Y que pode ocupar) MaxY: 26.35 ( posição máxima segundo Y que pode ocupar) Decision Algorithm: 1 (1 para guarda-redes, 2 para defesa e 3 para avançado) Podemos verificar que o jogador do tipo 1 é um guarda-redes, os jogadores do tipo 2, 3 e 6 são defesas e os jogadores 4 e 5 são avançados. No bloco seguinte são definidos os parâmetros das formações. # Formations Definition ---------------------------------------------------------------- -------- 1 1 # 2-1-2 Formation 1 - Type 1 - SBSP -420.0-180.0, -180.0-50.0-50.0 #Posx 0.0-50.0, 50.0-100.0 100.0 #Posy 1 2 2 3 3 #Type PT_GOA PT_MID PT_DEF... 2 1 # 2-1-2-1 test Formation 2 - Type 1 - SBSP -420.0-180.0, -180.0-50.0-50.0 #Posx 0.0-40.0, 40.0-100.0 100.0 #Posy 1 2 2 3 3 #Type PT_GOA PT_MID PT_DEF... 3 2 # Formation 3 - Type 2 - Delaunay - Formation description 3 FormacaoFinal.conf # Name 1 2 2 3 3 #Type PT_GOA PT_MID PT_DEF... 4 2 # Formation 4 - Type 2 - Delaunay - Formation description 4 formations-ataque-ultimo.conf # Name 1 2 2 3 3 #Type PT_GOA PT_MID PT_DEF... Na formação 1 temos para cada um dos cinco jogadores a definição da posição base que deve ocupar e qual o tipo de jogador que ocupa essa posição (definido no bloco anterior). Enquanto a formação 2 é semelhante em termos de parâmetros à formação 1, as formações 3 e 4 usam um ficheiro externo para definir as posições base, fazendo uso da triangulação de Delaunay. Esta metodologia será mais à frente explicada, no ponto 5.2. 52
O bloco seguinte define as matrizes de fluxo: # Flux Matrixes Definition ------------------------------------------------------------- -------- 1 1 # Flux 1,Type 1 (old) - Types:Norm 1, Del 2 - Flux Description - Normal 10 20 30 40 50 60 70 60 60 10 20 30 40 50 60 60 70 70 00 10 20 30 50 50 50 80 90 00 00 20 30 50 50 50 90 100 00 10 20 30 50 50 50 80 90 10 20 30 40 50 60 60 70 70 10 20 30 40 50 60 70 60 60 2 1 # Flux 2,Type 1 - Flux Description - Test go back with ball 10 9 8 7 5 4 3 2 0 9 8 7 6 4 3 2 1 0 8 6 5 4 3 2 1 0 0 7 6 4 3 2 1 1 0 0 6 4 2 2 1 1 0 0 0 2 2 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 3 2 # Flux 3,Type 2 - Delaunay - Flux Description fluxo1.conf # name 4 2 # Flux 4,Type 2 - Delaunay - Flux Description fluxo1.conf #name Neste caso podemos verificar que as matrizes de fluxo (ver mais à frente a sua importância no ponto 5.3) 1 e 2 estão claramente especificadas (sendo do tipo 1), enquanto as matrizes 3 e 4 são definidas por um ficheiro externo (neste caso o mesmo, sendo as matrizes do tipo 2). O bloco de SetPlays, ou jogadas estudadas, não foi alterado, uma vez que não foi utilizado. # SetPlays Definition ("setplay.conf")-------------------------------------------------- ---------- 1 2 # Set Number and Type (1 - Old Setplays, 2 - New Setplays) - Set Description 1 2 3 4 5 6 7 8 2 2 # Set Number and Type 2 - New Setplays - Set Description 1 2 3 4 3 2 # Set Number and Type 2 - New Setplays - Set Description 1 2 8 Por fim são fornecidos alguns parâmetros do jogo e do sistema: # General Domain Parameters 1200 600 # Game Time, Extra Time 730 485 # Field Size TODO 140 220 120 # Penalty Area Size and goal width TODO 100 100 30 # max kick distance, running speed/sec, agentsize # END OF CONFIGURATION FILE ------------------------------------------------------------ ---------- 53
Esses parâmetros são: Duração total do tempo de jogo; Duração do tempo extra; Dimensões do campo; Dimensões da grande área e da baliza; Distância máxima a que um agente consegue chutar a bola; Velocidade máxima que ele consegue atingir; A dimensão do agente. Alterando este ficheiro podemos mudar rapidamente a forma de pensar e agir de uma equipa sendo por isso uma mais valia [Lau e Reis, 2002], principalmente no decorrer dos jogos em que se dispõe de pouco tempo para fazer alterações. Por outro lado, acrescentar novos tipos de jogadores e novas matrizes de fluxo, por exemplo, é uma tarefa que não demonstra dificuldades. 5.2 - Posicionamento estratégico A formação de uma equipa é muito importante para o desempenho da mesma. Uma boa escolha da formação pode esconder algumas das falhas da equipa ou aproveitar melhor as suas mais valias. Também se deve ter em conta que a estratégia da equipa adversária pode mudar, pelo que é necessário adaptar diferentes estratégias a diferentes adversários [Almeida, 2008]. É importante garantir que os jogadores não se encaminham todos para a bola, nem que vão para posições que não são interessantes para a equipa. Por essa razão, foi decidido que os jogadores que não possuem a bola ou que não estão a tentar interceptá-la, se devem deslocar para a sua posição estratégica. Para esta tese foram usadas duas metodologias para a criação das formações e de posicionamentos estratégicos. Numa primeira fase foi utilizado um algoritmo simples, denominado "Situation Based Strategic Positioning" [Lau e Reis, 2007a], em que cada jogador ocupa uma posição base e sente depois uma atracção pela bola, sendo essa atracção definida no ficheiro Strategy.conf.MR. Este tipo de metodologia pode ser observado, por exemplo, na equipa CAMBADA de futebol robótico com robôs reais [Lau et al., 2008]. A fórmula de cálculo da posição para onde o jogador se deve deslocar, no caso de se querer deslocar para a sua posição estratégica, é: çã é = çã +( çã çã ), (6.1) Esta é uma forma simples de implementar o posicionamento estratégico. No entanto, não permite uma disposição diferente para cada zona do campo. Podemos por exemplo querer que, quando a bola se encontra no meio campo adversário, três jogadores avançados se disponham em linha e apenas um defesa fique mais recuado, ao passo que numa situação mais defensiva, possa ser mais útil ter quatro jogadores em linha na defesa. Para dar resposta a este problema, foi usado o software "matchflow", já usado para a Liga 2D e 3D. Este software permite que se definam, para certos pontos onde a bola possa estar, a localização dos agentes. Para os restantes pontos a posição estratégica 54
é calculada usando a triangulação de Delaunay. Podemos ver o processo em acção nas figuras que se seguem (figuras 18 à 20): Figura 18: Posição dos jogadores com a bola no ponto 1 Figura 19: Posição dos jogadores com a bola no ponto 2 Figura 20: Posição dos jogadores com a bola entre o ponto 1 e 2 55
Como se pode verificar pelas imagens, numa posição intermédia entre dois pontos definidos, os agentes irão ter a sua posição estratégica num local intermédio a esses mesmo pontos. À medida que nos encaminhamos do ponto 1 para o ponto 2, os jogadores afastam-se da posição definida em 1 para se aproximarem da posição definida em 2. Na equipa CAMBADA de futebol robótico com robôs reais, foi utilizado um algoritmo dinâmico que adapta a formação a uma possível variação do número de agentes activos [Lau et al., 2009]. Um algoritmo semelhante pode ser no futuro implementado nesta Liga. 5.3 - Matrizes de fluxo A matriz de fluxo é uma matriz que divide o campo em vários sectores e os gradua de acordo com a tendência a que queremos que o agente se desloque para esse ponto, sendo que o agente tem preferência em ir na direcção dos pontos de maior fluxo. Para a Mixed Reality optou-se por usar uma matriz de fluxo criada pelo software "Matchflow", o mesmo que foi usado para criar as formações. Para criarmos esta matriz, é necessário primeiro definir os pontos do campo que vamos graduar. Para isso deve ser criada uma formação onde definimos todos os pontos. Foi criada uma malha mais densa para as zonas perto das balizas, já que nessas zonas existe a necessidade de precisar mais detalhadamente o movimento dos robôs, uma vez que se tratam de zonas críticas. Essa malha pode ser vista na figura 21. Figura 21: Malha para definição de fluxo O passo seguinte é dar valores de fluxo aos pontos definidos. Os valores de fluxo devem ter valores mais elevados à medida que se caminha para a baliza adversária, caso contrário os robôs terão mais tendência a deslocar-se noutra direcção, o que 56
não é desejável. Também se deve ter o cuidado de definir valores de fluxo nulos para zonas fora do campo, já que não queremos que o robô se desloque para essa zona. A única excepção é para os pontos dentro da baliza adversária, já que encaminhar a bola para esses pontos é o objectivo primordial. Na figura 22 pode ser visto um exemplo de uma matriz de fluxo, criada no "Matchflow". Figura 22: Matriz de fluxo Neste exemplo temos até bem perto da baliza adversária (do lado direito), valores mais altos junto às alas do que no centro do terreno. Desta forma os agentes terão uma maior tendência a conduzir a bola por aí. Na maioria dos casos esta é a melhor solução, já que as equipas tendem a ter os defesas mais perto do centro do terreno, de forma a melhor defender a sua baliza. É muito raro e seria até estranho uma equipa colocar os seus defesas junto às linhas laterais, deixando um corredor central livre. Por fim podemos gravar esta matriz de fluxo, num ficheiro com extensão *.flux. Este ficheiro terá no seu interior algo semelhante a: Begin Flux 115 0 0 0 52 1-420 260 0 2 420-260 0 3 0 260 0 4 0-260 0 5 420 260 0 6-370 -260 0... 57
Em que o primeiro valor identifica o ponto, os outros dois números indicam as coordenadas desse ponto e o último número identifica o valor do fluxo. 5.4 - Segurança O factor de segurança tem influencia no ponto para onde um jogador se move com a bola. A título de exemplo, se for usado um factor de segurança demasiado elevado, um jogador com a posse de bola poderá trazer a bola para a sua defesa em vez de partir para o ataque, já que na sua defesa não existem jogadores adversários e o risco de perder aí a bola é menor. Este comportamento é fortemente indesejável, já que a equipa não progride no campo e mantém a bola numa zona que não é interessante para os objectivos globais (marcar golos e não os sofrer). Usando um valor pequeno para a segurança, e usando uma matriz de fluxo igual à da figura 22, podemos ter resultados interessantes. Uma vez que esta matriz de fluxo tem valores bastante maiores à medida que se progride no campo e o factor de segurança é pequeno, conseguimos garantir que um jogador com a posse de bola vai sempre tentar progredir no terreno. No entanto, para uma linha paralela à linha de meio campo, os valores não são assim tão díspares, pelo que apesar de o jogador ter tendência a ir para as alas (no caso da figura 22), irá também ter tendência a desviar-se dos adversários. Assim é possível que o jogador não se desloque para a ala, caso aí se encontre um jogador adversário. 5.5 - Conclusões Neste capítulo foi descrita a estratégia da equipa que foi adaptada da estratégia utilizada pela equipa FC Portugal noutras ligas do RoboCup. Esta estratégia é composta por tácticas, formações e fluxos de jogo. Não foi utilizado nenhum modelo para os adversários, de forma a tentar prever os seus movimentos. De acordo com Lattner, [Lattner et al., 2006] tal podia ser feito retirando pequenas informações sobre a interacção entre jogadores, informações estas contidas em "game logs". No entanto, tal artefacto não existe ainda na Liga Mixed Reality. Uma outra aplicação interessante da previsão de movimentos seria a demonstrada em [Teixeira, Lau e Reis, 2004], em que a direcção do remate à baliza é influenciada pela previsão da posição do guarda-redes. No próximo capítulo serão analisadas as influências destes factores no desempenho da equipa de Mixed Reality desenvolvida. 58
Capítulo 6 Testes e análise de resultados obtidos 6.1 Teste das funções do WorldData Para verificar o bom funcionamento das funções criadas, foram realizados testes à medida que estas iam sendo concluídas. Para testar as funções, colocou-se a ser impressos no terminal os valores que iam sendo calculados pelos agentes, por cada uma das funções. 59
6.1.1 Teste da função GetFieIdDimension() Os resultados obtidos foram os presentes na tabela 1 (em pixels). Tabela 1 - Dimensões do campo Medidas Dimensão do campo eixo X Dimensão do campo eixo Y 0 778.590 488.659 1 779.584 491.226 2 779.812 488.704 3 780.451 482.609 4 781.601 486.839 Como se pode verificar, os resultados são bastante positivos, sendo o erro relativo menor que 0,4%. Estes valores são consistentes e independentes da localização do agente. Este valor é muito importante, uma vez que é usado nos cálculos de outras funções. 6.1.2 Teste da função GetMyPosition() Para testar esta função, era necessário saber a posição real do robô, de forma a comparar com o valor calculado. Uma vez que o sistema permite a recolocação manual da bola, o que foi feito foi colocar a bola na posição em que o robô pensa que se encontra e verificar visualmente se há sobreposição. Um dos resultados obtidos e que é demonstrativo da totalidade dos testes efectuados, é o que se encontra na figura 23. O teste neste caso foi realizado para o agente 01. Figura 23: Teste da função GetMyPosition() 60
Como se pode verificar, há uma sobreposição quase perfeita da imagem do jogador e da bola, estando esta quase no centro do quadrado que representa o robô, o que demonstra o bom funcionamento desta função. 6.1.3 Teste da função GetBallPosition() Para esta função o teste realizado consistiu em reposicionar manualmente a bola, numa posição que é conhecida. De seguida verifica-se na consola qual a posição da bola calculada pelos agentes. Os resultados obtidos podem ser vistos na tabela 2 (em pixels). Tabela 2 - Resultados da função GetBallPosition() Posição real da bola Posição calculada X = 359.0 ; Y = 168.5 X = 361.321 ; Y = 164.445 X = -141.0 ; Y = -31.5 X = -138.678 ; Y= -33.8236 X = 159.0 ; Y = -181.5 X = 160.083 ; Y = -185.785 X = -41.0 ; Y = 68.5 X = -37.9921 ; Y = 64.021 X = -341.0 ; Y = -131.5 X = -339.125 ; Y = -134.984 Como se pode verificar, o erro relativo não é elevado, independentemente da posição da bola. Esta função usa os valores calculados pelas funções GetMyPosition() e GetMyOrientation(), pelo que se espera que o erro desta função seja superior à das outras duas. 6.1.4 Teste da função GetPlayerPosition() Para testar esta função, foi realizado um teste semelhante ao usado em 6.1.2, onde se testava a função GetMyPosition(). Neste caso, a informação que era impressa na consola por parte do agente era a posição dos restantes jogadores. Colocando a bola numa posição em que o agente julga estar um jogador, é possível verificar visualmente se existe sobreposição. Por inspecção visual o resultado foi semelhante ao obtido em 6.1.2., podendo afirmar-se que a função foi bem sucedida. Um exemplo típico deste teste pode ser observado na figura 24. 61
Figura 24: Teste da função GetPlayerPosition() 6.1.5 Teste da função GetMyOrientation() Esta função foi um pouco mais difícil de testar já que não existia uma forma de obter o valor real da orientação do agente. A experiência realizada consistiu em imprimir na consola os valores da orientação dos vários agentes e por inspecção visual, verificar se estavam correctos. Uma outra forma de validar o bom funcionamento desta função é recorrer aos resultados obtidos para as funções GetPlayerPosition(), GetMyPosition() e GetBallPosition, já que estas necessitam do valor calculado pela função GetMyOrientation(), para nos seus cálculos chegarem ao valor final. Uma vez que essas funções foram bem sucedidas, podemos afirmar que a função GetMyOrientation() foi também ela um êxito. 6.2 Teste das funções do BasicPlayer 6.2.1 Teste da função GoToXY(double xx, double yy) De forma a verificar o correcto funcionamento desta função foi pedido ao agente que imprimisse na consola as coordenadas do ponto para onde se queria deslocar e para enviar a mensagem "Cheguei a x y" assim que atingisse o objectivo. Nessa altura o jogo era parado e verificava-se por inspecção visual, recolocando a bola nas mesmas coordenadas, se de facto o agente se tinha movido para o local correcto. O resultado obtido pode ser verificado na figura 25, onde foi realizado o teste com o agente número 01. 62
Figura 25: Teste da função GoToXY(double xx, double yy) Como se pode ver, o agente está bastante próximo do ponto pretendido. Esse valor não é mais exacto porque se considera que o agente atingiu o seu objectivo quando está a uma distância de 10 pixels do destino, pelo que nessa altura o agente pára nessa posição. 6.2.2 Teste da função KickXY(Vector FinalPos) Para proceder ao teste desta função colocaram-se os agentes a imprimir na consola, o local onde viam a bola e o local para onde tentavam chutar a bola. Para avaliar a posição da bola foi usada a função GetBallPosition(), que já tinha demonstrado ser bastante fiável. Na tabela 3 estão os resultados obtidos, em que a posição inicial é o local onde a bola estava antes de ser chutada, a posição requisitada é o local onde o agente quer colocar a bola e a posição final é o local onde a bola parou, após ser chutada. Tabela 3 - Resultados da função KickXY () Posição inicial Posição requisitada Posição final X= -9.9195 ; Y = -203.15 X= 84.1298 ; Y= -179.845 X= 77.418 ; Y= -178.721 X= 126.22 ; Y =-170.229 X= 225.95 ; Y= -178.229 X= 203.287; Y= -175.579 X= -138.505 ; Y =72.2825 X= -141.671; Y= 141.404 X= -161.499 ; Y= 135.171 X= -136.246 ; Y =-134.642 X= -42.262 ; Y= -168.804 X= -64.0405 ; Y= -154.922 X= 45.1371; Y =-156.322 X= 143.464; Y= 176.246 X= 168.467 ; Y= 152.975 X= 149.453 ; Y=-177.972 X= 249.451 ; Y= -177.372 X= 202.772; Y= -179.459 X= -180.841 ; Y=-138.304 X= -178.453; Y= -148.014 X= -175.035 ; Y= -128.127 63
Tomando como referência o tamanho do robô, um quadrado com 30 pixels de lado, podemos considerar que os resultados não foram maus, apesar de poderem ser melhores. Nesta função foi feita uma linearização entre a intensidade do chuto e a distância onde se quer colocar a bola. Não foi tido em conta a velocidade da bola no momento do chuto. Considerar a velocidade da bola poderia melhorar a precisão. Outra importante alteração que poderia ser feita seria não optar pela linearização e ter em conta a função de desaceleração da bola. Estas duas alterações propostas foram de facto implementadas, no entanto, duas semanas antes do início da competição, a função de desaceleração da bola foi alterada, pelo que não houve tempo de a modificar convenientemente. Uma vez que manter esta função mais simples não demonstrou prejudicar o desempenho da equipa, ela foi mantida assim. 6.3 Análise global aos resultados obtidos Para avaliar o desempenho da equipa houve duas equipas adversárias para a testar. No entanto, uma delas era claramente de fraca qualidade, não permitindo obter o real valor do desempenho da equipa. Por essa razão, foi apenas utilizada uma equipa para testes, equipa essa que já tinha vencido torneios anteriores. A equipa em causa é a BahiaMR. Esta equipa ataca apenas com dois jogadores, deixando o guarda-redes e os defesas atrás da linha de meio campo. Em situações em que a equipa está a defender, os dois defesas recuam para muito perto da baliza e os avançados recuam até aproximadamente metade da sua zona defensiva. As figuras 26 e 27 são exemplificativas disso, onde a BahiaMR está representada pela cor amarela. Figura 26: BahiaMR ao ataque 64
Figura 27: BahiaMR à defesa Para os teste foram realizados jogos de 10 minutos. Foram também testadas duas matrizes de fluxo diferentes, uma que força mais a condução da bola até à baliza adversária pelo centro do terreno e uma outra, em que a condução da bola é feita tendencialmente pelas alas. Chamarei a estas matrizes de fluxo, matriz de fluxo central e de fluxo lateral, respectivamente, podendo ser vistas nas figuras 28 e 29. Figura 28: Matriz de fluxo com preferência pelo centro (fluxo central) 65
Figura 29: Matriz de fluxo com preferência pelas alas (fluxo lateral) 6.3.1 Formação com dois avançados e dois defesas. Esta formação mantém constantemente todos os jogadores atrás da linha da bola. Numa situação de ataque, os dois defesas nunca avançam muito para lá da linha de meio campo. Nas imagens que se seguem pode ser visualizado o posicionamento estratégico da equipa em diversas situações (figuras 30 à 33). Figura 30: Equipa à defesa com bola no centro 66
Figura 31: Equipa à defesa com bola na lateral Figura 32: Equipa ao ataque com bola no centro Figura 33: Equipa ao ataque com bola pela lateral 67
Como se pode verificar, esta é uma formação em que a grande prioridade é a defesa. Na tabela 4 podem ser verificados os resultados obtidos em dez jogos com o fluxo central. Tabela 4 - Resultados obtidos com dois avançados e fluxo central Jogo FCPortugal BahiaMR 1 0 1 2 0 0 3 0 0 4 0 2 5 0 0 6 0 1 7 0 1 8 0 2 9 0 2 10 0 2 Na tabela 5 é feita uma estatística para esta formação com o fluxo central. Tabela 5 - Estatística com dois avançados e fluxo central Valores Totais Vitórias Empates Derrotas Golos Marcados Golos Sofridos 0 3 7 0 11 Valores Médios 0% 30% 70% 0.0 1.1 Na tabela 6 estão os resultados obtidos em dez jogos com o fluxo lateral. 68
Tabela 6 - Resultados obtidos com dois avançados e fluxo lateral Jogo FCPortugal BahiaMR 1 0 0 2 0 0 3 0 1 4 0 0 5 0 0 6 1 0 7 0 0 8 1 1 9 0 0 10 0 0 Na tabela 7 é feita uma estatística para esta formação com o fluxo lateral. Tabela 7 - Estatística com dois avançados e fluxo lateral Valores Totais Vitórias Empates Derrotas Golos Marcados Golos Sofridos 1 8 1 2 2 Valores Médios 10% 80% 10% 0.2 0.2 6.3.2 Formação com quatro avançados Esta é uma formação principalmente preocupada com o ataque. Enquanto a equipa opera em modo defensivo mantém três jogadores atrás da linha da bola e outros dois à frente, de forma a poder sair mais rapidamente em contra-ataque. Quando a bola se encontra no meio campo da equipa adversária, todos os jogadores, com excepção do guarda-redes, se deslocam em direcção à baliza adversária. O descrito pode ser visto nas figuras 34 a 37. 69
Figura 34: Equipa à defesa com a bola no corredor central Figura 35: Equipa à defesa com a bola numa posição lateral Figura 36: Equipa ao ataque com bola pelo corredor central 70
Figura 37: Equipa ao ataque com bola numa posição lateral Os resultados obtidos em dez jogos, com o fluxo central, podem ser consultados na tabela 8. Fi Tabela 8 - Resultados obtidos com quatro avançados e fluxo central Jogo FCPortugal BahiaMR 1 0 1 2 0 2 3 0 0 4 0 1 5 0 1 6 0 1 7 0 0 8 0 2 9 0 0 10 0 1 Na tabela 9 é feita uma estatística para esta formação com o fluxo central 71
Tabela 9 - Estatística com quatro avançados e fluxo central Valores Totais Valores Médios Vitórias Empates Derrotas Golos Marcados Golos Sofridos 0 3 7 0 9 0% 30% 70% 0.2 0.9 Na tabela 10 estão os resultados obtidos em dez jogos, usando o fluxo lateral. Tabela 10 - Resultados obtidos com quatro avançados e fluxo lateral Jogo FCPortugal BahiaMR 1 3 0 2 2 2 3 3 0 4 2 0 5 2 0 6 3 1 7 2 0 8 3 0 9 2 0 10 2 0 Na tabela 11 é feita uma estatística para esta formação com o fluxo lateral. Tabela 11 - Estatística com quatro avançados e fluxo lateral Valores Totais Vitórias Empates Derrotas Golos Marcados Golos Sofridos 9 1 0 24 3 Valores Médios 90% 10% 0% 2.4 0.3 72
6.3.3 Formação com três avançados e um defesa Esta é uma formação que se inclina bastante para o ataque. No entanto, por razões de segurança, deixa sempre um jogador atrás da linha de meio campo, para além do guarda-redes. O posicionamento estratégico da equipa pode ser visto nas figuras 38 à 41. Figura 38: Equipa à defesa com a bola numa posição central Figura 39: Equipa à defesa com a bola numa posição lateral 73
Figura 40: Equipa ao ataque com a bola no centro Figura 41: Equipa ao ataque com a bola junto à linha lateral Os resultados obtidos com o fluxo central podem ser observados na tabela 12. 74