O Simulador 3D para Futebol de Robs o USPDSAluno: Diogo Oliveira de Melo Orientadora: Profa. Dra. Roseli Aparecida Francelin Romero ICMC/USP - So Carlos a e-mail: dmelo87@gmail.com e-mail: rafrance@icmc.usp.br 10 de maro de 2009 c

1

Sumrio a1 Introduo ca 2 Viso Geral a 3 Interface Grca a 4 Estratgia e 4.1 Campos Potenciais . . . . . . . . . . . . . . . . . . 4.1.1 Adaptao da tcnica de Campos Potenciais ca e tebol de Robs . . . . . . . . . . . . . . . . o 4.1.2 Componentes da Estratgia . . . . . . . . . e 4.1.3 Sub-Mdulo Individual . . . . . . . . . . . . o 4.1.4 Sub-Mdulo Interativo para Simurosot . . . o 4.1.5 Sub-Mdulo Interativo para Mirosot . . . . o 4.2 Campos Potenciais Harmnicos . . . . . . . . . . . o 4.2.1 Mtodos de Relaxao . . . . . . . . . . . . e ca 4.2.2 Mtodo de Gauss-Sidel . . . . . . . . . . . . e 4.2.3 Mtodo de Jacobi . . . . . . . . . . . . . . . e 4.3 Campos Potenciais Orientados . . . . . . . . . . . . 4.4 Campos Potenciais Localmente Orientados . . . . . 5 N cleo do Simulador u 5.1 Gerenciamento da Comunicao ca 5.2 Engine F sica . . . . . . . . . . 5.3 Deteco de Coliso . . . . . . . ca a 5.4 Tratamento de Colises . . . . . o 5.5 Funo de Tratamento de Erros ca entre . . . . . . . . . . . . os Mdulos o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . para . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 5 6 7 9 11 11 12 16 17 18 19 21 22 24 24 24 25 27 28 28

6 Conexo entre os Mdulos a o 29 6.1 Comumicao com a Estratgia . . . . . . . . . . . . . . . . . 31 ca e 6.2 Comunicao com a Interface Grca . . . . . . . . . . . . . . 32 ca a 7 Grid 32 7.1 Ferramentas e Mtodos Utilizados . . . . . . . . . . . . . . . . 32 e 7.2 Testes e Resultados . . . . . . . . . . . . . . . . . . . . . . . . 33 8 Heur stica de Avaliao de Estratgias ca e 34 8.1 Avaliao entre Duas Estratgias . . . . . . . . . . . . . . . . 35 ca e 8.2 Avaliao de uma Estratgia no Contexto Geral . . . . . . . . 35 ca e 8.3 Testes e Resultados . . . . . . . . . . . . . . . . . . . . . . . . 36 2

9 Utilizao ca 9.1 Pr-Requisitos . . . . . . . . . . . . . . . . . . . . . . e 9.2 Instalar . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Interface Grca - Eyes . . . . . . . . . . . . . . . . . a 9.3.1 Tipos de Cmera . . . . . . . . . . . . . . . . a 9.3.2 Controle Sobre o Tempo de Exibio do Jogo ca 9.4 Concluso . . . . . . . . . . . . . . . . . . . . . . . . a

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

36 36 37 38 38 38 39

3

1

Introduo ca

Futebol de robs um ambiente utilizado para o desenvolvimento de peso e quisas em diversas reas. Viso computacional, aprendizado de mquina, a a a planejamento de caminhos, controle e automao so alguns exemplos das ca a reas envolvidas no funcionamento de um time de futebol de robs. Esforos a o c empregados no desenvolvimento e otimizao de um time de futebol de robs ca o sero reetidos em todos os outros ambientes que utilizam essas tcnicas ou a e que possuem paradigmas simulares. A t tulo de exemplo podemos citar a tcnica de Campos Potenciais Harmnicos, primeiramente proposto em [8], e o e uma tcnica utilizada para planejamento de caminhos. O ambiente de futee bol de robs representa uma oportunidade colocar em prtica e desenvolver o a pesquisas importates na reas de computao e robtica mvel. a ca o o O simulador surgiu a partir da necessidade de desenvolver estratgias de e controle para times de futebol de robs, da categoria Very Small Size para o times com trs jogadores. Em inumeras situaes a utilizao de simulao e co ca ca proporciona mais vantagens em relao ` utilizao do ambiente real. A ca a ca verso 1.1 do simulador, descrita neste relatrio tcnico, proporciona um a o e ambiente de simulao de qualidade e baixo custo computacional. ca Tendo em mente o objetivo de desenvolver um time de futebol de robs, o existe a necessidade de testar, analisar e avaliar as estratgias construidas. e Com este prposito o uso de simulao o mais recomendado. So necessrios o ca e a a os reesultados de vrios jogos para vericar o funcionamento da estratgia ao a e longo de seu desenvolvimento. Certicar de que todos os robs, mais a cmera o a e todo o software necessrio esto funcionando muito dispendioso. O uso a a e de simulao nesses casos, livra o desenvolvedor de uma srie de problemas. ca e Inicialmente foi analisada a possibilidade de utilizar algum simulador j a existente, como o SServer [7] da Robocup, que software livre e foi constru e do para a plataforma GNU/Linux, tambm h o simulador da FIRA [1], que e a pertence ` categoria Simurosot. Entretanto, h desvantagens em relao a a ca a ambos os simuladores. O simulador da FIRA, por exemplo, s funciona o na plataforma Windows, os times so compostos por cinco jogadores e o a simulador no pode ser executado sem a parte grca 1 . O Simulador da a a Robocup simula futebol de robs porm os robs possuem geometria circular, o e o entretanto o time a ser constru possui robs de formato cbico. Uma do o u terceira possibilidade seria utilizar o Mobile Robots Simulator (MOBS) [17]. Este simulador segue as regras da categoria Simurosot e possui times com trs jogadores entretanto, no software livre e nem pode ser executado sem e a eA importancia de ter um simulador que funcione sem visualizao grca a facilidade ca a e de automatizar a execuo de vrias simulaes ca a co1

4

a interface grca. a No encontrar um simulador que atendesse a todas as necessidades levou ` a a construo do simulador USPDS. Este simulador foi desenvolvido no Laboraca trio de Aprendizado de Robs (LAR) do Instituto de Cincias Matemticas o o e a e de Computao de So Carlos (ICMC). Este simulador possui times de trs ca a e robs, cada rob um cubo de 75 mil o oe metros de aresta. Este um projeto e de software livre e est dispon em http://uspds.sourceforce.net. Embora a vel o simulador tenha sido projetado para a plataforma GNU/Linux, o ambiente de simulao oferecido independente de linguagem de programao e ca e ca sistema operacional.

2

Viso Geral a

USPDS foi projetado para ser to ex a vel quanto poss vel. O objetivo do projeto atender pessoas que desenvolvem estratgias para futebol de robs e e o 2 da categoria Very Small Size . E necessrio possibilitar que o usurio cona a gure o simulador de acordo com seu caso (peso do rob, coeciente de atrito o entre o rob e o campo e etc.). Este pr-requisito fez com que o simulador o e fosse constru em mdulos. A simulao composta por trs programas do o ca e e sendo executados em sincronia. Cada estratgia se conecta ao ncleo por e u uma conexo TCP/IP. Em cada iterao, a estratgia recebe informaes soa ca e co bre as condies do jogo, calcula a deciso e envia os comandos de volta para co a o ncleo do simulador. A interface grca opcional durante a simulao, u a e ca tambm poss ter vrias interfaces grcas conectadas a uma simulao e e vel a a ca o que permite que vrias pessoas de diferentes lugares consigam acompanhar a o mesmo jogo.

3

Interface Grca a

Durante a simulao a interface grca utilizada para mostrar os dados ca a e do jogo. A interface totalmente passiva, apenas recebe informaes do e co simulao. Cada interface grca conectada ao simulador recebe o estado ca a de cada iterao. Por estado entende-se as posies e orientaes de cada ca co co robs mais a posio da bola. A interface grca utiliza a linguagem de o ca a programao C++ e a biblioteca OpenGL e possibilita que o usurio assista ca a o jogo atravs de quatro diferentes modos. O modo padro mostra ao usurio e a a a viso do espectador, que consiste de uma cmera esttica sobre o campo. a a aUma das tarefas para uma verso futura do USPDS extend-lo, de modo a tornar a e e fcil a congurao do tamnho e formato do campo assim como nmero de robs a ca u o2

5

Figura 1: Interface Grca EYES a

No segundo modo a cmera est focada em um jogador. O terceiro modo a a consiste na cmera embarcada ao rob. Finalmete, o quarto modo, a viso a o e a livre, o usurio possui controle sobre a cmera e pode moviment-la pelo a a a campo. O Eyes (nome da interface grca) tambm possibilita controle sobre a e a velocidade do jogo. Isto tambm inclui pausar e avanar. e c O Eyes composto por duas threads. A primeira responsvel por receber e e a dados e a segunda por mostr-los. Toda a interao com o usurio mais a a ca a parte de OpenGL est relacionada com a segunda thread. A primeira thread a mantm uma conexo aberta com o ncleo do simulador para receber os e a u dados da simulao. Todos os dados recebidos podem ser gravados em um ca arquivo, no formado do simulador. A interface grca tambm possibilita a e exportar o jogo para o formato de v deo AVI. A Figura 1 uma foto da e interface grca, mostrando um jogo. a

4

Estratgia e

A maioria dos times de futebol de robs no conseguem capturar o ngulo o a a dos robs adversrios. Por este motivo, cada time possui informaes sobre o a co a angulao apenas dos prpios robs. Alm dos ngulos dos prprios robs, ca o o e a o o cada estratgia recebe as posies, em coordenadas cartesianas, de todos os e co objetos do jogo: os prprios robs, robs adversrios e a bola. Aps receber o o o a o 6

estas informaes, cada time deve determinar a velocidade de cada roda de co cada rob do prprio time. o o O simulador possui um suporte adicional para estratgias constru e das na linguagem de programao C++, que consiste dos mtodos necessrios para ca e a enviar e receber dados do ncleo do simulador. Tambm foram adicionados u e mtodos que calculam a velocidade de cada roda para que um rob se dirija e o at determinado ponto do campo. e Junto ao simulador exitem duas estratgias. A primeira baseada em e e Campos Potenciais (CP) e a segunda utiliza Campos Potenciais Localmente Orientados (CPLO). Entretanto, a estrtgia baseada em CP uma adapae e tao de uma estratgia para a categoria Simurosot da FIRA e a estratgia ca e e baseada em CPLO uma juno entre Campos Potenciais Harmnicos (CPH) e ca o e Campos Potenciais Orientados (CPO). Portanto, sero abordadas as quatro a tcnicas: CP, CPH, CPO e CPLO. e

4.1

Campos Potenciais

A tcnica de Campos Potenciais foi proposta por Kathib [16]. Esta tcnica e e prope que o ambiente seja modelado como um espao no qual os objetos o c promovam foras uns sobre os outros. Aplicando esta tcnica ao ambiente de c e futebol de robs, temos que a fora resultante atuando sobre um determinado o c jogador (do time em que a estratgia aplicada), dever servir de base para e e a determinar a trajetria que este jogador dever seguir. o a Por ser um mtodo de baixo custo computacional, esta tcnica tem sido e e muito utilizada em planejamento de trajetrias de robs mveis que necessio o o tam navegar por um ambiente desconhecidos e/ou dinmico, evitando colia ses com obstculos. Vrios pesquisadores tm apresentado propostas para o a a e melhorar a ecincia do mtodo de Campos Potenciais. e e Krogh [18] aprimorou este conceito ao considerar que a velocidade do rob o deve diminuir na vizinhana dos obstculos para diminuir o risco de coliso. c a a Thorpe [22] aplicou o mtodo de Campos Potenciais para pelanejamento de e caminhos. Newman [20] introduziu a implementao de funoes potenciais ca c atravs da combinao de funes individuais de obstculos com operadores e ca co a lgicos. o Brooks [5] e Arkin [4] so os pioneiros em utilizar a tcnica de Campos a e Potenciais de forma reativa, ou seja, para cada novo passo do rob uma nova o fora resultante dever ser calculada para direcionar seu movimento. Esta c a caracter stica reativa torna o mtodo muito eciente para robs que realizam e o tarefas em ambientes dinmicos. a Pela proposta feira por Faria [12], necessrio denir quais os pontos de e a atrao e repulso, no campo. Tambm necessrio determinar de que modo ca a e e a 7

Figura 2: Campo gerado por um ponto de repulso [12] a

Figura 3: Campo gerado pela bola [12]

estes campos iro se propagar. O jogador atacante interpreta a bola como a ponto de atrao e os outros jogadores representam pontos de repulso. A ca a fora de repulso provocada por cada jogador inversamente proporcional ao c a e quadrado da distncia entre o jogador que provoca a fora e o jogador ataa c cante em questo. Sendo assim, o campo potencial, gerado por um jogador, a pode ser visto como ilustado na Figura 2. O modo de propagao da fora de atrao diferente. O mdulo da ca c ca e o fora de atrao, provocada pela bola, constante. Foi denido desta forma c ca e porque o jogador atacante, independente de sua posio, deve ser atra ca do pela bola. O Campo Potencial gerado pela bola como ilustrado na Figura e 3. Tambm necessrio denir constantes, que determinam o mdulo relae e a o tivo entre as foras exercidas sobre o jogador atacante. No caso da estratgia c e proposta por Faria [12], foram denidas trs constantes. A primeira usada e e

8

Figura 4: Campo potencial gerado por dois obstculos e uma meta [12] a

no clculo da fora gerada pelos jogadores que pertencem ao mesmo time que a c o jogador atacante. A segunda constante diz respeito aos jogadores do time adversrio. A ultima constante usada para determinar o mdulo da fora a e o c exercida pela bola. Uma vez que cada fora calculada, a fora resultante obtida pela soma c e c e dos vetores das foas calculadas. A direo e o sentido, da fora resultante, c ca c determinam a trajetria que o rob atacante deve seguir. A fora resultante o o c o resultado do somatrio de todas as foras que atuam sobre o jogador e o c atacante. A tcnica de Campos Potenciais apresenta vrias vantagens. Dentre estas e a vantagens est o baixo custo computacional e a grande ecincia em ambiena e tes dinmicos. Embora esta estratgia apresente um bom desempenho, Faria a e [12] apresenta algumas modicaes que corrigem alguns erros da estratgia, co e at aqui descrita. e 4.1.1 Adaptao da tcnica de Campos Potenciais para Futebol ca e de Robs o

Para aumentar a ecincia, Faria [12] props essencialmente duas alteraes e o co na aplicao da tcnica de Campos Potenciais ` estratgia. ca e a e A primeira modicao diz respeito ao rob artilheiro (ou atacante). Com ca o o rob sendo atraido diretamente pela bola, foi observado que a quantidade de o gols contra era grande. Para corrigir este erro, foi criada uma reta imaginria a s que determinada pelo centro do gol adversrio e a bola. Sobre a reta s e a foi colocado o ponto P (em vermelho), que ca a uma distncia i da bola, a 9

Figura 5: Representao do comportamento do artilheiro ca

como ilustrado na Figura 5. Segundo a proposta feita por Faria [12], o rob artilheiro atraido pelo o e ponto P. Porm, quando o jogador estiver prximo do ponto P (na rea e o a sombreada em vermelho), o artilheiro passa a ser atra diretamente pela do bola. Essa adaptao aumenta as chances de chute certeiro ao gol adversrio. ca a A segunda adaptao proposta por Faria [12], foi a criao de uma deca ca fesa. Para criar o comportamento da defesa, foram inseridas quatro linhas imaginrias (a, b, c e d ). Estas linhas cortam o campo longitudinalmente. a Uma quinta linha z foi criada. Esta ultima determinada pelo centro do e gol e a bola. Desta forma, cada jogador da defesa tem seu ponto de atrao ca determinado pelo cruzamento entre os segmento z e a sua respectiva linha vertical, como mostrado na Figura 6. Depois de ter estudado a proposta feita por Faria, so propostas algumas a importante lembrar que as modicaes, as quais so descritas a seguir. E co a alteraes descritas abaixo foram implementadas tendo como base o cdigo co o desenvolvido por Faria. Porm a estratgia para times com trs jogadores foi e e e implementada baseada em algumas bibliotecas criadas para o Simulador, o restante foi reimplementado do inicio.

10

Figura 6: Representao do comportamento da defesa ca

4.1.2

Componentes da Estratgia e

Para manter um bom n vel de organizao, a Estratgia ser dividida em ca e a dois sub-mdulos: sub-mdulo individual e sub-mdulo interativo. O subo o o mdulo individual composto por funces e mtodos que tm por objetivo o e o e e determinar o comportamento de um jogador sem implementar tticas de a equipe. Por outro lado o sub-mdulo interativo visa o comportamento em o grupo, isto , a cooperao entre dois ou mais jogadores do time. e ca 4.1.3 Sub-Mdulo Individual o

As funes pertencentes ao sub-mdulo individual so funes bsicas. Estas co o a co a funes do suporte `s funes utilizadas pelo sub-mdulo interativo. As co a a co o funes que fazem parte do sub-mdulo individual so: Velocity, Angle, Goto co o a e GotoXY. A funo Velocity a funo mais bsica. Como atributos, so passados ca e ca a a o rob alvo (que o rob considerado por essa funo), a velocidade desejada o e o ca na roda esquerda e a velocidade desejada na roda direita. A funo faz com ca que o rob alvo altere as velocidades das rodas para as velocidades passadas o por parmetro. a A funo Angle utiliza a funo Velocity para fazer com que o rob alvo ca ca o se posicione no ngulo passado, ` funo, por parmetro. Caso o rob j a a ca a o a esteja prximo o suciente do ngulo desejado a funo Angle pra o rob. o a ca a o 11

Para que o rob alcance o ngulo desejado, a funo Angle faz com que ele o a ca gire em torno do prprio eixo. o A funo Goto semelhante a funo Angle porm, faz com que o rob ca e ca e o alcance o ngulo desejado descrevendo uma curva. a Por m, a funo GotoXY, utiliza a funo Goto para guiar o rob at ca ca o e um determinado ponto, fornecido atravs de coordenadas cartesianas. e 4.1.4 Sub-Mdulo Interativo para Simurosot o

Atualmente, trs funes compem o sub-mdulo interativo da estratgia e co o o e feita para Simurosot, as funes FollowBall, Defesa e Strategy. A FollowBall co usada para a parte do ataque. A funo Defesa, como o prprio nome j e ca o a sugere, usada pela defesa do time, o que inclui o goleiro. A funo Strategy e ca coordena as funes que cada rob ir utilizar. co o a Lembrando que cada time dessa categoria tem cinco jogadores, foi decidido que dois desses jogadores faro parte do ataque e os outros trs iro a e a compor a defesa. Porm, com exceo do goleiro, essas posioes no so e ca c a a xas. Dependendo da situao em que o jogo se encontra, jogadores do ataque ca podem passar para a defesa e vice-versa. A seguir, abordaremos o modo de funcionamento de cada uma dessas trs funes. e co A funo FollowBall, foi projetada para controlar dois jogadores. Entreca tanto, observamos que pode acontecer de dois robs, do mesmo time, dispuo tarem a bola, o que indesejvel. e a Para resolver este problema, a funo FollowBall tem a nalidade de secca cionar o campo em duas reas (separadas pela linha verde), como ilustrado a na Figura 7. Quando a bola estiver na rea inferior, o jogador A1 ca encara regado de buscar a bola. Ao mesmo tempo, o atacante A2, procura por uma posio prop para brigar pela bola, caso a bola passe para a outra rea. ca cia a Quando a bola entra na outra rea, os papis dos atacantes so invertidos. a e a Na funo FollowBall os jogadores atacantes so repelidos pelos outros ca a jogadores e sentem atrao pelos pontos vermelhos ilustrados na Figura 7. ca O ponto de atrao do atacante A1 determinado pelo segmento de reta, ca e formado pelo fundo do gol adversrio e a bola, sendo que este ponto ca a a uma distncia da bola, na direo oposta ao gol adversrio. A distncia, entre a ca a a a bola e o ponto de atrao, foi tomada como sendo equivalente a metade da ca medida da aresta do rob 3 . o A escolha do ponto de atrao do jogador A1 foi feita com o intuito ca de direcionar o ataque do jogador. No modo anterior, porposto por Faria Essa distncia foi determinada empiricamente. E uma das constantes que devem ser a otimizadas pelo mtodo descrito no cap e tulo 6.3

12

Figura 7: Diviso feita pela FollowBall a

[12], o atacante tambm era atra por um ponto colinear ao centro do gol e do adversrio e a bola porm, o novo ponto de atrao ca a uma distncia a e ca a menor da bola o que faz com que no seja necessrio que o jogador tome a a uma nova atitude ao se aproximar do ponto de atrao. ca O atacante A2 sente atrao pelo ponto cujas coordenadas so formadas ca a pelo X da bola e o Y da lateral da grande rea. A inteno que o jogador a ca e A2 no ataque mas, que na posio mais estratgica poss a ca e vel, esperando que a bola passe para a sua rea. a Para chamar a funo Defesa necessrio passar alguns parmetros. ca e a a Parte desses parmetros denem a rea de atuao do jogador da defesa. a a ca A posio da bola, em relao ` rea de defesa do jogador, ir determinar a ca ca a a a atitude desse jogador. Na Figura 8 est ilutrado um jogador da defesa. Este jogador tem a sua a rea de atuao limitada pelas linhas verde e vermelha. Sendo assim, existem a ca trs partes do capo em que a bola pode estar: ` frente da linha verde, entre e a a linha verde e a linha vermelha ou atrs da linha vermelha. a Caso a bola esteja ` frente da linha verde, o jogador ser atra pelo a a do ponto determinado pelo cruzamento entre os segmentos a e b. Isso faz com que o jogador procure estar entre a bola e o fundo do gol no qual a estratgia e est atuando, servindo assim como um escudo. a Se a bola estiver entre as linhas verde e vermelha ento a funo de ataque a ca (FollowBall ) chamada para o jogador em questo. Isso signica que, caso a e a 13

Figura 8: Area de alcance da funo Defesa ca

bola esteja na rea de alcance do jogador ele tentar jogar a bola na direo a a ca do gol adversrio. a Caso a bola esteja atrs da linha vermelha, o jogador ser repelido pela a a bola. O racioc que, uma vez que a bola est fora do alcanve, o mximo nio e a a que o jogador pode fazer no atrapalhar. Essa medida tem se mostrado e a eciente em fazer com que o jogador no atrapalhe (permitindo que a bola a saia da rea da defesa) porm, ineciente para retomar sua posio adequada, a e ca quando a bola sai de trs da linha vermelha. a O goleiro tambm utiliza a funo Defesa. Porm, a rea de atuao e ca e a ca que determinada para ele, faz com que ele sempre que ` frente da linha e a verde. Essa medida induz o goleiro a car sempre entre o gol e a bola. E importante ressaltar que a ecincia da defesa depende das reas de atuao e a ca que so denidas para cada jogador. a Como dito anteriormente, os jogadores (com exceo do goleiro) no posca a suem posies xas. A funo que cada jogador desempenha depende do co ca Estado do jogo. A funo responsvel por implementar maleabilidade ao ca a time a Strategy. e O Estado do jogo depende da posio da bola, no campo. Existem apenas ca dois Estados, o Estado 1 e o Estado 2. O Estado 1 caracterizado pelo fato e da bola estar no lado do campo do time adversrio. Como existem apenas a dois Estados. Se o jogo no estiver no Estado 1 ento estar no Estado 2. a a a A Figura 9 ilustra o Estado 1. Neste Estado, dois jogadores so designados a 14

Figura 9: Representao do Estado 1 ca

para o ataque, usando a funo FollowBall, e os outros trs usam a funo ca e ca Defesa. A estratgia montada para o Estado 1 faz com que o time ataque e porm, no descuide da defesa. e a A rea de atuao de cada jogador determinada pelas linhas verdes a ca e que segmentam o campo. Dentro de cada uma dessas reas h um ponto a a vermelho. Cada um destes pontos representa o ponto de atrao para cada ca jogador de sua respectiva rea. a A Figura 10 representa a ao no Estado 2. Neste estado, todos os jogaca dores assumem funo de defesa. ca Quando a bola est no lado da defesa todos os jogadores passam a usar a a funo Defesa. Isso faz com que os robs exeram funo de bloqueadores, ca o c ca impedindo que a bola chegue ao nosso gol. Da mesma forma que na Figura 9, as linhas verdes da Figura 10 dividem o campo em reas. Para cada uma das reas formadas, no lado da defesa, a a existe um jogador designado para defender a sua rea. a Como visto anteriormente, quando a bola entra na rea de um jogador a da defesa, esse jogador passa a usar a funo FollowBall e com isso trabalha ca no intuito de expulsar a bola de sua rea, tentando levar a bola para o lado a do adversrio. a A forma dinmica com que a Strategy faz os jogadores se movimentarem, a passando de defensores para atacantes e vice-versa, se apresentou satisfatria. o Porm o dinamismo usado na estratgia para times com trs jogadores mais e e e e 15

Figura 10: Representao do Estado 2 ca

atenuado. 4.1.5 Sub-Mdulo Interativo para Mirosot o

Esta estratgia segue a mesma linha da estratgia para Simurosot com die e ferenas apenas na forma como os jogadores alteram de funes. Quando a c co congurao do campo est no Estado 1, dois jogadores so designados para ca a a o ataque e o terceiro jogador ca no gol. O que dene quais jogadores vo a para o ataque a distncia de cada um deles em relao a bola. Os dois joe a ca gadores mais prximo da bola vo para o ataque, como o ilustrado na Figura o a 11. Quando o jogo est no Estado 2. Os trs jogadores so designados para a e a defesa e o que dene qual deles ser o goleiro a distncia em relao ao a e a ca fundo do gol a ser defendido. Em uma das estratgias o mtodo Defesa possuir o mesmo algoritmo e e a que a defesa da Simurosot e a outra estratgia possuir um algoritmo mais e a simplicado. A inteo fazer jogos entre as duas estratgias e avaliar o ca e e desempenho de cada uma delas.

16

Figura 11: Representao da estratgia para Mirosot ca e

4.2

Campos Potenciais Harmnicos o

Embora a tcnica de Campos Potenciais seja eciente, esta tcnica possui e e limitaes que podem comprometer a ecincia do sistema. Um dos proco e blemas da tcnica de Campos Potenciais a formao de m e e ca nimos locais. Conforme explicado a seguir, uma das caracteristicas do CPH (Campos Potenciais Harmnicos) no possuir m o e a nimos locais. As funes harmnicas foram primeiramente utilizadas para controle de co o robs por Connolly [9]. De acordo com Connolly, uma funo p : R, o ca n com R , uma funo Harmnica, se a Equao 1 for setisfeita. e ca o can

2 p =i=1

p2 =0 x2 i

(1)

Embora os robs sejam tridimensionais, eles se movem em um plano. o Dessa forma R2 . A Equao 1 pode ser reescrita na forma da Equao ca ca 2. 2p 2p + =0 x2 y 2 (2)

Conforme descrito por Faria [11], para resolver equaes diferenciais parco 17

ciais existem mtodos numricos como Gauss-Seidel (GS), Sucessiva Sobree e Relaxaes (SOR) e o mtodo de Jacobi. Aplicar um mtodo de relaxao co e e ca em uma malha resolver o sistema numericamente. a 4.2.1 Mtodos de Relaxao e ca

Alguns mtodos de relaxamento foram implementados. Com o objetivo de e fazer uma anlise comparativa entre os mtodos de relaxamento, ser necesa e a srio denir as dimenses da malha4 . O campo de futebol de robs mede a o o 1, 7mx1, 3m. Cada rob, possui aresta de, aproximadamente, 7, 5cm. Para o discretizar o campo, usaremos uma malha retangular quadriculada. Esta malha, possuir o formato retangular do campo de futebol de robs e ser a o a composta por quadrados de 1cm de lado. Uma vez determinada que cada quadrado possui 2, 5cm de lado, temos que, nossa malha retangular possuir a um total de 170x130 clulas. e Foram analisadas trs opes: mtodo de Jacobi, mtodo de Gauss-Siedel e co e e e SOR (Successive Over Relaxion). O Mtodo de Jacobi possui a caractee r stica de necessitar de duas malhas para o seu clculo. A primeira malha a utilizada para guardar a i-sima iterao e, durante o clculo da iterao e e ca a ca i + 1, esta malha utilizada apenas para leitura. A iterao i + 1 calculada e ca e e armazenada na segunda malha. Por ser um mtodo iterativo, a iterao e ca i + 1 necessita apenas do resultado da itareo i. A vantagem deste mtodo ca e e o fato dele ser altamante paralelizvel. Como descrito adiante, paralelizao a ca ser essencial para executar esta aplicao em tempo real. a ca O mtodo SOR, assim como o de Gauss-siedel necessita alocar espao para e c apenas uma malha, o que representa uma vantagem em relao ao mtodo ca e de Jacobi. Alm desta, o mtodo SOR possui a vantagem de necessitar de e e um menor nmero de iteraes para atingir a convergncia. Entretanto, o u co e fato das iteraes intermedirias do SOR no terem a garantia de serem co a a utilizveis torna o uso deste mtodo imprprio, devido `s necessidades da a e o a aplicao. Por esta ser uma aplicao que deve ser processada em tempo ca ca real, caso a convergncia demande mais tempo do que o limite, para ser e calculada, ser necessrio encerrar as iteraes e utilizar a malha gerada at a a co e o momento. Este um caso em que ser necessrio perder em preciso para e a a a ganhar em tempo. Abaixo est descrita a implementao feita atravs da relaxao pelo a ca e ca mtodo de Gauss-Siedel. eDenir a priori as dimenses da malha necessrio pois a velocidade de convergncia o e a e dos mtodos de relaxamento dependem das conguraes da malha e co4

18

Categoria do Ponto Meta Vazio Obstculo a

Valor Inicial 0.0 0.5 1.0

Tabela 1: Valores iniciais das clulas, na malha e 4.2.2 Mtodo de Gauss-Sidel e

O relaxamento utiliza o operador de Laplace [19], mostrado na Equao 3 ca 0 1 0 (3) Ls1 = 1 4 1 0 1 0 Utilizando o mtodo de Gauss-Siedel com o escolhido operador de Laplace e temos que a clula pi,j da malha obtida de forma iterativa, segundo a e e Equao 4. ca 1 t (pt+1 + pt+1 + pt (4) i,j+1 + pi+1,j ) i1,j i,j1 4 Cada iterao percorre todas as clulas da malha. Quanto maior o nca e u mero de iteraes, mais precisos so os valores da malha. E necessrio denir co a a o nmero de iteraes pelo qual a malha ir passar. Para monitorar a velou co a cidade de convergncia da malha podemos utilizar o erro quadrtico. O erro e a quadrtico eq dado pela Equao 5. a e ca pt+1 = i,jm n

eq =i=1 j=1

(pt pt1 )2 i,j i,j

(5)

Em que m e n signicam o nmero de linhas e colunas, respectivamente, u da matriz que representa a malha. Utilizaremos eq como critrio de parada e para as iteraes. Quando o erro quadrtico for menor do que determinada co a constante, o programa pra de fazer iteraes sobre a malha. a co Lembrando que a malha representa as dimenses de um campo de fuo tebol de robs, foram xados obstculos nos pontos (2cm, 2cm) e no ponto o a (100cm, 100cm) e uma meta no ponto (50cm, 50cm). A congurao inicial ca do campo dada pela Tabela 1. e O primeiro experimento necessitou de 3902 iteraes para que eq conco vergisse para um valor da ordem de 106 . Uma vez que estamos utilizando ponto utuante de preciso simples, escolhemos, como limiar para o erro quaa drtico, o limite de representao do ponto utuante. A Figura 12 uma a ca e representao grca da malha ao nal das iteraes. ca a co 19

Figura 12: Malha gerada utilizando o operador de laplace Ls1 .

20

Ls2 , denido pela Equao 6, um ca e 1 4 Ls2 = 1

outro operador de Laplace. 4 1 20 4 4 1

(6)

A denio de pi,j utilizando o operador Ls2 obtida do mesmo modo que ca e para o operador Ls 1. Utilizando o operador Ls2 , o erro quadrtico alcanou a c 6 10 em 4048 iteraes. Foram realizados experimentos com outras conguco raes de malhas. Em todos os experimentos, a relaxao utilizando Ls2 foi co ca mais lenta do que utilizando o operador Ls1 . Com estes resultados experimentais, podemos concluir que o operador Ls1 leva o sistema ` convergncia a e mais rpido do que o operador Ls2 . a Ao implementar a estratgia utilizando CPH dois fatos importantes foram e observados. O primeiro fato que a necessidade de muitas iteraes ocorre e co apenas no inicio do jogo, ao fazer a primeira relaxao. Depois da primeira ca relaxao so necessrias, em mdia, apenas 10 iteraes. O segundo fato ca a a e co aferido diz respeito a tempo gasto por iterao. O tempo gasto por iterao ca ca 5 de 7ms. Este tempo proibitivo, seriam necessrios 70ms por quadro e e a para executar o CPH. Para melhorar o tempo de execuo, a malha passou a ca ter a dimenso de 85x65 clulas. Esta reduo fez o tempo de execuo, por a e ca ca iterao, cair para 1, 62ms. Este tempo ainda muito alto. Por este motivo ca e foi decidido fazer a relaxao utilizando paralelizaao. O mtodo de Jacobi, ca c e por ser paralilizvel, foi escolhido para substituir o de Gauss-Siedel. a 4.2.3 Mtodo de Jacobi e

O mtodo de Jacobi extremamente parecido com o mtodo de Gauss-Siedel. e e e Matematicamente, a diferena entre os dois mtodos est na equao de relac e a ca xao. A Equao 7 mostra a relaxao para o mtodo de Jacobi. E poss ca ca ca e vel observar que, para executar est mtodo sero necessrias duas matrizes. A e e a a primeira guarda a malha no estado atual e a segunda utilizada para guardar e o resultado da iterao seguinte. ca 1 t t t (pt (7) i1,j + pi,j1 + pi,j+1 + pi+1,j ) 4 A implementao paralela foi feita atravs da biblioteca OpenMP [2]. ca e Com o intuito de obter o melhor desempenho poss necessrio levar em vel e a considerao as caracter ca sticas da arquitetura do computador utilizado. O pt+1 = i,jTodos os sistemas que compem o futebol de robs tem um total de 33ms para serem o o executados5

21

processador um Intel Core 2 Quad modelo Q6600 2.4GHz com 8MB de e memria Cache. o Cada clula da malha ocupa 28 bytes. Isso faz com que toda a malha nee cessite de aproximadamente 150KB. Logo, o grid pode ser facilmente alocado na memria cache, o que prov um considervel ganho de desempenho. o e a A biblioteca OpenMP composta por uma interface que permite gerene ciar o paralelismo da aplicao de modo simples. Aps implementar a verso ca o a paralela da relaxao, utilizando o mtodo de Jacobi, o tempo de processaca e mento necesrio por iterao desceu para 0, 45ms aproximadamente. Este a ca tempo consiste em um speedup absoluto de 3, 6 e desempenho de 0.9. Mais informaes sobre o clculo de speedup e rendimento de uma aplicao paco a ca ralela podem ser encontradas em [3]. Utilizando os resultados obtidos poss e vel manipular um CPH com o custo computacional de 4, 5ms, a cada quadro. O tempo de 4, 5ms consie derado baixo, entretanto necessrio alocar um CPH para cada jogador, o e a que resultaria em 13, 5ms por quadro, que um tempo alto. Uma vez que e a viso computacional consome 20ms, a estratgia e o controle possuem, no a e mximo, 13ms para serem executados. a Uma poss soluo para este problema utilizar a teoria de Campos vel ca e Potencias Localmente Orientados (CPLO), proposta por Faria [13]. Na seo ca seguinte esto descritos os resultados obtidos no estudo do Campos Potencial a Orientados (CPO), que a base do CPLO. e

4.3

Campos Potenciais Orientados

A tcnica CPO foi proposta por Prestes em [21]. Est tcnica consiste em e a e adicionar um vetor de inuncia sobre a malha com o intuito de direcionar o e movimento do rob. A Figura 13 ilustra a inuncia provocada por diferentes o e poss observar que o vetor de inuncia fora o caminho alcanar vetores. E vel e c c a meta com um ngulo prximo ao ngulo do vetor de inuncia. a o a e A diferena matemtica entre CPH e CPO est na equao do relaxac a a ca mento das clulas. A Equao 8 representa o relaxamento das clulas no e ca e CPO, utilizando o mtodo de Jacobi. O CPO adiciona um termo a equae co do CPH, este termo responsvel por produzir o efeito de orientao na a e a ca malha. 1 1 pt+1 = (pt +pt +pt +pt )+ [(pt pt )vx+(pt i, j + 1pt i, j 1vy)] i1,j i,j1 i,j+1 i+1,j i,j 4 8 i+1,j i1,j (8) O CPO muito vantajoso, por exemplo, para fazer com que o jogador e atacante direcione o seu ataque para o gol adversrio ou tambm para ima e 22

Figura 13: Inuncia do vetor v no campo potencial. (a) CPH sem inuncia e e do vetor; (b) CPO com v = (1, 0); (c) CPO com v = (1, 1); (d) CPO com v = (0, 1)

23

pedir que o goleiro abandone a rea do gol. Entretanto, o CPO s consegue a o mapear um tipo de comportamento por malha. Ainda com o CPO necese srio utilizar trs malhas para o controle dos trs jogadores. O CPLO prov a e e e uma soluo para controle de multiplos robs em uma unica malha. ca o

4.4

Campos Potenciais Localmente Orientados

A teoria de CPLO proposta em [13] apresenta uma soluo de baixo custo ca computacional para o controle de mltiplos robs. O CPLO basicamente u o e uma juno entre o CPH e mltiplos CPOs. A cada rob associado um ca u o e vetor e duas constantes e . O algoritmo para relaxar a malha cosiste em percorrer todos as clulas da malha. Para cada clula encontra-se o rob e e o mais prximo. Se a distncia at o rob mais prximo for maior do que , o a e o o e utilizada a Equao 3, caso contrrio, utilizao a Equao 8. ca a ca ca O algoritmo de estratgia ACIn, proposto em [10], que utiliza CPLO foi e implementado e tambm faz parte do USPDS. Posteriormente, sero realizae a dos testes no simulador para vericar o desempenho da estratgia utilizando e CPLO em relao a estratgia que utiliza CP. ca e

5

N cleo do Simulador u

O ncleo do simulador possui duas tarefas: se comunicar com os demais u mdulos e calcular as novas posies e ngulos dos objetos a cada iterao. o co a ca A seguir est descrito o modo como o simulador realiza estas duas tarefas. a

5.1

Gerenciamento da Comunicao entre os Mdulos ca o

Existem, no m nimo, quatro threads no ncleo do simulador. Trs delas u e destinam-se a comunicao. Destas trs, duas so utilizadas para comunicaca e a co com as estratgias, uma thread para cada estratgia. A terceira thread a e e utilizada para comunicao com interface grca. Toda vez que uma ine ca a terface grca se conecta ao simulador, por meio desta terceira thread. O a e papel desta thread criar uma nova thread que converse com a interface e grca, toda vez que uma interface grca se conectar a ela. Desta forma, o a a simulador capaz de se conectar a vrias interfaces grcas. A quarta thread e a a reponsvel por executar a Engine f e a sica. A estratgia e o simulador se comunicam atravs de duas conexes TCP/IP. e e o A escolha por dois sockets ao invs de apenas um se deve ao fato de muitos e times de futebol de robs utilizarem computadores diferentes para processar o a viso, estratgia e comandos de baixo n a e vel do rob. Lembrando que o o 24

simulador desenvolve o papel do sistema de viso e controle de baixo n a vel, durante as simulaes, dois sockets so sucientes para estabelecer a comuco a nicao entre o simulador e uma estratgias. ca e O simulador possui uma porta xa para esperar por conexes da interface o grca, a porta 4321. A thread responsvel por lidar com a comunicao abre a a ca esta porta e espera por conexes. Quando uma conexo estabelecida, a o a e porta trocada, criado uma nova thread e a comunicao continua na nova e e ca thread com a porta que acabou de ser criada. A thread original (responsvel a por esperar conexes na porta 4321) est novamente livre para aguardar por o a novas interfaces grcas. a

5.2

Engine F sica

A Engine F sica o corao do simulador. E nesta parte que so calculae ca a dos os deslocamentos dos objetos, ocorrencias de gols e etc. Basicamente, a Engine f sica tem como entrada o que deniremos como cena atual do jogo. Uma cena o conjunto das posies, velocidades, aceleraes, ngulos, veloe co co a cidades angulares, aceleraes ngulares de todos os objetos (apenas a bola co a no possui referencia a ngulo) e etc no instante de tempo T . O resultado a a do processamento uma nova cena do jogo, referente ao instante de tempo e T + T , em que T o passo de tempo utilizado. Desta forma, para chegar e ao resultado de um jogo inteiro, necessrio realizar vrias iteraes at que e a a co e a soma dos t se equivalha ao tempo total de jogo. Existem trs tipos de objetos: campo, bola e rob. O campo considerado e o e como um conjunto de paredes. A bola uma esfera perfeita. O terceiro e tipo de objeto o rob em formato cbico de duas rodas. A complexidade e o u do modelo f sico adotado determina a qualidade da simulao e tambm o ca e custo computacional para processar o modelo. Utilizar um modelo muito realista aumenta a qualidade da simulao mas tambm aumenta o custo ca e computacional necessrio. Um modelo f a sico pobre, por outro lado, produz uma simulao de qualidade insatisfatria mas com consumo computacional ca o baixo. Embora o simulador se comunique com as estratgias a cada 33ms de e simulao, o passo de tempo T utilizado dentro do simulador menor. A ca e questo que se T tiver um valor grande demais, pode acontecer de colises a e o no serem detectadas. Para explicar melhor vamos pegar um caso em que a um rob e a bola esto em rota de coliso. Em uma das cenas os objetos o a a esto para colidir. Ento esta cena passada para a Engine f a a e sica, que no a detectar nenhuma coliso pois nenhuma coliso ocorreu at este instante. a a a e Como no h coliso na cena a Engine f a a a sica vai calcular os novos atributos dos objetos e gerar a cena seguinte. Se T for grande demais, a nova cena 25

Figura 14: Atributos da classe robo

ter os dois objetos em posio tal como se eles fossem fantasma.... [escrever a ca melhor essa pichorra] Para construir a Engine foram criadas duas classes principais: a classe campo e a classe objeto. Alm dessas duas foram criadas as classes robo e e bola. Estas duas ultimas herdam parte de seus atributos da classe objeto. A priori a classe campo tambm era uma classe lha da objeto. Porm, como e e o campo no possui atributos como velocidade ou acelerao, optou-se por a ca separar a classe campo da objeto. Os atributos de cada objeto so basicamente: posio, velocidade e fora a ca c resultante. Alm disso, para os robs, tem os atributos torque, velocidade ane o gular e ngulo. A cada per a odo t de tempo todos os atributos so calculados a novamente. Como os atributos de um objeto podem depender dos atributos de outros objetos (no caso de colises) foi determinado que para cada o atributo existe um outro atributo relativo ao prximo instante de tempo. o Por exemplo, existem os atributo forca resultante e nova forca resultante. Os dois atributos tm o mesmo signicado porm, se referem a instantes de e e tempo diferentes. O primeiro (forca resultante) se refere ao tempo T (atual), enquanto o atributo nova forca resultante se refere ` fora resultante que a c atua sobre o centro de massa do objeto no instante de tempo T + t. Foram criados atributos secundrios para os robs. Atributos como v roda direita, a o que descreve a velocidade da roda esquerda. Esses atributos secundrios tem a so utilizados para o calculo dos outros atributos. a Para lidar com grandezas vetorias como fora e velocidade foi necessrio c a criar uma classe de vetores nomeada vetor2d. Foram implementados mtodos e para soma, subtao e multiplicao (vetorial e escalar) entre os vetores. ca ca Alm disso tambm foi implementado um mtodo para decomposio de e e e ca 26

vetores. A Engine permanece em em loop innito. No estgio em que o Simulador a est ainda no foram implementados mtodos para reconhecer faltas, gols, a a e m de jogo e etc. O algoritmo que o Simulador segue para recalcular os atributos dos objetos o descrito abaixo: e Identicar colises; o tratar colises; o calcular fora resultante e torque; c calcular velocidade e velocidade angular; calcular nova posio e novo ngulo. ca a

5.3

Deteco de Coliso ca a

No simulador, esto modelados quatro tipos de colises. Estas colises so a o o a entre rob e campo, rob e bola, rob e rob, bola e campo. o o o o A vericao de coliso entre campo e bola, por exemplo, dividida em 16 ca a e vericaes. Uma para cada parede do campo. Como a altura das paredes co do campo maior do que o raio da bola, podemos fazer uma modelagem e bidimensional sem perder a exatido. Neste caso a parede modelada como a e um segmento de reta e a bola como uma circunferncia. Para calcular a e distncia entre este dois objetos utiliza-se a Equao 9 a ca d= bx by 1 1 P 1x P 1y 1 2 P 2x P 2y 1 (9)

O tempo, na simulao, discreto, a coliso detecteda quando os limites ca e a e dos objetos se interseptam e formam uma regio comum. Para evitar o perigo a de um objeto passar pelo outro sem que a coliso seja detectada necessrio a e a estimar a velocidade mxima a qual um objeto pode chegar. Baseado nessa a velocidade poss o tempo ideal de cada iterao. Assumindo que a veloe vel ca cidade mxima no ir ultrapassar 10m/s, escolhemos t = 1, 111... ms. Isso a a a signica que o simulador calcula todas as variveis 900 vezes por segundo. a Exitem dois motivos para se escolher exatamente o nmero 900. O primeiro u o fato de 900 ser um mltiplo de 30, que o nmero de vezes ao qual o e u e u simulador se comunica com as estratgias por segundo. O segundo motivo e e que dessa forma, nenhum objeto se move mais do que 1, 111 cm entre uma iterao e outra. ca 27

As colises foram classicadas em quatro tipos: rob e campo, rob e o o o rob, rob e bola e, nalmente, bola e campo. Colises entre o rob e campo o o o o so detectadas quando o rob colide com alguma borda do campo. Nesta a o vericao, rob e campo so considerados objetos bidimensionais. Para ca o a detectar colises entre dois robs o simulador simplesmente verica se cada o o um dos quatro cantos do rob est dentro do segundo rob. Para calcular o a o se um ponto est dentro de um quadrado vericamos soma das reas S = a a EAB + EBC + ECD + EDA, de acordo com a Figura 15. Se S for maior do que a rea do rob signica que o ponto E est fora do rob e, a o a o portanto, no houve coliso com esta aresta. a a rb rr Considere a Figura 16. Vamos denir dr = cos() e db = cos() . A distncia a limite dlimite = dr + db , ser usada para determinar se houve ou no coliso a a a entre rob e bola.S haver coliso se dlimite for maior do que a distncia o o a a a entre o rob e a bola. o

5.4

Tratamento de Colises o

O tratamento de colises inui de modo signicativo na qualidade da simuo lao. Entretando, modelos muito complexos so computacionalmente caros ca a e modelos simples produzem simulaes com qualidade inferior ` admiss co a vel. Algumas simplicaes podem ser feitas sem que a qualidade seja afetada, co Por exemplo, uma vez que o campo tem uma posio xa, aps toda colica o so com algum objeto no necessrio recalcular a posio do campo. Para a a e a ca todas as colises, os objetos so tratados como sendo bidimensionais. Esta o a simplicao pode ser feita baseado no fato de que os robs sempre estaro ca o a tocando o campo. Uma vez que cada tipo de objeto tratado de modo diferente, necese e srio descrever um algoritmo para cada poss coliso. O primeiro passo a vel a identicar o ponto de impcto, calcular as foras repulsivas que agem soe a c bre os objetos. Aps isso necessrio dividir essas foras em torque e fora o e a c c que age sobre o centro de massa do rob. Desta forma, poss calcular a o e vel acelerao linear e ngular do rob 6 . ca a o

5.5

Funo de Tratamento de Erros ca

Para alguns tipos de colises dif identicar o ponto em que ocorreu o o e cil impcto. Quando robs batem no campo, um lado inteiro do rob pode estar a o o em contato com a parede. A parte de tratamento de coliso no considera a a todas as possibilidades. Isso tornaria o modelo complexo demais. A soluo ca6

No considerado a rotao da bola a e ca

28

Figura 15: Vericar se um ponto est dentro de um quadrado a

para este problema criar uma funo de tratamento de erros que corrige a e ca situao toda vez que o tratamento de erros gera um resultado nitidamente ca errado. Basicamente, o que esta funo faz vericar novamente se os objetos ca e esto em coliso e separ-los. Est funo executada logo aps a funo do a a a a ca e o ca tratamento de colises, logo, se alguma coliso for detectada, signica que o o a tratamento de colises falhou. o A funo de tratamento de erros separa os objetos dois a dois, a medida ca que as colises so detectadas. Esta separao occore sobre a reta determio a ca nada pelo centro de massa dos dois objetos em coliso. Aps separar todos a o os objetos, verica-se novamente se eles esto em coliso. Este procedimento a a repetido at que nenhuma coliso encontrada. e e a e Esta funo de tratamento de colises no se baseia em nenhum modelo ca o a f sico e, embora necessria, denigre a qualidade da simulaao. Felizmente, a c durante os testes realizados, vericou-se que menos de 1% das situaes neco cessitam desta funo. ca

6

Conexo entre os Mdulos a o

Toda as comunicao utilizam o protocolo TCP/IP e o USPDS o servidor. ca e Existem dois tipos de comunicao. O primeiro tipo entre o simulador e ca e a estratgia, descrito na seo 6.1 e o segundo tipo entre o simulador e o e ca e visualizador do jogo, descrito na seo 6.2. ca A interface de comunicao com os mdulos deve prover comunicao ca o ca importante entre entre entre o Kernel, as estratgias e a interface grca. E e a lembrar que o Simulador funciona independente da interface grca estar ou a no funcionando mas, necessrio ter as duas estratgias conectadas. a e a e Conforme o representado na Figura 17, a comunicao entre o Simulador ca 29

Figura 16: Coliso entre bola e rob a o

Figura 17: Representao da interface entre os mdulos ca o

30

e a interface grca unidirecinal, ocorre apenas do Kernel para a GUI. Isso a e ocorre porqu a unica funo da interface grca apenas mostrar o jogo. e ca a e Todas as interaes do usuario com o Simulador ocorrem antes de iniciar co o jogo, por modo texto. Mas isso no impede que a GUI seja interativa. a Para o GUI especicada no projeto de Computao Grca espera-se que ela ca a amazene o jogo a medida que recebe os dados do Simulador para que seja poss manipular o tempo de apresentao do jogo 7 . Tambm faz parte vel ca e da proposta da GUI que o usurio seja capaz de escolher de qual ngulo ele a a deseja ver o jogo. A comunicao do Kernel com as estratrgias ocorre em ambos os sentica e dos. Cada estratgia recebe informaes sobre o jogo a cada 33ms, processa e co essas informaes e retorna as velocidades que as rodas de cada um dos jogaco dores do seu time deve ter. O Kernel no ca esperando por uma resposta de a nenhuma das estratgias sendo que se uma estratgia car um ciclo sem ene e viar dados, o Kernel utiliza as informaes enviadas no quadro mais recente. co Cada uma das threads possuem temporizadores. Trechos de cdigo eno carregados de sincronizar as thread. No estgio atual do Simulador, se esses a trechos no existissem o Kernel processaria informaes a uma velocidade a co maior do que a de tempo real de forma tal que as informaes passadas para co as estratgias seriam inteis. e u

6.1

Comumicao com a Estratgia ca e

Existem dois tipos de comunicao entre o simulador e a estratgia. No ca e primeiro tipo os dados so enviados do simulador para a estratgia e no a e segundo da estratgia para o simulador. O time 1 recebe dados pela porta e e 4322 e o time 2 pela porta 4324. Os dados so enviados na forma de um a array de oat: bx , by , pa[1]x , pa[1]y , pa[1]a , pa[2]x , pa[2]y , pa[2]a , pa[3]x , pa[3]y , pa[3]a , pb[1]x , pb[1]y , pb[2]x , pb[2]y , pb[3]x , pb[3]y . pa[1]x , representa a coordenada x do rob 1 do time a. Os times so representados por a e b, time o a 1 e time 2, respectivamene. A numerao dos robs vai de 1 a 3. Os tipos ca o de coordenadas so x para eixo X do plano cartesiano, y eixo Y e a ngulo a a do rob. Os nmeros so pontos utuantes de preciso simples, de acordo o u a a com o padro IEEE 754. Observe que o tamanho, em bytes de cada nmero a u constante assim como a quantidade de nmeros transmitidos. O tamanho e u deste tipo de mensagem sempre 68 bytes. e As mensagens enviadas da estratgia para o simulador devem ser do tipo: e v[1]x , v[1]y , v[2]x , v[2]y , v[3]x , v[3]y . v[1]x , representa a componente X doSer poss a vel escolher a velocidade com a qual o jogo mostrado, e tambm ser e e a poss escolher a partir de qual ponto a animao deve comear. vel ca c7

31

vetor de velocidade do rob 1. Da mesma forma que a mensagem anterior, o est mensagem enviada como um array de pontos utuantes de preciso a e a simples. E o tamanho da mensagem xo e igual a 24 bytes. Por padro, e a o time 1 utiliza a porta 4323 para enviar este tipo de mensagem e o time 2 utiliza a porta 4325.

6.2

Comunicao com a Interface Grca ca a

Qualquer cliente que queira abrir uma conexo para receber dados sobre o a jogo deve se conectar a porta 4321. Os dados so transmitidos unicamente a no sentido de servidor para cliente. A cada instante de tempo enviado e um array de pontos utuantes que representam bx , by , pa[1]x , pa[1]y , pa[1]a , pa[2]x , pa[2]y , pa[2]a , pa[3]x , pa[3]y , pa[3]a , pb[1]x , pb[1]y , pb[1]a , pb[2]x , pb[2]y , pb[2]a , pb[3]x , pb[3]y , pb[3]a

7

Grid

Uma das vantagens do simulador a possibilidade de avaliar estratgias bae e seado em uma anlise estat a sticas de repetidos jogos. Um jogo tem a durao ca de 10 minutos e no consegue fornecer dados sucientes para avaliar o desema penho de uma estratgia em um ambiente to catico. Com base nisso, surgiu e a o a necessidade de fazer o Grid. O papel do Grid gerenciar a execuo de e ca uma grande quantidade de jogos, distribuindo-os entre vrios computadores. a Todo o sistema foi constru utilizando o sistema operacional GNU/Linux do e faz parte da verso 1.1 do simulador. Durante o desenvolvimento e na fase a de testes foram utilizados seis computadores. Entretanto, o Grid foi constru de forma tal a permitir que este nmero indenido de computadores do u heterogneos sejam utilizados para executar diversas simulaes. Durante e co uma seo de testes, oito mquinas foram utilizadas para compor o Grid. A ca a aplicao funcionou conforme o previsto em todos os testes, o que leva a crer ca que o limite mximo de computadores que o Grid suporta gerenciar est bem a a acima de oito.

7.1

Ferramentas e Mtodos Utilizados e

A princ pio qualquer computador conectado a internet pode fazer parte do Grid, desde que seja acess via SSH (Secure Shell) [23] e esteja executando o vel sistema operacional GNU/Linux. O computador central (o mestre) se conecta aos outros computadores usando o protocolo SSH. A partir do ponto em que

32

a conexo foi estabelecida, o mestre envia uma cpia do simulador para o a o escravo. Recebida a cpia, o escravo aguarda por ordens do mestre. o O mestre utiliza as bibliotecas OMP e PThread para gerenciar threads. No inicio da execuo, o mestre cria um conjunto de threads. As tarefas ca so divididas entre as threads. O algoritmo bsico seguido por cada thread a a simples: para cada tarefa a ser executada, procure o computador menos e ocupado e envie a tarefa a ele. Entretanto, quando o computador mais desocupado encontrado, tambm vericado se ele j no est sobrecarregado. e e e a a a Se o computador estiver sobrecarregado, a thread espera por 30 segundos e realiza uma nova pesquisa. Repete este procedimento at encontrar um come putador dispon para executar a tarefa. Outro detalhe importante que vel e quando uma tarefa enviada a um computador remoto, nada garante que e este escravo executar a funo at o nal. Instabilidade na rede ou queda a ca e de energia, por exemplo, podem fazer com que um escravo receba a tarefa mas no a cumpra. Para se previnir desse tipo de fatalidade, a thread no a a passa para a prxima tarefa at se certicar de que a tarefa corrente tenha o e sido nalizada e o resultado recebido do escravo. Caso algo errado ocorra com a execuo da tarefa, a thread envia a tarefa a outra mquina que possa ca a execut-la. a Para medir o quanto um computador est sobrecarregado utilizado o a e conceito load averagedo Linux. O load average a soma dos processos na e la de execuo com os processos j sendo executados pela mquina. O Grid ca a a utiliza o load averagecorrespondentes aos ultimos cinco minutos do sistema. Esta medida considerada muito comum, simples e util em aplicaes para e co sistemas Linux/UNIX. Para realizar as conexes utilizando ssh necessrio criar um par de chaves o e a RSA [15] ou DSA [6] para permitir que a conexo acontea sem que seja nea c cessrio interao com o usurio. O mestre mantem, em um arquivo de texto, a ca a uma lista dos computadores que podem ser acessados pelo Grid. O formato do arquivo conf/hosts [usuario]@[hostname], por exemplo, dmelo@lar1. Em e que dmelo o nome do usurio e lar1 o nome pelo qual a mquina acess e a e a e vel pela rede. O nome tambm pode ser substituido pelo IP. O Grid verica e constantemente quais mquinas esto dispon a a veis para planejar a distribuio ca de tarefas.

7.2

Testes e Resultados

O tempo que cada escravo consome para executar operaes de comunicao co ca com o mestre representam menos de 2% do tempo total de processamento do escravo. Isso signica que a performance do Grid praticamente proporcional e ao poder computacional empregrado para execut-lo. Durante a execuo do a ca 33

Grid, o mestre tenta manter o load averagepoximo a 6. Isso signica que r mquinas com grande poder de processamento executaro mais simulaes a a co em paralelo do que mquinas com menor desempenho. a Em testes feitos com um computador que utiliza um processador Intel Core 2 Quad 2.0GHz Q6600, com 4 Gbytes de memria RAM, constatou-se o que uma simulao consome, em mdia, 7 minutos. Cinco simuladores execa e cutanto ao mesmo tempo, consumiram aproximadamente 10 minutos para serem nalizados. Para mais do que cinco processos foi constatado que o desempenho (tempo mdio por simulao) aumentava. A explicao do fato de e ca ca que cinco simuladores processando concorrentemente consomem 2 minutos cada, em mdia, enquanto apenas um simulador consome 7 minutos sime e ples. Uma vez que foi utilizado um processador com quatro ncleos, apenas u um simulador processando no era o suciente para ocupar nem um ncleo a u por completo. Isso porque o gargalo durante esta simulao era a comunicaca co entre o simulador e as estratgias. A medida que o nmero de simulaes a e u co foi sendo incrementado, os ncleos comearam a ser ocupados at que, utiliu c e zando cinco simuladores, foi atingido o total aproveitamento do processador. A partir de cinco simulaes executando simultneamente, espera-se que o co a desempenho diminua por conta do aumento da frequncia de chaveamento e entre os processos que o processador ter que fazer. a Um outro teste realizado em um computador com processador Intel Pentium 4 2.8GHz e 2 GBytes de memria RAM, teve como resultado que o o ideal para esta mquina executar apenas um simulador por vez. No caso a e desta mquina, com um simulador, o processador foi totalmente ocupado. a Ao tentar executar dois processadores ou mais, a load averageda mquina a ca muito alto e o desempenho em processar os simuladores diminiu devido ` constante troca de processos. a Como o Grid chega a executar vrias simulaes em uma mesma mquina a co a ao mesmo tempo, ele no utiliza as portas padres do simulador. Para cada a o simulao so escolhidas cinco portas aleatrias, entre 1025 e 65535. Aps ca a o o escolher as portas elas so testadas. Depois de conseguir cinco portas aptas a a serem utilizadas, a ordem de executar a simulao utilizando estas portas ca enviada para o mestre. e

8

Heur stica de Avaliao de Estratgias ca e

Estratgias baseadas em Campos Potenciais (CP), Campos Potenciais Oriene tados (CPO) e Campos Potenciais Localmente Orientados (CPLO) existem constantes de ajuste que determinam aspctos sobre o comportamento dos e robs. O ajuste destas constantes feito de modo emp o e rico e impreciso. Ter 34

uma funo de avaliao que determine o quo eciente uma estratgia ca ca a e e torna poss a utilizao de tcnicas de otimizao. vel ca e ca

8.1

Avaliao entre Duas Estratgias ca e

E importante ressaltar que ainda que um time A sej superior a um time a B, no necessariamente verdade que A ganharia todas as partidas jogadas a e contra B. O fato do time A ser melhor que o time B implica apenas que a probabilidade de A ganhar de B maior do que a probabilidade de B ganhar e de A. Outro fato importante que deve ser levado em considerao que se ca e um time A considerado melhor do que um time B e o time B considerado e e maior do que um time C ento no necessariamente verdade que A melhor a a e e do que C. Entretanto, para a heur stica proposta importante comparar a e performance de um time baseado em um segundo time. Para calcular a probabilidade de um time A ganhar uma partida de um time B, vamos nos basear no Teorema do Limite Central [14], que diz que a soma de muitas variveis aleatrias independentes com a mesma distribuio a o ca de probabilidade tende ` Distribuio Normal. A idia bsica simular a ca e a e diversos jogos entre os times A e B, am de calcular a probabilidade de vitria. o

8.2

Avaliao de uma Estratgia no Contexto Geral ca e

O problema de se avaliar a estratgia A em relao a apenas uma outra e ca estratgia B que na melhor das hipteses chegariamos a uma estratgia e e o e especializada em vencer a estratgia B. Para calcular a qualidade de uma e estratgia em um contexto geral seria necessrio realizar vrias partidas entre e a a a estratgia em questo e cada poss e a vel estratgia adversria. Felizmente, e a uma amostra com algumas estratgias j deve retornar um resultado aceitvel e a a sobre a qualidade da estratgia em um contexto geral. e Vamos denotar por Sn um conjunto constituido por n estratgias distintas e 8 . O vetor n dimensional V representa o conjunto de probabilidades de vitria, de tal forma que a probabilidade de A vencer o time si igual a vi , o e para todo i|1 i P n. O time A considerado melhor do que o conjunto S e n v 1 se, e somente se, i=1 i > 2 . Logo, quanto maior a mdia dos elementos do e n vetor V , melhor time, em relao ao conjunto S. e ca A heur stica de avaliao consiste em comparar a estratgia em questo ca e a com um conjunto de estratgias. Este mtodo no determin e e a e stico. OuDuas estratgias so consideradas distintas se produzem padres de comportamento e a o diferentes sobre os jogadores8

35

Figura 18: Resumo de um Jogo

tro problema que a preciso deste mtodo inversamente proporcional ao e a e e tempo computacional necessrio para processar o problema. a

8.3

Testes e Resultados

Am de obter dados sobre as simulaes foi necessrio instrumentar o cdigo co a o da estratgia de modo tal que a cada jogo fosse gerado um arquivo de texto e representando contendo os instantes de tempo em que os gols ocorreram e um grco para melhor visualizar o resultado. A Figura 18 um exemplo de a e um arquivo gerado aps uma simulao. o ca

99.1

Utilizao caPr-Requisitos e

Para compilar e executar o USPDS so necessrios: a a Sistema operacional GNU/Linux GCC 4.2.0 ou superior G++ 4.2.0 ou superior 36

make libxvidcore4 libxvidcore4-dev freeglut3 freeglut3-dev xlibmesa-gl xlibmesa-gl-dev xlibmesa-glu libglu1-mesa-dev tar xterm9

9.2

Instalar

O modo de instalao simples. Tenha o arquivo compactado do simulador ca e no diretrio corrente. Para descompactar use: o tar -zxvf uspdsXXX.tar.gz Aps isto, basta entrar na pasta e instalar: o cd uspds/ sh congure.sh make O comando make install no est funcionando corretamente no simulador. a a Deste modo, aps instalar, para executar o simulador necessaio entrar na o e r pasta e utilizar o arquivo fast exec.sh sh fast exec.sh Este script ir inicializar o simulador com as duas estratgias contidas a e mais a interface grca. Para executar o simulador manualmente, utilizando a suas prprias estratgia necessrio seguir os seguintes passos: o e e a ./bin/simulator main xterm -e ./bin/eyes localhost 4321 ./bin/strategy localhost 1 ./bin/strategy pf2 localhost 2Xterm o emulador de console recomendado para ser utilizado junto ` interface grca e a a Eyes9

37

Se tudo ocorrer dentro do normal, aps estes passos o simulador estar o a executando com a exibio do jogo na interface grca Eyes. Caso seja necesca a srio matar algum processo referente ao simulador use o script terminar.sh a sh terminar.sh

9.3

Interface Grca - Eyes a

O Eyes possui comandos para alterar o tipo de cmera, zoom e controlar o a tempo de exibio do jogo. Todos os comandos so inseridos como teclas de ca a atalho. abaixo est a lista dos atalhos para os modos de cmera. a a 9.3.1 Tipos de Cmera a

f - Modo de cmera free; a c - Modo de cmera Chase; a o - Modo de cmera Onboard; a F, C, O - Modo de cmera padro; a a A cmera pado proporciona a viso sobre o campo. E permitido que a a a a cmera se aproxime ou se afaste, utilizando as teclas + e -, respecticamente. a Tambm pode-se transladar a cmera ao redor do campo utilizando as teclas e a z, no sentido anti-horrio, ou Z, sentido horrio. As teclas x e X tambm a a e podem ser utilizadas para transladar a cmera em um eixo determinado pelo a centro dos gols. No modo de cmera Free, o usurio pode navegar pelo campo alterando a a a posio da cmera e alterando o ponto para o qual ela est apontada. Os ca a a comandos frente, traz, direita e esquerda so ativados pelas teclas u, j, h a e k, respectivamente. Para subir e descer a cmera, os atalhos so y e b, a a respectivamente. Ao ativar o modo Chase, a cmera ca centrada em um dos robs. Para a o alterar o rob focado pela cmera utiliza a tecla c. A cmera pode se aproo a a ximar do rob atravs da tecla + ou se afastar, utilizando a tecla -. o e A cmera Onboard proporciona a viso de uma cmera embarcada no a a a rob. Para trocar de rob utilize a tecla o. o o 9.3.2 Controle Sobre o Tempo de Exibio do Jogo ca

O controle do tempo de exibio do jogo permite ao usurio adiantar, atrasar ca a e parar o jogo, atravs das teclas . (ponto), , (virgula) e p, respectivamente. e 38

9.4

Concluso a

O projeto j possui a verso 1.0 que a primeira verso estvel. O simulador a a e a a oferece um ambiente real stico e com custo computacional aceitvel para o a desenvolvimento de estratgias nesta plataforma. A possibilidade de executar e simulaes sem a interface grca mostrou-se extremamente util nos casos co a importante ressaltar que em que necessrio executar vrias simulaes. E e a a co o projeto continua em desenvolvimento para correo erros, adio de novas ca ca funcionalidades e melhoria das j existentes. Pretende-se, para a verso 2.0 a a do simulador, dar suporte a mais categorias de futebol de robs. o

Referncias e[1] http://www.ra.net/soccer/simurosot/overview.htm. [2] http://www.openmp.org. [3] George Karypis Ananth Grama, Anshul Gupta and Vipin Kumar. Introduction to Parallel Computing. Addison Wesley, 2003. [4] R. C. Arkin. Motor schema-based mobile robot navigation. The International Journal of Robotics Research, 4(8):92112, 1989. [5] R. A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, 2(1):1423, 1986. [6] James H. Burrows. Digital signature standard (dss). Technical report, Federal Information Processing Standards Publications (FIPS PUBS), May 1994. [7] M. Chen and E. Foroughi. RocoCup Soccer Server, Users Manual, 2002. [8] C. I. Connolly and R. A. Grupen. On the application of harmonic functions to robotics. Journal of Robotic Systems, 10:931946, 1993. [9] Christopher I. Connolly. Aplication of harmonic functions to robotics. Proceedings of the 1992 IEEE International Symposium on, 1992. [10] G. FARIA. Tese de doutorado, icmc. page 92, 2006. [11] G. Faria. Uma arquitetura de controle inteligente para mltiplos robs. u o PhD thesis, Instituto de Cincias Matemticas e de Computao - USP, e a ca 2006.

39

[12] G. Faria and R. A. F. Romero. Estratgia para futebol de robss bae o seada em campos potenciais. I EnRi 2004, (CD-ROM), Anais do SBC 2004 XXIV Congresso da Sociedade Brasileira de Computao ISBN ca 85-88442-93-0, 2004. [13] G. Faria, R. A. F. Romero, E. Prestes, and M. A. P. Idiart. Comparing harmonic functions and potential elds in the trajectory control of mobile robots. IEEE Conference on Robotics, Automation and Mechatronics, Singapore, 1:762767, 2004a. [14] W. Feller. Teoria das Probabilidades e Suas Palicaes. Edgar Blucher, co So Paulo, 1976. a [15] B. Kaliski and J. Staddon. Pkcs 1: Rsa cryptography specications. Request For Comments, Internet Engineering Task Force, October 1998. [16] O. Kathib. Real-time obstacle avoidance for manipulators and mobile robots. IEEE International Conference on Robotics and Automation, St. Louis, Missouri, pages 500505, 1985. [17] G. Klancar. http://msc.fe.uni-lj.si/PublicWWW/Klancar/RobotSimulator.html. [18] B. H. Krogh. A generalized potential eld approach to obstacle avoidance. International Robotics Research Conference Bethlehem, Pennsylvania, 1986. [19] Fujiki Morii. Distortion analysis on discrete laplacian operators by introducing random images. Image and Graphics, 2004. Proceedings. Third International Conference on, 18-20 Dec. 2004. [20] W. S. Newman and N. Hogan. High speed robot control and obtacle avoidance. Proceeding of the 1987 IEEE International, Raleigh, North Carolina, pages 1424, 1987. [21] Edson Prestes. Navegao Exploratria Baseada no Problema do Valor ca o de Contorno. PhD thesis, Universidade Federal do Rio Grande do Sul (UFRGS), Porto Alegre, RS, 2003. [22] C. Thorpe. Path relaxation: Path planning for a mobile robot. Technical Report CMU-RI-TR-84-05, Robotics Institute, Carnegie Mellon University, Pittsburg, PA, 1984. [23] T. Ylonen. The secure shell (ssh) authentication protocol. Request For Comments, Internet Engineering Task Force, January 2006.

40