1

CENTRO UNIVERSITÁRIO FUNDAÇÃO SANTO ANDRÉ

ISRAEL ZANATA ESCORIZZA

RASTREAMENTO VEICULAR COM AQUISIÇÃO DE IMAGEM

SANTO ANDRÉ

2015
 2

ISRAEL ZANATA ESCORIZZA

RASTREAMENTO VEICULAR COM AQUISIÇÃO DE IMAGEM

Trabalho de Conclusão de Curso

apresentado como exigência parcial para
obtenção de grau de bacharel em
engenharia eletrônica com ênfase em
telecomunicações, à Faculdade Eng.
Celso Daniel do Centro Universitário
Fundação Santo André.

Orientador:

Prof. Dr. Marcos Forte

SANTO ANDRÉ

2015
 3

Candidato: Israel Zanata Escorizza

Título: Rastreamento veicular com aquisição de imagem.

Trabalho de Conclusão de Curso apresentado como exigência parcial para obtenção

do grau de Engenheiro Eletrônico, à Faculdade de Engenharia Eng. Celso Daniel do
Centro Universitário Fundação Santo André, Curso de Engenharia Eletrônica com
ênfase em Telecomunicações.

Data: 08 de dezembro de 2015.

Professor: Dr. Marcos Forte

____________________

Instituição Centro Universitário Fundação Santo André (Assinatura)

Professor: Me. Josemar dos Santos

____________________

Instituição Centro Universitário Fundação Santo André (Assinatura)

Aprovado ( )
 4

Nota: ______

AGRADECIMENTOS

Ao Prof. Dr. Marcos Forte pela dedicação durante a orientação deste trabalho,
sempre apontando o melhor caminho a ser trilhado;

ao Centro Universitário Fundação Santo André e seu corpo docente que durantes os
anos dedicados nesta graduação pavimentaram o caminho do conhecimento sem o
qual este trabalho não seria possível;

aos amigos, familiares e a minha noiva e futura esposa Ariadina Arrais Ribeiro pelo
carinho, compreensão e apoio nos momentos mais árduos.
 5

“A menos que modifiquemos nossa maneira

de pensar, não seremos capazes de resolver os
problemas causados pela forma como nos
acostumamos a ver o mundo”.

Albert Einstein
 6

RESUMO

Segundo a Secretaria de Segurança Pública de São Paulo, a

criminalidade no estado é uma das mais elevadas das últimas décadas, com
destaque para o roubo e furto de veículos, tornando-se cada vez mais necessário a
utilização de dispositivos de segurança e rastreamento, e para atender esta grande
demanda o mercado apresenta soluções cada vez mais sofisticadas de
monitoramento. Em análise realizada dos serviços disponibilizados pelas principais
prestadoras deste serviço, verificou-se que todas são capazes de informar em tempo
real o posicionamento do automóvel, porém poucas disponibilizam acesso a
imagens do interior do veículo, e as que disponibilizam, cobram um alto custo do
cliente, o que vai contra a realidade onde cada vez mais a demanda de informação
em tempo real cresce. Este trabalho descreve os passos do desenvolvimento de um
protótipo de baixo custo baseado em Arduino e no modulo SIM908, para aquisição
de localização e imagem, com transmissão dos dados pela rede de dados
GSM/GPRS, incluindo toda codificação realizada no protótipo e no desenvolvimento
de um servidor para armazenamento e exibição da informação.

Palavras-chave: Segurança. Monitoramento. Imagem. Arduino. GPS. GPRS.

 7

ABSTRACT

According to Secretaria de Segurança Pública de São Paulo, crime rates

in the state is one of the highest in decades, especially robbery and theft of vehicles,
increasing the necessity of safety and tracking devices, meeting this high demand,
market presents sophisticated monitoring solutions. Analysing services provided by
leading providers of monitoring services, all are able to report real-time positioning of
the carv, but few provide access to images of the inside and, those providing, charge
a high cost, against the reality where more and more real-time information demand
grows.This paper describes the steps in developing a low-cost prototype based on
Arduino and SIM908 module for acquisition of geolocation and image, with data
transmission over GSM/GPRS network, including all coding performed on the
prototype and development of a storage server and display of information.

Keywords: Security. Monitoring. Image. Arduino. GPS. GPRS

 8

LISTA DE ILUSTRAÇÕES

FIGURA 2-1 - REDE DE SATÉLITES GPS 16

FIGURA 2-2 - SENSOR DE IMAGEM CCD (ESQUERDA) E CMOS (DIRETA) 19
FIGURA 2-3 - MATRIZ DE BAYER E ATUAÇÃO DE FILTRO 20
FIGURA 3-1 - VISÃO MODULAR DO PROJETO 24
FIGURA 3-2 - ARDUINO UNO 25
FIGURA 3-3 - MÓDULO PTC06 V1.0 27
FIGURA 3-4 - MÓDULO WAVESHARE MICROSD 28
FIGURA 3-5 - MÓDULO SIM908 29
FIGURA 3-6 - SHIELD DFROBOTS SIM908 30
FIGURA 3-7 - ARDUINO UNO COM SHIELD DFROBOTS SIM908 ACOPLADO 31
FIGURA 3-8 - PROTOBOARD DOS MÓDULOS DE AQUISIÇÃO DE IMAGEM E ARMAZENAMENTO 32
FIGURA 3-9 - PROTOSHIELD COM OS MÓDULOS DE ARMAZENAMENTO E AQUISIÇÃO DE IMAGEM 33
FIGURA 3-10 - PROTOSHIELD INSTALADO JUNTO AO ARDUINO UNO E SHIELD DFROBOTS SIM908 33
FIGURA 3-11 - ARQUIVO SETUP.INF 36
FIGURA 3-12 – TRECHO DA ROTINA INISHIELD 37
FIGURA 3-13 - ROTINA GETIMAGEM 41
FIGURA 3-14 - ROTINA SENDGPRS 42
FIGURA 3-15 – ROTINA SENDFTP 43
FIGURA 3-16 - CRIAÇÃO DA TABELA TB_GPSINFO 44
FIGURA 3-17 - ROTINA DATA.PHP 45
FIGURA 3-18 - CODIFICAÇÃO PAGINA HTTP://GPSIMAGE.HOL.ES 46
FIGURA 4-1 - INSTALAÇÃO DO PROTÓTIPO 47
FIGURA 4-2 - IMAGEM CAPTURADA PELA CÂMERA 49
FIGURA 4-3 - ARQUIVO DE LOG DO PROTÓTIPO 51
FIGURA 4-4 - BANCO DE DADOS CONTENDO INFORMAÇÕES ENVIADAS 51
FIGURA 4-5 - ARQUIVOS ENVIADOS PARA SERVIDOR POR FTP 52
FIGURA 4-6 - PÁGINA DE ACESSO DO USUÁRIO 52
 9

LISTA DE TABELAS

TABELA 2-1 - ÍNDICE DE ROUBOS E FURTOS DE VEÍCULOS NA CIDADE DE SÃO PAULO 15

TABELA 2-2 - COBERTURA DA TECNOLOGIA 3G 23
TABELA 3-1 - PORTAS DE COMUNICAÇÃO ARDUINO UNO 26
TABELA 3-2 - GLOBAL POSITIONING SYSTEM FIXED DATA 38
 10

LISTA DE ABREVIATURAS E SIGLAS

SSP-SP Secretaria de Segurança Pública do Estado de São Paulo.

CONTRAN Conselho Nacional de Transito.

Navstar Navigation Satellite with Timing and Ranging.

NNSS Navy Navigation Satellite System.

GPS Global Positioning System.

RF Rádio Frequência

PRN Pseudo Random Noise

CCD Charge Coupled Device

CMOS Complementary Metal Oxide Semiconductor.

RGB Red, Green, Blue

CMYG Cyan, Magenta, Yellow, Green

SMC Serviços Móveis Celulares

GSM Global System for Mobile

TDMA Time Division Multiple Access

ETSI European Telecommunications Standards Institute

GPRS General Packet Radio Service

PWM Pulse Width Modulation

LED Light Emitting Diode

SPI Serial Peripheral Interface ou

SS Slave Select

MOSI Master Output, Slave Input

MISO Master Input, Slave Output

 11

SCK Serial Clock

TTL Lógica transistor-transistor

DSP Processador Digital de Sinal

NTSC National Television System Committee

JPEG Joint Photographic Experts Group

SDIO Secure Digital Input Output

SOA Arquitetura Orientada a Serviços

IDE Ambiente de Desenvolvimento Integrado

UTC Tempo Universal Coordenado

FTP File Transfer Protocol

HTML HyperText Markup Language

NMEA National Marine Eletronics Association

GPGGA Global Positioning System Fixed Data

URL Uniform Resource Locator

PHP Hypertext Preprocessor

 12

1. SUMÁRIO

1. INTRODUÇÃO 13

2. ESTUDO DA ARTE 14

2.1. MERCADO DE RASTREADORES VEICULARES 14

2.2. TECNOLOGIA GPS 16
2.3. CAPTURA DIGITAL DE IMAGEM 19
2.4. TRANSMISSÃO DE DADOS POR REDE DE TELEFONIA CELULAR 21

3. PROJETO 24

3.1. COMPONENTES 25
3.1.1. Arduino UNO 25
3.1.2. Módulo de aquisição de imagem 27
3.1.3. Módulo de armazenamento 28
3.1.4. Módulo GPS e Módulo GSM/GPRS 29
3.2. PROTÓTIPO – HARDWARE 31
3.2.1. Módulo GPS e Módulo GSM/GPRS 31
3.2.2. Módulo GPS e Módulo GSM/GPRS 32
3.3. PROTÓTIPO – SOFTWARE 34
3.3.1. Modelo de operação 34
3.3.2. Configuração de hardware 35
3.3.3. Aquisição de localização GPS 38
3.3.4. Aquisição de imagem e armazenamento de arquivos 40
3.3.5. Envio de informações por GSM/GPRS e FTP 42
3.4. SERVIDOR 44
3.4.1. Banco de Dados 44
3.4.2. Armazenamento de dados 45
3.4.3. Exposição de dados 45

4. RESULTADOS 47

5. CONCLUSÃO 54

REFERENCIAS 55

APÊNDICE A – FLUXO DE EXECUÇÃO DO SISTEMA 57

APÊNDICE B – CODIFICAÇÃO 58
 13

CODIFICAÇÃO ARDUINO 58
CRIAÇÃO DA TABELA NO BANCO DE DADOS 66
WEBSITE – AQUISIÇÃO DE DADOS 66
WEBSITE – EXIBIÇÃO DE DADOS 66

2. INTRODUÇÃO

Com o crescente índice de criminalidade no estado de São Paulo (SÃO

PAULO, 2015), com destaque para o aumento no roubo e furto de veículos, torna-se
cada vez mais essencial a utilização de sistemas de segurança e rastreamento.
Além disto, o governo aprova leis que delimitam a jornada de trabalho de motoristas
(BRASIL, 2012), punindo severamente com multas as empresas que permitem
jornadas excessivas dos funcionários. Para atender esta demanda, o mercado se
adequa com soluções cada vez mais sofisticadas de monitoramento (IDC, 2013).

O mundo torna-se cada vez mais conectado e a demanda de informação

em tempo real a respeito de tudo que acontece em nosso entorno somente aumenta
com a utilização de redes sociais, e dispositivos móveis que anteriormente somente
realizavam ligações e hoje possuem recursos de integração cada vez mais
aprimorados com redes sociais, onde se sabe o que amigos e familiares estão
vivenciando no dia-a-dia, e quase que em totalidade, necessitam de conexão de
dados para utilização dos vários recursos disponíveis.

Aplicando o conceito de conectividade em tempo real ao rastreamento

veicular, surge a ideia de um sistema de aquisição de imagens internas do veículo
juntamente com sua localização, coletando o maior número de informações do que
está acontecendo naquele momento, com transparência, e integrado a ferramentas
web de fácil acesso a qualquer dispositivo das novas gerações.
 14

3. ESTUDO DA ARTE

3.1. Mercado de rastreadores veiculares

Em estudo realizado no ano de 2013 (IDC,2013) pela renomada empresa

de consultoria e inteligência de mercado IDC Brasil, é apontado crescimento
considerável no mercado de rastreamento veicular e gestão de frotas brasileiras,
movimentando cerca de R$1,5 bilhões de reais em 2012 e atingindo a marca de 1,94
milhões de dispositivos instalados na frota nacional. O estudo destaca que 39% das
empresas de transporte e logística contratam soluções de rastreamento e pretendem
aumentar o investimento neste serviço, pois segundo Samuel Carvalho, consultor da
IDC Brasil, “Os principais motivos para contratação são o crescente número de
roubos de carga e de veículos, o controle sobre as horas trabalhadas pelo motorista,
a redução de custos e a busca por mais eficiência no controle de rotas” (IDC,2013).

A aprovação da lei 417/2012 do Conselho Nacional de Transito

(CONTRAN) que regula a jornada de trabalho de motoristas tornou ainda mais
essencial o uso de rastreadores para o cumprimento da lei. A IDC Brasil projetou um
crescimento de 14% nas vendas entre os anos de 2013 e 2017 com incremento de
11,6% ao ano nas receitas, sendo que os setores que mais tendem a consumir este
tipo de tecnologia são o de varejo e seguradoras, sendo que 65% dos dispositivos
são instalados em veículos leves (IDC,2013).

Segundo pesquisa publicada no anuário 2014-2015 do fórum de

segurança pública (SÃO PAULO,2015) “[...] o índice de furto e roubo de veículos no
estado de São Paulo é um dos mais elevados do Brasil”. A Tabela 2-1 apresenta
dados de roubos e furtos de veículos na cidade de São Paulo nos anos de 2013,
2014 e 2015, podendo-se observar que o índice de roubo ou furto de veículos
ultrapassa 10% de todos os casos registrados pela polícia.
 15

Tabela 2-1 - Índice de roubos e furtos de veículos na cidade de São Paulo

Fonte: Secretaria de Segurança Pública do Estado de São Paulo.

Devido ao crescimento dos índices de criminalidade, o rastreador veicular

vem se popularizando, segundo Silva, em matéria publicada no blog
rastreadores.org, especializado em rastreamento veicular,

“[...] diante da crescente demanda de garantir a segurança da sua

propriedade, o rastreador se mostra como uma opção muito confiável não
apenas para reaver o carro, mas também para manter o controle de onde
está o veículo, em casos de furtos e roubos.”. (SILVA,2015)

Entre diversas vantagens de optar pela instalação de um rastreador, Silva

cita o barateamento da apólice de seguro e o alto índice de sucesso em reaver a
propriedade roubada ou furtada, devido ao constante monitoramento pela
tecnologia. Em análise do mercado de rastreadores veiculares Silva lista as
principais marcas disponíveis no mercado brasileiro, sendo elas SASCAR,
CARSYSTEM, ITURAN, ONIXSAT e TRACKER. Todas estas empresas operam de
maneira similar, possuindo rastreamento via rádio, satélite e GSM/GPRS, porém
diferem nos serviços prestados. Os principais serviços oferecidos são seguros
veicular, central de apoio em caso de roubo e gerenciamento logístico de frota.
Todos estes serviços dependem da utilização de um rastreador agregando valor ao
produto instalado. Todavia, as inovações apresentadas pelas empresas líderes de
mercado focam no serviço, e não no hardware do rastreador.

Sendo assim, existe espaço neste mercado para inovações no hardware,

com inclusão de novos dispositivos, que por sua vez trarão novas possibilidades de
serviços, em um mercado em expansão.
 16

3.2. Tecnologia GPS

Originalmente desenvolvido pelo exército americano como um sistema de

navegação e inteligência militar (ESTADOS UNIDOS,2015), em 1985 foi lançado o
primeiro satélite Vanguard dando início ao sistema Navigation Satellite with Timing
and Ranging (Navstar). Em 1967 foi liberado para utilização civil o sistema Navy
Navigation Satellite System (NNSS) ao qual foi denominado Transit, porém somente
em 1973 o Departamento de Defesa Americano iniciou o desenvolvimento de um
sistema capaz de oferecer posicionamento instantâneo, velocidade e horário em
qualquer região da superfície terrestre, este sistema ficaria conhecido como Global
Positioning System (GPS).

O GPS iniciou sua operação em 1991 e continua sendo desenvolvido pelo

Departamento de Defesa Americano, podendo ser utilizado em condições
meteorológicas adversas satisfazendo a necessidade das forças militares.
Atualmente o sistema possui 27 satélites, sendo 24 em operação e três para
contingência, mantidos com energia solar, distribuídos em seis orbitas distintas ao
redor do planeta a uma distância de 19,3 mil quilômetros e dispostos de modo que
em qualquer local do planeta seja possível a visualização de ao menos quatro
satélites.

Figura 2-1 - Rede de satélites GPS

Fonte: Estados Unidos. Forças Aéreas, Segmento Espacial

 17

Os sinais dos satélites são formados por uma portadora em Rádio

Frequência (RF) que carrega códigos binários de informação de controle e dados de
navegação (MONICO,2000). Estes satélites possuem frequências definidas para
diversos tipos de comunicação, sendo:

- Comunicação com usuários. Link de transmissão:

a) Link 1 (L1)

Portadora: 1575,42 MHz

Nível de Sinal: -163dBm à -160dBm

Modulação: Em fase.

b) Link 2 (L2)

Portadora: 227,60 MHz

Nível de Sinal: -166dBm

Modulação: Em fase.

- Comunicação com estação de controle.

Link de transmissão: Banda: 2227,50 MHz

Link de recepção: Banda: 1783,74 MHz

Cada mensagem transmitida pelos satélites contém informações

chamadas de “System Data”, que são codificadas e transmitidas em sua parte
binária. Estas mensagens de controle possuem as seguintes informações:

- Parâmetros para correção do relógio do satélite.

- Dados funcionais de toda constelação de satélites.

- Dados para correção do efeito de refração ionosférica

 18

- Códigos de identificação

a) Código P (“Precision”): uso militar e transmitido nas bandas L1 e L2.

b) Código C/A (“Coarse/Acquisition”): uso civil, transmitido somente na

banda L1 e sujeito a degradações naturais ou não.

Tanto o código P quanto o código C/A são do tipo Pseudo Random Noise
(PRN) e permitem que a mensagem de posição transmitida pelo satélite seja
acrescida de ruído, deteriorando a precisão da determinação do posicionamento,
porém garantindo uma precisão da ordem de 10 a 20 metros. O departamento de
defesa americano, por motivos de segurança utiliza técnicas de degradação dos
sinais, limitando a precisão do sistema disponível ao uso civil. As principais técnicas
são a de Selective Disponibility (AS) e Anti-Spoofing (A-S), ambas geram ruídos não
gaussianos que impedem a localização exata do receptor (MONICO,2000).
 19

3.3. Captura digital de imagem

Nas últimas décadas, a grande maioria das inovações tecnológicas em

produtos eletrônicos surgiram da conversão de informações analógicas em
informações digitais, alterando principalmente como interagimos com informações
visuais e sonoras (WILSON et al.,2009). Dificilmente encontra-se câmeras
fotográficas que utilizam filme, reprodutores de fitas K-7 ou vídeo cassetes para
venda em lojas, todas estas tecnologias foram quase que totalmente substituídas
pela digitalização da informação.

A aquisição digital de imagens já faz parte do cotidiano, estando

presentes em webcams, scanners, câmeras fotográficas digitais, celulares e
sistemas de segurança. Todos estes modos de obter a imagem de forma digital
utilizam o mesmo fundamento, a transformação de informação luminosa em
informação digital (bits) com a utilização de sensores de imagem.

Essencialmente uma imagem digital é uma longa sequência de zeros e

uns que representam os pontos, pixels, que compõem a imagem. Um sensor de
imagem digital utiliza uma estrutura de lentes para focalizar a luz e criar uma
imagem, porém esta luz incide sobre a matriz do sensor que pode ser do tipo
Charge Coupled Device (CCD) ou Complementary Metal Oxide Semiconductor
(CMOS) (Figura 2-2). Estes sensores convertem a intensidade de luz recebida em
sua matriz em um determinado número de elétrons, quanto maior a intensidade da
luz mais elétrons são gerados, estes elétrons então são convertidos em valores
numéricos por um conversor analógico para digital, conversor A/D, e este valor é
processado por circuitos eletrônicos dentro do dispositivo. (AXIS, 2015)

Figura 2-2 - Sensor de imagem CCD (esquerda) e CMOS (direta)

Fonte: Axis Communication – Camera Elements

 20

Os sensores de imagem registram a quantidade de luz de claro ao

escuro, sem informação de cores, para obter-se a informação de cor, um filtro é
utilizado na frente da matriz do sensor permitindo medir a intensidade da luz que não
foi absorvida por determinada cor do filtro, definindo a intensidade de determinada
cor do filtro para cada pixel. As cores vermelho, verde e azul (do inglês red, green e
blue respectivamente) são cores primárias para luz, que combinadas de diferentes
maneiras são capazes de produzir a maior parte das cores visíveis ao olho humano
e por este motivo os dois métodos mais comuns de filtro de cor são o Red, Green,
Blue (RGB) e o Cyan, Magenta, Yellow, Green (CMYG). (KIMMEL, 1999)

O filtro RGB mais comum é a matriz de Bayer (Figura 2-3), que alterna
linhas de vermelho e verde com linhas de verde e azul. Tendo em vista que o olho
humano é mais sensível a cor verde do que ao vermelho e o azul (KIMMEL,1999), a
matriz possui duas vezes mais filtros da cor verde, ou seja, na matriz de Bayer para
cada conjunto de 2x2 pixels, duas diagonais opostas possuem filtros verdes, e as
outras duas possuem filtros vermelho e azul, sendo assim o olho humano pode
detectar mais detalhes do que se as três cores possuíssem a mesma distribuição no
filtro.

Figura 2-3 - Matriz de Bayer e atuação de filtro

Fonte: CambridgeinColor.com

A cor original da imagem é reconstruída em um processo chamado Bayer

Demosaicing. Este processo preenche as cores entre os pixels por interpolação,
utilizando predições de padrões e cálculos matemáticos para estimar as cores entre
os pixels. Esta aproximação não é tão fiel quanto a captura de imagem analógica,
entretanto por seu modo de operação, a matriz de Bayer obtém resultados
extremamente satisfatórios na estimativa de cores (KIMMEL,1999).
 21

3.4. Transmissão de dados por rede de telefonia

celular

Os Serviços Móveis Celulares (SMC) iniciaram suas operações na

década de 80 visando atender a necessidade de comunicação pessoal, sendo que
sua primeira geração foi totalmente baseada em comunicação analógica, onde os
telefones móveis eram simples transmissores e receptores de rádio com um
identificador associado (número do telefone), sendo um sistema limitado que não
suportou a crescente demanda de usuários (TATEOKI,2007).

As limitações do sistema analógico tornaram necessário o

desenvolvimento de novas tecnologias de comunicação e assim a segunda geração
de sistemas celulares surgiu, permitindo uma comunicação mais segura e terminais
telefônicos compactos e de baixo consumo, esta geração ficou conhecida como
telefonia digital. (SVERZUT,2007)

Inicialmente as aplicações da segunda geração envolviam apenas sinais

de voz, mas já prevendo a transmissão e recepção de dados, utilizando uma
alocação fixa de canal de voz, o que depois de alguns anos tornou o sistema
inadequado para aplicações em comunicação de dados de trafego por demanda,
como a internet. Visando atender a demanda por trafego de dados, a terceira
geração de telefonia móvel começou a ser desenvolvida, porém o mercado
necessitava de soluções a curto prazo e, sendo assim, uma família intermediaria que
ficou conhecida como geração 2.5 foi criada, agregando à comunicação móvel de
dados aos tradicionais serviços de voz.

Com o crescimento da utilização de dados pela rede celular, o aspecto de

segurança passou a ser um ponto importante tanto para transmissão de dados de
grandes empresas ou da privacidade de comunicações pessoais, o que novamente
fez com que as redes de telefonia celular se adaptassem. Tendo como base uma
tecnologia digital de transmissão por comutação de pacotes, aceitando serviços
clássicos de telefonia e comunicações de dados, tornando-se mais eficiente do que
os sistemas de segunda geração, permitindo vários usuários e serviços utilizarem
simultaneamente os canais disponibilizados. Este sistema ficou conhecido como
 22

Global System for Mobile (GSM) sendo baseado em tecnologia Time Division
Multiple Access (TDMA) onde cada usuário possui uma parcela de tempo para envio
de informações.

Com a popularização do uso da internet e de outros serviços de dados,

em meados de 1990 foi previsto que as redes GSM não seriam capazes de
comportar a grande quantidade de dados nos diferentes estágios do sistema, e para
garantir os serviços futuros o European Telecommunications Standards Institute
(ETSI) publica o modo de operação do General Packet Radio Service (GPRS). As
redes GPRS foram desenvolvidas baseadas em transmissão por comutação de
pacotes utilizando de modo mais eficiente a fonte de rádio para trafego por rajadas,
que é uma característica dos serviços de dados até os dias atuais. (SVERZUT,2007)

Segundo o ETSI na documentação padrão sobre GPRS, em tradução

livre, “[...] a rede GPRS pode ser considerada como um aditivo a rede GSM [...]”
(ETSI, 1999), acrescentando tráfego de dados orientado a pacotes, mediante leves
modificações de arquitetura, permitindo o envio e recebimento de dados de forma
simples por qualquer aparelho que utilize a tecnologia. Para que operadoras utilizem
os serviços GSM e os serviços de dados do GPRS a partir de uma única base, os
dois sistemas compartilham várias características como banda de frequência,
estrutura de frame e técnica de modulação, porém a cobrança pelo uso do GPRS é
realizada pela quantidade de dados transmitidos enquanto o GSM é realizado por
tempo de conexão.

Para conectar-se à rede de dados, quando um terminal GPRS é ligado a

uma rede GSM, é reconhecido como um terminal de voz e a partir deste instante é
estabelecido um enlace lógico, sendo atribuído um endereço Internet Protocol (IP),
normalmente dinâmico, e estabelecida a conexão com a operadora de telefonia
celular ou fornecedor de serviço. Uma vez ativa a interface GPRS-Internet, o
dispositivo fica em modo de espera para o envio e recebimento de dados. A
transmissão de dados em uma rede GPRS a partir do usuário é realizada na forma
de protocolos em camadas, denominada “Plano de Transmissão” pelas
especificações do GPRS que padronizam a transmissão para permitir serviços de
dados IP. (SVERZUT,2007)
 23

Atualmente novas tecnologias de transmissão de voz e dados foram

desenvolvidas e no Brasil está disponível a cobertura da terceira geração 3G e do
Long-Term Evolution (LTE) que pode ser considerada como o final da terceira
geração e início da quarta. O GSM/GPRS ainda é muito utilizado principalmente em
áreas mais afastadas dos grandes polos urbanos, sendo totalmente suportado pelas
operadoras conforme apresentado na Tabela 2-2 - Cobertura da Tecnologia 3G

Tabela 2-2 - Cobertura da Tecnologia 3G

Região Municípios % Municípios População % População

SP 643 99,70% 44.389.172 100,00%
RJ/ES 170 100,00% 20.479.935 100,00%
MG 715 83,80% 19.946.300 95,60%
PR/SC 597 85,70% 17.311.371 96,20%
RS 414 83,80% 10.980.088 97,80%
Centro Oeste 368 54,10% 17.216.267 88,20%
Norte 309 68,10% 17.562.557 86,40%
BA/SE 380 77,20% 16.166.671 92,70%
Nordeste 657 60,60% 28.562.047 88,70%
Total 4.253 76,40% 192.614.408 94,20%

* Dados coletados a partir dos sites das operadoras em set/2015

Fonte: Teleco.com

4. PROJETO

Este projeto descreve o desenvolvimento de um protótipo de rastreador

veicular de baixo custo, utilizando a plataforma de desenvolvimento Arduino e a
tecnologia GPS, agregando a inovação de aquisição de imagens do interior do
veículo. As informações geradas pelo rastreador serão enviadas pela rede de dados
de telefonia celular e disponibilizadas em um servidor online, para que assim seja
possível conhecer a rota e a real situação no interior do veículo.

Para execução do projeto foi desenvolvido um sistema, que integra a

plataforma de desenvolvimento Arduino, módulo de captura de imagem, módulo de
armazenamento, módulo e antena GPS, e módulo e antena GSM/GPRS. Os
módulos se comunicam por meio de conexões seriais, utilizando o Arduino como
centralizador. A Figura 3-1 apresenta a visão modular do projeto, destacando cada
modulo que foi desenvolvido.
 24

Figura 3-1 - Visão modular do projeto

Fonte: Israel Zanata Escorizza

 25

4.1. Componentes

4.1.1. Arduino UNO

O Arduino Uno (Figura 3-2) é uma plataforma de desenvolvimento e

programação de microcontroladores baseados no ATmega328, seus projetos são
publicados sob a licença Creative Commons, o que permite aos usuários
desenvolverem suas próprias versões da placa estendendo ou melhorando suas
funcionalidades. (CREATIVE COMMONS, 2015)

O microcontrolador ATmega328 possui 32KB de memória Flash (0,5Kb

são utilizados pelo bootloader), 2KB de SRAM e 1KB para EEPROM. Para
comunicação disponibiliza 14 portas digitais configuráveis, dos quais seis podem ser
utilizadas como saídas com modulação de largura de pulso, do inglês Pulse Width
Modulation (PWM), para controle de motores. Em sua estrutura ainda existem seis
portas analógicos configuráveis, um cristal oscilador de 16MHz para gerar pulso de
referência (clock), Light Emitting Diode (LED) integrado a placa de desenvolvimento,
conexão USB para comunicação com o computador e entrada para fonte com
regulador de tensão para 5v e 3.3v nas portas de saída (ARDUINO,2015).

Figura 3-2 - Arduino UNO

Fonte: Arduino.cc
 26

A plataforma de desenvolvimento Arduino simplifica o processo de

programação de microcontroladores inserindo uma camada amigável ao
desenvolvedor, abstraindo grande parte da complexidade para os iniciantes, porém,
ainda é suficientemente flexível para usuários avançados.

Algumas portas possuem funções pré-estabelecidas, que devem ser

observadas durante o desenvolvimento, porém, as portas de comunicação não são
exclusivamente para estes usos, podendo ser configuradas como o desenvolvedor
desejar. A Tabela 3-1 apresenta as portas e sua função pré-estabelecida.

Tabela 3-1 - Portas de comunicação Arduino UNO

Fonte: Arduino.cc
 27

4.1.2. Módulo de aquisição de imagem

Para o módulo de aquisição de imagem foi escolhido para o

desenvolvimento do protótipo o módulo PTC06 V1.0 (Figura 3-3) que integra as
funcionalidades de aquisição de imagem e comunicação serial com o Arduino,
diminuindo a quantidade de portas envolvidas no desenvolvimento. Dispositivos de
captura de imagem normalmente utilizam de oito a dez portas, sendo que o módulo
escolhido utiliza somente duas portas de lógica transistor-transistor (TTL), uma Tx e
uma Rx, para comunicação serial e as portas 3.3v e terra (GND) para alimentação.

Este pequeno módulo possui as mesmas funcionalidades de outros

módulos de aquisição de imagem, porém mais compacto, sendo desenvolvido para
uso em sistemas de segurança. Utiliza um processador digital de sinal (DSP) modelo
VC0706 capaz de gerar saída de vídeo em cores no padrão National Television
System Committee (NTSC), capturar imagens estáticas deste vídeo (fotografia) e
transmitir esta imagem utilizando comunicação serial. As imagens são capturadas e
compactadas no formato Joint Photographic Experts Group (JPEG), podendo ser
configuradas para as resoluções 640x480, 320x240 ou 160x120 pixels.
(ADAFRUIT,2015)

O módulo possui funcionalidades como balanço automático de branco,

ajuste automático de brilho, ajuste automático de contraste e detector de movimento
realizado por comparação de quadros, sendo capaz de identificar a mudança de
posição comparando o quadro capturado atual e o capturado anteriormente.

Figura 3-3 - Módulo PTC06 V1.0

Fonte: Adafruit.com
 28

4.1.3. Módulo de armazenamento

A maioria dos microcontroladores possuem armazenamento

extremamente limitado, e devido a este aspecto é necessário a utilização de um
módulo de armazenamento de arquivos temporários para que as imagens obtidas
pelo módulo de aquisição de imagem sejam armazenadas durante o processamento
dos outros módulos. Para esta função, foi escolhido o módulo WaveShare (Figura 3-
4), que adapta um cartão micro SD para armazenamento.

Existem dois modos de comunicação com cartões SD, utilizando SPI ou

Secure Digital Input Output (SDIO). O modo SDIO é um método de comunicação
mais rápido, porém muito mais complexo e possui desenvolvimento proprietário,
sendo necessária aquisição de documentos de especificações e por este motivo, é
pouco utilizado fora da indústria. (SDCARD, 2013).

Todo cartão SD também possui um modo de comunicação SPI de baixa

velocidade, que é facilmente integrada a qualquer microcontrolador, sendo
necessárias somente quatro portas de comunicação sendo elas D0 (MISO), D1
(MOSI), Clock (SCLK) e habilitador (CS), além de duas portas de alimentação 3.3v e
terra (GND). Cartões SD utilizam armazenamento puro sendo somente setores em
uma memória flash, não existindo estrutura de armazenamento, podendo armazenar
qualquer tipo de sistema de arquivo (SDCARD, 2013). O sistema de arquivo mais
comum em aplicações que utilizam cartões SD são o FAT16 ou FAT32, a utilização
de sistema de arquivos mais complexos pode utilizar grande quantidade de memória
de microcontroladores menores, como o Arduino.

Figura 3-4 - Módulo WaveShare MicroSD

 29

Fonte: WaveShare.com

4.1.4. Módulo GPS e Módulo GSM/GPRS

Para os módulos de GPS e GSM/GPRS foi escolhido o SIM908 da

SimCom (Figura 3-5), pois agrega funcionalidades de comunicação de dados pela
rede pública de telefonia celular e aquisição de dados de posicionamento global em
um único microchip. De acordo com o datasheet do fabricante, este dispositivo opera
nas frequências 850, 900, 1800 e 1900 MHz, possuindo uma taxa de transferência
máxima de 85.6 kbps para download e 42,8 kbps para upload com suporte ao
protocolo TCP/IP e broadcast. Ainda de acordo com o datasheet, o dispositivo
necessita de uma fonte de alimentação de 3,2V à 4,8V com um consumo de
corrente variável de 651 µA quando em modo de economia de energia à 320 mA
quando em comunicação de dados GPRS. (SIMCOM,2013)

Figura 3-5 - Módulo SIM908

Fonte: SimCom.com

Para o desenvolvimento do protótipo, devido à dificuldade de produção de

uma placa equivalente em pequena escala, foi escolhido o shield da DFRobots
SIM908 (Figura 3-6), por atender as necessidades do projeto e possuir ótimo custo x
benefício em relação a aquisição do Módulo SIM908 separadamente e produção de
placa específica para o projeto.
 30

O Shield é composto pelo microchip SIM908, conexões reutilizáveis para

as principais portas do Arduino, conectores do tipo P2 de áudio e microfone,
conector para cartão SIM, antena para conexão GSM e antena GPS.

A comunicação com os módulos GSM e GPS, utilizados no projeto, é

realizada pelas portas de comunicação serial padrão do Arduino, por onde é feita a
configuração do módulo utilizando um conjunto de comandos AT. Outras cinco
conexões são necessárias para utilização do shield, habilitador de GPS, habilitador
de GSM e habilitador do Shield, que operam com sinal de tensão baixo, e portas de
alimentação 5v e GND.

Figura 3-6 - Shield DFRobots Sim908

Fonte: DFRobots.com
 31

4.2. Protótipo – Hardware

4.2.1. Módulo GPS e Módulo GSM/GPRS

A comunicação entre o Arduino e o módulo (Figura 3-7) é realizada

utilizando as portas 1 (TX) e 2 (RX). As funções do shield são habilitadas com envio
de sinal baixo (LOW) nas portas 3 (GSM), 4 (GPS), e 5 (ENABLER), sendo que as
funções GSM e GPS são concorrentes e somente uma deve estar habilitada por vez.

Figura 3-7 - Arduino UNO com Shield DFRobots SIM908 acoplado

Fonte: Israel Zanata Escorizza

 32

4.2.2. Módulo GPS e Módulo GSM/GPRS

Para aquisição e armazenamento da imagem, foi projetado um shield que

integra os módulos de armazenamento e de aquisição de imagem.

Inicialmente, foi testado em protoboard (Figura 3-8) o funcionamento dos

módulos, e verificadas quais portas seriam utilizadas. Foram definidas as portas 6
(TX) e 7 (RX) para comunicação serial com o módulo de aquisição de imagem, as
portas 7 (ENABLER), 11 (MOSI) ,12 (MISO) e 13 (CLOCK) para comunicação com o
módulo de armazenamento utilizando SPI. Foram utilizados ainda as portas de 3.3V
e GND do Arduino.

Figura 3-8 - Protoboard dos módulos de aquisição de imagem e armazenamento

Fonte: Israel Zanata Escorizza

 33

Após verificação que o sistema estava funcional, foi montado um shield

protótipo (Figura 3-9) para integração no sistema (Figura 3-10).

Figura 3-9 - ProtoShield com os módulos de armazenamento e aquisição de imagem

Fonte: Israel Zanata Escorizza

Figura 3-10 - ProtoShield instalado junto ao Arduino UNO e Shield DFRobots SIM908

Fonte: Israel Zanata Escorizza

34
 35

4.3. Protótipo – Software

4.3.1. Modelo de operação

A programação do Arduino para utilização dos módulos foi realizada em

linguagem C, seguindo os princípios da arquitetura orientada a serviços (SOA), ou
seja, cada módulo é tratado como um serviço, sendo responsável e capaz de
realizar sua função sem depender dos outros. Este processo faz com que um grande
problema seja dividido em partes menores, de resolução menos complexa, e a
somatória das resoluções menores resolve o problema maior (ERL,2005).

É possível identificar diversos sub processos na estrutura principal que o

projeto se propõe a realizar, sendo os principais: a configuração do hardware na
inicialização do dispositivo, aquisição de posicionamento GPS, aquisição da
imagem, armazenamento temporário e o envio das informações pela rede de dados
a um servidor.

Seguindo o escopo de que cada sub processo atuará gerenciando as

informações de um módulo do hardware, foram desenvolvidas rotinas específicas
para cada sub processo. O sub processo de configuração do hardware será
executado na inicialização do dispositivo, na rotina padrão setup do Arduino, e os
demais serão executados sequencialmente, na rotina de repetições loop do Arduino,
onde será realizada a requisição das informações possibilitando que ao final de cada
iteração o processo completo tenha sido executado de forma satisfatória.

O Apêndice A – Fluxo de execução do sistema, demonstra o fluxograma

de execução em uma visão detalhada do processo.

O Apêndice B – Codificação, apresenta a codificação realizada para o

desenvolvimento do sistema.
 36

4.3.2. Configuração de hardware

Para que o sistema esteja preparado para receber as requisições de

informação da rotina de gerenciamento, foram utilizadas bibliotecas padrão do
Ambiente de Desenvolvimento Integrado (IDE) do Arduino SPI.h, SD.h e SoftSerial.h
(ARDUINO,2015) e a biblioteca customizada Adafruit_VC0706.h (ADAFRUIT,2015)
para controle da câmera serial.

Visando o menor consumo de memória da plataforma e o princípio do

SOA que cada serviço deve ser capaz de executar sua função independentemente,
foi definido que variáveis globais deveriam ser utilizadas somente quando sua
existência fosse realmente benéfica à performance do sistema, o que fez com que
somente quatro variáveis globais fossem utilizadas, contendo o nome do arquivo
físico no cartão SD, o horário no padrão Tempo Universal Coordenado (UTC), a
latitude e a longitude, informações estas que são obtidas na etapa inicial do ciclo de
processamento, persistindo até a finalização do ciclo de monitoramento.

Para a configuração do hardware foi desenvolvida a rotina IniShield

responsável por preparar todas as configurações necessárias de modo que as
chamadas a cada módulo sejam executadas de forma correta, definindo as portas
de comunicação serial entre os módulos e configurando os parâmetros de acesso à
rede GSM/GPRS, protocolo File Transfer Protocol (FTP) e HyperText Markup
Language (HTML) com a utilização de comandos AT.

Todos estes parâmetros são configuráveis e o sistema deve aceitar que o

usuário configure seus próprios parâmetros de conexão, mantendo assim a
interoperabilidade entre os diversos serviços de conexão, no caso do GSM/GPRS e
das aplicações que podem ser desenvolvidas, para o FTP. Estas informações são
disponibilizadas em um arquivo de configuração, setup.inf, acessível ao usuário no
cartão SD, que são lidas pela rotina genérica ReadSetup e utilizadas na
configuração do sistema.

A Figura 3-11 e a Figura 3-12 mostram o arquivo de configuração e o

trecho de código contendo a função IniShield realizando a configuração do GPRS. A
função completa pode ser visualizada no Apêndice B – Codificação.
 37

Figura 3-11 - Arquivo Setup.inf

Fonte: Israel Zanata Escorizza

 38

Figura 3-12 – Trecho da rotina IniShield

Fonte: Israel Zanata Escorizza

 39

4.3.3. Aquisição de localização GPS

Seguindo o modelo de execução apresentado no Apêndice A – Fluxo de

execução do sistema, a primeira rotina a ser executada após a inicialização do
dispositivo é a de aquisição de localização GPS. A rotina GetGPSInfo organiza e
executa as chamadas necessárias as sub-rotinas para obter a localização.

A primeira etapa da rotina desenvolvida foi a leitura dos dados de

localização do receptor GPS presente no shield DFRobots, e para isto envia o
comando AT AT+CGPSINF=2, onde o parâmetro deste comando informa ao
receptor o formato de dados a ser utilizado na resposta, neste projeto optou-se pela
utilização do padrão National Marine Eletronics Association (NMEA) – Global
Positioning System Fixed Data (GPGGA), pois retorna os dados formatados de
modo simples, sendo possível gerar as informações necessárias ao projeto.
(SIMCOM,2013).

A Tabela 3-2 apresenta os dados retornados pelo protocolo.

Tabela 3-2 - Global Positioning System Fixed Data

Fonte: SIMCOM, SIM908 AT Command Manual V1.01 (Tradução livre).

 40

Cabe citar que os exemplos de código fornecidos pelo fabricante

DFRobots para aquisição de posicionamento disponibilizados em sua página de
consulta, realizam uma aquisição para cada parte de dados que compõe o protocolo,
o que torna o processo lento e inidôneo, pois nada garante que o posicionamento
não se altere entre as medições.

Para garantir a consistência das informações, a rotina desenvolvida

realiza uma única aquisição comparando a cadeia de caracteres que chegam pela
comunicação serial com o conjunto '$','G','P','G','G','A' e, quando identifica estes 6
caracteres em sequência garante que os próximos caracteres compõem as
informações necessárias, sendo armazenados em uma variável que será utilizada
durante todo processo, melhorando a performance e garantindo que todos os dados
de localização sejam provenientes de uma mesma amostragem.

Os dados obtidos com a leitura do receptor necessitam ser formatados

para valores numéricos para que seja possível trabalhar-se os dados no sistema, e
para isto foram desenvolvidas as funções auxiliares ConvDouble, que converte o
texto recebido em número com “n” casas decimais solicitadas.

Após os testes realizados com as rotinas desenvolvidas, ficou claro que

as informações obtidas não condiziam com a realidade, sendo necessário ajustes de
calibragem tanto para o horário UTC quanto para o posicionamento recebido. Para o
ajuste do horário UTC, foi definida uma variável no arquivo de configuração
contendo o ajuste de fuso horário em relação ao meridiano de Greenwich (-3 horas)
que é somada ao valor recebido.

As calibragens de latitude e longitude foram realizadas por amostragem,

recebendo posicionamento em quatro locais distintos e comparando com o
posicionamento conhecido obtido com a utilização da ferramenta gratuita google
maps (GOOGLE,2015). Foi gerado uma média de 30 medições de cada local, em
um total de 120 medições, gerando o valor que foi inserido no arquivo de
configurações somado ao valor recebido pelo receptor. Nos testes subsequentes, o
posicionamento mostrou-se com bom nível de precisão.
 41

4.3.4. Aquisição de imagem e armazenamento de arquivos

Ao termino da aquisição da localização GPS, o sistema deve realizar a

captura da imagem, nesta etapa, foi desenvolvida a rotina GetImagem, que realiza a
conexão com o modulo de câmera utilizando a porta serial virtual, define o nome do
arquivo, o tamanho da resolução da imagem e a aquisição propriamente dita da
imagem digital. A definição do nome do arquivo é realizada verificando no cartão SD
se já existe algum arquivo com o mesmo nome do presente na variável global
cCamFile, caso exista, é incrementado o número identificador no nome, até que não
exista um arquivo com o nome.

Para definição do tamanho, obtenção da imagem e armazenamento da

imagem são utilizados os métodos do objeto setImageSize, takePicture frameLength
e readPicture, disponibilizados pela biblioteca customizada da câmera. (ADAFRUIT,
2015)

A resposta do hardware da câmera a solicitação de captura da imagem é

uma sequência de bytes que é lida da porta de comunicação serial e armazenada
diretamente no cartão de memória. Devido à grande quantidade de informação,
definiu-se que seriam lidos somente 64 bytes por iteração até que não existam mais
bytes a serem lidos da porta de comunicação serial.

A Figura 3-13 mostra o código com a descrição de cada etapa da função

e os comandos utilizados na execução.
 42

Figura 3-13 - Rotina GetImagem

Fonte: Israel Zanata Escorizza

 43

4.3.5. Envio de informações por GSM/GPRS e FTP

De posse da localização GPS, e do arquivo de imagem, o sistema deve

enviar estas informações à algum servidor e para isto, foi desenvolvida a rotina
SendGPRS. A rotina acessa as variáveis de configuração do arquivo setup.inf e
obtém o servidor e o id, montando dinamicamente o comando AT que será enviado
ao shield DFRobots Sim908 contendo a Uniform Resource Locator (URL) de destino
que executará uma rotina Hypertext Preprocessor (PHP) onde os parâmetros serão
informados na URL e recebidos por método GET do PHP (W3SCHOOLS,2015).

Não é possível o envido de arquivos de imagem por URL, portanto, foi

escolhido a utilização do FTP e desenvolvida a rotina SendFTP. Esta rotina assim
como a SendGPRS monta dinamicamente o comando AT que será enviado ao
shield DFRobots Sim908 para o estabelecimento da conexão com o servidor FTP.
Assim como a leitura da imagem obtida pela câmera, o envio foi dividido em partes
menores de 100 caracteres por iteração visando não gerar grande carga de dados.

A Figura 3-14 e Figura 3-15 mostram os trechos do código contendo as

rotinas SendGRPS e SendFTP respectivamente.

Figura 3-14 - Rotina SendGPRS

 44

Figura 3-15 – Rotina SendFTP

Fonte: Israel Zanata Escorizza

 45

4.4. Servidor

O desenvolvimento do projeto envolve o envio a um servidor, portanto foi

utilizado o hostinger (http://www.hostinger.com.br/), uma empresa de hospedagem
de sites que disponibiliza gratuitamente um servidor de banco de dados e diversas
funcionalidades, como servidor PHP e FTP, que são utilizados neste projeto.

Foi criado o domínio gratuito gpsimage.hol.es onde será hospedada toda

parte web do projeto.

4.4.1. Banco de Dados

Para o armazenamento das informações enviadas pelo protótipo, foi

desenvolvido um banco de dados padrão MySQL, contendo as informações básicas
recebidas pelo PHP. O banco armazena as informações de ID, Hora UTC, Latitude,
Longitude e Nome do arquivo de imagem. A tabela ainda conta com um registro
interno de data e hora no qual o registro foi incluso, sendo a chave primária
composta da tabela o registro de inclusão e o ID informado. Toda manipulação dos
dados é realizada pelo PHP, garantindo a integridade da base de dados.

Para criação da tabela no bando de dados MySQL foi utilizado a

codificação apresentada na Figura 3-16.

Figura 3-16 - Criação da tabela tb_gpsinfo

Fonte: Israel Zanata Escorizza

 46

4.4.2. Armazenamento de dados

Ao ser enviado o comando AT para o shield DFRobots Sim908 pela

função SendGPRS, é enviada para a URL montada pela função uma requisição
PHP, que deve ser tratada para que os dados informados sejam corretamente
armazenados. Para isto, foi desenvolvido no servidor a rotina data.php que conecta
ao bando de dados e realiza a inclusão das informações recebidas na URL. A rotina
é apresentada na Figura 3-17 .

Figura 3-17 - Rotina data.php

Fonte: Israel Zanata Escorizza

4.4.3. Exposição de dados

Para que seja possível a visualização dos dados coletados de modo

amigável, foi implementada no servidor uma página web que exibe a informação
armazenada ao usuário. Esta página foi desenvolvida somente para verificação dos
dados, sendo que não houve implementação de nenhum tipo de segurança da
informação.
 47

Ao acessar a URL http://gpsimage.hol.es/ são exibidas todas as

informações contidas no banco de dados, ordenados pelo id do usuário e data de
registro da informação. Caso se deseje uma consulta especifica de um id, é possível
informar ao final da URL o id (http://gpsimage.hol.es/?id=000001) para que a o
resultado da busca seja refinado mostrando somente dados do id informado. A
codificação da página pode ser visualizada na Figura 3-18.

Figura 3-18 - Codificação pagina http://gpsimage.hol.es

Fonte: Israel Zanata Escorizza

 48

5. Resultados

A montagem do protótipo foi considerada satisfatória, sendo mantida a

ideia original do desenvolvimento de baixo custo. A integração do hardware ocorreu
conforme o planejado, sendo necessário alguns ajustes, detalhados no capitulo 3, na
montagem dos módulos. As codificações realizadas para os módulos ocorreram
seguindo os conceitos de arquitetura definidos no início do projeto, sendo que não
foram necessárias alterações de fluxo de dados. A codificação possui
aproximadamente 480 linhas de código, apresentadas no Apêndice B, e sua
compilação ocupa um total de 69% da memória interna do Arduino. Quanto a
utilização de memória dinâmica do microprocessador, o sistema utiliza
aproximadamente 74% da memória disponível, restando 602 bytes para variáveis
locais. Estes valores estão próximos ao limite de segurança de operação do Arduino
(ARDUINO,2015), que em seu ambiente de desenvolvimento informa que podem
ocorrer erros e instabilidades na operação quando é consumido acima de 75% da
memória disponível.

Os resultados apresentados a seguir foram coletados durante os dias 02

de novembro e 18 de novembro do ano de 2015 e seguirão o fluxo de execução do
sistema apresentado no Apêndice A, comentando as descobertas e alterações
realizadas para obtenção do resultado final. Para os testes, o protótipo foi instalado
em um carro (Figura 4-1) em um dos cabos de 12 volts disponíveis, diretamente na
alimentação do Arduino, sendo acionado quando o veículo era ligado, iniciando o
monitoramento.

Figura 4-1 - Instalação do protótipo

 49

Fonte: Israel Zanata Escorizza

A inicialização do protótipo e toda configuração dos parâmetros iniciais

consomem 30 segundos, sendo que um terço deste tempo é utilizado para
reinicialização do GPS em modo autônomo. Esta espera mostrou-se necessária,
pois a comunicação com o dispositivo fica interrompida durante a reinicialização, e
deve-se garantir que todas as configurações estejam corretas antes da aquisição do
posicionamento. Em exemplos encontrados no site do fabricante (DFROBOTS,2015)
as inicializações de outras modalidades menos complexas, como somente GPS ou
somente GPRS, consomem até duas vezes o tempo obtido neste projeto. Este valor
mostrou-se satisfatório e demonstrou que os exemplos que estavam sendo
utilizados poderiam ser aprimorados quanto ao desempenho.

Foi verificado o consumo de energia elétrica do protótipo, medindo-se a

corrente consumida enquanto conectado a bateria de 12 volts, obtendo um valor
máximo de 175 mA (mili ampères) durante a transmissão dos dados. Baseado
nesses valores, calcula-se o consumo médio pela formula 4.1, onde S é a potência, i
é a corrente consumida e U é a tensão da bateria.

S=i∗U [Watt ]
(4.1)

Tendo como base os valores utilizados neste projeto, onde i = 195mA e U

= 12v, calcula-se (4.2).

−3
S=175 x 10 A∗12 v =2,1W (4.2)

Para a requisição de posicionamento GPS, o dispositivo apresentou uma

excelente desempenho em ambientes abertos, como ruas e quintais, sendo possível
obter uma resposta contendo o posicionamento com a utilização de ao menos quatro
satélites em menos de um minuto, porém em testes realizados em ambientes
fechados, o dispositivo possui uma resposta que foi considerada insatisfatória, com
amostragens onde não foi possível a definição do posicionamento, isto ocorre devido
à grande quantidade de obstruções como lajes, vigas de ferro, sinais de roteadores
wireless e outros que atenuam o sinal. Este problema poderia ser solucionado com a
 50

utilização de uma antena com maior ganho no receptor. Esta solução não foi
adotada no projeto, pois para estudo de viabilidade de um rastreador com aquisição
de imagem, as respostas do módulo GPS mostraram-se satisfatórias com o veículo
em trânsito.

Durante as experimentações iniciais, foi constatado que a captura da

imagem consome até 560 bytes da memória dinâmica do microcontrolador, o que
fez necessário otimizar a utilização das variáveis em memória do sistema. Após
otimização do código, a captura da imagem apresentou problemas quanto a nitidez,
que foi corrigido com o ajuste fino mecânico da câmera. Para realizar o ajuste, era
obtida uma imagem e comparada manualmente com a anterior, até obtenção de
uma imagem com boa qualidade. Cada imagem obtida a partir deste ajuste ocupa
um espaço de aproximadamente 55 KB no armazenamento, tamanho que foi
considerado aceitável pela qualidade da imagem (Figura 4-2).

Figura 4-2 - Imagem capturada pela câmera

Fonte: Israel Zanata Escorizza

Para o armazenamento das imagens foi utilizado um cartão micro SD de 2

Gigabytes (2.097.152 KB), sendo que neste cartão são armazenados os arquivos de
configuração e log do sistema. Pode-se calcular a quantidade de arquivos de
 51

imagem versus a capacidade do cartão de memória utilizando a formula 4.3 onde A

é a quantidade de arquivos que podem ser armazenados, G é a capacidade do
cartão SD em Gigabytes e K é o tamanho médio do arquivo a ser armazenado.

1024 2∗G
A= (4-
K
3)

Tendo como base os valores utilizados neste projeto, onde G = 2 e K =

55, calcula-se (4.4).

1024 2∗2
A= =38.130[arquivos ] (4-4)
55

O envio das informações para o servidor via conexão GPRS, utilizando os

comandos AT, foi um dos grandes desafios do projeto, sendo que nos testes iniciais,
a execução ocorria de modo intermitente. Após análise dos exemplos
disponibilizados no site do fabricante do shield (DFROBOTS,2015) e documentação
(SIMCOM,2011) foi identificado uma falha no modo de conexão GPRS e após a
correção a requisição ao servidor foi executada corretamente, entretanto, a
disponibilidade do sinal da operadora escolhida para os testes (Vivo), para dados
mostrou-se inconstante em regiões mais afastadas dos centros urbanos, porém não
afetando com criticidade o sistema.

O envio da imagem para o servidor por FTP foi um dos pontos críticos do
projeto, uma vez que para realizar o carregamento da imagem por uma página
HTML seria necessário que o protótipo acessasse a página e preenche-se campos
com a localização da imagem no cartão de memória, realizando uma carga
temporária no servidor para somente após submissão do formulário HTML ser
realizado o armazenamento (W3SCHOOLS,2015). A carga temporária em uma
página web além de ser mais lento, torna o processo de desenvolvimento do
servidor muito mais complexo, e para este projeto o desenvolvimento de um servidor
de grande capacidade encontra-se fora de escopo. O FTP além de mais rápido, trata
o arquivo de imagem, disponibilizando-o diretamente no armazenamento do servidor
 52

de modo prático, onde as aplicações do prestador de serviço podem acessar e

realizar os tratamentos compreendidos fora do escopo deste projeto.

A programação do envio FTP ocorreu sem grandes anormalidades, porém

o tempo de envio gasto chega a aproximadamente 35 segundos por imagem,
tornando-se o grande gargalo do processamento, em grande parte pela escolha do
envio particionado em pequenas quantidades da imagem devido à pouca memória
disponível no microcontrolador.

Quanto ao desenvolvimento da lógica do servidor para conferência das

informações enviadas pelo protótipo, o desenvolvimento de um banco de dados
simples e programação PHP ocorreu sem dificuldades, com testes realizados
localmente realizando as chamadas por browser antes dos testes reais. Durante os
testes com o protótipo não existiram falhas quando a requisição é encaminhada
corretamente, sendo processadas corretamente, populando o banco de dados.

As Figura 4-3, Figura 4-4 e Figura 4-5 mostram, respectivamente, as

informações do log do protótipo no cartão SD, as informações inseridas no banco de
dados do servidor, e os arquivos de imagem inseridos na pasta do servidor de FTP.

Figura 4-3 - Arquivo de LOG do protótipo

Fonte: Israel Zanata Escorizza

 53

Figura 4-4 - Banco de dados contendo informações enviadas

Fonte: Israel Zanata Escorizza

Figura 4-5 - Arquivos enviados para servidor por FTP

Fonte: Israel Zanata Escorizza

Após envio dos dados e da imagem para o servidor, é possível a

visualização destas informações na página de acesso do usuário
(http://gpsimage.hol.es/) como mostrado na Figura 4-6.
 54

Figura 4-6 - Página de acesso do usuário

Fonte: Israel Zanata Escorizza

Baseando-se nos dados experimentais obtidos, pode-se prever a

utilização do plano de dados necessário para o envio das informações ao servidor
utilizando a formula 4-5, onde C é o consumo médio mensal, n é a quantidade de
amostragens em uma hora e b o tamanho em KB da amostra de imagem.

C=
31∗24∗n∗b Mb
1024 mês [ ] (4-

5)

Tomando como exemplo a configuração utilizada nos testes que realiza

amostragens a cada cinco minutos (12 amostragens por hora), para arquivos de
imagens com aproximadamente 55 KB obtemos como resultado (4-6).

C=
31∗24∗12∗55 Mb
1024 mês [ ]
= 479,53
Mb
mês [ ] (4-

6)
 55

Adicionando uma margem de segurança de 10% deste valor, obtemos o

valor total de consumo de plano de dados (4-7).

C=1,1∗ ( 31∗24∗12∗55
1024 )[ mês
Mb
]=527,48[ mês
Mb
] (4-7)

Levando em consideração os planos de dados oferecidos pela operadora

utilizada nos testes (Vivo), onde é possível adquirir na data atual um plano de dados
com 500 Mb ao mês por R$49,99 (VIVO, 2015), o consumo médio mensal foi
considerado compatível com os planos disponíveis no mercado.
 56

6. Conclusão

Tendo como base os estudos realizados sobre posicionamento global,

rastreamento veicular, captura de imagens digitais, transmissão de dados pela rede
GPRS e atuando no desenvolvimento do protótipo foi possível entender a
complexidade e a importância que cada uma destas tecnologias possui. Também se
observou o grande empenho dos engenheiros para criá-las e possibilitar seu uso
comercial.

Durante o desenvolvimento do protótipo foi possível entender as

dificuldades de um projeto de engenharia, por mais simples que se mostre no início,
cada etapa possui desafios a serem rompidos e ajustes a serem realizados, desafios
e ajustes estes que não seriam superados sem os conhecimentos adquiridos
durante o curso.

O projeto foi validado por diversos testes, descritos no capítulo de

resultados, atingindo os objetivos propostos em sua concepção inicial, sendo capaz
de executar cada uma das funções a que se propõe, alcançando o ideal de um
rastreamento veicular com aquisição de imagem e com baixo custo de operação.

Melhorias podem ser realizadas no hardware e no software do projeto.

Tendo em vista que a utilização de memória do Arduino Uno foi um fator crítico
durante o desenvolvimento, recomendasse a utilização de plataformas de
desenvolvimento com maior capacidade de memória e processamento, como o
Arduino Mega, possibilitando a implantação de novas funcionalidades e otimizando
os recursos, aperfeiçoando o projeto de modo que se torne viável comercialmente.
 57

7. Referencias

ADAFRUIT. TTL Serial Camera. Disponível em <https://learn.adafruit.com/ttl-serial-camera>. Acesso em 30 de

março de 2015.

ARDUINO. Overview. Disponível em <https://www.arduino.cc/en/Main/ArduinoBoardUno>. Acesso em 30 de

março de 2015.

AXIS COMMUNICATIONS. Camera Elements. Disponível em <http://www.axis.com/pt/pt/learning/web-

articles/technical-guide-to-network-video/image-sensors> Acesso em 15 de junho de 2015.

BRASIL (Governo). Departamento Nacional de Transito. Resolução Nº 417. Diário Oficial da União: Conselho
Nacional de Transito, Brasília, 12 de setembro de 2012. Disponível em
<http://www.denatran.gov.br/download/Resolucoes/(RESOLU%C3%87%C3%83O%20417.2012).pdf>. Acesso
em 30 de março 2015.

CREATIVE COMMONS. Licenças. Disponível em <https://br.creativecommons.org/licencas/>. Acesso em 15

julho de 2015.

ERL. Thomas. Service Oriented Architeture Concepts, Technology and Desing. 2005. Pearson Education.

ESTADOS UNIDOS (Governo). Forças Aéreas. The Global Positioning System. 03 de mar 2015. Disponível em
<http://www.gps.gov/systems/gps/>. Acesso em 08 de maio de 2015.

ETSI. ETSI TS 151 010-1 V12.5.0. França. Agosto de 2015. Disponível em

<http://www.etsi.org/deliver/etsi_ts/151000_151099/15101001/12.05.00_60/ts_15101001v120500p.pdf>.
Acesso em 10 de agosto de 2015.

GOOGLE. Google Mapas. Disponível em <maps.google.com>. Acesso em 15 de julho de 2015.

IDC BRASIL, Estudo sobre tendências veiculares no Brasil, São Paulo, 11 setembro de 2013. Disponível em
<http://br.idclatin.com/releases/>. Acesso em 28 de março 2015.

KIMMEL, R. Demosaicing: Image reconstruction from color CCD samples. IEEE transactions on image
processing, v. 8, n. 9, p. 1221, set 1999.

LAPORTA, M. Z; FOGO, M; FUZARI, D.F. Manual para elaboração de trabalhos acadêmicos. 4. ed. Santo André,
2013.
 58

MONICO, J.F.G. Posicionamento pelo NAVSTAR-GPS: Descrição, fundamentos e aplicações. 1.ed. Presidente
Prudente: UNESP, 2000.

SÃO PAULO (Estado). Secretaria de Segurança Pública do Estado de São Paulo. Dados Estatísticos do Estado de
São Paulo. São Paulo, 2015. Disponível em <http://www.ssp.sp.gov.br/novaestatistica/Pesquisa.aspx>. Acesso
em 30 de março 2015.

SD ASSOCIATION. SD Standard Overview. Disponível em

<https://www.sdcard.org/developers/overview/index.html>. Acesso em 15 de abril de 2015.

SILVA, J. E. Fabricantes de rastreadores. Rastreadores.org. 03 de mai. 2015. Disponível em

<http://www.rastreadores.org/fabricantes-de-rastreadores/>. Acesso em 21 de maio 2015.

SIMCOM. SIM908 AT Command Manual V1.01. Julho de 2011. Disponível em

<http://www.dfrobot.com/image/data/TEL0051/3.0/SIM908_AT%20Command%20Manual_V1.01.pdf>. Acesso
em 14 de maio de 2015.

SVERZUT, J. U. Redes GSM, GPRS, EDGE e UMTS: Evolução a Caminho da Terceira Geração. São Paulo: Érica,
2007.

TATEOKI, G. T. Monitoramento de Dados via Internet baseado em Telefonia Celular. 2007. 123 f. Dissertação
(mestrado) - Universidade Estadual Paulista. Faculdade de Engenharia de Ilha Solteira, 2007.

TELECO. Cobertura 3G. Disponível em <http://www.teleco.com.br/3g_cobertura.asp>. Acesso em 15 de abril

de 2015.

VIVO. Planos e pacotes. Disponível em <https://www.vivo.com.br/portalweb/appmanager/env/web?

_nfls=false&_nfpb=true&_pageLabel=P95800228171426280444407&WT.ac=portal.paravoce.movel.planosepac
otes.vivocontrolemovel.smartvivocontrole#>. Acesso em 10 de novembro de 2015.

WILSON T. V; NICE, K; GUREVICH, G. Como funcionam as câmeras digitais. 2009. Disponível em

<http://tecnologia.hsw.uol.com.br/cameras-digitais.htm>. Acesso em 15 de junho de 2015.

W3SCHOOLS. PHP Connect to MySQL. Disponível em

<http://www.w3schools.com/php/php_mysql_connect.asp>. Acesso em 25 de outubro de 2015.
 59

8. Apêndice A – Fluxo de execução do sistema

 60

9. Apêndice B – Codificação

10. Codificação Arduino

/****************************************************************************************
* Código: GPS_System.ino
* Autor.: Israel Zanata Escorizza (israel.escorizza@gmail.com)
* Data...: 22/10/2015
* Versão: 1.0
*****************************************************************************************/
//- Bibliotecas ------------------------------------------------------------------------------------------------------------------------------
#include <Adafruit_VC0706.h> //- Biblioteca para comunicação com câmera serial.
#include <SPI.h> //- Biblioteca para comunicação SPI
#include <SD.h> //- Biblioteca para a gravação/leitura de cartão SD
#include <SoftwareSerial.h> //- Biblioteca para comunicação serial virtuais

//- Variaveis Globais ---------------------------------------------------------------------------------------------------------------------

char cCamFile[9]; //- Nome do arquivo gravado no cartão SD
char cSetup[10] = "setup.inf";

double nUtcTime = 0.0; //- Hora UTC

double nLatitude = 0.0; //- Latitude
double nLongitude= 0.0; //- Longitude

//- Setup ---------------------------------------------------------------------------------------------------------------------------------

void setup() {
IniShield(); //- Inicializa Shield DFRobots
}

//- Loop ----------------------------------------------------------------------------------------------------------------------------------

void loop(){
char cCodErr[6] = "",
cLoop[5] = "";

int8_t nCont = 0;

if (!GetGPSInfo()){
sprintf(cCodErr,"GPS01");
}
else{
while (nCont <= 3 && !GetImagem()){
nCont++;
delay(5000);
}
if (nCont > 3){
sprintf(cCodErr,"CAM01");
}
else {
nCont = 1;
while (nCont <= 3 && !SendGPRS()){
nCont++; delay(5000);
}
if (nCont > 3){
sprintf(cCodErr,"GPR01");
}
}
}
 61

strcpy(cCamFile,"");
nUtcTime = 0.0;
nLatitude = 0.0;
nLongitude= 0.0;

if (strlen(cCodErr)) //- Verifica erro e define tempo de espera.

ReadFile(cSetup,"FAIL",cLoop);
else
ReadFile(cSetup,"LOOP",cLoop);

Logger("erro.inf",cCodErr); //- Atualiza LOG

delay(ConvDouble(cLoop,0) *1000); //- Espera entre iterações
};

//-- Funções Setup ------------------------------------------------------------------------------------------------------------------------

/****************************************************************************************
Função....: IniShield()
Parâmetros:
Resposta..:
*****************************************************************************************/
void IniShield (){
char cRet[20],
cSend[100];
unsigned int nTOut = 2000;

//- Definição de portas para comunicação com Shield DFRobots -----------------------------------------------------------

pinMode(3,OUTPUT); //- Controle do modo GSM
pinMode(4,OUTPUT); //- Controle do modo GPS
pinMode(5,OUTPUT); //- Controle do Shield DFRobots

Serial.begin(9600); //- Inicializa comunicação serial a 9600 kbps

SD.begin(8); //- Inicializa comunicação com SD na porta 8

digitalWrite(5,HIGH);
delay(2000);
digitalWrite(5,LOW);
delay(3000);

digitalWrite(4,HIGH); //- Desativa modo GPS

delay(500);
digitalWrite(3,LOW); //- Ativa modo GSM
delay(500);

while(Serial.available()) Serial.read();

//- Configurações GPS -------------------------------------------------------------------------------------------------------------------

SendAt("AT+CGPSPWR=1","",nTOut); //- Controle da energia do GPS (baixo consumo)
SendAt("AT+CGPSRST=1","GPS Ready",nTOut*5); //- Reinicia GPS em modo autônomo

//- Configurações GSM/GPRS -----------------------------------------------------------------------------------------------------------

while(SendAt("AT+CREG?","+CREG:",nTOut)); //- Registro na rede de telefonia publica

ReadFile(cSetup,"APN",cRet); //- Domínio de autenticação

sprintf(cSend,"AT+SAPBR=3,1,\"APN\",\"%s\"",cRet);
SendAt(cSend,"",nTOut);

ReadFile(cSetup,"PIN",cRet); //- PIN da operadora

sprintf(cSend,"AT+CPIN=\"%s\"",cRet);
SendAt(cSend,"",nTOut);
 62

ReadFile(cSetup,"USR",cRet); //- Usuário para autenticação

sprintf(cSend,"AT+SAPBR=3,1,\"USER\",\"%s\"",cRet);
SendAt(cSend,"",nTOut);

ReadFile(cSetup,"PSW",cRet); //- Senha para autenticação

sprintf(cSend,"AT+SAPBR=3,1,\"PWD\",\"%s\"",cRet);
SendAt(cSend,"",nTOut);

SendAt("AT+SAPBR=3,1,\"Contype\",\"GPRS\"","",nTOut); //- Tipo de conexão (GPRS)

SendAt("AT+SAPBR=1,1","",nTOut); //- Final de envio de registro

//- Configurações FTP ---------------------------------------------------------------------------------------------------------------

SendAt("AT+FTPCID=1","",nTOut);

ReadFile(cSetup,"FTPSRV",cRet); //- Servidor FTP

sprintf(cSend,"AT+FTPSERV=\"%s\"",cRet);
SendAt(cSend,"",nTOut);

ReadFile(cSetup,"FTPPORT",cRet); //- Porta do servidor FTP

sprintf(cSend,"AT+FTPPORT=\"%s\"",cRet);
SendAt(cSend,"",nTOut);

ReadFile(cSetup,"FTPUSR",cRet); //- Usuário FTP

sprintf(cSend,"AT+FTPUN=\"%s\"",cRet);
SendAt(cSend,"",nTOut);

ReadFile(cSetup,"FTPPSW",cRet); //- Senha FTP

sprintf(cSend,"AT+FTPW=\"%s\"",cRet);
SendAt(cSend,"",nTOut);
}

//-- Funções GPS --------------------------------------------------------------------------------------------------------------------------

/****************************************************************************************
Função....: GetGPSInfo()
Parâmetros:
Resposta..: 1 - Execução com sucesso.
0 - Falha.
*****************************************************************************************/
char GetGPSInfo(){
char cDataRead[100], //- Informação obtida do receptor GPS
cAjust[10]; //- Ajuste

if (ReadGPS(cDataRead)){
ReadFile(cSetup,"UTC_A",cAjust);
if(!(nUtcTime = GPSInfo(cDataRead,7,0,-1,ConvDouble(cAjust,0)))) return 0;
if(nUtcTime < 0.0) nUtcTime+=240000.00;

ReadFile(cSetup,"LAT_A",cAjust);
if(!(nLatitude =(GPSInfo(cDataRead,18,6,0,ConvDouble(cAjust,6))))) return 0;

ReadFile(cSetup,"LON_A",cAjust);
if(!(nLongitude=(GPSInfo(cDataRead,32,6,1,ConvDouble(cAjust,6))))) return 0;
return 1;
}
return 0;
}

/****************************************************************************************
 63

Função....: ReadGPS()
Parâmetros: cDataRead - Retorno da informação obtida pelo receptor GPS.
Resposta..: 1 - Execução com sucesso.
0 - Falha.
*****************************************************************************************/
char ReadGPS(char *cDataRead){
int nX = 0;
char cProt[6] = {'$','G','P','G','G','A'}; //- Protocolo GPGGA

digitalWrite(3,HIGH); //- Desativa modo GSM

delay(500);
digitalWrite(4,LOW); //- Ativa modo GPS
delay(500);

Serial.println("AT+CGPSINF=2"); //- Requisição solicitando informação GPS

delay(2000);

while (nX != 6){ //- Recebe protocolo $GPGGA da serial.

if(Serial.available()){
cDataRead[nX] = Serial.read();
if (cDataRead[nX]==cProt[nX])
nX++;
else
nX=0;
}
}
while (nX != 100 ) { //- Leitura da informação recebida da serial
if(Serial.available()){
cDataRead[nX] = Serial.read();
if (cDataRead[nX] == '$') { //- Finaliza ao receber '$'
cDataRead[nX] = '\0';
Serial.println(cDataRead);
return 1;
}
nX++;
}
}
return 0;
}

/****************************************************************************************
Função....: GPSInfo()
Parâmetros: cDataRead - Informação obtida pelo receptor GPS.
nMod - Posicionador da linha.
nDec - Quantidade de casa decimais esperada.
nDir - Informa se calcula direção
[-1] Não calcula
[0] Latitude
[1] Longitude
nAjust - Ajuste a ser realizado antes do retorno.

Resposta..: fValor - Valor da informação solicitada.

*****************************************************************************************/
double GPSInfo(char *cDataRead, int8_t nMod, int8_t nDec, int8_t nDir, float nAjust){
char cReturn[15];
strcpy(cReturn,strtok(cDataRead+nMod,","));
if (strlen(cReturn) < 5) return 0.0;

if (nDir == -1)
return (ConvDouble(cReturn,nDec) + nAjust);
else
 64

return (((ConvDouble(cReturn,nDec)/100) + nAjust) * GPSDir(cDataRead,nDir));

}

/****************************************************************************************
Função....: GPSDir()
Parâmetros: cDataRead - Informação obtida pelo receptor GPS.
nDir - Informa deslocamento na string para cálculo de direção
[0] Latitude
[1] Longitude

Resposta..: 1 - North (N) ou East (E)

-1 - South (S) ou West (W)
*****************************************************************************************/
double GPSDir(char *cDataRead,char cDir){
int i = 30 + (cDir * 15);
if ((cDataRead[i] == 'S') || (cDataRead[i] == 'W'))
return -1.0;
else
return 1.0;
}

//-- Funções Camera------------------------------------------------------------------------------------------------------------------------

/****************************************************************************************
Função....: GetImagem()
Parâmetros:
Resposta..: 1 - Execução com sucesso.
0 - Falha.
*****************************************************************************************/
char GetImagem(){
//- Novo objeto de camera utilizando comunicação serial nas portas 6(Tx) e 7(Rx)
SoftwareSerial CamConn = SoftwareSerial(6,7);
Adafruit_VC0706 Cam = Adafruit_VC0706(&CamConn);
File fSDFile;

if(Cam.begin()){ //- Inicializa câmera.

Cam.setImageSize(VC0706_640x480); //- Tamanho da imagem 640x480 pixels.
delay(2000);

if(Cam.takePicture()){ //- Captura imagem.

strcpy(cCamFile,"IMAG00.JPG"); //- Busca no cartão SD nome disponível.
for(int nX=0; nX<100; nX++){
cCamFile[4] = '0' + nX/10;
cCamFile[5] = '0' + nX%10;
if(!SD.exists(cCamFile)) break;
}
fSDFile = SD.open(cCamFile, FILE_WRITE); //- Abre arquivo para escrita.
uint16_t nJPGLen = Cam.frameLength(); //- Tamanho da imagem em bytes.

//- Realiza leitura do buffer enquanto existir bytes a serem lidos e escreve no arquivo
while(nJPGLen > 0){
uint8_t cBytesLeft = min(64, nJPGLen);
uint8_t *cBuffer = Cam.readPicture(cBytesLeft);
fSDFile.write(cBuffer,cBytesLeft);
nJPGLen -= cBytesLeft;
}
fSDFile.close(); //- Fecha arquivo no SD.
Serial.println(cCamFile);
return 1;
}
else{
return 0; //- Falha de execução.
 65

}
}
else {
return 0; //- Falha de execução.
}
}

//-- Funções Envio GRPS / FTP --------------------------------------------------------------------------------------------------------

/****************************************************************************************
Função....: SendGPRS()
Parâmetros:
Resposta..: 1 - Execução com sucesso.
0 - Falha.
*****************************************************************************************/
char SendGPRS(){
char cRet[40];
int nDelay = 5000;

digitalWrite(4,HIGH); delay(500); //- Desativa modo GPS

digitalWrite(3,LOW); delay(500); //- Ativa modo GSM

SendAt("AT+HTTPINIT","",2000);
SendAt("AT+HTTPPARA=\"CID\",1","",2000);
Serial.print("AT+HTTPPARA=\"URL\",\""); //- Estrutura da requisição HTML
ReadFile(cSetup,"SERVER",cRet); //- Servidor
Serial.print(cRet);
Serial.print("id="); //- ID de usuário
ReadFile(cSetup,"ID",cRet);
Serial.print(cRet);
Serial.print("&utc="); //- Horário
Serial.print(nUtcTime);
Serial.print("&lat="); //- Latitude
Serial.print(nLatitude,6);
Serial.print("&lon="); //- Longitude
Serial.print(nLongitude,6);
Serial.print("&file="); //- Arquivo
Serial.print(cCamFile);
SendAt("\"","",2000);

//- Retorno da função é o resultado da requisição HTTP e o envio FTP.

return (SendAt("AT+HTTPACTION=0","",10000) && SendFTP(cRet)) ;
}

/****************************************************************************************
Função....: SendFTP()
Parâmetros: cID - ID do usuario.
Resposta..: 1 - Execução com sucesso.
0 - Falha.
*****************************************************************************************/
char SendFTP(char *cID){
File fSDFile;
int nX = 0;
char cRead[100];

sprintf(cRead,"AT+FTPPUTNAME=\"%s\"",cCamFile);
SendAt(cRead,"",2000);

sprintf(cRead,"AT+FTPPUTPATH=\"%s\"",cID);
SendAt(cRead,"",2000);
 66

if (SendAt("AT+FTPPUT=1","+FTPPUT:1,1",5000)){
fSDFile = SD.open(cCamFile,FILE_READ);
while(fSDFile.available()){
cRead[nX] = fSDFile.read();
nX++;
if(nX > 100){
//- Realiza o envio ao FTP, em caso de falha, retorna 0.
if(!SendAt("AT+FTPPUT=2,100","+FTPPUT:",5000) && !SendAt(cRead,"+FTPPUT:",5000)){
fSDFile.close();
return 0;
}
}
}
cRead[nX] = '\0';
if(!SendAt("AT+FTPPUT=2,100","+FTPPUT:",5000) && !SendAt(cRead,"+FTPPUT:",5000)){
fSDFile.close();
return 0;
}
return 1;
}
}

//-- Funções Auxiliares--------------------------------------------------------------------------------------------------------------------

/****************************************************************************************
Função....: SendAt()
Parametros: cComando - Comando AT a ser enviado.
cEsper - Resposta esperada do comando AT.
nTimeout - Tempo máximo de espera antes de retornar falha.

Resposta..: 1 - Execução com sucesso.

0 - Falha.
*****************************************************************************************/
char SendAt(char *cComando, char *cEsper, unsigned int nTimeout){
unsigned long nTime;
char cResp[100];
int nX = 0,
nResp = 0;

if (!strlen(cEsper)) sprintf(cEsper,"OK");

while(Serial.available() > 0) Serial.read(); //- Limpa serial

Serial.println(cComando); //- Executa comando AT

nTime = millis();
do{
if(Serial.available() > 0){
cResp[nX] = Serial.read();
Serial.print(cResp[nX]);
nX++;
if(strstr(cResp,cEsper) != NULL) nResp = 1;
}
} while(nResp == 0 && millis()-nTime < nTimeout); //- Enquanto sem resposta ou timeout

return nResp;
}
/****************************************************************************************
Função....: ConvDouble
Parâmetros: cValor - String de entrada que será convertida.
nNum - Numero de casas decimais.
*****************************************************************************************/
double ConvDouble (char *cValor, int nNum){
double dTemp = 0.0; //- Variável de retorno
 67

int cNeg = 0; //- Define valor negativo

int cI = 0;
int cJ = 0;
if ( cValor[cI] == '-' ){ //- Verifica se primeiro caractere é '-' e define valor como negativo
cNeg = 1;
cI++;
}

while(cValor[cI] != '.' && cValor[cI] != '\0') //- Enquanto caractere não for '.' compõe a parte inteira.
dTemp = dTemp * 10 + (cValor[cI++] - 0x30);

for (cJ=0;cJ<nNum;cJ++) //- Adiciona nNum zeros a parte inteira

dTemp = dTemp * 10 + (cValor[++cI] - 0x30);

for (cJ=0;cJ<nNum;cJ++) //- Divide a parte inteira para compor ponto flutuante
dTemp = dTemp / 10;

if (cNeg == 1) dTemp *= -1; //- Se negativo, multiplica por -1

return dTemp;
}

/****************************************************************************************
Função....: ReadFile
Parametros: cArq - Arquivo de configuração que será lido.
cBusca - Configuração a ser lida do arquivo.
cRet - Resposta obtida do arquivo de configuração.
*****************************************************************************************/
void ReadFile(char *cArq, char *cBusca, char *cRet){
int nX = 0;
File fSDFile;
fSDFile = SD.open(cArq,FILE_READ);

if (fSDFile){
while (fSDFile.available() && fSDFile.read() != '$');
while(fSDFile.available() && nX < strlen(cBusca)-1){
if(fSDFile.read() == cBusca[nX]){
nX++;
}
else{
nX = 0;
while(fSDFile.available() && fSDFile.read() != '$');
}
}
while(fSDFile.available() && fSDFile.read() != ':');
nX = 0;
while(fSDFile.available()){
cRet[nX] = fSDFile.read();
if(cRet[nX] == ';') break;
nX++;
}
cRet[nX] = '\0';
}
fSDFile.close();
}

/****************************************************************************************
Função....: Logger
Parametros: cFile - Arquivo que será escrito o log
cErrCod - Código do Erro.
*****************************************************************************************/
void Logger(char *cFile, char *cCodErr){
 68

char cErro[100];
File fSDFile;

ReadFile(cFile,cCodErr,cErro);
fSDFile=SD.open("Erro.log",FILE_WRITE);
fSDFile.println(cErro);
Serial.println(cCodErr);
Serial.println(cErro);
fSDFile.close();
}
 69

11. Criação da tabela no banco de dados

CREATE TABLE tb_gpsinfo (

reg datetime NOT NULL DEFAULT NOW(),
id VARCHAR(10) NOT NULL,
utc VARCHAR(20) NOT NULL,
lat VARCHAR(20) NOT NULL,
lon VARCHAR(20) NOT NULL,
img VARCHAR(20),
PRIMARY KEY (reg,id)
)

12. Website – Aquisição de dados

<?php

//- Variaveis PHP

$ID = $_GET['id'];
$UTC = $_GET['utc'];
$LAT = $_GET['lat'];
$LON = $_GET['lon'];
$ARQ = $_GET['file'];

//- Variaveis MySql

$dbhost="mysql.hostinger.com.br";
$dbuser="u655789027_info";
$dbpass="is159753";
$dbname="u655789027_info";
$base='tb_gpsinfo';

//- Conexão MySql

$conn=mysqli_connect($dbhost,$dbuser,$dbpass,$dbname);

$myquery = "insert into $base values (now(),'$ID','$UTC','$LAT','$LON','$ARQ');";

mysqli_query($conn,$myquery);

?>

13. Website – Exibição de dados

<?php
//- Variaveis PHP
$ID = $_GET['id'];

//- Variaveis MySql

$dbhost="mysql.hostinger.com.br";
$dbuser="u655789027_info";
$dbpass="is159753";
$dbname="u655789027_info";
$base='tb_gpsinfo';

//- Conexão MySql

$conn=mysqli_connect($dbhost,$dbuser,$dbpass,$dbname) or die(mysql_error);

$myquery="select * from $base";

if ($ID != NIL){
$myquery= $myquery." where id = $ID";
}

$query_res=mysqli_query($conn,$myquery);
?>
 70

<!DOCTYPE html>
<html lang="pt-br">
<head>
<meta charset="utf-8">
<title>GPS Tracker</title>

<style>
div.linha_topo {
border-bottom: solid black 1px;
width: 50%;
text-align: center;
}
div.linha{
z-index:99px;
width: 50%
}

div.linha:hover{
background: #2980b9
}

div.coluna{
width: 10%;
display: table-cell;
text-align: center;
}

div.coluna_img{
width: 10%;
display: table-cell;
text-align: center;
}

div.coluna_img:hover {
cursor: pointer;
}

div.coluna_img:hover span{
background: black;
position: absolute;
z-index: 200px;
padding: 10px;
margin-left: 30px;
margin-top: 5px;
width: 500px;
height: 400px;
border: solid black 2px;
display: block;
}
div.coluna_img span{
display: none;
}

.img_cam {
width: 100%;
height: 100%;
}

</style>

<script>
</script>
</head>
<body>
<section id="topo">
<div>
<h1> GPS Tracker - Informa&ccedil;&atilde;o </h1>
</div>
</section>
<section id="tabela">
<div class='linha_topo'>
 71

<div class='coluna'> ID </div>

<div class='coluna'> UTC </div>
<div class='coluna'> LATITUDE </div>
<div class='coluna'> LONGITUDE </div>
<div class='coluna'> ARQUIVO </div>
</div>

<? while($data=mysqli_fetch_array($query_res,MYSQLI_ASSOC)){ ?>

<div class='linha'>
<div class='coluna'>
<? echo $data['id']; ?>
</div>
<div class='coluna'>
<? echo $data['utc'];?>
</div>
<div class='coluna'>
<? echo $data['lat'];?>
</div>
<div class='coluna'>
<? echo $data['lon'];?>
</div>
<div class='coluna_img'>
<? echo $data['img']; ?>
<span>
<img class='img_cam' src="http://gpsimage.hol.es/<?echo
$data['id'];?>/<? echo $data['img'];?>" alt="">
</span>
</div>
</div>
<? } ?>
</section>
</body>
</html>