Embed Size (px)
Citation preview
Dênis Schneider Strassmann
DESENVOLVIMENTO DE UMA ARQUITETURA
BASEADA EM SUBSUNÇÃO PARA UM TIME DE
FUTEBOL DE ROBÔS
Florianópolis - SC
Agosto de 2006
Dênis Schneider Strassmann
DESENVOLVIMENTO DE UMA ARQUITETURA
BASEADA EM SUBSUNÇÃO PARA UM TIME DE
FUTEBOL DE ROBÔS
Monografia apresentada ao programa de
Bacharelado em Ciências da Computação da
Universidade Federal de Santa Catarina como
requisito parcial para a obtenção do grau
Bacharel em Ciências da Computação.
ORIENTADOR:
Prof. Mauro Roisenberg
UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO
Florianópolis -SC
Julho de 2006
“Ciência da computação tem tanto a ver com o computador como a Astronomia com o
telescópio, a Biologia com o microscópio, ou a Química com os tubos de ensaio. A Ciência não
estuda ferramentas, mas o que fazemos e o que descobrimos com elas."
Edsger Dijkstra
RESUMO
Este trabalho de conclusão de curso aborda uma estratégia reativa baseada na arquitetura de
subsunção na implementação de uma equipe de futebol de robôs, apresentando desde o projeto
até sua implementação. O projeto mostra os algoritmos de controle, visão artificial, e
comunicação utilizados juntamente com a definição dos comportamentos, através de autômatos
finitos, relevantes em uma partida de futebol. A implementação relata as questões tecnológicas
que o projeto se submeteu, assim como suas dificuldades e seus resultados.
ABSTRACT
This B. Sc. thesis presents an reactive strategy based on the architecture of subsumption in the
implementation of a team of robot soccer, presenting design and implementation. The designt
shows the control system algorithms, artificial vision, and communication used in definition of
behaviors, through finite automatas, relevant in a soccer game. The implementation reliefs the
technological tricks that the project is submitted, as well as its difficulties and its results.
Lista de Figuras
Figura 1: O Desafio Grand Challenge. (a) Read Team em 2004. (b) Logotipo de 2007
Figura 2: Robôs exploradores. (a) Sojourner em 1996. (b) Spirit e Opportunity em 2004
Figura 3: Perspectiva futura de sistemas computacionais.
Figura 4: Dentro do mundo de sistemas embutidos, 6% pertence a robótica.
Figura 5: Arquitetura robótica tradicional.
Figura 6: Arquitetura robótica de subsunção.
Figura 7: Robô da Honda no torneio da RoboCup 2003.
Figura 8: Logo da RoboCup.
Figura 9: Infraestrutura RoboCup 2004.
Figura 10: Logo da FIRA.
Figura 11: Jornada de Robótica Inteligente em Campo Grande - MS, 2006.
Figura 12: EyeBots projetados pela UWA.
Figura 13: Arquitetura Hibrida adotada.
Figura 14: Diagrama final da arquitetura de controle.
Figura 15: Arquitetura de subsunção dos jogadores.
Figura 16: Automato da camada Procurar
Figura 17: Automato da camada desviar.
Figura 18: Autômato da camada Carregar.
Figura 19: (a) Diagrama do sistema realimentado. (b) Coordenadas da bola em um frame.
Figura 20: Função de correção para perseguir a bola.
Figura 21: Autômato da camada Chutar.
Figura 22: Autômato da camada Fazer Gol.
Figura 23: Automato responsável pela comunicação entre os robôs.
Figura 24: Máquina de estados da comunicação do módulo externo.
Figura 25: Cone de cores do espaço HSV
Figura 26: Cubo de cores do espaço RGB.
Figura 27: Conversão de RGB para Hue.
Figura 28: (a) Fluxograma do algoritmo de procura em uma linha. (b) Função de avaliação da
concentração de cor em uma linha.
Figura 29: Curva de relação entre distância e número da linha.
Figura 30: Diagrama com a otimização no cálculo da média e o refinamento de novas buscas.
Figura 31: Tarefas principais do sistema
Figura 32: Código da execução principal do programa (main.c).
Figura 33: (a) Thread mediadores. (b) Thread Subsuncao. (c) Thread Menu.
Figura 34: Código das threads (main.c).
Figura 35: Um modelo padrão para o header.
Figura 36: Um modelo padrão para o \u201ccorpo\u201d do módulo.
Figura 37: Arquitetura do software
Figura 38: Modelo das ações de uma máquina de estados.
Figura 39: Modelo de uma máquina de estados.
Figura 40: Algoritmo de realimentação para perseguir a bola
Figura 41: Erro angular da bola aplicado na correção
Figura 42: (a) Fator de correção aplicado ao tamanho do objeto. (b) Resultado da correção para
um objeto de 2cm.
Figura 43: Matriz de correção usada no software (visao.c).
Figura 44: Código da conversão de RGB para Hue (visao.c).
Figura 45: Fator de erro dos sensores de distância.
Figura 46: Conversação do estado dos sensores feita pelo módulo de sensores (sensores.c).
Figura 47: Conversão das mensagens de navegação para os motores (navegação.c)
Figura 48: (a) Controle Remoto do SoccerBot. (b) Janela estendida para observação da
comunicação de rádio.
Sumário
Resumo
Abstract
Lista de Figuras
1. Introdução....................................................................................................................... 9
1.1 Objetivos............................................................................................................. 9
1.2 Motivação............................................................................................................ 10
1.3 Organização do Trabalho.................................................................................... 13
2. Contextualização............................................................................................................ 14
2.1 Robótica Móvel................................................................................................... 14
2.2 Sistemas Baseados em Comportamentos............................................................ 18
2.3 Futebol de Robôs................................................................................................ 20
2.3.1.RoboCUP............................................................................................ 22
2.3.2.FIRA................................................................................................... 25
2.3.3.No Brasil............................................................................................ 27
2.4 EyeBot............................................................................................................... 28
2.5 UFSC-Team....................................................................................................... 30
3. Projeto............................................................................................................................ 32
3.1 Arquitetura Hibrida............................................................................................ 32
3.2 Comportamentos................................................................................................ 35
3.2.1.Procurar.............................................................................................. 35
3.2.2.Desviar............................................................................................... 37
3.2.3.Carregar............................................................................................. 38
3.2.4.Chutar................................................................................................ 40
3.2.5.Fazer Gol........................................................................................... 41
3.3 Modelagem de Dados........................................................................................ 41
3.3.1.Sensores............................................................................................. 42
3.3.2.Atuadores.......................................................................................... 42
3.3.3.Comunicação..................................................................................... 43
3.3.4.Controle Externo............................................................................... 45
3.3.5.Tratamento de Imagem..................................................................... 46
4. Implementação................................................................................................................ 52
4.1 Aspectos Tecnológicos........................................................................................ 52
4.1.1.Questões do Sistema Embarcado........................................................ 52
4.1.2.Programação Modular......................................................................... 58
4.1.3.Arquitetura do Software...................................................................... 60
4.1.4.Máquinas de Estado Finito.................................................................. 61
4.2 Camadas de Subsunção....................................................................................... 63
4.3 Módulos.............................................................................................................. 64
4.3.1.Visão................................................................................................... 64
4.3.2.Comunicação...................................................................................... 65
4.3.3.Sensores............................................................................................. 66
4.3.4.Navegação.......................................................................................... 67
4.3.5.Controle Remoto................................................................................ 70
5. Conclusão....................................................................................................................... 72
Referências........................................................................................................................... 74
1 Introdução
Este trabalho visa desenvolver uma arquitetura baseada na arquitetura de subsunção como
estratégia de controle de um time autônomo de futebol de robôs, implementado sobre a
plataforma Eyebot, aproveitando todas suas características, como câmera rádio, sensores e
atuadores. A arquitetura passará por testes de avaliação e por uma prova de participação de uma
campeonato de futebol de robôs.
1.1 Objetivos
A importância de estudos nessa área se deve à necessidade de substituição de tarefas humanas
realizadas em ambientes de risco ou de difícil acesso, como pesquisas dentro de vulcões,
manutenção de turbinas hidrelétricas, explorações interplanetárias, inclusive em testes de novas
tecnologias. Muito mais do que ambientes que necessitam de simples regras baseadas em
percepção e ação, são ambientes que precisam de planejamento de ações, e classificação dos
dados a partir de uma avalanche de informações vindas de diversos tipos de sensores. E para o
sucesso de tais tarefas é imprescindível o experimento e validação de técnicas de
reconhecimento, planejamento e controle, assim como o eventual desenvolvimento de novas
técnicas, em plataformas reais interagindo com ambientes reais.
Seguindo esta necessidade uma arquitetura de nível reativo é estudada, a arquitetura de
9
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
O primeiro evento ocorreu em março de 2004 com a participação de 15 equipes, e nenhuma
conseguiu percorrer sequer 0,5 % (meio por cento) do trajeto exigido. O melhor desempenho
foi alcançado pela equipe da Universidade Carnegie Mellon com 11 km de corrida. O que,
apesar da grande quantidade de pesquisas, mostra que ainda há um longo caminho a ser traçado
no desenvolvimento de veículos totalmente autônomos. A figura 1 mostra o carro automatizado
de uma das equipes e o desafio lançado para 2007, que é percorrer parte do percurso em área
urbanizada.
(a)
(b)Figura 1: O Desafio Grand Challenge. (a) Read Team em 2004. (b) Logotipo de 2007
Outro desafio, mas não a caráter de competição, é a exploração robótica de Marte. Atualmente
os jipes Spirit e Opportunity, figura 2, estão coletando dados fundamentais para pesquisas sobre
o planeta vermelho. Apesar dos veículos não precisarem ser totalmente autônomos e nem se
movimentar numa velocidade tão alta como os veículos do desafio da DARPA, eles apresentam
uma outra dificuldade a ser vencida, estão a cerca de 360 milhões de km da Terra, o que
inviabiliza qualquer tipo de controle remoto em tempo real. Para superar este obstáculo uma
equipe, no laboratório de propulsão a jato na NASA, planeja cautelosamente todo movimento
executado no planeta vizinho, e envia um código calculado especificamente para uma manobra.
Mas isso não ausenta os robôs de autonomia, eles precisam continuar a executar tarefas de
sobrevivência em casos de risco em que a equipe não pode responder a tempo. Aqui novamente
é possível perceber a quantidade de pesquisa ainda necessária nesse ramo, pois apenas 9 das 33
missões à Marte, cerca de 27%, obtiveram sucesso [App04].
11
(a)
(b)Figura 2: Robôs exploradores. (a) Sojourner em 1996. (b) Spirit e Opportunity em 2004
Além das aplicações práticas citadas acima, a área de sistemas embarcados que possui
aplicabilidade direta dentro da robótica, também possui desafios bastante motivadores pela sua
grande área de atuação e características, como restrições de tempo real, tamanho de código,
corretude, robustez e eficiência de algoritmos, que geram temas bastante atuais para pesquisa e
desenvolvimento.
Sistemas computacionais embarcados tendem cada vez mais para o mundo da miniaturização e
integração como pode ser visto na figura 3, que é um resumo histórico sobre a evolução dos
computadores e sua influência tecnológica.
Figura 3: Perspectiva futura de sistemas computacionais.
É uma área que apresenta grandes perspectivas de crescimento e precisa ser estudada para que o
desenvolvimento ocorrera sobre bases teóricas bem formalizadas e se consiga um melhor
12
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
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
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
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
● 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
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
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
● 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
(DeepBlue 1997) e gamão [Tes94], e são competitivos em muitos outros jogos.
A idéia do futebol robótico foi mencionada pela primeira vez pelo professor Alan Mackworth
da Universidade British Columbia, Canadá. Mas, independentemente dele, um grupo de
pesquisadores japoneses organizaram um workshop sobre os grandes desafios da Inteligência
Artificial em outubro de 1992, em Tóquio. Este evento desencadeou uma série de discussões
sobre como utilizar o jogo de futebol para fomentar a pesquisa em ciência e a tecnologia. Foi
feita então uma investigação sobre a viabilidade tecnológica, financeira e o impacto social.
Juntamente, foram desenvolvidos regras e protótipos de robôs-jogadores e simuladores. Como
resultado destes estudos, concluíram que o projeto era possível e desejável. Assim, em junho de
1993, Minoru Asada, Yasuo Kuniyoshi e Hiroaki Kitano decidiram iniciar uma competição,
primeiramente com o nome de Robot J-League (O "J" deve-se a japanese). Esta acabou se
transformando na primeira liga profissional de futebol robótico do mundo. Logo a seguir,
devido a pedidos de pesquisadores de todo mundo também interessados, mudou-se o nome da
liga e do projeto como um todo para Robot World Cup Initiative, ou simplesmente RoboCup.
O interesse ao redor do tema atingiu proporções mundias, a ponto de serem criadas federações
para organizarem workshops e outros eventos de cunho científico onde são apresentadas as
inovações e propostas de cada equipe bem como campeonatos reais - e por vez divertidos -
onde pode-se comprovar na prática as melhores estratégias e as táticas usadas pelas equipes.
Existem atualmente duas federações internacionais envolvidas em pesquisas com futebol
robótico; a Robot World Cup Soccer Games and Conferences (RoboCup) e a Federation of
International Robot-soccer Association (FIRA). Cada uma delas possui seus próprios
regulamentos e categorias, sendo a mais notável diferença entre estas duas federações o
enfoque. Enquanto a RoboCup está mais empenhada em fomentar pesquisas na área de IA,
dando grande ênfase às inovações e ao aspecto teórico, a FIRA está mais voltada à robótica em
si e nas tecnologias de construção dos robôs. São abordagens diferentes com importantes
influências nos resultados.
Há também a participação de grandes empresas do setor de tecnologia. Elas foram atraídas pelo
enorme leque de oportunidades que pesquisas como estas representam para o futuro e hoje são
patrocinadoras destes eventos. Na figura 7 pode ser visto uma foto do robô humanóide FirsStep
da Honda International Technical School durante o evento da RoboCup em 2003.
21
Figura 7: Robô da Honda no torneio da RoboCup 2003.
Talvez a maior vantagem do futebol robótico seja a capacidade de integrar conceitos e
tecnologias como: inteligência artificial, sistemas de tempo-real, visão computacional, sistemas
multi-agentes colaborativos, fusão sensorial, eletrônica, mecânica fina, robótica móvel
autônoma. E entre algumas aplicações que os estudos nesta área proporcionam estão:
● Semáforos inteligentes que se comunicam entre si para desobstruir regiões inteiras de
uma cidade e não apenas cruzamentos [Nun02].
● Veículos autônomos para a exploração de ambientes perigosos e desconhecidos, como
robôs de exploração interplanetária [Zlo02].
● Transporte viário totalmente automatizado, que reconhece e consegue utilizar a malha
rodoviária existente atualmente.
2.3.1 RoboCup
Figura 8: Logo da RoboCup.
A RoboCup, figura 8, é uma iniciativa científica internacional que atualmente envolve mais de
300 grupos de pesquisa ativos em todo o mundo, e como a própria federação cita: “A RoboCup
é uma iniciativa internacional de pesquisa e educação. Ela encoraja pesquisadores de
Inteligência Artificial e Robótica Inteligente oferecendo um problema padrão onde uma grande
22
gama de tecnologias podem ser integradas e exploradas” [Rob06]. O futebol foi escolhido por
causa da grande quantidade de desafios que um robô precisa enfrentar para jogar efetivamente
uma partida. Por exemplo, ele precisa reagir em tempo real a um ambiente altamente dinâmico,
cooperar com os companheiros, distinguir os adversários e assim por diante. [Pag04]
Talvez a mais audaciosa das metas até então já estabelecidas por desafios internacionais
envolvendo pesquisa e desenvolvimento de tecnologias, a RoboCup formulou o objetivo de
“desenvolver até 2050 um time de robôs humanóides totalmente autônomos capazes de vencer
o time campeão mundial de futebol pelas regras oficias da FIFA” [Kit99].
Mesmo que o objetivo não seja alcançado, a iniciativa da RoboCup já conseguiu produzir o
resultado de criar interesse e disseminar conhecimento sobre Inteligência Artificial e Robótica,
crescendo de um pequeno encontro de poucos cientistas interessados para um evento sobre
robótica de escala mundial. De fato a RoboCup evoluiu, e a partida de futebol é somente uma
das atividades, que agora abrangem um campeonato mundial com diversas categorias;
conferências técnicas apresentadas durante o evento; desafios inteligentes (onde desafios são
projetados afim de encorajar a comunidade RoboCup à permanecer ativa em diferentes áreas de
pesquisa); programas educacionais para estudantes do primeiro e segundo ano ou graduandos; e
desenvolimento de toda uma infra-estrutura (por exemplo, todo ano, a arena de treinamento
para a liga de Resgate é construída no país cede do evento da RoboCup, como uma facilidade
aberta aos pesquisadores da área de robótica de resgate). A figura 9 mostra um pouco da arena
construída para o evento de 2004.
Em sua última edição [Rob06], realizada em Bremen na Alemanha, o evento cobriu três
competições distintas, a copa robótica de resgate (RoboCupRescue), a copa júnior de robôs
(RoboCupJunior), e a copa de futebol de robôs (RoboCupSoccer). Dentro do terceiro domínio
as competições são divididas nas seguintes ligas ou categorias:
● Simulation league: Tem o propósito de oferecer um ambiente para o desenvolvimento
de arquiteturas e algoritmos avançadas de controle explorando áreas como coordenação
de multi-agentes e estratégias de alto nível sem se preocupar com limitações e evolução
de hardware.
● Small Size league: Permite um enfoco no controle centralizado de vários robôs
pequenos, os times frequentemente optam pelo uso de uma câmera global e
processamento em um computador externo, direcionando as pesquisas para visão
artificial, dinâmica dos times e cooperação. Os robôs apresentam uma certa
23
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 2004.
24
A plataforma EyeBot se encaixa na categoria de pequeno porte (small size league),
tecnicamente chamada de F180 pois seu tamanho não pode ultrapassar um cilindro de 18 cm de
diâmetro e 22cm de altura. A categoria pode tanto usar câmera embarcada como global, sendo
no segundo caso a altura máxima permitida para o robô de 15cm. Cada time é livre para
desenvolver seus próprios robôs, permitindo inclusive adaptações específicas para o goleiro, o
que permite pesquisas mais avançadas em outros aspectos ligados às engenharias, além da
programação.
Atualmente a categoria F180 joga em um campo de 3,4m de largura e 4,9m de comprimento e
uma abertura do gol de 70cm. Como a categoria pode jogar tanto com visão local ou global, um
gol é pintado de amarelo e outro de azul. A bola é um bola comum de golfe na cor laranja. A
partida é jogada em dois tempos de 10min com um intervalo de 5min. Durante o jogo não é
permitido nenhuma interação dos programadores, os robôs devem ter total autonomia até o fim
de cada tempo, sendo permitido mudanças somente durante o intervalo. Cada time pode ter
entre 1 a 5 jogadores. Existem regras para faltas, pênaltis, cobranças, lateral, substituição de
jogadores e muitas outras que podem ser vistas no página da organização [Rob04].
2.3.2 FIRA
Figura 10: Logo da FIRA.
A FIRA [Fir06], figura 10, surgiu a partir de um comitê internacional formado sob a liderança
do professor JongHwan Kim com o objetivo de promover o Micro-Robot World Cup Soccer
Tournament (MiroSot). Assim, um encontro foi marcado e em 29 de julho de 1996 regras e
regulamentos foram criados. Trinta times de treze países aceitaram o desafio. A primeira
MiroSot'96 aconteceu em KAIST (Korea Advanced Institute of Science and Technology), entre
9 e 12 de novembro do mesmo ano. Esta primeira edição contou com a participação de vinte e
três equipes de dez países diferentes. A equipe Newton, do Laboratório de Pesquisas Newton
foi a vencedora, seguido por SOTY da Coréia. A equipe do CMU foi a campeã na categoria S-
25
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
hardware. Pesquisas podem ser feitas sem grandes custos envolvidos.
2.3.3 No Brasil
No Brasil as competições acontecem todo ano dentro da Jornada de Robótica Inteligente (JRI)
que promove as competições de robótica e o Encontro de Robótica Inteligente (EnRI). As
Competições de Robótica reúnem três eventos distintos: A Competição IEEE Brasileira de
Robôs, a RoboCup Brasil, e a RoboCupJunior Brasil. A Competição IEEE Brasileira de Robôs,
atualmente em sua IV edição é patrocinada pelo IEEE Latin American Robotics Council. Seu
objetivo é promover o desenvolvimento científico e tecnológicos nas áreas de Robôs
Autônomos e Mecatrônica, na América Latina. Estas competições possuem grande parte dos
desafios encontrados pela robótica móvel do mundo real, tais como, navegação em ambientes
dinâmicos, exploração de ambiente, realização de procedimentos de contingência em ambiente
perigosos ou insalubres, monitoramento ambiental. Esta competição promove torneios nas
categorias Lego, Very Small Robot Soccer e Livre.
A RoboCup Brasil atualmente em sua terceira edição, é um projeto conjunto internacional para
promover a IA, robótica e campos relacionados. Trata-se de uma tentativa de estimular a IA e a
robótica inteligente através do oferecimento de problemas padrão onde diversas tecnologias
podem ser empregadas. As categorias que a RoboCup Brasil possui competições são a F-180,
Simulação-2D, Simulação-3D, Resgate Simulado e Robôs Virtuais.
A RoboCupJunior Brasil atualmente em usa primeira edição, é uma iniciativa orientada à
educação que tem por objetivo introduzir a robótica aos jovens estudantes de ensino
fundamental, médio e técnico. Mais do que o desenvolvimento tecnológico, o foco neste liga é a
educação e o estímulo ao surgimento de futuros pesquisadores, promovendo competições nas
modalidades Dança e Resgate.
A Jornada de Robótica Inteligente de 2006 ocorreu em Campo Grande, Mato Grosso do Sul, no
Campus da Universidade Católica Dom Bosco (UCDB) onde a UFSC competiu nas categorias
de Lego, dentro da Competição IEEE Brasileira de Robôs, onde conseguiu o primeiro lugar no
desafio inteligente, e na categoria F-180, dentro da RoboCup, ficando em segundo lugar. A
figura 11 mostra a arena montada para a competição da categoria Very Small na Jornada de
27
Robótica Inteligente de 2006.
Figura 11: Jornada de Robótica Inteligente em Campo Grande - MS, 2006.
2.4 Robôs Eyebot
A Universidade Western Austrália desenvolve vários modelos de robôs, figura 12, todos com a
filosofia de poderem operar de forma totalmente independente, existem dois modelos com
rodas, o SoccerBot e o Omni, dois modelos bípedes, o Android e o Walker, e um terceiro
modelo hexapode. A UFSC adquiriu três unidades do SoccerBot, o qual foi projetado para
satisfazer as regras da liga de pequeno porte (small-size league) da competição mundial de
futebol de robôs RoboCup.
Figura 12: EyeBots projetados pela UWA.
28
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
e branco IPDither(), detecção de arestas através do operador de Laplace, IPLaplace(), e
operador de Sobel, IPSobel(), e um subtrator de imagens IPDiffer(). Constituindo um kit
rudimentar para visão computacional e reconhecimento de padrões.
Por ser um sistema operacional voltado para a robótica móvel, ele também possui facilidades
para processamento de imagem, incluindo alguns dos algoritmos mais utilizados em sistemas de
visão artificial. Muitos sistemas móveis autônomos utilizam uma câmera para sua navegação,
desviando assim de obstáculos, e/ou definindo trajetórias a serem realizadas.
As funções de processamento de imagem, que o RoBIOS possui, utilizam como entrada
imagens em escala de cinza, enquanto que a câmera fornece uma imagem colorida. Para esta
conversão de cores o sistema oferece a função IPColor2Grey() que realiza a operação
matemática “(R+2*G+B)/4” em cada pixel de entrada, para produzir a imagem em cinza.
2.5 UFSC-Team
O Projeto UFSC-Team teve início no final do ano de 97, apenas um ano após a realização do
primeiro evento mundial de futebol robótico realizado em 1996. Inicialmente contando com a
participação de um aluno de doutorado e um professor, evoluiu para conter também alunos de
iniciação científica e mestrado. Tornou-se então um importante campo de estudos para a
validação de pesquisas principalmente para interessados em Inteligência Artificial. A primeira e
principal meta deste projeto era desenvolver um equipe para participar das competições de
futebol robótico na categoria simuladores e, talvez mais tarde também participar com robôs
reais de pequeno porte.
Após alguns meses de trabalho, em 1998 o primeiro time de futebol capaz de participar da
RoboCup na categoria simuladores ficou pronto. Um artigo descrevendo (da Costa e
Bittencourt, 1998) as inovações e a proposta foi apresentado no workshop da RoboCup. Este
evento acontece em paralelo às competições e serve para promover e incentivar as pesquisas
nesta área. Também é o lugar onde são expostas e apresentadas as inovações de cada time. O
simulador apresentava uma arquitetura de agentes concorrentes com o processo decisório
centralizado.
30
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
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
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
“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
3.2 Comportamentos
A arquitetura de subsunção do robô é decomposta em cinco comportamentos separados
segundo à importância das tarefas consideradas durante uma partida de futebol. São estas: Fazer
Gol, Chutar Bola, Carregar Bola, Desviar e Procurar Bola, como mostra a figura 15. Onde a
mais importante, representada ao topo da hierarquia, inibe as ações das camadas inferiores, e
assim sucessivamente caracterizando tarefas prioritárias sobre os comportamentos relacionados
à baixo dela.
Figura 15: Arquitetura de subsunção dos jogadores.
3.2.1.Procurar
O comportamento mais básico definido na arquitetura é o de procurar a bola, pois este deve
emergir quando nenhuma outra situação relevante estiver ocorrendo, ela também é responsável
pela ação de voltar para a defesa quando for solicitado.
O comportamento inicia sua tarefa relevando a informação de que o robô não possui a bola, e se
da em um sequência de cinco ações executadas continuamente, que são representadas pela
transição dos estados superiores na figura 16. Primeiramente é executado uma busca nas
proximidades, com a câmera abaixada e um giro angular de 90°, em seguida a mesma ação
porém no sentido contrário somando um ângulo de 90° novamente, ao que já foi percorrido,
totalizando 180°. Depois uma busca por localidades mais distantes é feita, dessa vez com a
câmera levantada, e em dois passos de 180° na mesma direção, totalizando um giro de 360°
sobre o próprio eixo. Para o robô não ficar infinitamente girando, é executado na quinta ação
35
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
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
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
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
w = erroerro = ref−med
ref = 90o
med = arctan c.o.c.a.
, c.o.= y e c.a.= x−30
med = arctan yx−30
mod 180
w = 90−arctan yx−30
mod 180
Figura 20: Função de correção para perseguir a bola.
Ao final a equação completa é exibida, seu cálculo é atualizado continuamente, enviando
valores de correção angular para o módulo de controle dos motores, até que a bola esteja de
posse do robô, permitindo a partir de então sua condução.
3.2.3.Chutar
O comportamento “Chutar Bola” tem prioridade quando o robô está com a bola porém
encontra-se cercado pelos adversários, cujo autômato está na figura 21. Sua função é de isolar
ou dividir a bola executando a ação de chute. O comportamento emerge a partir da informação
de posse de bola e ativação dos três sensores de distância, e o cuidado de não chutar contra o
próprio patrimônio é analisado através da informação de “golComp”, que acarreta em um giro
até que o gol companheiro não esteja mais sendo detectado, para então a execução do chute.
Figura 21: Autômato da camada Chutar.
40
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
A troca de informações dentro do sistema se da através de mensagens, portanto além de funções
algoritmicas que cada módulo pode conter, existe também a necessidade de discretização das
mensagens, onde todas as possibilidades de valores usadas em cada módulo são resumidos em
alguns valores principais.
3.3.1.Sensores
O módulo de sensores é responsável pela utilização dos sensores de distância, ficando
responsável por ligar, desligar, executar a aquisição e principalmente discretizar o valor de
acordo com a necessidade dos comportamentos da arquitetura de subsunção.
Dentre as mensagens utilizadas, existe principalmente a necessidade do aviso de um obstáculo
perto, portanto a separação da faixa útil em três valores aceitável, e pode ser definido através do
seguinte conjunto:
Sensores = {PERTO , MEDIO , LONGE}
3.3.2.Atuadores
Os atuadores possuem o controle dos motores DC para navegação e dos dois servo motores,
para o chute e para a câmera. Para a navegação é necessário comandos para se locomover para
frente, para trás e girar para cada um dos lados, dessa forma a discretização parte
principalmente desses quatro comandos: frente, trás, direita e esquerda. Um conjunto mais
completo é elaborado para permitir um controle simples de velocidade (normal, lento e rápido),
juntamente com um comando de parar, portanto o conjunto fica definido da seguinte forma:
Navegacao = {parar , frentel , frente , frenter , reh , girohorl , giro hor , giroahorl , giro ahor}
Para o controle do servo motor responsável sobre o mecanismo de chute, dois valores são
apropriados para suprir a demanda dos comportamentos elaborados (levantar o chute e baixar o
chute), um terceiro comando é adicionado para a realização de passe de bola, onde o servo não
atua com a força máxima, e sim em uma intermediária. Ficando o conjunto de mensagens
definido da seguinte forma:
Chute={voltar , toque ,chute }
42
O servo motor da câmera é utilizado somente para a localização da bola, portanto dois valores
são suficientes para o seu controle, são eles: câmera reta, que é o posicionamento normal da
câmera e permite a visualização do campo de forma ampla; e câmera direcionada para baixo,
que serve para analisar a posse de bola ou verificar se ela está nas proximidades. O conjunto de
mensagens para o controle do servo da câmera pode então ser definido da seguinte forma:
Camera={cima , baixo}
3.3.3.Comunicação
O módulo de comunicação implementa um protocolo que pretende complementar o protocolo
usado pelo sistema operacional, oferecendo um serviço de transmissão de mensagens confiável,
ou seja, retransmissão de pacotes perdidos, pois a rede EyeNet somente oferece tolerância a
falhas, onde são descartados pacotes que possuem erros de transmissão. Este serviço é
implementado através de uma arquitetura de envio/resposta, caso a resposta não seja recebida
dentro de um tempo, ela é retransmitida.
O protocolo possui basicamente cinco tipos de mensagens: “com bola”, “sem bola”, “voltar”,
“posição” e “comando remoto”. Os dois primeiros são trocas de mensagens entre jogadores
durante uma partida, quando alguém está de posse da bola, avisa aos companheiros que está
com ela, dessa forma eles não precisam procurar ou disputar a bola e o goleiro não precisa ficar
atento caso a bola esteja vindo em sua direção. A estratégia adotada nesse estado é de manter os
robôs o máximo de tempo parado afim de economizar energia das baterias durante uma partida.
Enquanto que o aviso “sem bola” avisa uma perda dela, informando aos companheiros que
voltem a situação normal de jogo. Ambas as mensagens são implementadas por uma máquina
de estados, mostrada na figura 23, que ao enviar o comando esperam por duas confirmações,
caso elas não cheguem dentro de um tempo limite, o comando é reenviado.
O comando “voltar” é utilizado pelo goleiro, alertando os companheiros que a bola está
próxima ao gol e que precisam assumir uma posição defensiva, e a partir da posição de defesa
continuar com os comportamentos normais de procurar bola e disputar sua posse. Ao chamar os
companheiros o goleiro espera por duas confirmações, caso elas não cheguem dentro de um
tempo limite, o comando é reenviado. Ao receber a mensagem de voltar, os jogadores tem a
liberdade de procurar pelo lado mais próximo de sua posição atual, e ao se dirigir até ela,
43
informa ao seu companheiro que lado escolheu, através do comando “posição” seguida da
identificação deste lado, restando ao outro jogador procurar o lado oposto. Esta mensagem
espera somente uma resposta de confirmação, pois o goleiro não precisa participar da
negociação de posicionamento.
A mensagem “remoto” serve para a estação enviar ordens para cada jogador, ou a todos ao
mesmo tempo, informando-os do início da partida, uma paralisação ou final da partida. O
comando também oferecerá um controle das ações do robô, no qual ele deixa o estado
autônomo e passa para um estado escravo, seguindo unicamente as ordens vindas da estação.
Estes comandos podem ser do tipo “ir para frente”, “ir para trás”, “girar horário”, “girar anti-
horário”, “levantar o chute”, “abaixar o chute”, “levantar a câmera”, “abaixar a câmera”.
Figura 23: Automato responsável pela comunicação entre os robôs.
Para a realização da comunicação o pacote possui um tamanho fixo de quatro campos, sendo
eles: Mensagem, Complemento, Destino e Tipo. A mensagem pode assumir uma entre “com
bola”, “sem bola”, “voltar”, “posição” e “remoto”. O complemento serve para as mensagens de
44
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.
3.3.4. 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 24.
45
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()”.
3.3.5.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
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
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 27.
48
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.
(a)
Avaliação do objeto:
∑i= primeiro
ultimo
∣pixel i−cor∣
ultimo− primeiro ≤ limiarCor
(b)
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
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 , if ∣pixel−cor∣ limiarCorfalse , if ∣pixel−cor∣ limiarCor}
50
Figura 30: Diagrama com a otimização no cálculo da média e o refinamento de novas buscas.
51
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.
4.2.1.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
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
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
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
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
(...)14 struct tcb *thSub, *thMed, *thMen;15 void subsuncao();16 void mediadores();17 void menu();18 19 int main() {20 int err, myId;(...)24 OSMTInit(PREEMPT);25 26 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, 500000, 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();50 51 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
(a)
(b)
(c)
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()66 67 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); // self89 }
Figura 34: Código das threads (main.c).
4.1.2.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
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
#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.
4.1.3.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
Figura 37: Arquitetura do software
4.1.4.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
// 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
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:
Figura 41: Erro angular da bola aplicado na correção
63
30 40 50 60 70 80 90 100 110 120 130 140 150
-1
-0.8
-0.6
-0.4
-0.2
0
0.2
0.4
0.6
0.8
1
Angulo
Cor
reca
o an
gula
r
4.3 Módulos
4.3.1.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 { 0.0017, 0.0017, 0.0018, 0.0018, 0.0018, 0.0018, 0.0019, 0.0019, 11 0.0019, 0.0019, 0.0020, 0.0020, 0.0020, 0.0021, 0.0021, 0.0022, 12 0.0022, 0.0022, 0.0023, 0.0023, 0.0023, 0.0024, 0.0024, 0.0025, 13 0.0026, 0.0026, 0.0027, 0.0027, 0.0028, 0.0028, 0.0029, 0.0029, 14 0.0030, 0.0030, 0.0031, 0.0031, 0.0032, 0.0033, 0.0033, 0.0034, 15 0.0034, 0.0035, 0.0035, 0.0036, 0.0036, 0.0037, 0.0038, 0.0039, 16 0.0040, 0.0043, 0.0045, 0.0048, 0.0050, 0.0054, 0.0058, 0.0061, 17 0.0065, 0.0069, 0.0080, 0.0093, 0.0100, 0.0106, 0.0110, 0.0124, 18 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 19 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 0.0124, 20 0.0124, 0.0124 };(...)
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
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;247 248 max = MAX(r, MAX(g,b));249 min = MIN(r, MIN(g,b));250 delta = max - min;251 252 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 = 126 + (42*(b-r)) / delta; /* 3*42 */256 else /*(b == max)*/ hue = 210 + (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).
4.3.2.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
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().
4.3.3.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 10.
66
(...) 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;36 37 if ( !PSDCheck() )38 return;39 40 // Sensor Frontal41 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;45 46 // Sensor Direita47 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;51 52 // Sensor Esquerda53 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).
4.3.4.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
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
(...) 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; 10 11 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
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
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
5 Conclusão
No desenvolvimento do projeto foram encontradas dificuldades relacionadas ao hardware,
utilização do sistema operacional do robô e no desenvolvimento dos autômatos referentes aos
comportamentos de cada camada na arquitetura de subsunção.
As principais dificuldades encontradas no hardware foram em relação a câmera e ao sensores. A
Câmera possui uma taxa de amostragem muito baixa reflete em uma baixa atualização no
sistema das informações de posse de bola e lado do campo através da identificação da core dos
gols. E os sensores apresentam uma resposta não linear e nem monotônica o que acarreta em
informações não realistas em certos casos onde o obstáculo está muito perto do robô. Outros
inconvenientes foram encontrados, como o mal contado e baixa carga das baterias, e os
conectores dos servos também com mal contado, porém estes não apresentaram um impecílio
no desenvolvimento e inclusive os sensores foram arrumados.
No aprendizado do sistema operacional houve uma certa latência devido a falta de
documentações mais elaboradas e códigos simples de exemplos referentes a utilização de certos
conjuntos de funções. Algumas funções são apresentadas de forma tão simplista na
documentação que gerou a necessidade de elaborar um programa exemplo para a verificação de
sua efetiva semântica. A falta de acesso ao código fonte do sistema operacional podem causar
demora na correção de bugs, e não permitem otimizações realizadas pelos desenvolvedores de
aplicação para os robôs EyeBot. Porém a utilização do GCC como compilador cruzado para a
arquitetura M68K da Motorola, diminui o tempo de desenvolvimento de um programa pois
72
possui suporte completo ao padrão da linguagem e não restringe o desenvolvimento a um
sistema operacional de mercado, devido ao porte à diferentes arquiteturas.
A elaboração dos autômatos apresentaram um tempo de desenvolvimento no projeto
comparável a praticamente todo o período de projeto da arquitetura e dos módulos somado ao
período de implementação, caracterizando a dificuldade de decompor um problema grande,
jogar uma partida de futebol, em máquinas de estado representando problemas menores.
Levando em consideração a simplificação do domínio já representada por comportamentos,
executados em um jogo efetivo, dentro de uma arquitetura de Subsunção. O tempo se deve
principalmente a dificuldade de expressar quais os estados em que o comportamento pode estar,
assim como as ações que devem ser tomada, usando somente os sensores de distância
informações simples da imagem adquirida, que não precisam complexidade no processamento
de imagem
O desenvolvimento do projeto foi impulsionado por um certo estímulo adicional, que foi a
participação no campeonato nacional da RoboCup, que apesar de não ter retornado com
resultado interessantes das partidas, derrota por 8x0 e 10x0, trouxeram observações construtivas
para a determinação de desenvolvimentos futuros, definição de novas metas e reflexão das
decisões tomadas sobre o projeto elaborado. Por exemplo, nas partidas ocorreram um grande
número de choques entre robôs e uma demora excessiva na procura da bola, que se deve à alta
movimentação dos robôs adversários e velocidade na trajetória da bola, respectivamente, que
evidenciam componentes de alta dinâmica em uma partida de futebol.
A quantidade de colisões refletem alterações necessárias em hardware, como maior número de
aquisições de imagem e maior velocidade nos motores, para a realização de respostas reativas
em menor tempo ao ambiente. Já a procura da bola sugere a investigação de técnicas mais
apuradas de software (como auto-localização no ambiente e cooperação de tarefas), que podem
ser exploradas pelos robôs para a finalidade de encontrar a bola, realizando uma coordenação
entre eles para a procura em regiões distintas, e para o compartilhamento de informações como
a localização da bola. Dessa maneira é evitada a execução de tarefas redundantes entre os robôs
(no caso da procura da bola em uma mesma região), que na concepção atual do projeto, elas são
realizadas de forma extremamente individualista, apresentando um baixo desempenho na
disputa de partidas.
Além do desenvolvimento de técnicas de cooperação e localização no espaço, também puderam
73
ser observadas as necessidades de inclusão de um sistema de previsão de trajetórias,
recuperação ao ficar preso e algumas alterações no sistema de visão. Um sistema de previsão da
trajetória de objetos para o melhoramento das ações de perseguir e carregar a bola, visando
também suprir as limitações da câmera que oferece uma baixa taxa de amostragem das imagens
do ambiente. Um comportamento pode ser adicionado a fim de tentar resolver o problema de o
robô ficar preso em outros robôs ou em algum canto do campo, fato que ocorreu varias vezes
durante a realização das partidas. E o sistema de visão pode ser melhorado, uma vez que o
algoritmo atual ainda permite mais processamento sem degradação das respostas reativas do
sistema, afim de inserir melhorias no sistema de identificação de objetos, se aproveitando de
filtros de ruído ou algoritmos de segmentação, inserir algoritmos para identificação de
obstáculos permitindo cálculo de trajetórias, auxiliando o sistema de navegação. Para a A
inclusão de um módulo de previsão
Outro inconveniente encontrado foi a baixa persistência do robô em disputar a bola, pois a ação
de seguir a bola era constantemente interrompida pelo comportamento reativo de procurar bola,
pois o estímulo necessário para a atuação dessa ação é a a não presença da bola no campo de
visão, que ocorre de forma bastante frequente mediada que outros jogadores passam na frente
ou a bola sai do campo de visão, gerando uma grande quantidade de ruído interna fazendo com
que o robô intercale tarefas de forma indesejável, deixando assim de executar a ação pertinente
que é a de perseguir a bola. Entre todas as consequências observadas, talvez essa seja a de
maior significância referente ao reflexo do modelo adotado pelo projeto na performance do
robô durante as partidas realizadas, pois explícita a dificuldade de expressar na forma
puramente reativa comportamentos que sugerem uma ação não dependente exclusivamente de
estímulos sensoriais, mas também de comportamentos realizados no passado. Essa
característica reflete diretamente a introdução no sistema de modelos mais elaborados de
processos cognitivos, como planejamentos e decisões de alto nível.
De forma geral o desenvolvimento do projeto contribuiu de uma forma construtiva, reunindo
estudos em disciplinas bem diferenciados como inteligência artificial, visão computacional e
sistemas embarcados, o que é inerente dentro da pesquisa e desenvolvimento em robótica por
ser uma área em que a informática, eletrônica e mecânica se fundem, trazendo desafios
interdisciplinares bastante motivadores e interessantes a serem superados. Entre eles a
realização de uma partida de futebol robótico totalmente autônomo.
74
Referências
[Abb83] ABBOTT, R.J., Program Design by Informal English Descriptions, CACM, vol. 26, nº 11, novembro de 1983, pp. 882-894.
[App04] APPELL, David. O pai do Spirit e do Opportunity. Scientific American Brasil, São Paulo, ano 2, n. 30, p. 20-21, nov. 2004.
[Ark98] R. C. Arkin. Behavior Based Robotics. The MIT Press, Cambrige-Massachusetts, 1998
[Bra04a] BRAUNL, Thomas; GRAF, Birgit. Autonomous mobile robots with on-board vision and local intelligence. Disponível em: < http://robotics.ee.uwa.edu.au/papers/AutMobRob-1999.pdf>. Acesso em: 26 novembro 2004.
[Bra04b] BRAUNL, Thomas. EyeBot: A family of autonomous mobile robots. Disponível em:< http://robotics.ee.uwa.edu.au/papers/EyeBotFamily-1999.pdf>. Acesso em: 26 novembro 2004.
[Bro85] Rodney A. Brooks. A Robust Layered Control System for a Mobile Robot. Massachusetts Institute of Technology. Setembro, 1985
[Bro86] Rodney A. Brooks. Achieving Artificial Intelligence Through Build Robots. Massachusetts Institute of Technology. Maio, 1986.
[Bro90] Rodney A. Brooks. Elephants Don't Play Chess. In Maes, P. (ed.) Designing Autonomous Agents. MIT Press, paginas 3-15, 1990.
[Bro91] Rodney A. Brooks. Inteligente Without Reason. Computers and Thought. Abril 1991
[Bur97] BURO, Michael. The Othello Match of the Year: Takeshi Murakami vs. Logistello , ICCA Journal 20(3) 1997, 189-193
[Den73] DENNIS, J. Modularity. Advanced Course on Software Engineering (F. L. Bauer, ed.), Springer-Verlag, 1973, pp. 128-182.
[Dij65] DIJKSTRA, E.W. Cooperating sequential processes. In: Genuys, F. (ed.) Programming languages. Londres: Academic Press, 1965.
[Dij69] Edsger Wybe Dijkstra. Notes on Structure Programming. In Structured Programming. Academic Press. Londres, UK, 1969.
[Per06] Anderson L. F. Perez, et. al. Arquitetura de Controle do Time de Futebol de Robôs UFSC-Team Categoria Very Small. Congresso Sociedade Brasileira de Computação. Julho de 2006
[FIR06] FIRA. FIRA | Federation of International Robot-soccer Association. Disponível em: <http://www.fira.net/>. Acessado em: 22 julho 2006.
[Fol06] FOLDOC. The Free On-line Dictionary of Computing. Disponível em: <http://foldoc.org>. Acessado em 22 julho 2006.
[Gib04a] GIBBS, W. Wayt. Uma nova geração de robôs. Scientific American Brasil, São Paulo, ano 2, n. 22, p. 36-45, mar. 2004.
[Gib04b] GIBBS, W. Wayt. Do fim ao começo. Scientific American Brasil, São Paulo, ano 2, n. 28, p. 20-21, set. 2004.
[HO93] William H. Harrison, Harold Ossher. Subject-Oriented Programming (A Criteria os Pure Objects). In Proceeding of the 8th Conferece of Object Oriented Programming Systems Languages and Applications, p. 411-428, Washington, U.S.A., September 1993.
[Kit99] KITANO H. 1999. Preface, Special Issue: RoboCup the First Step. Artificial Intelligence 110(2); 189-191.
[KLM97] Gregor Kicczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean Mare Loingtier, John Irwin. Aspect Oriented Programming. Proceeding of the European Conference on Object-Oriented Programming '97. vol. 1241. Lecture Notes in Computer Science, p. 220-242. Jyväskylä, Finlandia, Junho 1997.
[KR84] Brian W. Kernighan e Dennis M. Ritchie. The C Programming Language. Printice-Hall. 1984.
[Nof99] Shimon Y. Nof. Handbook of Industrial Robotics. John Wiley e Sons, 2a edição. 1999.
[Nor06] Anders Norlander. Linking with Borland C. Disponível em: <http://www.cygwin.com/ml/cygwin/1998-09/msg00458.html>. Acessado em: 22 Julho 2006
[Nun02] NUNES, Luís Eugenio. On Learning by Exchanging Advice. Second Symposium on Adaptive Agents and Multi-Agent System. 2002.
[Pag04] PAGELLO, Enrico; et. al. RoboCup-2003: New Scientific and Technical Advances. AI-MAGAZINE. 81-98. Volume 25; Numero 2; 2004.
[Paz02] PAZOS, F. Automação de Sistemas e Robótica. Editora Axcel. 2002.
[RN04] RUSSEL, S. J.; NORVIG, P. Inteligência artificial. Tradução de Vandenber D. de Souza. Rio de Janeiro: Elsevier, 2004. 1025 p. Titulo Original: Artificial intelligence, 2nd ed.
[Rob04] ROBOCUP. RoboCup World Championship. Disponível em: <http://www.robocup.org/02.html>. Acessado em: 22 novembro 2004.
[Rob06] ROBOCUP. RoboCup 2006 – Bremen / Germany. Disponível em: <http://www.robocup2006.org>. Acessado em: 22 julho 2006.
[Sam67] SAMUEL, Arthur. Some studies in machine learning using the game of checkers. II-Recent progress. IBM Journal on Research and Development, 11:601-617, 1967
[Sil98] SILVA, Luciano Rottava da. Análise e programação de robôs móveis autônomos da plataforma EyeBot. Dissertação de Mestrado. 2003
[Sil06] Flávio A. Silva, et. al. Estratégia para o Controle dos Robôs Eyebot do UFSC-Team: Categoria Small Size do Futebol de Robôs. Congresso da Sociedade Brasileira de Computação. Julho de 2006
[Sim69] Herbert A. Simon. Sciences of the Artificial. MIT Press. 1969.
[Smi78] A. R. Smith, Color gamut transform pairs, in SIGGRAPH '78: Proceedings of the 5th annual conference on Computer graphics and interactive techniques. New York, NY, USA: ACM Press, 1978, pp. 12--19.
[Ten00] TENNENHOUSE, David. Proactive Computing. Communications of the ACM, 43(5):45 -50, Maio 2000.
[Tes94] TESAURO, Gerry. TD-Gammon, a self-teaching backgammon program, achieves master-level play. Neural Computation, 6(2): 215-219, 1994
[Wan05] WANGENHEIM, Aldo von. Visão Computacional. Disponível em: <http://www.inf.ufsc.br/~visao/>. Acessado em: 03 julho 2005.
[Wol01] Wayne Wolf, Computer as Componentes: Principles of Embedded Computing System Design. Morgan Kaufman. 2001
[Woo90] Wood, M. e Barrett, T. A Real-Time Primer, Embedded Systems Programming, vol 3, nº 2, pp.20-28. Fevereiro 1990.
[Zlo02] ZLOTZ, L. M., STENTZ, A. T., DIAS, M. B., THAYER, S. Market-driven Multi Robot Exploration Technical Report. CMU-RI-TR-02-02, Robotics Institute, Carmegie Mellon University, Pittsburg, PA.
[ZM06] Ricardo Zelenovsky e Alexandre Mendonça. PC: um Guia Prático de Hardware e Interfaceamento, 4ª edição. MZ Editora. 2006
