Sistema de Monitoramento de Atletas de Corrida de Aventura
Propaganda
UNIVERSIDADE POSITIVO NÚCLEO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE ENGENHARIA DA COMPUTAÇÃO ANDRÉ LUIZ SELEME MARIANO Sistema de Monitoramento de Atletas de Corrida de Aventura Trabalho de Conclusão de Curso. Prof. Valfredo Pilla Jr. Orientador Curitiba, setembro de 2011. UNIVERSIDADE POSITIVO Reitor: Prof. José Pio Martins Pró-Reitor de Administração: Prof. Arno Antonio Gnoatto Pró-Reitor Acadêmico: Prof.ª Márcia Sebastiani Coordenador do Curso de Engenharia da Computação: Prof. Leandro Henrique de Souza iii iv UNIVERSIDADE POSITIVO NÚCLEO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE ENGENHARIA DA COMPUTAÇÃO Sistema de Monitoramento de Atletas de Corrida de Aventura Proposta de Trabalho de Conclusão de Curso apresentada à disciplina de Trabalho de Conclusão de Curso como requisito parcial a conclusão do Curso de Engenharia da Computação, orientada pelo Prof. Valfredo Pilla Jr. Curitiba, setembro de 2011. v vi TERMO DE APROVAÇÃO ANDRÉ LUIZ SELEME MARIANO Sistema de Monitoramento de Atletas de Corrida de Aventura Monografia aprovada como requisito parcial à conclusão do curso de Engenharia da Computação da Universidade Positivo, pela seguinte banca examinadora: Prof. Valfredo Pilla Jr.(Orientador) Prof. José Carlos da Cunha Prof. Mauricio Perretto Curitiba, setembro de 2011 vii viii Sumário Lista de Abreviaturas e Siglas ......................................................................................... xi Lista de Figuras ............................................................................................................. xiii Lista de Equações ........................................................................................................... xv RESUMO ..................................................................................................................... xvii ABSTRACT .................................................................................................................. xix 1. Introdução ao Projeto ................................................................................................ 1 2. Fundamentação Teórica ............................................................................................ 3 2.1 GPS .................................................................................................................... 3 2.2 GSM ................................................................................................................... 4 2.2.1 2.3 Padrões de Arquitetura....................................................................................... 5 2.3.1 3. 4. GPRS............................................................................................................ 4 Padrão MVC ................................................................................................ 6 Especificação ............................................................................................................. 7 3.1 Características do Projeto .................................................................................. 7 3.2 Requisitos........................................................................................................... 7 3.3 Arquitetura ......................................................................................................... 8 3.4 Testes do sistema ............................................................................................... 9 Projeto ..................................................................................................................... 13 4.1 Hardware .......................................................................................................... 13 4.1.1 Módulo de Leitura de Batimentos Cardíacos ........................................... 14 4.1.2 Modulo de Aquisição de Dados GPS e Envio ao Servidor. ....................... 14 4.1.3 Firmware para controle do Hardware ...................................................... 14 4.2 Software ........................................................................................................... 15 4.2.1 Modelo...................................................................................................... 16 4.2.2 Visão ......................................................................................................... 17 4.2.3 Controle .................................................................................................... 18 4.3 Comunicação Hardware-Software ................................................................... 19 ix 4.4 5. Resultados ............................................................................................................... 21 5.1 Quanto ao protótipo. ........................................................................................ 21 5.1.1 Frequência Cardíaca ................................................................................. 21 5.1.2 Localização ................................................................................................ 22 5.2 6. Protocolo de Comunicação .............................................................................. 19 Quanto ao Software gerenciador. ..................................................................... 24 Conclusão ................................................................................................................ 25 Referências ..................................................................................................................... 27 x Lista de Abreviaturas e Siglas GPS Global Positioning System GPRS General Packet Radio Service PHP PHP: Hypertext Preprocessor MVC Model-view-controller DER Diagrama Entidade Relacionamento RIA Rich Internet Application DoS Denial of Service xi xii Lista de Figuras 3.1 Representação Gráfica do Sistema .............................................................................8 3.2 Diagrama em blocos do Hardware .............................................................................9 3.3 Diagrama de Colaboração Genérico do Software .......................................................9 4.1 Esquemático do Hardware .........................................................................................13 4.2 Conexão entre o Chip RMCM01 e a Cinta Polar ......................................................14 4.3 Fluxograma do Firmware ..........................................................................................15 4.4 Casos de Uso do Software .........................................................................................16 4.5 DER ...........................................................................................................................17 4.6 Tela de Rotas .............................................................................................................18 4.7 Tela de Relatório .......................................................................................................18 5.1 Protótipo finalizado ...................................................................................................21 5.2 Gráfico de comparação de frequência cardíaca do protótipo com o relógio Polar....22 5.3 Gráfico de redundância dos pontos do GPS ..............................................................23 5.4 Comparação entre a rota utilizando GPS (vermelho) e a rota ideal (branco) ............23 xiii xiv Lista de Equações 1. Formula utilizada para o calculo dos batimentos cardíacos ..........................................8 xv xvi RESUMO Este trabalho trata-se do projeto do Sistema de Monitoramento de Atletas de Corrida de Aventura, tendo como característica a aquisição dos dados de localização por GPS (Global Positioning System) e frequência cardíaca utilizando a cinta Polar para a sua captação. Estas informações são enviadas em tempo real por rede celular a um servidor remoto podendo ser analisadas a qualquer momento. As corridas de aventura são eventos que acontecem em ambiente natural, onde os atletas devem percorrer rotas em situações climáticas adversas, seguindo apenas as marcações dadas em um mapa que é entregue antes da prova. Muitos técnicos não podem acompanhar a rota e muito menos o rendimento de seus atletas durante a atividade. O único controle possível durante as provas são registros de passagem pelos postos de controle nos quais os atletas têm seu tempo anotado e sua localização identificada. Tendo em vista estes problemas, o sistema auxilia os atletas e os técnicos, uma vez que dispõe de um módulo GPS para aquisição da posição atual e GPRS (General Packet Radio Service) para comunicação com a internet via rede celular. Junto a ele está conectado um receptor de frequência cardíaca que se comunica com uma cinta Polar. A cinta Polar é um equipamento que, colocado em volta do tórax do atleta, detecta e transmite os batimentos cardíacos. Estes parâmetros - posição atual e batimentos cardíacos (média do último minuto) - são enviados a um servidor web pelo método POST, permitindo a visualização dos dados em qualquer lugar. Após o recebimento e validação dos dados, o sistema apresenta as rotas executadas permitindo visualiza-las para uma análise de desempenho e orientação para uma possível melhoria em corridas posteriores, podendo também ser possível comparar rotas e até mesmo o desempenho de atletas. Em complemento a comparação entre rota e entre atletas, o sistema permite o armazenamento dinâmico de um histórico de dados do atleta, onde o usuário cria os atributos que deseja começar a monitorar, podendo visualizá-los em forma de relatório gráfico ou textual. A utilização do sistema tem como principal objetivo um acompanhamento mais preciso e aproximado do atleta a fim do mesmo e seu técnico aprimorarem técnicas de treinamento para uma melhoria em corridas futuras. Palavras-chave: GPS, GPRS, Frequência Cardíaca, Cinta Polar, Corridas de Aventura. xvii xviii ABSTRACT The Adventure Racing Athletes Monitoring System Project is characterized by the acquisition of location data by GPS (Global Positioning System) and heart rate using a chest strap transmitter to capture. This information is sent in real time by cellular network to a remote server. The information sent can be analyzed at any time during or after the sport activity. Adventure races are events that happen in a natural environment where athletes must travel routes in adverse weather conditions, following only the checkpoints given in a map that is delivered before the race. Many coaches can not follow the route neither the performance of their athletes during the activity. The only possible control during the races are records of passage through checkpoints in which athletes have to register time and location. Given these problems, the Adventure Racing Athletes Monitoring System helps athletes and coaches, since it has a GPS module to acquire the current position and GPRS (General Packet Radio Service) to communicate with the Internet via the cellular network. Next to it is connected a heart rate receiver that communicates with a chest strap transmitter. The chest strap transmitter is a device that fitted around the chest of the athlete, detects and transmits the heartbeat. These parameters - current position and heart rate (average for the last minute) - are sent to a web server by POST method, allowing the visualization of data anywhere. Upon receipt and validation, the system show all the routes allowing coach and athlete to work on performance analysis and guidance for a possible improvement in subsequent races, and may also allowing them to compare routes and even athletic performance through data as speed, heart rate and altitude of the athlete in a given moment of time. In addition to the comparison between athletes and route, the system allows the dynamic storage of historical data of the athlete, where the user creates the attributes that want to start monitoring, which can then be viewed one by one, or grouped, in the form of textual or graphical report. The system's main objective is a more accurate and close analysis of races helping athlete and his coach to reach improvement in future races. Key-words: GPS, GPRS, Heart rate, Polar Belt, Adventure Race xix 1 1. Introdução ao Projeto As corridas de aventura são eventos que acontecem em ambiente natural, onde muitos técnicos não podem acompanhar o rendimento de seus atletas e o único controle possível nas provas do evento é nos postos de controle pelos quais os atletas são obrigados a passar para marcar seu tempo(SIFF et al., 2001). Tendo em vista estes problemas, o Sistema de Monitoramento de Atletas de Corrida de Aventura auxilia os atletas e consequentemente os técnicos, uma vez que dispõe de um módulo GPS para aquisição da posição atual e GPRS para comunicação com a internet via celular. Junto a ele está conectado um receptor de frequência cardíaca que se comunica com uma cinta Polar a qual mede os batimentos cardíacos de um atleta. Estes parâmetros - posição atual e batimentos cardíacos - são enviados a um servidor web, permitindo a visualização dos dados em qualquer lugar. O objetivo deste equipamento é disponibilizar aos atletas de corrida de aventura e aos seus técnicos, um maior controle de seu treinamento, podendo assim analisar com precisão quais as maiores falhas e qualidades do atleta para assim poder variar o treino e trabalhar com mais qualidade os pontos fracos e intensificando os pontos fortes. 3 2. Fundamentação Teórica Para um maior entendimento do sistema, neste capitulo serão explanados alguns conceitos que abordam o projeto. 2.1 GPS Sistema de Posicionamento Global (Global Positioning System) também conhecido como GPS, é um sistema que informa o tempo e a localização do usuário em qualquer lugar no planeta onde tenha no mínimo quatro satélites desobstruídos, ou que estejam visíveis ao aparelho que está requisitando os dados de localização e tempo. O projeto do GPS foi iniciado em 1960 para fins militares pelo governo dos Estados Unidos em conjunto com o Departamento de Defesa americano, com a NASA e com o Departamento de transportes americanos. O objetivo principal era o desenvolvimento de um sistema de satélites para a determinação de posição tridimensional com as seguintes características: cobertura global, operação em qualquer ambiente, habilidade de trabalhar com plataformas dinâmicas e alta precisão (KAPLAN et al.,2006). O GPS se tornou totalmente operacional em 1995 com vinte e oito satélites, sendo quatro destes sobressalentes. Os satélites estão localizados em seis planos orbitais havendo quatro satélites por plano. Atualmente o GPS dual-use, isto é, disponibiliza serviços separados para militares e para civis. São os chamados PPS (Precise Positioning System) e SPS (Standard Positioning System). O PPS, que apresenta maior precisão e menor tempo de resposta é utilizado a fins militares e a SPS que apresenta menor precisão e maior tempo de resposta é utilizado por civis (KAPLAN et al.,2006). Atualmente o GPS é utilizado de inúmeras formas, sendo as mais comuns o uso em aparelhos de navegação pelas cidades, onde se colocando o destino, com o auxilio do GPS, o aparelho indica ao usuário o caminho mais adequado, na maioria das vezes. Para aquisição dos dados de GPS, é necessária interpretação do NMEA, tipo de protocolo utilizado para comunicação de dispositivos de navegação, entre eles, o GPS. O protocolo disponibiliza informações como latitude, longitude, altitude, hora e antenas conectadas ao aparelho que faz a requisição dos dados (KAPLAN et al.,2006). 4 2.2 GSM Global System for Mobile Communications, ou GSM, é o padrão para descrever tecnologias de segunda geração para redes de celular. Desenvolvido pela European Telecommunications Standards Institute ou ETSI, o GSM é o antecessor das tecnologias GPRS e da tecnologia 3G (HALONEN et al.,2003). Seu desenvolvimento foi sugerido graças ao grande número de padrões de telefonia na Europa havendo incompatibilidade de telefonia entre um país e outro sendo necessário em alguns casos um usuário da telefonia celular ter um aparelho para cada país. O desenvolvimento do GSM iniciou em 1982 e teve grande aderência, seja pela padronização da telefonia ou pelo baixo custo dos serviços, uma vez que após 16 anos já possuía mais de 100 milhões de assinantes (HALONEN et al.,2003). A necessidade do desenvolvimento contínuo do GSM já havia sido discutida e programada no inicio do trabalho de especificação e a consequência disso foi a divisão do seu desenvolvimento em duas fases. A fase 1 incluía habilitar os serviços mais comuns o mais rápido possível para o GSM já entrar no mercado. Nesta fase, os serviços habilitados eram telefonia básica, chamadas de emergência, 300 a 9600kbps de transferência de dados, criptografia, autenticação, encaminhamento ou bloqueio de chamadas e SMS (HALONEN et al.,2003). Já na fase 2, as especificações incluíam compatibilidade entre fases e tratamento de erro para habilitar os novos serviços. Entre os novos serviços, foram habilitados, por exemplo: Identificação de chamada, chamada em espera, aviso de carga e recarga e chamadas com mais de um usuário (HALONEN et al.,2003). Com as duas primeiras fases criando uma base solida para a evolução para a terceira geração (3G), foram iniciados os desenvolvimentos dos requisitos e itens, sendo conhecidos como Fase 2+. Dentre as melhorias, foi criado o General Packet Radio System, ou GPRS, que tinha como foco a conectividade com a internet (HALONEN et al.,2003). 2.2.1 GPRS A fim de melhorar a transmissão de dados do GSM, foi desenvolvido o GPRS (General Packet Radio Service), tendo como maior objetivo o aumento de dados na 5 transmissão. Para isso ele é baseado na transmissão de pacote de dados, utilizando a conexão apenas quando necessário e não a todo instante (SANDERS et al.,2003). Por conta da implementação de transferência orientada a pacote de dados, o custo do GPRS é calculado pelo número de dados trafegados na rede e não pelo tempo de conexão e é neste quesito que ele se sobressai. Uma vez que lida com pacotes de dados ele pode trocar informações diretamente com a internet ou uma intranet de uma empresa. Outra vantagem é poder estar conectado em qualquer lugar a todo instante. (SANDERS, et al.,2003) O único problema inicial encontrado pelo GPRS foram os aparelhos da época que não possuíam extensão para ele, nem suportavam transferência orientada a pacote de dados, sendo a única solução uma troca de aparelho celular por novos celulares que eram compatíveis com essa extensão (SANDERS et al.,2003). Sendo telefonia de segunda geração, o GPRS consegue chegar até a 114kbit/s quando a qualidade do sinal é garantida, podendo variar até 56kbit/s (SANDERS et al.,2003). Como o GPRS é uma extensão do GSM, ele também oferece serviços, dentre eles: Menor custo de SMS. Manipulação de arquivos. Mensagens multimídia Conexão WAP. 2.3 Padrões de Arquitetura Para facilitar o desenvolvimento de software e a padronização dos modelos de desenvolvimento, foram criados os padrões de arquitetura. Os padrões de arquitetura não são regulamentados por nenhum órgão, mas recebem este nome por serem desenvolvidos por muitos especialistas e terem sua eficiência conhecida (MACORATTI et al.,2002). Estes padrões são normalmente utilizados em frameworks para que desenvolvedores com pouca experiência ou tempo consigam começar a desenvolver rapidamente e sem muita dificuldade. 6 Também são utilizados para tornar os sistemas mais simples e fáceis de realizar manutenção, como por exemplo, os padrões de arquitetura de camadas onde se separa o software em camadas de aplicação (MACORATTI et al.,2002). Existem três tipos de padrões de camadas: 1. Aplicação monolítica, onde a lógica de aplicação, lógica de negócios, e lógica de acesso ficam na mesma camada, existindo desta forma, apenas uma. É um dos desenvolvimentos menos recomendados uma vez que a alteração em qualquer uma das lógicas pode e vai alterar a outra 2. Aplicação em duas camadas, sendo a lógica de aplicação e a lógica de negócios separadas em uma camada e a lógica de dados separada em outra camada. Este modelo já é mais interessante uma vez que os dados são o mais importante de uma aplicação e desta maneira eles não ficam comprometidos. 3. Aplicação em três camadas, a qual atualmente tem maior utilização, é o modelo mais recomendado uma vez que cada uma das lógicas de aplicação, negócios e dados são separadas em camadas, onde a alteração de uma não vai alterar a outra. 2.3.1 Padrão MVC Model View Controller, ou MVC, é um padrão de arquitetura, onde a camada de Dados (Model), a camada de apresentação (View) e a camada de regra de negócios (Controller), são separadas, ou seja, a alteração de qualquer uma destas camadas não modifica as outras. Apesar de tomar um maior tempo de desenvolvimento, a utilização do modelo MVC, se bem implementado, pode tornar a aplicação escalável e multiusuário, uma vez que sua manutenção é mais simples, não sendo necessário alterar todas as camadas, e caso haja mais que um cliente, só é necessário alterar a camada de apresentação (MACORATTI et al.,2002). 7 3. Especificação Este capítulo tem como objetivo detalhar as características, requisitos, arquitetura, testes e planejamento necessários para desenvolvimento do projeto como um todo. 3.1 Características do Projeto Modulo GPS/GPRS GM862 (TELIT COMUNICATIONS S.p.A,2009): o Precisão do GPS: 2,5m; o Ganho da Antena do GPS: 26dB; o Alimentação: fonte externa, +3.6V; Consumo médio de corrente: 200mA; Taxas de atualização: 1. Posição: 5 segundos; 2. Batimentos cardíacos: 10 segundos; 3. Atualização do servidor: 60 segundos; Linguagens de Programação: 1. Modulo GPS/GPRS: Python e comandos AT; 2. Camada visual do software: Action Script 3.5; 3. Camada de Negócios: PHP; 4. Camada de Modelo: SQL; Servidor (HOSTMONSTER, 2011): 1. Sistema operacional: Linux 2. Versão do Apache: 2.2.17 3. Versão do PHP: 5.2.17 4. Versão do PostgreSQL: 8.2 3.2 Requisitos Fonte de alimentação externa 3.6v; Computador com porta serial; Modulo GPS/GPRS GM862-GPS; Chip de celular com acesso a internet; Cinta Polar; 8 Antenas de Captação GPRS e GPS Receptor da cinta polar RMCM01; Ferramenta de Desenvolvimento Eclipse; Plug-in do Software Adobe Flex para o Eclipse; Ferramenta de Desenvolvimento Netbeans; Plug-in do PHP para Netbeans; Banco de Dados PostgreSQL; Servidor Web; 3.3 Arquitetura A representação gráfica do sistema, como apresentado na figura 3.1 recebe os dados de batimento e localização do atleta, enviando ambos os parâmetros para um servidor web, via comunicação celular, permitindo a visualização dos dados em qualquer lugar com conexão com a internet. Figura 3.1– Representação Gráfica do Sistema 9 O diagrama de blocos do funcionamento do hardware é bem simples como mostra a figura 3.2. Os batimentos cardíacos são enviados ao leitor RMCM01 pela cinta Polar. Uma vez recebidos, eles são enviados ao modulo GPS/GPRS GM862-GPS. Este módulo de tempos em tempos faz a requisição aos satélites GPS da posição atual do atleta, então pega tanto estes dados como os batimentos cardíacos e envia a um servidor web. Figura 3.2 – Diagrama em blocos do Hardware Já para a arquitetura de software é utilizado o padrão MVC onde o mesmo é separado em visão, controle e modelo. Na arquitetura abaixo (Figura 3.3) é apresentado o diagrama de colaboração genérico entre ambos, após a interação de um usuário, sendo a visão o Flex, o controle a classe PHP e o modelo, o Banco de Dados. Figura 3.3– Diagrama de Colaboração Genérico do Software 3.4 Testes do sistema Os testes do sistema são de grande importância para o projeto, uma vez que a partir deles são definidas as corretas aproximações para um desenvolvimento otimizado. Para testes mais eficientes, serão separados em três módulos principais, sendo eles: Hardware, Software e Integração entre Hardware e Software. Hardware o Teste da Cinta Polar e do Receptor RMCM01 10 Entrada: Batimentos cardíacos provenientes de um ser humano, transmitidos pela cinta polar; Saída esperada: Vcc quando recebido os batimentos cardíacos e Gnd quando houver ausência do batimento. o Teste do Módulo GPS/GPRS GM862-GPS Teste de Conexão com o servidor Entrada: Comando AT para se conectar ao servidor seguido de requisição GET com passagem de parâmetros de batimento e posição; Saída esperada: Resposta afirmativa do servidor, informando que a conexão foi feita corretamente. Teste de GPS Entrada: Comando AT para aquisição e recebimento dos dados do GPS Saída Esperada: A localização atual nos padrões NMEA. o Teste da Integração entre o Receptor RMCM01 e o Módulo GPS/GPRS GM862-GPS Entrada: Sinal do receptor dos batimentos cardíacos. Saída: Ler o sinal do receptor e enviar os dados dos batimentos cardíacos e a posição atual do GPS para um servidor web. Software o Testes das Classes de Objetos Entrada: Dados a serem tratados pelas classes e suas respectivas funções Saída esperada: Tratamento correto dos dados e resposta em forma de XML. 11 o Testes do Banco de Dados Entrada: SQL para consulta, inserção, alteração ou exclusão. Saída esperada: A resposta proveniente do SQL executado. o Teste da Interface do Usuário Os testes da interface de usuário envolvem verificar se o layout da pagina esta de acordo com o perfil do usuário, se o sistema está intuitivo e se a usabilidade dele está comprometida. o Teste de Comunicação entre as camadas Será verificado se a comunicação entre as camadas está se dando de forma correta. Como, por exemplo, os dados do banco de dados, devem ser trazidos por uma requisição feita por uma das classes que foi acionada por uma ação do usuário na tela do software. Integração entre Hardware e Software o Será analisado neste momento, o sistema inteiro, onde as aquisições de dados feitas pelo modulo GM862-GPS tanto dos batimentos, quanto da posição atual do GPS deverão ser enviadas a um servidor web, que por sua vez deverá apresenta-los aos usuários que fizerem requisição destes dados. Será verificado se os dados apresentados são compatíveis com o mundo real. 13 4. Projeto Neste capítulo pretende-se detalhar todo o projeto, abrangendo as partes de hardware e software, apresentando características da montagem e do desenvolvimento. 4.1 Hardware Para poder desenvolver o sistema de monitoramento de atletas, é necessário o hardware para a aquisição de dados, tanto de batimentos cardíacos quanto de localização e envio dos dados para o servidor web. Pelo fato do sistema GPS e GPRS estarem integrados no módulo GM862-GPS, a montagem do hardware do sistema é simples, uma vez que o único chip externo é o de leitor de batimentos cardíacos, logo o hardware fica composto pelo receptor de dados da cinta polar e pelo módulo como apresentado na figura 4.1. Figura 4.1 – Esquemático do Hardware Para um desenvolvimento mais rápido, foi separado o hardware em três partes: Módulo de Leitura de Batimentos Cardíacos, que consiste na cinta polar e no chip de recepção dos batimentos cardíacos. Módulo de Aquisição de Dados e Envio ao servidor, que consiste no Módulo GPS/GPRS GM862-GPRS. Firmware para Controle do Hardware. 14 4.1.1 Módulo de Leitura de Batimentos Cardíacos Como visto na figura 4.2, o módulo de Batimentos cardíacos é composto por duas partes: A Cinta Polar, que envia os dados do batimento cardíaco; O Chip RMCM01, que faz a leitura dos dados enviados pela cinta Polar via radiofrequência. Figura 4.2 – Conexão entre o Chip RMCM01 e a Cinta Polar (Polar Electro Inc, 2008) 4.1.2 Modulo de Aquisição de Dados GPS e Envio ao Servidor. Este módulo é composto de: Módulo GPS/GPRS GM862-GPS, que além de receber os dados de GPS, recebe os dados do módulo de leitura de batimentos e envia os dados ao servidor. Cartão SIM para celular, que possibilita o envio de dados via GPRS. Antenas GPS e GPRS, para conseguir captar os dados dos satélites GPS e das antenas GPRS. 4.1.3 Firmware para controle do Hardware O módulo GPS/GPRS GM862-GPS é programável em Python, contendo até 1,2 Megabytes de memória para funcionamento do script e 1,9 Megabytes de memória interna utilizada para o armazenamento de dados nas áreas onde o sinal GPRS não é captado. O script em Python funciona como um algoritmo normal como demonstra seu fluxograma na figura 4.3. 15 Figura 4.3 – Fluxograma do Firmware 4.2 Software O software desenvolvido permite ao cliente acesso a inúmeros dados, seja de cadastramento, rotas utilizadas, atributos inerentes a cada atleta, por exemplo, peso, altura, entre outros, assim como relatórios entre comparação de atributos em um determinado período, como apresentado na figura 4.4. 16 Figura 4.4 – Casos de Uso do Software Para o desenvolvimento software, foi utilizada a arquitetura MVC onde se separa o software em três camadas de desenvolvimento, sendo elas: camada visual ou de Visão, camada de negócios ou Controle e camada de armazenamento de dados ou Modelo (MACORATTI, et al.,2002). Uma das melhores e mais utilizadas arquiteturas em softwares online, uma vez que é possível fazer reparos em qualquer uma das três camadas sem alterar os dados da outra. Tendo isto em vista, a separação utilizada foi: Modelo, que se encaixa o Banco de Dados, no caso, o Banco de Dados PostgreSQL. Visão, que se encaixa a parte visual do sistema utilizada o software Adobe Flex para o desenvolvimento. Controle, que se situa a regra de negócio, ou seja, todo o tratamento correto dos dados para a inserção dos mesmos no banco de dados e seu retorno a Visão, onde foi utilizado o PHP como plataforma padrão. 4.2.1 Modelo Para o Modelo, ou Banco de Dados, foi selecionado o SGBD PostgreSQL, considerado um dos melhores SGBDs open-Source para se trabalhar. O desenvolvimento do modelo para o sistema foi feito da maneira mais dinâmica possível, onde a vinculação de rotas e comparação entre dados de períodos diferentes do atleta podem ser feito facilmente e dinamicamente, como visto no DER na figura 4.5. 17 Figura 4.5 – DER 4.2.2 Visão Para este módulo, foi escolhido o programa Adobe Flex, considerado uma Aplicação Rica para Internet, ou RIA, onde gera aplicações amigáveis para o usuário e extremamente dinâmicas, como visto nas figuras 4.6 e 4.7, quebrando o paradigma que foi gerado no HTML onde é possível gerenciar apenas uma janela por tela. (ADOBE, 2011) 18 Figura 4.6 – Tela de Rotas. Figura 4.7 – Tela de Relatório. 4.2.3 Controle Foi utilizado como plataforma de regra de negócios, o PHP, tanto por sua facilidade de conexão com o Modelo, quanto a sua integração com a Visão, onde é possível enviar objetos inteiros de um para o outro, sem ter o problema de serialização ou fragmentação de objetos. Outro motivo para utilização do PHP é que seu custo é de graça e praticamente todos os servidores permitem a utilização dele, podendo então ter um servidor com um custo muito baixo, apesar de que o PHP não possui tantas funções e segurança quanto outras linguagens de programação que podem ser utilizadas como Controle, por exemplo: Java Web. 19 4.3 Comunicação Hardware-Software Para a Conexão do Hardware com o Software, são utilizadas requisições GET do hardware GM862-GPS para o servidor do Software em questão, acessando diretamente uma classe PHP que valida os dados de localização de batimento, assim como os dados de segurança, para então inserir os dados no banco de dados. 4.4 Protocolo de Comunicação O Protocolo de comunicação utilizado no software é o de cliente-servidor onde vários clientes podem acessar a um servidor simultaneamente fazendo requisições e o servidor processa estas e retorna aos clientes (CAMARGO, 2008). A escolha deste protocolo é pelo fato do sistema poder ser acessado de qualquer lugar e o cliente não necessitar ter o software instalado em seu computador, mas em contrapartida, quando o tráfego de dados no servidor está muito alto ou quando este trava, todos os clientes, sem exceção perdem acesso aos seus dados naquele período de tempo, seja por timeout da conexão, ou por DoS. 21 5. Resultados Após várias utilizações do sistema e testes em campo, o equipamento mostrou-se funcional, conseguindo registrar para cada atleta seu tempo de rota, batimento cardíaco, velocidade entre outros atributos. 5.1 Quanto ao protótipo. O Protótipo (Figura 5.1) foi capaz de armazenar dados de batimentos por minuto e localização do atleta sem enviá-los ao servidor por até oito dias. Quando requisitado, enviou todos os dados com os respectivos horários de rota corretos, havendo um erro máximo de três segundos entre o tempo real e o tempo da rota. Figura 5.1 - Protótipo finalizado. 5.1.1 Frequência Cardíaca A frequência cardíaca, ou batimento cardíaco, é o número de vezes que o coração bate por minuto. Seu cálculo é dado pelo número de vezes que o coração bate dentro de um minuto, ou, neste caso, se dá por meio da somatória dos batimentos dentro dos últimos vinte segundos multiplicados por três, apresentado na equação a seguir: Para conseguirmos os batimentos por minuto, sabendo que Bt[i] representa os batimentos dentro do I-ésimo segundo, é necessário pegar os batimentos nos últimos vinte segundos, somá-los e multiplicá-los por três, tendo assim os batimentos cardíacos por minuto. 22 Figura 5.2 – Gráfico de comparação de frequência cardíaca do protótipo (azul) com o relógio Polar (vermelha) Após vários testes, a exemplo do gráfico apresentado na figura 5.2, em comparação ao relógio da cinta Polar, foi alcançando uma precisão média de 98,8% do batimento real estabilizado, e em casos que o batimento varia muito rapidamente, a precisão pode chegar a uma média de 92%, sempre chegando aos 98,8% após vinte segundos de estabilização. 5.1.2 Localização A fim de verificar a precisão do GPS, foi realizado um teste de redundância que consistiu em manter o GPS parado captando dados. Como se pode observar na figura 5.3, dos cento e sessenta pontos capturados, a distância máxima entre um ponto e outro foi de 6,24 metros sendo a distância máxima entre os pontos da extremidade e o ponto central, onde estava localizado o aparelho, de 3,15 metros. A precisão média encontrada, após o calculo de todos os pontos de redundância foi de 2,43 metros. 23 Figura 5.3– Gráfico de redundância dos pontos do GPS. Sabendo a precisão média do GPS, é possível fazer uma rota com diferença muito pequena da rota real, uma vez que o erro máximo alcançado pelo teste de redundância foi de 4%. Utilizando o Protótipo em um caso real, pode-se perceber como apresentado na figura 5.4, onde a linha vermelha representa a rota executada pelo atleta e gravada pelo GPS e a linha branca representa a rota ideal, que a rota ideal apresentou uma distância de 491,89 metros enquanto a rota gravada pelo GPS apresentou uma distância de 474,31 metros apresentando um erro de 3,5% de distância total em comparação com o percurso original. Figura 5.4 – Comparação entre a rota utilizando GPS (vermelho) e a rota ideal (branco). 24 5.2 Quanto ao Software gerenciador. O software desenvolvido para gerenciar os dados funcionou como esperado, sendo intuitivo quanto à vinculação de rotas e apresentando dados válidos e relevantes para levantamento de progresso do atleta pelo seu tempo de monitoramento. Também apresentou um sistema de atributos dinâmicos que o atleta ou o técnico conseguem gerenciar, sendo estes numéricos, texto ou um valor predefinido, podendo gerar relatórios de comparação entre atributos e até mesmo entre atletas. Outra funcionalidade tão importante quanto é o gerenciamento de vários atletas pelo mesmo técnico, podendo este avaliar os mesmos separadamente, ou comparando uns com os outros. 25 6. Conclusão A partir de testes de seu funcionamento, o protótipo mostrou-se útil para corridas de aventura auxiliando os técnicos no monitoramento de seus atletas. Apresentando precisões de GPS e frequência cardíaca relativamente boas, o protótipo pode ser utilizado não somente para monitoramento de atletas, como também para monitoramento de pessoas com problemas de saúde, envolvendo medição de batimentos cardíacos e permitindo um acompanhamento online a distância, possibilitando assim uma ação imediata em caso de complicações. Como melhoria, podemos citar a modificação do portal para que organizadores de corridas de aventura consigam monitorar os atletas sem ter obrigatoriamente pessoas em postos de controle, reduzindo assim custo dos eventos de corrida de aventura. Outra melhoria a ser citada é a integração do protótipo com os smartphones que possuem GPS e conexão com internet, utilizando apenas o leitor de frequência cardíaca conectado a um ultrassom, eliminando a necessidade do módulo GPS/GPRS, reduzindo o custo do projeto. Conclui-se que o protótipo apresentou resultados satisfatórios ao que foi proposto, podendo se tornar uma solução comercial apenas com algumas melhorias de redução de tamanho. 27 Referências 1. SIFF, Barry; CADWELL, Liz; ADAMSON, Ian. Adventure Racing: The Ultimate Guide. Velopress , 2001, 256 p. 2. KAPLAN, Elliot D.; HEGARTY, Christopher J. Understanding GPS: principles and applications. Artech House,2006. 675p. 3. HALONEN,Timo ; ROMERO, Javier ; MELERO, Ruan . GSM, GPRS and edge performance: evolution towards 3G/UMTS. John Wiley & Sons Ltd., 2003. 615p. 4. SANDERS,G.;THORENS,L.;REISKY,M;RULIK,O.;DEYLITS,S. GPRS networks. John Wiley & Sons Ltd., 2003 294p. 5. TELIT COMMUNICATIONS S.p.A. Datasheet do GM862-GPS , 2009. Disponível em http://www.telit.com/en/products.php?p_id=3&p_ac=show&p=4 , acesso em 15 de março de 2011 6. HOSTMONSTER . Hosting Features ,2011. Disponível em http://www.hostmonster.com/cgi/info/hosting_features , acesso em 15 de março de 2011. 7. POLAR ELECTRO INC. Datasheet do RMCM01,2008. Disponível em http://www.sparkfun.com/datasheets/Wireless/General/RMCM01.pdf , acesso em 15 de março de 2011. 8. MACORATTI, José Carlos. Padrões de Projeto: O modelo MVC - Model View Controller,2002. Disponível em http://www.macoratti.net/vbn_mvc.htm , acesso em 10 de abril de 2011. 9. ADOBE. Rich Internet Applications , 2011. Disponível em http://www.adobe.com/resources/business/rich_internet_apps/ , acesso em 10 de abril de 2011. 10. CAMARGO,Camila. O que é Cliente-Servidor?,2008 . Disponível em http://www.tecmundo.com.br/982-o-que-e-cliente-servidor-.htm , acesso em 10 de abril de 2011.
