UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SIMULAÇÃO DE ESTRATÉGIAS PARA UM VEÍCULO ROBÓTICO AUTÔNOMO PARA PATRULHAMENTO
Área de Robótica
por
Eduardo Rocha Passos
Rafael Luiz Cancian, M.Sc. Orientador
Itajaí (SC), junho de 2008
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SIMULAÇÃO DE ESTRATÉGIAS PARA UM VEÍCULO ROBÓTICO AUTÔNOMO PARA PATRULHAMENTO
Área de Robótica
por
Eduardo Rocha Passos Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Rafael Luiz Cancian, M.Sc.
Itajaí (SC), junho de 2008
DEDICATÓRIA
Este trabalho é dedicado a todas as
pessoas que buscam ampliar os horizontes do
conhecimento, visando facilitar a vida das
das pessoas e tornar o mundo um lugar
melhor para se viver.
AGRADECIMENTOS
A meus pais, que sempre me deram todo o apoio necessário durante esta jornada, assim
como a educação e o exemplo de vida que me fizeram chegar até aqui.
À minha namorada, que com muita paciência e compreensão, esteve me apoiando ao longo
desse tempo e pela compreensão nos momentos em que não pude estar ao seu lado.
Aos meus colegas e amigos que fiz durante esta caminhada, compartilhando alegrias e
angustias.
Ao meu orientador Rafael Luiz Cancian, pelas muitas horas de paciência, sugestões e
críticas para que o trabalho fosse bem elaborado.
À banca examinadora do meu trabalho, por todas as sugestões e críticas feitas para que meu
trabalho fosse bem elaborado.
A todos os professores, que durante o período acadêmico me forneceram o conhecimento
necessário para a elaboração deste trabalho.
SUMÁRIO
LISTA DE ABREVIATURAS ................................................................. vii LISTA DE FIGURAS ............................................................................. viii LISTA DE QUADROS .............................................................................. iv RESUMO ..................................................................................................... x ABSTRACT ................................................................................................ xi 1 INTRODUÇÃO ........................................................................................ 1 1.1 PROBLEMATIZAÇÃO ....................................................................................... 2 1.2 OBJETIVOS .......................................................................................................... 3 1.2.1 Objetivo Geral ..................................................................................................... 3 1.2.2 Objetivos Específicos .......................................................................................... 3 1.3 METODOLOGIA .................................................................................................. 4 1.4 ESTRUTURA DO TRABALHO ......................................................................... 4 2 FUNDAMENTAÇÃO TEÓRICA .......................................................... 5 2.1 ROBÓTICA ........................................................................................................... 5 2.1.1 Definições ............................................................................................................. 6 2.1.2 Tipos de robôs ..................................................................................................... 7 2.1.3 Mapeamento espacial ......................................................................................... 8 2.2 AUTOMAÇÃO E CONTROLE DE SISTEMAS ............................................ 12 2.2.1 Controladores .................................................................................................... 12 2.2.2 Sensores ............................................................................................................. 13 2.2.3 Atuadores .......................................................................................................... 15 2.2.4 Sistemas Embarcados ....................................................................................... 16 2.3 SIMULADORES DE ROBÔS ............................................................................ 16 2.3.1 Simulador Khepera .......................................................................................... 16 2.3.2 Robocode ........................................................................................................... 18 2.3.3 Simulador Simbad ............................................................................................ 20 2.4 TEORIA DOS GRAFOS .................................................................................... 23 2.4.1 Definições ........................................................................................................... 23 2.4.2 Representação para Grafos ............................................................................. 25 2.4.3 Tipos de Grafos ................................................................................................. 25 2.4.4 Caminhamento em Grafos ............................................................................... 28 2.4.5 Caminho Crítico ............................................................................................... 29 2.5 LÓGICA NEBULOSA ........................................................................................ 29 2.6 TRABALHOS RELACIONADOS .................................................................... 31 3 DESENVOLVIMENTO ........................................................................ 34 3.1 PROJETO ............................................................................................................ 34 3.1.1 Análise de Requisitos ........................................................................................ 34 3.1.2 Especificação dos Requisitos Funcionais ........................................................ 35
vi
3.1.3 Arquitetura do Sistema .................................................................................... 37 3.1.4 Modelagem UML .............................................................................................. 38 3.1.1.1 Diagrama de Componentes .............................................................................. 38 3.1.1.2 Diagrama de Caso de Uso ............................................................................... 39 3.1.1.3 Diagrama de Classes ........................................................................................ 40 3.1.1.4 Diagrama de Seqüência ................................................................................... 44 3.1.4 Controlador Fuzzy ............................................................................................ 48 3.2 IMPLEMENTAÇÃO .......................................................................................... 49 3.2.1 Execução do Sistema ........................................................................................ 49 3.2.1.1 Testes de validações ........................................................................................ 50 4 CONCLUSÃO ........................................................................................ 53 REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 55
ANEXO ............................................................................ 51 I FERRAMENTA JAVA.......................................................................... 52
LISTA DE ABREVIATURAS
TCC Trabalho de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí GSED Grupo de Sistemas Embarcados e Distribuídos UML Unified Modeling Language RUS Rossum´s Universal Robots AC Corrente Alternada DC Corrente Direta ou Continua PERT Program Evaluation and Review Tecnique GPS Sistema de Posicionamento Global
LISTA DE FIGURAS
Figura 1. Possível classificação para máquinas .................................................................................. 8 Figura 2. Representação da trajetória do robô ..................................................................................... 9 Figura 3. Propagação do algoritmo do brushfire com conexão de oito – ponto................................ 10 Figura 4. Diferentes formas de representar um ambiente: topológica, geométrica e grades ............. 11 Figura 5. Sensor ótico de barreira ...................................................................................................... 14 Figura 6. Tela do Simulador Khepera ............................................................................................... 16 Figura 7. Anatomia de um robô ......................................................................................................... 18 Figura 8. Meu primeiro Robô ............................................................................................................ 20 Figura 9. Interface do Simulador Simbad...........................................................................................22 Figura 10. Grafo dirigido (à esquerda) e não dirigido (à direita) ..................................................... 24 Figura 11. Grafo conexo .................................................................................................................... 25 Figura 12. Grafo Desconexo .............................................................................................................. 26 Figura 13. Componente conexo ......................................................................................................... 26 Figura 14. Grafo fortemente conexo .................................................................................................. 27 Figura 15. Componente fortemente conexo ...................................................................................... 27 Figura 16. Algoritmo do Carteiro Chinês .......................................................................................... 28 Figura 17. Estrutura do controlador nebulosos .................................................................................. 31 Figura 18. Estrutura de Camadas de Software .................................................................................. 38 Figura 19. Diagrama de Componentes .............................................................................................. 39 Figura 20. Diagrama de Caso de Uso ................................................................................................ 40 Figura 21. Diagrama com uma visão geral das classes ..................................................................... 41 Figura 22. Diagrama de Classe do Analisador de Ambiente ............................................................. 43 Figura 23. Diagrama de Classe do Estrategista ................................................................................. 44 Figura 24. Diagrama de Seqüência de tomadas de decisão do Estrategista ...................................... 46 Figura 25. Diagrama de Seqüência do Planejador de Rotas .............................................................. 47 Figura 26. Diagrama de Seqüência do Mecanismo de Comunicação ............................................... 47 Figura 27. Ambiente de simulação do Simbad .................................................................................. 50 Figura 28. Log obtido quando o robô detecta obstáculo próximo ..................................................... 51 Figura 29. Log obtido quando o robô detecta uma alteração grande no ambiente ............................ 51 Figura 30. Log obtido quando o robô encontra um buraco .............................................................. 52 Figura 31. Robô identificando diferentes tipos de obstáculos ........................................................... 53 Figura 32. Robô encontra uma alteração no ambiente e notifica a Central ....................................... 54 Figura 33. Robô se desloca até uma coordenada repassada pela Central .......................................... 55 Figura 34. Robô verifica pessoal autorizado – parte 1 ...................................................................... 56 Figura 35. Robô verifica pessoal autorizado – parte 2 ...................................................................... 57
LISTA DE QUADROS
Quadro 1. Principais comandos do robô ............................................................................................ 19 Quadro 2. Eventos utilizados pelo robô ............................................................................................. 19 Quadro 3. Funções para obter informações ....................................................................................... 19 Quadro 4. Principais funções disponibilizadas pelo Simbad..............................................................22 Quadro 5. Função de pertinência........................................................................................................49
RESUMO
PASSOS, Eduardo Rocha. Simulação de Estratégias para um Veículo Robótico Autônomo para Patrulhamento. Itajaí, 2008. 72 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2008. Um dos grandes problemas da sociedade moderna é o aumento da criminalidade. Esse problema vem aumentando cada vez mais o investimento na área de segurança, com a criação de empresas especializadas que provêm equipamentos de monitoração e pessoal capacitado. Pelo alto custo para se manter um sistema de segurança eficiente, cada vez mais empresas buscam novas tecnologias para atender suas necessidades. A utilização de robôs para executar a tarefa de monitoramento e vigilância de propriedades é uma idéia que vem sendo o foco de pesquisa em várias empresas dessa área e em centros acadêmicos. Este projeto desenvolveu o software de alto nível de um robô para que ele seja capaz de se locomover de maneira autônoma para realizar o patrulhamento de grandes áreas, como, edifícios, indústrias, fazendas, etc. Supôs-se que as camadas mais baixas de software e que o hardware já estavam prontos, e utilizou-se o ambiente de Simulação Simbad como interface para essas camadas e para o ambiente físico, simulando a área a ser patrulhada. Os resultados demonstram a possibilidade de patrulhamento autônomo por robôs comunicantes e indicam os desenvolvimentos que ainda são necessários. Palavras-chave: Robótica. Inteligência Artificial. Segurança.
ABSTRACT
The increase of criminality is one of the biggest problems in modern societies. This problem has increased even more investments for security, with the creation of specialized enterprises that provide monitoring equipments and capable employees. Due to the high cost to maintain efficient security systems, more and more enterprises look for new technologies to satisfy their needs. The use of robots to execute the task of monitoring and keeping private places have being focus of research in such enterprises and also in academy. This project intends to develop the software of a robot to make it in position to move itself to monitor private places, as buildings, industries, farms, and so on. In this project we present a theorical fundamentation about the main concerns related to it, such as robotics and techniques for path planning and high level strategies. This text also presents the design and development of the system that was implemented in this work completion of course.
Keywords: Robotics. Artificial Intelligence. Graph Theory.
1 INTRODUÇÃO
Um robô é definido por Heinen (2007) como sendo “uma máquina programável que é capaz
de imitar as ações ou aparência de uma criatura inteligente, geralmente um ser humano”. Que se
difere das outras máquinas por ser capaz de, no mínimo, duas coisas: (i) obter informações de seu
próprio ambiente, e (ii) atuar de alguma forma física neste ambiente, se movendo ou manipulando
objetos, por exemplo. A robótica já pode ser encontrada atuando na área de segurança,
principalmente em situações que envolvem alto risco ao ser humano. Um exemplo disso é o robô
“Ofro”, que foi utilizado na copa do mundo da Alemanha, e era capaz de avançar por terrenos
difíceis, subir escadas e detectar explosivos, armas e pessoas. Ele também era capaz de localizar
agentes químicos ou biológicos e detectar movimento suspeitos em um raio de 30 metros
(AGENCIA EFE, 2006).
Já existem várias empresas desenvolvendo sistemas robóticos capazes de fazer a segurança
de lojas e estabelecimentos comerciais, utilizando sensores para aumentar sua eficiência e dificultar
a ação dos marginais. Nos Estados Unidos, a empresa VersaLogic lançou um robô de patrulha,
destinado a substituir guardas humanos nas rondas de edifícios, empresas, e áreas de segurança em
geral. O “PatrolBoot”, como foi batizado, utiliza um processador Pentium III e o sistema
operacional Linux, o que o torna capaz de se comunicar via rede sem fio, enviando imagens e sons
para outro computador da rede (embora essas características também possam ser conseguidas com o
uso de outras arquiteturas, inclusive embarcadas). O robô está equipado com um sistema avançado
de navegação, sendo capaz de armazenar em sua memória um mapa completo da sua área de
atuação, o que o permite saber exatamente sua localização e possibilita seu deslocamento por todo o
território, inclusive encontrando rotas alternativas caso a escolhida esteja obstruida. O custo
aproximado do “PatrolBoot” é de U$ 30.000,00 (ROBÔ PATRULHEIRO, 2003).
Neste trabalho de conclusão de curso foi modelado um sistema que pode ser empregado em
diversos tipos de robôs com a finalidade de realizar o patrulhamento em grandes áreas, como
edifícios, indústrias, etc. Para validar a solução proposta foi utilizado o ambiente de simulação
Simbad.
Para a realização deste trabalho foram utilizadas diversas áreas de conhecimento da ciência
da computação, como circuitos digitais, arquitetura de computadores, sistemas embarcados,
inteligência artificial, redes de computadores e teoria dos grafos, sendo possível colocar em prática
o conhecimento adquirido durante o curso. Este trabalho também apresentou um grau razoável de
complexidade para seu desenvolvimento, está em concordância com as linhas de pesquisa e com o
2
interesse do Grupo de Sistemas Embarcados e Distribuídos (GSED) do Curso de Ciência da
Computação, e demonstra ser uma solução inovadora para o problema, com potencial para
publicações técnico-científicas e a geração de produtos.
1.1 PROBLEMATIZAÇÃO
Formulação do Problema
Um dos grandes problemas do mundo atual é o grande aumento da criminalidade, e o Brasil
não está fora desta terrível realidade. Segundo uma matéria do Jornal Hoje da rede Globo (JORNAL
HOJE, 2007), o ritmo de crescimento da violência vem aumentando cada vez mais no interior do
país, onde estão surgindo novos pólos de crescimento econômico e há poucos investimentos por
parte dos governantes na área de segurança.
Devido a esses problemas, surgem cada vez mais empresas privadas na área de segurança
que oferecem a seus clientes soluções que incluem desde vigilância patrimonial física, realizada por
pessoal treinado, até vigilância eletrônica, realizada através de sistemas de monitoramento de
alarmes e controle de acessos. O grande problema dessas empresas é manter um sistema de
vigilância eficiente, 24 horas por dia em uma propriedade, devido ao custo dos equipamentos e
principalmente com pessoal treinado para fazer a segurança do local e operar tais equipamentos.
Conforme Pazos (2002) este custo poderia ser reduzido com a utilização de robôs, pois eles podem
trabalhar cerca de 98% do tempo na tarefa requerida e não estão sujeitos aos encargos trabalhistas e
os diversos benefícios que aumentam o valor da “hora-homem” de trabalho.
Solução Proposta
Este Trabalho de Conclusão de Curso (TCC) propõe-se a modelar e implementar robôs
autônomos capazes de obter informações sobre o ambiente que os cercam, atuar sobre ele, e
comunicar-se com demais robôs com o objetivo de realizar a patrulha em grandes propriedades,
condomínios fechados e empresas. Seus vários tipos de sensores podem fazer com que tenham um
bom conhecimento do ambiente ao seu redor, e eles podem ser acrescidos de diferentes
equipamentos, permitindo que tenham características específicas e que realizem outros tipos de
serviços.
3
Imagina-se que, devido às suas diversas características, em alguns anos, o custo/benefício
da solução robótica será satisfatório, se comparado à solução “humana” ou eletrônica, e que tal tipo
de solução poderá tornar-se altamente comum a partir desse momento.
1.2. OBJETIVOS
1.2.1. Objetivo Geral
Este Trabalho de Conclusão de Curso (TCC) visa modelar e implementar o software para
robôs autônomos, tornando-os capazes de se locomover autonomamente por um ambiente dinâmico
e de se comunicar com outros robôs, com o objetivo de realizar a patrulha em grandes propriedades,
como empresas e indústrias. Para limitar seu escopo, neste TCC foi pressuposto que as camadas de
software de mais baixo nível estavam disponíveis e possuíam uma interface de programação
definida, permitindo que fosse focado nas camadas mais altas, de planejamento de caminho e
estratégias de ação dos robôs.
1.2.2 Objetivos Específicos
Os objetivos específicos desse processo de pesquisa são:
• Pesquisar e analisar soluções similares;
• Determinar os requisitos necessários à execução do projeto;
• Pesquisar e compreender os conceitos e tecnologias necessárias à implementação do
sistema;
• Realizar a modelagem conceitual do sistema;
• Implementar as camadas mais altas de software de controle do robô;
• Testar e verificar implementação do sistema através de um simulador;
• Testar e validar a utilidade/funcionalidade do sistema;
• Documentar o desenvolvimento e os resultados do sistema.
4
1.3 METODOLOGIA
A metodologia utilizada para a realização deste trabalho está dividida nas seguintes etapas:
(i) Pesquisa, (ii) Modelagem, (iii) Implementação, (iv) Validação, e (v) Documentação.
Na etapa de Pesquisa foi realizada uma revisão bibliográfica baseada na leitura de textos
disponíveis em livros, artigos técnicos-científicos e sites na internet. Realizou-se então uma análise
das tecnologias já disponíveis e de possíveis soluções para o problema proposto, visando determinar
a melhor forma para a implementação do projeto.
Na etapa de Modelagem, foi realizado o projeto do sistema. Utilizando o modelo UML
(Unified Modeling Language) foram gerados diversos diagramas para descrever o projeto.
As etapas de Pesquisa e a parte inicial da Modelagem foram realizadas na primeira fase
deste trabalho (TCC I). A conclusão da etapa de Modelagem, assim como as etapas de
Implementação e Validação foram realizadas na segunda etapa desta pesquisa (TCC II).
A etapa de Documentação, desenvolvida durante todo o trabalho, inclui a redação dos textos
produzidos e que compõe este relatório.
1.4 ESTRUTURA DO TRABALHO
Este trabalho se divide em quatro capítulos, sendo o Capítulo 1 uma introdução sobre os
assuntos que serão abordados no texto. O Capítulo 2 apresenta a fundamentação teórica, na qual são
descritos os assuntos relevantes ao trabalho. No Capítulo 3 é descrita a modelagem do sistema a ser
desenvolvido e, no Capítulo 4, serão apresentadas as considerações finais.
5
2 FUNDAMENTAÇÃO TEÓRICA
2.1 ROBÓTICA
Desde os tempos pré-históricos a humanidade tem demonstrado grande fascínio por seres
extraordinários, homens mecânicos e outras criaturas que, em geral, nunca saíram da sua
imaginação. Os sacerdotes egípcios utilizavam braços mecânicos para impressionar o povo com o
poder dos deuses. Os gregos utilizavam estátuas operadas hidraulicamente para exercícios didáticos
e entretenimento. E na época medieval, relógios montados no topo das igrejas e catedrais tinham
figuras humanas em tamanho natural, representando anjos e demônios, que se movimentavam para,
com um martelo, bater num sino (PAZOS, 2002).
Vários autores, como Pazos (2002), Groover et al. (1989) e Polonskii (1996), concordam
que um importante acontecimento para a robótica foi a peça escrita por Karel Capek e que deu
origem ao termo robô. A peça RUR (“Rossum´s Universal Robots”), que foi encenada pela primeira
vez em Praga (Republica Tcheca), em 1921, conta a estória de um cientista chamado Rossum, que
desenvolve uma substância química e a utiliza para a construção de humanóides que deveriam ser
obedientes e realizar trabalhos físicos. Ele continua fazendo aperfeiçoamentos no projeto até chegar
a um ser que ele considerou perfeito. O plano muda de rumo quando os robôs “perfeitos” começam
a não gostar de seu papel de servir e rebelam-se contra seus senhores, destruindo toda vida humana.
Em tcheco a palavra robota significa trabalhador que exerce um serviço em forma compulsória,
sendo traduzida para o inglês, o termo virou robot.
Pazos (2002) e Groover et al. (1989) também concordam que outro escritor que contribuiu
muito nessa área foi o escritor de ficção cientifica Issac Asimov, sendo considerado o primeiro a
utilizar o termo robótica para definir a ciência que estuda os robôs. Ele também estabeleceu o que
ele chamou de “três leis fundamentais da robótica” que são:
1.Um robô não deve prejudicar nunca um ser humano nem através da ação direta, nem
através da inação;
2.Um robô deve sempre obedecer a seres humanos, a menos que isso entre em conflito com
a primeira lei;
3.Um robô deve sempre se proteger de danos a menos que isso entre em conflito com a
primeira ou a segunda lei.
6
Conforme Groover et al. (1989), o conceito popular de um robô é que o mesmo possui uma
forma humanóide, que se parece e age como o ser humano. Esse conceito foi inspirado e encorajado
por inúmeras histórias de ficção cientifica. Entretanto, a forma humanóide não é necessária e sequer
a mais comum na robótica atual.
Essas histórias de ficção científica inspiraram vários cientistas da década de 60 e 70, que
começaram a desenvolver os primeiros protótipos de robôs móveis que tentavam imitar a forma
humana e necessitavam de um operador, pois não eram providos de qualquer tipo de inteligência e
tinham como finalidade a diversão dos seus criadores e do publico em geral. A partir do final da
década de 70 e do começo da década de 80, surgiram os primeiros projetos com aplicações sérias
para robôs móveis, como patrulhamento de regiões, transporte de cargas, exploração, etc, e na
maioria das vezes patrocinadas por órgãos militares ou grandes empresas.
2.1.1 Definições
O entendimento de alguns conceitos básicos é necessário ao desenvolvimento de robôs,
começando pelo conceito de máquina. Existem várias definições para máquinas, mas aquele que
foca em sua utilidade define máquina como qualquer dispositivo capaz de transformar energia em
trabalho útil. A energia pode ser adquirida de qualquer fonte, podendo ser qualificada e expressa
numa unidade física chamada Joule. E o trabalho útil, do ponto de vista físico, é a aplicação desta
energia(PAZOS, 2002).
As máquinas podem ser classificadas de várias formas diferentes, como, por exemplo,
discriminando-as segundo o tipo de energia empregado para gerar este trabalho, dividindo-as em
máquinas elétricas, térmicas, manuais, etc (PAZOS, 2002).
Outra forma de classificação é a origem da fonte de energia, isto é, se a fonte de energia for
proveniente de força humana ou externa à ação do operador, sendo assim divididas em máquinas
automáticas ou manuais. As máquinas automáticas são aquelas cuja energia provém de uma fonte
externa, por exemplo, energia elétrica, térmica, etc. Máquinas manuais são aquelas que precisam
da energia permanente do operador para efetuar o trabalho (PAZOS, 2002).
As máquinas automáticas também podem ser classificadas de diversas formas, segundo tipo
de energia, características construtivas, peso e tamanho. Será utilizada a classificação que divide as
máquinas automáticas em programáveis e não programáveis. Sendo as máquinas automáticas não
programáveis aquelas que, uma vez projetadas ou configuradas, efetuam sempre o mesmo
trabalho, como por exemplo, a furadeira automática que apenas gira a broca. E as máquinas
7
automáticas programáveis são todas aquelas cujo trabalho depende em certa medida de instruções
previamente dadas pelo operador, seja qual for o meio pelo qual foram introduzidos essas instruções
na máquina e o formato delas. Essas instruções serão chamadas genericamente de programas.
Então pode-se definir o termo robô como sendo uma máquina automática programável (PAZOS,
2002).
Segundo Groover et al. (1989), a definição “oficial” de um robô industrial é dada pela
Associação das Indústrias de Robótica, antigo Instituto Americano de Robótica, e que define um
robô industrial como um manipulador programável, multifuncional, projetado para mover materiais,
peças, ferramentas ou dispositivos especiais em movimentos variáveis programados para a
realização de uma variedade de tarefas. Assim, os robôs industriais devem ser classificados como
uma forma de automação programável.
2.1.2 Tipos de robôs
Segundo Pazos (2002), os diferentes tipos de robôs também podem ser classificados de
diversas maneiras, de acordo com suas diferentes utilidades, conforme Figura 1.
A primeira classe a considerar é a dos robôs manipuladores, que são braços mecânicos, ou
qualquer sistema que em geral, tenha por objetivo deslocar material de um ponto a outro do espaço
ou acompanhando uma trajetória dentro de um volume de trabalho (PAZOS, 2002).
A maioria dos robôs usados em fábricas hoje é montada em uma base fixa, que está ligada à
base e ao braço. Na extremidade do braço está o punho, que consiste de vários componentes que lhe
permitem orientação numa diversidade de posições. Os movimentos relativos entre os diversos
componentes do corpo, braço e punho são proporcionados por uma série de juntas. E o conjunto
formado pela base, braço e punho é por vezes chamado de manipulador (GROOVER et al., 1989).
Outra classe a ser considerada é a de robôs exploradores, que tem por objetivo explorar um
determinado ambiente e revelar, através de sensores, suas características físicas (PAZOS, 2002).
Um exemplo desse tipo de robô são os robôs Spirit e Opportunity, projetados pela NASA para fazer
a exploração de Marte. Eles receberam diversos sensores para coletar informações e transmiti-las de
volta à Terra com a ajuda de uma sonda espacial denominada de Mars Reconnaissance Orbiter.
Inicialmente os dois robôs exploradores receberam apenas três meses de vida, devido ao desgaste
das peças pelo ambiente rigoroso do planeta, e hoje já completam três anos funcionando no solo de
Marte. Segundo o Laboratório de Propulsão a Jato, entidade da NASA que supervisiona os
8
trabalhos em Marte, os robôs estão cada vez mais inteligentes devido às atualizações em seus
softwares.
A terceira classe é a de máquinas-ferramentas, ou robôs que tem por objetivo processar
uma determinada matéria-prima, aumentando seu valor agregado, como os robôs de solda (PAZOS,
2002).
Figura 1. Possível classificação para máquinas
Fonte: Silva (2003).
Existem também robôs que não se enquadram nas classificações anteriores, como os robôs
de uso geral. Um exemplo é o controlador de temperatura programável, que tem como finalidade
manter a temperatura do ambiente ou sistema num determinado nível ou percorrendo determinada
excursão térmica, segundo programa previamente indicado ao controlador (PAZOS, 2002).
2.1.3 Mapeamento espacial
Esta seção foi baseado no livro de Choset et al. Principles of Robot Motion: Theory,
Algorithms, and implementations. MIT Press Books, 2005.
Existe uma grande dificuldade em mapear espaços de configurações para os robôs e
desenvolver algoritmos de busca capazes de “explorar” o espaço livre ao procurar por um trajeto ou
realizar uma tarefa. Alguns algoritmos são limitados a espaços bidimensionais, mas será buscado
plataformas de robôs que são aplicadas a classes mais gerais de espaços de configuração,
9
principalmente as tridimensionais, necessárias ao projeto de robôs que se deslocam por terrenos
irregulares ou que utilizam o ar ou a água como meio de locomoção.
A função potencial é um exemplo de mapeamento espacial, sendo uma função de valor real
diferenciado, onde o valor da função potencial pode ser entendido como energia, e o gradiente
potencial pode ser visto como força. Usando a função potencial, o robô age como uma partícula que
se move em um campo do vetor do gradiente. Os gradientes podem ser vistos como a força que age
sobre o robô carregando positivamente a partícula para que seja atraída pelo objeto negativamente
carregada. Os obstáculos recebem também uma carga positiva de forma a repelir o robô para longe
dos mesmos. As combinações de forças atrativas e repulsivas dirigem o robô pelo trajeto, evitando
os obstáculos, conforme Figura 2.
Figura 2. Representação da trajetória do robô
Fonte: Choset et al. (2005).
Esse tipo de função trata de sistemas de primeira ordem, ou seja, sistemas que ignoram a
dinâmica. As funções potenciais podem ser vistas como paisagens, onde os robôs se movem de
locais com “altos valores” para locais de “baixo valor”, conforme ilustrado na Figura 3. Nenhuma
mudança dinâmica no ambiente é avaliada.
Um dos maiores desafios nas funções potenciais atrativas/repulsivas é determinar a posição
atual do robô e a sua localização global (em relação ao ambiente de interesse). Os dois métodos
mais utilizados para isso são a utilização de sensores e a utilização de uma grade contendo uma
10
imagem onde são computados os pixels e através disso calculada a distância entre o robô e os
objetos encontrados no ambiente.
O algoritmo de Brushfire é um método para computar a distância de uma representação do
mapa chamado de grade, que é uma disposição normalmente bidimensional dos elementos
espaciais, ou pixels. Atribui-se valor 0 (zero) a um pixel livre de obstáculo e valor 1 (um) se for
ocupado por um obstáculo. Então os pixels seguintes aos obstáculos recebem valores que são
incrementados conforme se afastam do obstáculo, até que todos os pixels com valor 0 (zero)
estejam preenchidos com valores maiores, que representam sua distância ao obstáculo mais
próximo. Com isso, um trajeto que evite a colisão implica seguir os pixels de maior valor, conforme
Figura 3.
Figura 3. Propagação do algoritmo do brushfire com
conexão de oito – ponto
Fonte: Choset et al. (2005).
Quando é necessário utilizar várias vezes o mesmo trajeto, faz sentido construir uma
estrutura de dados e usar essa estrutura para navegar com maior rapidez nos próximos trajetos. Essa
estrutura de dados é chamada frequentemente de mapa, e quando o robô não recebe essa informação
a priori, deve confiar em seus sensores para gerar um modelo do ambiente. Na construção de mapas
11
referentes à ambientes fechados deve-se levar em consideração três fatores: (i) topologias, que
visam representar objetos distintos no ambiente; (ii) modelos geométricos, usam os primitivos
geométricos para representar o ambiente; (iii) e as grades, que possuem uma estrutura similar a
grade de pixels, descrita anteriormente, onde cada parcela é preenchida com informações do espaço
de trabalho, conforme Figura 4.
O método de mapeamento (roadmap) exige uma representação explícita da geometria do
trajeto, o que o torna pouco prático devido ao tamanho que o mapa pode atingir. Para resolver esse
problema pode se utilizar um método baseado em amostragem, onde são empregadas várias
estratégias para gerar amostras e conectar essas amostras ao trajeto para obter as soluções desejadas.
Usam-se amostras aleatórias para se obter os nós e gerar as bordas do mapa. Mapas podem ser
representados internamente por estruturas de dados tipo grafos dirigidos. Depois que o mapa foi
gerado é verificado se as configurações correspondem às configurações iniciais definidas pelo
usuário e se o mapa atende seu objetivo. Também é possível fazer a combinação dos métodos, o que
em alguns casos pode ser desejável.
Figura 4. Diferentes formas de representar um ambiente: topológica,
geométrica e grades
Fonte: Choset et al. (2005).
Mapas rodoviários probabilísticos constroem um mapa probabilístico para o espaço de
trabalho dado, onde se pode supor que as configurações estão feitas de forma aleatória e
distribuídas uniformemente. As bordas correspondem aos trajetos e esses trajetos são consultados
como trajetos locais, que são computados por um planejador (de trajeto) local, que conecta duas
configurações por uma linha reta, se esta existir. Para resolver problemas individuais do trajeto
utilizando um mapa rodoviário, onde são informados os pontos inicial e final, o planejador busca
primeiramente conectar o ponto inicial ao ponto final, se bem sucedido então são geradas bordas
12
para o gráfico, e esta seqüência gerada será transformada em um trajeto praticável pelo robô. Os
trajetos locais podem ser armazenados no mapa rodoviário, mas este aumentaria as exigências de
armazenamento do mapa rodoviário.
Quando o problema envolve o trajeto para múltiplos robôs, é necessário que o robô
verifique, a cada etapa, se não há colisão entre o robô e um obstáculo ou entre o robô e outro robô.
As soluções apresentadas anteriormente podem ser utilizadas também para casos envolvendo
múltiplos robôs, sendo necessárias apenas pequenas mudanças. A cooperação entre os robôs exige
não apenas o cálculo de trajetórias sem colisões para cada robô, mas um nível estratégico mais
abstrato e complexo.
2.2 AUTOMAÇÃO E CONTROLE DE SISTEMAS
2.2.1 Controladores
O controle automático de sistemas representa um avanço muito importante na engenharia e
na ciência, e tem permitido o desenvolvimento de inúmeros novos processos e equipamentos em
diversos segmentos da atividade humana, incluindo indústrias (produção, automotiva, etc), robótica,
sistemas militares e vários outros. A automatização do controle de sistemas possibilita maior
desempenho e confiabilidade na execução de tarefas complexas, perigosas ou mesmo enfadonhas e
repetitivas. Controlar significa medir o valor de uma ou mais grandezas de interesse no sistema e
aplicar uma ação manipuladora ao sistema para corrigir ou limitar o desvio do valor medido para o
valor desejado (OGATA, 1990).
Assim, um sistema de controle automático deve manter uma ou mais grandezas físicas sob
controle, ou seja, com valores desejados pelo usuário. Ao valor desejado para uma grandeza física,
denomina-se valor de referência. As grandezas físicas a serem controladas são denominadas
variáveis de controle (ex: temperatura, pressão, etc). Para poder modificar as variáveis de controle
num sistema qualquer, o controle automático precisa influenciar essas grandezas físicas, o que é
feito com o auxílio de atuadores (ex: compressores, motores, etc). Ao ato de influenciar uma
variável de controle no sistema controlado através de um atuador, denominamos ação de controle.
O sistema sob controle, que pode ser um equipamento, ambiente ou processo, é denominado planta.
A planta sofre a influência de diversos fatores externos que tendem a afetar adversamente o valor
das variáveis de controle. A esses fatores externos indesejados, denominamos perturbações. Se a
planta sofrer muitas perturbações e o sistema de controle não for capaz de medir tais desvios em
13
relação ao valor de referência, a ação de controle pode ser incorreta e não haverá um controle
eficiente. Para realizar medições das variáveis de controle com o objetivo de ajustar a ação de
controle, utilizam-se sensores (ex: termopar, LDR, microfone, etc) (OGATA, 1990; PHILLIPS;
HARBOR, 2000).
2.2.2 Sensores
Conforme Pazos (2002), os sensores são dispositivos que entregam um sinal elétrico
proporcional a uma grandeza física mensurada. Outra forma de se definir sensores é como sendo
dispositivos que mudam seu comportamento quando sofrem a ação de uma grandeza física,
podendo fornecer de maneira direta ou indireta um sinal que indique essa grandeza. Os que agem de
maneira direta são aqueles que convertem uma forma de energia neutra, também são chamados de
transdutores, e aqueles que agem de maneira indireta alteram as propriedades como a resistência, a
capacitância ou a indutância, sob a ação de uma grandeza, de maneira mais ou menos proporcional.
Sensores são a única maneira pelo qual um robô é capaz de obter informações sobre o
ambiente que o cerca. Para que o ele possa compreender adequadamente esse ambiente, costuma ser
necessária a utilização de diversos tipos de sensores. A seguir são apresentados alguns exemplos de
sensores.
Sensores de temperatura são sensores capazes de medir ou detectar mudanças de
temperatura e produzir um sinal elétrico em função dessa medição ou mudança. Os principais
sensores de temperatura são: (i) par bimetálico; (ii) sensores de resistência elétrica; (iii)
termistores; (iv) junções semicondutoras; (v) termocuplas ou termopares.
Sensores de distância têm como função permitir a um controlador saber a distância entre o
dispositivo e um objeto de certa natureza. Para exercer essa função existem muitos sensores de
“presença” ou “distância”, como: (i) switches, que detectam colisão; (ii) reed switches, que
detectam campo eletro-magnéticos; (iii) sensores óticos, conforme exemplo na Figura 5, que ilustra
um sensor de barreira, onde um emissor envia um sinal a um recepitor, quando este sinal é
interrompido por algum objeto então o receptor envia um sinal ao controlador; (iv) sensores
indutivos; (v) sensores capacitivos, que detectam a aproximação de um objeto.
14
Figura 5. Sensor ótico de barreira
Fonte: Pazzos (2002).
Sensores de posição são utilizados para determinar a posição de um objeto em relação ao
dispositivo. O método empregado para o monitoramento da posição depende de uma série de
fatores, destacando-se: o tipo de movimento a ser realizado, a faixa de movimento possível e
também o tipo de atuador (PAZOS, 2002). Os sensores de posição mais conhecidos são: (i)
sensores potenciômetros; (ii) transformador linear diferencial variável; (iii) sensor capacitivo;
(iv) encoders; (v) sensores de ultra-som; (vi) sincros.
Sensores de força, também conhecidos como extensômetros, servem para medir a extensão,
ou deformação, que sofre uma peça quando é submetida a uma força axial ou tensão (PAZOS,
2002).
Sensores de velocidade são mecanismos utilizados para avaliar uma grandeza física que é
derivada da posição com respeito ao tempo, levando em consideração os ruídos de baixa amplitude,
mas alta freqüência. Os sensores de velocidade mais utilizados são: (i) tacômetros; (ii) encoders.
Sensores de luz têm como objetivo medir a quantidade de luz num determinado ambiente,
sendo o resistor dependente da luz o mais utilizado. Ele utiliza o princípio fotoelétrico, que consiste
na utilização de alguns materiais sensíveis à luz, como o sulfato de cádmio, para gerar energia
elétrica (PAZOS, 2002).
Sensores de som são mecanismos que traduzem uma onde mecânica que se propaga pelo ar
em um sinal elétrico equivalente, sendo o microfone o sensor de som mais simples e mais utilizado
(PAZOS, 2002).
Os sensores apresentam um conjunto de características principais e especificações como: (i)
faixa, que são todos os níveis de amplitude da grandeza física medida nos quais se supõe que o
sensor pode operar dentro da precisão especificada; (ii) resolução, que é o menor incremento da
grandeza física medida e que provoca uma mudança no sinal de saída do sensor; (iii) sensibilidade,
que é a relação entre o sinal elétrico entregue na saída e a grandeza física medida; (iv) linearidade,
15
estabelecida pelas variações obtidas quando variações iguais da grandeza física medida produzem
variações iguais no sinal entregue; (v) exatidão ou erro, que é a diferença absoluta entre o valor
real do sinal de saída entregue pelo sensor e o sinal que este deveria fornecer para esse valor de
grandeza física, podendo representar o erro dividindo essa diferença pela faixa; (vi) Relação sinal/
ruído, é a relação entre a potência de um sinal qualquer entregue na saída do instrumento e a
potência do sinal de ruído, medida como o sinal de saída com informação de entrada nula. Pode-se
observar também que a maioria das grandezas físicas é analógica e, portanto, com a utilização de
um controlador digital será necessário um conversor Analógico/Digital na entrada dele (PAZOS,
2002).
2.2.3 Atuadores
Segundo Pazzos (2002), atuadores são dispositivos que traduzem um determinado tipo de
energia em algum outro tipo de energia diferente. Nesse sentido, também são transdutores, como os
sensores. Entretanto, ao contrário deles, os atuadores convertem a energia de modo a modificar uma
grandeza física sobre o ambiente, e não obter informações sobre ela. Alguns exemplos de atuadores
incluem os motores (que entregam energia mecânica), resistores (térmica), lâmpadas (energia
luminosa), pistões (mecânica), eletroímãs (mecânica), etc. Eles geralmente ficam dentro de uma
estrutura física e proporcionam movimento, calor ou um outro tipo de energia, possibilitando seu
funcionamento.
Os motores elétricos são dispositivos que transformam energia elétrica em energia
mecânica. Existem vários tipos de motores elétricos, incluindo os motores AC (Corrente Alternada),
que operam com corrente alternada, e os motores DC (Corrente Direta ou Contínua), que operam
com corrente continua, sendo este último o mais utilizado em projetos de robótica. Existem vários
tipos de motores de corrente contínua, como os motores de série, os motores paralelos, os motores
compostos e os motores com imã permanente. Outro tipo de motor de corrente contínua que merece
certo destaque são os motores-de-passo, que produzem uma saída em forma de incrementos
angulares, controlados por pulsos elétricos do sinal de alimentação, onde cada pulso corresponde a
um ângulo fixo de rotação. Isso os torna precisos e recomendados para aplicações que necessitem
de ajustes precisos de posição, mas que não necessitem de grande torque.
Atuadores hidráulicos têm como objetivo gerar um movimento, que pode ser linear ou
rotativo, e consiste na introdução de um líquido de alta pressão num recipiente perfeitamente
16
selado, a fim de evitar vazamento, onde se localiza a haste ou o eixo, sendo que a passagem do
liquido gera a movimentação deste.
Atuadores pneumáticos são basicamente como os dispositivos hidráulicos, com a diferença
que o fluido utilizado não é liquido e sim ar comprimido (PAZOS, 2002).
2.2.4 Sistemas Embarcados
Sistemas embarcados, segundo Wayne Wolf (2001), são definidos como “qualquer
dispositivo que inclui um computador programável, mas que não seja ele próprio um computador de
propósito geral”. Estes sistemas interagem com o ambiente a sua volta por meio de sensores e, por
estarem sempre interagindo com o ambiente, requerem dos projetistas conhecimentos não apenas de
programação, mas também noções sobre controle de processos, sistemas em tempo real e as
tecnologias que serão aplicadas para a aquisição de dados, e exigem um cuidado especial referente à
eficiência do código produzido. Hoje já pode-se encontrar sistemas embarcados em quase todas as
áreas de atividade humana, como em aeronaves, indústrias, telefones celulares, impressoras,
eletrodomésticos, etc. Por possuir um sistema computacional de propósito específico que obtém
dados do ambiente e atua sobre ele, um robô é também um sistema embarcado, e por isso, seu
desenvolvimento deve seguir alguma metodologia de desenvolvimento de sistemas embarcados.
2.3 SIMULADORES DE ROBÔS
2.3.1 Simulador Khepera
O simulador do Robô Khepera foi desenvolvido na universidade de Nice Sophia, por Oliver
Michel. Ele é um programa do tipo freeware e que pode ser adquirido gratuitamente no site do robô
Khepera (http://diwww.epfl.ch/lami/team/michel/khep-sim/).
Ele foi desenvolvido para desenvolver os algoritmos de controle utilizando a linguagem C
ou C++ e conta com uma biblioteca de funções para realizar a movimentação do robô e obter os
resultados. Sendo caracterizado pela habilidade de dirigir um robô Khepera real, sendo facilmente
transferidos os resultados das simulações a um robô real.
O simulador funciona numa estação de trabalho que utilize o Sistema Operacional Unix e
apresenta uma interface gráfica colorida e agradável. Sendo que a tela do simulador Khepera se
17
divide em duas partes: (i) a primeira é a parte que está à esquerda e representa o Ambiente, onde é
possível visualizar o comportamento do robô em seu ambiente; (ii) a segunda parte que está a
direita representa o Robô, onde pode-se observar o que está ocorrendo internamente no robô
(sensores, motores e controladores), conforme Figura 6.
O simulador conta com vários ambientes de simulação já disponíveis em seus diretórios, que
podem ser utilizados para a realização das simulações. Sendo que o simulador também permite ao
usuário a edição e criação de novos ambientes de simulação.
O robô móvel simulado pelo simulador Khepera conta com oito sensores infravermelhos,
para a detecção de objetos e medir o nível de luz do ambiente. E usa modelos de motores simulados
diretos, movendo-se de acordo com a velocidade estipulada pelo usuário.
Figura 6. Tela do Simulador Khepera
Fonte: Michel (1997).
18
2.3.2 Robocode
O Robocode foi desenvolvido pela AlphaWorks, uma divisão da IBM que tem como
finalidade difundir novas tecnologias de desenvolvimento. O Robocode é um projeto hospedado
pela SourceForge e pode ser encontrado em http://robocode.sourceforge.net/. A idéia básica é
fornecer um ambiente de simulação de batalhas entre robôs que execute em qualquer plataforma
Java. O usuário utiliza as classes básicas disponíveis pelo ambiente para criar um robô e colocá-lo
em batalha contra outros robôs criados por outros desenvolvedores. Com ele é possível aprimorar
conceitos como herança, polimorfismo, eventos, entre outros (ROBOCODE, 2006), além de servir
para testes de heurísticas de combate e de movimentação.
No Robocode, um robô é composto por: (i) um veículo, que provê movimentação e rotação
ao robô; (ii) um canhão, que serve para atacar os robôs inimigos; (iii) um radar, que é utilizado
para localizar outros robôs no campo de batalha e que pode movimentar-se de forma independente
do canhão, conforme Figura 7. E tem como restrições: (i) energia, que é utilizada para realizar as
operações no robô e nos disparos, onde é possível se definir a quantidade de energia que será
utilizada e sendo recuperada quando se acerta o outro robô; (ii) calor, onde um canhão só dispara
quando seu calor estiver em zero e o calor produzido é proporcional à potência do disparo.
Figura 7. Anatomia de um robô
Fonte: Sourceforge (2007).
O Robocode apresenta certas características físicas, como: (i) tempo, que é medido no
Robocode através dos “ticks” que são equivalentes aos frames, que são os quadros do jogo por
segundo, iniciados na tela; (ii) distância, a distância é medida através dos pixels, com duas
exceções, a primeira as distâncias são medidas com precisão “double”, permitindo que se possa
mover uma fração de um pixel e o Robocode altera automaticamente a escala para que as mesmas
19
possam caber na tela, sendo neste caso a unidade de medida menor que um pixel; (iii) aceleração
do robô é feita na taxa de 1 pixel/tick e a desaceleração na taxa de 2 pixel/tick, sendo que o
Robocode determina automaticamente a aceleração baseado na distância que se pretende
movimentar o robô; (iv) velocidade é representada por uma equação v=em, sendo que a velocidade
máxima não pode exceder 8 (SOURCEFORGE, 2007).
Os principais comandos do robô são apresentados no Quadro 1.
AÇÃO DO ROBÔ MÉTODO Virar o robô turnRight(double degree), turnLeft(double degree) Move o robô e finaliza caso bata em uma parede
ahead(double distance), back(double distance)
Virar o canhão independente do veiculo
turnGunRight(double degree), turnGunLeft(double degree)
Se verdadeiro, vira o canhão junto com o veículo
setAdjustGunForRobotTurn(boolean flag)
Se verdadeiro, vira o radar junto com o veículo
setAdjustRadarForRobotTurn(boolean flag)
Se verdadeiro, vira o radar junto com o canhão
setAdjustRadarForGunTurn(boolean flag)
Quadro 1. Principais comandos do robô
Os principais eventos utilizados pelo robô são descritos no Quadro 2.
DESCRIÇÃO MÉTODO Chamado quando o robô é detectado pelo radar
onScannedRobot(ScannedRobotEvent)
Chamado quando o robô é atingido por uma bala
onHitByBullet(HitByBulletEvent)
Chamado quando a colisão entre robôs onHitRobot(HitRobotEvent) Chamado quando o robô colide com uma parede
onHitWall(HitWallEvent)
Quadro 2. Eventos utilizados pelo robô
As funções para se obter informações são descritas no Quadro 3.
DESCRIÇÃO MÉTODO Coordenada corrente do robô get x(), get y() Direção corrente getHeading(),getGunHeading(),getRadarHeading() Dimensão do campo de batalha getBattleFieldWidth() and getBattleFieldHeigth() Quadro 3. Funções para obter informações
20
A Figura 8 apresenta um exemplo de código, para a implementação de um robô:
package man;
import robocode.*;
public class MyFirstRobot extends Robot
{
public void run () {
while (true) {
ahead (100);
turnGunRigth (360);
back (100);
turnGunRigth (360);
}
}
public void onScannedRobot (ScannedRobotEvent e) {
fire (1);
}
}
Figura 8. Meu primeiro Robô
Fonte: Sourceforge (2007).
Os robôs comuns executam apenas uma coisa de cada vez, mas é possível criar robôs mais
avançados, em que ações assíncronas são definidas e executadas, e permanecerem em execução
paralelamente a outras possíveis ações. As principais vantagens nesse tipo de programação são: (i)
execução de múltiplos movimentos simultâneos; (ii) pode-se definir uma estratégia diferente a cada
tique do relógio; (iii) pode-se definir eventos customizados.
Existe também a opção de se criar uma equipe de robôs cooperantes, no qual os robôs
podem trocar mensagens entre si através dos métodos broadcastMessage (Serializable msg) e
onMessageReceived (MessageEvent event).
2.3.3 Simulador Simbad
O Simbad é um projeto Open Source (tipo de software cujo código fonte é visível
publicamente), que utiliza a plataforma JAVA 3D e tem como objetivo gerar um ambiente para
simulação de robôs que forneça aos desenvolvedores uma base simples para estudos na área de
Inteligência Artificial, no contexto de robótica autônoma e Agente autônomos (SIMBAD,2007).
Conforme Hugues e Bredeche (2006), o Simbad tem dois pacotes adicionais: (i) o
PicoNode, contendo bibliotecas de Redes Neurais (feed-forward NN, NN recorrentes, etc); (ii) e o
21
PicoEvo, uma estrutura de evolução artificial para algoritmos genéticos, estratégias evolutivas e
programação genética. Estes pacotes são direcionados para robôs evolutivos.
O pacote Simbad possui um simulador de robôs móveis com complexa modelagem de cena
em 3D (simbad), uma biblioteca de Redes Neurais (feed-forward NN, NN recorrentes), bem como
uma completa biblioteca de algoritmos evolutivos (algoritmo genético, estratégia evolutiva,
programação genética com árvores ou grafos). Todas as ferramentas foram escritas para serem
eficientes e fáceis de usar por programadores em Java e ou Python, permitindo a eles escrever seus
próprios controladores de robôs, modificar o ambiente e utilizar os sensores disponíveis ou
construir novos sensores (HUGUES; BREDECHE, 2006).
O Simbad está disponível a partir do site http://simbad.sourceforge.ner/ sob as condições da
GLP (GNU General Public Licence) e necessita da plataforma Java (versão 1.4.2 ou superior) e Sun
Java 3D (versão 1.3.1 ou superior). Estes dois componentes estão disponíveis para uma ampla gama
de plataformas (Windows, Mac OS X, Linux, IRIX, AIX). Após ter instalado e configurado o java
de acordo com o sistema operacional e instalado o Java 3D, basta executar o comando java –jar
simbad-[versão].bin.jar, para executar o simulador (SIMBAD,2007).
Em relação à simulação, o usuário somente utilizará um ambiente derivado da classe
EnvironmentDescription e um controlador de robô derivado da classe Robot. Esta última tem um
método de inicialização (initBehavior) e um método a ser chamado a cada etapa da simulação
(performBehavior). Em seguida são executadas as ordens de controle motor de forma semelhante á
um verdadeiro controlador de robô, isto é, repetitivas chamadas para o micro-controlador
(HUGUES; BREDECHE, 2006).
F
F
Os princ
Define o tamanmundo. Cria um objetoClasse que auxsensores. Define a velocmetros por segDefine a velocpor segundo. Retorna a posiQuadro 4. Princ
Após a
utilização do R
disponível, o q
eventos (exceç
22
igura 9. Interface do simulador Simbad
onte: Hugues e Bredeche (2006)
ipais funções disponibilizadas pelo Simbad são descritas no Quadro 4.
DESCRIÇÃO MÉTODO ho do quadro que receberá o
setWorldSize(float size)
caixa no ambiente. Box(Vector3d, Vector3f, EnvironmentDescription) ilia na construção de robôs e
RobotFactory()
idade translacional em undo.
setTranslationalVelocity(double tv)
idade rotacional em radianos setRotationalVelocity(double rv)
ção do robô em coordenadas. getCoords(javax.vecmath.Point3d coord) ipais funções disponibilizadas pelo Simbad
nálise dos dois primeiros simuladores apresentados, inicialmente optou-se pela
obocode, pois ele é desenvolvido em java (multiplataforma); possui o código-fonte
ue permite mudar características do ambiente e do robô; permite capturar e gerar
ões), simulando eventos do ambiente e novos sensores e permite a comunicação
23
entre robôs. Essas características não estão presentes no Simulador Khepera, já que o mesmo
necessita de um Sistema Operacional Unix; não tem seu código-fonte disponibilizado, não sendo
possível sua adaptação para outros tipos de robôs ou a inclusão de novas funções, estando
obrigatoriamente ligado ao próprio robô Khepera.
Entretanto, durante o decorrer do projeto foram encontradas algumas dificuldades no
desenvolvimento do código e principalmente em relação à simulação do ambiente, deixando claro
que, apesar de ser um bom simulador, o Robocode não seria o mais adequado para este projeto. Isso
levou à escolha pelo Simulador Simbad, que apresenta as mesmas características do Robocode, mas
possui recursos avançados para simulação do ambiente usando a plataforma Java 3D e um número
maior de sensores disponíveis em sua biblioteca.
2.4 TEORIA DOS GRAFOS
2.4.1 Definições
A mais antiga menção de grafos que se tem conhecimento ocorreu em 1736, num trabalho
de Euler, considerado como uma “frívola adivinhação”. Ele baseia-se em um desenho onde todos os
caminhos devem ser percorridos sem que se tire o lápis do papel e sem passar duas vezes sobre a
mesma linha. No problema que também ficou conhecido como as pontes de Königsberg, os pontos
correspondiam às margens e as ilhas de um rio e as linhas representavam as pontes. Euler então
provou que era impossível percorrer todos os caminhos passando apenas uma única vez sobre cada
ponte devido à disposição delas. E ainda no século XIX, Kirchhoff e Cayley desenvolveram a teoria
das árvores. Outro jogo apareceu em 1859, proposto por Hamilton, onde o problema consistia em
percorrer as arestas de forma que cada uma fosse percorrida uma única vez. Em seguida surgiu o
problema das quatro cores, onde Appel e Haken provaram que qualquer mapa poderia ser
preenchido utilizando somente quatro cores e sem que dois paises adjacentes ficassem com a
mesma cor. A teoria dos grafos teve seu avanço principalmente após as décadas de 40 e 50, quando
surgiram os primeiros computadores, e o estudo da teoria dos grafos acelerou e se tornou uma dos
principais instrumentos de esquematização de problemas (RABUSQUE, 1992).
Conforme Choset et al. (2005), um grafo é um conjunto de vértices e arestas, que pode ser
representado por um conjunto G=(V,E), onde G representa o grafo, V representa o conjunto de
vértices e E representa o conjunto de arestas. Em um planejamento de caminho, um vértice
representa uma posição, e uma aresta conecta dois vértices que possuem um relacionamento
24
relevante (como uma conexão física que pode ser percorrida pelo robô). Podemos também atribuir
valores às arestas que são chamados de pesos. Uma aresta é dita incidente com os vértices que ela
liga, sendo esta aresta denominada laço quando está ligada a apenas um único vértice e dois vértices
são adjacentes quando estão ligados por uma aresta. E quando não existe aresta atuando sobre um
vértice ele é chamado de isolado. Quando as arestas de um grafo possuem direção ele é chamado de
dígrafo ou grafo dirigido, se não houver orientação o grafo é chamado de não dirigido (Figura 10).
Figura 10. Grafo dirigido (à esquerda) e não dirigido (à direita)
Fonte: Choset et al. (2005).
Uma árvore é um grafo dirigido conectado sem nenhum ciclo, e tem um vértice especial
chamado raiz, que é o único que não possui nenhum entrante. Pode-se comparar a raiz com o pai e
os vértices que estão abaixo dele são os filhos, sendo que um vértice sem filhos é chamado de
folha. Uma busca em profundidade começa pela raiz, escolhe um vértice filho e vai para o filho
deste, assim sucessivamente até encontrar uma folha ou o vértice desejado. Se ele encontrar uma
folha ele retorna ao vértice anterior e percorre os vértices filhos deste até encontrar o nó desejado ou
chegar a uma folha, repetindo esse processo até que o vértice desejado seja encontrado ou todos os
caminhos sejam percorridos. A busca em largura é o contrário; a busca começa pela raiz e visita
todos os vértices filhos da raiz primeiro, depois todos os vértices filhos. Partindo do princípio que o
nó desejado estaria mais próximo à raiz, fazendo que a busca necessite de menos tempo (CHOSET
et al., 2005).
Uma grade produz um grafo onde cada vértice corresponde a um pixel e uma aresta conecta
um vértice aos pixels vizinhos. Uma conexão de quatro pontos liga apenas os pixels do norte, sul,
leste e oeste, enquanto uma conexão de oito pontos ligará todos os pixels vizinhos. O grafo que
representa uma grade não é uma árvore (CHOSET et al., 2005).
Um algoritmo deve procurar sempre o melhor tipo de busca para cada caso, pois uma
escolha errada pode fazer com que o caminho seja encontrado, mas a um custo computacional mais
alto que o necessário, o que pode tornar inviável sua utilização (CHOSET et al., 2005).
Denomina-se distância o menor caminho entre dois vértices, e caso esse caminho não exista
a distância entre eles é tida como infinita (RABUSQUE, 1992).
2.4.2 Representação para Grafos
A forma mais conhecida de representação de um grafo é através do desenho de pontos e
linhas, mas em um computador o grafo pode ser representado de várias maneiras e a eficiência do
algoritmo vai depender da escolha certa na forma de representar o grafo (RABUSQUE, 1992).
Algumas formas conhecidas de se representar computacionalmente um grafo são: (i) matriz
de adjacência; (ii) matriz de custo; (iii) lista de arestas; (iv) estrutura de adjacência; (v) e a
matriz de incidência.
2.4.3 Tipos de Grafos
Um grafo G (V,E) é chamado de conexo se há pelo menos uma cadeia ligando cada par de
vértices deste grafo, conforme Figura 11 (MARIANI, 2007).
Figura
Fonte: M
em rela
ser uma
25
11. Grafo conexo
ariani (2007).
Um grafo G (V,E) desconexo é formado por pelo menos dois subgrafos conexos, disjuntos
ção aos vértices e maximais em relação a inclusão. Cada um destes subgrafos conexos é dito
componente conexo de G, conforme Figura 12 (MARIANI, 2007).
26
Figura 12. Grafo Desconexo
Fonte: Mariani (2007).
Um grafo G (V,E) desconexo é formado por pelo menos dois subgrafos conexos, disjuntos
em relação aos vértices e maximais em relação à inclusão. Cada um destes subgrafos conexos é dito
ser uma componente conexo de G, conforme Figura 13 (MARIANI, 2007).
Figura 13. Componente conexo
Fonte: Mariani (2007).
Em grafos orientados, que são grafos em que os vértices possuem informações adicionais
como, por exemplo, a direção que devem seguir, um grafo é chamado de fortemente conexo se
cada par de vértices estiver ligado por pelo menos um caminho em cada sentido, ou seja, qualquer
vértice pode ser alcançado partindo-se de qualquer outro vértice do grafo, conforme Figura 14
(MARIANI, 2007).
27
Figura 14. Grafo fortemente conexo
Fonte: Mariani (2007).
Em um grafo G (V, E) que não é fortemente conexo é formado por pelo menos dois
subgrafos fortemente conexos, disjuntos em relação aos vértices e maximais em relação a inclusão.
Cada um desses subgrafos é chamado de componente fortemente conexo de G, conforme Figura
15 (MARIANI, 2007).
Figura 15. Componente fortemente conexo
Fonte: Mariani (2007).
Um vértice é chamado de vértice de corte quando a remoção deste (junto com as arestas a
que ele se conecta) causa uma redução na conexidade do grafo (MARIANI, 2007).
Uma aresta é chamada de ponte se sua remoção provoca uma redução na conexidade de um
grafo (MARIANI, 2007).
28
2.4.4 Caminhamento em Grafos
Supondo um mapa rodoviário em que as cidades são representadas por pontos e as estradas
por linhas, podemos então considerá-lo um grafo, modelando as cidades por vértices, as estradas
por arestas e as distâncias como pesos das arestas. O problema é encontrar a menor distância entre
dois pontos. Existem alguns exemplos que demonstram esse tipo de problema, como o problema do
carteiro chinês, ilustrado na Figura 16, que consiste em um grafo de uma rede rodoviária em que é
necessário determinar o custo do menor caminho partindo de um vértice inicial, percorrendo todos
os vértices uma única vez e retornando ao ponto de origem (RABUSQUE, 1992).
Algoritmo : Carteiro chinês
Entrada: grafo G (V,E).
Saída: menor caminho passando por todo grafo e seu custo.
P1- Determinar os vértices de grau impar;
P2- Construa a matriz de distância D, com apenas os vértices de grau impar;
[utiliza o algoritmo de Dijkstra para determinar a matriz D].
P3- Determinei, através da matriz D, o par de vértices Vi e Vj que contém o
menor caminho;
P4- construa um caminho artificial de Vi para Vj com o custo encontrado em P3;
[Este caminho artificial representa as arestas de menos custo que serão
repetidas entre Vi e Vj].
P5- Elimine da matriz D as linhas e colunas correspondentes a Vi e Vj;
P6- Se ainda houver linhas e colunas, então volte para P3;
P7- Oriente o garfo;
P8- O custo será igual à soma dos custos de todas as arestas acrescidas dos
custos das arestas encontradas em P3;
Figura 16. Algoritmo do Carteiro Chinês
Fonte: Rabusque (1992).
Outro problema conhecido é o do caixeiro viajante, que também consiste em determinar o
menor caminho passando por todos os vértices e retornando ao ponto inicial. Uma solução pare esse
caso é o método algébrico apresentado por Christofides, que envolve gerar todos os caminhos
simples por multiplicação sucessiva de matriz (RABUSQUE, 1992).
Se o objetivo for encontrar o menor caminho entre dois vértices sem restrições, então
podemos utilizar algoritmos como: (i) o algoritmo de Floyd, que é um algoritmo matricial, que
aceita valores negativos nas arestas, mas a possibilidade de ciclos absorventes exige precauções na
avaliação dos resultados; (ii) algoritmo de Dijkstra, tendo um grafo G(V,E) e uma função
distância L que associe cada aresta (v,w) a um número real não negativo e também um vértice fixo
chamado fonte. O problema consiste em determinar um caminho de Vo para cada vértice v de G, de
29
tal forma que a somatória das distâncias das arestas envolvidas em cada caminho seja mínima
(RABUSQUE, 1992).
2.4.5 Caminho Crítico
O caminho crítico é utilizado para administrar grandes projetos que possuam um grande
número de atividades e que geram problemas complexos no planejamento, coordenação e controle,
especialmente quando precisam ser executados em uma seqüência especifica. O controle desses
projetos pode ser feito através de PERT (Program Evaluation and Review Tecnique), o qual leva
em conta os riscos de não completar em tempo ou não as várias atividades (RABUSQUE, 1992).
2.5 LÓGICA NEBULOSA
Os problemas no mundo real nem sempre podem ser representados através de limites pré-
definidos e absolutos como, por exemplo, zero ou um. Muitas vezes precisamos levar em
consideração certos graus de incerteza utilizando valores intermediários entre eles.
Segundo Lopes (1999), Lofti A. Zadeh desenvolveu a teoria dos conjuntos nebulosos, que
generaliza a teoria clássica da teoria dos conjuntos, permitindo que os objetos possuam graus de
pertinência a determinados conjuntos. Isso possibilita a representação de conceitos vagos e
imprecisos, mas mantém a precisão matemática no tratamento. Com isso é possível criar um
sistema inteligente capaz de imitar o comportamento de um ser humano.
Conforme Silva (2003), quando se utiliza a representação de Venn, tem-se dois conjuntos
distintos, infinitos e totalmente independentes, não sendo possível ter um número natural que não
seja nem par nem impar. Com isso, um número pertenceria ao conjunto de números pares ou ao de
ímpares, mas nunca aos dois. A teoria clássica dos conjuntos é aplicada perfeitamente a esse caso.
Mas na área de Inteligência Artificial frequentemente tem-se que lidar com situações vagas e
imprecisas, onde é necessário arrumar meios de imitar a capacidade humana de lidar com esses
problemas. Quando utilizamos à lógica nebulosa atribuímos valores de pertinência a esses
conjuntos; é possível representar variáveis imprecisas como baixo, mediano e alto.
Conforme Lopes (1999), algumas razões que justificam o uso da lógica nebulosa são: (i) os
conceitos matemáticos associados são simples; (ii) é flexível; (iii) é tolerante a dados imprecisos;
(iv) permite modelar funções não lineares de complexidade arbitrária; (v) pode ser construído
30
usando a experiência de especialistas; (vi) muitas vezes é a opção de controle mais simples; e (vii)
se baseia na linguagem natural, por isso suas bases são as mesmas da comunicação humana.
Segundo Silva (2003), algumas vantagens em se utilizar esse tipo de abordagem são: (i) os
conjuntos nebulosos podem ser construídos de uma forma muito mais intuitiva e natural, sem o total
conhecimento matemático do sistema com que se está tratando; (ii) trabalham com informações
imprecisas; (iii) uma solução pode ser alcançada por diferentes caminhos; (iv) é mais robusto pois a
falta de regras não necessariamente inviabiliza o resultado. Além disso ele também destaca, no caso
dos controladores automáticos, as seguintes vantagens: (i) ajustes podem ser feitos tanto nos
conjuntos quanto nas funções de pertinências (ajustes finos); (ii) a transição entre um nível e outro
de saída se dá de uma forma gradual e sem sobressaltos; (iii) apresentam bons resultados em
processos não lineares, entradas irregulares e restrições conflitantes; (iv) futuras alterações podem
ser feitas mais facilmente alterando-se as regras do sistema nebuloso. E destaca como desvantagens:
(i) dificuldade em se desenvolver um modelo a partir de um modelo nebuloso; (ii) não há uma
definição matemática precisa como em outros sistemas.
A lógica booleana é utilizada para problemas que onde a resposta pode ser representada
retornando valores 0 ou 1. Um conjunto nebuloso permite representar os valores compreendidos
entre 0 e 1, refletindo o grau em que o elemento pertence ao conjunto. Esses conjuntos permitem
várias operações, como: (i) a intersecção de conjuntos, onde dois conjuntos A e B têm como
resultado da intersecção deles exatamente aqueles elementos que estão contidos ao mesmo tempo
nos conjuntos A e B; (ii) união de conjuntos, tendo os conjuntos A e B então a união dos conjuntos
contêm todos os elementos contidos em A e B, (iii) negação de conjuntos, tendo um conjunto A
que pertence a um universo de discurso S, então, o conjunto resultante da negação de A é formada
por todos os elementos que pertencem ao universo de discurso S, mas que não pertencem ao
conjunto A (LOPES, 1999).
Segundo Lopes (1999), os especialistas podem expressar até os sistemas mais complexos em
forma de regras nebulosas e controles de pertinência. E elas são denominadas nebulosas porque não
retornam comandos em formas de sinais, mas na forma de ações, as quais podem ser definidas em
diferentes níveis. O controle automático é um processo complexo em que muitas vezes não se
conhece com precisão sua dinâmica. Assim, torna-se menos eficiente do que o controle feito por um
operador humano experimentado. A lógica nebulosa busca aumentar essa precisão através de um
algoritmo baseado nas experiências de um operador humano e que utilizam um conjunto de regras
lingüísticas para descrever a estratégia de controle a ser utilizada.
31
Um controlador nebuloso é formado por três partes básicas: (i) o nebulizador, responsável
por receber os valores referentes às leituras dos sensores e, através de um mapeamento, o valor da
variável é transferido ao correspondente universo de discurso; (ii) o mecanismo de inferência,
onde serão aplicadas as regras de controle sobre os valores obtidos; (iii) o desnebulizador, ele pega
a conclusão obtida no processo anterior e transforma num comando de controle que será enviado ao
atuador, conforme Figura 17.
Figura 17. Estrutura do controlador nebulosos
Fonte: Lópes (1999).
2.6 TRABALHOS RELACIONADOS
Nos últimos anos a área de robótica vem tendo um avanço considerável e muitas pesquisas
têm voltado seus esforços no que se refere à robótica móvel. Robôs móveis buscam autonomia para
tomar decisões e se orientar em ambientes estáticos e dinâmicos, sendo capazes de ultrapassar
obstáculos.
O laboratório de robótica móvel do instituto de sistemas e robótica de Coimbra, em
Portugal, está desenvolvendo um projeto de robôs cooperantes para patrulha de edifícios. O projeto
deverá ser capaz de construir um mapa da área a ser patrulhada, dividindo o território entre os robôs
disponíveis e detectando objetos e pessoas estranhas no ambiente. Para isso serão utilizados robôs
Scout da Nomadics com cinemática diferencial, dotado de comunicação sem fio, odometria,
sonares, visão estéreo, e eventualmente, um laser scanner (ROCHA, 2006).
Existem também grandes empresas investindo nessa área, como a empresa norte americana
VersaLogic, que lançou um robô destinado a substituir guardas humanos nas rondas em edifícios,
32
empresas e áreas de segurança em geral. O PatrolBot, como foi batizado, tem um processador
Pentium III, instalado numa placa do tipo single board computer, onde todos os componentes ficam
instalados em uma única placa. Ele também possui um sistema de navegação completo, incluindo
sensores laser, sonar, encoders nos eixos, sensores de colisão e sistemas de correção giroscópicos. É
capaz de criar em sua memória um mapa completo da sua área de atuação, e com a utilização dos
sensores ele sabe exatamente sua posição, o que permite que o mesmo se desloque com precisão de
um ponto a outro dentro do seu território. O PatrolBot utiliza o sistema operacional Linux, o que o
torna capaz de se comunicar através de rede sem fio, enviando imagens e sons para qualquer
computador da rede e tem um custo aproximado de U$ 30.000,00 (ROBÔ PATRULHEIRO, 2003).
A empresa japonesa Sogo Securities Service, também lançou, no final de novembro de
2006, um robô de guarda, desenvolvido para patrulhar o interior de edifícios, além de guiar
visitantes através de um monitor de cristal líquido montado em seu corpo. O Guardrobo D1, como
foi chamado, foi demonstrado num centro comercial de Tóquio e chamou a atenção das crianças.
Comandado por controle remoto, ele custa pouco mais de R$ 7.150,00 por mês (ROBÔ, 2006).
Durante a copa do mundo na Alemanha, também foram utilizados vários robôs para fazer a
segurança das ruas e dos estádios. Os “Ofro”, como foram chamados, fabricados pela Berlinense
Robowatch Tecnologies, são capazes de avançar por terrenos difíceis, subir escadas e detectar
armas, explosivos e pessoas. Ele pode identificar agentes químicos ou biológicos e movimento de
suspeitos num raio de 30 metros. A empresa possui pedidos de exemplares do Ofro em várias partes
do mundo (sendo alguns deles para fins militares) e seu custo varia entre 55.000,00 a 85.000,00
euros (ROBÔ, 2006).
Uma tecnologia que tem sido utilizada em robôs móveis para a sua orientação é a
combinação da informação azimutal absoluta com a odométria relativa, o que permite se locomover
por um determinado local e retornar ao ponto de partida com uma precisão considerável e um baixo
custo. Um exemplo disso é o robô Bulldozer IV, desenvolvido em conjunto por três universidades e
foi o campeão do concurso micro ratos 2001, em que o robô teve que percorrer um labirinto
desconhecido e regressar ao ponto de partida, executando esta tarefa por duas vezes num percurso
de 25 metros e voltando a primeira posição, parando a menos de 25 centímetros do ponto inicial
(SANTOS; SILVA; ALMEIDA, 2002).
Para a percepção da localização de robôs autônomos, uma das soluções mais fáceis é a
utilização de GPS (Sistema de Posicionamento Global), através do qual se pode obter a posição
absoluta do robô em relação à Terra. Entretanto, atualmente, o mesmo apresenta uma variação de
cerca de 5 metros, sendo necessários receptores diferenciados para transformar esta diferença em
33
alguns centímetros. Infelizmente esses receptores são, em sua maioria, muito volumosos e caros. A
bússola digital, por outro lado, é uma alternativa mais acessível, mas, contudo, ela por si só não
permite a realização de um sistema de orientação, pois apenas fornece informações azimutais e
apresenta suscetibilidade a interferências externas. Para a realização deste sistema de orientação é
necessário a utilização da odometria, que consiste na medição da distância relativa percorrida e é
normalmente efetuada com codificadores rotativos (encoders). Esses sistemas de odometria têm
como característica um erro cumulativo, principalmente em dispositivos ligados às rodas
(SANTOS; SILVA; ALMEIDA, 2002).
Outra solução que vem sendo utilizada por pesquisadores é a utilização de um sistema de
visão computacional, que consiste em uma câmera digital que capta imagens do ambiente e envia
para um computador que as analisa, retornando a posição do robô e de outros objetos estranhos ao
ambiente através de rádio-freqüência. A FURB (HUBNER, 2003), UFPR (KAICK, 2003) e a USP
(BIANCHI; REALI-COSTA, 2000), desenvolveram projetos utilizando esta tecnologia para criar
um time de futebol de robôs para participar de competições nesta categoria, sendo utilizado um kit
de robótica Lego para a construção do robô utilizado pela FURB.
Pode-se também utilizar sonares de ultra-som para a movimentação de robôs. Com ele é
possível criar um mapa virtual do local de atuação do robô encontrando obstáculos a serem
transpostos. O sensor pode ter sua profundidade máxima determinada pela posição em que ele é
montado, sendo que o som se dispersa em formato de cone com abertura de 30º e, caso seja
montado numa altura relativamente baixa, (menor que 2,5m) ele irá sofrer uma reflexão do chão,
alterando a profundidade máxima a ser obtida pelo sensor. Este método é um tanto falho devido à
imprecisão inerente no uso de sonares para detecção de obstáculos, mas é uma boa alternativa para
ser utilizado de maneira híbrida com outros sensores (OTTONI; LAGES, 2003).
34
3 DESENVOLVIMENTO
Neste capítulo é apresentado o projeto e a implementação do sistema. O projeto contém uma
descrição da análise de requisitos, suas especificações e a modelagem do sistema, e na
implementação são apresentados os aspectos referentes à materialização e validação do sistema.
A modelagem foi feita utilizando a UML, que é uma linguagem de modelagem padronizada
para engenharia de sistemas orientados a objeto e que possibilita um melhor entendimento de suas
funções através de diagramas. Nas próximas seções serão apresentados os requisitos funcionais, as
especificações e os diagramas que representam este projeto.
3.1 PROJETO
3.1.1 Análise de Requisitos
Os requisitos funcionais descrevem as funcionalidades que o sistema deverá possuir, ou seja,
o que ele faz. Esses requisitos serão melhor descritos na especificação do sistema.
• RF01: Se locomover sem a ajuda humana;
• RF02: Atuar em modos de operações diferentes;
• RF03: Receber parâmetros determinando sua área de patrulhamento;
• RF04: Aprender os caminhos para se alcançar um ponto dentro de sua área de atuação;
• RF05: Desviar de obstáculos;
• RF06: Localizar alterações no ambiente;
• RF07: Distinguir entre o pessoal autorizado e não autorizado;
• RF08: O robô deverá possuir uma interface que possibilite a comunicação com outros
robôs ou com uma central;
• RF09: Receber ordens de outros robôs, assim como de uma central;
• RF10: Enviar um sinal informando a central sobre qualquer alteração encontrada; e
• RF11: Determinar sua posição dentro do ambiente que está patrulhando.
35
3.1.2 Especificação dos Requisitos Funcionais
As especificações são informações mais detalhadas sobre os requisitos funcionais e contêm
informações importantes para o sistema. Os itens abaixo descrevem as especificações deste sistema:
• Se locomover sem a ajuda humana: o robô possui uma série de sensores, através dos quais
ele consegue captar o ambiente a sua volta, estas informações são repassadas a um
estrategista, que com o auxílio de um controlador Fuzzy processa estas informações e
determina a ação a ser executada pelo robô, fazendo com que o mesmo seja totalmente
independente;
• Atuar em modos de operações diferentes: o robô possui uma classe estrategista, que utiliza
um controlador Fuzzy para avaliar as informações coletadas pelos sensores e processar estas
informações seguindo uma serie de regras já pré-definidas e então retorna o modo de
operação correspondente à ação que deverá ser executada pelo robô. Foram implementados
os seguintes modos: (i) Fire: utilizado quando o robô encontra uma temperatura muita
elevada em algum ambiente, indicando possível incêndio; (ii) Follow: utilizada quando o
robô deve seguir em frente (continuar andando); (iii) Divert: utilizada quando o robô está
muito próximo de um objeto ou de algum obstáculo que impeça sua passagem e necessita
desviar; (iv) Check: utilizado para verificar uma variação fora do comum nos sensores; (v)
Accelerate: utilizado para aumentar a velocidade do robô caso não haja nenhum obstáculo
próximo e o mesmo esteja devagar; (vi) Breaking: utilizado para reduzir a velocidade do
robô quando está próximo a um obstáculo; (vii) Goto: utilizado para deslocar o robô até uma
determinada posição;
• Receber parâmetros determinando sua área de patrulhamento: o robô possui um sensor,
onde a área de patrulhamento está pré-definida, e lhe informa quando está em um local que
não faz parte do seu roteiro;
• Aprender os caminhos para se alcançar um ponto dentro de sua área de atuação: o robô
possui um planejador de rotas, que utiliza o conceito de Grafo, para criar pontos (nós) e
armazenar a distância entre os pontos (arestas). Com a utilização do Algoritmo de Dijkstra
ele é capaz de determinar o menor caminho até o local desejado. Caso este caminho não
exista, ele retorna o ponto mais próximo conhecido do local desejado;
• Desviar de obstáculos: quando um sensor detecta algum obstáculo o estrategista é
informado e com o auxílio de um controlador Fuzzy ele avalia o quanto este obstáculo esta
36
próximo, caso a distância até este obstáculo seja pequena o robô então entre em modo de
operação Divert, para desviar do mesmo;
• Localizar alterações no ambiente: o robô possui vários sensores que retornam informações
referentes ao ambiente e que o permitem localizar alterações, como por exemplo, uma
variação na temperatura do local;
• Distinguir entre o pessoal autorizado e não autorizado: o robô possui um sensor que
informa o nível de segurança referente a região que esta sendo patrulhada e quando um outro
robô é localizado ele então compara o nível de segurança do local com o nível de
autorização do robô localizado;
• O robô deverá possuir uma interface que possibilite a comunicação com outros robôs ou
com uma central: o robô possui um comunicador, através do qual ele pode enviar e receber
mensagens para outros robôs e para uma central;
• Receber ordens de outros robôs, assim como de uma central: com a utilização do
comunicador o robô pode receber mensagens como “vá para o ponto : x, y, z.” e após
interpretar esta mensagem executar a ordem recebida;
• Enviar um sinal informando a central sobre qualquer alteração encontrada: com a
utilização do comunicador é possível informar a central de qualquer alteração relevante,
como por exemplo quando o robô detecta uma temperatura muito alta em um ambiente o
mesmo entra em modo Fire, repassando esta informação a central juntamente com a
localização do local onde foi detectado tal alteração; e
• Determinar sua posição dentro do ambiente que está patrulhando: o robô possui um sensor
que simula um GPS, retornando as coordenadas referentes a posição do mesmo.
3.1.3 Arquitetura do Sistema
Este trabalho buscou desenvolver o software de alto nível para que robôs móveis possam
locomover-se autonomamente por um ambiente e realizar seu patrulhamento.
A estrutura de camadas de software dos robôs é apresentada na Figura 18. As camadas mais
baixas de software são dependentes do hardware ou fornecem serviços básicos de controle do robô.
Assumiu-se, para este trabalho, que tais camadas já estão implementadas, e o acesso as suas funções
é feito através de uma interface de programação (API) estabelecida. Neste trabalho, assumiu-se que
esta interface de programação é a mesma disponibilizada pelo Simulador Simbad. Sendo que esta
37
interface foi expandida, com a inclusão de novas funções necessárias ao funcionamento de robôs de
tipos específicos.
As camadas de alto nível do software foram o foco deste trabalho, e devem prover a
funcionalidade desejada aos robôs. A camada de planejamento de caminhos recebe comandos da
camada superior especificando uma posição destino. Ela é encarregada, então, de estabelecer a
seqüência de posições pela qual o robô deve atravessar para chegar ao destino. Se o ambiente tiver
mudado (obstáculos tiverem sido movidos), esta camada é responsável por descobrir um novo
caminho até o destino.
A camada mais alto nível é responsável pelo controle de modos de operações e estratégias de
ação dos robôs, bem como por sua comunicação. Ela se baseia nas diversas informações sobre o
ambiente que cerca o robô e em suas configurações, para estabelecer o macro comportamento do
robô (fire, follow, divert, check, accelerate e breaking). Alguns desses comportamentos podem ser
cooperativos ou exigir a notificação de eventos, o que exige a comunicação com outros robôs e com
a central.
A definição deste macro comportamento para o robô é feita através de um Controlador Fuzzy,
onde foram definidas variáveis de controle e seus intervalos que serão usados, para calcular, através
de uma função trapezoidal o quanto este valor pertence a esta variável.
38
Figura 18. Estrutura de Camadas de Software
3.1.4 Modelagem UML
Abaixo são apresentados os diagramas UML utilizados para representar os aspectos da
estrutura e aspectos dinâmicos do sistema, contendo suas devidas explicações.
3.1.4.1 Diagrama de Componente
A visão geral dos principais comportamentos deste trabalho é apresentada na Figura 19.
Diversos robôs, possivelmente heterogêneos, realizam o patrulhamento de uma área. Eles podem
trocar informações e comandos entre si, usando alguma tecnologia de comunicação sem fio. Essas
informações podem ser advindas do ambiente ao redor (obtidas por sensores) e que podem ser
compartilhadas com outros robôs ou retransmitidas através destes até uma central. Nesse sentido, os
robôs funcionam como uma rede de sensores sem fio. Diversas situações podem fazer com que o
39
robô seja desejável. Nesse sentido, um robô também pode enviar comandos a outros robôs
solicitando seu deslocamento até certo local ou outro serviço específico.
Por não possuírem interface com o usuário, os robôs precisam ser programados ou
configurados remotamente, através de uma estação central presente no local de patrulhamento
(devido à limitação de alcance da rede sem fio). Através de uma conexão com a internet, os robôs
poderiam ser configurados de qualquer lugar, como da empresa de segurança, por exemplo.
Do mesmo modo que os robôs comunicam-se entre si ou recebem novas configurações e
comandos da central, eles também podem reportar situação anormais à central ou à empresa, como
a presença de intrusos, movimentos não identificados, mudanças de luminosidade, etc.
Figura 19. Diagrama de Componentes
3.1.4.2 Diagrama de Caso de Uso
Os diagramas de caso de uso descrevem de maneira conceitual os requisitos que devem ser
atendidos pelo sistema.
A figura 20 ilustra o diagrama de caso de uso de envio e recebimento de mensagens, onde
durante o patrulhamento, o robô ao encontrar alguma variação no ambiente que necessite de sua
atenção, envia uma mensagem a Central informando o remetente, o destinatário, o que causou a
notificação e as coordenadas correspondentes ao local que foi obtido o valor e ao receber a
mensagem a Central envia uma mensagem ao robô confirmando seu recebimento. O robô também
pode enviar e receber comandos para uma central ou para outros robôs, repassando uma ação a ser
executada por eles e as coordenadas de onde esta ação deve ser realizada.
40
Figura 20. Diagrama de Caso de Uso
3.1.4.3 Diagrama de Classes
O diagrama de classe representa a estrutura lógica e os elementos que descrevem o modelo e
suas relações. Cada classe descreve as ações que serão realizadas. A Figura 21 ilustra uma visão
geral das classes das classes deste sistema, que são: Robô, Estrategista, Analisador de
Ambiente, Sensores, Ambiente, Solo, Mecanismo de Locomoção, Planejador de Rotas,
Grafo, Dijkstra, Atuadores, Meio de Locomoção, Controlador Fuzzy, Comunicador.
A Figura 22 ilustra as classes que compõe o Analisador de Ambiente, onde o
Estrategista invoca o Analizador de Ambientes, que por sua vez chama a classe
Sensores, que faz uma varredura no ambiente coletando informações através de sensores como
sonares, de colisão, de temperatura, entre outros. Estas informações então são encaminhadas ao
Analisador de Ambiente que verifica se algum sensor retornou um valor que indique uma
variação no ambiente e que possa necessitar de atenção por parte do robô. Se um valor deste é
identificado, ele envia uma notificação para o Estrategista, contendo o nome do sensor e o
valor obtido pelo sensor e ele processa esta informação e verifica qual é a melhor ação a ser tomada
para aquela situação. Quando o Analisador de Ambiente decta esta variação ele verifica se
41
veio de um sonar ou sensor de colisão e caso tenha vindo de um destes sensores, ele então inclui um
novo obstáculo na classe Ambiente.
Figura 21. Diagrama com uma visão geral das classes
A Figura 23 ilustra a classe Estrategista e sua interação com as classes Planejador
de Rotas, Mecanismo de Comunicação e Controlador Fuzzy. Depois que o
estrategista recebe a notificação do Analisador de Ambiente, conforme descrito
anteriormente, ele repassa esta informação ao Controlador Fuzzy que através de uma função
de pertinência transforma esse valor e processa o resultado utilizando uma serie de regras pré-
definidas, que retornam ao Estrategista qual a ação que deve ser executada naquele momento.
Quando a ação for movimentar o robô para determinada posição, o Estrategista então aciona
o Planejador de Rotas, repassando as coordenadas para onde ele deve deslocar o robô. Ele
então encaminha estas coordenadas ao Gerenciador de Grafo que utilizando o Algoritmo
de Dikstra faz uma busca nos nós gerados durante a movimentação do robô e retorna o menor
caminho ate o ponto desejado, caso este caminho não seja conhecido, ele então retorna o ponto mais
próximo conhecido. Após receber as coordenadas o Planejador de Rotas então aciona os
42
atuadores e movimenta o robô ate estas coordenadas, repetindo este processo ate atingir o local
desejado. Ela também ilustra a interação do Estrategista com o Mecanismo de
Comunicação, que após ser acionado para enviar uma mensagem, pega o conteúdo desta e salva
em um arquivo texto. E sempre que é acionado pelo Estrategista para verificar se a alguma
mensagem para ele, o conteúdo deste arquivo texto é aberto e processado, sendo repassado ao
estrategista o nome do destinatário da mensagem que por sua vez verifica se a mensagem é para ele
e se for então salva o seu conteúdo e avisa o Mecanismo de Comunicação que a mensagem
foi lida e esta então é apagada do arquivo texto.
43
Figura 22. Diagrama de classe do Analisador de Ambiente
44
Figura 23. Diagrama de classe do Estrategista
45
3.1.4.4 Diagrama de Seqüência
O diagrama de seqüência representa o comportamento dos objetos em um sistema em
seqüência temporal de mensagens e representação das atividades e operações. Os objetos são
desenhados em linhas verticais e as ações seguem uma seqüência acompanhando as linhas de cima
para baixo.
O diagrama ilustrado na Figura 24, representa o processo de tomada de decisão por parte do
Estrategista. O Robô invoca o Estrategista, que invoca o Analisado de
Ambiente e aguarda por uma notificação informando uma alteração relevante no ambiente. O
Analisador de Ambiente aciona os Sensores que varem o ambiente e retornam os
valores obtidos, estes valores são enviados ao Analisador de Ambiente que os processa e
verifica se algum deles merece atenção por parte do Estrategista. Se o valor merecer atenção
o Analisador de Ambiente notifica o Estrategista, informando o nome do sensor e o
valor obtido por ele durante a leitura. Então o Estrategista invoca o Gerenciador de
Lógica Fuzzy e repassa este valor, que pega esta informação e processa devolvendo ao
Estrategista a ação que deve ser tomada. O Estrategista então recebe esta informação e
passa a operar no modo correspondente a ação.
A Figura 25 ilustra o diagrama representa as ações executadas para movimentação do robô.
Onde o Estrategista determina uma coordenada para onde o robô deve se deslocar e invoca o
Planejador de Rotas, enviando esta coordenada para o mesmo, que solicita ao
Gerenciador de Grafo o menor caminho até este ponto. O Gerenciador de Grado
utiliza o Algoritmo de Dijkstra para determinar o menor caminho até a coordenada
repassada e devolve o primeiro ponto que o robô deve se deslocar para chegar ao local determinado,
caso o caminho até este ponto não seja conhecido ele retorna o ponto conhecido mais próximo do
local desejado. O Planejador de Rotas então aciona o Mecanismo de Locomoção que
processa as coordenadas recebidas e aciona os Atuadores, que movimentam o robô.
O Mecanismo de Comunicação é representado pelo Diagrama ilustrado na Figura 26.
O Estrategista pode optar por enviar ou receber uma mensagem, para enviar o
Estrategista aciona o Mecanismo de Comunicação e envia uma mensagem para ele,
que pega esta mensagem e salva em um arquivo texto. Para receber as mensagens o
Estrategista verifica com o Mecanismo de comunicação se existe alguma mensagem,
este então faz a leitura do arquivo texto e processa estas informações retornando a mensagem ao
46
estrategista que verifica se o nome do destinatário confere e então se for para ele coleta as
informações e informa ao Mecanismo de Comunicação que a mensagem foi lida e ele apaga
a mensagem do arquivo texto. Estas mensagens podem ser informações que foram coletadas no
ambiente e precisam ser repassadas a outros robôs ou a uma central ou então comando referentes a
ações que devem ser executadas pelos robôs ou pela central.
Figura 24. Diagrama de Seqüência de tomadas de decisão do Estrategista
47
Figura 25. Diagrama de Seqüência do Planejador de Rotas
Figura 26. Diagrama de Seqüência do Mecanismo de Comunicação
48
3.1.5 Controlador Fuzzy
Para tomar as decisões, o Estrategista utiliza um controlador implementado, utilizando
lógica Fuzzy, e que possui definidas em seu interior as seguintes variáveis: (i) Temperatura,
usada para avaliar a temperatura do local em busca de possíveis incêndios e possui os valores para
Temperatura Baixa de 0, 15, 25 e 30, para Temperatura Média de 25, 30, 40 e 45 e para
Temperatura Alta de 40, 50, 60 e 70; (ii) Altura, utilizado para ajudar o robô durante o seu
deslocamento em busca de buracos, com valores para Altura Baixa de 0, 0.03, 0.06 e 0.10,
para Altura Média de 0.08, 0.12, 0.16 e 0.20, e para Altura Alta de 0.18, 0.22, 0.28 e 0.30;
(iii) Terreno, utilizado para avaliar o quanto o terreno é macio e se é possível se deslocar por este
terreno com o meio de locomoção utilizado pelo robô, com os valores para Terreno Macio de
0, 0.5, 1.5 e 2, para Terreno Médio de 1.5, 2, 2.5 e 3 e Terreno Duro de 2.5, 3, 3.5 e 4; (iv)
Nível de Segurança, utilizado para avaliar o nível de segurança da local que esta sendo
patrulhado, com os valor para Nível de Segurança Baixo de 0, 0.5, 1 e 1.5, para Nível
de Segurança Médio de 0.5, 1, 1.5 e 2 e para Nível de Segurança Alto de 1.5, 2, 2.5
e 3; (v) Velocidade, utilizado para avaliar a velocidade de deslocamento do Robô, com os valor
para Velocidade Baixa de 0, 0.1, 0.3 e 0.4, para Velocidade Média de 0.3, 0.4, 0.6 e 0.7
e para Velocidade Alta de 0.6, 0.7, 0.9 e 1; e (vi) Distância, utilizado para avaliar a
distancia do Robô ate o obstáculo, com os valores para Distância Baixa de 0, 0.2, 0.4 e 0.6,
para Distancia Média de 0.6, 1, 1.6 e 2, e para Distância Alta de 1.8, 2, 2.5 e 3.
O valor que é obtido através dos sensores é transformado por uma função de pertinência,
conforme Quadro 5, no processo chamado de Fuzzyficação, para que valores de grandezas
diferentes possam ser avaliados de maneira igual. Estes valores então são calculados para avaliar o
quanto este pertence (baixo, médio ou alto) ao conjunto definido da variável em questão e esta
condição atribuída a variável as regras descritas abaixo, para determinar qual ação deverá ser
executada pelo Robô. As regras são:
Se TEMPERATURA for ALTA então retorne “FIRE”;
Se ALTURA_ANTERIOR for BAIXA e ALTURA for MÉDIA então retorne “FOLLOW”;
Se ALTURA_ANTERIOR for BAIXA e ALTURA for ALTA então retorne “DIVERT”;
Se ALTURA_ANTERIOR for MÉDIA e ALTURA for ALTA então retorne “FOLLOW”;
Se ALTURA_ANTERIOR for ALTA e ALTURA for BAIXA então retorne “DIVERT”;
49
Se TERRENO for BAIXO então retorne “DIVERT”;
Se NIVEL_SEGURANÇA for MÉDIO então retorne “CHECK”;
Se NIVEL_SEGURANÇA for ALTO então retorne “CAPTURE”;
Se DISTANCIA_ANTERIOR for MAIOR que DISTANCIA então retorne “CHECK”;
Se DISTANCIA for BAIXA então retorne “DIVERT”;
Se DISTANCIA for ALTA e VELOCIDADE for BAIXA então retorne “ACCELERATE”;
Se DISTANCIA for MEDIA E VELOCIDADE for BAIXA então retorne “ACCELERATE”; e
Se DISTANCIA for MEDIA E VELOCIDADE for alta então retorne “BRAKING”.
Esta ação então é devolvida ao Estrategista que entra em modo correspondente a ação para
executa - lá, ainda a opção de desfuzificar esta variável para obter o valor correspondente à ação.
CONDIÇÃO FUNÇÃO DE PERTINENCIA Se (_value < _min) f(x) = 0
Se (_value >= _min) e (_value <= _md1) f(x) = (_value - _min) / 5; Se (_value >= _md1) e (_value <= _md2) f(x) = 1 Se (_value >= _md2) e (_value <= _max) f(x)(_max - _value) / 5;
Se (_value > _max) f(x) = 0; Quadro 5. Função de pertinência
3.2 IMPLEMENTAÇÃO Nesta sessão são apresentados alguns aspectos de implementação do sistema, incluído os
métodos e componentes utilizados para isso. Serão também apresentados os procedimentos
realizados para validação e teste do sistema.
3.2.1 Execução do Sistema
O sistema desenvolvido não possui um interface que permita a interação direta do usuário
com o Robô, o sistema é chamado através do Simulador Simbad, que proporciona um ambiente de
simulação para robôs em 3 dimensões e fornece algumas das funções de baixo nível necessárias
para o funcionamento do robô.
50
3.2.1.1 Testes e validações
Os testes do Robô foram realizados no Simulador Simbad, submetendo o mesmo a diversas
situações, buscando coletar os mais diversos valores por parte dos sensores e avaliar se o
comportamento adotado corresponde as regras especificadas no Controlador Fuzzy. A Figura 25
mostra o ambiente de simulação utilizado para os testes.
Figura 27. Ambiente de Simulação Simbad A Figura 28 mostra o log obtido através do NetBeans (interface de programação em Java)
durante a simulação com o Robô, onde o Estrategista recebe uma notificação do Analisador de
Ambiente, informando que um dos sensores de distância (sonar) retornou o valor de 0.31000018,
esta informação então é repassada ao Controlador Fuzzy que processa esta informação e retorna a
ação a ser executada pelo Estrategista, que neste caso é desviar. O Estrategista então solicita ao
Planejador de Rotas para girar o Robô, que por sua vez aciona o Mecanismo de Locomoção, que
repassa aos atuadores e executa a aperação.
A Figura 29 ilustra o log obtido quando o Robô verifica uma variação muito grande no
ambiente como, por exemplo neste caso, estava captando valores pequenos nos sensores de
51
distância e depois encontrou um valor maior, então o Estrategista recebe uma notificação no
Analisador do Ambiente informando que a variação foi detectada através de um sonar e o valor
obtido por ele foi 0.5999998. Este valor então é repassado ao Controlador Fuzzy, que executa os
cálculos e retorna a ação Check, para que o robô verifique o motivo de tal variação e como no caso
anterior o Estrategista então invoca o Planejador de Rotas que se encarrega de levar o robô ate o
local.
Na Figura 30 é mostrado o log de quando o Robô encontra um buraco, sendo que o sensor de
altura coletou uma variação no terreno de 0.05 (5 centímetros) e este valor foi repassado ao
Estrategista, que por sua vez repassou ao Controlador Fuzzy que processou esta informação e
retornou a ação desviar ao Estrategista, que entrou em modo desviar e acionou o Planejador de
Rotas para executar a tarefa.
Strategist:update(EnvironmentAnalyser@1c80b01,sonar#0.31000018)
FuzzyController: calcular
FuzzyController: fuzzyficador
FuzzyController: desfuzzyficador
FuzzyController: rules
FuzzyController:Action Divert
RoutePlanner:spinRobot()
MovingMechanism:spinRobot()
RobotActuators:spinRobot()
Figura 28. Log obtido quando Robô detecta obstáculo próximo
Strategist:update(EnvironmentAnalyser@1a8bd74,sonar#0.5999998)
FuzzyController: calcular
FuzzyController: fuzzyficador
FuzzyController: desfuzzyficador
FuzzyController: rules
FuzzyController:Action Check
RoutePlanner:goRobot()
MovingMechanism:goRobot()
RobotActuators:setvelocity(0.6)
Figura 29. Log obtido quando Robô detecta uma alteração grande no ambiente
52
Strategist:update(EnvironmentAnalyser@1542a75,terrain#0.05)
FuzzyController: calcular
FuzzyController: fuzzyficador
FuzzyController: desfuzzyficador
FuzzyController: rules
FuzzyController:Action Divert
RoutePlanner:spinRobot()
MovingMechanism:spinRobot()
RobotActuators:spinRobot()
Figura 30. Log obtido quando Robô encontra um buraco
A Figura 31 ilustra o robô percorrendo o ambiente, sendo capaz de identificar diferentes
tipos de obstáculos como paredes e buracos, assim como tipo de terreno. Onde, (i) a primeira tela,
ilustra o ambiente conforme a visão do robô através dos sensores; (ii) a segunda tela, mostra o robô
em sua posição inicial; (iii) a terceira tela, mostra o momento em que o robô encontra uma parede e
altera sua trajetória; (iv) a quarta tela, ilustra o deslocamento do robô após ter desviado da parde;
(v) a quinta tela, mostra o momento em que o robô identifica o tipo de terreno como sendo água;
(vi) a sexta tela, mostra o momento em que o robô desvia da água; (vii) a sétima tela, mostra o
momento em que o robô encontra um declive no terreno que não pode ser ultrapassada por ele; e
(viii) a oitava tela, ilustra o momento em que o robô desvia do buraco.
A Figura 32 ilustra o robô no momento em que encontra uma alteração no ambiente e
informa esta alteração a Central. Sendo que, (i) a primeira tela, mostra o robô em seu estado inicial;
(ii) a segunda tela, ilustra o momento em que o robô encontra uma parede e desvia da mesma
seguindo na direção oposta; (iii) a terceira tela, mostra o momento em que durante o patrulhamento
é constatada uma alteração no ambiente, através do sensor de temperatura, que constata que a
temperatura esta muito elevada naquele local e envia uma mensagem notificando a Central da
alteração encontrada no ambiente; ; (iv) a quarta tela, ilustra o momento em que a Central confirma
o recebimento da mensagem enviada pelo robô; (v) a quinta tela, mostra o momento em que o robô
se retira do local para preservar sua integridade.
53
Figura 31. Robô identificando diferentes tipos de obstáculos
54
Figura 32. Robô encontra uma alteração no ambiente e notifica a Central
A Figura 33 ilustra o robô recebendo uma mensagem da Central com um comando para que
ele desloque até um determinado ponto. Onde, (i) a primeira tela, mostra o robô em sua posição
inicial; (ii) a segunda tela, ilustra o robô patrulhando o ambiente; (iii) a terceira tela, mostra o
momento em que o robô recebe uma mensagem da Central contendo o comando para que ele
desloque até um determinado ponto; (iv) a quarta tela, mostra o robô confirmando o recebimento
55
da mensagem enviada pela Central; (v) a quinta tela, ilustra o robô durante o deslocamento até o
ponto repassado; (vi) a sexta tela, ilustra o momento em que o robô chega a coordenada
determinada;
Figura 33. Robô se desloca até uma coordenada repassada pela Central
As Figuras 34 e 35 ilustram o robô verificando a presença de intrusos e funcionários em
local não autorizado. Sendo que, (i) a primeira tela, mostra o robô em seu estado inicial; (ii) a
segunda tela, mostra o robô durante o patrulhamento; (iii) a terceira tela, mostra o momento em
que o robô detecta a presença de outro robô e identifica o mesmo como sendo a Central e que esta
possui autorização para estar naquele setor; (iv) a quarta tela, mostra o momento em que o robô
retorna ao patrulhamento; (v) a quinta tela, ilustra o momento em que o robô encontra um intruso;
(vi) a sexta tela, ilustra o momento em que o robô envia uma mensagem a Central notificando a
presença de um intruso; (vii) a sétima tela, ilustra o momento em que a Central confirma o
recebimento da mensagem; (viii) a oitava tela, mostra o robô no momento em que ele retorna ao
patrulhamento; (ix) a nona tela, ilustra o momento em que o robô encontra um funcionário da
empresa e ao identificá-lo verifica que o mesmo não tem permissão para estar naquele setor; (x) a
décima tela, mostra o momento em que o robô envia uma mensagem a central notificando a
presença do mesmo; (xi) a décima primeira tela, mostra a Central confirmando o recebimento da
mensagem.
56
Figura 34. Robô verifica pessoal autorizado - parte 1
57
Figura 35. Robô verifica pessoal autorizado – parte 2
58
4 CONCLUSÃO
Este trabalho apresentou uma descrição geral de uma modelagem para robôs autônomos,
assim como a implementação de parte desta modelagem e a realização de testes através do
simulador Simbad. Os objetivos propostos inicialmente para este trabalho eram modelar um robô
capaz de se locomover sem a ajuda humana (autonomamente), atuar em diferentes modos de
operação, receber parâmetros determinando sua área de patrulhamento, aprender os caminhos para
se alcançar um ponto dentro de uma área de atuação, desviar de obstáculos, localizar alterações no
ambiente, distinguir entre pessoal autorizado e não autorizado, possuir uma interface que possibilite
a comunicação com outros robôs ou com uma central, receber ordens de outro robô ou de uma
central, enviar informações a central sobre qualquer alteração encontrada e determinar sua posição
dentro do ambiente que está patrulhando.
Pelo que foi apresentado ao longo do texto e dos resultados obtidos durante os testes
realizados no simulador, concluiu-se que o mesmo atendeu de maneira satisfatória aos objetivos
propostos, pois é capaz de realizar todas as ações previstas nos requisitos do sistema.
Apesar de ter apresentado resultados satisfatório nas simulações o robô apresenta limitações,
pois possui apenas uma interface de mais alto nível o que impossibilita testes em um robô real sem
que seja necessário a implementação das camadas de mais baixo nível e talvez pequenas
adequações no código.
Varias dificuldades foram encontradas durante o desenvolvimento deste trabalho, sendo que
o principal deles foi encontrar um simulador para ser utilizado como plataforma base para o robô e
na realização de testes para validação do projeto. A maioria dos simuladores encontrados
apresentaram problemas principalmente por suas limitações tanto na parte de construção de um
ambiente de simulação próximo a um ambiente real, assim nas limitações referentes a parte de
programação e expansão das funcionalidades do robô, que não permitiam que fossem atingidos os
requisitos do sistema.
O sistema permite melhorias, as quais podem ser realizadas em trabalhos futuros, sendo que
algumas delas são apresentadas a seguir.
Mesmo tendo sido implementado uma série de ações e modos de operações para o robô, a
parte de lógica ainda possibilita uma grande ampliação, podendo ser incluídas novas regras no
Gerenciador de Lógica Fuzzy, que farão com que cada vez mais o raciocínio do robô seja parecido
com o de uma pessoa. Assim como a implementação e inclusão de novos sensores que tornarão
59
mais precisas as informações e em maior número, o que possibilita uma análise mais precisa da
situação.
Outra sugestão para o futuro seria a implementação do mecanismo físico, para testar o
sistema e seu desempenho em um ambiente real. E até mesmo virar um produto comercial, caso
sejam realizadas as melhorias necessárias para tal finalidade.
Por fim o desenvolvimento deste trabalho deve auxiliar estudantes e professor na área de
robótica, pois possui a implementação de vários conceitos importantes para esta área e pode servir
como base para o desenvolvimento de trabalhos futuros.
48
REFERÊNCIAS BIBLIOGRÁFICAS
AGENCIA EFE. Alemães apresentam o robô de segurança da copa. Terra. Brasil. Disponível em: <http://tecnologia.terra.com.br/interna/0,,OI961269-EI4799,00.html>. Acesso em: 03 mar. 2007. BATALHANDO e Aprendendo com Robocode. UDESC, Brasil, 2007. Disponível em: <http://www.sbs.udesc.br/semana2007/Robocode.pdf>. Acesso em: 21 maio 2007.
BIANCHI, Reinaldo A. C.; REALI-COSTA, Anna H. O sistema de visão computacional do time FUTEPOLI de futebol de robôs. In: CONGRESSO BRASILEIRO DE AUTOMÁTICA, 13., 2000, Florianópolis. Anais eletrônicos... Florianópolis: CBA, 2000. Disponível em: <http://www.lti.pcs.usp.br/publicacoes/BianchiCosta00a-CBA.pdf>. Acesso em: 26 mar. 2007. CHOSET, Howie et al. Principles of Robot Motion: theory, algorithms, and implementations. MIT Press Books, 2005.
DAMASCENO JUNIOR, Américo. Aprendendo Java programação na Internet. São Paulo: Erica, 1996. GROOVER, Mikell P. et al. Tradução David Maurice Savatovsky. Robótica, Tecnologia e Programação. São Paulo: McGraw-Hill Ltda, 1989. HEINEN, Farlei José. O que é um robô? Grupo de robótica inteligente. Disponível em: <http://ncg.unisinos.br/robotica/>. Acesso em: 07 mar. 2007. HORSTMANN, Cay S.; CORNELL, Gary. Tradução João Eduardo Nóbrega Tortello. Core Java 2 Volume I – Fundamentos. São Paulo: Pearson Makron Books, 2003.
HUBNER, Jomi Fred. Sistema de posicionamento para robôs Lego Mindstorm. Blumenau: FURB, 2003. Disponível em: <http://www.inf.furb.br/gia/projetos/sistemaPosicionamentoLego.pdf>. Acesso em: 26 mar. 2007. HUGUES, Louis; BREDECHE, Nicolas. Simbad: an Autonomous Robot Simulation Package for Education and Research. Paris: GINKGO - NETWORKS, 2006. Disponível em: <http://www.lri.fr/~bredeche/MyBiblio/SAB2006simbad.pdf >. Acesso em: 09 nov.embro 200726 mar. 2007.
JORNAL HOJE. Mapa da violência no Brasil. Disponível em: <http://jornalhoje.globo.com/JHoje/0,19125,VJS0-3076-20070227-268471,00.html>. Acesso em: 03 mar. 2007.
KAICK, Oliver Matias Van et al. Reconhecimento em tempo real de agentes autônomos em futebol de robôs. Curitiba: UFPR, 2003. Disponível em: <http://209.85.165.104/search?q=cache:71gkShAPh_4J:geo.inf.ufpr.br/~oliver/artigos/sbai2003.pdf+orienta%C3%A7%C3%A3o+robos&hl=pt-BR&ct=clnk&cd=18&gl=br&lr=lang_pt>. Acesso em: 26 mar. 2007.
49
LÓPES, Amarilys Lima. Controle Nebuloso e Algoritmos Genéticos: uma aplicação ao robô móvel Khepera. 1999. 98 f. Dissertação (Mestrado em Engenharia Elétrica) – Pós-Graduação em Engenharia Elétrica, Universidade Federal de Santa Catarina, Florianópolis, 1999. MARIANI, Antonio C. Conceitos básicos da teoria dos garfos. UFSC, Brasil, 2007. Disponível em: <http://www.inf.ufsc.br/grafos/definicoes/definicao.html>. Acesso em: 29 mai. 2007. MICHEL, Olivier. Khepera Simulator Homepage. EPFL, 1997. Disponível em: <http://diwww.epfl.ch/lami/team/michel/khep-sim/>. Acesso em: 28 jul. 2007. OGATA, Katsuhiko. Modern Control Engineering. Prentice Hall, 1990. OTTONI, Guilherme de Lima; LAGES, Walter Fetter. Navegação de robôs móveis em ambientes desconhecidos utilizando sonares de ultra-som. Controle & Automação, Brasil, v. 14, n. 4, 2003. Disponível em: <http://www.cs.pr/nceton.edu/~ottoni/pub/rca2003.pdf>. Acesso em: 26 mar. 2007.
PAZOS, Fernando. Automação de Sistemas & Robótica. Rio de Janeiro: Axcel Books do Brasil, 2002.
PHILLIPS, Charles L.; HARBOR, Royce D. Feedback Control System. 4. ed. Prentice Hall, 2000.
POLONSKII, Mikhail M. Introdução a Robótica e Mecatrônica. Caxias do Sul: Universidade de Caxias do Sul, 1996. RABUSQUE, Márcia A. Introdução à teoria dos grafos. Florianópolis: UFSC, 1992.
ROBÔ PATRULHEIRO. Inovação Tecnológica. Brasil, 19 set. 2003. Robótica. Disponível em: <http://www.inovacaotecnologica.com.br/noticias/noticia.php?artigo=010180030919>. Acesso em: 24 mar. 2007.
ROBÔ patrulheiro é lançado no Japão. Terra, Brasil, 01 dez. 2006. Tecnologia. Disponível em: <http://tecnologia.terra.com.br/interna/0,,OI1279061-EI4799,00.html>. Acesso em: 25 mar. 2007.
ROBOCODE, JavaFree.org. Brasil, 10 fev. 2006. Notícias. Disponível em: <http://www.javafree.org/news/view.jf?idNew=276>. Acessado em: 21 mai. 2007.
ROCHA, Rui. CooPatrol – Robôs móveis cooperantes para patrulha de um edifício e vigilância. DEEC, Portugal, 2006. Disponível em: <http://www.deec.uc.pt/~rprocha/ensino_ficheiros/CooPatrol-prop-proj-LEEC-2006-07.pdf >. Acesso em: 24 mar. 2007.
SANTOS, Frederico M.; SILVA, Valter F.; ALMEIDA, Luis. Auto-localização em pequenos robôs móveis e autônomos: o caso do robô Bulldozer IV. Eletrônica e Telecomunicações, Portugal, 2002. Disponível em: <http://microrato.ua.pt/main/docs/artigos/robotica02-bulldozer.pdf.>. Acesso em: 25 mar. 2007. SHAW, Ian S.; SIMÕES, Marcelo Godoy. Controle e Modelagem Fuzzy. São Paulo: Edgard Blücher: FAPESP, 1999.
50
SILVA, Luciano Rottava da. Análise e programação de robôs móveis autônomos da plataforma EYEBOT. 2003. 95 f. Dissertação (Mestrado em Engenharia Elétrica) – Pós-Graduação em Engenharia Elétrica, Universidade Federal de Santa Catarina, Florianópolis, 2003. SOURCEFORGE. Robocode. Disponível em: < http://robocode.sourceforge.net/>. Acesso em: 29 mai. 2007. SOURCEFORGE. Simbad. Disponível em: < http://simbad.sourceforge.net/>. Acesso em: 09 nov. 2007.
VÁRIOS robôs patrulham os estádios da Copa do mundo. Terra, Brasil, 21 jun. 2006. Disponível em: <http://tecnologia.terra.com.br/interna/0,,OI1049276-EI4799,00.html>. Acesso em: 25 mar. 2007. WOLF, Wayne. Computer as components: principles of enbedded computing system design. Morgan Kaufman, 2001.
ANEXO
I FERRAMENTA JAVA
Conforme Horstmann e Cornell (2003), em 1991 a Sun Mycrosystems, através de um grupo
liderado por James Gosling e Patrick Naughton, projetou uma linguagem que foi chamada de
“Green” para ser utilizada em dispositivos de consumo como caixas “set-top” de televisão
inteligente. Ela foi projetada para ser uma linguagem simples e de arquitetura neutra, de modo que
pudesse ser utilizada em diferentes hardwares. Mas nunca se encontrou um cliente para esta
linguagem.
Gosling lembra que em 1994 a equipe percebeu: “Poderíamos escrever um navegador
realmente bom. Era uma das poucas coisas na tendência dominante cliente/servidor que precisava
algumas das esquisitices que nós projetamos: arquiteturas neutras, tempo real, confiável, segura”.
Em 1995 durante a SunWorld foi apresentado o navegador HotJava, que possuía uma propriedade
singular: conseguia fazer downloads de programas chamados de applets, escritos na linguagem
agora chamada de Java e que permitia aos desenvolvedores fornecer uma variedade de animações e
interações, que expandiram as qualidade das paginas Web. A partir de 1996, essa nova linguagem
passou a ser incorporada nos navegadores da Netscape e da Microsoft (HORSTMANN;
CORNELL, 2003).
A linguagem Java por ser uma linguagem mais simples que sua rival mais próxima o C++,
teve uma taxa de crescimento fenomenal. Outro fator que contribuiu para seu crescimento foi que o
Java já possuía uma rica biblioteca que torna possível escrever programas portáveis capazes de
serem executados em diferentes sistemas operacionais proprietários. Mesmo que algumas
expectativas iniciais tenham sido otimistas demais e o slogan “escreva uma vez, rode em qualquer
lugar” virou “escreva uma vez, depure em todos os lugares” para os primeiros usuários que tinham
que lidar com implementações não perfeitas, desde lá o Java já percorreu um grande caminho e as
novas versões trouxeram um nível muito maior para o desenvolvedor (HORSTMANN; CORNELL,
2003).
Segundo Horstmann e Cornell (2003), “como o Java foi projetado para a Internet, ela possui
dois atributos que a tornam muito adequada para iniciantes: segurança e portabilidade”. Isso é
importante porque ao visitar uma página que contenha applets, elas automaticamente começaram a
serem executadas no seu computador e caso essas applets pudessem realizar tarefas como apagar
dados ou ler arquivos pessoais do seu computador, você estaria correndo um grande risco toda vez
que navegasse na web e por isso a linguagem Java possui mecanismos de segurança que impedem
que essas applets malignas executem em seu computador. E por ser uma linguagem voltada a web,
53
é fundamental que ela possa rodar nos mais diversos sistemas operacionais como Windows, Unix,
Linux ou Machintosh, sem precisar sofrer alterações no programa, tendo em vista que é uma rede
mundial e os conteúdos da página não tem idéia de qual computador está sendo usado para navegar,
ele apenas recebe o código portável gerado pelo compilador Java e a máquina virtual instalada no
seu computador então se encarregara de executar esse código.
Outras vantagens da linguagem Java são: (i) possui uma linguagem similar ao C++, mas
ainda mais orientada a objeto e recursos que eliminam os erros mais comuns durante a
programação; (ii) com o Java não é necessário alocar e eliminar memória manualmente pois tem
coleta de lixo automática; (iii) eliminou a aritmética de ponteiros criando arrays verdadeiros; (iv)
eliminou herança múltipla, substituindo por uma interface que oferece o que se espera de uma
herança mas sem a complexidade que surge com o controle de hierarquia (HORSTMANN;
CORNELL, 2003).
Conforme Dario Borralli, gerente geral da Sun Microsystems do Brasil em 1996, “a
linguagem Java está provocando uma mudança radical nos princípios da computação”. Isso se deve
primeiramente por ser um sistema capaz de rodar em qualquer computador independente da
plataforma ou sistema operacional e por permitir a utilização de várias mídias ao mesmo tempo,
tornando a internet mais dinâmica e divertida (DAMASCENO JUNIOR, 1996).
Horstmann e Cornell (2003) destacam ainda que apesar de já ter se estabelecido como uma
das mais importantes linguagens de programação, bem como para o ensino em ciência da
computação e seja uma linguagem boa para iniciantes ela não é perfeita por duas razoes: (i) por não
ser projetada especificamente para estudantes ela não foi projetada para facilitar a escrita de
programas e até mesmo os programas mais simples necessitaram de uma certa dose de mecanismos
técnicos, sendo necessário um certo conhecimento em programação para o entendimento destes
mecanismos; (ii) ale m disso ele possui um vasto conjunto de pacotes e bibliotecas que são
necessários para se escrever programas úteis e nem mesmo programadores experientes conhecem o
conteúdo de todos os pacotes, eles apenas usam aqueles que necessitam para determinados projetos.