Embed Size (px)
Citation preview
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO ACADÊMICO DE INFORMÁTICA
CURSO DE ENGENHARIA DE COMPUTAÇÃO
ALLYSON DOS REIS MOREIRA
HADRYEL HOLANDA
LUCAS MINTO MAIA SOUTO
THAINÃ MONTEIRO
VANESSA BRAGANÇA WREZINSKI
SISTEMA DE DETECÇÃO DE BURACOS EM ESTRADAS
CURITIBA
2013
ALLYSON DOS REIS MOREIRA
HADRYEL HOLANDA
LUCAS MINTO MAIA SOUTO
THAINÃ MONTEIRO
VANESSA BRAGANÇA WREZINSKI
SISTEMA DE DETECÇÃO DE BURACOS EM ESTRADAS
Monografia apresentada à Disciplina Oficina de Integração II, do Curso Superior de Engenharia de Computação da Universidade Tecnológica Federal do Paraná. Orientador: Prof. Daniel Rossato de Oliveira, M. Sc.
CURITIBA
2013
SISTEMA DE DETECÇÃO DE BURACOS E FALHAS EM ESTRADAS
BRASILEIRAS
Monografia apresentada no dia 24 de abril de 2013 como requisito ao projeto
da disciplina Oficina de Integração II, do curso de Engenharia de Computação da
Universidade Tecnológica Federal do Paraná. A Banca contará com a presença dos
professores Hugo Vieira Neto e Daniel Rossato de Oliveira e do aluno Rui Pimentel
Leite.
RESUMO
Com este projeto, tivemos o objetivo final de produzir um sistema capaz de
detectar buracos em estradas ou rodovias, por meio da análise de variações das
acelerações sofridas por um acelerômetro acoplado a um veículo. O acelerômetro é
conectado a uma plataforma de prototipagem eletrônica de hardware (Arduino),
devidamente programada e que é capaz de ler e interpretar os valores do sensor. O
Arduino, por sua vez, é conectado a um computador rodando um software que é
capaz de interpretar os dados recebidos. A detecção dos buracos é realizada via
software por meio da interpretação dos valores fornecidos pelo sistema embarcado.
Palavras-chave: Detecção de buracos, sistema embarcado, acelerômetro, Arduino.
ABSTRACT
The objective of this project is to produce a system that is capable of detecting
holes in places such as roads or highways. This is done through the analysis of the
acceleration variation suffered by an accelerometer attached to a vehicle. The
accelerometer is connected to electronics prototyping platform hardware (Arduino)
that is properly programmed to be able to read and interpret the values given by the
sensor. The Arduino is connected to a computer running software that is able to
interpret the data received. The hole detection is performed via software through the
interpretation of the values provided by the embedded system.
Keywords: Detection of holes, embedded system, accelerometer, Arduino.
LISTA DE FIGURAS
Figura 1 – Diagrama de Bloco do Sistema ................................................................ 11
Figura 2 – Diagrama de Bloco do Software. .............................................................. 12
Figura 3 – Arduino Mega 2560 .................................................................................. 15
Figura 4 - Sinal de Dados e Sinal de Clock (DIAS FILHO, s.d.) ................................ 16
Figura 5 – Acelerômetro ADXL 345. .......................................................................... 18
Figura 6 – Comunicação entre Arduino e Acelerômetro ............................................ 19
Figura 7 – Módulos do Software ................................................................................ 20
Figura 8 - Vetor de Acelerações Z ............................................................................. 21
Figura 9 - Exemplo do Algoritmo ............................................................................... 22
Figura 10 – Fluxograma do Algoritmo. ...................................................................... 23
Figura 11 – Dados Brutos(Raw) provenientes do Acelerômetro e Dados Escalados.
.................................................................................................................................. 27
Figura 12 - Análise da Velocidade Máxima .............................................................. 28
Figura 13 - Caixa sobre bicicleta. .............................................................................. 30
Figura 14 – Detalhe do Encapsulamento do Sensor e Arduino. ................................ 31
Figura 15 - Buraco 1. ................................................................................................. 32
Figura 16 - Buraco 2 com roda de bicicleta. .............................................................. 33
Figura 17 - Declive em calçada. ................................................................................ 34
Figura 18 – Amortecedor ........................................................................................... 37
Figura 19 – Cronograma ........................................................................................... 44
SUMÁRIO
1 INTRODUÇÃO ............................................................................................... 9
1.1. Objetivos ........................................................................................................ 9
1.2. Justificativa .................................................................................................... 9
1.3. Funcionamento do Sistema ......................................................................... 10
2 FUNDAMENTAÇÃO TEÓRICA ................................................................... 13
2.1. Arduino ........................................................................................................ 14
2.2. Protocolo I2C .............................................................................................. 15
3 METODOLOGIA .......................................................................................... 17
3.1. Hardware ..................................................................................................... 17
3.1.1. Acelerômetro ............................................................................................... 17
3.1.1.1. Código do Arduino ............................................................................... 18
3.1.1.1. Arduino e Acelerômetro ....................................................................... 18
3.2. Software ....................................................................................................... 19
3.2.1. Arquitetura do Software .............................................................................. 20
3.2.2. Detector de Buracos ................................................................................... 21
3.2.3. Simplificações do problema ........................................................................ 21
3.2.1. O algoritmo ................................................................................................. 21
3.2.2. Exemplo do algoritmo ................................................................................. 22
3.2.3. Fluxograma do algoritmo ............................................................................ 23
3.3. Versionamento ............................................................................................ 24
3.4. Controle de Tarefas .................................................................................... 24
4 RESULTADOS E DISCUSSÕES ................................................................. 26
4.1.1. Simulação ................................................................................................... 26
4.1.1.1. Carrinho ............................................................................................... 29
4.1.1.2. Bicicleta ................................................................................................ 29
4.3. Testes Reais ............................................................................................... 31
4.3.1. O Protótipo .................................................................................................. 31
4.3.2. Os buracos .................................................................................................. 31
4.3.2.1. Buraco 1 ............................................................................................... 32
4.3.2.2. Buraco 2 ............................................................................................... 32
4.3.2.3. Declive ................................................................................................. 33
4.3.3. Os testes ..................................................................................................... 34
4.3.3.1. Configuração ........................................................................................ 34
4.3.3.2. Teste 1 ................................................................................................. 35
4.3.3.3. Teste 2 ................................................................................................. 36
4.3.3.4. Teste 3 ................................................................................................. 37
5 CONCLUSÃO .............................................................................................. 40
REFERÊNCIAS .................................................................................................... 41
APÊNDICES ......................................................................................................... 42
9
1 INTRODUÇÃO
Grande parte das estradas brasileiras está em estado deplorável de
conservação e possui diversos buracos. Os motoristas precisam ter muita atenção
ao conduzir seus veículos, pois algumas rodovias possuem tantos buracos que é
preciso escolher em qual passar, e, com isso, aumenta tanto o custo da manutenção
dos veículos quanto o número de acidentes (Borges et. al, 2011).
As empresas responsáveis pela manutenção das rodovias não realizam com
frequência operações para solucionar este problema e não tem critério de escolha
sobre quando ou onde devem ser realizadas as obras (Borges et al, 2011). Porém,
existem evidências de que as imperfeições e as irregularidades da superfície
influenciam parte dos acidentes. Acredita-se que a existência de buracos na pista
exerce maior influência na ocorrência de acidentes envolvendo veículos. Um estudo
australiano destaca que buracos e ondulações no pavimento podem causar
deslocamento na carga de caminhões ou a capotagem dos mesmos. (Ogden, 1997)
1.1. Objetivos
Com esse projeto, visamos colaborar com a instrumentação necessária para
a identificação de buracos em estradas. A proposta é desenvolver um sistema
embarcado a ser instalado em veículos, o qual terá a capacidade de identificar
buracos pelos quais um veículo passe. Esse sistema, em implementações futuras,
poderá ser acoplado a um sistema de GPS capaz de localizar exatamente a posição
geográfica de cada buraco identificado, e dessa forma poderá reportar as empresas
interessadas tais pontos para a realização de manutenção.
O foco principal do trabalho consiste na identificação de um buraco através da
utilização de sensores e na implementação de um software capaz de interpretar os
dados obtidos, fazendo assim a identificação.
1.2. Justificativa
Uma das motivações para o desenvolvimento deste projeto foi a possibilidade
de ajudar as empresas de manutenção de estradas a identificarem pontos críticos,
10
onde há maior incidência de buracos, e a realizarem operações tapa buracos com
mais eficiência e rapidez.
Seria muito interessante expandir as pesquisas nessa área no país para evitar
acontecimentos fortuitos, tendo em vista o número elevado de acidentes ocorridos
devido a buracos (Justiça, 2010) em estradas pelo país.
Para o desenvolvimento deste trabalho, optou-se por utilizar um sensor
acelerômetro ao invés de um sensor ultrassônico que detectasse buracos sem
passar sobre os mesmos, pois o intuito deste projeto é identificar os buracos em que
os veículos realmente “caem” – e não os que eles desviam –, de forma que as
empresas serão notificadas dos buracos mais críticos. Isso acontecerá quando o
sistema contar com a interação com o localizador GPS e um módulo de
comunicação com os servidores, assuntos reservados a implementações futuras.
Além disso, a possibilidade de aprofundar alguns fundamentos de eletrônica,
sensores, mesmo que básicos, também motivou a equipe, tendo em vista que o
curso é composto por mais matérias deste campo.
1.3. Funcionamento do Sistema
Para o desenvolvimento do sistema foi utilizado um sensor capaz de detectar
a variação da aceleração sofrida pelo protótipo quando este passa por um buraco
em conjunto com um software de computador que pudesse interpretar esses valores
fornecidos pelo sensor.
Os diagramas nas Figuras 1 e 2 descrevem os componentes e a forma como
eles interagem. Na Figura 1, o acelerômetro disponibiliza os valores das acelerações
nos eixos X, Y e Z, que serão coletadas pelo Arduino através do protocolo I²C. O
Arduino coleta os valores das acelerações nos eixos do acelerômetro e, após uma
separação que permite a distinção do valor de cada eixo, envia ao software através
da comunicação serial. O software, então, interpreta os dados recebidos do Arduino
e informa quando o protótipo passa por um buraco.
11
Figura 1 – Diagrama de Bloco do Sistema
Na Figura 2, o software apresenta dois modos de funcionamento, onde a
diferença entre os modos está no formato das entradas.
O primeiro modo consiste na entrada das acelerações dos eixos ortogonais
através do Arduino. O segundo modo de funcionamento consiste na entrada das
acelerações através de um arquivo de dados com valores anteriormente
armazenados representado no diagrama por uma linha tracejada, pois não é o
caminho principal do sistema. O algoritmo executado gera uma resposta informando
a passagem sobre um buraco.
12
Figura 2 – Diagrama de Bloco do Software.
13
2 FUNDAMENTAÇÃO TEÓRICA
Nesse projeto fora utilizado um acelerômetro para medir a aceleração
instantânea em três eixos, convencionalmente denominada x, y e z. Para analisar os
dados fornecidos pelo acelerômetro foram utilizados conceitos como vetores,
velocidade e aceleração.
Um vetor é um conceito geométrico utilizado para representar uma grandeza
física definida pelo seu módulo, direção e sentido. Os vetores, em um espaço
euclidiano, podem ser representados geometricamente como segmentos de retas
com setas e definidos por suas coordenadas (usam-se as coordenadas x e y para
vetores bidimensionais e x, y e z para vetores tridimensionais) (Steinbruch &
Winterle, 1987).
Dentre as grandezas físicas, existem as escalares e as vetoriais. As grandezas
escalares, tais como a massa, pressão, volume, energia e temperatura, são
definidas por números e pelas unidades utilizadas em suas medidas. As grandezas
vetoriais, além dos números e das unidades, precisam ser associadas a uma direção
para que sejam completamente definidas.
Quando a velocidade de um corpo se altera, dizemos que ele está sofrendo uma
aceleração, grandeza vetorial que possui tamanho e direção, e que representa a
taxa de variação da velocidade em relação ao tempo. A dimensão da mesma é
comprimento/tempo² ou velocidade/tempo. No sistema internacional de unidades, a
aceleração é quantificada em metro por segundo ao quadrado (m/s²) (Tipler &
Mosca, 2009).
Podemos calcular a aceleração média e a instantânea de um corpo. A primeira
pode ser calculada dividindo a variação da velocidade pela variação do tempo. A
segunda é o limite da mesma razão quando a variação do tempo tende a
zero(SERWAY & JR., 2008). Existe também a aceleração transversal, que causa
mudança na direção da velocidade. Se essa aceleração for constante e sua direção
ortogonal à velocidade, temos uma aceleração centrípeta. Um exemplo de
aceleração transversal é a causada pela força da gravidade, que faz com que os
planetas no nosso sistema solar orbitem em torno do Sol(Neto, 2004).
14
No âmbito desse projeto, o foco será na aceleração instantânea. A mesma pode
ter sinal positivo ou negativo em relação à orientação do sensor usado. Deve-se dar
atenção ao fato de que, caso o sinal seja negativo, não necessariamente o corpo
está perdendo velocidade. Isso acontece somente quando a aceleração e a
velocidade têm sinais opostos. Se ambos possuírem o mesmo sinal, ainda que
negativos, o módulo da velocidade do corpo está aumentando (Tipler & Mosca,
2009).
A aceleração pode ser medida por um acelerômetro. Esse instrumento mede a
aceleração instantânea nos eixos x, y e z. Quando em repouso e posicionado de
forma que o eixo z corresponda ao eixo ortogonal à Terra, a leitura do acelerômetro
apresenta valores nulos nos eixos x e y; e valores próximos à aceleração da
gravidade para o eixo z.
Para a detecção de buracos, analisaremos os valores apresentados por todos os
eixos do acelerômetro, com foco principal no eixo z, pois a aceleração nos outros
dois eixos é menos relevante quando o carro passa por buracos. Como a aceleração
da gravidade tem sinal negativo e a leitura do acelerômetro fornece o valor da
gravidade para o eixo z quando o corpo está em repouso nesse eixo, será
necessário ficar atento às variações que tornem a aceleração menor – fato que
acontece quando o veículo cai em um buraco – e que depois a tornem maior, o que
ocorre quando o veículo volta à sua altura inicial.
2.1. Arduino
O Arduino consiste em uma placa micro controlada de I/O (Entrada/Saída) e
um ambiente de desenvolvimento baseado no framework Wiring. Uma das
aplicações da placa micro controlada é fazer a comunicação entre dispositivos
eletrônicos e computadores. A comunicação entre o Arduino e o computador é feita
através de uma porta USB (Universal Serial Bus).
A solução desenvolvida para a comunicação com o acelerômetro foi baseada
no Arduino(Arduino, 2010). O modelo utilizado foi o Mega 2560 e é mostrado na
Figura 5.
15
Figura 3 – Arduino Mega 2560
2.2. Protocolo I2C
Com o objetivo de melhorar a eficiência do hardware e minimizar a
complexidade dos circuitos, o protocolo de comunicação I2C foi criado pela Philips,
em meados de 1996. O I2C (sigla em inglês para circuito integrado) ainda é
amplamente difundido e utilizado para a interconexão de vários dispositivos (DIAS
FILHO).
O protocolo I2C utiliza dois sinais para comunicação: um para o clock
(sincronização) denominado SCL e outra pela transmissão de dados denominada
DAS (serial data line).
A comunicação e a troca de dados entre os dois dispositivos são explicitadas
nas seguintes etapas:
- Ajuste das condições iniciais no dispositivo Master.
- Envio de sete bits do Master para o Slave com o objetivo de informar com
qual dispositivo ocorrerá a comunicação.
- Envio do oitavo bit pelo dispositivo Master informando se deseja ler ou
escrever no dispositivo.
- Retorno de um bit do dispositivo Slave com a informação de que
16
compreendeu a comunicação (Acknowledge bit).
- Envio da informação desejada por pacotes de oito bits sempre seguidos de
um ACK (Acknowledge bit) que confirma o recebimento da informação.
- Término da comunicação pelo envio de um bit de parada (stop bit) do
Master.
Pode-se observar na Figura 4 um exemplo de Sinal de Dados e Sinal de
Clock, demonstrando a comunicação entre dispositivos.
Figura 4 - Sinal de Dados e Sinal de Clock (DIAS FILHO, s.d.)
17
3 METODOLOGIA
Como já introduzido ao leitor, para o desenvolvimento do sistema foi utilizado um
sensor capaz de detectar a variação da aceleração sofrida pelo protótipo quando
este passa por um buraco.
O sistema é composto por:
Um sensor acelerômetro capaz de captar aceleração em 3 eixos ortogonais;
Um microcontrolador (Arduino) para realização da aquisição e
processamentos dos dados;
Cabo USB para a comunicação com o computador;
Um software para interpretar os dados processados.
3.1. Hardware
Os componentes de hardware presentes neste trabalho consistem em toda parte
eletrônica utilizada para os fins de detecção de buracos. Nessa parte estão o sensor
(acelerômetro), o microcontrolador (Arduino), as conexões e o interfaceamento de
dispositivos.
3.1.1. Acelerômetro
Para captar a aceleração nos eixos (x, y, z) onde o protótipo passar foi
utilizado o acelerômetro ADXL 345, Figura 5. O acelerômetro utilizado no projeto
possui dois métodos de operação configuráveis, o método de comunicação I2C e o
SPI. Decidiu-se usar o protocolo I2C e toda comunicação entre os dispositivos foi
baseada neste método de comunicação.
18
Figura 5 – Acelerômetro ADXL 345.
3.1.1.1. Código do Arduino
Para a interpretação inicial dos valores provenientes do acelerômetro, foi
desenvolvido um software embarcado no dispositivo Arduino que é capaz de se
comunicar com o ADXL345 e obter os valores da aceleração nos eixos X, Y e Z
sofridas pelo sensor.
Além disso, o software embarcado para Arduino também é responsável por
enviar os valores lidos para a porta serial para que posteriormente seja executado o
interfaceamento Arduino - Java por meio da comunicação serial.
3.1.1.1. Arduino e Acelerômetro
Para a interligação Arduino e acelerômetro foi utilizado um circuito seguindo
as recomendações do fabricante do acelerômetro de forma a garantir a
confiabilidade dos dados e garantia de comunicação. As seguintes ligações foram
efetuadas de forma que o sensor operasse no modo de comunicação I2C:
Arduino 3.3V conectado ao ADXL345 VCC, SDO e CS.
Arduino GND conectado ao ADXL345 GND.
ADXL345 SDA conectado ao Arduino 3.3V usando um resistor de 10k Ohms.
ADXL345 SCL conectado ao Arduino 3.3V usando um resistor de 4,7k
Ohms.
ADXL345 SDA conectado ao Arduino I2C Data (Pino 20).
ADXL345 SCL conectado ao Arduino I2C Clock (Pino 21).
O diagrama esquemático simplificado do circuito pode ser visto na Figura 6.
19
Figura 6 – Comunicação entre Arduino e Acelerômetro
3.2. Software
O software do projeto usa a biblioteca RXTX Java Library para obtenção dos
dados fornecidos pelo Arduino, uma vez que essa biblioteca tem funções prontas
que permitem simplificar a implementação do projeto. Os dados que são utilizados
correspondem às componentes das acelerações nos eixos do espaço tridimensional,
captados pelos sensores do acelerômetro. Como o escopo do projeto consiste na
detecção de um buraco na estrada, estuda-se a possibilidade da utilização do vetor
aceleração resultante que será obtido através das componentes dos eixos x, y e z,
fornecidos pelo acelerômetro. É usada a variação da aceleração no eixo z, para
permitir uma aproximação do sentido de deslocamento do protótipo no eixo vertical,
eixo que será usado também para obter uma aproximação da profundidade do
buraco analisado.
A biblioteca RXTX, como já dito, é responsável pela obtenção dos dados do
Arduino. Suas funções permitem a leitura das portas seriais presentes no Arduino,
através da linguagem de programação Java.
20
3.2.1. Arquitetura do Software
Para que o software possa registrar quando o protótipo passar dentro de um
buraco na superfície em que ele se desloca, foi implementado um sistema cuja
estrutura e funcionamentos são apresentados a seguir.
O sistema responsável pela coleta e interpretação dos dados fornecidos pelo
acelerômetro é constituído por quatro módulos em Java: um módulo de
comunicação arduino e Java que realiza por meio da bibloteca RXTX o
interfaceamento entre os dispositivos; um módulo interpretador de entradas que
povoa os objetos em Java a partir das leituras realizadas na porta serial do
computador; um módulo gráfico responsável pela exibição dos resultados e por
mostrar as opções disponíveis no software; e, por fim, um módulo detector de
buracos com as propriedades e fórmulas aplicadas, que será explicada na sessão
destinada ao funcionamento do algoritmo.
Os módulos descritos nessa sessão podem ser observados na Figura 7.
Figura 7 – Módulos do Software
21
3.2.2. Detector de Buracos
Para a detecção de um buraco, em um primeiro momento, foram
consideradas as acelerações nos eixos X, Y e Z. A princípio quando houvesse uma
variação de valores de entrada muito grandes, o algoritmo identificaria um buraco.
A partir do estudo de diversos casos e também da análise de diversos
experimentos realizados com protótipos, conclui-se que seria necessário uma
simplificação no algoritmo de detecção dos buracos a fim de concluir a fase inicial do
projeto no tempo estipulado da disciplina.
3.2.3. Simplificações do problema
Desta forma as simplificações realizadas foram: considerar somente a
variação da aceleração no eixo Z sofrida pelo protótipo; considerar buraco toda
variação acima de um percentual definido e configurável no eixo Z; e comprar
somente dois dados de aceleração, o anterior e o atual em cada parte da avaliação.
3.2.1. O algoritmo
Os valores das acelerações são armazenados em um vetor com N posições
crescentes, e cada posição é uma aceleração no eixo Z em um dado momento N.
Um exemplo didático do vetor e suas posições são mostrados na Figura 8.
Figura 8 - Vetor de Acelerações Z
O algoritmo analisa duas posições desse vetor. A posição N e N-1.
Verificando se o valor da posição N-1 é maior que o valor da posição N multiplicado
por uma constante de proporção ou tolerância. Tal constante é utilizada como
parâmetro de configuração do sistema, de forma que ele possa ser adaptável a
diferentes tipos de protótipos (ex: carro, caminhão, moto).
22
3.2.2. Exemplo do algoritmo
Na Figura 9, um exemplo do funcionamento do algoritmo. A proporção
utilizada para esse caso foi 120%. Inicialmente o algoritmo verifica as posições N=1
e N=2. Resultando em 1G<1,2G e, portanto não acusando buraco nesse momento.
Na próxima verificação o algoritmo considera as posições N=2 e N=3. Resultando
em 1G>0,84G que indica que nesse momento o sistema passa por um buraco. Nas
analises seguintes o algoritmo verifica as posições N=4 e N=5 resultando em
0,8G<1,5G, ou seja, não há a presença de buraco nesse instante.1
Dessa forma, o algoritmo é capaz de detectar buracos de forma simplificada.
Figura 9 - Exemplo do Algoritmo
1 No exemplo a verificação entre N=3 e N=4 é omitida, pois não tem relevância para o leitor.
23
3.2.3. Fluxograma do algoritmo
O fluxograma na Figura 10, demonstra o funcionamento do algoritmo por meio
do uso de estruturas de blocos para facilitar a compreensão do leitor. A aceleração
anterior (N-1) é representada pela variável Za e a aceleração atual (N) é
representada pela variável Zd. O funcionamento é idêntico ao descrito no tópico
3.2.1 e conta com a constante de proporção ou tolerância representada pela letra P.
Figura 10 – Fluxograma do Algoritmo.
24
3.3. Versionamento
Para o desenvolvimento do software, foi utilizado um sistema de controle de
versão (SCM). Tal sistema permite que o software seja desenvolvido em conjunto,
através da sincronização de um mesmo código em diferentes máquinas, e garantir
um controle das atividades de cada membro. O provedor responsável pelo
armazenamento dos dados do software e a ferramenta de controle do software do
projeto foram fornecidos pela empresa Assembla Workspaces, que disponibiliza
gratuitamente até 1GB de armazenamento para que pequenas equipes versionem
seus projetos.
3.4. Controle de Tarefas
Além do controle de versão do código, a equipe fez o uso de uma ferramenta de
controle de tarefas, que possibilita o controle, a designação e o acompanhamento de
tarefas por pessoa da equipe ou por grupo de pessoas. No projeto, a ferramenta
utilizada foi fornecida gratuitamente pela empresa Acunote. Para cada membro da
equipe foi criado um usuário de acesso ao sistema seguindo o padrão do e-mail de
cada pessoa da equipe.
Para otimizar o desenvolvimento do projeto, este foi divido em três áreas,
mostradas na Tabela 1, onde estão descritas as áreas e seus membros
correspondentes.
Tabela 1 - Áreas do Projeto
Área Descrição Responsáveis
Hardware Área do projeto que engloba o sensor acelerômetro, o
arduíno, o desenvolvimento do código para Arduino ,
desenvolvimento do protótipo e testes com o protótipo.
Allyson, Thainã e
Vanessa
Software Área do projeto referente à comunicação Arduino-Java,
Interpretação das Entradas, Algoritimo Detector de
Buracos e resultados de buracos identificados.
Hadryel, Lucas,
Thainã
Projeto Área que compreende toda a documentação do projeto. Toda a Equipe
25
Para o controle de tarefas, inicialmente era realizada uma reunião e
verificadas as aptidões e os interesses de cada membro de cada área do projeto. A
partir disso eram designadas tarefas necessárias para o desenvolvimento do
sistema a cada membro da área. As tarefas iniciadas eram marcadas pelo seu
proprietário (Owner) como Started. Assim, nenhum membro realiza a mesma tarefa
que outro, evitando desperdício de recursos humanos e de tempo. Assim que cada
membro terminava suas tarefas, o mesmo designava um tempo estimado por cada
uma e marcava-a como Completed.
Ao longo do processo obteve-se o controle das tarefas de forma simples e
intuitiva que auxiliou o cumprimento de metas e prazos pela equipe.
26
4 RESULTADOS E DISCUSSÕES
4.1.1. Simulação
O processo de simulação ocorreu durante a maior parte do desenvolvimento
do sistema, pois para o desenvolvimento do algoritmo detector de buraco foram
necessários simulações e ajustes constantes. Assim, a equipe pode estudar o
comportamento da variação da aceleração no protótipo em diversos algoritmos ao
longo do desenvolvimento da ferramenta.
Inicialmente foram realizados testes captando os dados provenientes do
acelerômetro diretamente utilizando o microcontrolador Arduino. Dessa forma, pode-
se fazer uma interpretação em alto nível dos valores permitindo que a equipe tivesse
uma visão dos valores que o sensor forneceria ao longo do projeto.
Na Figura 11 são apresentados os primeiros resultados provenientes do
acelerômetro. Na primeira coluna são mostrados os valores Brutos(Raw) fornecidos
pelo dispositivo ADXL345 os quais não foram utilizados diretamente no projeto. Após
aparecem os dados em escala (Scaled), ou seja, dados que são apresentados em
função da aceleração da gravidade da Terra. O processamento que realiza a
conversão de valores acontece de forma encapsulada no dispositivo acelerômetro. A
equipe utilizou somente os valores já convertidos pelo sensor, que conta com um
microprocessador interno.
27
Figura 11 – Dados Brutos(Raw) provenientes do Acelerômetro e Dados Escalados.
Inicialmente a equipe realizou a leitura dos valores do sensor a uma
frequência de 10 vezes por segundo resultando em um período de amostra de 0,1
segundos. Levando em consideração que o sistema, para realizar a detecção,
necessita de no mínimo três valores de acelerações no eixo Z como mostrado na
Figura 12 e supondo um buraco de X metros. Para garantir que, no pior dos casos,
o sistema consiga receber todos os pontos necessários, é preciso no mínimo 4
amostras.
28
Figura 12 - Análise da Velocidade Máxima
Dessa forma, a velocidade máxima que o veículo pode passar sobre o buraco
é definida pela fórmula a seguir, onde Ta é o período da amostra.
Aplicando a fórmula para um buraco de 10 centímetros tem-se:
Percebeu-se que nessa taxa de amostragem o sistema seria ineficiente para
a detecção de buracos em veículos. A partir daí, a equipe passou a utilizar taxas de
amostragem maiores, fixando a mesma em 200 Hz.
29
4.1.1.1. Carrinho
A ideia inicial para a realização dos testes do projeto envolvia a utilização de
um carrinho de controle remoto e uma maquete de isopor. A maquete seria
construída de forma que simulasse uma estrada com buracos, sobre a qual o
carrinho seria guiado para que pudesse ser feita a análise e teste do software
implementado para o projeto. Porém, essa ideia apresentava certas limitações.
Como o projeto foi desenvolvido de forma que o Arduino estivesse conectado a um
computador durante a execução dos testes, essa conexão limitaria o deslocamento
do carrinho, ou um notebook deveria ser acoplado ao sistema. Como o acoplamento
seria algo complexo de ser feito, decidiu-se por utilizar outra forma de execução dos
testes do projeto. Além disso, o tamanho do carrinho exigiria que a profundidade dos
buracos na maquete fosse pequena. Isso dificultaria a leitura das variações das
acelerações fornecidas pelo acelerômetro, pois as mesmas seriam menores e
menos significativas do que na escala natural de um veículo.
4.1.1.2. Bicicleta
Foi decido que uma bicicleta seria utilizada para a realização dos testes, pois,
devido ao seu tamanho, ela poderia passar por buracos de tamanhos similares aos
presentes nas estradas, o que aumentaria as variações das acelerações fornecidas
pelo acelerômetro, facilitando a análise.
O Arduino e o acelerômetro foram colocados dentro de uma pequena caixa,
que foi preenchida com algodão para um amortecimento na movimentação do
acelerômetro, diminuindo a interferência causada nos valores medidos das
acelerações. Além disso, o algodão protege os componentes de possíveis danos
devido a choques mecânico com as paredes da caixa.
Esse sistema foi acoplado próximo ao guidão da bicicleta, para que os
mesmos estejam conectados a um computador com o sistema desenvolvido
devidamente configurado. O resultado dessa configuração pode ser visto na Figura
13.2
2 O algodão foi removido para facilitar a visualização do leitor.
30
Figura 13 - Caixa sobre bicicleta.
4.2. Discussões e montagem do Projeto
Dado o objetivo de trabalhar com sensores, a proposta sobre como detectar
buracos nas estradas com o auxílio de um acelerômetro foi moldada. Devido ao
curto período de tempo disponível para a realização do projeto, o mesmo foi re-
modelado para apresentar resultados simplificados.
Um dos obstáculos encontrados no desenvolvimento do projeto foi o de como
construir um protótipo que pudesse ser conectado a um veículo. Com o auxílio de
outras propostas, viu-se a possibilidade de trabalhar com um acelerômetro em cada
uma das quatro rodas de um automóvel ou até mesmo com o controle de um vídeo
game que possui um acelerômetro dentro. Decidiu-se pelo uso de um acelerômetro
com uma placa de Arduino Mega, devido o vasto material disponível nos dias de
hoje e sua relativa facilidade de utilização.
Para testar o protótipo, decidiu-se que seria usado um carrinho de controle
remoto, simulando um veículo, e folhas de isopor moldadas para a simulação de
uma estrada. Descartou-se a primeira ideia devido a um grande número de
31
interferências e imprecisões que estariam presentes nos resultados de tal execução.
Decidiu-se então que uma bicicleta seria usada para a simulação do veículo.
4.3. Testes Reais
Ao longo de todo o desenvolvimento do projeto foram-se realizando diversos
testes, entretanto, o último deles foi o mais significativo e demonstrou o resultado
final do sistema como um todo.
4.3.1. O Protótipo
O protótipo utilizado para esses testes foi o descrito no tópico 4.1.1.2 e
aparece na Figura 14.
Figura 14 – Detalhe do Encapsulamento do Sensor e Arduino.
4.3.2. Os buracos
Foram escolhidos dois buracos na calçada da Rua Silva Jardim, próximos ao
número 900, e também um declive na mesma calçada para que fosse testado o
funcionamento do sistema.
32
4.3.2.1. Buraco 1
O primeiro buraco foi escolhido para representar o caso de um buraco em que
a roda da bicicleta não cai totalmente em seu interior. O buraco possuí
aproximadamente 20 centímetros de comprimento e largura e 5 centímetros de
profundidade, e pode ser visto na Figura 15.
Figura 15 - Buraco 1.
4.3.2.2. Buraco 2
O segundo buraco foi escolhido para representar o caso em que a bicicleta
passa com uma das rodas completamente dentro do buraco. Na Figura 16 é
mostrado o buraco e a roda frontal da bicicleta no momento em que passa dentro do
mesmo.
O buraco usado para o segundo teste apresenta 35 centímetros de
comprimento, 20 centímetros de largura e 3 centímetros de profundidade.
33
Figura 16 - Buraco 2 com roda de bicicleta.
4.3.2.3. Declive
Para calibrar o sistema e garantir que ele não acusasse buraco como declive,
foi utilizado um declive na calçada da rua com aproximadamente 25° de inclinação.
Que pode ser visto na Figura 17.
34
Figura 17 - Declive em calçada.
4.3.3. Os testes
Nos testes realizados a seguir o sistema analisou instantaneamente os
valores das acelerações. Para que isso fosse possível um dos integrantes
acompanhou o deslocamento da bicicleta portando um notebook.
Os dados em negrito representam as acelerações verificadas pelo sensor e
sua unidade G(9.8 m/s²) foi suprimida para facilitar a leitura. Eles representam em
qual comparação de acelerações o algoritmo encontrou um buraco. Retomando a
notação utilizada nos tópicos anteriores, os dados aparecem na forma:
Buraco de: [N-1] a [N]
4.3.3.1. Configuração
No início dos testes percebeu-se que o sistema estava identificando buracos
quando o protótipo se deslocava em um plano com pequenas irregularidades.
35
Verificou-se que a configuração do sistema estava com uma constante de tolerância
P configurada para variações de 20%(ou seja P=120%). Como já dito, essa
constante é a responsável por definir qual é o percentual de variação que duas
medidas consecutivas de aceleração precisam ter para que seja considerado um
buraco na região. Os testes foram feitos então com a constante em 150% e o
sistema apresentou uma quantidade de falsas identificações menor, mas ainda
significativa. Com o objetivo de reduzir ao máximo essas interferências indesejadas
na solução do problema, utilizou-se 200% como constante de tolerância em alguns
testes, onde somente valores com a metade da aceleração anterior seriam
considerados buracos.
4.3.3.2. Teste 1
Nesse teste um dos integrantes passou com a bicicleta pelo Buraco 1 e foram
analisados 458 valores da aceleração Z, com a constante de tolerância sendo
150%.
O sistema acusou um buraco já no início da passagem sobre o buraco no
instante em que a roda começa a cair no buraco. Verificando a seguinte variação da
aceleração:
Buraco de: 0,87 a 0,58
Ou seja, o protótipo estava sofrendo uma aceleração de 0,87G e passou a
perceber 0,58G em seu eixo Z.
Entretanto logo que a roda começa a voltar para o plano normal da calçada,
ou seja na extremidade direita do buraco, o sistema falha e encontra outro buraco:
Buraco de: 1,44 a 0,71
O que indica uma falha no algoritmo identificador de buraco e já aponta uma
necessidade futura de implementação. O algoritmo identificador de buracos deve
“enxergar” dados passados e não somente dados instantâneos como foi feito.
36
4.3.3.3. Teste 2
Para a realização do segundo teste, o mesmo integrante passou sobre o
Buraco 2 de forma que toda a roda frontal da bicicleta entrou no buraco. Foi utilizada
dessa vez uma constante de tolerância de 200% a fim de reduzir interferências.
Logo que a roda caiu dentro do buraco o sistema acusou:
Buraco de: 0,91 a 0,36
Demonstrando que nesse instante a bicicleta passa por um pequeno período
de queda livre até que atinja o fundo do buraco.
Nos momentos seguintes o sistema acusou diversos buracos:
Buraco de: 1,1 a -0,03
Buraco de: -0,03 a -1,31
Buraco de: 1,99 a 0,16
...
Uma hipótese que a equipe levantou para o acontecimento disso é o fato da
bicicleta possuir um amortecedor (Figura 18) em sua roda frontal, o que fez com que
o módulo percebesse um efeito de sobe e desce do garfo.
37
Figura 18 – Amortecedor
Esse segundo teste fez com que a equipe percebesse que seria necessário
levar em consideração o efeito do amortecedor do protótipo para que o sistema
possa um dia ser acoplado a veículos automotores.
4.3.3.4. Teste 3
Neste teste a bicicleta se deslocou sobre o declive citado anteriormente tanto
no sentido de decida quanto no sentido de subida. Foram analisados 1025 valores
de acelerações no eixo Z enquanto a bicicleta se deslocava sobre o declive.
A análise dos dados a seguir é delicada e exige certo nível de entrosamento
com os métodos utilizados nesse trabalho. Em resumo eles demonstram que o
sistema não se comportou como o esperado e identificou diversos buracos onde não
havia nenhum.
38
Segue um detalhe dos resultados gerados pelo programa:
Subida:
...
Buraco de: 1,27 a 0,5
Aceleração Anterior: 0,5 Aceleração Atual: 0,37
Aceleração Anterior: 0,37 Aceleração Atual: 0,04
Buraco de: 0,37 a 0,04
Aceleração Anterior: 0,04 Aceleração Atual: 1,45
Aceleração Anterior: 1,45 Aceleração Atual: 1,0
Aceleração Anterior: 1,0 Aceleração Atual: 0,44
Buraco de: 1,0 a 0,44
...3
Decida
...
Aceleração Anterior: 1,44 Aceleração Atual: 1,1
Aceleração Anterior: 1,1 Aceleração Atual: 0,6
Buraco de: 1,1 a 0,6
Aceleração Anterior: 0,6 Aceleração Atual: 0,66
Aceleração Anterior: 0,66 Aceleração Atual: 0,26
Buraco de: 0,66 a 0,26
....
3 Reticências representam valores omitidos, irrelevantes para esta análise
39
O intuito de realizar esse teste era garantir que o sistema não identificasse
como um buraco a passagem por um declive, mas mesmo com a constante de
tolerância modificada o objetivo não foi atingido.
A causa dessa falha no algoritmo remete mais uma vez à análise instantânea
da aceleração. Do modo que a verificação de buracos foi modelada o sistema
ignora as acelerações no eixo Z que não estejam a um tempo de distância do
analisado, ou seja, ele não é capaz de reconhecer que o móvel já se encontra em
um declive.
4.4. Problemas e Futuras Implementações
Ao longo de cada teste realizado foi discutida a possível causa e necessidade
de melhoria no algoritmo utilizado.
A equipe sempre esteve ciente da complexidade de um algoritmo que
reconhecesse buracos em estradas de forma eficiente, genérica e exata. Por isso
optou por realizar a simplificação do algoritmo a fim de apresentar um resultado,
mesmo que intermediário na solução do problema ao final da disciplina.
O algoritmo apresentou um nível de funcionalidade aceitável, ainda que
apresente certas saídas que necessitam de um filtro. Em nenhum dos testes
realizados o algoritmo deixou de apontar um buraco. Se o algoritmo falhou, falhou
pelo excesso e com pequenas modificações, já apontadas e discutidas, futuramente
pode ser utilizada por concessionárias de pedágio ou órgãos que são responsáveis
pela manutenção das vias indicando falhas que precisam ser corrigidas desde que
haja mapeamento com GPS.
A equipe modelou o software e desenvolveu o sistema de forma que ele está
preparado para a instalação de um sensor GPS que possa armazenar a posição dos
buracos encontrados.
40
5 CONCLUSÃO
O objetivo do projeto foi a produção de um sistema embarcado que identifica
buracos em ruas e estradas quando veículos passem pelos mesmos.
A utilização de um sensor foi indispensável. Assim, utilizou-se um
acelerômetro e um dispositivo Arduino para interfacear o sensor com o software
desenvolvido.
Desenvolveu-se também um software para a obtenção dos dados fornecidos
pelo conjunto Arduino e acelerômetro como também para a interpretação dos
mesmos, realizando toda a identificação dos buracos.
Percebeu-se que o software indicava buracos quando a bicicleta passava não
só por buracos, mas também por pequenas irregularidades. Para a correção desse
problema foi necessário aumentar a constante de tolerância nas configurações do
sistema – o que minimizou consideravelmente os erros, mas o problema não foi
corrigido por completo.
Os erros encontrados podem ser justificados por alterações externas devido
aos amortecedores da bicicleta, à deficiência do programa em reconhecer que o
sistema já se encontra em um declive e à falta de consciência do conjunto de
amostras passadas de acelerações pelo algoritmo.
Apesar dessas complicações, o sistema funciona de forma satisfatória
(considerando o curto prazo e o objetivo geral da matéria), tendo sido capaz de
identificar todos os buracos pelos quais o sistema passou nos testes.
Por fim, vale reforçar que o sistema apresentado nesse documento é um
protótipo para futuras utilizações em veículos e dá base para o desenvolvimento de
um sistema complexo que conte com a localização de buracos e reporte os mesmos
para um sistema de controle de estradas e rodovias.
41
REFERÊNCIAS
BORGES, P., Carvalho, T., Pires, T., Torres, M., & Milian, F. M. (2011). Embedded
System for Detecting and Georefencing Holes in Roads. 33 (1).
BOULOS, P., & Camargo, I. d. (1987). Geometria Analítica: Um tratamento Vetorial.
São Paulo: Makron Books.
DIAS FILHO, R. P. (s.d.). Protocolo de Comunicação I2C. Acesso em Fevereiro de
2013, disponível em Protocolo de Comunicação I2C:
http://www2.eletronica.org/artigos/eletronica-digital/protocolo-de-comunicacao-i2c
ERIKSSON, J., Girod, L., Hul, B., R. N., Madden, S., & Balakrishnan., H. (2008). The
Pothole Patrol: Using a Mobile Sensor Network for. p. 11.
Justiça, R. (2010). Turma Recursal Federal Mantém Indenização por Acidente
Causado por Buraco na Pista. Revista Eletrônica da Seção Judiciária nº 10 .
NETO, J. B. (2004). Mecânica Newtoniana, Lagrangiana e Hamiltoniana. Livraria da
Física.
ODGEN, K. W. (1996). Safer roads: a guide to road safety engineering. p. 516.
ODGEN, K. W. (1997). The Effects of Paved Shoulders on Accident on Rural
Highways. Accident Analysis and Prevention , pp. 353-362.
SERWAY, R. A., & JR., J. W. (2008). Princípios de Física vol. 1: Mecânica Clássica.
São Paulo: Cengage Learning.
STEINBRUCH, A., & Winterle, P. (1987). Geometria Analitica. São Paulo: Makron.
SUYAMA, M. (2006). Protocolos de Comunicações. Acesso em Fevereiro de 2013,
disponível em Protocolos de Comunicações:
http://www.criarweb.com/artigos/533.php
TIPLER, P., & Mosca, G. (2009). Física Para Cientistas e Engenheiros Volume I:
Mecânica, Oscilações e Ondas, Termodinâmica. São Paulo: Editora LTC.
42
APÊNDICES
APÊNDICE A – CUSTOS DO PROJETO
Todos os componentes eletrônicos envolvidos no projeto até o presente
momento estão descritos na Tabela 2. A maior parte deles foi importada de lojas
online internacionais. Para reduzir custos, todos os produtos importados foram
adquiridos pela equipe no último trimestre de 2012, tendo um tempo de entrega em
média de 2 meses. Os componentes foram fabricados na China e enviados por
pessoa física da cidade de Hong Kong por meio do serviço postal oficial do país,
China Post.
Tabela 2 - Orçamento
Produto Quantidade Preço
Arduíno Mega 2560 1 R$ 130,00
Acelerômetro ADXL345 1 R$ 15,00
Resistor 220Ω 10 R$ 0,30
Resistor 1kΩ 10 R$ 0,30
Carrinho de Controle Remoto 1 R$ 100
Placa Isopor 1 R$ 5
Protoboard 1 R$ 15,00
Jumpers 64 R$ 10,00
Total R$ 275,60
43
APÊNDICE B – Cronograma do projeto
As tarefas e atividades desenvolvidas pela equipe foram definidas em
reuniões. Prazos, metas e avanços foram as principais pautas das reuniões
semanais. O diagrama de Gantt, Figura 19, aponta em resumo as tarefas que foram
realizadas pela equipe até o final do projeto.
44
Figura 19 – Cronograma
