Desenvolvimento de uma arquitetura baseada em subsunção para um time de futebol de robôs

Dênis Schneider Strassmann

DESENVOLVIMENTO DE UMA ARQUITETURA

BASEADA EM SUBSUNÇÃO PARA UM TIME DE

FUTEBOL DE ROBÔS

Florianópolis - SC Agosto de 2006

Dênis Schneider Strassmann

DESENVOLVIMENTO DE UMA ARQUITETURA

BASEADA EM SUBSUNÇÃO PARA UM TIME DE

FUTEBOL DE ROBÔS

Monografia apresentada ao programa de Bacharelado em Ciências da Computação da Universidade Federal de Santa Catarina como requisito parcial para a obtenção do grau Bacharel em Ciências da Computação.

ORIENTADOR:

Prof. Mauro Roisenberg

CENTRO TECNOLÓGICO

Florianópolis -SC Julho de 2006

“Ciência da computação tem tanto a ver com o computador como a Astronomia com o telescópio, a Biologia com o microscópio, ou a Química com os tubos de ensaio. A Ciência não estuda ferramentas, mas o que fazemos e o que descobrimos com elas."

RESUMO

Este trabalho de conclusão de curso aborda uma estratégia reativa baseada na arquitetura de subsunção na implementação de uma equipe de futebol de robôs, apresentando desde o projeto até sua implementação. O projeto mostra os algoritmos de controle, visão artificial, e comunicação utilizados juntamente com a definição dos comportamentos, através de autômatos finitos, relevantes em uma partida de futebol. A implementação relata as questões tecnológicas que o projeto se submeteu, assim como suas dificuldades e seus resultados.

ABSTRACT

This B. Sc. thesis presents an reactive strategy based on the architecture of subsumption in the implementation of a team of robot soccer, presenting design and implementation. The designt shows the control system algorithms, artificial vision, and communication used in definition of behaviors, through finite automatas, relevant in a soccer game. The implementation reliefs the technological tricks that the project is submitted, as well as its difficulties and its results.

Lista de Figuras

Figura 1: O Desafio Grand Challenge. (a) Read Team em 2004. (b) Logotipo de 2007 Figura 2: Robôs exploradores. (a) Sojourner em 1996. (b) Spirit e Opportunity em 2004 Figura 3: Perspectiva futura de sistemas computacionais.

Figura 4: Dentro do mundo de sistemas embutidos, 6% pertence a robótica. Figura 5: Arquitetura robótica tradicional.

Figura 6: Arquitetura robótica de subsunção.

Figura 7: Robô da Honda no torneio da RoboCup 2003. Figura 8: Logo da RoboCup.

Figura 9: Infraestrutura RoboCup 2004. Figura 10: Logo da FIRA.

Figura 11: Jornada de Robótica Inteligente em Campo Grande - MS, 2006. Figura 12: EyeBots projetados pela UWA.

Figura 13: Arquitetura Hibrida adotada.

Figura 14: Diagrama final da arquitetura de controle. Figura 15: Arquitetura de subsunção dos jogadores. Figura 16: Automato da camada Procurar

Figura 17: Automato da camada desviar. Figura 18: Autômato da camada Carregar.

Figura 19: (a) Diagrama do sistema realimentado. (b) Coordenadas da bola em um frame. Figura 20: Função de correção para perseguir a bola.

Figura 21: Autômato da camada Chutar. Figura 22: Autômato da camada Fazer Gol.

Figura 23: Automato responsável pela comunicação entre os robôs. Figura 24: Máquina de estados da comunicação do módulo externo. Figura 25: Cone de cores do espaço HSV

Figura 26: Cubo de cores do espaço RGB. Figura 27: Conversão de RGB para Hue.

Figura 28: (a) Fluxograma do algoritmo de procura em uma linha. (b) Função de avaliação da concentração de cor em uma linha.

Figura 29: Curva de relação entre distância e número da linha.

Figura 30: Diagrama com a otimização no cálculo da média e o refinamento de novas buscas. Figura 31: Tarefas principais do sistema

Figura 32: Código da execução principal do programa (main.c).

Figura 33: (a) Thread mediadores. (b) Thread Subsuncao. (c) Thread Menu. Figura 34: Código das threads (main.c).

Figura 35: Um modelo padrão para o header.

Figura 36: Um modelo padrão para o \u201ccorpo\u201d do módulo. Figura 37: Arquitetura do software

Figura 38: Modelo das ações de uma máquina de estados. Figura 39: Modelo de uma máquina de estados.

Figura 40: Algoritmo de realimentação para perseguir a bola Figura 41: Erro angular da bola aplicado na correção

Figura 42: (a) Fator de correção aplicado ao tamanho do objeto. (b) Resultado da correção para um objeto de 2cm.

Figura 43: Matriz de correção usada no software (visao.c). Figura 44: Código da conversão de RGB para Hue (visao.c). Figura 45: Fator de erro dos sensores de distância.

Figura 46: Conversação do estado dos sensores feita pelo módulo de sensores (sensores.c). Figura 47: Conversão das mensagens de navegação para os motores (navegação.c)

Figura 48: (a) Controle Remoto do SoccerBot. (b) Janela estendida para observação da comunicação de rádio.

Sumário

2.2 Sistemas Baseados em Comportamentos... 18

2.3 Futebol de Robôs... 20 2.3.1.RoboCUP... 22 2.3.2.FIRA... 25 2.3.3.No Brasil... 27 2.4 EyeBot... 28 2.5 UFSC-Team... 30 3. Projeto... 32 3.1 Arquitetura Hibrida... 32 3.2 Comportamentos... 35 3.2.1.Procurar... 35 3.2.2.Desviar... 37 3.2.3.Carregar... 38 3.2.4.Chutar... 40 3.2.5.Fazer Gol... 41 3.3 Modelagem de Dados... 41 3.3.1.Sensores... 42 3.3.2.Atuadores... 42 3.3.3.Comunicação... 43 3.3.4.Controle Externo... 45 3.3.5.Tratamento de Imagem... 46

4. Implementação... 52

4.1 Aspectos Tecnológicos... 52

4.1.1.Questões do Sistema Embarcado... 52

4.1.2.Programação Modular... 58

4.1.3.Arquitetura do Software... 60

4.1.4.Máquinas de Estado Finito... 61

4.2 Camadas de Subsunção... 63 4.3 Módulos... 64 4.3.1.Visão... 64 4.3.2.Comunicação... 65 4.3.3.Sensores... 66 4.3.4.Navegação... 67 4.3.5.Controle Remoto... 70 5. Conclusão... 72 Referências... 74

1 Introdução

Este trabalho visa desenvolver uma arquitetura baseada na arquitetura de subsunção como estratégia de controle de um time autônomo de futebol de robôs, implementado sobre a plataforma Eyebot, aproveitando todas suas características, como câmera rádio, sensores e atuadores. A arquitetura passará por testes de avaliação e por uma prova de participação de uma campeonato de futebol de robôs.

1.1 Objetivos

A importância de estudos nessa área se deve à necessidade de substituição de tarefas humanas realizadas em ambientes de risco ou de difícil acesso, como pesquisas dentro de vulcões, manutenção de turbinas hidrelétricas, explorações interplanetárias, inclusive em testes de novas tecnologias. Muito mais do que ambientes que necessitam de simples regras baseadas em percepção e ação, são ambientes que precisam de planejamento de ações, e classificação dos dados a partir de uma avalanche de informações vindas de diversos tipos de sensores. E para o sucesso de tais tarefas é imprescindível o experimento e validação de técnicas de reconhecimento, planejamento e controle, assim como o eventual desenvolvimento de novas técnicas, em plataformas reais interagindo com ambientes reais.

subsunção, a fim de avaliar sua utilização em um ambiente real de competição de futebol de robôs.

Será desenvolvido durante o projeto toda a arquitetura dentro da plataforma Eyebot de robôs móveis, juntamente com seus comportamentos, modelação das informações de sensores, incluíndo algoritmos de visão computacional, manipulação de atuadores, e construção de um protocolo de comunicação entre os robôs e um módulo de controle externo.

Um controle remoto simples deve ser desenvolvido para sinalizar o início e o fim de uma partida de futebol aos robôs, juntamente com um controle simples de navegação do mesmo, que será utilizado em etapas de teste e posicionamento remoto do robô.

1.2 Motivação

Robôs móveis autônomos são encontrados hoje em toda a gama de veículos não tripulados. Os veículos terrestres são projetados para uso na entrega de alimentos em hospitais, para mover contêineres em docas de carga e em operações de resgate acompanhando equipes anti-bomba. Outros tipos de robôs autônomos incluem veículos aéreos comumente usados para vigilância, pulverização de lavouras e operações militares, e os veículos subaquáticos, usados em exploração no fundo do mar.

Dentro da área da área de Robótica Móvel Autônoma existem muitos exemplos motivadores de aplicações ambiciosas totalmente funcionais, como é o caso do desafio da DARPA no Grand Challenge, e os robôs de exploração espacial da NASA que estão atualemtne em Marte os jipes

Spirit e Opportunity.

O Grand Challenge é um desafio anunciado pela DARPA, em fevereiro de 2003, onde veículos robóticos auto navegáveis, que não podem receber qualquer tipo de sinais de humanos (exceto uma ordem de parar), competem numa corrida de 322 km no deserto, em 10h ou menos. Os veículos percorrem sobre terreno desconhecido e acidentado, podendo ser trilhas arenosas, passagens sob viadutos estreitos, torres de eletricidade e curas muito sinuosas, sem ultrapassar limites de percurso estipulados pela organização. O trajeto, assim como os limites laterais, são entregues a cada equipe horas antes da partida, contendo coordenadas de GPS ao qual os veículos utilizam para se guiar na corrida.

O primeiro evento ocorreu em março de 2004 com a participação de 15 equipes, e nenhuma conseguiu percorrer sequer 0,5 % (meio por cento) do trajeto exigido. O melhor desempenho foi alcançado pela equipe da Universidade Carnegie Mellon com 11 km de corrida. O que, apesar da grande quantidade de pesquisas, mostra que ainda há um longo caminho a ser traçado no desenvolvimento de veículos totalmente autônomos. A figura 1 mostra o carro automatizado de uma das equipes e o desafio lançado para 2007, que é percorrer parte do percurso em área urbanizada.

(a)

(b)

Figura 1: O Desafio Grand Challenge. (a) Read Team em 2004. (b) Logotipo de 2007

Outro desafio, mas não a caráter de competição, é a exploração robótica de Marte. Atualmente os jipes Spirit e Opportunity, figura 2, estão coletando dados fundamentais para pesquisas sobre o planeta vermelho. Apesar dos veículos não precisarem ser totalmente autônomos e nem se movimentar numa velocidade tão alta como os veículos do desafio da DARPA, eles apresentam uma outra dificuldade a ser vencida, estão a cerca de 360 milhões de km da Terra, o que inviabiliza qualquer tipo de controle remoto em tempo real. Para superar este obstáculo uma equipe, no laboratório de propulsão a jato na NASA, planeja cautelosamente todo movimento executado no planeta vizinho, e envia um código calculado especificamente para uma manobra. Mas isso não ausenta os robôs de autonomia, eles precisam continuar a executar tarefas de sobrevivência em casos de risco em que a equipe não pode responder a tempo. Aqui novamente é possível perceber a quantidade de pesquisa ainda necessária nesse ramo, pois apenas 9 das 33 missões à Marte, cerca de 27%, obtiveram sucesso [App04].

(a)

(b)

Figura 2: Robôs exploradores. (a) Sojourner em 1996. (b) Spirit e Opportunity em 2004

Além das aplicações práticas citadas acima, a área de sistemas embarcados que possui aplicabilidade direta dentro da robótica, também possui desafios bastante motivadores pela sua grande área de atuação e características, como restrições de tempo real, tamanho de código, corretude, robustez e eficiência de algoritmos, que geram temas bastante atuais para pesquisa e desenvolvimento.

Sistemas computacionais embarcados tendem cada vez mais para o mundo da miniaturização e integração como pode ser visto na figura 3, que é um resumo histórico sobre a evolução dos computadores e sua influência tecnológica.

Figura 3: Perspectiva futura de sistemas computacionais.

É uma área que apresenta grandes perspectivas de crescimento e precisa ser estudada para que o desenvolvimento ocorrera sobre bases teóricas bem formalizadas e se consiga um melhor

aproveitamento e resultados robustos. A utilização de técnicas aprimoradas é de suma importância para o desenvolvimento do projeto e garantias de corretudo, segurança e longevidade, uma vez que os sistemas computacionais estão em toda nossa volta, como é mencionado por Zelenovsky e Mendonça:

“O mundo atual oferece-nos uma grande quantidade de equipamentos para desfrutarmos a vida moderna. Temos à disposição telefones que discam por comandos de voz, televisores que se conectam à Internet, microondas operados remotamente, máquinas fotográficas que não usam filmes e automóveis que estacionam sozinhos.” [ZM06]

1.3 Organização do Trabalho

O trabalho basicamente é constituído de uma contextualização, o projeto e a implementação divididas em quatro partes. A primeira parte é formada pelo capítulo de introdução, onde foi apresentado o projeto e as áreas que ele abrange, juntamente com seus objetivos e sua motivação. E o capítulo de contextualização onde é feita uma pesquisa bibliográfica, apresentada as principais competições de Futebol de Robôs e relatado uma síntese do histórico do UFSC-Team.

A segunda parte descreve a etapa de elaboração do projeto, onde a estratégia utilizada é descrita, juntamente com o embasamento teórico dos algoritmos utilizados. Este capítulo descreve todo o funcionamento da arquitetura e justifica as decisões tomadas pela estrutura adotada.

A terceira parte constitui do capítulo de implementação, onde características tecnológicas são levadas em consideração e o programa gerado a partir do projeto é explicado, juntamente com justificativa e basamento teórico das soluções adotadas.

Por fim é relatada a conclusão, mostrando os objetivos que foram alcançados, as falhas de algumas decisões adotadas e uma breve sugestão de trabalhos futuros que puderam ser observados no decorrer deste trabalho de conclusão de curso.

2 Contextualização

2.1 Robótica Móvel

A robótica móvel ocupa-se de estudar e desenvolver máquinas capazes de se locomover, em geral, em ambientes não controlados, ruidosos e desconhecidos. Para atender a estes objetivos, a multidisciplinaridade faz-se necessária. Mecânica fina, elétrica/eletrônica e computação são integradas para dar suporte a esta nova e importante área (Pazos, 2002).

Os desafios são cada vez maiores. Não bastam apenas serem capazes de desviarem de obstáculos e evitarem colisões. Os robôs móveis de hoje devem ser dotados de alguma "inteligência" que lhes possibilite, por exemplo, reconhecer um dentre vários objetos. A fusão sensorial tem sido usada para tentar melhorar as respostas e com isto modelar o comportamento dos robôs. Mas só isto não basta, é preciso algo mais. Neste sentido, a Inteligência Artificial desempenha um papel fundamental. É ela a responsável por essa mudança, de simples máquinas estáticas repetidoras de tarefas a robôs totalmente autônomos capazes de tomarem suas próprias decisões.

Segundo Shimon [Nof99] os robôs podem ser classificados de acordo com sua complexidade:

● Primeira Geração: São robôs tipicamente utilizados em ambientes industriais,

desprovidos de "inteligência" senão aquela programada. O mundo onde atuam deve ser preparado pois eles não são capazes de perceber os objetos ao seu redor com exatidão.

Poucos utilizam um computador dedicado embarcado. No entanto, ainda são usados em fábricas devido ao aumento de produtividade e qualidade do produto gerado e da durabilidade. Tendem a desaparecer à medida que as exigências em termos de produtividade e velocidade aumentarem ainda mais.

● Segunda Geração: O rápida expansão do mercado de semicondutores fez com que

computadores se tornassem produtos baratos o suficiente para equipar robôs. Isto permitiu um avanço significativo pois máquinas anteriormente muito limitadas puderam ser equipadas com controladores que permitiram cálculos em tempo real e controle mais preciso dos atuadores ao longo de trajetórias. Sensores de força, torque e proximidade puderam ser integrados proporcionando maior adaptabilidade e precisão ao trabalho desempenho pelo robô em seu ambiente. Entre as aplicações estão, pintura, montagem e soldagem.

● Terceira Geração: Representam os modelos mais avançados hoje disponíveis.

Caracterimzam-se por incorporarem múltiplos processadores, cada um deles funcionando de forma assíncrona e independente dos demais. Também possuem sistemas supervisórios e de controle destes processadores utilizando funções de alto nível. São capazes de se comunicarem com outros sistemas. Todo seu potencial ainda não foi explorado. Entre suas aplicações estão aplicações extremamente delicadas e especializadas como medicina.

O campo da robótica está atualmente entrando em uma fase de mudanças. Enquanto no passado os robôs eram usados praticamente com exclusividade em fábricas, com o propósito de participar nos processos de manufatura e transporte, agora uma nova geração de serviços robóticos está começando a emergir, onde robôs precisam ter a capacidade de cooperar com pessoas, e fornecer assistência em suas tarefas do dia a dia.

Os robôs não podem mais simplesmente ficar confinados a evitar colisões, mas detectar e interagir com objetos, portanto existe a necessidade de estudos sobre a área de visão robótica. No âmbito desta questão são realizados, em diversos centros de pesquisas ao redor do mundo, experimentos que abrangem situações reais mas restritas a um objetivo específico, entre elas pode-se citar o reconhecimento de bola, gol e companheiros dentro de um campo de futebol de robôs, onde não existe somente a necessidade de detecção mas também de interação, no caso da bola, servindo como um ótimo exercício para o treinamento de técnicas com a visão robótica. Segundo Russel e Norvig [RN04] estão entre os domínios da tecnologia de robótica as

seguintes aplicações:

● Indústria e agricultura ● Transporte

● Atuação em ambientes arriscados ● Exploração

● Ferramentas médicas ● Serviços pessoais ● Entretenimento

● Ampliação da capacidade humana

Segundo o estudo publicado por Tennenhouse [Ten00], os sistemas embarcados ocupam uma fatia em torno de 98% do mercado de sistemas microprocessados, dentro do qual cerca de 6% são utilizados na área de robótica. Isso mostra a importância em se considerar também conceitos atuais alcançados no estudo dentro da área de sistemas embarcados, além da tradicional importância que a inteligência artificial oferece, no desenvolvimento de um sistema robótico.

Figura 4: Dentro do mundo de sistemas embutidos, 6% pertence a robótica.

Sistemas embarcados são executados em dispositivos desde a eletrônica de consumo, como TVs e microondas, até na indústria aeroespacial, por isso geralmente caracterizado de forma demasiadamente genérica como simplesmente sendo um sistemas que não foi projetado para ser de propósito geral, como notebooks, desktops e mainframes. Entre algumas de suas definições temos:

“Hardware e software que forma um componente de algum sistema maior e que o devido funcionamento é esperado sem a intervenção humana” [Fol06]

Apesar da dificuldade de expressar em poucos termos o que é um sistema embarcado, eles possuem várias características em comum, entre elas Perter Marwedel, em [Mar03] identifica as seguintes:

● Realização de uma função ou conjunto de funções específicas. ● Interagem com o ambiente através de atuadores e sensores.

● Sistemas reativos ao ambiente, normalmente expressados por Autômatos.

● Precisam ser confiáveis, pois possuem aplicações onde falhas podem causar catástrofes: ○ Estabilidade.

○ Recuperação. ○ Disponibilidade. ○ Segurança.

● A eficiência não se restringe à velocidade de execução, entre elas também estão: ○ Consumo de energia.

○ Tamanho de código.

○ Utilização de recursos de hardware. ○ Peso.

○ Custo.

● Interfaces dedicadas (botões, LEDs, Buzzers). ● Requisitos de tempo real.

● Sistemas híbridos com partes analógicas e digitais.

Devido a essa grande quantidade de características, o processo de desenvolvimento de software para sistemas embarcados tende a ficar intimamente ligado a métodos formais de especificação e validação de algoritmos, entre elas talvez a que mais apresente estudos relacionados a formalização, é a questão de tempo real. A expressão “Sistemas de Tempo Real” [Hin83] apareceu pela primeira vez na Série Especial sobre Integração de Sistemas publicada na revista

Electronic Design.

O software de tempo real é altamente acoplado ao mundo externo, ou seja, ele deve responder ao domínio do problema (o mundo real) numa escala de tempo ditada por este. Uma vez que o software deve operar sob rigorosas restrições de tempo, o projeto do software muitas vezes é baseado na arquitetura de hardware e também de software, considerando características do sistema operacional, da linguagem de programação e do seu compilador.

2.2 Sistemas Baseados em Comportamento

Em meados da década de 1980, alguns pesquisadores acreditavam que o planejamento de ordem parcial e técnicas correlatas nunca poderiam funcionar com rapidez suficiente para gerar comportamento efetivo para um agente no mundo real (Agre e Chapman, 1987). Em vez disso, foram propostos os sistemas de planejamento reativo; em sua forma básica, esses sistemas são agentes reativos, possivelmente com estado interno, que podem ser implementados com qualquer uma dentre diversas representações para regras condição-ação. A arquitetura de subsunção de Brooks (1986) utilizava máquinas de estados finitos dispostas em camadas instaladas em robôs munidos de pernas e rodas para controlar sua locomoção e evitar obstáculos.

Tradicionalmente é usada uma abordagem para a construção do sistema de controle dos robôs, que decompões o problema em um série de unidades funcionais executadas sequencialmente como é ilustrado na figura 5. Através de um estudo feito por Brooks [Bro85] foram analisadas as necessidades computacionais de um sistema robótico autônomo e decompostas em tarefas essenciais que o robô precisava executar. Cada tarefa foi implementada separadamente e todas foram colocadas para funcionar de maneira competitiva. Muitas tarefas executam de modo conflitante, partindo então para um arquitetura separada em camadas horizontais, chamadas também de níveis de competência, onde camadas mais altas possuem prioridade sobre as camadas inferiores, como é ilustrado na figura 6.

Figura 6: Arquitetura robótica de subsunção.

Cada camada é conectada diretamente aos sensores e atuadores, funcionando de modo totalmente independente. Frequentemente as tarefas mais básicas da arquitetura estão na primeira camada (de baixo para cima) e executam comportamentos puramente instintivos, como mostra na figura 6 que a primeira camada é de evitar a colisão com obstáculos. A medida que os níveis vão aumentando, tarefas mais elaboradas vão sendo executadas, como exploração de ambiente, construção de mapas, até um topo onde processos mais elaboradas como identificação de objetos, planejamento de tarefas e identificação de comportamentos são executados.

O design da arquitetura de Brooks para o desenvolvimento de robôs móveis autônomos é baseado em nove princípios básicos que são discutidos em [Bro85]:

● Complexidade: comportamentos complexos não precisam necessariamente surgir de

sistemas de controle extremamente complexos. Comportamentos complexos podem simplesmente emergir a partir de um ambiente complexo [Sim69].

● Tarefas precisam ser simples.

● Os robôs andam por ambiente desconhecido sem intervenção, ajuda ou controle

humano.

● Os robôs precisam modelar o mundo tridimensionalmente se quiserem executar tarefas

junto com humanos

● Uso de coordenadas relativas para diminuir a quantidade de erros de posicionamento. ● O ambiente possui obstáculos de diversas formas, não somente poliedros perfeitos como

● Dados visuais são mais apropriados para descrever o mundo.

● Os robôs precisa continuar funcionando caso um dos sensores ou atuadores falhar. ● Os robôs devem sobreviver por um longo período de tempo sem ajuda humana.

Os comportamentos reativos em uma arquitetura de Brooks são frequentemente montados a partir de máquinas de estado finitos. Os nós dessas máquinas podem conter testes para certas variáveis de sensores e, nesse caso, a condução da execução de uma máquina de estados finitos estará condicionada ao resultado de tal teste. Os arcos são marcados com mensagens que são geradas quando eles forem percorridos, e que serão enviadas aos atuadores do robô ou a outras máquinas de estado finitos. Além disso, as máquinas de estados finitos frequentemente possuem relógios internos que controlam o tempo de duração do percurso de um arco. As máquinas resultantes normalmente são referidas como máquinas de estados finitos ampliadas, ou MEFAs, nas quais a ampliação se refere ao uso de relógios internos.

2.3 Futebol de Robôs

Os Jogos ocuparam as faculdades intelectuais dos seres humanos – chegando algumas vezes a um grau alarmante – desde que surgiu a civilização. Para pesquisadores de IA, a natureza abstrata de jogos os torna um assunto atraente para estudo. É fácil representar o estado de um jogo e, em geral, os agentes se restringem a um pequeno número de ações cujos resultados são definidos por regras precisas. Jogos físicos, como críquete e hóquei sobre o gelo, têm descrições muito mais complicadas, uma faixa muito maior de ações possíveis e regras bastante imprecisas definindo a legalidade das ações. Com exceção do futebol de robôs, esses jogos físicos não atraíram muito interesse na comunidade de IA [RN].

A participação em jogos foi uma das primeiras tarefas empreendidas em IA. Por volta de 1950, quase ao mesmo tempo em que os computadores se tornaram programáveis, o xadrez foi estudado por Konrad Zuse (o criador do primeiro computador programável e da primeira linguagem de programação), por Claude Shannon (o criador da teoria da informação), por Norbert Wiener (o criador da moderna teoria de controle) e por Alan Turing (o criador da ciência da computação). Desde então, houve um progresso constante no padrão dos jogos, até o ponto em que as máquinas ultrapassaram os seres humanos nos jogos de damas [Sam67] e Othello [Bur97], derrotaram campeões humanos (embora não todas as vezes) em xadrez

(DeepBlue 1997) e gamão [Tes94], e são competitivos em muitos outros jogos.

A idéia do futebol robótico foi mencionada pela primeira vez pelo professor Alan Mackworth da Universidade British Columbia, Canadá. Mas, independentemente dele, um grupo de pesquisadores japoneses organizaram um workshop sobre os grandes desafios da Inteligência Artificial em outubro de 1992, em Tóquio. Este evento desencadeou uma série de discussões sobre como utilizar o jogo de futebol para fomentar a pesquisa em ciência e a tecnologia. Foi feita então uma investigação sobre a viabilidade tecnológica, financeira e o impacto social. Juntamente, foram desenvolvidos regras e protótipos de robôs-jogadores e simuladores. Como resultado destes estudos, concluíram que o projeto era possível e desejável. Assim, em junho de 1993, Minoru Asada, Yasuo Kuniyoshi e Hiroaki Kitano decidiram iniciar uma competição, primeiramente com o nome de Robot J-League (O "J" deve-se a japanese). Esta acabou se transformando na primeira liga profissional de futebol robótico do mundo. Logo a seguir, devido a pedidos de pesquisadores de todo mundo também interessados, mudou-se o nome da liga e do projeto como um todo para Robot World Cup Initiative, ou simplesmente RoboCup. O interesse ao redor do tema atingiu proporções mundias, a ponto de serem criadas federações para organizarem workshops e outros eventos de cunho científico onde são apresentadas as inovações e propostas de cada equipe bem como campeonatos reais - e por vez divertidos - onde pode-se comprovar na prática as melhores estratégias e as táticas usadas pelas equipes. Existem atualmente duas federações internacionais envolvidas em pesquisas com futebol robótico; a Robot World Cup Soccer Games and Conferences (RoboCup) e a Federation of

International Robot-soccer Association (FIRA). Cada uma delas possui seus próprios

regulamentos e categorias, sendo a mais notável diferença entre estas duas federações o enfoque. Enquanto a RoboCup está mais empenhada em fomentar pesquisas na área de IA, dando grande ênfase às inovações e ao aspecto teórico, a FIRA está mais voltada à robótica em si e nas tecnologias de construção dos robôs. São abordagens diferentes com importantes influências nos resultados.

Há também a participação de grandes empresas do setor de tecnologia. Elas foram atraídas pelo enorme leque de oportunidades que pesquisas como estas representam para o futuro e hoje são patrocinadoras destes eventos. Na figura 7 pode ser visto uma foto do robô humanóide FirsStep da Honda International Technical School durante o evento da RoboCup em 2003.

Figura 7: Robô da Honda no torneio da RoboCup 2003.

Talvez a maior vantagem do futebol robótico seja a capacidade de integrar conceitos e tecnologias como: inteligência artificial, sistemas de tempo-real, visão computacional, sistemas multi-agentes colaborativos, fusão sensorial, eletrônica, mecânica fina, robótica móvel autônoma. E entre algumas aplicações que os estudos nesta área proporcionam estão:

● Semáforos inteligentes que se comunicam entre si para desobstruir regiões inteiras de

uma cidade e não apenas cruzamentos [Nun02].

● Veículos autônomos para a exploração de ambientes perigosos e desconhecidos, como

robôs de exploração interplanetária [Zlo02].

● Transporte viário totalmente automatizado, que reconhece e consegue utilizar a malha

rodoviária existente atualmente.

2.3.1 RoboCup

Figura 8: Logo da RoboCup.

A RoboCup, figura 8, é uma iniciativa científica internacional que atualmente envolve mais de 300 grupos de pesquisa ativos em todo o mundo, e como a própria federação cita: “A RoboCup é uma iniciativa internacional de pesquisa e educação. Ela encoraja pesquisadores de Inteligência Artificial e Robótica Inteligente oferecendo um problema padrão onde uma grande

gama de tecnologias podem ser integradas e exploradas” [Rob06]. O futebol foi escolhido por causa da grande quantidade de desafios que um robô precisa enfrentar para jogar efetivamente uma partida. Por exemplo, ele precisa reagir em tempo real a um ambiente altamente dinâmico, cooperar com os companheiros, distinguir os adversários e assim por diante. [Pag04]

Talvez a mais audaciosa das metas até então já estabelecidas por desafios internacionais envolvendo pesquisa e desenvolvimento de tecnologias, a RoboCup formulou o objetivo de “desenvolver até 2050 um time de robôs humanóides totalmente autônomos capazes de vencer o time campeão mundial de futebol pelas regras oficias da FIFA” [Kit99].

Mesmo que o objetivo não seja alcançado, a iniciativa da RoboCup já conseguiu produzir o resultado de criar interesse e disseminar conhecimento sobre Inteligência Artificial e Robótica, crescendo de um pequeno encontro de poucos cientistas interessados para um evento sobre robótica de escala mundial. De fato a RoboCup evoluiu, e a partida de futebol é somente uma das atividades, que agora abrangem um campeonato mundial com diversas categorias; conferências técnicas apresentadas durante o evento; desafios inteligentes (onde desafios são projetados afim de encorajar a comunidade RoboCup à permanecer ativa em diferentes áreas de pesquisa); programas educacionais para estudantes do primeiro e segundo ano ou graduandos; e desenvolimento de toda uma infra-estrutura (por exemplo, todo ano, a arena de treinamento para a liga de Resgate é construída no país cede do evento da RoboCup, como uma facilidade aberta aos pesquisadores da área de robótica de resgate). A figura 9 mostra um pouco da arena construída para o evento de 2004.

Em sua última edição [Rob06], realizada em Bremen na Alemanha, o evento cobriu três competições distintas, a copa robótica de resgate (RoboCupRescue), a copa júnior de robôs (RoboCupJunior), e a copa de futebol de robôs (RoboCupSoccer). Dentro do terceiro domínio as competições são divididas nas seguintes ligas ou categorias:

● Simulation league: Tem o propósito de oferecer um ambiente para o desenvolvimento

de arquiteturas e algoritmos avançadas de controle explorando áreas como coordenação de multi-agentes e estratégias de alto nível sem se preocupar com limitações e evolução de hardware.

● Small Size league: Permite um enfoco no controle centralizado de vários robôs

pequenos, os times frequentemente optam pelo uso de uma câmera global e processamento em um computador externo, direcionando as pesquisas para visão artificial, dinâmica dos times e cooperação. Os robôs apresentam uma certa

convergência de projeto pelas soluções mais otimizadas, sendo as diferenças principalmente no mecanismo de drible e chute.

● Midle Size league: Nesta categoria não é permitida qualquer interação entre os robôs e

uma central localizada fora do campo, ou seja, todo o processamento de visão, sensores, estratégia, locomoção, chute e drible deve ser local. Isso permite que pesquisadores desenvolvam arquiteturas e algoritmos para robôs totalmente autônomos. O tamanho máximo também é maior que outras categorias, podendo chegar a robôs de até 1m de altura.

● Four-legged league: Possui o foco principalmente no desenvolvimento de software para

robôs autônomos capazes de processar informações de sensores locais e cooperar com outros robôs, sem o problema de hardware customizado por causa do uso de uma plataforma estável, viável e padronizada (Sony AIBO robot).

● Humanoid league: Introduzida em 2002, robôs humanóides demonstram uma série de

habilidades que pesquisadores desenvolvem, sendo uma categoria mais voltada a demonstração do que a competição, pois os times ainda não conseguem ser totalmente funcionais para a realização de uma partida completa (devido a uma série de desafios que ainda precisam ser superados), portanto os robôs competem apenas em alguns aspectos de uma partida de futebol, como uma disputa de pênaltis.

A plataforma EyeBot se encaixa na categoria de pequeno porte (small size league), tecnicamente chamada de F180 pois seu tamanho não pode ultrapassar um cilindro de 18 cm de diâmetro e 22cm de altura. A categoria pode tanto usar câmera embarcada como global, sendo no segundo caso a altura máxima permitida para o robô de 15cm. Cada time é livre para desenvolver seus próprios robôs, permitindo inclusive adaptações específicas para o goleiro, o que permite pesquisas mais avançadas em outros aspectos ligados às engenharias, além da programação.

Atualmente a categoria F180 joga em um campo de 3,4m de largura e 4,9m de comprimento e uma abertura do gol de 70cm. Como a categoria pode jogar tanto com visão local ou global, um gol é pintado de amarelo e outro de azul. A bola é um bola comum de golfe na cor laranja. A partida é jogada em dois tempos de 10min com um intervalo de 5min. Durante o jogo não é permitido nenhuma interação dos programadores, os robôs devem ter total autonomia até o fim de cada tempo, sendo permitido mudanças somente durante o intervalo. Cada time pode ter entre 1 a 5 jogadores. Existem regras para faltas, pênaltis, cobranças, lateral, substituição de jogadores e muitas outras que podem ser vistas no página da organização [Rob04].

2.3.2 FIRA

Figura 10: Logo da FIRA.

A FIRA [Fir06], figura 10, surgiu a partir de um comitê internacional formado sob a liderança do professor JongHwan Kim com o objetivo de promover o Micro-Robot World Cup Soccer

Tournament (MiroSot). Assim, um encontro foi marcado e em 29 de julho de 1996 regras e

regulamentos foram criados. Trinta times de treze países aceitaram o desafio. A primeira

MiroSot'96 aconteceu em KAIST (Korea Advanced Institute of Science and Technology), entre

9 e 12 de novembro do mesmo ano. Esta primeira edição contou com a participação de vinte e três equipes de dez países diferentes. A equipe Newton, do Laboratório de Pesquisas Newton foi a vencedora, seguido por SOTY da Coréia. A equipe do CMU foi a campeã na categoria

S-MiroSot, onde um partida é disputada por apenas dois robôs, um por equipe.

Assim como a RoboCup, o objetivo principal da FIRA é o desenvolvimento tecnológico, especialmente na área da robótica e visão computacional. Os eventos promovidos pela FIRA continuam ano após ano, sediando competições em vários países do mundo, inclusive no Brasil. Novamente aqui são agregadas novas categorias a cada edição do evento, comprovando os avanços obtidos desde o início das atividades desta federação.

A FIRA está dividida nas seguintes ligas:

● NaroSot (Nano Robot World Cup Soccer Tournament): Partida jogada por duas equipes,

cada uma composta por cinco robôs sendo que um deles pode ser o goleiro. Apenas três humanos (um gerente, um técnico e um treinador) podem permanecer na área reservada ao jogo. Não mais que um computador por equipe pode ser usado para o processamento da imagem, identificação e localização. Cada robô possui as seguintes dimensões: 4cm x 4cm x 5cm.

● MiroSot (Micro Robot World Cup Soccer Tournament): Nesta categoria uma partida é

jogada por duas equipes compostas de três robôs, sendo um deles o goleiro. Os robôs não deverão exceder as seguintes medidas: 7 5cm x 7 5cm x 7 5cm. As regras restantes são as mesmas da NaroSot. RoboSot (Autonomous Robot-soccer Tournament): Equipes compostas de um à três robôs. Estes podem ser autônomos ou semi-autônomos. Cada robô possui as dimensões: 20cm x 20cm x 40cm. HuroSot (Humanoid Robot-soccer

Tournament): O robô humanóde deverá ter apenas duas pernas (bípede). O robô não

deverá ter mais que 40cm de altura e 15cm de diâmetro total, ou seja, as pernas não deverão exceder o espaço determinado por este círculo. Por ser uma categoria nova, ainda não existem regras definidas. Exibições são feitas mais a título de demonstração.

● KheperaSot (Khepera Robot-soccer Tournament): Nesta categoria, equipes são

compostas por um robô Khepera. A participação humana esta restrita a duas pessoas por time na área de jogo. Os robôs devem ser totalmente autônomos. Desta forma, o processamento das imagens deve ser feito inteiramente on-board.

● QuadroSot (Quadruped Robot-soccer Tournament): Categoria recém criada que utiliza

robôs quadrúpedes. Utilizam, em sua maioria, robôs desenvolvidos pela Sony. São os famosos cães-robô. SimuroSot (Simulated Robot-soccer Tournament): Categoria dedicada ao desenvolvimento de programas clientes. Cada equipe codifica suas estratégias para serem confrontadas com a ajuda de um simulador, onde atuam de cinco a onze programas-jogadores. A grande vantagem neste caso é a ausência total de

hardware. Pesquisas podem ser feitas sem grandes custos envolvidos.

2.3.3 No Brasil

No Brasil as competições acontecem todo ano dentro da Jornada de Robótica Inteligente (JRI) que promove as competições de robótica e o Encontro de Robótica Inteligente (EnRI). As Competições de Robótica reúnem três eventos distintos: A Competição IEEE Brasileira de Robôs, a RoboCup Brasil, e a RoboCupJunior Brasil. A Competição IEEE Brasileira de Robôs, atualmente em sua IV edição é patrocinada pelo IEEE Latin American Robotics Council. Seu objetivo é promover o desenvolvimento científico e tecnológicos nas áreas de Robôs Autônomos e Mecatrônica, na América Latina. Estas competições possuem grande parte dos desafios encontrados pela robótica móvel do mundo real, tais como, navegação em ambientes dinâmicos, exploração de ambiente, realização de procedimentos de contingência em ambiente perigosos ou insalubres, monitoramento ambiental. Esta competição promove torneios nas categorias Lego, Very Small Robot Soccer e Livre.

A RoboCup Brasil atualmente em sua terceira edição, é um projeto conjunto internacional para promover a IA, robótica e campos relacionados. Trata-se de uma tentativa de estimular a IA e a robótica inteligente através do oferecimento de problemas padrão onde diversas tecnologias podem ser empregadas. As categorias que a RoboCup Brasil possui competições são a F-180, Simulação-2D, Simulação-3D, Resgate Simulado e Robôs Virtuais.

A RoboCupJunior Brasil atualmente em usa primeira edição, é uma iniciativa orientada à educação que tem por objetivo introduzir a robótica aos jovens estudantes de ensino fundamental, médio e técnico. Mais do que o desenvolvimento tecnológico, o foco neste liga é a educação e o estímulo ao surgimento de futuros pesquisadores, promovendo competições nas modalidades Dança e Resgate.

A Jornada de Robótica Inteligente de 2006 ocorreu em Campo Grande, Mato Grosso do Sul, no Campus da Universidade Católica Dom Bosco (UCDB) onde a UFSC competiu nas categorias de Lego, dentro da Competição IEEE Brasileira de Robôs, onde conseguiu o primeiro lugar no desafio inteligente, e na categoria F-180, dentro da RoboCup, ficando em segundo lugar. A figura 11 mostra a arena montada para a competição da categoria Very Small na Jornada de

Robótica Inteligente de 2006.

Figura 11: Jornada de Robótica Inteligente em Campo Grande - MS, 2006.

2.4 Robôs Eyebot

A Universidade Western Austrália desenvolve vários modelos de robôs, figura 12, todos com a filosofia de poderem operar de forma totalmente independente, existem dois modelos com rodas, o SoccerBot e o Omni, dois modelos bípedes, o Android e o Walker, e um terceiro modelo hexapode. A UFSC adquiriu três unidades do SoccerBot, o qual foi projetado para satisfazer as regras da liga de pequeno porte (small-size league) da competição mundial de futebol de robôs RoboCup.

Essas unidades móveis de pequenas dimensões e baixo consumo de energia, estão equipadas com um microcontrolador de 32 bits MC68332 da Motorola, um display de LCD capaz de exibir gráficos de baixa resolução (e com apenas 1 bit por pixel ), uma câmera digital CMOS colorida (24 bits por pixel e resolução de 80x60 pixels), uma porta serial outra paralela, saídas digitais, saídas analógicas, dois encoders, três sensores infravermelhos, quatro servo motores e uma unidade de comunicação sem fio, modulada em 433MHz, permitindo o robô a se comunicar com outros robôs ou uma estação de controle.

O microcontrolador MC68332 pertence a família de 32 bits MC68000 da Motorola, voltada para a utilização em hardware de sistemas dedicados e projetada para suportar códigos que exijam uma intensa carga de cálculos, fornecendo uma Unidade Lógica Aritmética completa operando a 32 bits, além de módulos para o suporte de memória virtual, operação no módulo

loop, execução de instruções em pipeline, poderosos modos de endereçamento facilitando o

trabalho de compiladores das linguagens de alto nível, conjunto de instruções especiais para as

Lockup Tables, Interpolações e modos de espera em baixo consumo. Ele possui diversos

periféricos internos, como contadores de 16 bits, watchdog timers, monitor de clock, monitor de barramento, uma unidade avançada para comunicação serial (USART), e acesso externo a um barramento, facilitando a conexão de novos periféricos.

A câmera digital é baseada em um circuito integrado de imagem CMOS, com a resolução de 80x60 com 24bits por pixel, permitindo ao robô fazer aquisição e processamento de imagens localmente, sem necessitar transmitir as informações da câmera para uma estação de trabalho. Associado ao microprocessador de 32 bits da Motorola o pequeno robô consegue autonomia e robustez dando uma excelente opção para pesquisa e desenvolvimento de algoritmos de visão computacional em tempo real, aplicados à robótica móvel.

O sistema operacional RoBIOS (robot input output system), oferece um um pequeno sistema de tempo real com funcionalidades de multi-threading e várias operações de E/S. Podem ser encontradas funções para leitura de sensores de distância, teclado, câmera, configuração de para controle PI em malha fechada dos servomotores, escrita no LCD, funções de áudio, comunicação de rádio e RS232, converçoes analógico/digitais, leitura e escrita na porta paralela, funções de sistema como multi-tasking, semáforos e timers e inclusive uma boa quantidade de funções um pouco mais avançadas para o processamento de imagens da câmera. Nele são encontrados algoritmos para escala de cinza IPColor2Grey(), transformação em preto

e branco IPDither(), detecção de arestas através do operador de Laplace, IPLaplace(), e operador de Sobel, IPSobel(), e um subtrator de imagens IPDiffer(). Constituindo um kit rudimentar para visão computacional e reconhecimento de padrões.

Por ser um sistema operacional voltado para a robótica móvel, ele também possui facilidades para processamento de imagem, incluindo alguns dos algoritmos mais utilizados em sistemas de visão artificial. Muitos sistemas móveis autônomos utilizam uma câmera para sua navegação, desviando assim de obstáculos, e/ou definindo trajetórias a serem realizadas.

As funções de processamento de imagem, que o RoBIOS possui, utilizam como entrada imagens em escala de cinza, enquanto que a câmera fornece uma imagem colorida. Para esta conversão de cores o sistema oferece a função IPColor2Grey() que realiza a operação matemática “(R+2*G+B)/4” em cada pixel de entrada, para produzir a imagem em cinza.

2.5 UFSC-Team

O Projeto UFSC-Team teve início no final do ano de 97, apenas um ano após a realização do primeiro evento mundial de futebol robótico realizado em 1996. Inicialmente contando com a participação de um aluno de doutorado e um professor, evoluiu para conter também alunos de iniciação científica e mestrado. Tornou-se então um importante campo de estudos para a validação de pesquisas principalmente para interessados em Inteligência Artificial. A primeira e principal meta deste projeto era desenvolver um equipe para participar das competições de futebol robótico na categoria simuladores e, talvez mais tarde também participar com robôs reais de pequeno porte.

Após alguns meses de trabalho, em 1998 o primeiro time de futebol capaz de participar da RoboCup na categoria simuladores ficou pronto. Um artigo descrevendo (da Costa e Bittencourt, 1998) as inovações e a proposta foi apresentado no workshop da RoboCup. Este evento acontece em paralelo às competições e serve para promover e incentivar as pesquisas nesta área. Também é o lugar onde são expostas e apresentadas as inovações de cada time. O simulador apresentava uma arquitetura de agentes concorrentes com o processo decisório centralizado.

Em 1999 a versão do time simulado migrou de uma arquitetura de agentes concorrentes para uma arquitetura de agentes concorrente autônomos, devido a problemas de timing e sincronização ocorridos entre os agentes e o ambiente, interferindo nas respostas de tempo real. O sistema baseado em conhecimento responsável pela tomada de decisões também havia se tornado extremamente complexo possuindo regras destinadas a tratar todo tipo de informação, inclusive de alto nível como o tipo de jogada ensaiada a ser utilizada.

Em 2000 chegaram os robôs Eyebot encomendados da Austrália, iniciando um estudo de seu funcionamento e sua utilização por Rottava [Sil03] na sua dissertação de mestrado. A estratégia adotada para a programação desses robôs era a de utilizar a câmera embarcada para transmitir as imagens a um micro computador central localizado do lado do campo, este seria responsável pela análise individual de cada imagem e decisão dos movimentos dos robôs. Porém como conclusão a estratégia foi considerada totalmente inapta para estes robôs, por apresentar um qualidade e velocidade de transmissão muito baixa no rádio.

Em 2006 a equipe foi retomada pelo Grupo de Robótica Inteligente (GPRI), com a intenção de participar de duas categorias do campeonato nacional da Robocup, a Very Small Size, com robôs de dimensôes de 7,5cm³ [Per06], e a Small Size [Sil06] com os robôs Eyebot, que pretende utilizar os robôs adquiridos em 2000 com uma estratégia totalmente autônoma que se encontra no âmbito deste trabalho.

3 Projeto

Este capítulo apresenta as questões de projeto levantadas no período de execução do trabalho, onde as principais características do problema (a autonomia de um robô durante uma partida de futebol) são salientadas e as formas conceituais de cada parte da solução são abordadas. Uma arquitetura híbrida é sugerida juntamente com os motivos que identificaram a necessidade dela, na sequência são explorados os comportamentos dessa arquitetura e por fim formalizados os módulos que ela utiliza.

3.1 Arquitetura Híbrida

Uma arquitetura de subsunção pura, possui os sensores conectados diretamente em suas camadas, permitindo que cada qual interprete as informações dos sensores do seu próprio modo, porém em um sistema embarcado, essa abordagem acaba sendo prejudicada, devido ao uso de recursos caros como aquisição e processamento de imagem. Por outro lado uma arquitetura tradicional não oferece a expressividade reativa que a arquitetura de subsunção possui, e que pode ser explorada em uma partida de futebol de robôs.

Em sistemas embarcados geralmente existe a escassez de memória, de processamento e de energia e mesmo assim precisam ser respeitados requisitos de tempo real, robustez e disponibilidade, interagindo de forma reativa ao meio ambiente. Dentro destas restrições,

processamento desnecessário e redundante devem ser evitados, concentrando tarefas similares dentro de um único algoritmo, ótimo e formalmente correto, sendo executado somente quando necessário.

Atendendo estas considerações, as informações brutas advindas dos sensores e utilizadas largamente dentro do sistema, podem receber uma otimização a partir do momento que toda a modelagem necessária seja executada de uma vez, e os dados já processados então consumidos pelas tarefas dentro do sistema.

Assim uma abordagem hibrida, como mostra a figura 13, é adotada no desenvolvimento da arquitetura dos robôs, separando o sistema em um estágio inicial de modelagem do ambiente (como é feito em arquiteturas tradicionais), tirando proveito de questões importantes das restrições de sistemas embarcados, seguido de um estágio de camadas com comportamentos hierarquizados, aproveitando a característica reativa do modelo de arquitetura de subsunção.

Figura 13: Arquitetura Hibrida adotada.

A vantagem dessa abordagem é a possibilidade de reutilização das informações caras e necessárias durante a realização efetiva de algumas tarefas, por exemplo, para descobrir a posse de bola, as camadas certamente farão a consulta em momentos diferentes, no lugar de cada uma requerer um frame da câmera ou analisá-lo separadamente, o frame e o processamento da imagem são antecipados pela aquisição e o pré-processamento de todas as informações necessárias pelas camadas. Assim elas usufruem de um dado já modelado, permitindo uma atualização mais ágil do estado interno de cada camada, e o processamento de imagem é realizado uma única vez, economizando tempo no ciclo do sistema.

Além da vantagem sobre os aspectos tecnológicos e de sistemas de tempo real do robô, esta abordagem também contorna um problema, que Russel e Norvig caracterizam como sendo intrínseco à arquitetura de subsunção:

“Primeiro, as MEFAs [Máquinas de estados finitos ampliadas]

normalmente são orientadas pela entrada bruta dos sensores, uma organização que funciona se os dados dos sensores forem confiáveis e contiverem todas as informações necessárias para a tomada de decisões, mas que falha se os dados de sensores tiverem de ser integrados de modos não-triviais ao longo do tempo” (Russel e Norvig, 2004).

Utilizando uma arquitetura hibrida a dificuldade é contornada através do pré-processamento das informações fornecidas pelos sensores, onde os dados podem ser modelados de acordo com necessidades temporais ou integração entre sensores, enviando para a entrada das camadas um uma informação confiável e livre de ruídos.

Com os recursos de hardware que a plataforma EyeBot oferece, o diagrama de blocos da figura 14 foi definido para a estruturação do software, utilizando o rádio, os sensores de distância, a câmera, os motores DC e os servo motores para a câmera e o mecanismo de chute. Os blocos de tratamento de imagem e comunicação são evidenciado justamente como estágios de pré-processamento para a arquitetura de subsunção, esta posicionada ao centro do diagrama e responsável pelo comportamento efetivo do robô.

3.2 Comportamentos

A arquitetura de subsunção do robô é decomposta em cinco comportamentos separados segundo à importância das tarefas consideradas durante uma partida de futebol. São estas: Fazer Gol, Chutar Bola, Carregar Bola, Desviar e Procurar Bola, como mostra a figura 15. Onde a mais importante, representada ao topo da hierarquia, inibe as ações das camadas inferiores, e assim sucessivamente caracterizando tarefas prioritárias sobre os comportamentos relacionados à baixo dela.

Figura 15: Arquitetura de subsunção dos jogadores.

3.2.1.Procurar

O comportamento mais básico definido na arquitetura é o de procurar a bola, pois este deve emergir quando nenhuma outra situação relevante estiver ocorrendo, ela também é responsável pela ação de voltar para a defesa quando for solicitado.

O comportamento inicia sua tarefa relevando a informação de que o robô não possui a bola, e se da em um sequência de cinco ações executadas continuamente, que são representadas pela transição dos estados superiores na figura 16. Primeiramente é executado uma busca nas proximidades, com a câmera abaixada e um giro angular de 90°, em seguida a mesma ação porém no sentido contrário somando um ângulo de 90° novamente, ao que já foi percorrido, totalizando 180°. Depois uma busca por localidades mais distantes é feita, dessa vez com a câmera levantada, e em dois passos de 180° na mesma direção, totalizando um giro de 360° sobre o próprio eixo. Para o robô não ficar infinitamente girando, é executado na quinta ação

uma navegação aleatória, denominada de passeio, onde o robô anda em linha reta durante um determinado tempo para sair da posição atual de procura. E por fim o ciclo se repete.

Figura 16: Automato da camada Procurar

Os quatro estados inferiores realizam a busca por uma posição no campo, quando uma mensagem de “voltar” for recebida pelo rádio significa que os robôs precisam assumir uma posição defensiva. O posicionamento ocorre sobre dois pontos previamente definidos, um em cada canto da área do goleiro, e são executados de forma competitiva pelos robôs, pois ambos passam a girar sobre o próprio eixo e seguir em direção ao campo aliado a fim de encontrar uma das duas posições. A primeira unidade que finalizar o processo de posicionamento avisa à outra que já está à caminho de um dos lados, restando a outra unidade a busca pelo posicionamento no outro lado.

3.2.2.Desviar

Esta camada camada é responsável por executar um reflexo defensivo do robô, que é desviar na presença de qualquer obstáculo, seu autômato é demonstrado na figura 17. Basicamente ele atua quando o sensor frontal (denotado por “F” no autômato) é estimulado, migrando seu estado incicial para dentro de um grafo cíclico que define uma ação para cada sensor ativado.

Figura 17: Automato da camada desviar.

No primeiro estado desse ciclo é escolhido uma das direções para desviar, e executado um giro em torno do próprio eixo até que o sensor frontal não esteja mais indicando obstáculo. Os dois estados subsequentes determinam uma direção fixa de giro, uma vez que indicam, além do sensor frontal, um dos sensores laterais (representados por “E” e “D”, esquerda e direita respectivamente). O estado restante do ciclo indica a situação em que todos os sensores foram ativados, lançando assim a ação de “Reh()”, fazendo com que o robô ande para trás até que um dos sensores pare de indicar obstáculo. Toda transição para os estados “E” e “D” possuem direção de desvio fixo, para o estado “F” a direção é escolhida de forma aleatória, e todo estado possui uma transição para o estado inicial (gerada pelo fim da indicação de obstáculo frontal - “!F”), onde nenhuma ação é executada.

3.2.3.Carregar Bola

O comportamento “Carregar Bola'', autômato da figura 18, emerge quando o robô encontra a bola em seu campo de visão, partindo então para a sua direção a fim de conquistar sua posse. Em seguida ela é conduzida levando em consideração duas situações, a primeira (grupo superior direito de estados) é a detecção do campo dos companheiros através da informação “golComp”, onde o robô executa uma curva de 180° conduzindo a bola a fim de seguir para o campo adversário, e caso seja detectado algum obstáculo na direita ou na esquerda, uma das direções de reversão em particular é executada. No grupo de estados mais abaixo, o robô reage à presença de adversários, onde um drible é executado a partir dos sensores estimulados.

Figura 18: Autômato da camada Carregar.

A transição do primeiro para o segundo estado, apresenta uma característica muito importante deste comportamento, que é a de seguir em direção da bola. Nesta ação é executado um algoritmo de correção de rota a partir de um sistema simples com realimentação angular pela câmera. Um sistema realimentado é um mecanismo de correção onde a informação da variável controlada retorna ao sistema, a fim de comparar o sinal desejado com o sinal medido no ambiente. Um diagrama simples é mostrado na figura 19a, demostrando as variáveis existentes para o sistema realimentado na ação de perseguir a bola. O erro é aplicado ao módulo de

controle dos motores, que converte a informação de velocidade em corrente para o motor. A câmera captura um frame do ambiente, do qual é possível calcular a posição da bola referente ao centro do robô, figura 19b, realimentando o sistema com um sinal de posição angular da bola, relativa ao robô, no mundo real.

(a)

(b)

Figura 19: (a) Diagrama do sistema realimentado. (b) Coordenadas da bola em um frame.

A construção da equação que rege a correção da direção do robô em relação a bola, é mostrada passo a passo na figura 20, onde w é a direção angular dos motores, e ela recebe o valor de erro que existe entre o ângulo desejado (αref), e o ângulo medido (αmed) da bola em relação ao robô. O

ângulo desejado é fixo em 90°, uma vez que a bola deve permanecer no centro do campo de visão, para o robô poder conduzir a bola. O ângulo medido precisa ser calculado a partir das coordenadas cartesianas fornecidas pela posição da bola no frame, portanto o arco tangente é calculado convertendo diretamente o eixo das ordenadas em cateto oposto, e o eixo das abscissas em cateto adjacente, descontando a diferença das origens de cada sistema de medição, no caso 30 pixels referentes ao centro da imagem. Como o sistema coordenado atua somente nos dois primeiros quadrantes (y é sempre positivo), os resultados dos ângulos referentes ao terceiro e quarto quadrante são espelhados para valores dentro dos primeiros dois quadrantes, através da operação mod, com o ângulo de 180, existente dentro da aritmética modular.

w = erro

erro = ref−med

ref = 90 o

med = arctanc.o._c.a. , c.o.= y e c.a.= x−30

med = arctan_x−30y  mod 180

w = 90−arctan y

x−30 mod 180

Figura 20: Função de correção para perseguir a bola.

Ao final a equação completa é exibida, seu cálculo é atualizado continuamente, enviando valores de correção angular para o módulo de controle dos motores, até que a bola esteja de posse do robô, permitindo a partir de então sua condução.

3.2.3.Chutar

O comportamento “Chutar Bola” tem prioridade quando o robô está com a bola porém encontra-se cercado pelos adversários, cujo autômato está na figura 21. Sua função é de isolar ou dividir a bola executando a ação de chute. O comportamento emerge a partir da informação de posse de bola e ativação dos três sensores de distância, e o cuidado de não chutar contra o próprio patrimônio é analisado através da informação de “golComp”, que acarreta em um giro até que o gol companheiro não esteja mais sendo detectado, para então a execução do chute.

3.2.5.Fazer Gol

O principal comportamento do robô é o “Fazel Gol”, está no nível mais alta e tem prioridade sobre todas as camadas anteriores. Sua função é executar o chute em direção ao gol, a partir do momento em que o gol adversário for detectado, e caso seja possível perceber que o goleiro não está presente, um chute de uma distância mais longa é realizada. Enquanto a distância para o chute não é alcançada, o robô segue em direção ao gol, corrigindo a rota para o lado com maior abertura. O chute é realizado juntamente com um período de aceleração, a fim de passar para a bola um máximo de velocidade.

Figura 22: Autômato da camada Fazer Gol.

3.3 Modelagem de Dados

A arquitetura definida possui 4 módulos que fornecem e consomem as informações das camadas de subsunção. Os módulos de processamento de imagem e sensores são somente de entrada para o sistema de comportamentos, enquanto que o módulo de motores, que controlam os motores DC e os servo motores, são de saída. O quarto módulo, de comunicação, no entanto pode fornecer e receber informações do sistema de comportamentos.

A troca de informações dentro do sistema se da através de mensagens, portanto além de funções algoritmicas que cada módulo pode conter, existe também a necessidade de discretização das mensagens, onde todas as possibilidades de valores usadas em cada módulo são resumidos em alguns valores principais.

3.3.1.Sensores

O módulo de sensores é responsável pela utilização dos sensores de distância, ficando responsável por ligar, desligar, executar a aquisição e principalmente discretizar o valor de acordo com a necessidade dos comportamentos da arquitetura de subsunção.

Dentre as mensagens utilizadas, existe principalmente a necessidade do aviso de um obstáculo perto, portanto a separação da faixa útil em três valores aceitável, e pode ser definido através do seguinte conjunto:

Sensores = {PERTO , MEDIO , LONGE}

3.3.2.Atuadores

Os atuadores possuem o controle dos motores DC para navegação e dos dois servo motores, para o chute e para a câmera. Para a navegação é necessário comandos para se locomover para frente, para trás e girar para cada um dos lados, dessa forma a discretização parte principalmente desses quatro comandos: frente, trás, direita e esquerda. Um conjunto mais completo é elaborado para permitir um controle simples de velocidade (normal, lento e rápido), juntamente com um comando de parar, portanto o conjunto fica definido da seguinte forma:

Navegacao = { parar , frentel , frente , frenter , reh , girohorl , giro hor , giroahorl , giro ahor}

Para o controle do servo motor responsável sobre o mecanismo de chute, dois valores são apropriados para suprir a demanda dos comportamentos elaborados (levantar o chute e baixar o chute), um terceiro comando é adicionado para a realização de passe de bola, onde o servo não atua com a força máxima, e sim em uma intermediária. Ficando o conjunto de mensagens definido da seguinte forma:

O servo motor da câmera é utilizado somente para a localização da bola, portanto dois valores são suficientes para o seu controle, são eles: câmera reta, que é o posicionamento normal da câmera e permite a visualização do campo de forma ampla; e câmera direcionada para baixo, que serve para analisar a posse de bola ou verificar se ela está nas proximidades. O conjunto de mensagens para o controle do servo da câmera pode então ser definido da seguinte forma:

Camera={cima , baixo}

3.3.3.Comunicação

O módulo de comunicação implementa um protocolo que pretende complementar o protocolo usado pelo sistema operacional, oferecendo um serviço de transmissão de mensagens confiável, ou seja, retransmissão de pacotes perdidos, pois a rede EyeNet somente oferece tolerância a falhas, onde são descartados pacotes que possuem erros de transmissão. Este serviço é implementado através de uma arquitetura de envio/resposta, caso a resposta não seja recebida dentro de um tempo, ela é retransmitida.

O protocolo possui basicamente cinco tipos de mensagens: “com bola”, “sem bola”, “voltar”, “posição” e “comando remoto”. Os dois primeiros são trocas de mensagens entre jogadores durante uma partida, quando alguém está de posse da bola, avisa aos companheiros que está com ela, dessa forma eles não precisam procurar ou disputar a bola e o goleiro não precisa ficar atento caso a bola esteja vindo em sua direção. A estratégia adotada nesse estado é de manter os robôs o máximo de tempo parado afim de economizar energia das baterias durante uma partida. Enquanto que o aviso “sem bola” avisa uma perda dela, informando aos companheiros que voltem a situação normal de jogo. Ambas as mensagens são implementadas por uma máquina de estados, mostrada na figura 23, que ao enviar o comando esperam por duas confirmações, caso elas não cheguem dentro de um tempo limite, o comando é reenviado.

O comando “voltar” é utilizado pelo goleiro, alertando os companheiros que a bola está próxima ao gol e que precisam assumir uma posição defensiva, e a partir da posição de defesa continuar com os comportamentos normais de procurar bola e disputar sua posse. Ao chamar os companheiros o goleiro espera por duas confirmações, caso elas não cheguem dentro de um tempo limite, o comando é reenviado. Ao receber a mensagem de voltar, os jogadores tem a liberdade de procurar pelo lado mais próximo de sua posição atual, e ao se dirigir até ela,

informa ao seu companheiro que lado escolheu, através do comando “posição” seguida da identificação deste lado, restando ao outro jogador procurar o lado oposto. Esta mensagem espera somente uma resposta de confirmação, pois o goleiro não precisa participar da negociação de posicionamento.

A mensagem “remoto” serve para a estação enviar ordens para cada jogador, ou a todos ao mesmo tempo, informando-os do início da partida, uma paralisação ou final da partida. O comando também oferecerá um controle das ações do robô, no qual ele deixa o estado autônomo e passa para um estado escravo, seguindo unicamente as ordens vindas da estação. Estes comandos podem ser do tipo “ir para frente”, “ir para trás”, “girar horário”, “girar

anti-horário”, “levantar o chute”, “abaixar o chute”, “levantar a câmera”, “abaixar a câmera”.

Figura 23: Automato responsável pela comunicação entre os robôs.

Para a realização da comunicação o pacote possui um tamanho fixo de quatro campos, sendo eles: Mensagem, Complemento, Destino e Tipo. A mensagem pode assumir uma entre “com