MINISTÉRIO DA DEFESA

EXÉRCITO BRASILEIRO

DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA

IME - INSTITUTO MILITAR DE ENGENHARIA

CURSO DE GRADUAÇÃO DE ENGENHARIA DE COMPUTAÇÃO

OSCAR MARTINS WANDERLEY FILHO

RENATO DIAS COSTA

WILLIAN ATSUKI KANASHIRO

CONSTRUÇÃO DE ROBÔ MÓVEL AUTÔNOMO COM PLATAFORMA

LEGO MINDSTORMS

Rio de Janeiro

2015

INSTITUTO MILITAR DE ENGENHARIA

OSCAR MARTINS WANDERLEY FILHO

RENATO DIAS COSTA

WILLIAN ATSUKI KANASHIRO

CONSTRUÇÃO DE ROBÔ MÓVEL AUTÔNOMO COMPLATAFORMA LEGO MINDSTORMS

Projeto de Fim de Curso apresentado ao Curso de Gradu-

ação de Engenharia de Computação do Instituto Militar de

Engenharia como requisito parcial para obtenção de gradu-

ando.

Orientador: Paulo Fernando Ferreira Rosa - Professor As-

sociado

Rio de Janeiro

2015

INSTITUTO MILITAR DE ENGENHARIA

Praça General Tibúrcio, 80 - Praia Vermelha

Rio de Janeiro-RJ CEP 22290-270

Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-

lo em base de dados, armazenar em computador, micro�lmar ou adotar qualquer forma

de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas

deste trabalho, sem modi�cação de seu texto, em qualquer meio que esteja ou venha a

ser �xado, para pesquisa acadêmica, comentários e citações, desde que sem �nalidade

comercial e que seja feita a referência bibliográ�ca completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e do(s)

orientador(es).

Martins, Oscar W. F., Costa, Renato D. , Kanashiro, Willian A.

Construção de robô móvel autônomo com plataforma Lego Mindstorms/

Renato Dias Costa, Oscar Martins Wanderley Filho, Willian Atsuki Kanashiro:

orientados por Paulo Fernando Ferreira Rosa. - Rio de Janeiro : Instituto

Militar de Engenharia, 2015.

xp. : il.

Monogra�as(Projeto de Fim de Curso). - Instituto Militar de Engenharia:

Rio de Janeiro, 2015.

1.Curso de Engenharia de Computação - monogra�as 2.Robótica 3.Sistemas

autônomos 4.Plataforma Lego I. Rosa, Paulo Fernando Ferreira II. Construção

de robô móvel autônomo com plataforma Lego Mindstorms III. Instituto Mi-

litar de Engenharia.

2

INSTITUTO MILITAR DE ENGENHARIA

OSCAR MARTINS WANDERLEY FILHO

RENATO DIAS COSTA

WILLIAN ATSUKI KANASHIRO

CONSTRUÇÃO DE ROBÔ MÓVEL AUTÔNOMO COM PLATAFORMA

LEGO MINDSTORMS

Projeto de Fim de Curso apresentado ao Curso de Graduação de Engenharia de Com-

putação do Instituto Militar de Engenharia como requisito parcial para obtenção de gra-

duando.

Orientador: Paulo Fernando Ferreira Rosa - Professor Associado

Aprovada em 26 de Maio de 2015 pela seguinte Banca Examinadora:

Paulo Fernando Ferreira Rosa - Professor Associado, do IME

Sandro Santos de Lima - Ms.C., do IME

Julio Cesar Duarte - D.C., do IME

Rio de Janeiro

2015

3

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Justi�cativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Estrutura da Monogra�a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 LEGO MINDSTORMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Controlador Lego e Interface de Programação . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Sensores e Motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 LARC - SEK 2014 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Regras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Con�guração Inicial da Arena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Robôs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1 Restrições dos Robôs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.1 Sistema de Pontuação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.2 Penalizações por Cartão Vermelho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.3 Classi�cação das Equipes em Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Requisitos para Participar da Competição . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6 O Júri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.7 Situações Extraordinárias Durante a Competição . . . . . . . . . . . . . . . . . . . . . . 25

4 PROVA DE CONCEITO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Objetivo da Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Materiais Utilizados e Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 COMPETIÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Estratégia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4

5.2 Montagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1 Robô Arremessador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3.2 Robô Coletor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4 Partidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 MELHORIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 LeJOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.2 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1.3 Prós e Contras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2 Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2.1 Sistema de Captura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2.2 Sistema de Seleção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2.3 Sistema de Lançamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.2.4 Rotina e Fluxograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.5 Comparação Entre os Robôs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.1 Resultado da Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.2 Resultado da Competição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3 Resultado da Melhoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9 REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5

RESUMO

A idéia de se construir robôs começou a tomar força no início do século XX,

com a necessidade de aumentar a produtividade industrial e melhorar a qualidade dos

produtos. A robótica atravessa uma época de contínuo crescimento que permitirá, em um

curto espaço de tempo, o desenvolvimento de robôs inteligentes, fazendo assim a �cção

do homem antigo se tornar a realidade do homem atual. Nesse contexto, o MIT (Mas-

sachuchetss Institute of Technology), em parceria com o LEGO Group, criou o produto

LEGO Mindstorms. O conjunto permite criar robôs simples, passíveis de executar funções

básicas pré-programadas, com o objetivo de estimular o desenvolvimento intelectual de

crianças e jovens de modo cativante.

Este trabalho foi idealizado almejando a obtenção de maiores conhecimentos no

ramo da robótica e de sistemas autônomos, assim como a participação em competições

acadêmicas de caracter educacional. Para este �m, foram idealizadas três etapas, nas

quais este foi dividido, a saber: (a) Prova de Conceito, (b) Construção do robô para a

competição e (c) Melhorias do robô após a competição. Na primeira etapa, cumpriu-se o

objetivo proposto de testar a viabilidade de utilização dos componentes para a constru-

ção de um robô autônomo móvel que pudesse participar da competição LARC 2014. Na

segunda etapa, foi conluído o objetivo de construir os robôs para participar da competição,

adquirir conhecimento e experiência por meio da participação e, por �m, propor melhorias

para o modelo. Na terceira e última etapa, foram estudadas, implementadas e analisadas

as melhorias propostas, em novos sistemas de lançamento, coleta e seleção, ao �m da

etapa anterior, com o objetivo de otimizar a funcionalidade do robô.

Dessa forma, adquiriu-se conhecimento na área de robótica por meio de estudos

e da interação com as outras equipes que participaram da competição; assim como ex-

periência na participação em competições. A linguagem Java foi estudada para utilização

na programação da rotina dos robôs, entretanto após a prova de conceito foi mantida

a linguagem em blocos devido aos contras encontrados no uso do Java. Somado a isso,

foi elaborado um protótipo que otimiza as tarefas a serem executadas na competição.

Dessa forma, o objetivo proposto para o projeto foi atingido. E como propostas futuras

sugere-se o estudo aprofundado da linguagem Java para Lego, devido ao seu potencial e

possibilidades.

6

ABSTRACT

The idea of building robots began to take force in the early twentieth century,

with the need to increase productivity and improve product quality. The robotics is going

through a time of continued growth which will, in a short time, allow the development of

intelligent robots, thus making the �ction of ancient man become the reality of today's

man. In this context, MIT (Massachuchetss Institute of Technology), in partnership with

the LEGO Group, created the product LEGO Mindstorms . The set allows you to create

simple robots, capable of executing pre-programmed basic functions, in order to stimulate

the intellectual development of children and youth, in a captivating way.

This study was designed aiming at obtaining more knowledge in robotics branch

and autonomous systems, as well as participation in academic competitions of educational

character. To this end, three stages were designed in which this project is divided, namely:

(a) Proof of Concept, (b) Construction of the robot for competition and (c) Improvements

of the robot after the competition. In the �rst stage, we ful�lled our objective to test the

feasibility of using the components for the construction of a mobile autonomous robot

that could participate in the competition LARC 2014. In the second stage, the goal of

building robots to participate in the competition was concluded, knowledge and experience

through participation was gained and, �nally, improvements to the model were proposed.

In the third and last step, the proposed improvements at the end of the previous step on

the launch, collection and selection systems, were studied, analyzed and implemented, in

order to optimize the functionality of the robot.

Thus, it was acquired knowledge in robotics through studies and interaction with

the other teams that participated in the competition; as well as experience in participating

in competitions. The Java language was studied for use in programming routine of robots,

however, after the proof of concept, it was kept the language in blocks due to the cons

found in the use of Java. Added to this, a prototype that optimized the tasks to be

performed in the competition was drafted. Therefore, the objective proposed for the

project has been reached. For future proposals, it is suggested the in-depth study of the

Java language for Lego, because of its potential and possibilities.

7

1 INTRODUÇÃO

O conceito de máquinas capazes de realizar tarefas sem condução mecânica de

um ser humano tem registros desde a antiguidade clássica. Porém, apenas ao longo do

século XX, em particular em sua segunda metade, foram descobertos e desenvolvidos os

componentes eletro-eletrônicos e os dispositivos computacionais necessários para a imple-

mentação funcional de tais máquinas (robôs) dando origem à sub-área ainda recente da

engenharia, a robótica.

Desde a década de 1960 até os dias atuais, a robótica tem se desenvolvido con-

cretamente de maneira cada vez mais acelerada, tornando-se cada vez mais presente no

cotidiano, servindo a propósitos cada vez mais diversos, sejam domésticos, industriais

ou militares. Entre aplicações futuras na área há, por exemplo, a implementação de

robôs cada vez mais especializados na medicina, permitindo a realização de cirurgias

remotamente ou possibilitando o uso de peças protéticas sensíveis e funcionais.

O impacto da robótica na sociedade atual, assim como as previsões de seus

impactos futuros, desperta o interesse de acadêmicos para o aprofundamento dos conheci-

mentos teóricos e práticos da área. Discussões sobre robótica na academia têm se tornado

cada vez mais frequentes, não apenas em cursos de engenharia, mas também de medicina,

�loso�a e direito, de modo que a relevância do tema já é amplamente reconhecida.

Dentre as formas de demonstração deste interesse acadêmico, existem desa�os

competitivos, estes nas mais diversas categorias e com os mais variados temas, mas todos

com o objetivo comum de desa�ar o competidor. São propostas tarefas, na qual o aluno

poderá ter um contato mais próximo da robótica e utilizar de sua criatividade e conheci-

mento para produzir robôs capazes não só de vencer, mas também de convencer de que a

robótica é um novo ramo a ser explorado pela sociedade.

Neste mundo de competições e desa�os, a LARC (Latin America Robotics Compe-

tition) detém uma categoria especial para kits robóticos padronizados, chamado de SEK

(Standard Educational Kit), onde pode-se utilizar de plataformas como o Lego Mind-

storms EV3, NXT 2.0 ou NXT 1.0.

Nesse contexto, o presente trabalho visa a obtenção de conhecimentos nessa

área, com foco em experiências práticas, de modo a compreender princípios fundamentais

8

e conhecer algumas das ferramentas disponíveis atualmente para o desenvolvimento de

robôs autônomos.

1.1 OBJETIVO

O objetivo da pesquisa é construir um robô móvel autônomo capaz de identi�car

bolas de uma determinada cor (dentre duas opções possíveis: laranja e azul), con�nadas

em uma arena, colhê-las e arremessá-las por sobre uma barreira para uma arena adja-

cente, em um tempo mínimo. Esta é a habilidade básica de um robô para participar de

competições de caráter educacional.[1].

1.2 MOTIVAÇÃO

O trabalho a seguir foi feito visando sempre a melhoria da robótica e a criação de

robôs capazes de auxiliar os seres humanos em cada vez mais tarefas. Apesar do problema

que será estudado não apresentar por si só uma aplicação prática no cotidiano, pretende-

se que os conceitos utilizados para resolvê-lo gerem resultados su�cientemente genéricos

de modo que sejam facilmente adaptados a outras tarefas, podendo assim ser aplicado em

situações mais reais.

1.3 JUSTIFICATIVA

O desenvolvimento deste trabalho possibilita não apenas a obtenção de conheci-

mentos práticos na área de robótica, como também uma maior visibilidade do Instituto

Militar de Engenharia em competições acadêmicas dentro e fora do país.

Através dos processos de planejamento, construção, programação e teste do robô

móvel autônomo, serão melhor compreendidos os desa�os práticos associados à imple-

mentação de projetos em robótica, comumente encontrados tanto na indústria quanto na

academia.

Além disso, a participação na Competição Brasileira de Robótica (CBR) 2014

e na Latin America Robotics Competition (LARC) permitirá aos membros do trabalho

um contato direto com equipes de estudantes brasileiros e extrangeiros, o que cria a

oportunidade para intercâmbio de conhecimentos e para a divulgação do Instituto Militar

de Engenharia no Brasil e na América Latina.

9

1.4 METODOLOGIA

O trabalho será feito em três etapas: (a) Prova de conceito, (b) construção do

robô para a competição e (c) melhorias do robô após a competição.

A prova de conceito tem como objetivo testar e avaliar o funcionamento de

diversos motores e sensores, de forma que sejam veri�cadas as di�culdades, características

e forma de manipulação de cada componente, facilitando as etapas seguintes.

Na segunda etapa foi construído um robô para participar da Latin America

Robotics Competition (LARC), a qual foi realizada no período entre 19 e 22 de outubro

de 2014.

Na terceira e última etapa, de acordo com o desempenho e atuação do robô

construído na etapa dois, serão estudadas e implementadas medidas para otimização e

correção de eventuais erros.

1.5 ESTRUTURA DA MONOGRAFIA

Esta monogra�a é composta por nove capítulos onde, inicialmente, no capítulo

um, é realizada uma introdução. Já no capítulo dois, há uma explicação sobre o kit Lego

Mindstorms utilizado.

No capítulo três será descrito a competição da LARC na categoria SEK, com

regras, arenas e objetivos.

Em seguida, no capítulo quatro, é feita uma explicação sobre o que é uma prova

de conceito, sua utilização e a implementação realizada na parte prática do trabalho. Essa

seção é composta de construção, materiais utilizados e resultados esperados.

A preparação, estratégia adotada, montagem e as partidas da competição serão

mostrados no capítulo cinco.

No sexto capítulo, é descrita a nova prova de conceito, para utilização da lin-

guagem Java na programação da rotina dos robôs, assim como a implementação das

melhorias propostas ao �m da segunda etapa.

No capítulo sete, são apresentados os resultados das três etapas; da primeira prova

de conceito, da competição e, �nalmente, da implementação das melhorias propostas.

No oitavo capítulo situa-se a conclusão de todos os resultados obtidos durante

a execução do projeto, assim como sugestões para pesquisas futuras e possíveis aprofun-

damentos desse projeto. No último capítulo, são fornecidas as referências bibliográ�cas

10

utilizadas na pesquisa.

Após as referências bibliográ�cas encontram-se os anexos a �m de auxiliar partes

da monogra�a.

11

2 LEGO MINDSTORMS

A plataforma de desenvolvimento de robôs Lego Mindstorms foi criação de uma

parceria entre a marca Lego e o MIT(Massaschusetts Institute of Technology) lançada

no ano de 1998. O objetivo dessa linha da Lego é possibilitar de maneira fácil, acessível

e intuitiva atividades na área de robótica para o público, mantendo uma interface de

programação amigável, por meio de uma linguagem própria para este robô, fazendo com

que mesmo leigos em programação possam usufruir de suas funcionalidades[2].

O conjunto Lego Mindstorms conta com diversos sensores, motores e peças dos

conjuntos Lego Technics, além de um microcontrolador central para manipular, adminis-

trar e controlar os demais componentes do robô[3].

2.1 CONTROLADOR LEGO E INTERFACE DE PROGRAMAÇÃO

Para a utilização dos sensores e motores, um microcontrolador central é

necessário. O Lego Mindstorms contém um microcontrolador próprio que reconhece os

motores e sensores disponíveis em seu conjunto, de forma que a programação deste com-

ponente pode ser feita utilizando-se uma linguagem própria desenvolvida pela Lego ou

por APIs em linguagem Java ou C++.

A linguagem própria deste componente conta com uma programação através

de blocos com funcionalidades especí�cas, cuja interface grá�ca está exempli�cada na

Figura 2.1. Laços de repetição, condicionais e cálculos numéricos também podem ser

feitos utilizando estes blocos, entretanto, a quantidade de operações possíveis é limitada.

Dessa forma, é incentivada a utilização de outros tipos de programação, visando elaborar

rotinas mais complexas[4].

12

FIG. 2.1: Interface de Programação Lego - (1) Play(Início do Programa) (2) Controle doServoMotor Grande (3) Loop (4) Operador Lógico (5) Sensor de Distância

FIG. 2.2: Estrutura de Repetição - While

13

FIG. 2.3: Estrutura de Repetição - For

FIG. 2.4: Estrutura de Seleção - If Else

14

Para a criação de uma rotina, colocam-se os blocos em ordem de execução, de

acordo com a ação desejada. Cada bloco apresenta diversas con�gurações, as quais resul-

tam em diferentes respostas do sistema. Por exemplo: Um motor pode ser con�gurado

pra rotacionar duas voltas ou em número de graus, com força total ou 10 % da capacidade,

no sentido horário ou anti-horário.

2.2 SENSORES E MOTORES

O conjunto apresenta diversos tipos de sensores e motores sendo os mais usados

e comuns descritos a seguir:

1. Servomotor grande: Este motor contém um detector de posição que permite que o

sistema saiba exatamente em que angulação se encontra, possibilitando controlar a

movimentação em quantidade de voltas ou em número de graus.

2. Sensor RGB (detector de cor): através de um feixe de luz infravermelho e sua

posterior re�exão nos objetos próximos, este sensor capta a frequência detectada, a

compara com o banco de dados existente e determina qual a cor analisada. Pode-se,

ao invés de utilizar as cores existentes no banco de dados, escolher, numa escala de

0 a 100, o valor ou intervalo desejado.

3. Sensor de toque: Através de um botão, localizado na sua extremidade, ele detecta

contato com objetos, podendo inclusive analisar a força com que este contato é

realizado.

4. Sensor de proximidade com ultrassom: Através de um sistema utilizando ultrassom,

este sensor determina a distância até um objeto próximo por meio do cálculo do

tempo necessário para um pulso ultrassônico emitido retornar, sendo mais preciso

que o sensor de infravermelho.

5. Sensor de proximidade com infravermelho: Através de um sistema utilizando luz

infravermelha, este sensor determina a distância até um objeto próximo por meio

do cálculo de tempo necessário para um pulso eletromagnético (luz infravermelha)

emitido retornar.

6. Giroscópio: Guarda a direção de giro em relação a um estado inicial.

15

7. Servomotor pequeno: Semelhante ao servo motor grande, entretanto consegue

fornecer maior velocidade, porém com menor força[5].

FIG. 2.5: Sensores e Motores - (1) Servomotor Grande (2) Sensor RGB (3) Sensor deToque (4) Sensor Ultrassônico (5) Sensor Infravermelho (6) Giroscópio (7) Servomotor

Pequeno

16

3 LARC - SEK 2014

3.1 OBJETIVO

Cada equipe deve maximizar o número de pontos ao �nal de 5 minutos, onde

bolas azuis no próprio campo valem +100 pontos e bolas laranjas valem -100 pontos.

3.2 REGRAS

O campo consiste de uma arena, de 2m x 2m, de madeira MDF com espessura

de 15 mm, na cor branca, dividida em duas áreas, conforme Figura 3.1. Cada uma

dessas áreas comporta uma equipe de 2 robôs titulares. As dimensões da arena estão

apresentadas na Figura 3.2.

As paredes laterais são formadas por placas de MDF de 15mm de espessura, na

cor branca, com altura de 400mm e �xas sobre a arena. As placas que formam a zona

morta são formadas por placas de MDF de 15mm de espessura, na cor branca, com altura

de 100mm e �xas sobre a arena, Figura 3.3.

No campo, são distribuídas bolinhas de ping-pong (table-tennis) nas cores laranja

e azul. A região denominada como zona morta divide a arena em duas regiões denomi-

nadas áreas. Esta região existe para evitar a colisão entre os robôs adversários. Esta não

poderá ser invadida em hipótese alguma. A sua invasão implica na colocação do robô nas

�áreas de partida� (zonas amarelas). A equipe infratora poderá escolher a zona amarela

para a recolocação do robô e seu reinicio. A arena possui �ta isolante preta de largura

19mm, colada no entorno de todas as paredes e nas �áreas de partida�, conforme Figura

3.1. Estas �tas não estão representadas na Figura 3.2, somente as �áreas de partida� estão

representadas. Existe também, em cada lado da parede da zona morta, uma �ta auxiliar

isolante preta de largura 19mm, distanciada de 50mm da borda da �ta da parede, Figura

3.3(c). As cotas das Figuras estão em mm. A equipe que arremessar bolas na zona morta

e estas permanecerem no local será penalizada em 50 pontos.

17

FIG. 3.1: Esquema das Arenas (a) Vista superior; (b) Vista Tridimensional

FIG. 3.2: Dimensões da Arena

18

FIG. 3.3: (a) Dimensões da Zona Morta; (b) Dimensões da Zona Morta; (c) Fitaauxiliar.

3.2.1 CONFIGURAÇÃO INICIAL DA ARENA

Cada área da arena inicialmente contém 12 bolas sendo 6 (seis) azuis e as demais

laranjas. A posição de cada bola será de�nida por sorteio a cada partida a ser realizada.

As con�gurações de inicio serão iguais e simétricas para cada área de cada equipe. São

19 posições possíveis (exceto os pontos dentro as áreas amarelas), conforme Figura 3.4.

Para o posicionamento inicial das bolas na arena será marcado o centro de cada

quadrado virtual, representados na Figura 3.4. como os cruzamentos das linhas ponti-

lhadas. Para representar o centro do quadrado serão utilizados adesivos no formato de

círculos brancos com diâmetro de 13mm. Estas marcas estarão presentes no cenário e não

poderão ser removidas.

19

FIG. 3.4: Posicionamento inicial das bolas

3.3 ROBÔS

Qualquer robô deve ser um dispositivo móvel autônomo e ser capaz de deslocar-se

através da arena e cumprir os objetivos sem intervenção humana. Só pode ser construído

com kits educacionais do tipo LEGO R© (NXT ou RCX ou EV3), PNCA R©, MECCANO c©ou VEX Robotics R©.

Os elementos do kit educacional não podem ser modi�cados. O não cumprimento

desta cláusula será motivo de desclassi�cação.

Os robôs devem possuir rigidez su�ciente para suportar impactos oriundos dos

lançamentos das bolas do adversário, sem desprendimento de peças. Caso isto ocorra a

equipe poderá reparar o robô, fora da arena, substituindo-o por um robô reserva. Entre-

tanto, o tempo da partida não para.

As equipes não podem propositadamente projetar os robôs para dani�car o robô

adversário.

3.3.1 RESTRIÇÕES DOS ROBÔS

As restrições para os robôs são as seguintes:

20

• As dimensões de cada robô, antes de iniciar cada participação, não deve ultrapassar

o tamanho de um cubo com aresta de 250mm. Uma vez iniciada a partida, após o

acionamento do cronômetro, esta restrição deixa de valer.

• Cada robô pode ter a quantidade máxima de 6 sensores e de 6 atuadores.

• Não deve haver qualquer tipo de comunicação com dispositivos exteriores. O des-

respeito desta condição é motivo de desclassi�cação. A única forma de comunicação

autorizada é entre os robôs na arena.

• O robôs não devem destruir o cenário. O desrespeito desta condição é motivo de

desclassi�cação.

3.4 PARTIDA

Uma partida, segundo as regras, ocorre com duas equipes, uma em cada área da

arena. Cada equipe deve competir com até 2 robôs cooperativos e autônomos dentro da

arena e possuir quantos robôs reservas quiser. Os robôs não precisam, necessariamente,

ser iguais.

Para inicio de cada partida, haverá em cada área 12 bolinhas, sendo 6 delas azuis

e as demais laranjas. Cada robô deverá sair das áreas denominadas �áreas de partida�,

representadas pelos quadrados amarelos, Figura 3.1.

Cada partida ocorre em 5 minutos corridos. Cada equipe poderá realizar ape-

nas 2 (duas) substituições durante a partida entre os dois robôs titulares e os reservas.

As substituições podem ser feitas em qualquer momento e para qualquer modi�cação

no robô (peças, formato, programação, etc), desde que mantenha as restrições descritas

anteriormente.

Os robôs podem ser projetados para bloquear o ataque do adversário. Porém,

nenhum robô, nem mesmo o robô bloqueador, poderá �car deliberadamente �xo na mesma

posição. Caso isto ocorra, este robô será eliminado da partida pela aplicação de cartão

vermelho e não poderá mais ser usado como robô reserva, devendo ser retido pelo juiz.

O tempo não para, nem mesmo para substituições. O membro da equipe que

desejar substituição e/ou manutenção deve pedir autorização ao juiz e informar o jogador

que sai e o jogador que entra. O jogador sempre entra na partida em uma das �áreas de

partida� (zonas amarelas). A escolha é realizada pela equipe. Se na retirada ou inserção

21

do jogador (robô) pelo membro da equipe, seja por substituição, penalidade ou mesmo

por invasão da zona morta, e tiver uma ou várias bolas adversárias colididas contra o

corpo do membro da equipe ou do robô, esta será mantida dentro do cenário do time que

estiver fazendo a substituição e pontuada normalmente. Caso esta caia na zona morta

ou fora da arena, esta será informada a equipe e guardada para ser pontuada no �nal da

partida.

Caso o robô, ao ser retirado da arena por penalidade ou substituição, contenha

bolas na sua estrutura estas serão retiradas do robô e guardadas para serem pontuadas

no �nal da partida se forem laranja. Se forem azuis estas não serão pontuadas. Estas

bolas não retornam para a arena.

A partida será �nalizada ao término de 5 minutos ou caso a equipe manifeste que

deseja encerrar sua participação na rodada, con�gurando-se uma desistência.

3.4.1 SISTEMA DE PONTUAÇÃO

A competição considera o sistema de pontuação e de parafusos. Durante uma

partida, cada equipe começa com 0 pontos. A bola pode alcançar a zona adversária de

qualquer maneira e estratégia desde que obedeça as regras deste regulamento.

Ao �nal dos 5 minutos, cada equipe receberá alterações na sua pontuação inicial

conforme a regra abaixo:

• cada bolinha azul na área da equipe: + 100 pontos

• bolinha laranja na área da equipe: - 100 pontos

A equipe pode ainda sofrer penalidades:

• Será considerado -50 pontos para cada bolinha laranja, ou azul, arremessada para

fora da arena que não tenha sido direcionada para a área adversária.

• Será considerado -50 pontos para cada bolinha que permanecer na zona morta após

o arremesso.

• Será considerado -100 pontos qualquer invasão visível da área de zona morta pelo

robô (garra, roda, parafuso, �o, etc). Ao ocorrer a invasão e a equipe receber a

penalidade, o robô deverá voltar para a área de partida (zona amarela). A escolha

da zona amarela �ca a critério da equipe.

22

Quem conseguir manter mais pontos ao �nal de 5 minutos é declarado vencedor.

Caso as duas equipes �quem com a mesma pontuação, é decretado empate.

Cada vitória atribui 3 parafusos para a equipe vencedora e 1 parafuso para

a equipe perdedora. Se houver empate, cada equipe recebe 2 parafusos. Caso haja

desistência de alguma equipe durante a partida, ou W.O., a equipe que não desistiu

receberá 3 parafusos. A equipe que desistiu recebe 0 (zero) parafusos

Considera-se desistência da partida quando um membro da equipe declara de-

sistência.

Considera-se W.O. quando a equipe não apresenta os robôs na arena para o início

da partida.

3.4.2 PENALIZAÇÕES POR CARTÃO VERMELHO

Para garantir um jogo dinâmico, penalidades podem ser dadas as equipes. Caso

algum robô �que deliberadamente, por interpretação do juiz, �xo em uma posição, seja

de bloqueio ou no meio da arena, o robô deverá receber CARTÂO VERMELHO. O robô

que recebe cartão vermelho deve deixar a partida, ser substituído por outro robô (caso

a equipe possua numero de substituições possíveis) e contará como 1 (uma) substituição

para a equipe. Este robô não poderá mais ser usado na partida, nem como robô reserva,

devendo ser retido pelo juiz até o �nal da partida.

3.4.3 CLASSIFICAÇÃO DAS EQUIPES EM GRUPOS

Para que as equipes possam ser classi�cadas em grupos, inicialmente ocorre a

pré-classi�catória. Cada equipe entra na arena, em apenas 1 das áreas, sem adversário,

e tem o tempo de 2 minutos para enviar o máximo de bolinhas laranjas possíveis para a

outra área da arena. Serão 19 bolinhas laranjas.

Conta-se a quantidade de bolinhas lançadas em 2 minutos para a outra área

ou marca-se o tempo que a equipe concluiu o lançamento das 19 bolinhas. Com isso, é

realizado um ranking das melhores equipes pela quantidade de bolinhas enviadas para o

outro lado da arena, tendo como critério de desempate o menor tempo de envio da 1a.

Bolinha (conta-se o tempo do inicio da partida até o momento da 1a. Bolinha laranja

bater no campo adversário).

Com este ranking, deve-se criar 4 grandes conjuntos, chamados de conjunto A

23

(os 25% melhores equipes), conjunto B, conjunto C e conjunto D (os 25% piores equipes

do ranking). Com isso, cada equipe do conjunto A se torna cabeça de chave de um grupo.

E cada grupo terá 1 equipe de cada conjunto (B, C e D) sorteados.

Critério de desempate para as fases 1 e 2 seguintes

Em caso de empate, serão realizadas partidas extras entre as equipes. Se ocor-

rer empate na partida extra, as equipes realizarão o mesmo processo da etapa pré-

classi�catória, porém com tempo menor. Quem conseguir jogar mais bolinhas laranjas

para o campo adversário em 1 minuto será declarado o vencedor do desempate. Se o

empate ainda assim prevalecer, será realizado sorteio.

1. primeira fase da competição - disputa nos grupos

Com os grupos formados, cada equipe compete com todas as equipes dentro

do seu grupo. Classi�cam-se para as próximas fases apenas 2 equipes de cada grupo

que obtiverem o maior numero de parafusos na 1a Fase. A equipe melhor classi�cada

de cada grupo avança direto para a 3a fase. A segunda equipe disputa a repescagem.

Usa-se o critério de desempate caso haja equipes empatadas.

2. segunda fase da competição - Repescagem

As equipes que �caram em segundo lugar de cada grupo disputam a 2a Fase

da competição. Nesta fase as equipes se enfrentam em eliminatórias. Quem ganhar

permanece e avança para a 3a fase, quem perder estará eliminado da competição.

Usa-se o critério de desempate caso a partida termine empatada.

3. terceira fase da competição - eliminatórias

A terceira fase ocorre com a formação de equipes vindas da 1a. Fase e da 2a.

Fase. Estas equipes devem compor um sistema de eliminatórias de oitavas ou quartas

de �nal. Também por sorteio, equipes se enfrentam visando alcançar as semi�nais

e �nais do torneio. Nas fases eliminatórias, se ocorrer empate, será realizada uma

nova partida entre as equipes. Se ocorrer empate após esta partida extra, o vencedor

será o que obteve o maior número de vitórias na 1a fase. Mantendo-se o empate,

realiza-se o mesmo processo da etapa pré-classi�catória. Quem conseguir jogar mais

bolinhas laranja para o campo adversário em 1 minuto será declarado o vencedor.

Se o empate ainda assim prevalecer, será realizado sorteio.

24

3.5 REQUISITOS PARA PARTICIPAR DA COMPETIÇÃO

Os interessados em participar da Competição Latino Americana de Robótica

LARC categoria IEEE SEK devem constituir equipes formadas por alunos de gradua-

ção de qualquer instituição educativa de qualquer país. Estudantes de Ensino Médio

também podem participar. Para se inscrever, os times deverão submeter um documento

descrevendo o desenvolvimento e o funcionamento do robô (TDP). Este TDP será utilizado

para que os ganhadores dos primeiros lugares façam um breve relato para os demais

competidores. Veri�car as datas de envio no site do evento.

O TDP da nossa equipe encontra-se no anexo.

3.6 O JÚRI

Este será composto por um membro da equipe organizadora da competição co-

nhecedor das regras, por dois auxiliares da organização e por dois membros das equipes

que não estejam competindo naquela partida, escolhidos antes do inicio da mesma.

3.7 SITUAÇÕES EXTRAORDINÁRIAS DURANTE A COMPETIÇÃO

Caso ocorra alguma situação não prevista nas regras ou na pontuação, caberá aos

juízes e aos organizadores da competição analisarem o caso e decidirem dentro da maior

imparcialidade possível.

25

4 PROVA DE CONCEITO

4.1 OBJETIVO DA PROVA DE CONCEITO

O objetivo desta prova de conceito é veri�car o funcionamento e viabilidade do

uso dos sensores e motores do conjunto Lego Mindstorms EV3 os quais julga-se necessários

para a construção do robô visando a competição da LARC. Os sensores e motores testados

são: Sensor RGB, sensor de toque, sensor de proximidade com infravermelho, sensor de

proximidade ultrassônico, servomotores grandes e servo motor pequeno[7].

4.2 MATERIAIS UTILIZADOS E CONSTRUÇÃO

Para a prova de conceito, foi construído um robô utilizando o microcontrolador

como base central, uma disposição de rodas em forma de triciclo, com as duas rodas

traseiras conectadas aos servomotores grandes e uma roda omnidirecional na frente. Acima

da roda omnidirecional, foram colocados os dois sensores de distância, o ultrassônico

voltado para a frente e o infravermelho voltado para baixo. Sobre o microcontrolador foi

colocado o sensor RGB e em sua lateral o servomotor pequeno, voltado para cima.

As visões lateral e frontal do robô construído na PoC podem ser vistas nas Figura

4.1 e Figura 4.2.

FIG. 4.1: Robô para a prova de conceito - visão lateral

26

FIG. 4.2: Robô para a prova de conceito - visão frontal

A rotina do robô foi concebida de tal forma que existisse um loop inicial com

dois switches encadeados, um onde o detector veri�casse qual a distância do objeto mais

próximo a frente e, caso fosse menor que seis centímetros, o robô voltaria meia volta

dos motores e em seguida viraria para a direita, caso contrário, andaria para frente meia

volta. O segundo switch veri�cava se a distância até o ponto mais próximo do sensor

de infravermelho era menor que vinte, numa escala de 0 a 100, e, em caso positivo, não

executaria nada. Já em caso negativo, daria meia volta para traz e viraria para a direita.

Em seguida, o robô pararia após um tempo de trinta segundos, entrando num

loop de espera o qual seria terminado com um estímulo do sensor de toque. Após a

ativação desse, o sensor RBG ligaria e determinaria a cor do objeto a sua frente, entrando

num switch onde, de acordo com a cor, o sistema emitiria um som informando o resultado

e imprimiria no visor o nome da cor.

Finalmente, após cinco execuções do sensor de RGB, o sistema entraria numa

espera de 1 segundo e giraria uma bandeira, através da ativação do servomotor pequeno,

com três voltas.

A rotina utilizada para o robô na PoC está no �uxograma da Figura 4.3.

27

FIG. 4.3: Fluxograma da Prova de Conceito

4.3 RESULTADOS ESPERADOS

Com esta estrutura, esperava-se que o robô se movesse durante um período de

trinta segundos de forma a não chocar-se contra a parede, testando a funcionalidade

do sensor de proximidade ultrassônico; que não caísse da mesa, testando o sensor de

proximidade infravermelho; e que, após os trinta segundos, o robô parasse e ativasse um

loop de espera, o qual seria interrompido através da ativação do sensor de toque. Logo

após, o sensor RGB seria ativado, detectando a cor de um objeto colocado a sua frente

e fornecendo o sinal para o robô emitir o som da cor detectada e escrever o seu nome no

seu visor. Esse loop de espera e detecção de cor seria repetido cinco vezes e �nalmente,

após aguardar um tempo de dois segundos, giraria uma bandeira colocada no servomotor

pequeno e a rotina seria encerrada.

28

5 COMPETIÇÃO

Nesta etapa, foi construído um robô visando a competição da LARC-SEK 2014,

de forma que a estratégia, montagem, estrutura e lógica computacional foram baseados

nos conhecimentos da equipe, na quantidade de materiais disponíveis e no tempo até o

início da competição.

Inicialmente, apenas 2 kits do Lego MindStorms EV3 estavam disponíveis, o que

di�cultou e restringiu bastante a elaboração de uma estratégia e o início da montagem de

um robô que pudesse participar da competição.

Faltando um mês para a competição, obteve-se mais um kit de Lego NXT e

faltando uma semana, mais 2 kits de Lego EV3.

Em relação ao tempo disponível para a execução do projeto, houve cerca de 2

meses para preparação, porém, como dito acima, os materiais foram chegando aos poucos.

Ainda assim, manteve-se o plano inicial, visto que a elaboração de uma nova estratégia e

a montagem de novos robôs poderia demandar mais tempo que o disponível.

5.1 ESTRATÉGIA

Devido a limitação dos recursos referentes a material (Lego) e tempo, teve-se que

adotar uma estratégia em que fosse possível executar as tarefas principais, mantendo a

estrutura dos robôs o mais simples possível. Assim, decidiu-se construir dois robôs, um

que seria o selecionador e arremessador, e outro que seria o coletor.

A estratégia adotada seria a de manter o robô arremessador no canto da arena,

percorrendo apenas o trajeto da sua posição inicial até a barreira de 10cm e voltando até a

posição inicial, recolhendo o máximo de bolas no caminho, selecionando-as, arremessando

as laranjas no campo adversário e largando as azuis no campo aliado.

Para auxiliar o robô arremessador, o robô coletor seria projetado para ser bastante

ágil, de modo a percorrer o campo com máxima e�ciência e assim, trazer o maior número

de bolas possível para próximo do robô coletor.

29

5.2 MONTAGEM

Iniciou-se pelo robô arremessador, montando uma estrutura retangular com base

nos dois microcontroladores disponíveis. Colocou-se uma catapulta em seu interior, de

forma que foi idealizada uma estrutura onde a seleção das bolas se daria antes destas

entrarem na catapulta.

Nas Figura 5.1 pode-se observar o primeiro protótipo para a competição.

FIG. 5.1: Primeiro Protótipo - Visão Superior

Entretanto, a estrutura deste protótipo era instável e o sistema de seleção constru-

ído não era e�ciente, pois a presença de diversas bolas travava o sistema, e era necessário

uma posição muito especí�ca de trajetória da bola, para que esta pudesse ser capturada,

selecionada e colocada na catapulta.

Devido às di�culdades encontradas no primeiro protótipo, foi construído um

segundo robô, com uma estrutura muito mais rígida e com o sistema de seleção das

30

bolas localizado atrás da catapulta, de forma que foi criada uma lógica onde, caso a bola

fosse laranja, esta era arremessada com força para o outro lado e, caso fosse azul, apenas

levantava-se a pá da catapulta para que a bola escorregasse atrás do robô, dentro do campo

da própria equipe. As Figuras 5.2 e 5.3 mostram o segundo protótipo em construção.

FIG. 5.2: Protótipo 2 - Visão Superior

FIG. 5.3: Protótipo 2 - Visão Frontal

31

Para a captura das bolas, foi montado um sistema contendo 3 garras, duas para

�abraçar� as bolas e outra para empurrar alguma delas na catapulta.

Para a localização do robô foram colocados três sensores de distância, dois ultras-

sônicos na frente e um infravermelho atrás, para que o robô identi�casse obstáculos tanto

na ida para frente quanto na volta. As Figuras 5.4, 5.5 e 5.6 mostram o robô arremessador

�nalizado.

FIG. 5.4: Robô Arremessador(Final) - Visão Superior

32

FIG. 5.5: Robô Arremessador(Final) - Visão Frontal

FIG. 5.6: Robô Arremessador(Final) - Visão Traseira

Ao mesmo tempo, foi construído o robô coletor, que tinha como base um micro-

controlador, dispondo de dois grandes braços que se abriam com o inicio da partida. Este

robô também continha um sensor de distância para identi�car sua posição na arena. As

imagens do robô coletor �nalizado podem ser vistas nas Figuras 5.7 , 5.8, 5.9 e 5.10.

33

FIG. 5.7: Robô Coletor(Final) - Visão Superior - Aberto

FIG. 5.8: Robô Coletor(Final) - Visão Superior

34

FIG. 5.9: Robô Coletor(Final) - Visão Frontal

FIG. 5.10: Robô Coletor(Final) - Visão Frontal - Aberto

5.3 LÓGICA

A lógica dos robôs foi desenvolvida utilizando a linguagem de programação em

blocos da Lego, com o auxílio da própria interface grá�ca de programação disponível no

site da Lego.

Para calcular as distâncias, força de arremesso, ângulo de arremesso, ângulo de

abertura e fechamento das garras, foram utilizados métodos heurísticos, com o auxílio de

uma arena montada no laboratório de robótica do Instituto Militar de Engenharia.

A rotina criada para os robôs foram as seguintes:

35

5.3.1 ROBÔ ARREMESSADOR

Partindo da posição inicial (Qualquer um dos quadrados amarelos) o robô iniciaria

um movimento para frente, até que �casse próximo (cerca de 10cm) a parede central, onde

pararia por 2 segundos, ligaria o sensor de cor e de acordo com a cor realizaria uma ação

diferente.

Caso a cor fosse azul, a catapulta apenas levantaria sua pá de arremesso até que

a bola pudesse escorregar a frente do robô e se a bola fosse laranja, a pá levantaria cerca

de 3cm e em seguida giraria 120 graus com força total para arremessar a bola no campo

adversário.

Após o arremesso, o robô voltaria e andaria até que �casse próximo (cerca de

8cm) da parade frontal, onde pararia e ativaria as garras de forma que duas se fechariam

primeiro para capturar o maior número de bolas possível e depois outra garra fecharia

para que uma das bolas capturada encaixasse na catapulta.

Após colocar a bola na catapulta, o robô fecharia as garras e andaria para a

frente novamente, reiniciando a rotina.

O programa �nal do robô arremessador pode ser visto nos anexos e um �uxograma

da rotina encontra-se na Figura 5.11.

FIG. 5.11: Fluxograma do Robô Arremessador

5.3.2 ROBÔ COLETOR

O robô coletor também teria sua lógica escrita com programação em blocos,

porém com uma rotina muito mais simples que a do robô arremessador. Teria uma se-

36

quência de movimentos onde, partindo da posição inicial (de um dos quadrados amarelos),

moveria-se para o canto oposto, em direção ao outro quadrado amarelo, abrindo os braços

no caminho, e parando um pouco antes da trilha onde o robô arremessador pudesse passar.

Após isso, fecharia seus braços e daria meia volta, chegando até a lateral da

arena, onde daria outra meia volta e iniciaria sua rotina de novo, andando em direção ao

lado onde estava localizado o robô arremessador, abrindo os braços e parando um pouco

antes da trilha do percurso do robô arremessador.

Fotos da posição inicial do robô arremessador e de uma posição intermediária,

com o robô coletor trazendo bolas para o arremessador e o arremessador próximo a parede

central encontram-se nas Figuras 5.12 e 5.13.

FIG. 5.12: Posição Inicial do Robô Arremessador

FIG. 5.13: Posição Intermediária dos Robôs

37

5.4 PARTIDAS

Na etapa classi�catória, o robô arremessador apresentou problemas em relação a

execução de sua rotina. Dessa forma, não conseguiu realizar nenhum lançamento, o que

ocasionou a classi�cação da equipe como 'D'. Já nas fases de grupos, no primeiro jogo, esse

robô apresentou o mesmo problema, não conseguindo novamente realizar lançamentos.

Simultaneamente, o robô coletor também apresentou problemas quanto a execução da

sua rotina, o que provocava choques com os limites da arena. Consequentemente, a

equipe foi derrotada.

Após o primeiro jogo da fase de grupos, após trocas de informações com outras

equipes, as quais sempre se mostraram prestativas e dispostas a ajudar, foi levantada

a hipótese de que os sensores ultrassônicos poderiam estar causando interferência uns

nos outros. Portanto, foi trocado um sensor ultrassônico do robô arremessador por um

infravermelho, enquanto a rotina do robô coletor foi aperfeiçoada. Com isso, a equipe

conseguiu vencer a segunda partida.

Já na terceira partida, os dois robôs realizaram suas rotinas como esperado,

realizando diversos lançamentos efetivos. Entretanto, não foi vitoriosa, visto que a equipe

adversária, que futuramente seria vice campeã, era mais e�ciente. Com isso, a equipe

�cou em terceiro lugar do grupo, sendo a décima sétima colocada, de trinta equipes.

Dessa forma, a equipe estaria eliminada da competição. Entretanto, a décima

sexta equipe, não acreditando que iria se classi�car, desmontou os seus robôs e não tinha

condições de participar da nova fase. Consequentemente, a nossa equipe foi convidada

novamente a participar. Foi jogada uma nova partida, contra a equipe campeã geral da

primeira fase, a qual resultou em derrota. Assim, foi encerrada a primeira participação

da equipe na competição, em décimo sexto lugar.

38

6 MELHORIAS

Após a conclusão da segunda etapa(Competição), com a construção dos robôs

para a competição e a efetiva participação, além do contato com outros projetos e equipes

na competição e a análise do funcionamento e comportamento dos robôs, é possível propor

melhorias no projeto inicial.

Inicialmente propôs-se o seguinte:

1. Estudo e implementação da linguagem Java na programação dos robôs;

2. No sistema de captura, otimizar a coleta e captura de múltiplas bolas simultanea-

mente, utilizando a arena como auxílio;

3. Utilizar um sistema seletor isoladamente, de forma que este mesmo sistema atue na

exclusão de bolas azuis, sem necessitar do auxílio do sistema de lançamento

4. Utilizar um sistema de lançamento mais rápido, sem a necessidade de manipular

bolas azuis.

6.1 LEJOS

Para veri�car a viabilidade e condições da utilização do Lejos, o que, por sua vez,

possibilitará a programação em linguagem Java, uma prova de conceito será feita testando

as funcionalidades básicas do visor, som, sensor de toque, sensor de cores e servomotor

grande. Para facilitar a compreensão, a PoC será dividida em três etapas: Instalação,

Testes, Adversidades e Resultados.

6.1.1 INSTALAÇÃO

De acordo com a proposta de melhoria, inicialmente será feita uma Prova de

Conceito(PoC), da biblioteca Lejos, de programação Lego na linguagem Java.

O passo inicial da PoC é o processo de instalação, tanto da biblioteca quanto

da modi�cação do Firmware do microcontrolador Lego para que seja compatível com

programas escritos em Java.

39

Para a instalação do Lejos, é preciso adequar o ambiente do computa-

dor para a programação em Java, de modo que, inicialmente, precisa-se insta-

lar o Java SDK, que é obtido através do endereço http://www.oracle.com/technet

work/java/javase/downloads/jdk8-downloads-2133151.html (acessado em 01/02/15).

Em seguida precisa-se de um arquivo chamado Java SE embeded for

LegoMindstorms EV3 que pode ser encontrado em http://www.oracle.com/technet

work/java/embedded/downloads/javase/javaseemeddedev3-1982511.html (acessado em

01/02/15) que será importante para a modi�cação do Firmware do microcontrolador.

Agora pode-se instalar o Lejos, que é obtido em http://sourceforge.net

/projects/ev3.lejos.p/�les/ (acessado em 01/02/15), sendo que, no �m da instalação, é

possível criar um arquivo para instalar o Firmware do Lejos, utilizando um cartão SD e

o arquivo Java SE embeded for LegoMindstorms EV3 baixado anteriormente.

Com o Lejos instalado precisa-se da instalação do Lejos plugin no

Eclipse, através da aba ajuda > instalar novo software, adicionando como endereço

http://lejos.sourceforge.net/tools/eclipse/plugin/ev3 (acessado em 01/02/15) e insta-

lando o plugin do Lejos. Finalmente, basta inserir o cartão SD no microcontrolador EV3

e será modi�cado automaticamente o Firmaware do Lejos para possibilitar a programação

em Java.

Maiores informações sobre a instalação pode ser obtida no vídeo tutorial em

http://lejos.sourceforge.net/tools/eclipse/plugin/ev3 (acessado em 01/02/15).

É interessante comentar que nas versões mais atuais do plugin do Lejos para o

Eclipse, existe uma interface grá�ca para auxiliar alguns testes mais simples.

A interface grá�ca e a nova funcionalidade do plugin no Eclipse são ilustradas na

FIG 6.1.

40

FIG. 6.1: Interface Grá�ca Lejos no Eclipse e Nova Funcionalidade do Plugin

6.1.2 TESTES

Para a programação, utilizou-se a API da Lejos[8] como referência, lembrando

que as classes utilizadas deveriam ser as especí�cas para o controlador modelo EV3.

Para o teste de display, foi incluído uma impressão de Hello World na tela,

utilizando a classe Brick, que se refere aos componentes do controlador, sendo que no

método getGraphicsLCD() pegamos o display e imprimimos com o método drawString().

FIG. 6.2: Programa do Teste com o Display

Para o teste de som, foi utilizado a classe brick com o método getAudio() para

pegar os componentes de som do controlador e o método playNote() para criar o som de

uma nota de piano.

41

FIG. 6.3: Programa do Teste com o Som

O teste do sensor de toque consistiu em criar uma mensagem de texto no display

e encerrar o programa quando o botão fosse pressionado.

O controle e acesso aos sensores são diferenciados em relação à manipulação dos

componentes já inclusos no próprio controlador(som e display), pois para instanciar um

sensor é preciso resgatar a porta em que ele está conectado, através do método getPort()

da classe brick, depois instanciar uma classe EV3*sensor correspondente, utilizando a

porta resgatada como parâmetro do construtor.

Entretanto, a coleta de dados dos sensores é complexa, pois cada sensor tem um

método especí�co, no caso do sensor de toque o método getTouchMode(), que retorna

um SampleProvider. Este sample provider tem um método fetchSample() que tem como

entrada um �oat[] e um int, onde o �oat[] é um vetor de �oats que armazenará os dados

coletados e o int é o o�set do vetor.

Cada método exige um �oat[] de tamanho diferente de modo que é preciso recorrer

a API o�cial[8] e veri�car quais os retornos de cada método. No caso do sensor de toque,

o método getTouchMode() tem o retorno uma variável que tem valor 0 se o botão não for

pressionado e 1 se o botão for pressionado.

O código do teste do sensor de toque está ilustrado na FIG 6.4.

42

FIG. 6.4: Programa do Teste com o Sensor de Toque

O sensor de cor, assim como o sensor de toque, precisa de métodos que retornem

um sampleProvider, de forma que utilizou-se o método getColorIdMode(), que retorna

uma escala de cor, tabelada em números inteiros.

No teste, foi impresso na tela o inteiro coletado pelo sensor de cor por 6 vezes.

FIG. 6.5: Programa do Teste com o Sensor de Cor

43

Com o servomotor grande, o teste feito foi o de manipulação de velocidade e

manipulação de aceleração (funcionalidade que não foi encontrada na programação em

blocos, tanto na documentação o�cial, quanto em fóruns de discussão).

Para a instanciação do servomotor foi utilizada a classe

EV3LargeRegulatedMotor, que exige como parâmetro do construtor a porta onde

o motor foi conectado.

Os métodos setSpeed() e setAcceleleration() admitem como parâmetros a ve-

locidade e aceleração desejados, em graus e o método rotate() admite como parâmetro

os graus de rotação desejado, podendo ser um valor negativo para rotacionar na direção

oposta. A FIG 6.6 mostra o código usado.

FIG. 6.6: Programa do Teste com o Servomotor Grande

6.1.3 PRÓS E CONTRAS

Na prova de conceito foi possível perceber que o uso do Lejos permite customiza-

ções e controle maiores que na linguagem em blocos, como por exemplo a possibilidade

de se manipular a aceleração do servomotor.

Dentre os componentes testados, todas as funcionalidades básicas foram possíveis

de ser executadas de modo que a programação em Java é viável.

Além disso, a adição de uma linguagem poderosa como o Java permite que seja

possível utilizar diversos recursos adicionais, como por exemplo o tratamento mais elabo-

44

rado em loops, sincronização de leitura de diversos sensores e medições por amostragem,

como calcular a distância por meio de 100 medições, as quais são somadas e o resultado

dividido por 100, obtendo-se assim a média, de forma que a precisão torna-se muito mais

con�ável, dado que um fator externo que altere o valor de uma medida não terá in�uência

signi�cativa no resultado �nal.

Entretanto, embora o uso da linguagem Java adicione maior controle, funcionali-

dades e customizações que não são possíveis na linguagem em blocos, o uso do Lejos trouxe

diversas adversidades. Entre elas, a di�culdade de se conseguir estabelecer a comunicação

entre o computador e o controlador, pois a instalação do LeJOS faz com que seja necessário

um driver especí�co para reconhecimento através da porta USB.

Outro fator complicador é o fato do Lejos ter sido inicialmente feito para a

plataforma NXT e agora estarem adicionando classes para suportar a plataforma EV3,

de modo que a documentação das classes do EV3 carece de informações vitais para o

desenvolvimento em Java.

Adicionado a isto, existe o inconveniente da necessidade do cartão SD estar

sempre no controlador para habilitar o Firmware necessário para a compatibilidade do

Lejos, sendo que se houver uma cadeia com 5 controladores, serão necessários 5 cartões

SD corretamente con�gurados.

Por �m, até o término desta pesquisa, não foi encontrada uma forma de habilitar

a comunicação por bluetooth entre os controladores, o que impossibilita a formação de

cadeias entre os mesmos.

6.1.4 RESULTADOS

A partir do balanceamento entre os prós e contras, foi decidido que a programação

do protótipo de melhoria será feita com programação em blocos devido às adversidades

encontradas no uso do Lejos, principalmente do falha na comunicação entre microcontro-

ladores, inviabilizando as construção de cadeias em série, e ao fato de ter sido encontrado

material consistente no desenvolvimento em blocos[9], além do auxílio e informações de

outras equipes que estiveram na LARC 2014.

45

6.2 PROTÓTIPO

Visando implementar e testar as melhorias propostas ao �nal da segunda etapa

(competição), construiu-se um novo protótipo. A disposição de novos materiais, tanto em

relação a novas peças, quanto em relação quantidade de motores e sensores, assim como o

conhecimento e experiência adquiridos pela equipe nas etapas anteriores, permitiram uma

maior amplitude e �exibilidade na concepção e montagem do novo modelo. Em oposição

ao modelo anterior, em que havia dois robôs, os quais dividiam as tarefas de coletar,

capturar, selecionar e lançar entre si; no atual, há apenas um robô, o qual executa todas

as tarefas previstas, o que torna o processo mais independente.

Para a montagem foram utilizados um total de 3 kits Lego Mindstorms EV3,

com 4 servomotores grandes, 2 servomotores pequenos, 2 sensores de toque, 1 sensor de

distância por ultrassom e um sensor RGB de cor.

6.2.1 SISTEMA DE CAPTURA

Diferentemente do modelo anterior, em que o robô arremessador dependia do

robô coletor para realizar a coleta das bolas e, desse modo poder capturá-las, o novo

robô percorre o campo para coletá-las. Para a captura, substitui-se as três garras por

uma pá, semelhante àquela de escavadeiras. Esta se encontra inicialmente elevada, sendo

posteriormente abaixada até o nível do campo. Após isso, o robô se movimenta até a

parede, imprensando as bolas contra a mesma, fazendo com que estas se �xem na pá.

Este percebe que atingiu a parede no momento em que os sensores de toque, que estão

posicionados transversalmente a linha vertical da pá (paralelos ao solo), detectam que

houve contato com a mesma. Em seguida, o protótipo se afasta o su�ciente para que a pá

possa ser elevada a posição inicial, sem se chocar contra a parede. Por meio do emprego

de dois servomotores grandes, realiza-se a elevação da pá em alta velocidade, fazendo uso

do momento gerado para mantê-las na mesma posição até o instante em que chegam ao

topo do robô, quando a pá pára e as bolas passam a se situar em uma rampa, a qual as

levará para o sistema de seleção.

46

FIG. 6.7: Sistema de Captura - Visão Lateral 1

FIG. 6.8: Sistema de Captura - Visão Lateral 2

47

FIG. 6.9: Sistema de Captura - Visão Superior 1

FIG. 6.10: Sistema de Captura - Visão Superior 2

6.2.2 SISTEMA DE SELEÇÃO

No modelo anterior, como já foi dito, a seleção era feita na própria catapulta.

Nessa nova entapa, entretanto a seleção é realizada independentemente do sistema de

48

lançamento. Após serem posicionadas pela pá no topo do robô, estas deslizam por uma

rampa até chegar ao sistema selecionador. Este é formado por uma garra quadrangular

com pontas nos vértices de modo que consiga segurar e movimentar as bolinhas. Assim

que a bola chega a ela, um sensor de cor a analisa, determinando se é azul ou laranja.

Caso seja azul, a garra gira de modo a jogar a bolinha para fora do robô e de volta no

campo. Se for laranja, a garra gira de modo a jogar a bolinha em outra rampa, dentro do

robô, a qual direciona a bola para o sistema de lançamento.

FIG. 6.11: Sistema de Seleção

49

FIG. 6.12: Sistemas de Seleção e Captura

6.2.3 SISTEMA DE LANÇAMENTO

Na etapa anterior, o lançamento era feito por uma catapulta, a qual lançava uma

bola por vez e tornava o procedimento lento, uma vez que apenas uma bola era capturada,

selecionada e lançada por vez. No novo modelo, é utilizada uma garra para lançamento

das bolas, a qual é girada em um plano vertical ao solo, impulsionando a bola por uma

rampa de lançamento. Embora lance apenas uma bola por vez, o fato de girar 360 graus

no plano vertical, aliado ao fato dos sistemas serem totalmente independentes, permite

que um número consideravelmente maior de bolas seja lançada em um menor tempo, uma

vez que a existência de rampas dentro do robô promove espaço de armazenamento prévio

para as bolas. Ou seja, as bolas laranjas que já foram selecionadas apenas esperam ser

lançadas e, enquanto o são, o robô, simultaneamente, já está coletando, capturando e

selecionando outras.

50

FIG. 6.13: Sistema de Lançamento - Visão Lateral 1

FIG. 6.14: Sistema de Lançamento - Visão Lateral 2

51

FIG. 6.15: Sistema de Lançamento - Visão Traseira

6.2.4 ROTINA E FLUXOGRAMA

Com o robô construído, falta apenas a parte relacionada a programação que,

como dito anteriormente no resultado da Prova de Conceito com LeJOS, será feita em

linguagem de blocos.

A rotina testada consiste numa parte do que seria a rotina completa da com-

petição, porém com todos os passos e ações necessárias, captura, seleção, descarte(bolas

azuis) e arremesso(bolas laranjas), faltando apenas alguns ajustes de mudanças de direções

para se atingir a rotina completa de uma partida o�cial.

O programa consiste em inicialmente baixar a pá de captura e andar para frente,

para que o robô inicie os contatos com as bolas espalhadas pela arena, seguindo até que o

sensor de toque identi�que a parede quando pressionado. Neste momento, com o auxílio

da parede, diversas bolas(no máximo 4) são encaixadas na pá coletora. Em seguido o

robô recua um pouco e sobe a pá para que as bolas capturadas sejam armazenadas na

parte superior.

Para que a própria pá não seja um obstáculo para o �uxo das bolas dentro do

robô, faz-se com que a pá abaixe novamente. Após isso o robô recua até chegar a 5cm da

parede traseira, identi�cada através do sensor de distância ultrassônico. O robô inicia o

52

procedimento de seleção, por 6 vezes, fazendo com que o sensor de cor identi�que a cor da

bola selecionada e caso seja azul, um sistema de descarte é feito e a bola cai para fora do

robô e se a bola tiver cor laranja, a bola é colocada numa rampa de acesso para o sistema

de lançamento.

Feita a seleção o sistema de lançamento é iniciado, lançando 6 vezes, através de um

sistema de chute com a rotação de uma peça presa ao servomotor pequeno. Finalmente,

o robô sobe a pá coletor e o programa se encerra.

A seguir tem-se um �uxograma explicativo sobre a rotina do robô.

FIG. 6.16: Fluxograma Explicativo Sobre a Rotina Implementada

6.2.5 COMPARAÇÃO ENTRE OS ROBÔS

Visando comparar os dois modelos concebidos, adotou-se como parâmetro o

tempo de lançamento das bolas, medida essa utilizada como meio para classi�cação dos

robôs em grupos, na primeira fase da competição LARC 2014. No primeiro modelo, o robô

arremessador levava, em média, 2 min para lançar 5 bolas. Já o novo protótipo lança as

mesmas 5 bolas em um intervalo de 40 segundos, em média. Dessa forma, conclui-se que o

novo robô é signi�cativamente mais e�ciente (33,33 %, aproximadamente), visto que cada

um dos seus sistemas (coleta, captura, seleção e lançamento) são executados de forma

independente, além de serem mais e�cientes que os seus respectivos antecessores. Para

53

maior �delidade, os testes foram executados diversas vezes e sob as mesmas condições:

80cm de distância entre as paredes, com 6 bolas, sendo 5 laranjas e 1 azul, dispostas a

frente do robô.

54

7 RESULTADOS

Com os estudos feitos, através das três etapas, foram obtidos os resultados a

seguir.

7.1 RESULTADO DA PROVA DE CONCEITO

Com o robô construído foi veri�cado que o mesmo identi�cava os objetos próxi-

mos, desviando destes de acordo com a rotina criada no programa. Veri�cou-se que, caso

o objeto à frente não tivesse uma altura maior ou igual ao da localização do sensor ul-

trassônico, poderia existir erro na detecção deste e, consequentemente a rotina de desviar

não seria executada.

Em relação ao sensor de proximidade infravermelho, conforme esperado, ao de-

tectar que o ponto mais próximo tinha uma distância maior que 20(dentro da escala de

0 a 100), o robô recuava meia volta e fazia a curva para a direita. Entretanto, como o

sensor estava localizado apenas na frente, houve casos em que o robô caiu da mesa no

movimento de recuo ou no movimento de virar para a direita.

O sensor RGB conseguiu detectar as cores azul, verde, branca, amarela, preta e

vermelha, com três testes para cada cor, errando uma vez na detecção da cor vermelha,

julgando-a como preta.

A parte �nal da rotina foi executada sem nenhum problema, visto que o servo-

motor pequeno conseguiu girar a bandeira por três vezes, sendo em seguida �nalizado o

programa.

7.2 RESULTADO DA COMPETIÇÃO

Percebeu-se que, embora diversas outras equipes utilizassem a mesma estratégia

adotada pela nossa, estas a executavam de forma mais e�ciente. O sistema do robô

arremessador responsável por capturar as bolinhas era bastante ine�ciente, além de a-

presentar alguns erros ocasionais de execução devido a presença da �ta amarela utilizada

para marcar as áreas iniciais. Essa �ta também prejudicava o movimento do robô, fazendo

este se chocar com a parede da arena.

55

Dessa forma, adicionou-se uma roda a lateral no robô, fazendo com que este

deslizasse pela parede, ao invés de se chocar com a mesma e �car travado, estratégia

essa adotada pela observação das outras equipes. Somado a isso, o sistema de arremesso,

embora executasse a sua função, lançava apenas uma bolinha de cada vez, mesmo com

dois motores, o que o tornava ine�ciente. O modo escolhido para coletar, com o segundo

robô, também era ine�ciente. Conclui-se que o melhor modo para realizar essa tarefa é a

construção de braços que utilizem a parede para capturar as bolinhas e sensores de toque

para a orientação dos robôs no campo.

Percebeu-se, ao longo da competição, que a compatibilidade entre os diferentes

sensores é algo extremamente importante. Deve-se analisar os efeitos que uns causam nos

outros, de modo que não gerem interferências e assim, prejudiquem a execução da rotina.

Outro fato a ser considerado é que, embora a Linguagem própria da Lego em blo-

cos permita a execução de rotinas complexas, não constitui a melhor abordagem. Outras

linguagens permitem a realização de rotinas mais e�cientes, utilizando ao máximo o poder

de processamento do microcontrolador e as leituras dos sensores. Dessa forma, na terceira

etapa do projeto, será realizada uma nova PoC visando determinar a melhor linguagem

a ser adotada.

Finalmente, concluiu-se que a participação da equipe na competição foi muito

proveitosa. Atingiu-se uma colocação razoável, considerando todos os problemas enfrenta-

dos, tanto de tempo como de falta de recursos materiais. Entretanto, o mais importante

foi o conhecimento adquirido pela experiência de participar, pela observação dos robôs e

estratégias das equipes adversárias, assim como pela troca de informações com as mes-

mas. Dessa forma, pretende-se aperfeiçoar as estratégias e os robôs, buscando um melhor

resultado numa possível nova participação.

7.3 RESULTADO DA MELHORIA

Devido as adversidades e problemas encontrados em relação a documentação

o�cial, má compatibilidade entre o computador e o controlador e ,principalmente , o não

funcionamento do bluetooth na programação com o Lejos, fez com que fosse optado pela

continuação da linguagem em blocos para a programação do protótipo de melhoria.

Porém veri�cou-se grande potencial na utilização do Lejos, pois possibilita con-

�gurações e controle em um grau mais elevado que a linguagem em blocos, além da

56

possibilidade de se utilizar os recursos da linguagem Java para aprimorar os programas

criados.

Além disto, a nova proposta dos sistemas de captura, seleção e lançamento de

bolas, mostrou-se mais e�ciente que os do robô inicial, pois além de ser possível o trata-

mento de diversas bolas ao mesmo tempo Sendo comprovado esta e�ciência num teste,

onde o robô lançou 5 bolas em 40 segundos, resultado superior as 5 bolas em 120 segundos

feito pelo projeto anterior.

57

8 CONCLUSÃO

No mundo atual, no qual a todo momento novas tecnologias, que antes se re-

duziam a meros lampejos de imaginação, se tornam realidades do dia-a-dia, o campo da

robótica tem ganho cada vez mais importância. Tem sido utilizada em diversas áreas,

seja reduzindo os custos e aumentando a produção por meio da inserção de robôs na linha

de produção; na aplicação de robôs como ferramentas para preservar o ser humano, robôs

bombeiros, cirurgiões, submarinos, dentre outros tipos; na substituição de membros per-

didos; ou ainda na nanotecnologia. Nesse contexto, este projeto teve como �nalidade a

obtenção de conhecimento nessa área, assim como a participação em competições educa-

cionais do ramo.

Foi realizado um estudo inicial para veri�car a viabilidade da construção do

robô, uma primeira versão foi contruída, a qual foi testada em competição e por �m foi

desenvolvida uma nova versão superior a criada inicialmente.Dessa forma, tem-se que o

objetivo do projeto foi alcancado. Durante o projeto foram adquiridos conhecimentos na

área de robótica, incluindo estudos da linguagem java na elaboração de rotinas de robôs

e de como desenvolver e construir modelos que resolvam tarefas de forma e�ciente.

Como sugestão para projetos futuros, tem-se o estudo mais aprofundado do

Lejos, pois o uso das propriedades da linguagem Java e a superioridade em termos de

controle, con�guração e uso dos sensores e motores, em relação a linguagem em blocos,

possibilita uma otimização em termos de software dos robôs, podendo otimizar ainda

mais os protótipos criados; assim como a implementação da comunicação em série, por

bluetooth, entre microcontroladores.

58

9 REFERÊNCIAS BIBLIOGRÁFICAS

[1] �Rules of SEK 2014 Category,� IEEE Latin America Robotics, Competition for

Student, 2014.

[2] �http://www.infoescola.com/tecnologia/lego-mindstorms/,� acessado em 22 de agosto

de 2014.

[3] P. C. R. Abrantes, �Aprender com Robots,� Dissertação de Mestrado em Educação,

2009.

[4] R. Higashi and S. robin, �Introduction to Programming Lego Mindstorms

EV3, Teacher`s Guide,� Carnegie Mellon's Robotics Academy, 2014.

[5] �Lego Mindstorms EV3, O�cial User Guide,� 2013.

[6] �Roteiro para análise da amostra (prova de conceito),� Pregão Eletrônico no

93, Tribunal de Contas da União, 2013.

[7] �Como demonstrar, testar e obter sucesso em provas de conceito com tec-

nologia NComputing,� Boletim Técnico, NCompunting.

[8] �http://www.lejos.org/ev3/docs/,� acessado em 01 de fevereiro de 2015.

[9] �http://www.afrel.co.jp/en/archives/839,� acessado em 01 de março de 2015.

59

ANEXO

Resumo — Neste artigo serão apresentadas informações

sobre dois robôs que serão utilizados para participar da LARC/

CBR 2014 na categoria IEEE Standard Educational Kit (SEK),

com explicações das ideias centrais e ilustrações de componentes

que serão utilizados.

I. INTRODUÇÃO

Este documento refere-se a informações da equipe

RoboIME para a participação da categoria Standard

Educational Kit (SEK) na LARC / CBR 2014, competição

que tem por objetivo incentivar e desafiar alunos de

graduação a construírem robôs móveis autônomos capazes de

realizar a tarefa proposta pela competição de cada ano.

A equipe da RoboIME será composta por alunos da

graduação do Instituto Militar de Engenharia, cursando os

mais diversos cursos de engenharia disponíveis na instituição.

Para a organização do documento, serão apresentadas

quatro partes sendo elas: A competição, características gerais

dos robôs, robô coletor, robô seletor e arremessador.

II. A COMPETIÇÃO

Neste ano a tarefa a ser realizada na competição consiste num “vôlei” entre robôs, na realidade chamado de THBall, cujas principais características são descritas abaixo.

A partida é realizada em uma arena dividida em duas partes, uma para cada equipe, onde existirão bolas coloridas (azuis e laranjas) colocadas inicialmente numa posição predeterminada dentro da arena. Cada equipe pode utilizar até dois robôs simultaneamente dentro da arena, sendo que estes robôs podem coletar, selecionar e arremessar as bolas para a área adversária. Ao fim de cinco minutos contam-se as bolas nas áreas de cada equipe, pontuando +100 para bolas azuis e -100 para bolas laranja.

Analisando o panorama geral da competição, é possível separa-la em três tarefas menores: coletar as bolas, selecionar as bolas e arremessar as bolas. Pensando nisto a equipe pretende separar as tarefas entre dois robôs distintos, sendo um robô coletor e outro seletor e arremessador.

Escrito em agosto de 2014, este trabalho descreve os robôs a serem

utilizados pela RoboIME na categoria IEEE Standard Educational Kit na LARC/ CBR 2014. A equipe RoboIME é um projeto que reúne alunos dos

diversos cursos de engenharia do Instituto Militar de Engenharia, Rio de

Janeiro, Brasil.

Figura 2.1 – Arena da competição [1]

III. ROBÔS E MATERIAIS

Os robôs serão construídos utilizando peças de Lego Mindstorms EV3, Lego Mindstorms EV3 Education e Lego Mindstroms NXT.

Estes robôs terão locomoção por rodas, dispostas em triciclo com tração traseira utilizando servo motores grandes, ajuste de posição através dos sensores ultrassônicos e infravermelho, seleção através dos sensores de cor e sistema de arremesso através de servo motores pequenos.

Cada robô terá dimensões iniciais de no máximo 25 cm, sendo que se expandirão após o inicio da partida.

Para o teste dos robôs utilizaremos como suporte arenas utilizadas na OBR 2013/ etapa regional do Rio de Janeiro, que foi realizada no IME, testando apenas a lógica e comportamento dos nossos robôs em sua própria área, sem a interação gerada por um equipe adversária, pois a simulação de uma equipe adversária consiste em adicionar aleatoriamente bolas no campo ao longo dos cincos minutos.

Figura 3.1 – Robôs, sensores e motores Lego

TDP da Equipe RoboIME para a categoria IEEE Standard

Educational Kit (SEK)

André L. M. Melo , Carlos A. D. Pinto, Driele N. Ribeiro, Felipe A. M. de Alcântra, Lucas Garcia , Marina P. Mota, , Oscar

Martins W. F., Rafael J. Lima, Rebeca C. de Brito, Vinicius C. O. de Andrade, Willian A. Kanashiro, Paulo Ferreira Rosa

Instituto Militar de Engenharia(IME) – Rio de Janeiro, RJ, Brasil

email:andreluizcmrj@gmail.com, driele.neves@gmail.com, kartgarcia@gmail.com

marina_mota18@hotmail.com,oscar_mwf@hotmail.com, raphael_josino1@hotmail.com,rebecac.brito@gmail.com,

willianatsuki@gmail.com, rpauloime@gmail.com

IV. ROBÔ COLETOR

Para a função de coleta das bolas, utilizaremos um robô com suportes frontais que se expandem ao iniciar a partida, para auxiliar na coleta, semelhante às utilizadas pela equipe DROID em 2012.

O controle do robô para a varredura da arena será utilizado o sensor de infravermelho, para evitar que este se choque nas paredes e também no outro robô.

Este robô percorrerá toda a área da arena, tentando reunir o máximo de número de bolas numa área menor, facilitando o trabalho do robô seletor, o qual não precisará se locomover muito para encontrar as bolas.

V. ROBÔ SELETOR E ARREMESSADOR

Para a função de seleção e arremesso, será utilizado um único robô, de forma que a função de seleção contará com o auxílio do sensor de cor, e irá separar as bolas em dois compartimentos acoplados ao próprio robô.

Para o arremesso, se posicionará o mais próximo possível da divisão central da arena, e arremessará todas as bolas laranja do compartimento num sistema de catapulta. No entanto, antes do arremesso, o robô abandonará na arena todas as bolas azuis.

CONCLUSÃO

O sucesso nessa competição depende não somente da estratégia utilizada, mas também da forma que as funcionalidades do robô serão implementadas. Saber dividir o objetivo em tarefas menores faz com que o projeto possa ser planejado e executado mais facilmente e com mais rapidez.

Com a definição das tarefas a serem realizadas e dotado dos meios materiais necessários, a equipe RoboIME se encontra em condições de participar pela primeira vez na categoria IEEE SEK na LARC/CBR 2014.

REFERÊNCIAS

[1] “Rules of SEK 2014 category,” in version 1.0 , 2014, pp. 2.