Post on 25-Aug-2020
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITÉCNICA ENGENHARIA DE COMPUTAÇÃO
Curitiba 2016
DIEGO UNOKI DE AZEVEDO
RELATÓRIO FINAL – ROBOFUT
__________________________________________________________
Orientador: Prof. Msc. Valter Klein Junior
Curitiba 2016
DIEGO UNOKI DE AZEVEDO
RELATÓRIO FINAL - ROBOFUT
Relatório final apresentado ao Curso de
Engenharia de Computação da Pontifícia
Universidade Católica do Paraná, como requisito
parcial de avaliação da disciplina de Projeto Final II,
coordenada pelo Prof. Ph.D. Luiz A. de P. Lima Jr.
Orientador: Prof. Msc. Valter Klein Junior.
SUMÁRIO
1. INTRODUÇÃO ..................................................................................... 1
2. DETALHAMENTO DO PROJETO ....................................................... 3
2.1. Visão geral ............................................................................... 3
2.2. Detalhamento dos Blocos ........................................................ 4
2.2.1. Computador .......................................................................... 4
2.2.2. Arduino I ............................................................................... 5
2.2.3. Módulo wireless – emissor ................................................... 7
2.2.4. Módulo wireless – receptor ................................................... 8
2.2.5. Arduino II .............................................................................. 8
2.2.6. Ponte H e Motores.............................................................. 10
2.2.7. Parte física do robô ............................................................ 11
2.2.8. Protocolo de comunicação ................................................. 11
3. TESDES E RESULTADOS ESPERADOS ......................................... 14
3.1. Teste do computador e Arduino I ........................................... 14
3.2. Teste nos motores e Ponte H ................................................. 14
3.3. Teste na comunicação ........................................................... 15
3.4. Teste em conjunto .................................................................. 15
4. CONCLUSÃO .................................................................................... 16
5. REFERÊNCIAS ................................................................................. 18
LISTA DE FIGURAS
Figura 1 Diagrama de blocos em alto nível do sistema ao todo. ............. 3
Figura 2 Interface Monitor Serial. ............................................................. 4
Figura 3 Módulo NRF24L01 conectado ao Arduino e computador. ......... 7
Figura 4 Tabela pinos NRF24L01. ........................................................... 7
Figura 5 DFD Arduino II ........................................................................... 8
Figura 6 Integração ponte H, motores, Arduino e módulo wireless ....... 10
Figura 7 Imagem de cima da estrutura do robô. .................................... 11
Figura 8 Imagem de baixo da estrutura do robô .................................... 11
Figura 9 Detalhes dos bits do protocolo de comunicação...................... 12
Figura 10 Diagrama de blocos simplificado, sistema ao todo. ............... 14
RESUMO
Tendo em vista que o curso de Engenharia da computação da PUCPR
ainda não estava presente na RoboCup, viu-se a oportunidade de iniciar tal
inserção através da construção de um robô para ser posteriormente
aperfeiçoado afim de competir na RoboCup.
Em uma breve pesquisa e conversa com professores e alunos que
querem desenvolver tal projeto, decidiu-se iniciar na categoria de entrada, a
Small Size League (SSL).
Levando em conta que o valor de alguns equipamentos necessários para
deixar o robô competitivo tem um valor muito elevado, nesse primeiro momento
foi utilizado componentes similares, porém para a parte da comunicação remota
já foi possível utilizar o módulo NRF24L01 que atende todas as necessidades
para a competição. Por esse motivo, foi dado uma atenção maior a essa parte
do projeto, desenvolvendo um protocolo de comunicação.
Com o desenvolvimento do robô foi possível validar a comunicação
remota de forma satisfatória. O teste para validar essa parte, foi basicamente
enviar comandos da porta serial do computador para o robô afim de que se
movesse para determinada direção com diferentes velocidades.
1
1.INTRODUÇÃO
Aproximadamente 24 anos atrás, a ideia de robôs jogarem futebol ficou
séria. Primeiramente com o professor Alan Mackworth e seu artigo On Seeing
Robots, e posteriormente em um workshop em Tóquio, pesquisadores japoneses
discutiam sobre a mesma ideia de forma independente, e assim as primeiras
regras foram criadas. Dessa forma a competição J-League surgiu no Japão e
depois se tornou mundial com o nome atual de RoboCup. De lá para cá, as
regras foram aperfeiçoadas, e uma vez por ano é escolhido um país para sediar
a competição. O Brasil já teve a honra de seriar em 2014 a RoboCup, porém
poucas equipes brasileiras participaram.
Com a motivação de alguns alunos do curso de Engenharia de
Computação da PUCPR em participar do torneio e com o apoio de alguns
professores, surgiu a ideia de trabalhar paralelamente a essa equipe com esse
projeto final que teve o objetivo de criar o hardware do robô para que a equipe
possa tomar como base, e focar apenas em melhorias e no desenvolvimento do
software para a automação do mesmo.
Nesse projeto foi implementado apenas o hardware do robô e seu
protocolo de comunicação. Por momento, não foi desenvolvido o sistema de
chute, a automação, e também foi deixado de lado o sistema de localização dos
robôs.
O principal problema levado em consideração para desenvolver todo o
projeto foram as regras da competição. A competição impõe diversas regras
mais para o projeto foram analisadas principalmente as regras que falam das
características do robô. Com isso foi necessário analisar se os motores, rodas e
todo o sistema em si iria se acoplar afim de que não ultrapasse as medidas
máximas estabelecidas pela regra, onde deixa claro que o robô deve caber
dentro de um cilindro de 18cm de diâmetro e 15 cm de altura. Outra regra impõe
que a comunicação deve ser obrigatoriamente wireless, e para a escolha do
módulo de comunicação, foi necessário verificar o tamanho do campo, pois a
partir de uma determinada distância a comunicação entre os módulos fica
inviável. A medida do campo é de nove metros por seis metros. Por definição de
2
outra regra, devemos levar em consideração que não podemos ter nenhum
mecanismo para segurar a bola, ela só pode ser empurrada.
Algumas regras da competição não foram citadas pois para o objetivo
desse projeto final não são relevantes. O que é de maior relevância são as regras
em relação ao robô em si. Então os problemas a serem tratados são todos
voltados ao robô.
O robô a ser construído será dividido em 4 módulos, hardware, software,
sistema de comunicação e a parte mecânica. O hardware é o circuito do robô,
que consiste no Arduino, pontes H e demais componentes do circuito. Essa parte
gerencia todo o robô, acionando os motores, ativando a comunicação e demais
módulos do sistema. O software, são programas que controlam o hardware.
Basicamente é o programa que roda no Arduino e faz a parte de gerenciamento
do sistema de comunicação. É no software que será criado o protocolo de
comunicação e onde será definido todas as funções para que o hardware
funcione de acordo com o esperado. Essa parte será desenvolvida
simplificadamente apenas para teste do hardware pois a parte de inteligência
artificial é muito complexa e por hora não será desenvolvida. O sistema de
comunicação será responsável pela comunicação sem fio entre o controle e os
robôs, esse deverá ser obrigatoriamente wireless exigido pela competição e
também será desenvolvido um protocolo de comunicação. A parte mecânica
consiste basicamente nas caixas de redução dos motores.
A seguir será apresentado o detalhamento do projeto que mostrará como
cada parte do projeto será desenvolvida, e também estará detalhado como o
protocolo de comunicação vai funcionar. Também será visto o procedimento de
testes e validações de cada etapa do projeto e do conjunto ao todo. Por fim
teremos a conclusão falando de algumas dificuldades e experiências adquiridas,
uma breve discussão sobre sustentabilidade e os trabalhos futuros que serão
necessários desenvolver após a conclusão desse projeto.
3
2.DETALHAMENTO DO PROJETO
2.1. Visão geral
O projeto contará basicamente com um controle e um robô. A parte do
controle consiste em um computador, um Arduino e um módulo wireless. Já o
robô vai contar com outro Arduino, outro módulo wireless, dois motores, uma
ponte H e demais componentes.
O diagrama da figura 1 mostra um Computador conectado ao Arduino I
que irá mandar informações através do Módulo wireless – Emissor para o Módulo
wireless – Receptor que está conectado ao Arduino II que por sua vez
processará as informações recebidas e assim acionará a Ponte H que vai
controlar os Motores.
Computador: Utilizado apenas para encaminhar comandos ao Arduino I.
Arduino I: Além de ativar o módulo wireless, ele vai ler as informações digitadas
pelo computador na Monitor serial, processar as informações, e armazenar em
uma variável que será transmitida pelo módulo wireless – Emissor.
Módulo wireless – Emissor: Será utilizado o módulo NRF24L01 que deverá
transmitir os dados gerados pelo computador para o módulo wireless – Receptor.
Módulo wireless – Receptor: Também será utilizado o módulo NRF24L01,
porém com a característica de apenas receber dados.
Figura 1 Diagrama de blocos em alto nível do sistema ao todo.
4
Arduino II: Além de habilitar o módulo NRF24L01 em modo receptor, será
responsável em interpretar os dados recebidos e mandar dados para a ponte H.
Ponte H: Driver ponte H L298N, que receberá os dados do Arduino afim de
movimentar o motor em determinado sentido e velocidade.
Motor: DC RED AK280, movimentará o robô, girando em sentido horário ou
anti-horário e com diferentes velocidades.
2.2. Detalhamento dos Blocos
2.2.1. Computador
O computador é responsável por enviar ao Arduino I as direções em que
o robô deve ir. Para isso será utilizado Monitor serial do software Arduino (IDE),
para enviar diferentes informações seguindo um padrão estabelecido pelo
protocolo de comunicação criado. O Monitor serial utiliza o padrão ASCII.
Abaixo está a interface do Monitor serial.
Figura 2 Interface Monitor Serial.
5
2.2.2. Arduino I
O Arduino I será responsável por habilitar o módulo NRF24L01 em modo
de emissor, e também estará conectado ao computador. Basicamente enviara
os comandos recebidos pelo usurário através do computador para o outro
Arduino que comandara o robô em si.
Abaixo está descrito o Pseudocódigo. Lembrando que a linguagem usada
para programação no Arduino é a sua própria linguagem, que é baseada em C
e C++.
//Código Arduino controle
Programa Arduino I
{
inclua biblioteca NRF24L01 –> NF24.H
define msg[11]
define dados[11]
define idx_msg = 0
ativar NRF24L01 (9,10)
endereço do NRF24L01 = 0xE14BC8F482LL
funcao inicio ()
{
inicia NRF24L01
inicia Serial
Escreve(“Digite o protocolo, ex: (00110001)”)
define NRF24L01 como emissor (pipeOut)
}
funcao loop ()
{
se (Serial disponivel)
{
6
se (idx_msg < 10)
{
msg[idx_msg]= Valor digitado na Serial();
idx_msg++;
}
}
senão
{
dados[0] = msg[0];
dados[1] = msg[1];
dados[2] = msg[2];
dados[3] = msg[3];
dados[4] = msg[4];
dados[5] = msg[5];
dados[6] = msg[6];
dados[7] = msg[7];
dados[8] = msg[8];
dados[9] = msg[9];
radio.escreve(dados, 11);
idx_msg = 0;
}
}
}
O código é bem simples, o programa lê os dados da serial até completar
10 valores. Então é armazenado cada valor em uma posição do vetor dados e
por fim é transmitido esse vetor.
7
2.2.3. Módulo wireless – emissor
A figura acima mostra as conexões que o módulo NRF24L01 vai fazer
com o Arduino I e ao computador. Lembrando que o módulo NRF24L01 tem a
característica de enviar e receber dados, porém para essa etapa será habilitado
somente o modo de transmissão pois só irá transmitir os dados para que o outro
módulo receba. Abaixo tem a figura de uma tabela, onde está a descrição dos
pinos de saída do módulo NRF24L01, e onde devem ser conectados ao Arduino.
As saídas CE e CSC são os pinos que habilitam o módulo. Já as saídas
MOSI e MISO são referentes a transmissão de dados, sendo a MOSI para
entrada de dados e MISO para saída. O SCK é para controle do Clock.
O alcance desse módulo pode chegar a 10m em ambientes fechados e
50m em campo aberto, o que é mais que suficiente para a competição.
Figura 3 Módulo NRF24L01 conectado ao Arduino e computador.
Figura 4 Tabela pinos NRF24L01
8
2.2.4. Módulo wireless – receptor
Este NRF24L01 estará conectado nas mesmas portas que o NRF24L01
– Emissor, porém no Arduino II que estará acoplado ao robô. Ele será
configurado como receptor pois só vai receber os dados do outro módulo que
estará conectado ao Arduino I, junto com o computador.
2.2.5. Arduino II
O Arduino II será responsável por ativar o módulo NRF2401 em modo
receptor e receber e processar os dados afim de mandar instruções para a ponte
H. Abaixo está o Diagrama de Fluxo de Dados.
Figura 5 DFD Arduino II
9
Abaixo está o Pseudocódigo para ajudar no entendimento do DFD acima.
// Robô
Programa Arduino II
{
inclua biblioteca NRF24L01 –> NF24.H
define MOTOR1_IN1 = 6
define MOTOR1_IN2 = 10
define MOTOR2_IN1 = 5
define MOTOR2_IN2 = 9
define dados[11]
Ativar NRF24L01 (7,8)
Endereço do NRF24L01 = 0xE14BC8F482LL
funcao inicio ()
{
inicia NRF24L01
define NRF24L01 como receptor
define MOTOR1_IN1, MOTOR1_IN2, MOTOR2_IN1, MOTOR3_IN2 como saídas //motores
}
funcao loop ()
{
se (Radio disponivel){
radio.leia(dados, 11)
se (dados[0] == '('){
se (dados[1] == '0'){
se (dados[2] == '0'){
se (dados[3] == '0'){
se (dados[4] == '1'){
se (dados[5] == '0'){
se (dados[6] == '0'){
se (dados[7] == '0'){
se (dados[8] == '0'){
10
se (dados[9] == ')'){
MOTOR1_IN1 = 0)
MOTOR1_IN2 = 0) }}}}}}}}}}
// ... demais casos de “SE” seguem a mesma regra acima.
}
}
O condigo acima interpreta os dados recebidos, e verifica cada posição do vetor para identificar o que deve realizar em relação aos motores. Não foi descrito todas as possibilidades para as posições do vetor pois são muitas, mais todas seguem o mesmo padrão da que está descrita do pseudocódigo.
2.2.6. Ponte H e Motores
Figura 6 Integração ponte H, motores, Arduino e módulo wireless.
Acima está disposto como será conectado os motores na ponte H e como a
ponte H será conectada no Arduino II.
A ponte H escolhida foi a Driver Motor Ponte H L298N, pois suas
especificações estão de acordo com o motor escolhido. Esse driver trabalha com
tensão entre 4v e 35v, tendo corrente de operação máxima de 2A por canal, ou
4A se usar apenas um canal. Sua potência máxima é 25W.
11
Já o motor DC escolhido AK280 trabalha com corrente de 300mA e tensão
de 9v. Como o Arduino uno é muito grande para acoplar na estrutura do robô,
será utilizado o Arduino Pro Mini, e ao invés das pilhas e bateria será utilizado
apenas uma bateria de 2100mAh 7.4v. Como a ponte H já possui um regulador
de tensão de 5v ideal para alimentar o Arduino, foi necessário adicionar um outro
regulador de tensão para o NRF24L01 que precisa de 3.3v.
2.2.7. Parte física do robô
A estrutura do robô será impressa na impressora 3D, assim como as
rodas. A estrutura do robô tem 12cm de comprimento por 11cm de largura.
Abaixo temos a imagem da estrutura do robô a ser impressa.
Na estrutura do robô, observamos duas entradas cilíndricas para acoplar os
motores com diâmetro de 2,5cm, e acima temos um lugar reservado para o
Arduino, ponte H e demais circuitos necessários. Na frente e na traseira foi feito
um recuo para maior facilidade de conduzir a bola. Embaixo foram feitos quatro
pés para diminuir o atrito e dar mais equilíbrio, já que serão utilizadas apenas
duas rodas.
2.2.8. Protocolo de comunicação
Para a comunicação foi necessário desenvolver um protocolo para que
futuramente seja mais fácil de trabalhar com a inteligência artificial para controle
automático do robô. Para desenvolver o protocolo foi pensado em diversas
características, e é importante lembrar que o Monitor serial do Arduino trabalha
com valores ASCII, e por isso foi simulado a entrada de dados para binário,
Figura 7 Imagem de cima da estrutura do robô Figura 8 Imagem de baixo da estrutura do robô
12
digitando apenas 0 ou 1 para os bits que representam as ações de controle.
Abaixo está a formatação do protocolo que possui tamanho simulado de 1 byte
para os dados:
Vale destacar que o início e fim do pacote de dados se dá por abre e fecha
parênteses. Abaixo temos uma imagem que está detalhado o que cada bit vai
representar.
Para interpretar o protocolo recebido, o Arduino de cada robô precisa ler
bit por bit, afim de definir qual função será chamada com os dados recebidos. Na
tabela 1, está definido os valores que cada bit pode assumir e o que eles
representam nas funções do robô em si.
Tabela 1 Descrição de cada caso do protocolo de comunicação
Partes do protocolo Descrição
( Define o início.
Bit 1 e 2 Caso bit 1 = 0 e bit 2 = 0, define-se robô 1.
Caso bit 1 = 0 e bit 2 = 1, define-se robô 2.
Caso bit 1 = 1 e bit 2 = 0, define-se robô 3.
Caso bit 1 = 1 e bit 2 = 1, define-se robô 4.
Bit 3 e 4 Caso bit 3 = 0 e bit 4 = 1, define-se motor 1.
Figura 9 Detalhes dos bits do protocolo de comunicação.
Figura 9 Detalhes dos bits do protocolo de comunicação
13
Caso bit 3 = 1 e bit 4 = 0, define-se motor 2.
Caso bit 3 = 1 e bit 4 = 1, define-se ambos os motores.
Bit 5 Caso bit 5 = 0, define-se rotação do motor em sentido
horário.
Caso bit 5 = 1, define-se rotação do motor em sentido
anti-horário.
Bit 6,7 e 8 Caso bit 6 = 0 e bit 7 = 0 e bit 8 = 0, define-se a
velocidade do motor = 0.
Caso bit 6 = 0 e bit 7 = 0 e bit 8 = 1, define-se a
velocidade do motor = 35.
Caso bit 6 = 0 e bit 7 = 1 e bit 8 = 0, define-se a
velocidade do motor = 70.
Caso bit 6 = 0 e bit 7 = 1 e bit 8 = 1, define-se a
velocidade do motor = 105.
Caso bit 6 = 1 e bit 7 = 0 e bit 8 = 0, define-se a
velocidade do motor = 140.
Caso bit 6 = 1 e bit 7 = 0 e bit 8 = 1, define-se a
velocidade do motor = 175.
Caso bit 6 = 1 e bit 7 = 1 e bit 8 = 0, define-se a
velocidade do motor = 210.
Caso bit 6 = 1 e bit 7 = 1 e bit 8 = 1, define-se a
velocidade do motor = 255.
) Define o fim.
A velocidade é baseada em sinal PWM que varia de 0 a 255. O protocolo
criado é bem adaptável, e possível de ajustes futuros caso seja necessário.
14
3. TESDES E RESULTADOS ESPERADOS
3.1. Teste do computador e Arduino I
Nessa etapa será testado a interação entre o computador e o Arduino I.
Para isso, será conectado ao Arduino dois leds, afim de que quando informado
algum comando pelo Monitor Serial, os leds acendam com diferentes
intensidades.
O resultado obtido nesse teste foi satisfatório pois quando informado um
comando no Monitor Serial seguindo um padrão definido pelo protocolo de
comunicação os leds acenderam de diferentes formas e intensidades. Com isso
foi possível dar continuidade e assegurar que o computador e o Arduino
conseguem conversar e desempenhar bem os comandos que serão dados pelo
usuário afim de movimentar o robô. Com isso foi valido a etapa Computador e
Arduino I do diagrama de blocos geral do sistema.
3.2. Teste nos motores e Ponte H
Após os testes do Arduino I em conjunto com o computador e os leds, foi
adicionado os motores sem rodas, apenas para primeiros testes para verificar
seu funcionamento sem programação aprofundada. Esse teste foi validado pois
o motor rodou e parou conforme solicitado na programação. Após isso, foi
adicionado a ponte H para ter total controle dos motores. Com isso foi possível
Figura 10 Diagrama de blocos simplificado, sistema ao todo.
15
controlar a velocidade e a direção da rotação dos motores. Essa etapa foi
essencial para a continuidade do projeto pois agora só falta a comunicação sem
fio. Com isso foi validado as etapas Arduino II, Ponte H e Motores do diagrama
de blocos geral do sistema.
3.3. Teste na comunicação
Esse teste consiste em validar a comunicação entre os módulos
NRF24L01, tanto como emissor quanto receptor. Para isso foram conectados um
módulo NRF24L01 e um botão no Arduino I, e no Arduino II outro NRF24L01 e
um Led. O objetivo é que apertando o botão acenderia o Led, porém isso deve
ocorrer remotamente, apertando o botão do Arduino I deve acender o Led no
Arduino II, o que ocorreu conforme o esperado. Com isso foi validado as etapas
Módulo wireless – emissor e Módulo wireless – receptor do diagrama de blocos
geral do sistema.
3.4. Teste em conjunto
Com todos os testes anteriores realizados e validados, agora é necessário
incorporar tudo, e montar o protótipo na estrutura do robô impressa na
impressora 3D. Após o protótipo do robô todo montado, foi realizado testes
enviando comandos do computador para o robô seguindo o protocolo criado,
como os comandos foram respondidos de forma esperada foi distanciado o robô
do controle para testar a distância, e também foi testado uma função para
demonstrar as funcionalidades do robô, como ir para frente e para trás, círculo
para direita e esquerda, e girar o próprio eixo com diferentes velocidades. Com
todos os testes acimas validados, o projeto se deu bem-sucedido.
16
4.CONCLUSÃO
A tecnologia vem avançando muito rápido, quem poderia imaginar que em
menos de três décadas já teríamos robôs que jogam futebol sozinhos. Não
podemos ficar de fora dessa realidade, com esse projeto iniciamos a inserção do
curso de Engenharia de computação na famosa RoboCup. O objetivo não é
apenas competir, e sim ser campeão na categoria Small Size League (SSL),
adquirindo conhecimento e reconhecimento para o curso.
Com o desenvolvimento do projeto, viu-se a necessidade do uso de
diferentes alternativas devido aos problemas enfrentados. A primeira dificuldade
foi para desenvolver a roda omnidirecional que não tinha nenhum projeto pronto
que se adequasse a nossa necessidade, então o seu desenvolvimento manual
tornaria o projeto inviável para os prazos determinados, com isso optou-se
temporariamente pelo uso de rodas normais. Outra dificuldade foi na
comunicação wireless, mesmo com vários projetos prontos disponíveis, nenhum
funcionou de acordo com o esperado, então foi necessário um tempo maior para
o desenvolvimento dessa etapa o que gerou atraso nas outras etapas. Com o
atraso gerado, foi modificado o número de motores em cada robô, o foco era
utilizar quatro motores, mais foi simplificado para apenas dois motores para ser
possível dar andamento ao projeto. Para agilizar ainda mais foi utilizado o
Arduino ao invés do PIC16f877A, pois era necessário relembrar e estudar o
funcionamento desse microcontrolador, e o tempo não era suficiente. Em várias
etapas do projeto, e em vários testes quase nada ocorreu conforme o esperado,
sempre era necessário algumas modificações ou esforço maior. A parte que mais
deu dor de cabeça foi quando a comunicação entre os módulos parou de
funcionar, o tempo gasto para tentar achar o erro foi imenso, e a solução era
simples, enviar mais de uma vez os dados, pois se fosse enviado apenas uma
vez não acontecia nada, os dados “se perdiam”. Um erro que não foi possível
correção foi que ao enviar um comando pelo Monitor serial, ao digitar o próximo
comando esse apresentava dados que não foram digitados, mesmo usando
artifícios na programação para evitar isso, não teve solução, e o único modo de
mandar outro dado é enviar várias vezes o mesmo comando ou fechar e abrir
novamente o Monitor serial.
17
É de extrema importância termos a consciência de sustentabilidade, onde
suprimos nossas necessidades sem comprometer o futuro das próximas
gerações. Com esse pensamento, nesse projeto foi utilizado baterias que podem
ser recarregadas e assim reutilizadas. Todo o ano, mais de 15 bilhões de
baterias são produzidas em todo o mundo, porém uma minoria são as baterias
recarregáveis, por isso devemos ter essa consciência de utilizar esse tipo de
bateria já que evita a dispensa desse lixo altamente toxico. Para ter uma ideia,
uma bateria recarregável vale por mil baterias normais. A geração atual é tão
tecnologicamente dependente, que não vê a possibilidade de reuso de
eletrônicos em geral, não vem a possibilidade do concerto de alguns eletrônicos.
E isso gera muito lixo que não é reciclável e é altamente toxico ao nosso planeta.
E é claro, o que as grandes empresas querem é isso mesmo, uso limitado dos
eletrônicos para gerar mais consumo, porém devemos pensar onde vai parar
tudo o que caiu em desuso. Parece que isso não vai mudar e só tende a piorar,
mais devemos ter a consciência que futuramente isso vai causar consequências
para o planeta e assim aos humanos.
Um projeto desse porte não se faz em um ou dois anos, e exige uma
equipe focada, mais com o desenvolvimento desse protótipo, que apenas exigira
melhores componentes e desenvolvimento da inteligência artificial, já é um
grande passo em direção ao objetivo da equipe. Então para tornar o robô a nível
de competição, serão necessárias algumas melhorias e alterar alguns
componentes por outros superiores, já que os utilizados nesse projeto já estão
defasados, excluindo o módulo wireless NRF24L01 que já atende com eficiência
a parte de comunicação. Uma mudança necessária será desenvolver as rodas
omnidirecionais que dão mais mobilidade ao robô, substituir os motores por
outros mais potentes e incluir mais dois totalizando quatro motores. Além disso,
vai ser necessário criar a inteligência artificial, sistema de localização e sistema
de chute que não foram desenvolvidos.
18
5.REFERÊNCIAS
RoboCup. Informações gerais. Disponível em: http://www.robocup.org. Acesso em 01 jun. 2016.
Small Size Robot League. Regras da competição e informações da
categoria. Disponível em: http://robocupssl.cpe.ku.ac.th/. Acesso em 08 jun. 2016.
Robô FEI. Informações gerais sobre o projeto da equipe Robô FEI.
Disponível em: http://portal.fei.edu.br/pt-BR/pesquisas_projetos/projetos_institucionais/Robo_FEI/Paginas/robo_FEI.aspx. Acesso em 08 jun. 2016.
Small Size ano 2007. Informações sobre o projeto de 2007 da equipe FEI.
Disponível em: http://portal.fei.edu.br/pt-BR/pesquisas_projetos/projetos_institucionais/Robo_F EI/informacoes_tecnicas/Paginas/robos.aspx. Acesso em 1 jun. 2016.
TDP. Team description paper da equipe Furbol do ano de 2010.
Disponível em: http://www.furgbol.c3.furg.br/index.php?Itemid=1108&option=download_categoria&task=detalhe&id_site_componente=1609&id=129. Acesso em 1 jun. 2016.