locbus - ufpro lpc1768 pode operar até uma freqüência de 100 mhz. o processador arm cortex-m3...

UNIVERSIDADE FEDERAL DO PARANÁSetor de Tecnologia – Engenharia Elétrica

LocBus

Sistema de Rastreamento de Transportes Coletivos

CURITIBA – 2011

Marcelo Baggio

LocBus


Monografia apresentada à disciplina TE105 (Trabalho de Conclusão de Curso) realizado pelo aluno Marcelo Baggio, portador do GRR20062548, para aprovação na matéria e requisito parcial para obtenção do título de engenheiro eletricista.

Orientador: Prof. Dr. Márlio J do C. Bonfim.

CURITIBA – 2011

Marcelo Baggio

LocBus


Monografia apresentada à disciplina TE105 (Trabalho de Conclusão de Curso) realizado pelo aluno Marcelo Baggio, portador do GRR20062548, para aprovação na matéria e requisito parcial para obtenção do título de engenheiro eletricista.

Orientador: Prof. Dr. Márlio J do C. Bonfim.

COMISSÃO EXAMINADORA

_______________________________ Prof. Dr. Márlio J. Do C. Bonfim

_______________________________ Prof. Dr. Alessandro Zimmer

_______________________________ Profª. Dra. Giselle Ferrari

Curitiba, 01 Julho de 2011

AGRADECIMENTOS

À minha família, em especial meu irmão Gustavo Baggio, que me ajudou e auxiliou na área de banco de dados e no Sistema Geográfico.

Ao meu colega de trabalho Rodolfo Bandeira, que emprestou o servidor onde este sistema está hospedado e auxiliou em diversos momentos.

Ao professor Orientador Márlio Bonfim pela ajuda prestada no desenvolvimento deste projeto.

Aos professores da UFPR por todo o conhecimento passado ao longo destes anos que permaneci na instituição.

RESUMO

A monografia visa exibir um novo sistema para melhorar a qualidade do transporte

público na cidade. Mostrar os passos realizados, bem como testes e resultados, para o projeto

de um rastreador, e uma aplicação web capaz de mostrar rotas, paradas e uma estimativa de

horário. Serão apresentados custos, peças, e toda a teoria envolvida para a construção do

protótipo final.

Palavras-chaves: Rastreamento, transporte, estimativa, GIS, aplicativo, ônibus.

ABSTRACT

This monograph shows a new system to improve the quality of public transport in the

city. Shows the steps taken, tests and results, for the project of a tracker and a web

application capable of displaying routes, bus stops and an estimated time. Will be presented

costs, parts, and all the theory involved to build the final prototype.

Key words: Tracking, transport, estimate, GIS, application, bus.

LISTA DE FIGURAS

Figura 1: Sistema de rastreamento…........................................................................................ 5

Figura 2: Esquemático ligação Serial....................................................................................... 6

Figura 3: LPC1768 Diagrama de Blocos Simplificado …....................................................... 8

Figura 4: Mbed e pinagem …................................................................................................... 9

Figura 5: Rede GPRS …......................................................................................................... 10

Figura 6: Protótipo do rastreador …........................................................................................ 15

Figura 7: Esquemático do Circuito …..................................................................................... 16

Figura 8: Circuito do regulador chaveado LM2576 …........................................................... 17

Figura 9: Placa de circuito impresso, visão Superior …......................................................... 18

Figura 10: Placa de circuito impresso, visão Inferior …......................................................... 19

Figura 11: Visão Geral do firmware …................................................................................... 21

Figura 12: Fluxograma do programa ….................................................................................. 22

Figura 13.a: Comandos enviados pelo Rastreador ….............................................................. 24

Figura 13.b: Comandos enviados pelo Rastreador – continuação …...................................... 25

Figura 14: Fluxograma do Servidor ….................................................................................... 35

Figura 15: Sistema rastreando um veículo em uma rota de ônibus ….................................... 39

Figura 16: Distância entre dois pontos geográficos …........................................................... 42

Figura 17: Distância entre dois pontos no círculo unitário …................................................. 43

Figura 18: Esfera unitária para demonstração da fórmula de Haversine …............................ 44

Figura 19: Trapézio isósceles retirado da esfera unitária ….................................................... 45

Figura 20: Triângulo para determinar o ângulo AÔB …......................................................... 46

Figura 21: Distância medida pelo sistema LocBus …............................................................. 48

Figura 22: Distância medida pelo Google Maps …................................................................ 49

Figura 23: Rastreador montado parcialmente ….................................................................... 57

Figura 24: Rastreador dentro do case …................................................................................. 57

Figura 25: Teste da função de rastreamento do sistema …..................................................... 59

Figura 26: Previsão de horário …............................................................................................ 60

Figura 27: Tempos medidos e tempo estimado ….................................................................. 62

LISTA DE ACRÔNIMOS

• ADC – Analogic-Digital Converter

• API – Aplication Programming Interface

• CAN – Controller Area Network

• CSS – Cascading Style Sheets

• DAC – Digital-Analogic Converter

• DNS – Domain Name System

• ETSI – European Telecommunications Standards Institute

• GIS – Geographic Information System

• GPIO – General Purpose Input/Output

• GPRS – General Packet Radio Service

• GPS – Global Positioning System

• GSM – Global System for Mobile Communications

• HTML - HyperText Markup Language

• IP – Internet Protocol

• LAN – Local Area Network

• MAC – Media Access Control

• NMEA – National Marine Electronics Association

• PHP - Hypertext Preprocessor

• PPP – Point to Point Protocol

• PWM – Pulse-Width Modulation

• RAM – Random Access Memory

• ROM – Read Only Memory

• RTC – Real Time Clock

• SQL – Structured Query Language

• TCP – Transmission Control protocol

• UART – Universal Asynchronous Receiver/Transmitter

• UDP – User Datagram Protocol

• USB – Universal Serial Bus

SUMÁRIO

Introdução …............................................................................................................................. 4

2. LocBus ….............................................................................................................................. 6

2.1 Hardware ….................................................................................................................... 6

2.1.1 Microcontrolador …............................................................................................... 7

2.1.2 Mbed ….................................................................................................................. 8

2.1.3 Modem …............................................................................................................... 9

2.1.4 GPS …................................................................................................................... 11

2.1.4.1 Características Técnicas …................................................................. 12

2.1.4.2 Protocolo NMEA 0183 …................................................................... 13

2.1.5 Protótipo …............................................................................................................14

2.1.6 Placa …................................................................................................................. 15

2.2 Firmware ….................................................................................................................. 20

2.2.1 A Máquina de Estados …...................................................................................... 22

2.3 Servidor ….................................................................................................................... 26

2.3.1 API Google Maps …............................................................................................. 27

2.3.2 MySQL …............................................................................................................. 29

2.3.2.1 Comunicando com o MySQL ….......................................................... 30

2.3.2.2 Construindo Queries …........................................................................ 30

2.3.3 PHP …................................................................................................................... 31

2.3.3.1 PHPMyAdimin …................................................................................. 31

2.3.4 Sistema de Informação Geográfico (GIS) …......................................................... 31

2.3.5 GeoCode reverso e os DynamapID's …................................................................ 33

2.3.6 Estrutura do Servidor …....................................................................................... 34

1

2.3.6.1 Index.php ….......................................................................................... 35

2.3.6.2 Jquery.js …............................................................................................ 35

2.3.6.3 Map.js …............................................................................................... 36

2.3.6 GetRota.php …........................................................................................ 36

2.3.6.5 GetBus.php …...................................................................................... 36

2.3.6.6 GetPontos.php …................................................................................. 37

2.3.6.7 GetSpeed.php …................................................................................... 37

2.3.6.8 GetRotaID.php …................................................................................. 37

2.3.6.9 MySQL …............................................................................................ 37

2.3.6.10 Coord.php …...................................................................................... 38

2.3.6.11 Classes.php ….................................................................................... 38

2.3.7 Previsão de Horário ….......................................................................................... 39

2.3.7.1 Cálculo da distância ….......................................................................... 40

2.3.7.2 Aquisição da velocidade média …......................................................... 49

2.3.7.3 Cálculo do tempo estimado …............................................................... 50

2.3.7.4 Variáveis periódicas ….......................................................................... 50

2.4 Custos do Projeto …..................................................................................................... 52

2.4.1 Custos do rastreador …......................................................................................... 52

2.4.2 Google Maps Premier …...................................................................................... 53

2.4.3 Frota de ônibus e custo inicial ….......................................................................... 53

2.4.4 Cálculo e custo de uso de banda mensal do chip GPRS ….................................. 54

2.4.5 Custo de Manutenção …....................................................................................... 54

2.5 Testes e Resultados Finais …....................................................................................... 56

2.5.1 Rastreador …........................................................................................................ 56

2

2.5.2 Função de rastreamento ….................................................................................... 58

2.5.3 Previsão de Horário …......................................................................................... 59

3. Conclusão …........................................................................................................................ 63

Referência Bibliográfica …...................................................................................................... 66

Anexo I …............................................................................................................................... .68

3

1. INTRODUÇÃO

O projeto consiste no desenvolvimento de um sistema de rastreamento de transporte

coletivos, cujo principal objetivo é proporcionar aos usuários uma maneira simples de

verificar onde se localizam os ônibus de uma determinada linha, itinerários, rotas de linhas de

ônibus, previsão de chegada e outras funcionalidades.

Cerca de 2.300.000 (duas milhões e trezentas mil) pessoas usam o serviço de

transporte público em Curitiba e Região Metropolitana diariamente nas 353 linhas de ônibus

que percorrem cerca de 500.000km por dia [16]. Logo, um aplicativo que proporcione uma

melhor qualidade do serviço de transporte pode ser amplamente usada por milhares de

curitibanos que dependem do ônibus.

O acesso às informações poderá ser feito através de qualquer dispositivo com conexão

à internet, sendo que o foco principal é o uso de celulares, devido à grande disseminação de

smartphones no mercado.

O funcionamento ocorre da seguinte forma: um rastreador instalado em um veículo

requisita as coordenadas através de um módulo GPS. Estas coordenadas são enviadas a um

servidor através de uma conexão GPRS e armazenadas em banco de dados (MySQL). O

aplicativo responsável por mostrar as informações então requisita os dados do banco e os

exibem em uma página na internet desenvolvida em PHP e Javascript com a API do

GoogleMaps, onde o usuário possa acessar e visualizar o conteúdo.

A figura abaixo ilustra de forma simplificada o sistema de rastreamento.

4

Figura 1 – Sistema de Rastreamento

Também é o foco dessa dissertação apresentar a teoria envolvida em cada parte do

projeto, bem como testes realizados e os resultados obtidos. Para os resultados, espera-se que

o sistema seja capaz de desenvolver a função de rastreamento e que a previsão de horário

esteja dentro do limite de erros de segundos, para o caso de um percurso normal, sem

acidentes ou anormalidades que aumentem ou diminuam muito a expectativa de tempo.

5

2. LOCBUS

2.1 HARDWARE

O hardware consiste na parte física do dispositivo, formada por um microcontrolador

que gerencia o rastreador e envia comandos para um modem GPRS/GPS. Este, por sua vez, é

responsável por coletar as coordenadas GPS e as enviar do dispositivo para o servidor.

A comunicação entre os dois módulos (microcontrolador e modem) é estabelecida

serialmente por dois sinais: Tx (transmite os dados) e Rx (recebe os dados). Onde o sinal Tx

de um módulo é ligado no pino Rx do outro e vice-versa, e um sinal de terra é comum à todos.

Com estes três fios é possível estabelecer a comunicação entre o microcontrolador e o modem

GPRS. As figuras abaixo mostram como é feita a ligação serial entre a placa do

microcontrolador e a placa do modem GPRS.

Figura 2 – Esquemático da ligação serial entre os dois módulos

Importante salientar que foram usados transistores para fazer a transição do sinal de

um módulo para o outro. O Modem é alimentado por 5V enquanto o microcontrolador usa

6

3.3V, o que poderia ocasionar danos à entrada do controlador caso a tensão mais alta fosse

usada.

2.1.1 Microcontrolador:

Segundo datasheet “user manual lpc17xx”, Agosto de 2010, o LPC1768 é um

microcontrolador ARM Cortex-M3 para aplicações embarcadas que exigem um elevado nível

de integração e baixa dissipação de energia.

O LPC1768 pode operar até uma freqüência de 100 MHz. O processador ARM

Cortex-M3 incorpora um pipeline de 3 estágios e usa uma arquitetura Harvard, com o bus de

instrução local separado do barramentos de dados, bem como um terceiro bus para os

periféricos.

Os periféricos do LPC1768 incluem 512kB de memória flash, até 64 kB de memória

de dados, Ethernet MAC, uma interface USB que pode ser configurado como Host, ou

Device, 4 UARTs, 2 canais CAN, dois controladores de SSP, SPI, 3 interfaces I²C, I²S, 8

canais ADC de 12 bits, 10 bits DAC, controle de motor PWM, quatro temporizadores de uso

geral, RTC de baixa potência com fonte de bateria separada, e até 70 pinos de I / O.

O diagrama de blocos simplificado do microcontrolador pode ser visto na figura 2

abaixo.

7

Figura 3 – LPC1768 Diagrama de Blocos simplificado, referência [1].

2.1.2 Mbed:

Visando a rápida evolução do projeto, optou-se por usar um kit de desenvolvimento

que utilizasse o microcontrolador já especificado acima. O Mbed oferece vários GPIOs,

interfaces seriais, ethernet, USB, conversores AD e DA usando o LPC1768. O

microcontrolador processa as informações a 4MHz, e conta com mais memória RAM, devido

a uma memória externa instalada na placa. Além disso, pode-se utilizar o compilador online

oferecido pela empresa, onde encontram-se várias bibliotecas já prontas para o Mbed, e uma

rápida forma de gravação via USB. O kit é mostrado na figura abaixo junto com a pinagem.

8

Figura 4 – Mbed e pinagem, retirado de http://mbed.org

2.1.3 Modem:

No projeto, há a necessidade de enviar os dados de forma wireless. Pelo fato do

rastreador não necessitar de um grande fluxo de informações com o servidor, o serviço de

GPRS foi utilizado no projeto.

Segundo Sanders, Thorens, Reisky, Rulik e Deylitz (GPRS Networks, 2003), GPRS é

um serviço introduzido ao GSM que permite enviar e receber pacotes de dados a altas

velocidades, possibilitando Internet móvel, controle remoto de dispositivos, jogos

multiplayer, m-commerce e demais serviços.

O GPRS criou-se pela necessidade de atender a certos serviços:

• Habilitar acesso à Internet e à LAN da empresa para o usuário;

• Prover relativamente alta taxa de velocidade de transmissão de dados;

• Habilitar o usuário de ser achado a qualquer hora – através de e-mails por

exemplo, e não apenas de chamadas de voz;

9

• Acesso mais flexível à rede para vários usuários ao mesmo tempo, e otimizar o

uso da rede baixando os custos para o provedor;

• Oferecer novos serviços a preços mais baixos;

A figura a seguir ilustra as vantagens do GPRS.

Figura 5 – Rede GPRS, referência [2] .

Pela facilidade oferecida e fácil disponibilização do produto, foi adquirido um modem

GPRS da fabricante italiana Telit. Outra vantagem deste modem é a integração de GPS e

entrada de SIMCard no mesmo módulo.

Para o modem estabelecer conexão com a rede GPRS e também para fornecer as

informações de coordenadas GPS, é necessário o uso de comandos que digam ao modem o

que deve ser feito. Para isso, vários modems usam um protocolo de comandos, conhecido

como Comandos AT. Há centenas de comandos, para as mais diversas funções como:

discagem para celular, armazenamento de números na memória, conexão GPRS, tocar

campainha, entre outros. Enviando certos comandos para o modem, é possível configurar e

conectá-lo à rede GPRS e enviar os dados para o servidor.

10

O módulo GM862 pode ser guiado através da interface serial usando os comandos AT

padrões. O módulo é compatível com:

• Lista de comandos AT padrão de Hayes, para manter a compatibilidade com

programas já existentes;

• ETSI GSM 07.07 comandos AT específicos e comandos GPRS;

• ETSI GSM 07.05 comandos AT específicos para SMS (Short Message Service) e CBS

(Cell Broadcast Service);

• Comandos FAX Classe 1.

E ainda o módulo suporta uma lista de comandos AT especial desenvolvida pela Telit.

O anexo I mostra todos os comandos AT usados neste projeto, suas funções e o

significado de cada possível resposta.

Também foi utilizado uma placa de desenvolvimento para o modem (Smart GM862),

expondo os pinos e cuidando da regulação da tensão de entrada.

2.1.4 GPS:

De acordo com Hegarty e Kaplan (Understanding GPS, Principles and Aplications,

2006), o GPS é totalmente funcional e atende aos critérios estabelecidos nos anos 60 de um

sistema de posicionamento ótimo. O sistema fornece uma forma precisa e global de se obter

coordenadas e velocidade. Também disseminou a forma de exibição de tempo Coordinated

Universal Time (UTC). A constelação de satélites consiste em 24 satélites arranjados em 6

planos de órbita com 4 satélites em cada órbita. Uma rede de monitoramento global monitora

os status dos satélites, enviando dados e atualizando os satélites quando necessário. O GPS

envia dados em apenas duas freqüências: L1 (1575,42MHz) e L2 (1227.6MHz) usando uma

técnica chamada Code Division Multiple Access (CDMA).

11

2.1.4.1 Características Técnicas:

No modem Telit em específico, o módulo GM862-GPS inclui um chip receptor de

sinal GPS SiRFstarIII, que suporta localização em tempo real em área urbana e sempre que

aquisições de alta sensibilidade são necessárias. Não possui antena interna, logo uma antena

externa de é necessária. Como principais características do receptor GPS, podem-se citar:

• Alta sensibilidade para recepção dentro de estabelecimentos, até -159dBm (com

antena ativa);

• “Hot start” menor que 3 segundos;

• Suporta 20 canais GPS L1 1575.42MHz;

• Precisão maior que 2,5m;

• Formato da resposta do GPS respeitando o protocolo NMEA 0183;

• Comandos AT dedicados para o GPS;

• Baixo consumo

O tempo para fixar a primeira coordenada válida demora menos de 3 segundos para

Hot Start, e menos de 35 segundos para os modos Warm Start e Cold Start. A sensibilidade

do módulo chega a até -159dBm. O módulo consome em média 55mA, incluindo 35mA para

o hardware e 20mA para a antena externa. A antena do GPS deve respeitar as seguintes

especificações:

• Frequência: 1575,42MHz;

• Ganho: 1,5dBi < Ganho < 4,5dBi

• Impedância: 50 Ohm

• Amplificação: Típica 25dBm (max. 27dBm)

12

• Tensão: Deve aceitar entre 3V e 5V DC

• Corrente: Típica de 20mA (max. 40mA)

2.1.4.2 Protocolo NMEA 0183:

O NMEA 0183 são especificações elétricas e de dados combinados para comunicação

entre equipamentos marinhos, entre eles o GPS. É controlado pelo National Marine

Electronics Association nos Estados Unidos.

A comunicação definida pelo protocolo NMEA é um link serial, com o fluxo de

dados de 4800 bits/segundo, sendo transmitidos 8 bits de dados, sem controle de paridade,

sem handshake e com um bit de parada. A sentença NMEA pode ser formado por qualquer

caractere da tabela ASCII, sendo que esta mensagem sempre começa com o símbolo “$” e

termina com um carriege return “\r” seguido de um new line “\n”. Sempre há um talker se

comunicando com um ou mais listeners, análogo a um componente mestre requisitando

informações aos componentes escravos.

Há três tipos de sentenças:

• Talker: Em que o talker requisita informações aos listeners;

• Proprietary: Em que empresas criam seus próprios formatos;

• Query: Em que o listener solicita uma determinada sentença para o talker.

No caso deste projeto, apenas foi usada sentenças tipo “Talker”. Estas ocorrem

quando um dispositivo mestre requisita informações a um dispositivo escravo, no caso, um

módulo GPS. Dessa forma, pode-se identificar o tipo de dispositivo “listener” através das

duas primeiras letras que vêm após o inicio “$” da sentença, no caso do GPS, as duas letras

são GP. Por isso, uma solicitação de coordenadas para um GPS obedecendo o formato

13

NMEA, sempre começará com “$GP[...]”. Há diversos outros dispositivos, e cada um tem seu

par de letras definidos.

Para o modem, ao enviar o comando AT (AT$GPSACP) que requisita a posição GPS, é

enviada uma resposta no seguinte formato:

$GPSAPC: <UTC>, <latitude>,<longitude>,<hdop>,<altitude>,<fix>,<cog>,<spkn>,<date>,<nsat>

Onde as informações importante ao projeto são:

<UTC> - Hora UTC (hhmmss.sss);

<latitude> - No formato ddmm.mmmm N/S, onde dd – graus e mm.mmmm – minutos,

seguido de N/S: Norte/Sul;

<longitude> - No formato dddmm.mmmm E/W, idem ao acima, seguido de E/W:

Leste/Oeste;

<spkm> - Velocidade sobre a terra (Km/h);

<date> - Data no formato ddmmyy (dia, mês e ano respectivamente);

Esta informação é gravada no microcontrolador e processada pelo firmware, que será

explicado mais adiante.

2.1.5 Protótipo:

O protótipo do rastreador é mostrado abaixo, com os dois módulos ligados por uma

comunicação serial. Medições realizadas mostram que o consumo médio do rastreador em

espera é de 200mA, chegando a 300mA quanto o modem está enviando dados ao servidor,

pois é necessário fornecer maior corrente elétrica à antena GPRS afim de aumentar a potência

para transmissão.

Os testes foram realizados com uma bateria selada de chumba-ácida capaz de fornecer

2300mAH para o rastreador.

14

Figura 6 – Protótipo do rastreador

2.1.5 Placa:

A placa de circuito impresso foi desenvolvida usando a versão livre do software Eagle.

É composta por uma placa dual layer, projetada para regular a tensão de entrada (12V) para as

tensões necessárias para os módulos (4V para o modem Telit e 5V para a placa Mbed).

Também há transistores responsáveis pela transição de sinal na comunicação serial entre os

dois módulos. O esquemático do circuito pode ser verificado abaixo.

15

Figura 7 – Esquemático do circuito

16

A tensão de entrada (12V) passa por um regulador de tensão com saída ajustável.

Optou-se por usar um regulador chaveado (LM2576), devido ao sobreaquecimento causado

pela dissipação de potência de um regulador linear. Segundo datasheet da fabricante [17] do

regulador, a tensão de saída pode ser calculada como:

Vout = Vref * (1 + (R2/R1)) (1)

Onde Vref vale 1,23[V] segundo [17], e Vout é a tensão de saída do regulador, e R2 e

R1 fazem parte de um divisor de tensão para realimentar o circuito regulador. Conforme a

figura abaixo.

Figura 8 – Circuito do regulador chaveado LM2576, retirado de [17]

A tensão desejada é de 4,6[V], logo, fixando um valor de R1 de 1,2[kOhm] e usando

a equação (1) acima, tira-se que o valor de R2 vale 3,3[kOhm].

A tensão já regulada serve para alimentar o kit Mbed (trabalha entre 4,5[V] e 14,0[V]

segundo a fabricante), e passa por um diodo com queda de 0,7[V] para alimentar o modem

Telit (que opera entre 3,6[V] e 4,2[V]). Entre o Mbed e o Telit há alguns transistores

responsáveis por realizar a transição de sinal da comunicação serial de um módulo para o

outro.

17

A função da placa é poder usar o modem sem o kit, e integrar os dois módulos para

que possa ser instalado em algum veículo e dar continuidade ao projeto. Optou-se por manter

o kit de desenvolvimento Mbed na placa, por uma questão de facilidade de projeto e agilidade

no desenvolvimento. Figuras do projeto da placa são mostradas abaixo.

Figura 9 – Placa de circuito impresso, vista superior

18

Figura 10 – Placa de circuito impresso, vista inferior

19

2.2 FIRMWARE

Segundo Sloss, Symes e Wright (ARM system developer's Guide, 2004), o firmware é

um programa totalmente embarcado de baixo nível, que providencia uma interface entre

hardware e a aplicação. Está alocada na memória ROM do dispositivo e é sempre executada

quando a força de alimentação é aplicada ao equipamento embarcado. O firmware pode se

manter ativo após a inicialização do sistema e suportar operações básicas para o sistema. Uma

das principais funções do firmware é providenciar um mecanismo estável para carregar e

iniciar um sistema operacional.

No projeto, não há necessidade da utilização de um sistema operacional embarcado,

logo o firmware é responsável por comandar todas as funções do rastreador. O firmware foi

desenvolvido em C/C++ devido à grande difusão desta linguagem de programação e por ser

esta a linguagem usada pelo ambiente de desenvolvimento do Mbed.

Um fluxograma simplificado do firmware encontra-se abaixo.

20

Figura 11 – Visão geral do firmware

O bloco “Boot do programa” contém apenas inicialização de variáveis e definição de

parâmetros e classes que serão usados durante o programa.

Já os blocos “Inicialização do GPS”, “Inicialização do GPRS” e “Aquisição de dados

do GPS” são compostos por vários comandos AT a serem enviados. Seguem na figura a

seguir o fluxograma de cada bloco e uma parte do código onde é enviado um dos comandos

AT.

21

Figura 12 – Fluxograma de três blocos do programa

void command::CPIN() { //Envia"AT+CPIN?" do{ send ("AT+CPIN?\r"); }while (!receive(READY)); //enquanto não receber "READY" }

Codigo 1 – Envio de comando para verificar o SIMCard.

2.2.1 A Máquina de Estados:

Todos os comandos AT são respondidos por alguma palavra ou frase pelo modem,

como mostrado no Anexo I. A resposta de todos os comandos usados podem ser filtradas por

algumas palavras-chaves. São elas:

22

• OK: O comando é válido e foi enviado com sucesso;• CGREG: palavra-chave da resposta ao comando AT+CGREG? (vide anexo I);• READY: palavra-chave da resposta ao comando AT+CPIN? (vide anexo I);• CONNECT: Resposta vinda quando o modem se conecta ao servidor;• GPRS 0 ou 1: Resposta quando o modem está (GPRS 1) ou não (GPRS 0) conectado à

rede GPRS;• ERROR: Palavra-chave quando ocorre algum erro no comando enviado;

Para o microcontrolador saber qual resposta foi enviada pelo modem, foi

implementada uma máquina de estados que analisa todas as letras recebidas pela comunicação

serial.

Por exemplo, quando enviamos o comando “AT” (testa conexão com o modem,

semelhante a um “Hello”), espera-se que o modem responda um “OK”. A máquina de estados

permanece no estado inicial onde espera o primeiro caractere chegar pela serial, que pode ser

um “O”, um “C”, um “R”, um “G” ou um “E”. Supondo que tenha recebido a letra “O”, a

máquina de estados irá para um próximo estágio, onde irá esperar pela letra “K”. Se não

receber um “K”, a máquina de estados reinicia e volta para o estado inicial. Se receber a letra

“K”, um indicador que diz ao firmware “foi recebido um OK” é enviado, e o programa

continua. Dessa forma, as demais palavras-chaves são recebidas, qualquer outra informação é

descartada.

Para se conectar ao servidor, o modem acessa uma página na web, para onde são

enviados os dados como parâmetros no próprio endereço da página. Caso a conexão não possa

ser estabelecida, o rastreador armazena os dados para enviar na próxima tentativa de conexão.

Atualmente o rastreador consegue armazenar mais de 400 coordenadas na memória.

Após enviar os dados ou gravá-los na ROM, o dispositivo entra em modo sleep para

esperar o momento de envio da próxima coordenada.

23

Para testes, foi usado o programa HyperTerminal para Windows, onde pode-se

verificar todos os comandos enviados e as respostas vindas do protótipo. As imagens abaixo

mostram o rastreador enviando uma coordenada válida para o servidor.

Figura 13.a – Comandos enviados pelo rastreador

24

Figura 13.b – Continuação dos comandos enviados pelo rastreador

25

2.3 SERVIDOR

Atualmente o servidor apenas recebe os dados vindos do rastreador e os exibe em uma

página na internet. Pode-se verificar o funcionamento acessando o website

http://www.flashunderground.com . Para isso, as funções são separadas em duas partes:

• O rastreador envia as coordenadas através de um site em PHP, passando os dados

como parâmetros que serão recebidos pelo servidor. Estes dados são então

armazenados em um banco de dados, e o rastreador se desconecta do servidor;

• A outra parte acontece quando o usuário acessa a página na internet. Desta vez a

página é construída usando HTML, PHP e JavaScript com a API do GoogleMaps. O

mapa é carregado na página HTML, e o código em PHP acessa as coordenadas

gravadas no banco de dados mencionado acima, e então as envia para a API, que é

responsável por inserir os elementos que são vistos na tela e como o mapa de

comporta conforme o usuário navega pelo mapa.

A página HTML é responsável por chamar os arquivos JavaScript que serão usados e

definir o estilo da página usando CSS. Segue o código abaixo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>LocBus</title> <link type="text/css" href="css/style.css" rel="stylesheet" media="all" /> <script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></script> <script type="text/javascript" src="js/map.js"></script>

26

http://www.flashunderground.com/teste/cap1.html

• Regras Gerais:

- Acesso Livre (sem pagamentos): A implementação usando a API deve ser acessível

aos usuários livre de cobranças, assinaturas pagas, ou outras formas de acesso restrito

por pagamentos. Esta regra vale para todo o conteúdo implementado agora e para

qualquer conteúdo que venha a ser vinculado no futuro.

- Acesso público (sem firewall ): A implementação usando a API não deve operar

somente atrás de um firewall, ou somente dentro de uma rede interna (exceto durante

fase de testes e desenvolvimento), ou dentro de uma comunidade fechada (por

exemplo, acesso somente a usuários convidados).

• Exceções:

- Versão Enterprise do Google: As regras das sessões anteriores não se aplicam caso

se obtenha a versão Enterprise do Google ou que seja concedida uma permissão

escrita da Google.

- Aplicações Móveis: A regra de “Acesso Livre” descrita anteriormente não se aplica

caso esteja se desenvolvendo aplicações para aparelhos móveis que possam ser

vendidos por uma taxa através de uma loja online e que possa fazer o download da

aplicação para uma aparelho que consiga acessar essa loja.

• Exemplos:

- A aplicação pode solicitar que usuários realizem um login, porém não pode cobrar

para isso;

- Pode ser cobrada uma taxa para a sua aplicação caso esta esteja disponível para

download para um aparelho rodando Android através da Android Market.

Se forem recebidas mais de 2.500 solicitações de geocódigo feitas por um mesmo

endereço IP em um período de 24 horas, ou se as solicitações forem enviadas com muita

28

frequência por um único endereço IP, o geocodificador da Google Maps API começará a

responder com o código de status 620. Se o uso excessivo do geocodificador continuar, o

acesso ao geocodificador da API do Google Maps a partir desse endereço IP pode ser

bloqueado permanentemente.

Ao usar uma das classes de geocodificação da API do Google Maps, as solicitações

são feitas pelo navegador da web do usuário e são contabilizadas na cota do endereço IP do

usuário. Isso significa que o uso excessivo por parte de um usuário não terá impacto em

outros usuários do site. No entanto, se muitos usuários acessarem as APIs do Google Maps

por meio de um único proxy, eles compartilharão a cota do endereço IP do proxy.

Quando as solicitações do geocodificador são feitas com o Serviços de geocodificação,

elas são contabilizadas na cota do endereço IP do sistema que está fazendo a solicitação

HTTP. Porém, não existe um limite para o número de visualizações de páginas de mapas no

site.

O custo estimado para se adquirir uma licença quando é ultrapassado o limite de

geocodificações é de R$32.000,00 por ano.

2.3.2 MySQL:

De acordo com Valade, Janet (PHP and MySQL Web Develpment, 2008), muitas

páginas web dinâmicas necessitam de um banco de dados. Este banco contém informações

que serão mostradas ao usuário pela página, ou irá guardar informações provenientes do

usuário, e em várias aplicações, fará as duas coisas.

O MySQL, o mais popular banco de dados para ser usado em páginas web, foi

desenvolvido para ser rápido e pequeno, especialmente para sites. Este banco é muito famoso

em sites escritos em PHP.

29

http://code.google.com/apis/maps/documentation/geocoding/#StatusCodes

O PHP e o MySQL trabalham bem juntos, pois o PHP tem funções designadas

especificamente para se comunicar com o MySQL. As funções se conectam ao banco e

enviam as queries.

2.3.2.1 Comunicando com MySQL

Toda a interação com o banco de dados é feita passando mensagens para o servidor

MySQL. A comunicação é feita usando Structured Query Language (SQL), que é uma

linguagem padrão interpretada pela maioria dos bancos de dados.

2.3.2.2 Construindo SQL Queries

SQL é composta, na maioria, por palavras em inglês, colocadas em frases muito

similares à língua inglesa. As queries são ações (verbos) que dizem ao MySQL o que deve ser

feito, tais como: CREATE, DROP, INSERT, SELECT, UPDATE, DELETE. Por exemplo:

SELECT lastName FROM Member

Essa query retorna todos os "lastNames" (sobrenomes) armazenados na tabela

"Member".

As queries podem se tornar mais complexas como esta:

SELECT h.DataHora as DataHora, h.latitude as latitude, h.longitude as longitude, h.DynamapID as DynamapID, asText(rcc.ogc_geom) as coordenadas

FROM HistoricoPosicoes h INNER JOIN RUAS_CURITIBA_COLOMBO rcc

ON rcc.DYNAMAP_ID = h.DynamapIDEssa query retorna a hora, latitude, longitude e dynamapID da tabela

“HistoricoPosicoes” e as coordenadas da tabela “RUAS_CURITIBA_COLOMBO” para o

dynamap pertencente ao HistoricoPosicoes

30

2.3.3 PHP:

Php é uma linguagem de script designada especificamente para o uso na Web,

contendo recursos para auxiliar na programação de tarefas necessárias para desenvolver

aplicações dinâmicas. É uma linguagem usada em mais de 20 milhões de domínios, e sua

popularidade continua crescendo. A sintaxe do php é similar à do C, ou até mesmo mais

simples, já que não inclui alguns conceitos mais difíceis do C, retirado de Valade, Janet (PHP

and MySQL Web Develpment, 2008).

2.3.3.1 PHPMyAdmin:

PhpMyAdmin é uma ferramenta livre escrita em PHP com o intuito de ajudar na

administração do MySQL na internet. A ferramenta suporta uma larga faixa de operação com

MySQL. As mais freqüentes operações usadas são suportadas por uma interface ao usuário (o

banco de dados, tabelas, campos, relações, index, usuários, permissões, etc), enquanto ainda

tem a opção de executar qualquer query que desejar usando uma janela especial.

Esta ferramenta foi usada para estruturar o banco de dados, criando tabelas que

são úteis à aplicação, tais como: tabela que armazena as rotas do ônibus, tabela que armazena

os pontos dos ônibus e a qual linha pertence, tabela para guardar a velocidade média de cada

linha em cada trecho da rota do ônibus; e também para inserir dados nos campos das tabelas,

como por exemplo, as coordenadas de cada ponto da linha, e os trechos que pertencem a cada

linha.

2.3.4 Sistema de Informação Geográfico (GIS):

Um GIS (Geographic Information System) é um sistema computacional capaz de

capturar, armazenar, analisar, e mostrar informações geográficas, que são dados identificados

de acordo com uma localização. O poder de um GIS vem de poder relacionar informações

31

diferentes em um contexto espacial e pesquisar uma conclusão sobre este relacionamento. A

maioria das informações que se têm sobre o mundo contem referência à uma localização,

colocando esta informação em algum ponto do globo. Por exemplo: Quando uma informação

sobre chuva é coletada, é importante saber onde a chuva está localizada. Isto é feito usando

um sistema de referenciamento de local, como longitude e latitude, e talvez elevação. A

comparação da informação da chuva com outras informações, como a localização dos

pântanos de um lugar, pode mostrar que certos pântanos recebem pouca chuva. Este fato

indica que estes pântanos estão mais propensos a secar, e esta análise pode ajudar

pesquisadores a tomarem a decisões apropriadas de como os humanos devem interagir com o

pântano. Um GIS, também pode revelar novas informações importantes que levam a uma

melhor tomada de decisão.

Várias disciplinas podem se beneficiar de uma tecnologia GIS. Um mercado ativo de

GIS resultou em queda de preços e melhorias contínuas no hardware e software de

componentes GIS. Esse desenvolvimento resultará em um uso muito mais largo da tecnologia

através da ciência, governo, negócios, e indústria, com aplicações incluindo saúde pública,

mapa de crime, defesa nacional, desenvolvimento sustentável, recursos naturais, arquitetura,

planejamento regional e comunitário, transporte e logística. GIS também está divergindo em

serviços baseados em local (LBS - Location-Based Services). LBS permitem aparelhos

móveis com GPS mostrar a localização em relação a restaurantes, postos de combustível,

amigos, carros de polícia ou repassar a posição de volta para uma central para mostrar ou

realizar outro processamento. Estes serviços continuam em desenvolvimento com um

aumento na integração da funcionalidade do GPS com o aumento de eletrônicos móveis mais

poderosos (cell phones, PDA's, laptops).

32

Recentemente houve uma explosão de aplicações envolvendo mapas na web, como o

Google Maps e Bing Maps. Estes websites dão ao público acesso a grande quantidade de

dados geográficos.

Alguns deles, como o Google Maps e o OpenLayer, expõem uma API que possibilita ao

usuário criar aplicações customizadas. Esses toolkits normalmente oferecem mapas de ruas,

imagem aérea/satélite, geocodificação, buscas e funcionalidade de rota. Os serviços de mapa

na web começaram a adotar características mais comuns em GIS.

2.3.5 Geocode Reverso, DynamapID's e Linestring :

Geocode reverso é o processo de conseguir detalhes do endereço a partir de uma

coordenada expressa na forma de latitude-longitude. Assim, dada uma certa coordenada, é

possível saber a rua a qual aquela coordenada pertence, o CEP, a quadra e entre quais

números da rua o ponto se encontra.

Muitas vezes as coordenadas do GPS não são exatamente no ponto original, há um

erro de alguns metros embutido em algumas medições. A função do Geocode reverso, neste

caso do projeto, é para descobrir qual a rua mais próxima daquele ponto, e então deslocar o

ponto original para esta nova coordenada, tentando manter coerente as informações que são

apresentadas na tela, como por exemplo, do ícone do ônibus sempre estar dentro da linha da

rota desejada, e não em outras ruas ou apontando para o telhado de residências em volta da

linha do ônibus.

Os DynamapID's são identificadores para cada quadra de cada rua presente na

cidade de Curitiba e Região Metropolitana. Esses identificadores são únicos e usados para

criar as rotas dos ônibus ao longo da cidade. Assim, cada consulta ao banco de dados que

procure uma rota, um ponto de ônibus ou a última posição do veículo, irá retornar um ou mais

33

DynamapID's que serão usados para realizar estimativa de tempo e também para apresentação

no mapa.

Cada DynamapID é composto por coordenadas que dizem onde a quadra começa e

termina. Em caso de quadras curvas, ou que seja formada por segmentos, mais coordenadas

são adicionadas entre o início e o final, representando de forma precisa as ruas da cidade.

O Geocode reverso implementado para o projeto verificar qual DynamapID

pertencente à linha do ônibus está mais perto da coordenada apontada pelo rastreador. Para

fazer este cálculo, calcula-se a distância do ponto dado pelo rastreador a todas os coordenadas

de todos os DynamapID's da rota do ônibus, a menor distância vai determinar a qual

DynamapID aquele ponto pertence. O cálculo foi implementado usando-se a fórmula de

Haversine, que será explicada e demonstrada mais adiante, na sessão 2.3.6 – Previsão de

Horário.

LineString é um tipo de dado que contém as coordenadas dos segmentos, definidos

por ada par de coordenadas consecutivas, ou seja, é uma curva com interpolações lineares

entre os pontos, porém, se linestring constituir de apenas duas coordenadas, será um areta.

Estes dados normalmente representam ruas em mapas urbanos ou rios em mapas de terreno.

2.3.6 Estrutura do servidor:

Como dito anteriormente o servidor é composto pela parte responsável em coletar

dados provenientes do rastreador e outra parte que faz a interação com o usuário. A figura

abaixo ilustra o funcionamento do servidor.

34

Figura 14 – Fluxograma do Servidor

2.3.6.1 Index.php:

O index.php é responsável por ser a ponte de acesso entre o usuário e a aplicação. Este

arquivo é composto por tags HTML que estruturam a página inicial e chamam dois outros

arquivos: jquery.js e map.js, ambos escritos em javascript.

2.3.6.2 Jquery.js:

Este arquivo é uma biblioteca rápida e concisa do JavaScript que simplifica o

documento HTML, a manipulação de eventos, animação e interações com o Ajax para um

desenvolvimento web mais rápido.

35

2.3.6.3 Map.js:

Este arquivo faz a interação com a API do GoogleMaps, fazendo o download do

mapa e configurando as propriedades de apresentação do mesmo. Além disso, este arquivo é

responsável por inserir os ícones no mapa, que são figuras da pasta “imagens”, e também

coleta dados de outros três arquivos. Como pode ser visto na figura 10 acima.

2.3.6.4 GetRota.php:

Este arquivo é chamado pelo map.js para retornar os DynamapID's (quadras) da rota

a qual é desejada. Para isto, é utilizada uma função que se conecta ao banco de dados e

executa uma query de seleção, tal como esta:

SELECT Ordem,DynamapID FROM Itinerario WHERE CodigoLinha=1 ORDER BY

Ordem DESC

Onde são selecionados os DynamapsID's e a ordem que eles compõem a linha, da

tabela “Ininerário” onde o código da linha é “1” (neste caso, a linha Santa Cândida/Capão

Raso). Estes dados são ordenados de forma decrescente e então são retornados para o arquivo

GetRota.php através de uma matriz de dados. O php então constrói um objeto que pode ser

lido pelo javascript e devolve este objeto para o arquivo map.js, que será responsável por

mostrar a rota no mapa.

2.3.6.5 GetBus.php:

O funcionamento deste arquivo é semelhante ao anterior, porém a query que é passada

ao MySQL seleciona outros campos de outra tabela, como por exemplo:

SELECT * FROM HistoricoPosicoes WHERE pos_id = 1

O banco irá devolver ao GetBus.php todos os campos (Hora, Data, Latitude, Longitude,

Velocidade) da tabela “HistóricoPosições” onde o identificador do ônibus é 1 (neste caso, a

36

linha Santa Cândida/Capão Raso). Da mesma forma como explicado anteriormente, o php irá

encapsular estas informações em um objeto que será enviado ao javascript responsável por

exibir a última posição do ônibus no mapa.

2.3.6.6 GetPontos.php:

Segue a mesma ideia apresentada nos arquivos acima, onde são selecionadas as

coordenadas dos pontos para serem apresentadas no mapa pelo arquivo map.js. Porém nesta

tabela há, além das coordenas, campos que serão usados para realizar a estimativa do horário

dos ônibus.

2.3.6.7 GetSpeed.php:

Este arquivo tem a finalidade de devolver todas as velocidades armazenadas no

banco de dados associadas aos DynamapID's que fazem parte da rota de ônibus. Estas

velocidades são usadas para realizar a estimativa de tempo do veículo chegar aos pontos de

sua rota.

2.3.6.8 GetRotaID.php:

Também usado para realizar a estimativa de tempo, este arquivo retorna do banco o

comprimento de todos os DynamapID's que fazem parte da rota.

2.3.6.9 MySQL:

O MySQL é o banco usado para guardar informações tais como: rotas, pontos,

velocidades, posições, distâncias, etc. Como explicado anteriormente, pode-se acessar os

37

dados do banco através de queries, que são comandos que dizem ao banco o que deve retornar

e como retorná-los.

O banco é organizado em tabelas, onde são inseridos os dados conforme necessários.

2.3.6.10 Coord.php:

Este arquivo é responsável por coletar as informações provenientes do rastreador,

realizar o geocode reverso e gravá-los no banco de dados, como foi descrito anteriormente na

sessão 2.3.4 Geocode Reverso e os DynamapID's.

2.3.6.11 Classes.php:

No arquivo classes.php são definidas duas classes usadas que auxiliam na elaboração

de rotas e do geocode reverso. São elas:

• Classe Ponto: Usada para armazenar a latitude e longitude das coordenadas.

Utiliza um construtor para separar a coordenadas do resto da string que o

banco retorna após uma consulta;

• Classe Line: Relaciona um DynamapID com um ponto (classe descrita

anteriormente), usada para compor as rotas e fazer o geocode reverso.

Também será útil para realizar a estimativa de tempo.

Abaixo segue uma figura da aplicação mostrando uma rota de ônibus com suas

paradas e a localização do veículo.

38

Figura 15 – Sistema rastreando um veículo em uma rota de ônibus

2.3.7 Previsão de Horário

Um dos diferenciais do projeto é justamente um estimativa de quanto tempo o ônibus

demorará para chegar nos pontos da linha. Para realizar esta previsão, são necessários dados

de velocidade média do veículo e a distância ao longo de todos os DynamapID's pertencentes

à rota de ônibus.

O cálculo do tempo estimado vem de uma equação de cinemática da física (retirada

de Resnick Walker, Halliday, “Fundamentos de Física I – Mecânica”, 7ª Edição, Editora LTC,

p. 19) :

∆x = v * t → t = ∆x/v

39

Onde “t” é o tempo em segundos, “v” é a velocidade média no trecho em questão e

“∆x” é o comprimento do trecho do DynamapID considerado. Aplicando esta equação para

todos os trechos que compõem a rota entre o DynamapID do ônibus e da parada considerada,

e somando os tempos estimados para o veículo percorrer cada um desses trechos, obtém-se

uma previsão de tempo que o veículo necessitará para chegar na parada desejada.

2.3.7.1 Cálculo da distância:

O MySQL possui suporte à algumas funções que utilizam dados tipo geometry, que

são dados de GIS. Estas funções podem ser categorizadas como:

• Funções para “Points”: Retornam a coordenada X ou Y de um determinado ponto;

• Funções para “LineStrings”: Retornam o ponto de início e final de uma determinada

LineString, a quantidade de pontos que compõe a LineString, e também o

comprimento da LineString;

• Funções para “MultiLineString”: Retornam comprimento e se a MultiLineString é

fechada ou aberta;

• Funções para “Polygons”: Retornam a área do polígono e LineStrings que o compõe;

• Funções para “MultiPolygons”: Idem ao acima.

Dentre todas as funções, foi usada apenas a função “Glength(ls)” para LineString.

Esta função recebe como parâmetro uma LineString e retorna o comprimento dela em graus,

ou seja, retorna a diferença entre o ponto (latitude, longitude) inicial e o final, porém esta

distância não é em linha reta, e sim seguindo todos os pontos que a LineString possui, que é

muito útil em casos de trechos em curvas.

Deve-se converter o valor retornado da função “Glength” de graus para metros.

Devido ao planeta ser esférico, não é possível usar a trigonometria Euclediana, pois esta é

40

relacionada a figuras planas, se fosse usada iria retornar a distâncias entre os pontos, porém

com um “túnel” ligando os dois pontos em linha reta. É necessário calcular a distância pela

superfície do planeta, como o comprimento de um arco em uma esfera. Um dos modos de se

calcular esta distância é pela lei de Haversine, que são fórmulas trigonométricas usadas por

navegadores no passado. O Versine (ou versed sine) de um ângulo A é 1-cos(A). O Haversine

é metade de um Versine, ou (1-cos(A))/2. A fórmula consiste no seguinte:

Suponhamos o planeta Terra como uma esfera de raio R (figura abaixo), com dois

pontos dados em coordenas esféricas (latitude, longitude) P1(lat1, long1) e P2(lat2, long2),

então a fórmula de Haversine (retirado de SINNOT, R. W., "Virtues of the Haversine," Sky

and Telescope, vol. 68, no. 2, 1984):

• ∆lat = lat2 – lat1

• ∆long = long2 – long1

• a = (sen(∆lat/2))² + cos(lat1) * cos(lat2) * (sen(∆long/2))²

• c = 2 * atan(sqrt(a)/sqrt(1 – a))

• d = R * c

O resultado de “c” é a distância percorrida na superfície da esfera em radianos, “a” é

o quadrado da metade do comprimento de corda (linha reta) que liga os dois pontos, e o

resultado de “d” (distância) tem a mesma unidade de R. O valor de c também é o valor

retornado pela função “Glength”, porém dado em graus. Para converter de graus para radianos

basta multiplicar o valor desejado por pi/180°.

41

Figura 16 – Distância entre dois pontos geográficos

A definição histórica de uma “milha náutica” é “um minuto do arco da superfície

terrestre”. Como a superfície não é uma esfera perfeita, esta definição é ambígua. No entanto,

no Sistema Internacional (SI), o valor do comprimento de uma minha náutica é de 1,852km.

Logo, a circunferência da superfície terrestre pode ser expressa por:

360 (graus) * 60 (minutos/grau) * 1,852 (km/minuto) = 40003,2km

Como a circunferência de um círculo é dada por C = 2 * pi * R, tira-se que o valor do

raio da Terra é de:

R = 6367km

Na demonstração da fórmula, suponha uma esfera de raio unitário. A distância deve

ser multiplicada por R, que é o raio da Terra.

Inicia-se com a fórmula calculando a distância em linha reta entre dois pontos

situados sobre o círculo unitário separados por um ângulo theta, como mostra a figura abaixo.

42

Figura 17 – Distância entre dois pontos no círculo unitário, redesenhado de [13]

“O” é o centro do círculo, “A” e “B” estão sobre o círculo, então o segmento AB é a

distância em linha reta entre os dois pontos. Se o ângulo AÔB = theta, então o ângulo AÔC =

theta/2, e OC é perpendicular ao segmento AB. O segmento AC pode ser calculado como AC

= sen(theta/2), portanto o segmento AB mede 2 * sen(theta/2).

Agora considerando a figura da esfera abaixo, com centro em “O” e considerando R =

1 (esfera unitária), os pontos de interesse são A (lat1, long1) e B (lat2, long2), que passam por

duas longitudes diferentes que ligam o polo Norte com a linha do Equador.

43

Figura 18 – Esfera unitária para demonstração da fórmula de Haversine,

redesenhado de [13]

“A” e “B” são os vértices opostos de um trapézio isósceles, ACBD, com os vértices

adicionais C (lat2, long1) e D (lat1, long2). As linhas retas que ligam AC e BD não são

mostradas, apenas os segmentos AD e CB do trapézio podem ser visualizadas na figura

acima.

Se forem ligados os pontos AO e CO (não mostrado), o ângulo AÔC é a diferença

entre lat 1 e lat2, ou ∆lat. O comprimento do segmento AC é, como mostrado anteriormente, 2

* sen(∆lat/2). O segmento BD tem o mesmo comprimento.

Os pontos E e F são onde a long1 e long2, respectivamente, encontram-se com a linha

do Equador. Portanto o comprimento de EF é 2 * sen(∆long/2).

Os pontos A e D estão sobre o círculo de latitude constante lat1. O raio deste círculo é

cos(lat1). Pode-se verificar isto desenhando uma perpendicular do ponto A ao segmento OE,

encontrando OE no ponto G. O ângulo AÔE é lat1, portanto o segmento OG = cos(lat1), que é

o mesmo comprimento do raio do círculo de lat1 no ponto A.

44

Portanto, o comprimento do segmento AD é 2 * sen(∆long/2) * cos(lat1).

Similarmente, o comprimento do segmento CB é 2 * sen(∆long/2) * cos(lat2).

Voltando para a figura em duas dimensões, agora é possível calcular a distância da

diagonal (segmento AB) do trapézio isósceles da figura a seguir.

Figura 19 – Trapézio isósceles retirado da esfera unitária, redesenhado de [13]

O comprimento de CH, onde AH é perpendicular ao segmento CB, é (CB – AD)/2.

Pelo teorema de Pitágoras:

AH² = AC² – CH² = AC² – (CB – AD)²/4

O comprimento de HB é (CB + AD)/2. Usando o teorema de Pitágoras novamente:

AB² = AH² + HB²

AB² = AC² – (CB – AD)²/4 + (CB + AD)²/4

AB² = AC² + CB * AD

Agora pode-se substituir os valores obtidos na figura esférica para os segmentos AC,

CB e AD:

AB² = 4 * (sen²(∆lat/2) + cos(lat1) * cos(lat2) * sen²(∆long/2))

45

O resultado intermediário “a” é o quadrado da metade do comprimento entre os

pontos:

a = (AB/2)²

a = sen²(∆lat/2) + cos(lat1) * cos(lat2) * sen²(∆long/2)

O último passo é encontrar o ângulo AÔB que corresponde ao comprimento AB. A

fórmula do arctan pode ser encontrada nesta figura:

Figura 20 – Triângulo para determinar o ângulo AÔB, redesenhado de [13]

Como “a” é o quadrado da metade do comprimento AB e AC é metade do

comprimento AB, então AC = sqrt(a). Aplicando Pitágoras:

OC = sqrt(OA² – AC²)

OC =sqrt (1 – a)

46

Onde pode-se tirar que tan(AÔC) = sqrt(a)/sqrt(1-a). Logo a variável “c”, que é o

comprimento de AB em radianos:

c = 2 * AÔC

c = 2 * arctan(srqt(a)/sqrt(1-a))

Como todos os cálculos levaram em consideração uma esfera de raio igual a 1, para

conhecer o comprimento de um arco formado pelo ângulo c (=AÔB) com um raio qualquer,

basta multiplicar “c” por R, portanto:

d = c * R

Demonstrando, assim, a lei de Haversine usada para calcular a distância entre dois

pontos dados suas latitudes e longitudes.

Para mostrar que os valores calculados por esta fórmula estão corretos, seguem duas

imagens: a primeira mostra o valor encontrado pelo sistema LocBus, entre o ônibus e o ponto;

e a segunda através de uma ferramenta que mede a distância entre duas coordenadas fornecida

no Google Maps. Note que o valor da distância nas duas figuras são iguais.

47

Figura 21 – Distância medida pelo sistema LocBus

48

Figura 22 – Distância medida no GoogleMaps

2.3.7.2 Aquisição da velocidade média:

O próximo passo é conseguir a velocidade média de um trecho específico. Quando o

rastreador envia as coordenadas para o servidor, entre os dados está a velocidade que o

veículo se encontra naquele momento. Esta velocidade é então gravada em uma tabela no

banco de dados através do arquivo coord.php.

Toda vez que é necessário calcular a previsão de tempo de um trecho, o arquivo

getSpeed.php acessa o banco de dados e recolhe todas as velocidades dos trechos da rota.

Como a previsão está no cálculo de um MRU, todas essas velocidades são consideradas

velocidades médias do trecho considerado. Logo, calcula-se uma velocidade média total,

49

fazendo a média da soma de todas as velocidades associadas ao trecho em específico.

Portanto:

Vmed = Σv / n

Onde Vmed é a velocidade média total, n é o número de dados associados a aquele

trecho e Σv é a soma das velocidades dos n elementos.

2.3.7.3 Cálculo do tempo estimado:

Uma vez conhecidas a distância “d” e a velocidade média “Vmed”, é possível calcular

o tempo estimado médio para o veículo passar pelo trecho usando a fórmula já apresentada

anteriormente:

t = d / Vmed

A soma dos n trechos da rota dá a estimativa do tempo total necessário para realizar o

percurso.

2.3.7.4 Variáveis Periódicas:

Alguns fenômenos que ocorrem frequentemente podem alterar os resultados. Porém o

sistema foi projetado levando em considerações tais fatos e tende a reduzir o impacto desses

no resultado final. São elas:

• Semáforos: Apesar de poder saber com antecedência onde estão os

semáforos de uma determinada linha de ônibus, não é possível prever se

este encontrar-se-á “vermelho” ou “verde”. Um veículo que trafega pela

sua rota com todos os semáforos fechados, com certeza irá realizar o

percurso mais rápido do que outro veículo que realiza a mesma rota, porém

com todos os semáforos fechados. Esse efeito tende a ser refletido na

50

velocidade média do trecho que contém o semáforo, que será menor que a

dos demais trechos. Isso acontece pois várias informações de velocidades

são passadas para o banco diariamente sobre aquele trecho. Logo, uma

certa quantidade dessas informações virão com velocidade de 0 (zero) km/

h, pois o veículo estará parado no semáforo. Quanto mais tempo esse

semáforo persistir fechado, maior serão os casos de velocidade zero, e isso

faz com que a velocidade média total desse trecho diminua.

• Horário de “pico” (maior movimento): O horário que consiste entre

06:00hrs – 08:00hrs e 17:00hrs – 20:00hrs é o horário em que grande parte

da população vai e volta do trabalho, o que gera trânsito e muitas pessoas

dependendo do transporte coletivo, o que acarreta em ônibus mais tempo

parados nos pontos. Assim como semáforos, esses horários geram muito

atrasos para determinados ônibus (que enfrentam congestionamento

pesado) enquanto outros encontram a rota mais livre e com o trânsito

fluindo mais normalmente. Levando isso em consideração, o sistema tende

a filtrar as velocidades médias pelo horário. Se, por exemplo, um usuário

acessa a aplicação às 17:38hrs, será pesquisado no banco de dados todas as

velocidades referentes ao horário entre às 17:00hrs e 18:00hrs, que

provavelmente terão suas velocidades médias menores do que os horários

entre 10:00hrs e 11:00hrs por exemplo, devido ao trânsito intenso.

Realizando esses filtros de posição (trechos que contém algo que faça o ônibus parar

ou reduzir bastante a velocidade) e de tempo (horários que têm maior congestionamento), o

sistema é capaz de adaptar-se a esses fenômenos estimando um tempo mais realista

independentemente de acontecimentos diários.

51

2.4 CUSTOS DO PROJETO

Esta sessão tem o objetivo de estimar o custo inicial para desenvolver o projeto para

a cidade de Curitiba e Região Metropolitana, e também a estimativa do custo de manutenção

de um sistema desse porte. Devido a algumas dificuldades de se conseguir determinadas

informações, os custos apresentados aqui são apenas estimativas para que possa servir de base

para futuras análises.

2.4.1 Custo do Rastreador

A tabela 1 abaixo mostra todos os componentes do rastreador junto com o preço

pesquisado na loja online da Mouser (www.mouser.com) para duas placas e o preço total para

uma placa:

Item Quantidade Preço/Uni (U$)

Preço Total/Uni (U$)

Preço/Milhar (U$)

Preço Total/Milhar (U$)

BC846 25 0,11 2,75 0,06 1,5B340A 2 0,86 1,72 0,36 0,72LM2546S 2 2,66 5,32 1,22 2,44KLDHCX-0202-A-LT 2 1,18 2,36 0,87 1,74Resistor – 220 25 0,016 0,4 0,01 0,25Resistor – 470 10 0,1 1 0,076 0,8Resistor – 1k 10 0,1 1 0,076 0,8Resistor – 1.2k 5 0,64 3,2 0,42 2,1Resistor – 2.2k 10 0,12 1,2 0,05 0,5Resistor – 4.7k 10 0,12 1,2 0,05 0,5Resistor – 10k 30 0,1 3 0,08 2,4Resistor – 47k 10 0,28 2,8 0,11 1,1max232ECD 2 1,14 2,28 0,54 1,08LD1117S33 2 0,51 1,02 0,34 0,68LPC1768 2 9,48 18,96 5,55 11,1Indutor 2 Oscilador – 12MHz 2 2,89 5,78 1,73 3,46Cristal – 32.768KHz 2 0,99 1,98 0,48 0,96Led – Verde 25 0,1 2,5 0,07 1,75Capacitor – 100n 40 0,05 2 0,01 1,6Capacitor – 10u 30 0,2 6 0,1 3Capacitor Elet. - 330u 4 Capacitor – 1u 10 0,09 0,9 0,05 0,5

52

http://www.mouser.com/

Capacitor – 18p 5 0,15 0,75 0,06 0,3 SUB-TOTAL (2 Placas) 68,12 39,28SUB-TOTAL (1 Placa) 34,06 19,64 TELIT (GPS+GPRS) 1 69 69 62 TOTAL (1 Placa)* 103,06 81,64*Preço apenas dos componentes eletrônicos, não inclusos cabos, caixas e conectores.

Tabela 1 – Preço dos componentes do rastreador

Como pode ser observado na tabela, o preço aproximado de um rastreador chega a

U$81,64, caso sejam adquiridos mil rastreadores. Usando a cotação do dólar comercial de

R$1,59 do dia 21/06/2011 retirado do site de economia da UOL

(http://economia.uol.com.br/cotacoes), o valor da placa é de R$129,80.

2.4.2 Google Maps Premier

Caso seja necessária uma licença para o uso da API do Google Maps devido alguma

regra vigente nos termos de serviço [10] (com algumas citações já vistas na sessão 2.3.1 –

API Google Maps), o custo é de R$32.000,00 por ano. Porém o projeto realiza o próprio

Geocode e o usuário não precisa fornecer qualquer tipo de pagamento para a utilização do

aplicativo, então, a princípio, não é necessária uma versão paga da API de mapas.

2.4.3 Frota de ônibus e Custo Inicial

A frota de ônibus de Curitiba e Região Metropolitana foi estimada em torno de 4236

veículos. Pode-se verificar no site oficial da URBS [16], que no final do ano de 2010 havia

353 linhas de ônibus. Estimando uma média de 12 (doze) ônibus por linha nos horários de

maior movimento, chega-se a um total de 4236 veículos.

Com o preço do rastreador cotado em R$129,80 e sendo um rastreador por veículo da

frota de ônibus, o custo inicial estimado do projeto é de :

53

http://economia.uol.com.br/cotacoes

129,80 * 4236 = R$549.865,00

2.4.4 Cálculo e custo de uso de banda mensal do chip GPRS

O plano adquirido para o chip com serviço de GPRS é limitado em 2MB por mês.

Para calcular se este plano é suficiente para as necessidades de rastreamento, estima-se que

cada veículo opera, em média, 12 horas por dia. Uma mensagem do rastreador para o servidor

tem 40bytes de comprimento adicionados de 20bytes do cabeçalho TCP, gerando um total de

60bytes de fluxo para o servidor a cada transmissão. O envio de coordenadas é realizada a

cada minuto, logo podemos estimar a banda mensal consumida pelo rastreador da seguinte

maneira:

12hrs/dia * 60min/hr * 30dias/mês * 60bytes/minuto = 1,296MB/mês

Mostrando, assim, que o plano de 2MB mensal é o suficiente para o funcionamento

normal do rastreador. Para que estoure o limite de banda do plano de serviço de GPRS, é

necessário que o ônibus opere por 18,5 horas diárias.

O custo mensal desse plano está na faixa de R$5,00 a R$10,00 por chip, e será levado

em consideração para o cálculo de custos de manutenção.

2.4.5 Custo de Manutenção

Segundo dados retirados de uma empresa de rastreamento em Curitiba, o custo para

manutenção mensal dos rastreadores pode variar de R$80,00 a até R$160,00 por rastreador.

Estimando que 50% dos rastreadores precisem de manutenção, o que significa 2118

rastreadores por mês, e ainda o custo mensal para o plano do chip, pode-se gerar uma faixa de

custo:

54

• Custo Mínimo:

2118 * 80,00 + 4236 * 5,00 = R$190.620,00

• Custo Máximo:

2118 * 160,00 + 4236 * 10,00 = R$381.240,00

Os custos são valores muito expressivos, e chegam a representar entre 34% e 69% do

custo inicial do projeto, e ainda não representam os custos para manutenção e

desenvolvimento de software. Apensar do custo parecer alto a princípio, o serviço de

transporte público conta com mais de 2.300.000 usuários diariamente [16]. Logo, o

faturamento de um dia já é suficiente para cobrir todos os custos de um mês para

disponibilizar uma aplicação como esta descrita no projeto, e possivelmente cobrir as

despesas mensais para manutenção do software.

55

2.5 TESTES E RESULTADOS FINAIS

Este tópico tem o objetivo de mostrar os resultados obtidos com o desenvolvimento

do projeto.

2.5.1 Rastreador:

O rastreador pode ser separado em dois níveis de conclusão: o (i) protótipo e a (ii)

placa final. O protótipo é funcional, com exceção de um bug na firmware que o faz travar

quando se está em movimento. Devido a grandes dificuldades de debuggar o rastreador em

movimento, o motivo desse bug não pôde ser descoberto. Porém, com este protótipo foram

realizados testes de rastreamento em que foi possível verificar o ícone do ônibus se movendo

na rota definida pela linha de ônibus, que será mostrado mais adiante. Já o rastreador em sua

versão final, na placa de circuito impresso, não é funcional, já que nem todos os componentes

foram soldados à placa. A dificuldade de se conseguir componentes SMD no Brasil é grande,

diversas lojas não vendem esses tipos de componentes, e as poucas que vendem dispõem de

um catálogo muito limitado que não supriu as necessidades para o desenvolvimento da placa.

O tempo estimado para importar componentes de lojas internacionais era maior que 30 dias,

tempo este que não estava disponível até a conclusão do projeto. Mas ainda assim, a maior

parte da placa foi montada usando componentes não SMD ou que se conseguiram de

equipamentos estragados. As imagens abaixo mostram o rastreador montado parcialmente.

56

Figura 23 – Rastreador montado parcialmente

Figura 24 – Rastreador dentro do case

O equipamento é capaz de rastrear ininterruptamente quando se está parado, porém,

ao se movimentar, a firmware trava. Para debuggar o problema é muito complicado, pois é

necessário que o veículo esteja em movimento (no caso, a bicicleta) e acessar a serial do

Mbed através de um notebook. Mas, uma análise através dos status leds do rastreador indicam

que o motivo de travamento ocorre ou na comunicação para recolher os dados do GPS, ou na

conexão com o servidor.

57

2.5.2 Função de rastreamento:

A possibilidade de permitir ao usuário verificar onde encontra-se o ônibus funciona

com sucesso. As rotas são desenhadas no mapa junto com os pontos de ônibus de forma

simples, sendo possível introduzir qualquer rota nova apenas definindo os DynamapID's

pertencentes à linha de ônibus e as coordenadas dos pontos e terminais. O mapa é atualizado a

cada trinta segundos, tornando a aplicação dinâmica e sem ícones fixos, portanto o usuário

não precisa atualizar manualmente para ver onde o veículo se encontra.

Para os testes, o rastreador foi embarcado em uma bicicleta que percorreu a linha do

ônibus enquanto um programa de captura de tela gravava o que acontecia na tela do

computador. Não optou-se por carregar o rastreador no ônibus devido ao risco de travar em

movimento, gastando tempo e recursos, este teste deve ser realizado quando o rastreador se

encontrar em um estado mais confiável. Para minimizar as chances de ocorrer o bug no

rastreador, a bicicleta diminuía a velocidade quando o rastreador se preparava para enviar os

dados, isso não evitou que ele travasse em alguns momentos, porém o teste de rastreamento

pôde ser feito. Esse bug também impediu que os dados de velocidade pudessem ser enviadas

ao servidor com maior exatidão, mais realista à situação real, pois diminuir a velocidade fazia

com que os dados enviados sobre este parâmetro não correspondesse com a situação real.

Abaixo encontram-se imagens de um vídeo feito durante um dos testes de rastreamento. Pode-

se notar que o ícone do veículo segue a rota até chegar ao terminal de ônibus, e depois volta

um trecho do caminho.

58

Figura 23 – Teste da função de rastreamento do sistema

2.5.3 Previsão de Horário:

Para testar a precisão da estimativa de tempo necessário para o veículo chegar em

determinado ponto, cronometrou-se o tempo que o ônibus precisa para chegar ao terminal

pela manhã, e voltar do terminal ao final da tarde. Como mostrado na figura abaixo, é o

59

percurso determinado pelo ícone do ônibus (parte inferior, atrás do terceiro Ponto “P”) até o

Terminal “T”.

Figura 24 – Previsão de horário

Devido ao bug do rastreador, não foi possível associar velocidades de cada

DynamapID para realizar a estimativa de tempo mais precisa, pois para minimizar as chances

de travamento da firmware, a velocidade sempre era reduzida quando o rastreador enviava os

dados, logo o valor da velocidade não correspondia fielmente à velocidade média daquele

trecho, era sempre inferior à real. Porém, o sistema usa uma velocidade média padrão quando

não há dado de velocidade associada ao DynamapID em que se está calculando a previsão,

esse valor é de 20 km/h, e foi escolhido pelo fato da linha passar por ruas dentro de bairros, de

mão dupla, compartilhadas com outros veículos em movimento ou estacionados.

60

O tempo previsto é de 3 minutos e 24 segundos (204 segundos), segue uma tabela

com os resultados obtidos para 40 medições realizadas:

Amostra Tempo Medido (segundos) Amostra Tempo Medido (segundos)1 213 21 2232 222 22 1893 206 23 2124 215 24 1915 189 25 1906 212 26 2217 214 27 2158 195 28 2259 211 29 22310 210 30 21211 221 31 21412 195 32 19313 213 33 19514 205 34 21515 212 35 22616 207 36 22317 220 37 22418 218 38 18819 207 39 21620 190 40 197

Tabela 2 – Tempos medidos

Pode-se observar nos dados acima que a maioria dos tempo medidos foram um pouco

maiores do que o tempo estimado (204 segundos). O maior tempo medido foi de 225

segundos, o que gera um erro de 10,3% acima do valor estimado, e o menor tempo para

percorrer o percurso foi de 188 segundos, gerando um erro de 7,85%. Os erros não são muito

elevados, no início do projeto esperava-se um erro máximo de 20%, felizmente o maior valor

encontrado foi a metade do esperado. O tempo médio para percorrer o percurso foi de 209,175

61

segundos, logo o erro médio para o valor estipulado é de 2,5%, que foi um resultado

surpreendente para a estimativa padrão do sistema.

A seguir segue um gráfico com os valores da tabela 2, mostrando os valores de tempo

reais medidos (linha contínua em preto), a estimativa (linha tracejada em vermelho) e o valor

médio das amostras coletadas (linha pontilhada em azul).

Figura 25 – Tempos medidos e tempo estimado

Como se pode perceber, a estimativa não é precisa, porém a finalidade da previsão de

horário não é a de saber o segundo exato em que o ônibus irá chegar ao destino, e sim situar o

usuário de que o veículo irá chegar próximo do que é estipulado, que nesse caso pode ser 10%

para mais ou para menos.

62

Estimativa de Tempo

0

50

100

150

200

250

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39

Amostras

Tem

po (s

egun

dos)

Tempo Medido Tempo Estimado Média dos tempos medidos

3. CONCLUSÃO

Dentro do tempo estabelecido e das dificuldades encontradas, o projeto teve um

resultado satisfatório. O objetivo era de criar um sistema capaz de coletar dados de um

veículo através de um equipamento embarcado, e mostrar essas informações em um mapa

com interface simples onde o usuário pode acessar de qualquer dispositivo com acesso à

internet, e ainda estimar um tempo para o veículo percorrer a rota com um erro relativamente

pequeno; esse objetivo foi cumprido.

Infelizmente, um bug crítico no rastreador no estágio de testes do projeto acabou

afetando todos os outros testes associados a ele. Mas ainda assim foi possível mostrar que o

sistema consegue rastrear e estimar tempos satisfatoriamente.

No estágio final do projeto, descobriu-se que o modo como foi implementada a

estimativa de tempo pode causar alguns resultados não muito confiáveis dependendo dos

eventos ocorridos, já que o tempo previsto leva em consideração a velocidade média de todos

os dias. Por exemplo, suponha que existam cem velocidades associadas a um único

DynamapID, e que todas tenham um valor de 30km/h. Porém, neste momento ocorreu um

evento, por exemplo um acidente de trânsito, que causou engarrafamento na quadra desse

DynamapID, e a velocidade média para percorrer este trecho seja, agora, de 2km/h. No modo

como está projetado no sistema atual, será feita uma média aritmética de todas as velocidades,

ou seja, somam-se as cem velocidades dos dias anteriores (30km/h) junto com esta nova

(2km/h) e divide-se pelo total (101), isto retornará uma velocidade média de 29,7km/h, que

não condiz com a realidade, logo o tempo estimado será muito parecido com o de todos os

dias anteriores, mesmo tendo ocorrido um acidente nesta quadra no dia de hoje. Para

contornar este problema, deveria ser implementada uma forma de atribuir pesos às

velocidades. Uma maneira de se fazer isso seria calculando uma velocidade média de todos os

63

dias anteriores a partir de ontem, e uma outra velocidade média para o dia de hoje, atribuindo

pesos a essas duas velocidade, por exemplo, peso 7 para a velocidade de hoje, e peso 3 para as

velocidades antigas, e só então fazer a média das duas. No caso do exemplo, se usado esse

novo método, ter-se-ia uma velocidade média de 30km/h (soma de todas as velocidades

dividida pelo total) para os dias anteriores, e uma segunda velocidade média para o dia de

hoje (2km/h, já que no exemplo só há uma velocidade associada a esse DynamapID). Fazendo

a média dessas duas velocidades com seus respectivos pesos, obter-se-á uma nova velocidade

média de 10,4km/h, valor esse que ainda não representaria uma estimativa confiável, porém o

valor da velocidade de 2km/h seria muito mais expressiva do que no modo como foi

implementado no projeto.

Essa forma de média por pesos e separadas por data não foi implementada pois

resultaria em várias alterações para o projeto, como na estrutura do banco de dados e dos

vários arquivos que compõem o servidor, mudança essa que não poderia ser feita já que o

problema foi diagnosticado apenas no estágio final. Porém deve ser arrumada para o futuro.

O projeto é inovador para o país, há formas semelhantes implementadas atualmente

no Brasil, como, por exemplo, estimativa de tempo em metrôs e até mesmo em pontos de

ônibus, porém, realizada uma breve pesquisa, não há uma maneira do usuário verificar isso

através da internet. No caso de Curitiba, nem mesmo há uma forma eficiente de se verificar as

rotas de ônibus, só há um aplicativo que desempenha esta função, porém está obsoleto e com

uma interface nem um pouco amigável. Uma solução como o LocBus tentaria trazer uma

forma mais eficiente de se verificar rotas e paradas de ônibus, mais simples para o usuário.

Além de fornecer dois novos serviços para a cidade: o rastreamento de ônibus e previsão de

horário (semelhante talvez aos encontrados nos metrôs em São Paulo).

64

Apesar da estimativa de custo parecer alta quando vista isoladamente, a

implementação deste projeto e a sua futura manutenção mensal não são das mais

dispendiosas. Basta lembrar que, segundo dados recolhidos do site da URBS, em 2010 foram

estimados um número de 2.300.000 passageiros transportados por dia (no caso, dia útil, sem

contar fins de semana e feriados). Na atual data, a tarifa de ônibus está R$2,50, e

considerando que do total de usuários, aproximadamente 2.000.000 são pagantes, isso gera

um arrecadamento bruto de aproximadamente R$5.000.000,00 diariamente. Se 20% desse

valor for destinado a implementar um sistema como a ideia deste projeto, em um dia é

possível manter o sistema por um mês.

Para finalizar, além do uso diário e promover uma melhor qualidade ao transporte

público na cidade, o projeto tem um grande potencial para ser realizado para a Copa do

Mundo de 2014 no Brasil e também para as Olimpíadas de 2016 no Rio de Janeiro. Devido ao

grande movimento que esses eventos irão gerar, o investimento em transporte público será o

mais adequado, logo, muitos estrangeiros ou pessoas que não conhecem a cidade dependerão

de ônibus e metrôs para chegar no destino desejado, e o LocBus poderia prestar auxílio, além

de até mesmo alguns serviços novos, como por exemplo, indicar todos os ônibus que devem

ser tomados para se chegar em um lugar desejado, como hotéis, restaurantes e pontos

turísticos, mostrando qual a parada mais próxima, conexões em terminais que devem ser feitas

e o tempo que leva para chegar em tal local.

65

REFERÊNCIAS

[1] NXP , “LPC17xx User Manual”, rev. 2. Agosto 2010.

[2] SANDERS, Geoff, THORENS, Lionel, REISKY, Manfred, RULIK, Oliver e DEYLITZ, Stefan, “GPRS Networks”. John Wiley & Sons Ltd, 2003.

[3] KAPLAN, Elliott D. e HEGARTY, Christopher J., “Undestanding GPS, Principles and Aplications”, 2ª Edição. Artech House Inc, 2006.

[4] SLOSS, Andrew N., SYMES, Dominic e WRIGHT, Chris, “ARM System Developer's Guide”. Elsevier, 2004.

[5] SVENNERBERG, Gabriel, “Beggining Google Maps API 3”. Apress, 2010.

[6] Telit Communications S.p.A, “AT Commands Reference Guide”, rev. 9.

2010.

[7] Telit Communications S.p.A, “GM862 Family Hardware User Guide”, rev 1.

2009.

[8] SCHILDT, Herbert, “C Completo e Total”, 3ª Edição. Makron Books do Brasil

ltda, 1997.

[9] GOOGLE, “The Google Maps Javascript API V3 Documentation”, acesso 13/04/2011, site:http://code.google.com/intl/pt-BR/apis/maps/documentation/javascript/basics.html

[10] GOOGLE, "Google Maps/Google Earth API's Terms of Service", acesso 06/06/2011, site:http://code.google.com/intl/pt-BR/apis/maps/terms.html

[11] VALADE, Janet, "PHP & MySQL Web Development", Wiley Publishing, 2008.

[12] Referência de bibliotecas C++, site: http://www.cplusplus.com/reference/

[13] SINNOT, R. W., "Virtues of the Haversine," Sky and Telescope, vol. 68, no. 2, 1984.

[14] Teoria de Haversine, acessado 15/06/2011 site: http://mathforum.org/library/drmath/view/51879.html

[15] HALLIDAY, Walker Resnick, “Fundamentos de Física I – Mecânica”, 7ª Edição, Editora LTC.

66

http://mathforum.org/library/drmath/view/51879.html

http://www.cplusplus.com/reference/

http://code.google.com/intl/pt-BR/apis/maps/documentation/javascript/basics.html

[16] URBS, acessado em 21/06/2011, site: http://www.urbs.curitiba.pr.gov.br/PORTAL/arquivos/XXXXXX080420111302290409.pdf

[17] PRAKASH, Arul, artigo “Geographical Information Systems – An Overview”, Indian Institute of Information Technology.

[18] BETKE, Klaus, “The NMEA 0183 Protocol”, 2000, rev. 2001

[19] National Semiconductor, “LM2576/LM2576HV Series Simple Switcher 3A Step-Dowm Voltage Regulator”, Agosto 2004

[20] GRIMMER, Lenz, “Navigating the spatial data support in MySQL 4.1”, 2003, acessado em 24/05/2011, site: http://www.lenzg.net/mysql/Navigating-The-Spatial-Data-Support.pdf

67

ANEXO I

Lista de comandos AT usados no projeto. AT é um prefixo para “Attention”.

1. AT:• Funcionalidade: Testa conexão com o modem;

2. ATE0:• Funcionalidade: Desabilita a opção de “Echo” (o modem volta o comando que

foi recebido junto com a resposta);

3. AT+IPR=9600:• Funcionalidade: Configura a comunicação serial para um baudrate de 9600bps;

4. AT&K0:• Funcionalidade: Desabilita o controle de fluxo da comunicação serial (não usa

os sinais CTS e RTS);

5. AT#SKIPESC:• Funcionalidade: Quando a conexão com o servidor é estabelecida, o modem

entra em um modo onde não aceita os comandos AT. Então um comando de “escape” é usado para o modem voltar ao modo normal (comando '+++'). O comando AT#SKIPESC faz com que os caracteres “+++” não sejam enviados ao servidor quando o modem detectá-los;

6. AT+CMEE = 2:• Funcionalidade: Quando algum comando enviar uma resposta de ERROR, a

mensagem será enviada com o que gerou o erro e em modo verbal (ou seja, não virá o código do erro, e sim uma frase diagnosticando o que aconteceu);

7. AT+CPIN?:• Funcionalidade: Requisita o status do SIMCard. A resposta fornece

informações como se o SIMCard está habilitado e pronto para o uso, ou se há algum erro ou esperando alguma senha;

8. AT+CGREG:• Funcionalidade: Verifica de há uma rede GPRS disponível.

9. AT$GPSP=1:• Funcionalidade: Liga o módulo GPS;

10. AT$GPSACP:• Funcionalidade: Requisita informações do GPS;

11. AT+CGDCONT = 1,"IP","APN","0.0.0.0",0,0:• Funcionalidade: Configura parâmetros do contexto PDP (Packet Data

Protocol). O primeiro parâmetro (1), especifica qual conexão está sendo

68

configurada. O segundo parâmetro especifica o protocolo a ser usado (IP – Internet Protocol ou PPP – Point to Point Protocol). O terceiro é o nome da APN (Acess Point Name) a qual o modem irá se conectar. Os demais parâmetros estão relacionados com compressão de dados;

12. AT#USERID = "xxx":• Funcionalidade: Configura o nome de usuário para se conectar à rede GPRS

definida no comando anterior;

13. AT#PASSW = "xxx":• Funcionalidade: Configura a senha do usuário definido acima;

14. AT#GPRS?:• Funcionalidade: Requisita o status se o modem está ou não conectado à rede

GPRS. Se a resposta for “#GPRS: 1”, o modem está conectado, se for “#GPRS: 0”, não está conectado;

15. AT#GPRS: 1:• Funcionalidade: Conecta à rede GPRS;

16. AT#GPRS: 0;• Funcionalidade: Desconecta da rede GPRS;

17. AT#SKTD = 0,”porta”,”IP”,255,0:• Funcionalidade: Abre um socket (0 – TCP ou 1 – UDP) na porta (definido em

“porta”) do IP/DNS (definido em “IP”, pode ser o IP do servidor ou o DNS). O quarto parâmetro define como a conexão será fechada (0 – Servidor fecha a conexão, 255 – O dispositivo fecha a conexão junto com o comando de escape “+++”). O último parâmetro representa a porta a ser usada do dispositivo, mas é usada apenas em conexões UDP, que não é o caso.

69

locbus - ufpro lpc1768 pode operar até uma freqüência de 100 mhz. o processador arm cortex-m3...

Documents