Printer Friendly

System to collect and make available data from potential roles in highways/Sistema para Coleta e Disponibilizacao de Dados de Potenciais Buracos em Rodovias.

1. Introducao

A malha rodoviaria brasileira e responsavel pelo escoamento da producao industrial e agricola do pais. Atraves dela e possivel o trafego de bens e pessoas pelo territorio nacional e a sua qualidade reflete diretamente no custo e na seguranca do transporte, tornando necessaria a manutencao periodica das vias para que elas oferecam seguranca e conforto para seus usuarios.

Dados do Sindicato Nacional Da Industria De Componentes Para Veiculos Automotores e da Associacao Brasileira Da Industria De Autopecas (2016) apresentam que, em 2016, no Brasil, a frota circulante de automoveis, caminhoes e onibus contava com aproximadamente 42,9 milhoes de unidades, revelando um pequeno aumento de 0,7 % em relacao ao ano anterior.

De acordo com a Confederacao Nacional de Transporte (2016) nesse mesmo periodo houve, na malha rodoviaria brasileira, um aumento de 26,6% no numero de trechos com buracos grandes, quedas de barreiras, pontes caidas e erosoes, passando de 327 para 414 o numero de pontos criticos. Desses, 304 sao trechos que possuem buracos com dimensoes maiores que o de um pneu de um automovel de passeio e sao ocasionados geralmente pela sobrecarga dos veiculos que trafegam e/ou pela espessura inadequada ou insuficiente empregadas na construcao do pavimento.

No estado de Santa Catarina 59,3% (1.886 km) das rodovias apresentam algum tipo de deficiencia. Dessa deficiencia nas estradas estaduais, 43,3% apresentaram pavimento em condicoes regular, ruim ou pessimo, deficiencia essa que eleva o custo da manutencao dos veiculos e o consumo de combustivel, alem de reduzir a seguranca no trafego diario de automotores. Segundo a CNT (Confederacao ..., 2016), essas deficiencias apresentadas no pavimento das rodovias fazem com que o custo operacional do transporte no Estado sofra um acrescimo estimado de 23,5%.

A manutencao das vias e de responsabilidade do governo ou das concessionarias proprietarias (Confederacao ..., 2016), sendo que as estatais sao distribuidas nas esferas em que se encontram (municipal, estadual ou federal).

Nas vias estatais e necessario um processo para a autorizacao do reparo e/ou manutencao, visando a obtencao de recursos para realizacao do servico. Para justificar a utilizacao desses recursos para manutencao, e importante que existam dados que comprovem a necessidade real do servico com informacoes como localizacao e o tipo de dano encontrado.

Moreira et al. (2013) afirmam que a presenca de buracos nas rodovias brasileiras e a influencia que eles exercem na ocorrencia de acidentes, fato ocasionado por uma manutencao deficiente e sem um criterio de escolha dos locais a serem reparados.

Trindade (2015) defendem a importancia do monitoramento de rodovias como forma de melhorar o planejamento da manutencao e adequacao das vias, coletando dados que acusaram pontos que demandam manutencao.

No ano de 2015, uma analise realizada pela Confederacao Nacional de Transporte (2016) apontou que 36,52% do montante de recursos autorizados para infraestrutura de transporte rodoviario nao foram utilizados. Esses valores nao utilizados poderiam ser convertidos em melhorias na malha viaria que reduziriam o numero de trechos deficientes e, consequentemente, aumentaria a seguranca e satisfacao de seus usuarios.

Assim, torna-se essencial o uso de um sistema que apresente um mapeamento dos trechos com buracos existentes em rodovias e que ao mesmo tempo permite armazenar a sua localizacao. Isso possibilitaria aos usuarios escolher qual rota utilizar para desviar de trechos esburacados e tambem seria um recurso util para que os responsaveis pela manutencao pudessem justificar os orcamentos de manutencao da infraestrutura de transporte rodoviario ou para cobrar as empresas responsaveis, quando estas estiverem sob concessao de uma empresa de iniciativa privada.

Alem disso, o sistema possibilitaria tambem a implantacao de planos de monitoramento planejado das vias, favorecendo a qualidade da estrutura viaria e um melhor aproveitamento dos recursos liberados para sua manutencao.

Esses dados mostram a colaboracao que esse sistema oportunizaria aos usuarios dessas estradas e tambem para a economia local, justificando a relevancia de sua implementacao

Com conhecimento desse problema e da importancia de uma manutencao mais eficiente e melhor planejada de nossas rodovias, esse projeto visou a elaboracao de um sistema que detecte a presenca de buracos em rodovias, utilizando-se dos conceitos das Leis da Mecanica de Newton para identificar os possiveis buracos encontrados ao longo da estrada e realizando o seu mapeamento atraves do uso de GPS (Global Positioning System). Toda a informacao coletada pelo sistema fica disponivel em uma pagina Web, permitindo assim, que os dados sejam consultados por quem tiver interesse.

2. Trabalhos correlatos

Pensando no desenvolvimento do trabalho, foi necessario efetuar uma busca em bases de dados para analisar os trabalhos correlatos. Assim, foi realizada busca no portal de periodicos da Coordenacao de Aperfeicoamento de Pessoal de Nivel Superior (CAPES), no Google Academico, e na base de dados da IEEE (IEEExplore) onde foram encontrados apenas os trabalhos de Borges et al. (2011), Moreira et al. (2013) e Rauta et al. (2017).

Borges et al. (2011) apresentam a proposta de um sistema para identificar a localizacao geografica dos buracos em estradas. No seu experimento foi utilizado um sistema com um microcontrolador, um modulo Bluetooth, um aparelho celular com GPS e um Wii remote adaptados a um carro de controle remoto. Com o projeto, Borges et al. (2011) concluiram que o sistema se mostrou viavel para a deteccao de buracos em estradas.

Moreira et al. (2013) desenvolveram um sistema semelhante. O objetivo do projeto era detectar buracos em estradas ou rodovias utilizando um acelerometro. Para tanto foram utilizados um microcontrolador, um acelerometro e um computador com um software para interpretacao dos dados processados. No experimento foi utilizado uma bicicleta para realizacao dos testes. O resultado obtido pelos autores foi um sistema capaz de identificar todos os buracos pelo qual o prototipo passou, com a ressalva de que ao sair de um buraco o sistema acabava identificando outro buraco.

Ja Rauta et al. (2017) se basearam nos dois outros trabalhos e apresentam uma proposta de um sistema para identificacao de buracos atraves das leis da mecanica de Newton. Porem, trata-se apenas de uma proposta e nao houve desenvolvimento no projeto.

Nos dois primeiros projetos apresentados a ideia de utilizar um sistema embarcado para identificar buracos obteve resultados satisfatorios, porem com suas aplicacoes em prototipos que nao refletem na totalidade o cenario real. Esse fator acaba influenciando os resultados, pois a disposicao dos eixos, o peso e as dimensoes maiores que um carro possui modificaria a logica necessaria para a identificacao de um buraco.

No trabalho de Borges et al. (2011) o prototipo utilizado possuia dimensoes muito distantes de um carro em tamanho real, e a dimensao dos buracos pelos quais ele passou tambem eram igualmente menores. Esse detalhe foi explorado no trabalho de Moreira et al. (2013) onde o prototipo pode passar por buracos no tamanho real pelo qual um carro passaria. Entretanto, o prototipo ainda estava longe da estrutura de um carro, uma vez que o carro possui quatro eixos e um peso substancialmente maior.

O intuito desse projeto foi desenvolver um sistema semelhante aos citados anteriormente em um carro, simulando o ambiente real pelo qual o sistema iria passar. Assim, esse projeto foi baseado na proposta de Rauta et al. (2017), o qual forneceu uma base teorica e uma metodologia a ser seguida no desenvolvimento do projeto.

A fim de comparar os trabalhos correlatos com o trabalho desenvolvido por esse projeto, foram elencados alguns criterio de comparacao entre os trabalhos. Os criterios utilizados foram: (i) se a localizacao era realizada por GPS ou por algum outro mecanismo; (ii) se o sistema era capaz de identificar buracos em tamanho real ou apenas grandes buracos; (iii) se foi desenvolvido um prototipo em escala real dentro de um carro, ou se foi montado um prototipo em uma outra escala; e (iv) se os dados lidos/obtidos pelo sistema seriam disponibilizados de alguma forma. Com base nesses criterios foi elaborada a Tabela 1, a qual apresenta o comparativo entre as principais diferencas entre os projetos citados em relacao a este projeto.

3. Solucao desenvolvida

A solucao proposta foi baseada na proposta de Rauta et al. (2017) com foco na coleta de informacao dos dados de possiveis buracos encontrados em rodovias e a disponibilizacao desses dados na forma de um mapeamento dos buracos identificados. Para isso, o sistema desenvolvido possui um modulo embarcado que coleta informacoes de ocorrencias de possiveis buracos e disponibiliza essa informacao atraves de uma aplicacao web instalada na nuvem. Assim, o sistema faz uso dos seguintes equipamentos de hardware: 1 Placa Arduino UNO; 1 Sensor acelerometro MPU6050; 1 Raspberry PI3; 1 Sensor GPS GYNEO6Mv2 + antena ceramica; 1 servidor em cloud.

Em relacao ao software, para obtermos as funcionalidades necessarias para o funcionamento do sistema, foram desenvolvidos os seguintes modulos: Modulo Servidor Web (MSW); Modulo Cliente (MC); Modulo Servidor Local (MSL), e Modulo Captacao de Dados (MCD). Para o funcionamento do sistema completo, os modulos interagem entre si ate os dados chegarem a um usuario conectado ao Modulo Cliente.

A Figura 1 apresenta o diagrama de distribuicao do sistema, exemplificando as interacoes entre os modulos ate as informacoes chegarem ao cliente. Esse projeto teve foco no desenvolvimento dos modulos destacados em amarelo. O Modulo Captacao de Dados, em branco, nao foi desenvolvido em sua totalidade pois nao era o objetivo principal desse projeto.

O Modulo Captacao de Dados (MCD) faz uso de uma placa Arduino UNO instalada em cada um dos eixos do carro, proximo ao amortecedor. Nessa placa foi acoplado o sensor acelerometro que faz a captacao dos valores das forcas gravitacionais, que serao recebidos pela aplicacao instalada no Arduino e enviados ao Modulo Servidor Local (MSL). Nesse modulo nao foi implementado o algoritmo completo para avaliacao das forcas gravitacionais, apenas uma aplicacao para teste e validacao do sistema. Alem disso, esse modulo deveria ser instalado nos eixos do carro, o que inviabilizou seu desenvolvimento completo.

O Modulo Servidor Local (MSL) faz a integracao com o MC para receber os dados dos sensores. O MSL possui integracao com o MC atraves do cabo USB utilizado para comunicacao e para alimentacao da placa Arduino. Isso possibilita o recebimento da leitura das variacoes identificadas pelo acelerometro do MC.

Alem de integrar com o Arduino, no modulo MSL sao armazenados os dados dos eventos capturados pelos sensores e, no momento em que o usuario solicitar o envio, existindo a disponibilidade de uma conexao com a internet, ele deve integrar com o Modulo Servidor Web (MSW), permitindo o envio dos dados recolhidos pela aplicacao instalada no Raspberry PI para armazenamento no banco de dados do MSW.

O Modulo Servidor Web (MSW) precisa estar disponivel para o MSL enviar os dados e para o Modulo Cliente (MC) consumir esses dados. Para armazenar esses dados, foi utilizado um banco de dados nao relacional MongoDB, que possui alta escalabilidade e facilidade na integracao com outras tecnologias, hospedado na nuvem atraves de um servico de gerenciamento de banco de dados online, o mLab. A insercao nesse banco de dados ocorre via socket, atraves de uma aplicacao implementada utilizando TCP/IP, que recebe requisicoes da aplicacao cliente existentente no MSL.

Para disponibilizar esses dados para o MC, foi implementado um Web Service RESTful utilizando o framework Jersey e o servidor Apache Tomcat, que permite consultas ao banco de dados com a possibilidade de efetuar buscas por data e/ou carro.

Por fim, para disponibilizar e apresentar os dados para o usuario, foi implementado uma pagina web que permite buscar todos os buracos encontrados ou realizar uma busca filtrada por periodo, por nome do carro ou por carro em um determinado periodo. Esses dados sao consumidos do Web Service e apresentados em um mapa utilizando a API do Google Maps e tambem em uma tabela. No mapa, cada buraco e representado por um marcador que, ao clicar sobre ele, apresenta um quadro com as informacoes individuais sobre cada buraco.

4. Validacao

Para a validacao do sistema foi realizada uma pesquisa experimental com os modulos desenvolvidos na qual foram realizados testes para validar a funcionalidade do MSL, MSW e MC. Foram realizados 9 testes, (I) teste de funcionamento no carro por 15 minutos; (II) teste de funcionamento no carro com interrupcao; (III) teste de funcionamento no carro configurado para encontrar buracos em um intervalo menor de tempo; (IV) teste de funcionamento no carro configurado para encontrar efetivamente um buraco; (V) teste de envio dos dados; (VI) teste de insercao no banco de dados; (VII) teste de persistencia e armazenamento de dados; (VIII) teste dos filtros de consulta e da apresentacao dos dados; e (IX) teste do sistema funcionando por completo.

No Modulo Servidor Local (MSL), foram realizados testes para verificar a captura das leituras do acelerometro e do GPS e o envio desses dados para o Modulo Servidor Web (MSW). Para testar a captura das leituras dos sensores, foi instalado um programa configurado para que, a cada 15 segundos, simulasse que o sistema encontrou um buraco. Guardando assim as informacoes da posicao do carro atraves do GPS e tambem a leitura atual, as 10 leituras anteriores e as 10 leituras posteriores a identificacao do buraco, durante um periodo de 15 minutos. Nos testes realizados no automovel, o sistema foi ligado a alimentacao 12V.

Devido a alimentacao das tomadas do carro serem energizadas no acionamento do motor, cada vez que o carro era desligado, essa alimentacao era cortada automaticamente, interrompendo assim o funcionamento da aplicacao. A Figura 2.a apresenta a disposicao do sistema no interior do carro. Essa ligacao e disposicao permitiu que o sistema funcionasse por um tempo menor para testar a persistencia de dados em condicoes adversas de funcionamento como, por exemplo, quando o motor do carro desliga sem a intencao do condutor. Ja a Figura 2.b apresenta a ligacao do sistema a alimentacao 12V do carro.Nos primeiros testes, apos configurada a aplicacao no Raspberry PI, o carro percorreu dois trajetos diferentes: no teste I pelo tempo necessario para o sistema rodar o programa por completo (15 minutos), e no teste II o sistema funcionando por aproximadamente 7 minutos ate ser interrompido pelo desligamento do motor do carro--corte na alimentacao. Depois, no retorno desse trajeto, o sistema foi religado e pode funcionar pelos 15 minutos necessarios para a aplicacao rodar por completo, totalizando 22 minutos de captura de buracos no segundo teste.

O teste III foi realizado alterando a configuracao do sistema para simular o encontro de um buraco a cada 7 segundos durante o periodo de 7,5 minutos. Apos percorrer o trajeto por aproximadamente 3 minutos, o motor do carro foi desligado e logo em seguida religado, permitindo que a aplicacao voltasse a funcionar, agora pelos 7,5 minutos necessarios. O sistema foi submetido a esse teste para verificar a disponibilidade da aplicacao apos uma interrupcao repentina da alimentacao, e para verificar a capacidade de buracos/segundo que ele poderia capturar.

Apos finalizar os testes descritos acima, a configuracao foi alterada para encontrar efetivamente um buraco, sendo o teste IV, realizado. Como o algoritmo para identificar um buraco nao foi desenvolvido nesse projeto, foi convencionado que o sistema consideraria como buraco os eventos dos sensores onde a leitura "AngleX" do acelerometro ultrapassasse o valor de 16.500. Valor escolhido arbitrariamente para que a aplicacao nao ficasse sensivel a ponto de encontrar eventos a todo instante, nem rigoroso demais impedindo que fosse encontrado algum evento. O sistema entao foi instalado no porta-malas do carro, onde o acelerometro foi fixado sobre a caixa de ar do eixo traseiro esquerdo, com o restante do sistema fixado sobre uma prancha de madeira, alimentado pela saida 12V do automovel (Figura 2.b).

Nesse quarto teste, o sistema foi programado para rodar durante um periodo de 10 minutos, no qual, durante o trajeto percorrido aleatoriamente, o carro fez varias paradas e, em cada uma, o carro foi desligado, fazendo com que o sistema nao funcionasse pelo tempo total de 10 minutos, simulando a condicao de uso na rotina diaria de uma pessoa que precisa realizar varios pequenos trajetos, como fazer compras, abastecer e levar o filho para escola.

Com os dados dos buracos armazenados no servidor local, foi possivel realizar o teste V: o envio de dados para o servidor web. Em cada vez que foi verificado o armazenamento dos dados coletados no Raspberry, a aplicacao de envio era iniciada para integrar os dados coletados com o servidor web.

O teste VI foi realizado para confirmar se os dados foram realmente inseridos, possibilitando a sua consulta. Para isso, foi acessado o gerenciador do banco de dados e, apos, foi acessado a pagina clicando para buscar todos os buracos.

Ja o teste VII, de persistencia e de armazenamento de dados, tambem foi realizado no servidor web: foram incluidos na pasta em que sao armazenados os buracos no Raspberry, todos os arquivos JSON de buracos encontrados (244 no total) e entao iniciou-se a aplicacao de envio.

Apos a insercao no banco de dados, o teste VIII foi realizado acessando a pagina web e efetuando consulta a todos os buracos (sem filtro), e depois foram realizadas consultas com o filtro de nome do carro, filtro por periodo e por ultimo consulta com o filtro de nome do carro dentro de um periodo.

Como teste final IX, foi implementado um programa com as configuracoes do teste que encontrou efetivamente um buraco. Esse teste nao foi realizado dentro do veiculo, foi realizado proximo ao computador por um periodo de 75 segundos. O objetivo era simular o sistema funcionando integralmente, desde a identificacao do buraco ate a apresentacao dos dados na pagina web.

Nesse teste IX o sistema foi posicionado com o sensor acelerometro na extremidade de uma mesa para que, no momento oportuno, fosse possivel inclina-lo para baixo, alterando assim o valor do "AngleX" do acelerometro (Figura 3). Apos essa movimentacao no acelerometro, um buraco seria identificado, dando inicio a captura dos dados.

5. Resultados

Com os testes realizados, foi possivel verificar que no teste I, apos percorrer os trajetos e acessado o sistema operacional do Raspberry PI, a aplicacao foi capaz de encontrar 60 buracos e 95 buracos no teste I. No teste III, onde o sistema estava configurado para encontrar buracos em um intervalo menor de tempo, a aplicacao foi capaz de encontrar 37 buracos.

Analisando o resultado dos tres primeiros testes, verificou-se que ha uma limitacao do sistema para encontrar buracos em periodos menores que 10 segundos. A limitacao ocorre pelo fato de que, apos identificar um possivel buraco, o sistema e programado para guardar as 10 proximas leituras do acelerometro, que envia essa informacao para o Raspberry a cada segundo. Como nesse momento ele esta aguardando receber as 10 proximas leituras para gravar as informacoes em arquivo, foi colocada uma trava no sistema que so e liberada quando terminar a gravacao para garantir a integridade dos dados coletados.

Essa funcionalidade de guardar as leituras seguintes foi inserida no sistema para que ela possa ser utilizada no desenvolvimento do algoritmo de identificacao de buracos, sendo que, apos esse algoritmo ser desenvolvido, existe a possibilidade de se retirar essa funcionalidade, permitindo reduzir o intervalo desse bloqueio. Alem disso, em tese, com essas leituras o algoritmo para reconhecimento de buracos eliminaria o problema relatado por Moreira et al. (2013), de detectar um buraco quando o veiculo esta saindo do buraco que havia entrado.

O teste IV considerava um buraco quando os eventos captados pelos sensores tivessem a leitura do "AngleX" com valor acima de 16.500 e, com essa configuracao, no trajeto percorrido, foram identificados 12 buracos. Demonstrando assim que e possivel o desenvolvimento de um algoritmo para identificacao de buracos utilizando as variacoes de forcas obtidas atraves do acelerometro.

Nos testes V e VI, como resultado do envio dos dados coletados ao servidor web, no teste I o servidor retornou que foram inseridos 60 buracos, no envio dos buracos do teste II foram 95 buracos, e no trajeto aleatorio do teste III, 12 registros foram inseridos no banco de dados.

Para confirmar se os dados foram realmente inseridos, foi acessado o gerenciador do banco de dados e confirmou-se, nas tres ocasioes, que a insercao ocorreu corretamente e no mesmo instante que foram enviados.

O teste VII e semelhante ao anterior, e como resultado foram inseridos 244 novos registros no banco, e foi possivel visualizar todos eles na pagina web. A Figura 4 mostra o envio atraves da aplicacao no Raspberry PI com a quantidade de registros inseridos retornada pelo servidor web, e os registros atualizados no banco de dados.Com esse teste a persistencia de dados foi colocada a prova. Nessa ocasiao, o sistema demorou aproximadamente 1 minuto e 30 segundos para enviar todos os 244 registros armazenados, devido ao fato de ser inserido um registro por vez para garantir a atomicidade e a consistencia dos dados, mas ao final, todos os dados foram inseridos.Ao realizar o teste VIII do consumo desses dados atraves do web service, ao clicar para buscar todos os buracos na pagina, foram apresentados todos os registros encontrados tanto na tabela quanto no mapa, com os marcadores apresentando as informacoes individuais de cada buraco, e ao utilizar os filtros, foram apresentados somente os dados filtrados.

A Figura 5 mostra a pagina web carregada apos enviar os dados para o servidor, com o mapeamento e a tabela de buracos. No inicio da visualizacao do mapa os marcadores ficaram bem proximos uns dos outros, mas a medida que se aproximava a imagem utilizando o zoom, foi possivel identificar os buracos atraves de cada marcador, melhor ilustrado pela Figura 6.

No teste final, teste IX, foram simulados 4 buracos. Com esse teste foi possivel simular como o sistema se comportaria no ambiente real, desde a captura dos dados, a identificacao do possivel buraco ate a apresentacao dos dados ao usuario. O resultado foi positivo, pois foi possivel visualizar os 4 buracos encontrados na pagina em tempo de execucao, logo apos o banco ter sido atualizado.

Os testes que foram realizados mostram o funcionamento da aplicacao e demonstram a viabilidade do sistema para uso aplicado na deteccao e mapeamento de buracos em rodovias, auxiliando na elaboracao de programas para manutencao e melhorias de estradas.

6. Conclusoes

O objetivo deste trabalho foi desenvolver uma ferramenta capaz de captar as informacoes e a localizacao de possiveis buracos encontrados em rodovias, disponibilizando e demonstrando esses dados na forma de um mapeamento de buracos nas rodovias.

O sistema necessita passar por varias etapas para chegar ate o mapeamento apresentado ao usuario, e o desenvolvimento de modulos e a integracao entre eles foi essencial para que essa funcionalidade pudesse ser oferecida. Como o objetivo inicial do projeto nao era a identificacao de buracos, mas sim o mapeamento dos mesmos, essa funcionalidade nao foi desenvolvida.

Atraves dos Modulos de Captacao de Dados (MCD) e Modulo Servidor Local (MSL) embarcados em um carro, foi possivel identificar potenciais buracos e armazenar localmente esses dados. Com a integracao dos Modulos Servidor Local (MSL) com o Mosulo Servidor Web (MSW), foi possivel enviar esses dados e armazena-los na nuvem, onde um Web Service disponibiliza a consulta a essas informacoes, consumidas atraves de uma pagina web (Modulo Cliente--MC) que apresenta um mapeamento dos buracos encontrados, buracos estes representados cada um por um marcador contendo as informacoes capturadas pelos sensores do MCD.

Os testes realizados atestaram a atomicidade e a consistencia dos dados do sistema, alem da sua disponibilidade no ambiente testado. Entretanto, para garantir a atomicidade dos dados, o desempenho da aplicacao em identificar os possiveis buracos foi diminuido, limitando em 10 segundos o intervalo necessario para encontrar um proximo buraco, fator que podera ser aperfeicoado apos o desenvolvimento do algoritmo para identificar efetivamente um buraco.

Ao visualizar o mapeamento dos dados na pagina, e possivel identificar os pontos no trajeto percorrido atraves da identificacao do carro e do horario de captura dos dados, permitindo assim a utilizacao da ferramenta por multiplos usuarios.

Com essas informacoes e possivel concluir que o sistema e capaz de captar as informacoes dos possiveis buracos e apresentar um mapeamento de forma que o usuario pode localizar em que parte do trajeto ha um possivel buraco, gerando valor de utilidade ao sistema desenvolvido.

Como trabalhos futuros, sugere-se o desenvolvimento de um algoritmo capaz de identificar e classificar buracos usando os dados capturados pelo sensor acelerometro; fazer uso de cameras para auxiliar na identificacao de buracos; a instalacao dos MCD nos quatro eixos de um carro, aumentando assim a performance do sistema em localizar buracos; e a implementacao de uma solucao para a inicializacao do sistema e outro para enviar os dados para o servidor, de modo que o usuario nao precise acessar o sistema operacional do Raspberry PI para efetuar o envio desses dados.

As melhorias sugeridas sao para a pagina web do MC, na qual poderiam ser acrescentados outros tipos de filtros, otimizar a apresentacao da tabela dos buracos, assim como implementar uma opcao para buscar buracos por localidade e/ou regiao. Tambem seria interessante a implementacao de um acesso a pagina como administrador, possibilitando a edicao de dados, por exemplo a exclusao de buracos que foram recapeados ou registros muito proximos, que podem ser buracos duplicados.

Assim, o projeto desenvolvido pode ser utilizado como estrutura para um sistema completo de mapeamento de buracos em rodovias, no qual as melhorias realizadas pelos proximos trabalhos incrementariam a utilidade e usabilidade do sistema, fazendo com que a justificativa de se oferecer uma ferramenta util tanto para quem necessita dar manutencao as rodovias quanto para quem e usuario sejam alcancadas.

Recebido/Submission: 03/09/2018

Aceitacao/Acceptance: 15/11/2018

Referencias

BORGES, P. de S. et al. (2011) Embedded system for detecting and georeferencing holes in roads. IEEE Latin America Transactions, 9(6), 921-925. DOI: 10.1109/TLA.2011.6096973

CONFEDERACAO NACIONAL DO TRANSPORTE (2016). Pesquisa CNT de rodovias 2016: relatorio gerencial. 20. ed. Brasilia: CNT: SEST: SENAT.

MOREIRA, A. R. et al. (2013) Sistema de deteccao de buracos em estradas. Trabalho de conclusao de curso (Graduacao). Universidade Tecnologica Federal do Parana, Departamento Academico de Informatica, Curso de engenharia de computacao, Curitiba, Brasil.

RAUTA, L. et al. (2017) Proposta de sistemas embarcados para identificacao de buracos em rodovias utilizando as Leis da Mecanica de Newton. In: Anais do Computer on the Beach 2017. ISSN: 2358-0852.

SINDICATO NACIONAL DA INDUSTRIA DE COMPONENTES PARA VEICULOS AUTOMOTORES; ASSOCIACAO BRASILEIRA DA INDUSTRIA DE AUTOPECAS (2017). Relatorio da frota circulante 2017. Sao Paulo: Sindicato Nacional da Industria de Componentes para Veiculos Automotores.

TRINDADE, D. H. (2015) Monitoramento de sistemas de transporte com Arduino e Shield-GSM, GPS, GPRS. Trabalho de conclusao de curso (Graduacao). Universidade de Brasilia, Faculdade UnB Gama, Curso de Engenharia Eletronica, Brasilia, Brasil.

Jefferson Kamigashima, Leonardo Rauta

jeffersonkamigashima@gmail.com, leonardo.rauta@ifsc.edu.br

Instituto Federal de Santa Catarina (IFSC)--Campus Gaspar. Brasil.

DOI: 10.17013/risti.30.78-90

Caption: Figura 1--Diagrama de distribuicao

Caption: Figura 2--Sistema instalado no porta-malas do automovel. a) montagem do sistema contendo a placa Raspberry ligada ao modulo GPS; b) alimentacao do sistema via 12V

Caption: Figura 3--Teste em bancada

Caption: Figura 4--Insercao no banco de dados. a) Logs da aplicacao no Raspberry PI informando que foram enviados 244 registros b) Pagina do banco de dados demonstrando que foram armazenados 244 registros

Caption: Figura 5--Pagina web apresentando localizacao de possiveis buracos a) Site apresentando o mapa com os buracos identificados b) Informacoes detalhadas sobre os buracos identificados

Caption: Figura 6--Zoom no mapa de buracos pra apresenta-los de forma mais visual
Tabela 1--Comparativo entre os trabalhos correlatos

Trabalho          Localizacao via    Buracos em       Prototipo em
                  GPS?               tamanho real?    escala real?

Borges et al.     Sim                Nao              Nao
Moreira et al.    Sim                Nao              Nao
Rauta et al.      Sim                Sim              Nao
Este trabalho     Sim                Sim              Sim

Trabalho          Disponibilizacao
                  dos dados?

Borges et al.     Nao
Moreira et al.    Nao
Rauta et al.      Sim
Este trabalho     Sim
COPYRIGHT 2018 AISTI (Iberian Association for Information Systems and Technologies)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2018 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Kamigashima, Jefferson; Rauta, Leonardo
Publication:RISTI (Revista Iberica de Sistemas e Tecnologias de Informacao)
Date:Dec 1, 2018
Words:4608
Previous Article:Congestion control mechanism for data transfers in multiple Multicast/Mecanismo de control de congestion para transferencias de datos en Multicast...
Next Article:Addressing the Usability Analysis of Tanziflex, a Web Tool for Operational Research/Abordando el Analisis de Usabilidad de Tanziflex, una Herramienta...
Topics:

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters