Dênis Schneider Strassmann DESENVOLVIMENTO DE UMA ARQUITETURA BASEADA EM SUBSUNÇÃO PARA UM TIME DE FUTEBOL DE ROBÔS

Transcrição

1 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

2

3 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 UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO Florianópolis -SC Julho de 2006

4 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." Edsger Dijkstra

5 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.

6 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.

7 Lista de Figuras Figura 1: O Desafio Grand Challenge. (a) Read Team em (b) Logotipo de 2007 Figura 2: Robôs exploradores. (a) Sojourner em (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 Figura 8: Logo da RoboCup. Figura 9: Infraestrutura RoboCup Figura 10: Logo da FIRA. Figura 11: Jornada de Robótica Inteligente em Campo Grande - MS, 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.

8 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.

9 Sumário Resumo Abstract Lista de Figuras 1. Introdução Objetivos Motivação Organização do Trabalho Contextualização Robótica Móvel Sistemas Baseados em Comportamentos Futebol de Robôs RoboCUP FIRA No Brasil EyeBot UFSC-Team Projeto Arquitetura Hibrida Comportamentos Procurar Desviar Carregar Chutar Fazer Gol Modelagem de Dados Sensores Atuadores Comunicação Controle Externo Tratamento de Imagem... 46

10 4. Implementação Aspectos Tecnológicos Questões do Sistema Embarcado Programação Modular Arquitetura do Software Máquinas de Estado Finito Camadas de Subsunção Módulos Visão Comunicação Sensores Navegação Controle Remoto Conclusão Referências... 74

11 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. Seguindo esta necessidade uma arquitetura de nível reativo é estudada, a arquitetura de 9

12 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. 10

13 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 (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]. 11

14 (a) (b) Figura 2: Robôs exploradores. (a) Sojourner em (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 12

15 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. 13

16 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. 14

17 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 15

18 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: 16

19 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. 17

20 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 5: Arquitetura robótica tradicional. 18

21 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 modelados em ambientes artificiais. 19

22 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 20

23 (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

24 Figura 7: Robô da Honda no torneio da RoboCup 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 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 22

25 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 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 23

26 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. Figura 9: Infraestrutura RoboCup

27 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] 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- 25

28 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 26

29 hardware. Pesquisas podem ser feitas sem grandes custos envolvidos 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 27

30 Robótica Inteligente de Figura 11: Jornada de Robótica Inteligente em Campo Grande - MS, 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. Figura 12: EyeBots projetados pela UWA. 28

31 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 29

32 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 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. 30

33 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. 31

34 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, 32

35 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: 33

36 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ô. Figura 14: Diagrama final da arquitetura de controle. 34

37 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 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 35

38 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. 36

39 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. 37

40 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 38

41 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. 39

42 w = erro erro = ref med o ref = 90 c.o. med = arctan, c.o.= y e c.a.= x 30 c.a. y med = arctan mod 180 x 30 w = 90 arctan y mod 180 x 30 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 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. Figura 21: Autômato da camada Chutar. 40

43 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. 41

44 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 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 } 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, giro horl, giro hor, giro ahorl, 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: Chute={voltar, toque,chute } 42

45 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} 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, 43

46 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 antihorá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 bola, sem bola, voltar, posição e remoto. O complemento serve para as mensagens de 44

47 posição e remoto, que exigem uma informação a mais a ser transmitida. O Destino informa para quem a mensagem é enviada, podendo ser para um dos jogadores, o goleiro ou a estação. E por último, o tipo, informa se é uma mensagem de envio ou de resposta. A resposta deve possuir a mesma mensagem e complemento do pacote enviado, para garantir que a resposta é referente ao comando correto. O protocolo EyeNet já possui uma identificação de origem da mensagem, porém, para a estação poder entrar em modo de escuta, onde as mensagens trocadas entre os jogadores durante a partida podem ser visualizadas, todas são enviadas em modo broadcast, sendo a identificação colocada no pacote transmitido. Dessa forma fica à cargo do protocolo de comunicação aceitar ou negar um pacote Controle Externo Um módulo externo é necessário principalmente para enviar os comandos ao robô sobre início e fim de uma partida. Ele é utilizado também para a monitoração da comunicação entre os robôs, onde toda troca de mensagens é exibida ao usuário através da forma de um texto corrido, permitindo a avaliação do funcionamento do protocolo assim como observação do comportamento dos jogadores. O controle possui dois comandos principais, iniciar e finalizar uma partida, e habilitar e desabilitar o modo remoto. Dentro do segundo comando podem ser enviados comandos para o controle de navegação do robô, entre eles: 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. Cada mensagem possui a estrutura de pacotes relatada no módulo de comunicação, e todo comando enviado espera uma resposta das unidades como confirmação de recebimento do comando. A máquina de estados responsável pelo gerenciamento de envio e re-envio de pacotes é mostrada na figura

48 Figura 24: Máquina de estados da comunicação do módulo externo. Cada comando pode ser enviado individualmente para cada unidade, portanto o número de confirmações recebidas pode ser variável. Dessa forma a máquina de estados implementa um estado que conta a quantidade de confirmações recebidas, e dependendo do número de vezes que a mensagem já foi reenviada, decide se o pacote é definido como perdido ou se realiza um novo reenvio. A contagem é realizada dentro da função conf(), a comunicação bem sucedida é contabilizada através de confall(), uma mensagem reenviada é executada através de um timeout(), e a perda de um pacote informada através de um reset() Tratamento de Imagem Os sistemas de visão (conhecidos como visão artificial, visão computacional ou visão robótica) fornecem uma imagem de relativa precisão, capaz de ser analisada e interpretada digitalmente. A interpretação pode ser definida em termos computacionais como a transformação de um conjunto de dados digitais representando uma imagem em uma estrutura de dados descrevendo a semântica deste conjunto de dados em um contexto qualquer. A Visão Computacional enfrenta uma série de desafios que vai desde aspectos teóricos, que Russel e Norvig [RN04] definem em termos de percepção de agentes, que é a dificuldade de, a partir de uma representação sensória modelar o estado do mundo, até questões tecnológicas que esbarram na grande quantidade de informação gerenciada e todo o ruído que os dispositivos de aquisição e digitalização introduzem. Portanto, é uma disciplina que se encontra ainda nos seus primórdios, sendo a grande maioria de suas soluções e abordagens objeto de pesquisas, o que pode ser percebido na colocação de Wangenheim: Uma das características mais marcantes do estado da arte em Visão Computacional é que ainda não existe nenhum modelo genérico de percepção visual passível de ser aplicado na prática. O conhecimento de como funcionam os 46

49 mecanismos de percepção visual nos animais tampouco é suficiente para a aplicação de algum mecanismo de "engenharia reversa", utilizando por exemplo técnicas de redes neurais para modelar ou imitar a percepçaõ visual biológica. (Wangenheim, 2005) O que ocorre na prática, é que, para a resolução de uma determinada tarefa de interpretação de imagens são utilizados um conjunto de algoritmos específicos, que são respectivamente responsáveis por realizar subtarefas limitadas dentro do processo de interpretação dessa imagem. Essas tarefas, segundo Groover et. al.[gw89], podem ser classificadas em: redução do dados de imagem, extração de características e reconhecimento de objetos. Entre a variedade de algoritmos é possível identificar vários grupos, como filtros de contraste, detectores de bordas de objetos, segmentadores de imagens em regiões, classificadores de texturas e assim por diante. Comumente um problema é resolvido encaixando um conjunto desses algoritmos um após o outro para a obtenção de um resultado que só funcionará para um conjunto de imagens com características muito específicas, deixando de funcionar para todas as outras. Na robótica as principais tarefas realizadas pelo sistema de visão podem ser generalizados para a inspeção de produtos na linha de produção, identificação de objetos e navegação autônoma em ambientes reais. No domínio do problema de futebol robótico uma das finalidades da câmera é a identificação da bola, do próprio gol e do gol adversário. Tomando como base o artigo de Bräunl e Graf [BG99], que mostra a detecção de objetos com robôs da familia EyeBot, os objetos (bola e gols) podem ser reconhecidos através da procura de suas cores, no espaço de cores HSV, da imagem analisada. O padrão HSV (das iniciais de Hue, Saturation, Value), é uma forma de representação das cores, desenvolvido por Smith [Smi78], definido em um sistema de coordenadas cilíndricas em termos de tom, brilho e vibração, normalmente representado por um cone, como mostra a figura 25. Nesse sistema todo o espectro de cores é representado em somente uma coordenada (o ângulo), o que traz basicamente duas vantagens, a facilidade na busca de uma cor dentro da imagem e uma certa robustez com as variações de brilho do ambiente. É normalmente o sistema de cores mais utilizado nos sistemas de visão computacional pois muitos algoritmos de processamento de imagem usam como base tons de cinza, representado pelo eixo do brilho. 47

50 Figura 25: Cone de cores do espaço HSV A câmera da família EyeBot fornecem a imagem em um sistema de cores RGB, em que o espaço de cores é representado através das componentes primárias vermelho, verde e azul definido em um sistema de coordenadas cartesiana, como mostra a figura 26. Este sistema é o mais utilizado por dispositivos de aquisição e formação de imagem, pois possui uma relação direta com uma grandeza física, que é a energia da onda eletromagnética. Figura 26: Cubo de cores do espaço RGB. A diferença dos sistemas coordenadas exige uma uma transformação, no caso da identificação de cores somente o valor do tom é interessante, por isso a única coordenada que precisa ser convertida é a coordenada angular, mostrada na figura

51 Figura 27: Conversão de RGB para Hue. Com a imagem representada pelo tom de cada pixel, é executado uma busca em cada linha pela concentração da cor desejada. Para a obtenção dessa concentração de cor o algoritmo busca os primeiros dois extremos de um possível objeto e realiza uma média aritmética de todas as diferenças entre a cor do pixel da cor desejada. Se essa média for menor do que uma certa tolerância para a cor do objeto, ele é aceito, caso contrário o algoritmo se repete até que os dois pontos extremos se encontrem. Um diagrama pode ser mostrado na figura 28, juntamente com a função do calculo para o reconhecimento da concentração de cor. Avaliação do objeto: ultimo i= primeiro pixel i cor ultimo primeiro limiarcor (b) (a) 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. 49

52 Neste processo porém, o cálculo da média das diferenças entre as extremidades encontradas é repetido toda vez que a média não atingir o valor de limiar. Um processo de otimização pode ser realizado se após a primeira busca soma for armazenada e então a partir da segunda busca, em que uma nova soma é calculada, o valor é subtraído da soma armazenada, e do resultado final é gerada uma nova média consequentemente avaliada sua tolerância. O diagrama é mostrado na figura 30. Um refinamento ainda pode ser alcançado ao executar as novas buscas de forma alternada, dependente de qual lado o deslocamento é maior. O algoritmo sugere três variáveis que podem ser escolhidas para a procura de um objeto, a cor, a tolerância e o tamanho. A cor e a tolerância influem diretamente na função de avaliação, identificando o intervalo de cores a ser procurado. O terceiro parâmetro no entanto depende da linha em que a procura está sendo executada, que é proporcional a distância em que o objeto está da câmera. Segundo experimentos realizados no artigo tomado como base [BG99], essa correção do tamanho avaliado em relação a distancia do objeto sugere uma curva exponencial, figura 29, que é uma função matemática custosa para ser executada pelo robô, portando no lugar do uso da aproximação de uma função é preferível o uso de tabelas com valores pré definidos, que permite um maior desempenho e maior acurácia quando adquirida através de calibração. Figura 29: Curva de relação entre distância e número da linha. Para a busca dos pontos de extremidade de um objeto também é usado o mesmo valor de tolerância que a função de avaliação da cor média usa. A avaliação de que determinado pixel pertence ou não à cor procurada é definida da seguinte forma: { alike = true, false, if pixel cor limiarcor if pixel cor limiarcor } 50

53 Figura 30: Diagrama com a otimização no cálculo da média e o refinamento de novas buscas. 51

54 4 Implementação 4.1 Aspectos Tecnológicos Nesta seção serão abordadas as questões tecnológicas que foram consideradas no desenvolvimento da arquitetura do software, relevando questões do SO, técnicas de programação e aspectos de linguagem de programação Questões do Sistema Embarcado Na obra clássica de Tanenbaum [Tan03], os sistemas operacionais são classificados em: Sistemas para computadores de grande porte, sistemas para servidores, sistemas para multiprocessadores, sistemas para computadores pessoais, sistemas de tempo real, sistemas embarcados e sistemas operacionais de cartões inteligentes. Dentre as características de sistemas embarcados citadas no capítulo anterior, talvez a que apresente a maior quantidade de estudos e aplicação seja a área de tempo real. Durante muitos anos, os principais consumidores de sistemas de tempo real foram os militares. Hoje, porém, significativas diminuições nos custos de hardware tornam possível que a maioria das empresas se dêem ao luxo de possuir sistemas (e produtos) de tempo real para aplicações diversas, que incluem controle de processos, automação industrial, robótica, pesquisa médica e científica, 52

55 computação gráfica, comunicações locais e em áreas extensas, sistemas aeroespaciais, testes apoiados por computados e um amplo conjunto de instrumentação industrial. O RoBIOS, é um sistema operacional embarcado com algumas características de tempo real, pois o tratamento dos periféricos do robô, por exemplo, a aquisição de um frame da câmera, o controle em malha fechada dos motores, e toda a comunicação via rádio, ocorre a medida que as interrupções do hardware vão sendo geradas. A API, porém, se limita ao oferecimento de um temporizador em tempo real para a utilização na programação, deixando outras características de sistemas de tempo real a cargo do programador, o qual deve então se aproveitar das funcionalidades do processador, fazendo uso das interrupções dos dispositivos não alocados ao sistema operacional. Apesar de sistemas embarcados poderem ser programados para a realização de uma única tarefa, muitas aplicações chegam a ser sofisticadas o bastante a tal ponto que a expressão em um único programa possa ser complexa e dificilmente gerenciável, mesmo inconveniente que aparecem em sistemas de maior porte. Desta forma a realização de multitarefa [Woo90] ou processamento concorrente, acabam também sendo muito importantes em sistemas de tempo real, porém um pouco mais elaborados, pois o escalonamento de tarefas não depende somente de um nível de prioridade, largamente utilizado pelos algoritmos clássicos, mas também da janela de tempo que a tarefa precisa ser executada (deadline). O RoBIOS, por ser um sistema embarcado, acaba não oferecendo suporte para o escalonamento de tarefas em tempo real, que geralmente acaba sendo uma tarefa cara devido ao algoritmo de escolha durante o processo de troca de contexto, portanto o sistema oferece um conjunto funcionalidades somente para as duas formas clássicas para a realização de multitarefa, chaveamento de processos cooperativo e preemptivo, que é escolhido na inicialização do do ambiente multitarefa do sistema, executado pela função OSMTInit(). Para o gerenciamento de threads existem as funções OSSpawn(), para criar uma thread, OSReady() para incluir a thread na fila de ready, OSKill() para finalizar uma thread, OSRun() que seleciona a thread que passará a ter o controle da CPU e OSSuspend() que coloca uma thread em modo suspenso. Algumas funções só podem ser chamadas pela própria thread, é o caso de OSReschedule() que coloca a thread atual na fila de ready e seleciona outra para ser executada, OSYield() que coloca a thread atual em modo suspenso e OSExit() que finaliza a thread atual e escalona outra para ser executada. O RoBIOS também oferece uma função para a execução de temporizações dentro de 53

56 um programa, executado pela primitiva OSSleep(), que implementa uma espera que imediatamente escalona outra thread para utilizar a CPU, diferente do OSWait() que implementa uma espera ocupada. Para aplicações de tempo real, onde tempo precisam ser cumpridos, o RoBIOS oferece as funções de OSSuspend() e OSPermit(), que podem ser utilizados para garantir o término de uma tarefa sem que o escalonador, no modo preemptivo, a tire da CPU. Em um sistema multitarefas, comumente existe a necessidade que as tarefas passem informação umas às outras, portanto o sistema deve prever mecanismos de comunicação e sincronização intertarefas. O RoBIOS não oferece nenhum mecanismo de comunicação entre threads, porém eles podem ser elaborados através do suporte de semáforos [Dij65], que o sistema operacional possui através das funções OSSemInit(), OSSemP() e OSSemV(). São utilizados atualmente três tipos de comunicação entre processos: memória compartilhada, sistema de mensagens e um bem simples, o signal, que não possibilita a passagem de dados. O método de memória compartilhada, basicamente define uma área de memória que pode ser lida/escrita por diferentes processos e para garantir a integridades dos dados, durante o processo de escrita, são usados semáforos. Com estas características do sistema operacional, é possível tirar vantagem do sistema multitarefa na configuração preemptiva para a separação de tarefas que precisam atender as restrições de tempo real, a arquitetura de subsunção que é o sistema reativo propriamente dito, das tarefas que exigem alta carga de processamento, que é o caso do processamento da imagem. Separando assim as tarefas de alta prioridade das de baixa prioridade. Como a câmera, principal fonte de informação, apresenta um tempo de resposta que pode ser classificado como lento diante da maioria das funcionalidades do sistema, ela e todos os módulos de acesso ao hardware também foram inseridos na thread de baixa prioridade. Para a comunicação entre as tarefas foi utilizado o método de memória compartilhada, definindo uma área, ou buffer de comunicação, onde os sensores escrevem as informações prémodeladas do mundo real, que serão utilizadas pelas camadas de comportamento da arquitetura. Basicamente funcionando em uma dinâmica do clássico problema produtor-consumidor. O mesmo método foi adotado para a interação entre a arquitetura de subsunção e o módulo de atuadores. 54

57 Da solução tradicional do problema produtor-consumidor os semáforos puderam ser adotadas algumas simplificações drásticas na solução tradicional do problema produtor-consumidor (praticamente descaraterizando-o de sua essência), que foi a eliminação dos semáforos, pois sua utilização é irrelevante, para garantira a corretude de funcionamento do sistema, devido a características bem particulares do domínio do problema sobre a sequência, integridade, e condições de corrida sobre o buffer de comunicação. A sequência de mensagens não chega a ser uma questão importante pois a dinâmica da arquitetura responde basicamente de forma reativa aos estímulos lançados no buffer de comunicação, portanto o que realmente importa é a resposta rápida do que atualmente está no buffer, e não o que esteve. O fato de responder a todos os estímulos sem perda, é uma restrição não crítica de tempo real, pois é desejável, mas não obrigatória. A integridade da informação é garantida desde que o transporte dos dados ocorra de forma atômica, o que ocorre na transferência de um valor com um tamanho menor ou igual a largura do barramento de dados do processador, que no domínio em questão é de 32 bits. Como na definição do projeto todas as informações foram apresentadas de forma discreta e enumerável, a integridade é garantida desde que o tamanho do conjunto enumerável seja menor do que 232. As condições de corrida também são evitadas a medida que só existe um produtor para cada buffer de comunicação, o que também pode ser implementado sem infringir as definições do projeto. No caso dos sensores a unicidade é garantida de forma inerente à definição do projeto, pois existe somente um módulo responsável pela modelação do sensor. Para o módulo de atuação a unicidade não pode ser garantida em termos de interação entre módulos, pois todas as camadas escrevem de forma independente no módulo de atuadores, porém ela pode ser garantida de forma temporal, obrigando o módulo de atuadores a somente modificar a saída após a execução de todas as camadas, o que é efetivado com a inclusão do tratamento dos atuadores, junto a thread de alta prioridade, onde está a arquitetura de subsunção. A execução principal do programa foi definida de acordo com o diagrama da figura 31, com três threads existentes no sitema, sendo a responsável pela atualização das camadas comportamentais a thread de alta prioridade. A terceira thread é colocada para um controle sobre o software, oferecendo um menu com opções de saída do programa e calibração do mesmo. 55

58 Figura 31: Tarefas principais do sistema. O código fonte a referente a função principal, pode ser observado na figura 32. O programa inicia com a declaração das threads (subsuncao, mediadores e menu), seguido da inicialização dos módulos e das threads, e do escalonamento da thread principal para a fila de preempção de threads. Por fim o programa espera a finalização de todas as thread e finaliza todos os módulos utilizados, desativando os dispositivos periféricos do hardware. 56

59 (...) 14 struct tcb *thsub, *thmed, *thmen; 15 void subsuncao(); 16 void mediadores(); 17 void menu(); int main() { 20 int err, myid; (...) 24 OSMTInit(PREEMPT); err = comunicacao_init(); 27 if (err) LCDPutString("Radio Error\n"); 28 err = visao_init(); 29 if (err) LCDPrintf("Vision Error:%d\n", err); 30 err = navegacao_init(); 31 if (err) LCDPrintf("Motor Error:%d\n", err); 32 err = chute_init(); 33 if (err) LCDPutString("Kicker Error\n"); 34 sensores_init(); 35 procurar_init(); 36 desviar_init(); 37 chutar_init(); (...) 42 thsub = OSSpawn("camadas", subsuncao, 16384, MAX_PRI, 1); 43 thmed = OSSpawn("mediadores", mediadores, , MIN_PRI, 2); 44 thmen = OSSpawn("menu", menu, 8192, MIN_PRI, 3); 45 OSReady(thSub); 46 OSReady(thMed); 47 OSReady(thMen); 48 OSPermit(); 49 OSReschedule(); chute_release(); 52 navegacao_release(); 53 visao_release(); 54 comunicacao_release(); 55 sensores_release(); 56 return 0; 57 } (...) Figura 32: Código da execução principal do programa (main.c). Cada thread é mostrada com seus serviços na figura 33, com o respectivo código na figura 34, evidenciando a separação da execução dos módulos da execução das máquinas de estado referentes aos comportamentos. 57

60 (c) (a) (b) Figura 33: (a) Thread mediadores. (b) Thread Subsuncao. (c) Thread Menu. (...) 72 void mediadores() { 73 while(1) { 74 comunicacao(); 75 visao(); 76 sensores(); 77 } 78 } (...) (...) 59 void subsuncao() { 60 while(1) { 61 procurar(); 62 desviar(); 63 chutar(); 64 carregar(); 65 fazergol() navegacao(); 68 chute(); 69 } 70 } (...) (...) 80 void menu() { 81 while(keyread()!= KEY4) { 82 OSSleep(10); 83 } 84 LCDSetPos(6,0); 85 LCDPrintf("Menu living!!"); 86 OSKill(thMed); 87 OSKill(thSub); 88 OSKill(0); // self 89 } Figura 34: Código das threads (main.c) Programação Modular Para a implementação do sistema foi selecionada a linguagem de programação C [KR78], atualmente todos os softwares projetados dentro da UFSC para a plataforma EyeBot estão nesta linguagem, assim como os exemplos disponibilizados pela página e pelo pacote de instalação. 58

61 Uma decisão conservadora, mas que para o estágio inicial de desenvolvimento contribuiu na forma de suporte, sobre a utilização dos módulos de hardware e das funcionalidades específicas ao sistema operacional do robô, encontrada nos projetos já implementados na UFSC e no mundo que seguem a tendência do uso desta linguagem para a plataforma em questão. A engenharia de software passou por uma série de paradigmas de programação, evoluindo da programação não estruturada até os diversos paradigmas existes hoje em dia, passando pela programação estruturada [Dij69], programação modular [Den73], programação orientada a objetos [Abb83], programação orientada a sujeitos [HO93] e programação orientada a aspectos [KLM97]. O mais alto nível de abstração que a linguagem C consegue expressar, é a programação modular, que em C apresenta a estrutura nas figuras 35 e 36, onde o programa é separado em dois arquivos, o primeiro apresentando a declaração das funçôes e variáveis acessadas por todos, e o segundo declara as funções e variáveis escondidas do resto do projeto, e também implementa as funções do próprio módulo. /* * Modulo responsavel para servir de exemplo para uma estruturacao * comum de todos os modulos respectivos ao sistema. */ #ifndef TEMPLATE_H #define TEMPLATE_H // public: // struct TemplateRegister { int message; } tplreg; enum TemplateMessages { tplmsg1, tplmsg2, tplmsg3 }; int template_init(); void template_release(); void template(); // #endif Figura 35: Um modelo padrão para o header. 59

62 #include "Template.h" // private: // static const int NUM_ONE = 1; static const int NUM_TWO = 2; static int internat; static void do_nothing(void); // // // module functions: // int template_init() { return 0; } // void template_release() { } // void template() { } // static void do_nothing(void) { } // // Figura 36: Um modelo padrão para o corpo do módulo Arquitetura do Software A arquitetura final foi defnida como mostra a figura 37, em um diagrama de desenvolvimento, onde fica claro que cada módulo é responsável por um periférico de hardware, e possui sua caixa de mensagens onde as camadas da arquitetura de subsunção escrevem em lêem respectivamente os sinais de sensores e os comandos para os atuadores. Como o servo da câmera é somente utilizado pelo módulo da visão, fica ele responsável tanto pela câmera como pelo servo motor que regula o ângulo de visão. Sendo este módulo de entrada e saída de informações como o módulo de comunicação que é responsável pelo controle do rádio. 60

63 Figura 37: Arquitetura do software Máquinas de Estado Finito As máquinas de estados segunda as definições da UML permitem diversas funcionalidades como ações na entrada de estados, ações na saída de estados, ações de estado e testes condicionais para a transição de estado e gatilhos de ações. Como um modo de simplificar a implementação o projeto foi definido somente com ações de transição, uma vez que este modelo equivale em expressividade ao modelo da UML. A codificação segundo [Wol01] de uma máquina de estados em uma estrutura switch() e case de um nível é mostrada nas figuras 38 e 39, onde e cada ação declarada como privada dentro do próprio módulo responsável pela execução desta. 61

64 // private: // static void action_dothis(void); static void action_doelse(void); // // // // // #################### MACHINE STATE ACTIONS ##################### // // static void action_dothis(void) { } // static void action_doelse(void) { } // // Figura 38: Modelo das ações de uma máquina de estados. // // // ######################## MACHINE STATE ######################### // // void fms_update(void) { static enum fmsstate { FIRST, SECOND } state = FIRST; switch (state) { case FIRST: // if (condition) { // state = NEXT_ONE; // action_some(); // break; } break; case SECOND: if (something) { state = SECOND; action_dothis(); break; } break; default: state = FIRST; } } Figura 39: Modelo de uma máquina de estados. 62

65 4.2 Camadas de Subsunção O comportamento Carregar Bola possui um sistema realimentado que tem por finalidade perseguir a bola, ele foi implementado de acordo com a figura 40, onde a função módulo, que é uma função cara dentro de sistemas embarcados, pode ser substituída por um desvio condicional simples, que é executado em 2 ciclos de clock, enquanto a função modular de um valor fora da base 2 precisa de uma divisão em software para ser executada. (...) 33 static void action_perseguir() { 34 float x, angulo; 35 x = visreg.xbola - 30; 36 if (x <= -5 && x >= 5) { 37 navreg.navwspeed = 0; 38 } 39 else { 40 angulo = atan(visreg.ybola/x); 41 if (angulo > 0) 42 angulo = M_PI/2 - angulo; 43 else 44 angulo = -(M_PI/2 + angulo); 45 navreg.message = navdirect; 46 navreg.navwspeed = -angulo; 47 } 48 LCDSetPos(3,9); 49 LCDPrintf("%2.3f", navreg.navwspeed); 50 navreg.navvspeed = 0.1; 51 navreg.message = navdirect; 52 } (...) Figura 40: Algoritmo de realimentação para perseguir a bola O valor de erro da função de realimentação ficou da seguinte forma: Correcao angular Angulo Figura 41: Erro angular da bola aplicado na correção 63

66 4.3 Módulos Visão Para a constante do fator de correção de profundidade necessário no algoritmo de visão foi utilizada a tabela da figura 42, produzindo um fator com o gráfico mostrado na figura 43a. A saturação ao final do gráfico se deve a distâncias grandes da bola, pois a continuação da função permitiria pontos de 1 pixel da cor laranja a serem identificados como bola, e que na realidade são ruídos do meio de conversão. A figura 43b mostra a quantidade de pixels necessários para a identificação da bola de acordo com sua altura, representada pelo eixo das ordenas da matriz de um frame da câmera. (...) 9 static float yfact[82] = 10 { , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , }; (...) , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Figura 42: Matriz de correção usada no software (visao.c). (a) (b) Figura 43: (a) Fator de correção aplicado ao tamanho do objeto. (b) Resultado da correção para um objeto de 2cm. 64

67 A figura 44 apresenta o código de conversão do espaço de cores RGB para a coordenada hue do espaço de cores HSV. É a função de maior consumo de processamento, devido a sua repetição de 4800 vezes devido ao tamanho de um frame de video da câmera. Com esta estrutura o algoritmo de conversão executa em cerca de 100ms, levando um terço do tempo necessário para a aquisição de um novo frame, evidenciando sua eficiência e inclusive mostrando a capacidade que o sistema ainda possui para o processamento de mais código. (...) 239 #define MIN(a,b) (a<b?a:b) 240 #define MAX(a,b) (a>b?a:b) (...) 244 int RGBtoHue(BYTE r, BYTE g, BYTE b) 245 { 246 int hue, delta, max, min; max = MAX(r, MAX(g,b)); 249 min = MIN(r, MIN(g,b)); 250 delta = max - min; if (2 * delta <= max) 253 return NO_HUE; 254 if (r == max) hue = 42 + (42*(g-b)) / delta; /* 1*42 */ 255 else if (g == max) hue = (42*(b-r)) / delta; /* 3*42 */ 256 else /*(b == max)*/ hue = (42*(r-g)) / delta; /* 5*42 */ 257 /* now: hue is in range [0..252] */ 258 return hue; 259 } (...) Figura 44: Código da conversão de RGB para Hue (visao.c) Comunicação Para a comunicação a linha EyeBot possui uma unidade de comunicação sem fio para uma conversação entre robôs, permitindo o estabelecimento de um plano, recepção das intenções ou comandos de outros robôs ou uma seqüência de instruções vindas de estações de trabalho controladas por humanos. O sistema operacional gerencia uma rede virtual tipo token ring com aspectos de tolerância a falhas. A rede, denominada EyeNet, possibilita um numero ilimitado de Robôs conectados e uma estação de trabalho opcional. A comunicação é realizada em 8 bits e todos os pacotes possuem um checksum para detecção de erros, porém é não confiável pois não oferece mecanismos de retransmissão de pacotes perdidos. A garantia de envio deve ser gerenciada em uma camada mais acima. O sistema operacional oferece as funções RADIOInit() e RADIOTerm() para ligar/desligar o módulo de rádio, RADIOSend(), RADIOCheck() e RADIORecv() para o envio/recebimento de 65

68 pacotes. Como o modulo de rádio funciona conectado em uma porta serial, o sistema oferece outras 3 funções para configurações de E/S, RADIOGetioctl(), RADIOSetIoctl() e RADIOGetStatus() Sensores A família SoccerBot é equipada com 3 módulos PSD (Position Sensitive Detection) para medição de distâncias e uma câmera colorida. Os sensores de distância são dispositivos infravermelhos fabricados pela empresa Sharp, sob código de GP2D02, como solução de baixo custo e que operam somente à distâncias entre 10 e 50cm e segundo a vários motivos podem gerar falsas medições em alguns momentos. Sua curva característica pode ser obtido da folha de dados do fabricante e pode ser visto na figura 45. Figura 45: Fator de erro dos sensores de distância. A conversão dos valores analógicos do sensor de distância para os valores discretos usados dentro das camadas é mostrada na figura 46, onde os sensores laterais possuem os valores de limiar nas linhas 7 e 8 do código, e o sensor frontal, por estar montado mais dentro do corpo do robô possui valores diferenciados nas linhas 9 e

69 (...) 7 static const int LIMIAR_ALTO = 120; 8 static const int LIMIAR_BAIXO = 90; 9 static const int LIMIAR_ALTOFRONTAL = 150; 10 static const int LIMIAR_BAIXOFRONTAL = 120; (...) 34 void sensores() { 35 int dist; if (!PSDCheck() ) 38 return; // Sensor Frontal 41 dist = PSDGetRaw(psd_front); 42 if ( dist > LIMIAR_ALTOFRONTAL ) senreg.sensfrontal = slonge; 43 else if(dist>limiar_baixofrontal)senreg.sensfrontal = smedio; 44 else senreg.sensfrontal = sperto; // Sensor Direita 47 dist = PSDGetRaw(psd_left); 48 if ( dist > LIMIAR_ALTO ) senreg.sensesquerda = slonge; 49 else if ( dist > LIMIAR_BAIXO ) senreg.sensesquerda = smedio; 50 else senreg.sensesquerda = sperto; // Sensor Esquerda 53 dist = PSDGetRaw(psd_right); 54 if ( dist > LIMIAR_ALTO ) senreg.sensdireita = slonge; 55 else if ( dist > LIMIAR_BAIXO ) senreg.sensdireita = smedio; 56 else senreg.sensdireita = sperto; 57 } Figura 46: Conversação do estado dos sensores feita pelo módulo de sensores (sensores.c) Navegação O SoccerBot possui dois motores DC controlados pelos módulos de PWM do microcontrolador, cada motor possui um encoder conectado conectado ao seu eixo permitindo uma realimentação de velocidade e um controle PI pelo sistema operacional. Dessa forma a velocidade pode ser controlada de forma mais precisa, porém como as duas rodas não possuem as mesmas características não é possível garantir um controle de posição do robô confiando unicamente na informação advinda destes sensores. Os parâmetros de P e I, dos controladores PI, foram obtidos de forma deliberativa, segundo a noção qualitativa da influência de cada parâmetro, que o método de ajuste pela resposta a um degrau juntamente com técnicas para calibração de sistemas de controle PID em campo [Oga98] oferece. Para o controle dos motores DC, o RoBIOS oferece as funções MotorInit() e MotorRelease(), para inicializar e desligar respectivamente os controladores, e MotorDrive() para alterar a velocidade e direção dos motores. 67

70 A plataforma possui mais 4 saídas para controle de servo motores, das quais uma é utilizada para controle do mecanismo de chute instalado na parte frontal do robô e outro no posicionamento da câmera, que possui uma rotação lateral imitando o movimento de uma cabeça para os lados. Para controle dos servo motores, o sistema operacional possui as funções SERVOInit() e SERVORelease() para ligar/desligar respectivamente os módulos de controle, e a função SERVOSet() que ajusta o ângulo de posicionamento do servo em questão. 68

71 (...) 6 static const int CTR_P_ESQ = 6; 7 static const int CTR_I_ESQ = 0.45; 8 static const int CTR_P_DIR = 6; 9 static const int CTR_I_DIR = 0.1; static const int PARADO = 0; 12 static const int BAIXA = 3; 13 static const int ALTA = 5; 14 static const int MAX = 7; (...) 37 VWStartControl(vw,6,0.45,6,0.1); (...) (...) 68 switch(lastmsg) { 69 case navparar: 70 s.v = 0.0; s.w = 0; 71 VWSetSpeed(vw,s.v,s.w); 72 break; 73 case navdirect: 74 s.v = navreg.navvspeed; 75 s.w = navreg.navwspeed; 76 VWSetSpeed(vw, s.v, s.w); 77 break; 78 case navfrentelento: 79 s.v = 0.3; s.w = 0; 80 VWSetSpeed(vw, s.v, s.w); 81 break; 82 case navfrente: 83 s.v = 0.4; s.w = 0; 84 VWSetSpeed(vw,s.v,s.w); 85 break; 86 case navfrenterapido: 87 s.v = 0.6; s.w = 0; 88 VWSetSpeed(vw, s.v, s.w); 89 break; 90 case navreh: 91 s.v = -0.4; s.w = 0; 92 VWSetSpeed(vw,s.v,s.w); 93 break; 94 case navgir_horlento: 95 s.v = 0.0; s.w = -0.5; 96 VWSetSpeed(vw,s.v,s.w); 97 break; 98 case navgir_hor: 99 s.v = 0.0; s.w = -0.7; 100 VWSetSpeed(vw,s.v,s.w); 101 break; 102 case navgir_ahorlento: 103 s.v = 0.0; s.w = 0.5; 104 VWSetSpeed(vw,s.v,s.w); 105 case navgir_ahor: 106 s.v = 0.0; s.w = 0.7; 107 VWSetSpeed(vw,s.v,s.w); 108 break; 109 default: 110 s.v = 0.0; s.w = 0; 111 VWSetSpeed(vw,s.v,s.w); 112 break; 113 } (...) Figura 47: Conversão das mensagens de navegação para os motores (navegação.c). 69

72 4.3.5.Controle Remoto Antes do desenvolvimento dos comportamentos foram realizados testes sobre os módulos de hardware oferecidos pelo robô, afim de garantir o funcionamento, enfrentar eventuais dificuldades de utilização antes do desenvolvimento dos comportamentos e levantar as condições e limitações reais do periférico em questão para o desenvolvimento de um software sintonizado com o hardware. O primeiro componente de hardware testado, foi o módulo de rádio, a fim de testar a comunicação entre os robôs e entre um robô e o computador. Para o teste foram utilizados dois programas exemplos disponibilizados pelo pacote do próprio EyeBot, são eles eye2pc e eye2eye, por serem programas simples a análise de como utilizar o rádio foi bastante simples. O primeiro programa faz uma comunicação entre um SoccerRobot e um microcomputador onde se estabelece uma repetição infinita em cada um dos códigos onde a estação espera por uma mensagem, que é somente um número, soma ela em uma unidade e reenvia para quem mandou, enquanto que o robô faz o caminho inverso, primeiro envia a mensagem, espera por uma resposta e soma um para reenvio. Após o teste da comunicação via rádio, foi iniciado o desenvolvimento do controle remoto do robô, para a implementação foi selecionada a ferramenta RAD (Rapid Application Development) C++ Builder da Borland devido ao fácil acesso de seus componentes visuais na construção da interface gráfica. O maior problema de utilizar a IDE da Borland é que as bibliotecas reconhecidas pelo seu compilador possuem um formato diferente das bibliotecas geradas pelo GCC, que é o cross-compiler (para o processador embarcado do EyeBot M68332 da Motorola), utilizado pela Universidade de UWA no desenvolvimento do RoBIOS e as bibliotecas para criação de aplicações usando as funcionalidade do SO. A solução foi a conversão de bibliotecas sugerida por Norlander [Nor06], onde é realizada a criação de uma biblioteca dinâmica (dll) no formato reconhecido pelas aplicações de Windows, e conseqüentemente utilizável pelo o compilador de C++ da Borland. O controle desenvolvido é mostrado na figura 48, que possui basicamnte 5 campos com funções distintas. Em sua parte superior é configurada a porta serial em que a antena do host está conectada, informada em vermelho quando a conexão não pode ser estabelecida e o periférico não está pronto, e com fundo branco quando a comunicação pode ser efetuada. Logo ao lado existem duas indicações de transmissão e recepção de pacotes no módulo de antena. 70

73 Os comando de controle fornecem as opções de iniciar e finalizar o jogo através do botão Game e habilitar e desabilitar o modo de funcionamento remoto através do botão Remote. Este modo habilida os botões a baixo dele que fornecem as mensagens responsáveis pelo controle a distância do robô, com comando simples de frente, ré, giro para direita, gira para esquerda, e chute. Alguns comandos de técnico também estão disponíveis, como mandar se movimentar para o canto esquerdo da área (posição defensiva 1) através do botão LFT, e para o canto direito da área (posição defensiva 2) através do botão RGT. O botão DEF avisa aos robôs para tomar a posição defensiva dentro do campo. A direita existem três botôes responsãveis pelo selecionamento de cada robô, e o botâo com uma seta abre o menu da figura 48b, ativando o modo promiscuo, onde todas as mensagens entre robôs e entre robô e central são impressos. (a) (b) Figura 48: (a) Controle Remoto do SoccerBot. (b) Janela estendida para observação da comunicação de rádio. 71