MAPEADOR TRIDIMENSIONAL DE AMBIENTES BASEADO EM...

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.


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.


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/>

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).


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.


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


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


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


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


Montar o dispositivo com os novos servos

Otimizar o processo de desenho de imagens no software

Começar o desenvolvimento do software definitivo


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


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


Discussão e solução com o professor sobre o problema com os servos

Descobrimento do problema com a biblioteca Servo.h do arduino


Elaborar a monografia final

Testar o software junto com o dispositivo

Solucionar o problema do servo

MAPEADOR TRIDIMENSIONAL DE AMBIENTES BASEADO EM...

Documents

Transcript of MAPEADOR TRIDIMENSIONAL DE AMBIENTES BASEADO EM...