Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO ACADÊMICO DE INFORMÁTICA
CURSO DE ENGENHARIA DE COMPUTAÇÃO
MAPEADOR TRIDIMENSIONAL DE
AMBIENTES BASEADO EM ULTRASSOM
DIEGO GABRIEL LEE
DIOGO GUILHERME GARCIA DE FREITAS
LEONARDO WATANABE KUME
LUÍS FERNANDO GUERREIRO
CURITIBA
2013
DIEGO GABRIEL LEE
DIOGO GUILHERME GARCIA DE FREITAS
LEONARDO WATANABE KUME
LUÍS FERNANDO GUERREIRO
MAPEADOR TRIDIMENSIONAL DE
AMBIENTES BASEADO EM ULTRASSOM
Projeto de oficina de integração 2
de Engenharia de Computação do
Departamento Acadêmico de Informática,
da Universidade Tecnológica Federal do
Paraná, Campus Curitiba.
Orientador: Prof. André Schneider
CURITIBA
2013
TERMO DE APROVAÇÃO
Diego Gabriel Lee
Diogo Guilherme Garcia de Freitas
Leonardo Watanabe Kume
Luís Fernando Guerreiro
PROJETO DE OFICINA DE INTEGRAÇÃO 2
Monografia do projeto de Oficinas de Integração 2, com apresentação prevista para
25 de setembro de 2013 na Universidade Tecnológica Federal do Paraná, como
requisito para aprovação na matéria. Aprovada por:
Orientador:
___________________________
Prof. André de Oliveira Schneider
Banca:
___________________________
Prof. Mário Sério Teixeira de Freitas
___________________________
Prof. João Alberto Fabro
___________________________
Henrique Simião Ferreira
RESUMO
Este projeto descreve o planejamento, a construção, o funcionamento e possíveis
aplicações de um dispositivo para mapeamento tridimensional de ambientes
baseado em ultrassom. Basicamente o trabalho envolve o desenvolvimento de um
dispositivo para movimentar um sensor de ultrassom que mede distâncias em um
percurso pré-definido, a cada nova posição do sensor, gravar a distância medida em
relação a um ponto específico do ambiente e representar graficamente no
computador cada ponto analisado. Ao final do mapeamento o resultado será um
conjunto de pontos dispostos em uma representação computacional em escala do
ambiente real.
Palavras chave: mapeamento, ultrassom, servomotor, OpenGL
LISTA DE FIGURAS
Figura 1: Protótipo do dispositivo. Fonte: autoria própria ............................................ 5
Figura 2: Diagrama de blocos do dispositivo. Fonte: autoria própria ........................... 6
Figura 3: Placa de desenvolvimento Arduino UNO R3. Fonte: (ARDUINO, 2013) ...... 7
Figura 4: Diagrama de tempo do funcionamento do sensor de ultrassom. Fonte:
(CircuitsToday, 2013) .................................................................................................. 8
Figura 5: Sensor de ultrassom HC-SR04. Fonte: (CircuitsToday, 2013) ..................... 9
Figura 6: Exemplo de sinal de controle de um servomotor. Fonte: (Lirtex, 2013) ..... 10
Figura 7: Sistema esférico de coordenas. Fonte: () ................................................... 12
Figura 8: modelo em CAD do dispositivo. Fonte: autoria própria. ............................. 13
Figura 9: Fluxograma da rotina de mapeamento. Fonte: autoria própria. ................. 15
Figura 10: Modelo em CAD do dispositivo exemplificando uma leitura. Fonte: autoria
própria. ...................................................................................................................... 16
Figura 11: Fluxograma do software mapeador. Fonte: autoria própria. ..................... 17
Figura 12: Janela de controle e display do software. Fonte: autoria própria. ............ 19
Figura 13: Objeto a ser mapeado e o resultado visto de dois ângulos diferentes.
Fonte: autoria própria. ............................................................................................... 23
Figura 14: Fotos do local de tamanho médio a ser mapeado. Fonte: autoria própria.
.................................................................................................................................. 24
Figura 15: Resultado do mapeamento de tamanho médio na primeira posição. Fonte:
autoria própria. .......................................................................................................... 24
Figura 16: Resultado do mapeamento de tamanho médio na segunda posição.
Fonte: autoria própria. ............................................................................................... 25
Figura 17: Resultado do mapeamento de tamanho médio na terceira posição. Fonte:
autoria própria. .......................................................................................................... 25
Figura 19: Planta do ambiente de tamanho grande. Fonte: autoria própria. ............. 27
Figura 20: Fotos do ambiente de tamanho grande a ser mapeado pelo dispositivo.
Fonte: autoria própria. ............................................................................................... 27
Figura 21: Resultado do mapeamento de um ambiente de tamanho grande. Fonte:
autoria própria. .......................................................................................................... 28
Figura 22: Representação da situação ideal para a leitura do sensor. Fonte: autoria
própria. ...................................................................................................................... 29
Figura 23: Representação de uma situação ruim para a leitura do sensor. Fonte:
autoria própria. .......................................................................................................... 30
SUMÁRIO
1 INTRODUÇÃO ........................................................................................ 3
2 DESCRIÇÃO DO PROJETO ................................................................... 5
3 REFERENCIAL TEÓRICO ...................................................................... 7
3.1 Hardware .............................................................................................. 7
3.2 Software ............................................................................................. 11
4 METODOLOGIA DE EXECUÇÃO ........................................................ 13
4.1 Montagem física do dispositivo .......................................................... 13
4.2 Elaboração de rotinas de mapeamento .............................................. 14
4.3 Envio de dados ................................................................................... 15
4.4 Implementação do software de mapeamento tridimensional .............. 16
5 PROBLEMAS ENCONTRADOS ........................................................... 21
5.1 Posicionamento dos motores ............................................................. 21
5.2 OpenGL .............................................................................................. 21
5.3 Sensor de Ultrassom .......................................................................... 22
6 TESTES ................................................................................................. 23
6.1 Ambiente de tamanho pequeno ......................................................... 23
6.2 Ambiente de tamanho médio .............................................................. 24
6.3 Ambiente de tamanho grande ............................................................ 26
6.4 Interpretação dos testes ..................................................................... 29
7 CONCLUSÃO ....................................................................................... 32
8 TRABALHOS FUTUROS PARA O PROJETO ..................................... 34
9 REFERÊNCIAS BIBLIOGRÁFICAS ..................................................... 35
A. CRONOGRAMA .................................................................................... 36
B. ORÇAMENTO ....................................................................................... 37
C. CÓDIGO ARDUÍNO .............................................................................. 38
D. RELATÓRIO DE REUNIÕES ................................................................ 40
3
1 INTRODUÇÃO
A robótica e a computação, que antes eram desenvolvidas em sua maioria
nas pesquisas de ponta ou para fins industriais, agora estão se tornando atividades
mais populares, ou seja, mais pessoas estão tendo acesso e se interessando por
essas áreas. Estas passaram de atividades formais e acadêmicas para algo mais
experimental e até recreativo. Um dos motivos dessa mudança de paradigma pode
ser a queda dos preços dos computadores e componentes eletrônicos e também a
maior disponibilidade de peças e plataformas de desenvolvimento “universais”. Com
isso os problemas clássicos da robótica e computação começam a ser confrontados
por mais pessoas e, portanto há maior possibilidade para que surjam soluções
criativas.
Por exemplo: o problema de mapear um ambiente de forma eficiente ao
levantar a topologia detalhada do local ou marcar pontos específicos que sirvam de
referência para algum sistema de navegação. Para contornar o problema é preciso
coletar dados a respeito do ambiente e processá-los de tal forma que gerem uma
representação do mundo real no computador, e com isso o sistema consiga executar
tarefas baseado em seu “reconhecimento” do ambiente. Esse é um dos problemas
clássicos da robótica e tem muitas aplicações práticas, por isso já existe uma
abordagem padrão, pelo menos em um primeiro momento, para resolvê-lo.
O passo inicial para resolver esse problema é coletar os dados do ambiente,
no caso de um mapeamento tridimensional uma abordagem seria escolher um ponto
do ambiente, fixar um sensor e medir as distâncias dos objetos em relação a esse
ponto fixo. Dispondo de um sistema que possa se movimentar é possível coletar
dados necessários para mapear o ambiente em três dimensões. Os dados brutos
resultantes dessa forma de mapeamento são chamados de point cloud (Wikipedia,
2013), a tradução literal do termo em inglês é “nuvem de pontos”, ou seja, é
basicamente um conjunto de pontos dispostos espacialmente em um sistema de
coordenadas onde cada ponto coletado é referente a uma superfície do ambiente
real. As limitações desse método dependem basicamente da qualidade do sensor
(precisão nas medidas de distância e velocidade de leitura) e da liberdade de
movimentação do sistema (possibilidade de mapear todos os pontos do ambiente,
velocidade de movimentação dos sensores e número de sensores). Mas essa
4
abordagem é relativamente simples de implementar e em muitos sistemas é o passo
básico para o mapeamento eficiente de ambientes, após coletar os dados é possível
processar o point cloud para gerar outras representações como superfícies ou
polígonos.
O projeto desenvolvido nessa disciplina visa exatamente produzir uma nuvem
de pontos a partir de um sistema simples e de baixo custo, dessa forma o sistema
pode ser construído por mais pessoas e serve como uma introdução ao tema de
mapeamento tridimensional de ambientes.
5
2 DESCRIÇÃO DO PROJETO
Inicialmente o projeto prevê o mapeamento de pequenos ambientes, por
exemplo, os cômodos de uma residência, portanto o dispositivo ficará fixo no centro
do local para realizar as medições. Para movimentar o sensor de ultrassom serão
usados dois servomotores acoplados. Dessa forma o dispositivo tem dois graus de
liberdade, ou seja, pode realizar rotações em torno de dois eixos no espaço. O
acoplamento entre os motores pode ser melhor compreendido ao observar a Figura
1.
Figura 1: Protótipo do dispositivo. Fonte: autoria própria
Como se vê na Figura 1, o item numerado como 1 é o motor que movimenta
o dispositivo no plano horizontal, o item 2 no plano vertical, o 3 é o sonar, o 4 é o
arduino e o 5 é uma placa de circuito impresso feita apenas para facilitar a conexão
dos fios. O controle coordenado dos motores e a aquisição dos dados serão feitos
pela placa de desenvolvimento Arduino UNO R3, que utiliza o microcontrolador
ATMEGA328 (ARDUINO, 2013).
O mapeamento será feito ao longo de um percurso, no qual a cada nova
posição assumida pelo sensor de ultrassom é feita uma leitura de distância. Então,
para cada uma de todas as possíveis posições do percurso são gravadas três
informações: a distância medida em relação aos obstáculos e a posição angular de
6
cada motor em relação ao seu respectivo eixo de rotação. Associando a cada ponto
no espaço essas três informações pode-se mapear o ambiente através de
coordenadas esféricas.
Até esse ponto o sistema é capaz apenas de movimentar o sensor no espaço
e gerar os dados referentes a um ponto, então é preciso enviar esses pontos
medidos, através da interface serial presente na placa Arduino, para o software de
mapeamento tridimensional processar cada um individualmente e gerar um
conjunto de pontos em coordenadas cartesianas, que será desenhado no ambiente
3D computacional em escala com a realidade.
O software de mapeamento tridimensional irá funcionar em três etapas:
processamento dos pontos adquiridos pelo hardware (transformação de
coordenadas esféricas para cartesianas), atualização do conjunto de pontos
(adicionar o último ponto recebido a um conjunto de pontos já processados) e
representação na tela do conjunto de pontos (plotagem dos pontos e do ambiente
tridimensional na tela através de instruções para a placa de vídeo do computador).
Cada item destacado anteriormente está representado no diagrama de blocos
na ilustrado na Figura 2.
Figura 2: Diagrama de blocos do dispositivo. Fonte: autoria própria
7
3 REFERENCIAL TEÓRICO
Podemos separar o projeto em hardware e software, o primeiro envolvendo os
dispositivos físicos e o segundo dizendo respeito a transformação dos dados obtidos
em um “mapa 3D”. Cada uma das partes envolve diferentes assuntos que são
abordados em várias matérias do curso de Engenharia de Computação.
3.1 Hardware
3.1.1 Controle de sensores e atuadores
Para coordenar a movimentação dos motores com a aquisição de dados do
sensor e o envio das informações para o computador é usado o Arduino (ARDUINO,
2013).
Figura 3: Placa de desenvolvimento Arduino UNO R3. Fonte: (ARDUINO, 2013)
Basicamente a placa da Figura 3, facilita a utilização do microcontrolador ao
dispor de forma organizada os pinos entrada e saída digital e analógicos, além de
fornecer uma interface de comunicação serial com o computador, permitindo a troca
de dados de forma relativamente fácil. Além disso, a página do Arduino fornece uma
interface de programação em linguagem C, dispondo de diversas bibliotecas que
encapsulam operações comuns do micro controlador em funções de fácil utilização.
8
Para este projeto utilizaremos os pinos de saída digital para enviar sinais aos
motores e ao sensor de ultrassom, processo melhor descrito nas seções 3.1.2 e
3.1.3.
3.1.2 Sensor de distância baseado em ultrassom (HC-SR04)
Uma parte do projeto diz respeito ao sensor de ultrassom, que envia ondas
sonoras de alta frequência para o ambiente e recebe a reflexão desse sinal. Com o
tempo de resposta e sabendo a velocidade de propagação do som, é possível
calcular a distância em relação a um determinado objeto com a seguinte equação:
O sensor HCSR04 (CircuitsToday, 2013) funciona da seguinte maneira,
conforme ilustrado na Figura 4, ao receber um sinal de pelo menos 10µs em 5V,
nível lógico 1 no pino “Trigger”, o módulo emite oito pulsos de ultrassom a uma
frequência de 40kHz, em seguida o sensor capta a reflexão do som que após ser
processada pelo circuito controlador do módulo gera um sinal de resposta no pino
“Echo”, a duração do sinal de resposta em 5V é diretamente proporcional a distância
medida.
Figura 4: Diagrama de tempo do funcionamento do sensor de ultrassom. Fonte: (CircuitsToday, 2013)
9
Alguns aspectos podem influenciar na reflexão do som emitido na direção de
um objeto, tais como o tipo de superfície, dimensões, distância e ângulo em relação
ao sensor. O entendimento detalhado desse procedimento de reflexão não faz parte
do escopo do projeto, pois como o mapeamento do ambiente é baseado em
milhares de pontos a omissão de alguns pontos por causa de leituras imprecisas não
afeta a qualidade geral do mapeamento. Além disso, pretende-se trabalhar com
ambientes em que já se conheça as características dos objetos a serem analisados.
Figura 5: Sensor de ultrassom HC-SR04. Fonte: (CircuitsToday, 2013)
3.1.3 Servomotores
Um servomotor consiste basicamente de: um motor de corrente contínua,
uma caixa de engrenagens de redução, um potenciômetro e sensor de posição.
Basicamente o servomotor agrega esses componentes para manter uma
determinada posição, quando está alimentado (usualmente de 4,8V até 6,0V) e
recebe determinados pulsos no pino de sinal.
Esses pulsos são sinais de onda retangular modulada em PWM, onde a
largura do pulso controla a posição angular do servomotor. Na maioria dos
servomotores a largura do pulso deve variar de 1 milissegundo até 2 milissegundos,
fazendo com que o ângulo varie 180 graus, conforme a Figura 6.
10
Figura 6: Exemplo de sinal de controle de um servomotor. Fonte: (Lirtex, 2013)
O mais importante de cada pulso é o tempo em nível lógico alto e o período
pode variar sem alterar o posicionamento do servomotor, desde que a frequência
dos pulsos seja suficientemente alta para que o motor não se desligue. A frequência
usada tipicamente é em torno de 50Hz. (Valkenburg, 1961).Dependendo da marca
do servomotor, esse tempo em nível lógico alto pode variar entre 0,5 milissegundos
a 3,5 milissegundos.
Para controlar os motores usando o Arduino existe uma biblioteca específica,
a Servo.h. Ela oferece uma classe “Servo” com funções prontas (ARDUINO, 2013).
As duas funções utilizadas no projeto são:
attach - associa um pino do Arduino ao objeto da classe servo. Mudando-se
os parâmetros de entrada dessa função, pode-se alterar os tempos mínimo e
máximo do nível lógico 1 do sinal enviado ao servomotor, que pode ser útil pois cada
servomotor pode ter especificações diferentes. Os tempos padrão são: mínimo 544
microssegundos para 0 grau e máximo 2400 microssegundos para 180 graus.
write - o parâmetro de entrada determina o ângulo que deseja-se mover o
servomotor, variando de 0 a 180 graus.
O uso desses comandos pode ser observado no código de controle da placa
Arduino em anexo.
11
3.2 Software
3.2.1 Programação orientada a objetos
As principais funções do programa serão: comunicação serial com hardware,
processar os dados recebidos e organizá-los em uma estrutura de dados apropriada,
e enviar instruções para a placa de vídeo desenhar o mapa, além disso, há uma
interface gráfica para o usuário escolher alguns parâmetros de funcionamento do
dispositivo. Para facilitar a programação utilizaremos a linguagem Java, que já
possui bibliotecas para cada uma dessas funcionalidades. Estas bibliotecas estarão
citadas e descritas ao longo do texto, pois cada uma diz respeito a uma parte
específica no software.
3.2.2 Computação gráfica
Para a parte do software de desenho, há a necessidade da utilização de uma
biblioteca que possibilite acessar diretamente a placa de vídeo do computador. Para
esta tarefa foi escolhida a biblioteca LWJGL (LWJGL, 2013). Com essa biblioteca é
possível utilizar as funções da placa de vídeo para desenhar formas primitivas como,
por exemplo: pontos, linhas e triângulos. A placa de vídeo utiliza instruções em
OpenGL (OpenGl, 2013), que é uma interface de programação de aplicativos multi-
plataforma implementável em várias linguagens, ou seja, é um conjunto de
instruções universal que permite a um software trocar informações com a placa de
vídeo e ter acesso a renderização acelerada por hardware. Portanto a biblioteca
LWJGL é um “wrapper”, invólucro em inglês, ou seja, serve para acessar as funções
e comandos OpenGL a partir de um programa escrito em Java.
3.2.3 Transformação de coordenadas
Esta tarefa consiste na transformação dos dados recebidos do hardware para
possibilitar que o programa desenhe o ponto no lugar correto dentro do ambiente
3D. Ela é necessária, pois os dados que vêm do microcontrolador para o
computador são a distância medida pelo sensor e a posição angular de cada
servomotor no momento da medição do sensor. Analisando estes dados, percebe-se
12
que os pontos obtidos podem ser representados em coordenadas esféricas, pois
apresentam um raio da origem até o ponto (M), um ângulo na vertical ( ) e outro
ângulo na horizontal ( ), conforme a Figura 7. Contudo, para que estes dados sejam
aplicáveis no programa, é necessária a transformação das coordenadas esféricas
para coordenadas cartesianas (SANTOS,2013). A razão disto é que função que se
usa para desenhar os pontos na biblioteca LWJGL usa os parâmetros de acordo
com os eixos x, y e z.
A transformação efetiva das coordenadas ocorre na aplicação das
seguintes equações:
Figura 7: Sistema esférico de coordenas. Fonte: (SANTOS,2013
13
4 METODOLOGIA DE EXECUÇÃO
A seguir é descrito o processo de implementação do projeto em etapas, um
cronograma completo com o tempo previsto para cada tarefa pode ser observado no
ANEXO 1. As tarefas descritas nessa seção compreendem etapas do projeto já
concluídas ou em andamento. Etapas como análise de resultados; ajustes finais;
correção de erros e conclusões serão descritas futuramente
4.1 Montagem física do dispositivo
Primeiramente, definimos o acoplamento dos motores de modo que o sensor
pudesse apontar para todas as direções possíveis. Então, foi definido um modelo de
protótipo que cumprisse tal tarefa. Após isto, um modelo em CAD foi feito para
visualizar os componentes físicos necessários para a construção do dispositivo.
Chegou-se a conclusão que era necessário duas placas em formato de “L” para
acoplar os motores da forma desejada. Uma vez obtidas as peças, a construção do
protótipo revelou ser necessária a fixação do dispositivo em uma base pesada o
suficiente para fazer com que este não se movimente durante a movimentação dos
motores, o resultado final da montagem aparece na Figura 8.
Figura 8: modelo em CAD do dispositivo. Fonte: autoria própria.
14
4.2 Elaboração de rotinas de mapeamento
O dispositivo terá dois servomotores para mover o sensor em todas as
direções desejadas. Para que este processo dure o menor tempo possível, será
necessário definir uma trajetória eficiente que complete o percurso programado.
Para isso os servos devem se movimentar um de cada vez, fazendo com que a cada
variação angular do servo da horizontal, o outro servo da vertical percorra 180 graus.
Portanto, a trajetória em questão deverá resultar em um formato de uma semiesfera,
que seria o suficiente para cobrir um ambiente fechado. A Figura 9 ilustra o
fluxograma de execução da rotina de mapeamento utilizada no projeto.
Conforme descrito na seção 3.1.3 é preciso mandar pulsos pré-definidos de
acordo com a especificação dos motores. No caso do servomotor utilizado, as
medições realizadas revelaram que é necessário um pulso com duração de 0.65
milissegundos para ir até a posição 0° e um pulso de 3.1 milissegundos para a
posição 180°. Cabe destacar que para cada modelo de servomotor esses valores
podem variar e, portanto é preciso fazer esse mapeamento das posições angulares
para cada motor utilizado.
15
Figura 9: Fluxograma da rotina de mapeamento. Fonte: autoria própria.
4.3 Envio de dados
O projeto prevê que o Arduino deve receber os dados do sensor e enviá-los
ao software no computador juntamente com os dados dos ângulos dos sensores.
Para tanto, o Arduino dispõe do recurso de comunicação serial para mandar
informações ao computador na forma de um vetor de bytes. Desta forma, será
utilizada a biblioteca RXTX (RXTX, 2013), que possibilita a comunicação serial entre
o Arduino e o programa em Java. Para enviar os dados do sensor e a posição dos
motores, o Arduino envia uma string contendo os números concatenados e
separados por um caractere especial, pois enviá-los em um byte de cada vez não
16
era o suficiente para representar um número inteiro positivo maior que 255. Depois o
software decodifica a string para extrair os valores e atribuí-los a variáveis. Um
exemplo de leitura dos dados pode ser observado na Figura 10 na qual ele enviaria
uma leitura como os seguintes dados: 24cm, 45cm e 180 graus.
Figura 10: Modelo em CAD do dispositivo exemplificando uma leitura. Fonte: autoria própria.
4.4 Implementação do software de mapeamento tridimensional
Para facilitar a organização do projeto dividimos o programa em algumas
classes, cada uma realizando uma tarefa específica. O fluxograma simplificado do
software pode ser observado na Figura 11.
17
Figura 11: Fluxograma do software mapeador. Fonte: autoria própria.
18
4.4.1 Classe “DisplayMapeador”
Esta é a principal classe do programa, responsável por criar o “Display”, ou
seja, a janela que exibe o ambiente tridimensional onde são desenhados os pontos,
os eixos de referência e os demais elementos gráficos do programa. Como é a
primeira classe a ser “chamada” na execução do programa durante a plotagem, ela
define todas as variáveis utilizadas para desenhar os pontos, por exemplo: declara
um vetor com a quantidade máxima de pontos a serem desenhados e define os
parâmetros de operação do OpenGL.
Além disso, a classe é responsável por atualizar os pontos e enviá-los para a
placa de vídeo através de um “Buffer” a cada vez que um novo ponto é recebido
pela classe “SerialCommunicator”. A etapa de transformação de coordenadas
esféricas para cartesianas também é executada nessa classe, dentro da função que
atualiza os pontos.
4.4.2 Classe “Movimentation”
Esta classe é utilizada para alterar a posição relativa da câmera dentro do
“Display”, ou seja, mudar a janela de visão do ambiente 3D. Para realizar essa
alteração de posição a classe tem uma função que recebe as entradas do teclado e
mouse e as interpreta em comandos como girar ou transladar a o ponto de vista da
câmera em relação a um eixo no espaço. Essa possibilidade de movimentação,
muito parecida com um videogame, facilita na hora de visualizar o resultado do
mapeamento, pois permite movimentar a câmera livremente pelo ambiente enquanto
a leitura dos pontos é realizada.
4.4.3 Classe “SerialCommunicator”
Esta classe é responsável por realizar a comunicação entre hardware e
software através da interface serial, disponível em Java através da biblioteca RXTX.
A classe tem uma função que fica esperando um “evento serial”, ou seja, alguma
ação na comunicação entre serial, quando esse evento ocorre a função lê uma
string, que são os dados de posição contidos no hardware, então essa classe
apenas decodifica essa string em três variáveis, distância medida e a posição
angular de cada motor, e as envia para a classe “DisplayMapeador”.
19
4.4.4 Classe “JanelaDeControle”
Esta é a classe que permite ao usuário operar o sistema de mapeamento, ao
definir parâmetros para o desenho dos pontos e controlar o início e fim do
mapeamento. A Figura 12 ilustra a janela de controle do programa, com os
respectivos itens numerados:
Figura 12: Janela de controle e display do software. Fonte: autoria própria.
20
1- Controle de escala: permite ao usuário mudar a escala da plotagem, varia de
1:1 até 1:10.
2- Posicionamento do sensor: ao inserir a posição do sensor em cada eixo
(x=vermelho, y=verde, z= azul) e clicar no botão “OK” o sensor é deslocado
para a posição escolhida pelo usuário e a partir de então os pontos passam a
ser desenhados em relação a esse novo referencial.
3- Leitura do sensor: apenas exibe o valor correspondente a distância atual
medida pelo sensor de ultrassom, serve para auxiliar no deslocamento do
sensor no espaço caso o usuário não disponha de algum instrumento para
medir distâncias. Também é útil para testar se o sensor está funcionando
adequadamente.
4- Botões “START/PAUSE” e “STOP”: ao clicar em “START” o display
começa a desenhar os pontos recebidos do hardware, com isso o rótulo do
botão muda para “PAUSE” que ao ser clicado congela o mapeamento no
último ponto desenhado, o que ativa a opção “START” novamente retomando
o mapeamento de onde parou. Caso o usuário clique em “STOP” o display
cancela o mapeamento e apaga todos os pontos já desenhados, além disso,
quando o mapeamento recomeçar pelo clique em “START” os motores voltam
para a posição angular 0º.
5- Botões “Salvar” e “Carregar” mapeamento: agregam as funcionalidades
essenciais de salvar e carregar mapeamentos. Clicando em salvar todos os
pontos mapeados são guardados em um arquivo de texto que posteriormente
pode ser carregado pelo programa. Ao carregar um mapeamento salvo
anteriormente é possível continuar a plotagem de pontos normalmente, sendo
que os novos pontos podem ser salvos junto com os anteriores gerando um
novo mapeamento gravado em arquivo.
6- Opção “ Mostrar grade” : Mostra ou esconde uma grade no plano XZ, essa
grade serve para auxiliar na visualização dos pontos e também para estimar
medidas, visto que o valor do espaçamento em centímetros entre uma linha e
outra é sempre exibido. A grade, assim como todos os elementos do
programa acompanham as mudanças na escala em tempo real.
21
5 PROBLEMAS ENCONTRADOS
5.1 Posicionamento dos motores
Sem dúvida o maior problema deste projeto foi o hardware, durante toda a
execução os problemas com os servomotores foram uma constante. No inicio os
dois motores estavam com problemas, um deles estava com uma peça danificada e
a única solução foi substituí-lo, o outro estava com um problema de tateio (quando o
motor fica oscilando entre posições próximas). Ao trocar a fonte de alimentação, do
Arduino para uma fonte CC ajustável o problema foi parcialmente resolvido e o tateio
residual pode ser causado pelo fato de o motor não ser novo. Ao utilizar um novo
motor foi detectado que ele não alcançava os 180° com a biblioteca Servo.h do
Arduino, após análises da onda PWM com o osciloscópio, foi detectado que o
período em nível alto da onda não chegava até os 3100 microssegundos descritos
no datasheet para o servo ficar no posição de 180°, por causa de uma limitação na
própria biblioteca. Para resolver o problema foi necessário alterar o código da
biblioteca.
Além dos problemas mecânicos apresentados, outro desafio foi mapear a
posição angular em função do sinal de entrada como descrito na seção 3.1.3, pois
cada motor (mesmo sendo da mesma marca) tem uma resposta ligeiramente
diferente. Portanto foi necessário definir os limites mínimo e máximo para o tempo
em nível lógico alto do sinal de controle de cada motor. O procedimento para
resolver esse problema foi variar o sinal de entrada através de um potenciômetro e
observar a resposta do motor, sua posição angular e a corrente consumida. Quando
o pulso era muito largo ou muito estreito a corrente consumida aumentava e o motor
ficava travado, indicando o “fim de curso do motor”.
5.2 OpenGL
Apenas trabalhar com as instruções OpenGL já foi um desafio, pois este
assunto não é abordado no curso de Engenharia de Computação e requer
conhecimento prévio de como funciona uma placa de vídeo e a sua comunicação
com o processador e memória do computador. Em linhas gerais a placa de vídeo
tem um processador e memória dedicados para realizar cálculos de posicionamento
de vértices, renderização de polígonos e preenchimentos de texturas, o que exige
basicamente cálculos envolvendo matrizes de números reais. Assim as placas de
22
vídeo operam com processamento paralelo e conseguem realizar esses cálculos
muito mais rápido que o processador, o único problema é a troca de dados entre o
processador e a placa de vídeo, que é o gargalo para a velocidade de renderização
de imagens na tela do computador.
O problema que ocorreu no início do projeto foi que a cada vez que um ponto
era calculado e desenhado havia uma “chamada” para a placa de vídeo, o
processador e a placa ficavam trocando informações a cada operação de calcular
um novo ponto e para manter os pontos anteriores na tela era necessário desenhá-
los novamente. Pode-se notar que com um número elevado de pontos há muito
retrabalho desenhando os anteriores e mandando para a placa de vídeo. Assim o
processador do computador ficava sobrecarregado por mandar informação para a
placa de vídeo em uma frequência muito alta.
A solução foi programar de modo mais eficiente a atualização dos pontos
através da criação de um buffer que vai guardando gradualmente os pontos
calculados e somente quando a tela é atualizada é que o vetor de pontos é mandado
para a placa de vídeo. Dessa forma a placa já recebe um vetor com grande
quantidade de pontos e os desenha de forma paralela, e só há nova comunicação
entre a placa de vídeo e o processador quando a tela é atualizada, operação que
ocorre com muito menos frequência que o cálculo de um novo ponto.
5.3 Sensor de Ultrassom
Um problema foi ligar o sensor de ultrassom em paralelo com os motores, ou
seja, usar o mesmo ponto de alimentação 5V. Isso gerou interferências na leitura do
sensor, que provavelmente ficou descalibrado devido a oscilações nessa tensão de
5V.É bem provável que as oscilações foram geradas pelos motores, uma vez que
esses dispositivos são conhecidos por gerarem ruído no circuito enquanto estão em
operação. Para resolver esse problema o sensor foi conectado diretamente a saída
de 5V do Arduino, enquanto que os motores foram conectados à fonte externa CC.
23
6 TESTES
Após a implementação do hardware e o desenvolvimento do software foram
realizados alguns testes para analisar se o funcionamento do dispositivo estaria de
acordo com o esperado. Nesta seção é descrito o procedimento de cada teste
realizado, os respectivos resultados encontrados e quais as medidas tomadas para
solucionar eventuais problemas.
6.1 Ambiente de tamanho pequeno
Primeiramente mapeamos pequenos objetos internamente, caixas de diversos
tamanhos e um balde, para determinar se os pontos desenhados tomariam a forma
dos objetos mapeados. Para caixas não obteve-se um bom resultado,
provavelmente devido ao material de papelão.
Para o balde o resultado ficou bom mesmo havendo alguns pontos
discrepantes, provavelmente por causa da reverberação do som dentro do balde. A
Figura 13 a seguir mostra o resultado do mapeamento.
Figura 13: Objeto a ser mapeado e o resultado visto de dois ângulos diferentes. Fonte: autoria própria.
24
6.2 Ambiente de tamanho médio
Agora testando o dispositivo em um ambiente um pouco maior o objetivo é
avaliar situações em que podem ocorrer leituras erradas, visto que há mais
possibilidades de reflexão do som emitido. No caso esse ambiente é a parte inferior
de uma estante, como aparece na Figura 14
Figura 14: Fotos do local de tamanho médio a ser mapeado. Fonte: autoria própria.
Figura 15: Resultado do mapeamento de tamanho médio na primeira posição. Fonte: autoria própria.
25
Figura 16: Resultado do mapeamento de tamanho médio na segunda posição. Fonte: autoria
própria.
Figura 17: Resultado do mapeamento de tamanho médio na terceira posição. Fonte: autoria
própria.
26
Para essa situação foi necessário usar a função de movimentar o sensor no
espaço, pois em apenas um ponto o mapeamento não era suficiente para detalhar o
objeto. Nesse caso foram usados três pontos diferentes. É possível observar na
Figura 16 e na Figura 17 que alguns pontos são desenhados no software como se
estivessem atravessando a parede, em locais que não deveriam estar. Isso ocorre
devido às reflexões que devido ao angulo que atingem o obstáculo, deveriam ser
sinais perdidos, porém, acabam por atingir outro obstáculo mais distante e voltar
para o sonar, causando uma leitura indesejada do sensor.
6.3 Ambiente de tamanho grande
Neste último teste foi realizado um mapeamento do ambiente completo,
mantendo o sensor fixo, para este caso usamos a menor variação angular possível,
1º, para gerar o maior número de pontos Fica evidente a distorção para objetos de
grandes dimensões, como a parede do quarto e o guarda roupas, observando a
Figura 20, em perspectiva, nota-se que o mapeamento tende a formar uma esfera,
pois o sensor está analisando pontos próximos como se correspondessem a uma
mesma distância.
Apesar de o mapeamento distorcer os objetos e não ser possível detalhar
muito superfícies irregulares, a disposição dos obstáculos no quarto fica bem
próxima do real, e, portanto esse dispositivo poderia ser integrado a um sistema de
navegação onde é preciso apenas saber se em determinada região existe um
obstáculo.
O local escolhido foi um quarto como aparece na Figura 18.
27
Figura 18: Planta do ambiente de tamanho grande. Fonte: autoria própria.
Figura 19: Fotos do ambiente de tamanho grande a ser mapeado pelo dispositivo. Fonte: autoria própria.
28
Figura 20: Resultado do mapeamento de um ambiente de tamanho grande. Fonte: autoria própria.
29
6.4 Interpretação dos testes
O sensor ideal seria um que fosse muito pontual e sempre medisse a
distância exata em relação ao obstáculo independente da posição do sensor,
infelizmente na prática esse tipo de sensor não existe. No caso do sensor de
ultrassom a medição é angular, ou seja, uma onda sonora é emitida da fonte e pode
atingir objetos dentro de um determinado ângulo de emissão, além disso, o sensor
também detecta reflexões dentro de uma determinada faixa angular.
A situação ideal para esse tipo de dispositivo é quando o objeto a ser medido
está perpendicular com o sensor. Figura 21. Nesse caso o som refletido provém
exatamente do ponto em que se deseja saber a distância. Porém quando o
mapeador se movimenta o emissor fica inclinado em relação ao obstáculo e como o
sensor detecta sempre a primeira onda sonora refletida a distância medida será
diferente da desejada, como aparece na Figura 22 Portanto quando mapeador vai
medir um objeto extenso esse objeto fica deformado, visto que enquanto o som
refletido provém de um ponto dentro da faixa angular de emissão a distância
detectada será sempre a mesma, no caso a menor. No caso do sensor utilizado
,conforme a descrição do fabricante, o “ângulo de medição” é de 15º , portanto essa
é a precisão do sensor, ou seja, o quão pontual ele pode ser. Quanto maior a
amplitude angular de emissão menos pontual é o sensor e a deformação dos objetos
é maior, o resultado é o que aparece nos mapeamentos, mostrando objetos
arredondados. Conforme aparece na Figura 20 objetos mais distantes do sensor
apresentam maior deformação.
Figura 21: Representação da situação ideal para a leitura do sensor. Fonte: autoria própria.
30
Dependendo do tipo de ambiente o som pode refletir em vários objetos antes
de voltar ao sensor e a distância medida será maior que a desejada, pois não
necessariamente as ondas refletidas provêm do ponto em que o sensor está
emitindo, essa situação é chamada de “reflexão fantasma”. Outra situação é quando
o ângulo entre o objeto e o sensor faz com que o som refletido nunca chegue ao
sensor, como aparece na Figura 22, gerando uma leitura inválida (zero ou fora de
alcance).
Figura 22: Representação de uma situação ruim para a leitura do sensor. Fonte: autoria
própria.
Uma forma de tratar essas leituras incorretas e filtrar pontos discrepantes
seria utilizar um algoritmo de ocupação, que cria o mapa do ambiente integrando os
dados coletados ao longo do tempo (Varveropoulus).De forma bem resumida, esse
algoritmo atribui uma probabilidade de existir um obstáculo em cada ponto do
espaço compreendido no mapa considerando que a emissão da onda sonora pode
ser aproximada para um formato cônico. Inicialmente todos os pontos do mapa tem
a mesma probabilidade de conter objetos ou não, então após várias medições ao
mover o sensor no ambiente, cada ponto do mapa visto de diferentes ângulos passa
a ter uma probabilidade maior ou menor de possuir algum objeto. Quanto maior o
número de mapeamentos maior a probabilidade de o mapa gerado estar correto.
Então a equipe adicionou no software a possibilidade de mover a referência
de onde está sendo medida cada ponto. Assim, passou a ser possível a
31
movimentação do sensor para realizar medições de diferentes ângulos, desde que o
usuário indicasse no software o quanto foi movimentado em cada eixo. Porém não
possível a implementação do algoritmo de ocupação devido a sua complexidade e
falta de tempo, visto que o problema foi detectado nas fases finais do projeto.
Além disso, com todo o estudo sobre os sensores percebeu-se a importância
de se escolher adequadamente um sensor que atenda as necessidades e seja
viável. Como o objetivo era criar um dispositivo de baixo custo, não chegamos a
testar um mapeamento com sensores de maior precisão.
32
7 CONCLUSÃO
Apesar de cumprir os objetivos propostos o projeto teve um resultado abaixo
do esperado, ou seja, a implementação de baixo custo, principalmente o sensor de
ultrassom, comprometeu a precisão e a qualidade final do projeto, mesmo gerando
uma nuvem de pontos passível de ser utilizada em aplicações de robótica e ainda
ser possível processar os dados para melhorá-los o resultado final não ficou
visualmente agradável, ocorreu muita distorção dos objetos mapeados. Devido a
imprevistos e principalmente a inexperiência com hardware a equipe demorou muito
para resolver problemas relativamente simples e acabou perdendo o foco do projeto.
Mesmo que o software e o hardware pudessem ser desenvolvidos em paralelo
ocorreram momentos em que toda a equipe concentrou-se em um problema a ser
superado, dessa forma outras partes do projeto ficaram sem evoluir enquanto aquele
determinado problema era trabalhado.
Por exemplo: o software de mapeamento começou a ser desenvolvido antes
da montagem do hardware, pois ainda não dispúnhamos das peças, então
inicialmente o programa avançou bastante e ficou praticamente pronto, usamos
pontos gerados arbitrariamente para testar o mapeamento, mas quando começamos
a montar o hardware surgiram os problemas e o software ficou parado. Só voltamos
a desenvolver o software na hora de integrar as partes do projeto e nesse momento
não havia mais tempo para implementar todas as ideias iniciais.
Independente do resultado do projeto a experiência adquirida durante o
processo já valeu o esforço da equipe, pois este é o primeiro momento do curso em
que aplicamos conhecimentos de várias disciplinas para integrar software e
hardware com a finalidade de resolver um problema prático, ou seja, a
implementação ou pelo menos a tentativa de realizar um projeto desse caráter é
uma amostra da realidade que enfrentaremos no restante do curso e na vida
profissional, portanto esse trabalho já serve para testar nossas habilidades como
engenheiros. Além disso, o projeto, ainda que superficialmente, aborda o tema de
computação gráfica e serve como uma introdução a essa área de estudo crescente.
Pode-se dizer que esse trabalho não está esgotado, com algumas melhorias
ele pode ser aproveitado em projetos futuros visto que se todas as ideias iniciais
fossem implementadas o dispositivo se tornaria muito mais versátil e integrável com
outras pospostas de robótica ou computação. Portanto esse projeto tem pleno
33
potencial de ser utilizado em conjunto com sistemas de mapeamento e navegação
em ambientes pequenos, além de ser relativamente fácil de construir a um custo
acessível para estudantes ou entusiastas de robótica e computação.
34
8 TRABALHOS FUTUROS PARA O PROJETO
Ao longo do desenvolvimento do projeto o grupo teve diversas ideias para
acrescentar. Porém devido a grande quantidade de imprevistos, não foi possível
realizar todas as ideias. A seguir há uma lista com as ideias que poderiam ser
implementadas no projeto:
Utilizar mais de um sensor para aumentar o número de leituras por unidade de
tempo;
Software em Java controlar o comportamento dos motores (rotinas de
mapeamento);
Realizar algum tipo de processamento sobre a nuvem de pontos gerada, por
exemplo: criar uma linha entre pontos que estejam a uma determinada distância
um do outro.
Estudo e escolha de um sensor mais eficiente para a aplicação
Implementação do algoritmo de ocupação que utiliza probabilidade para
interpretar mais eficientemente os dados recebidos pelo sensor.
Integração do projeto com um robô móvel com odometria, fazendo com que a
parte de movimentação seja autônoma
35
9 REFERÊNCIAS BIBLIOGRÁFICAS
ARDUINO. (2013). Arduino UNO. Acesso em Agosto de 2013, disponível em
http://arduino.cc/en/Main/arduinoBoardUno
CircuitsToday. (2013). CircuitsToday. Acesso em Agosto de 2013, disponível em
http://www.circuitstoday.com/ultrasonic-range-finder-using-8051
Lirtex. (2013). Lirtex Thecnology on the edge of time. Acesso em Agosto de 2013,
disponível em http://www.lirtex.com/robotics/servo-motors-information-and-
control/
LWJGL. (2013). Lightweight Java Game Library. Acesso em Agosto de 2013,
disponível em http://www.lwjgl.org/
Margolis, M. (2011). Arduino Cookbook. O'Reilly media.
OpenGl. (2013). OpenGl The Industry's Foundation for High Performance Graphics.
Acesso em Agosto de 2013, disponível em http://www.opengl.org/
ROSSUM. (2013). Rossum project. Acesso em Setembro de 2013, disponível em
http://rossum.sourceforge.net/
RXTX. (2013). RXTX Wiki. Acesso em Agosto de 2013, disponível em
http://rxtx.qbang.org/wiki/index.php/Main_Page
SANTOS. (s.d.).
Santos, R. J. (2012). Matrizes, vetorres e geometria analítica. Belo Horizonte:
Imprensa Universitária.
SAWICZ, D. (s.d.). Hobby Servo Fundamentals. Fonte:
http://www.princeton.edu/~mae412/TEXT/NTRAK2002/292-302.pdf
Valkenburg, V. (1961). Sistemas síncronos e servomecanismos básicos (2 ed.). New
York: Nooger & Nevile.
Varveropoulus, V. (s.d.). Robot localization and Map Construction Using Sonar Data.
Acesso em Setembro de 2013, disponível em The Rossum Project:
http://rossum.sourceforge.net/
Wikipedia. (2013). Point Cloud. Acesso em 09, disponível em Wikipedia: The Free
Encyclopedia: http://en.wikipedia.org/wiki/Point_cloud
36
A. CRONOGRAMA
37
B. ORÇAMENTO
Tabela 1: Orçamento do projeto. Fonte: Os autores
Descrição Quantidade utilizada
Preço total (R$)
Servomotor TowerPro (MG995) 2 46,00
Arduino UNO 1 70,00
Sensor ultrassom (HCSR04) 1 20,00
Outros (parafusos, suporte madeira, fios e conectores)
variada 10,00
TOTAL --- 146,00
* Valores baseados em cotações da internet no ano de 2013. Fonte : <http://www.mercadolivre.com.br/>
38
C. CÓDIGO ARDUÍNO
#include <Servo.h> #include <NewPing.h> #define TRIGGER_PIN 5 //pino utilizado para o trigger do sensor de ultrassom #define ECHO_PIN 6 // pino utilizado para o echo do sensor de ultrassom #define MAX_DISTANCE 500 // Maximum distance we want to ping for (in centimeters). //Maximum sensor distance is rated at 400-500cm. #define VARIACAO_HORIZONTAL 2 //determina a variação de ângulo horizontal #define VARIACAO_VERTICAL 5 //determina a variação de ângulo vertical NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance. Servo servoHorizontal, servoVertical; int horizontal = 0, vertical=0; int distancia = 0; boolean aumentaAnguloHorizontal = true; void setup() { servoHorizontal.attach(9); // associa o pino 9 ao objeto do servo horizontal servoVertical.attach(10); // associa o pino 9 ao objeto do servo vertical Serial.begin(115200); // Open serial monitor at 115200 baud to see ping results. } void loop() { servoVertical.write(vertical); servoHorizontal.write(horizontal); lerSensor(horizontal,vertical); if(aumentaAnguloHorizontal == true) { horizontal += VARIACAO_HORIZONTAL; //incrementa o ângulo horizontal if(horizontal >= 180) //chegou no limite do servo horizontal { horizontal = 180; //evita valores maiores que 180 aumentaAnguloHorizontal = false; //muda o sentido do movimento if(vertical >= 180){ //chegou no limite do servo vertical vertical = 0; } else{ vertical += VARIACAO_VERTICAL; //incrementa o ângulo vertical } }
39
} else { horizontal -= VARIACAO_HORIZONTAL; //decrementa o ângulo horizontal if(horizontal <= 0) //chegou no limite do servo horizontal { horizontal = 0; //evita valores negativos aumentaAnguloHorizontal = true; //muda o sentido do movimento if(vertical >= 180){//chegou no limite do servo vertical vertical = 0; } else{ vertical += VARIACAO_VERTICAL; //incrementa o ângulo vertical } } } } void lerSensor(int theta, int phi) { delay(30); // Wait 50ms between pings (about 20 pings/sec). 29ms should be the shortest delay between pings. unsigned int uS = sonar.ping(); // Send ping, get ping time in microseconds (uS). distancia = uS / US_ROUNDTRIP_CM; if(distancia != 0)// verifica se teve medição válida { //envia para o computador os valores da distância medida e ângulos dos servos por comunicação serial Serial.println(String(distancia)+"#"+String(theta)+"#"+String(phi)); } }
40
D. RELATÓRIO DE REUNIÕES
Data: 03/07/2013 Atividades Desenvolvidas:
Testes com Arduino (sensor distância).
Testa da comunicação serial do Arduino para Java.
Pesquisas sobre comunicação serial e desenvolvimento 3D em Java
Pesquisas de preço dos componentes (servomotor e sensor ultrassom). Próximas atividades:
Testar o servo motor e o sensor de ultrassom.
Programação de um ambiente 3D(testes com pontos aleatórios).
Data: 10/07/2013 Atividades Desenvolvidas:
Reunião com o orientador da equipe: o Apresentação de soluções para o mecanismo rotativo onde o sensor de ultrassom
será acoplado. o Sugestão de modo de calibração utilizando um laser centralizado junto com o sensor
para visualizar o local onde está ocorrendo a medição. o Discussão da possibilidade de usar formas para minimizar os erros e os buracos
entre os pontos medidos, usando ferramentas matemáticas como probabilidade ou se aproveitar da imprecisão dos servomotores para plotar mais de um ponto na mesma posição.
Testes com a distância medida pelo sonar, sendo que este mostrou resultados bons com apenas algumas medições discrepantes.
Testes do ultrassom utilizando o osciloscópio.
Pesquisa sobre a ferramenta OpenGL. Próximas atividades:
Começo da programação de um ambiente 3D utilizando OpenGL.
Elaboração de uma base para o acoplamento do sensor no mecanismo rotativo.
Data: 31/07/2013 Atividades Desenvolvidas:
Definição do modelo do dispositivo físico no SketchUp.
Definição das ferramentas e bibliotecas utilizadas para o desenvolvimento do software.
Instalação das ferramentas e bibliotecas utilizadas para o desenvolvimento do software nos computadores da equipe.
Reconhecimento das diretrizes para a confecção do relatório de acompanhamento.
Obtenção dos materiais para confecção do dispositivo físico.
Próximas atividades:
Confeccionar as partes necessárias para o dispositivo físico.
Redigir o relatório de progresso.
Desenvolver método para transformar coordenadas esféricas em coordenadas retangulares.
41
Data: 07/08/2013 Atividades Desenvolvidas:
Testes controlando o servo motor com o Arduino
Tentativa de corrigir a falha detectada no servo
Elaboração da base de acoplamento do dispositivo
Elaboração do relatório de progresso
Próximas atividades:
Arrumar o servo motor para que tenha condições de uso no projeto, ou comprar um novo se for o caso.
Redigir o relatório de progresso
Otimizar o processo de desenho de imagens no software
Testar distância de alcance do sensor
Data: 14/08/2013 Atividades Desenvolvidas:
Tentativa de corrigir a falha detectada no servo
Elaboração do relatório de progresso
Verificação do raio de alcance do sensor de ultrassom
Próximas atividades:
Montar o dispositivo com os novos servos
Otimizar o processo de desenho de imagens no software
Começar o desenvolvimento do software definitivo
Data: 28/08/2013 Atividades Desenvolvidas:
Teste do dispositivo montado o Debug do software o Solução de problemas dos servos o Solução de problemas do sensor
Discussão da ideia de fazer uma PCI para facilitar a montagem
Reunião com o orientador para discussões sobre o dispositivo e relatório Próximas atividades:
Elaborar o projeto do PCI e executá-lo
Elaboração dos cabos necessários
Data: 04/09/2013 Atividades Desenvolvidas:
42
Elaboração dos cabos
Elaboração da PCI
Detectado problemas com o atual esquema da PCI
Discussão de ideias para resolver os problemas do sensor Próximas atividades:
Refazer o projeto da PCI
Resolver os problemas detectados com os servos e o sensor
Data: 11/09/2013 Atividades Desenvolvidas:
Discussão e solução com o professor sobre o problema com os servos
Descobrimento do problema com a biblioteca Servo.h do arduino
Próximas atividades:
Elaborar a monografia final
Testar o software junto com o dispositivo
Solucionar o problema do servo