Mapeador Final

Prévia do material em texto

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á resultarem 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 noposiçã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 
exatamentedo 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óximasatividades: 
 
 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