Embed Size (px)
Citation preview
DESENVOLVIMENTO DE SISTEMA DETECTOR DE
QUEDAS DA PRÓPRIA ALTURA UTILIZANDO
DISPOSITIVOS MÓVEIS
Ricardo Carvalho Wasniewski
Projeto de Graduação apresentado ao Curso de
Engenharia Eletrônica e de Computação da Escola
Politécnica, Universidade Federal do Rio de Janei-
ro, como parte dos requisitos necessários à obten-
ção do título de Engenheiro.
Orientador: Flávio Luis de Mello
Rio de Janeiro
Fevereiro de 2017
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
DEDICATÓRIA
Dedico este trabalho ao meu falecido avô, Wolymir Ivan Wasniewski, único
Engenheiro da minha família, e também graduado na Escola Politécnica da UFRJ.
AGRADECIMENTO
Agradeço primeiramente ao Carlos José Ribas D’Ávila, coordenador do curso de
Engenharia Eletrônica e de Computação pela maior parte do tempo em que fui aluno,
pela paciência e bondade com todos os graduandos do curso. Ao Flavio Mello, meu
orientador deste projeto, por toda a sua disponibilidade, interesse e capacidade
linguística para me guiar nesse processo. À Giovana Pineschi, minha parceira em todos
os momentos, por todo o apoio dado. Ao Hamed Hadaddi, meu orientador neste projeto
na parte em que desenvolvi em Londres, por todo o apoio e orientação. Ao André
Augusto, meu grande amigo, por ter me emprestado seu celular para todo o
desenvolvimento e apresentação do projeto em Londres. À Natália Stefanon, minha
colega e amiga, por ter emprestado seu celular para o desenvolvimento do projeto no
Brasil. Aos meus pais, Ricardo José Wasniewski e Lais Perazo Nunes de Carvalho, que
são a base do que eu sou hoje, por todo o suporte e amor. E, por fim, à toda equipe, sem
exceções e incluindo terceirizados, que trabalham na Universidade Federal do Rio de
Janeiro, cada um com o seu modo de contribuir para o constante crescimento e melhora
dessa escola que tanto me ensinou.
RESUMO
Este trabalho tem o intuito de fazer uso do conceito de Internet das Coisas
trazendo mais segurança e bem-estar juntamente com privacidade. O projeto consiste
em um detector de quedas seguidas de desmaio, principalmente voltado para os idosos
visto que estas quedas seguidas de desmaio são facilmente detectáveis. Apesar do
aparelho utilizado não possuir uma gama muito grande de sensores disponíveis, apenas
o acelerômetro é necessário. O processo de detecção de quedas ocorre em um
smartwatch que, posteriormente, mede a frequência cardíaca do usuário e envia esses
dados via bluetooth a um smartphone. Este último é responsável por adquirir a
localização do usuário e concatená-la à mensagem final que será enviada via SMS para
outra pessoa. Outra funcionalidade do relógio é o botão de emergência que, quando
pressionado, automaticamente manda uma mensagem para um número pré cadastrado,
sem ter que passar por todo o processo de detecção de queda.
Palavras-chave: Internet das Coisas, tecnologias vestíveis, smartwatch, smartphone,
detecção de quedas, quedas da própria altura
ABSTRACT
This project was designed to be an application based on the Internet of Things,
bringing more safety and well-being, along with privacy. It consists of a fall detector
mainly for the elderly, aiming a fall followed by unconsciousness. Despite the gadget
doesn’t have many resources (sensors) available, just the accelerometer is necessary.
The fall detection process occurs on a smartwatch which then measures the users’ heart
rate and sends this information through bluetooth to a smartphone. The latter is
responsible for acquiring the users’ location and appending it to the final message which
will be sent via SMS to another person. Other feature of the project is the ‘Emergency
button’ that, when pressed, automatically sends a message to someone else (a pre-
registered number), without going through all the fall detection process.
SIGLAS
CSS – Cascading Style Sheets
Dll – Dynamic-link library
GPS – Global Positioning System
HMM – Hidden Markov Model
IDE – Integrated Development Environment
IoT – Internet of Things
LTE – Long-Term Evolution
SAP – Samsung Accessory Protocol
SDK – Software Development Kit
SMS – Short Message Service
SOA – Service Oriented Architecture
TCE – Traumatismo Cranioencefálico
UFRJ – Universidade Federal do Rio de Janeiro
XML – Extensible Markup Language
Sumário
1 Introdução 1
1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Fundamentação Teórica 4
2.1 - Quedas da Própria Altura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 - Tecnologias Vestíveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 - Apresentação das Plataformas . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 - Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 - Algoritmos de Detecção de Queda Existentes . . . . . . . . . . . 20
3 Solução 23
3.1 - Descrição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 - Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 - Arquitetura da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 - Implementação da Solução . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 - Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Conclusão
41
5 Bibliografia 43
6 Anexo A
46
7 Anexo B 48
1
Capítulo 1
Introdução
1.1 – Tema
O tema do trabalho é o desenvolvimento de um software para Smartwatch e
Smartphone a fim de detectar quedas da própria altura seguidas de desmaio. Logo, o
problema a ser resolvido é o uso de tecnologias vestíveis para a identificação de quedas
entre idosos ou pessoas com doenças que propiciam quedas.
1.2 – Delimitação
O objeto de estudo são os diferentes tipos de quedas da própria altura que
potencialmente podem ocorrer. Para o projeto foi utilizado um Smartwatch da Samsung
que possuía apenas um acelerômetro. Isto não permite o desenvolvimento um algoritmo
de alta complexidade, porém coaduna com a intenção de disponibilizar um aplicativo de
imediata comercialização.
Considerando o exposto, o público alvo são, portanto, os idosos e/ou pessoas
com doenças que propiciam quedas, visto que são as mais susceptíveis a sofrerem uma
queda seguida de desmaio, assim não podendo pedir ajuda.
1.3 – Justificativa
É inegável que o envelhecimento sempre foi uma preocupação da humanidade.
Atualmente, a União Europeia está se tornando cada vez mais alerta com relação a essa
questão, visto que a parcela de idosos da população tem crescido rapidamente nos
últimos anos, e irá continuar crescendo nos próximos anos [1]. Assim, uma questão que
pode ser levantada, é de como lhes dar uma vida melhor em termos de qualidade e
cuidado, mas também resguardando sua privacidade. As quedas estão, certamente, entre
as maiores razões de lesões nos idosos [2].
O crescimento exponencial da tecnologia recente, técnicas e métodos para evitar
essas quedas estão sendo desenvolvidos para que eles possam viver uma vida mais
segura. Hoje, há alguns aplicativos para Smartphone cujo objetivo é detectar quedas.
Entretanto, levando em conta que o celular provavelmente fica guardado em um bolso, a
acurácia da detecção se deteriora. A técnica da detecção feita em um aparelho no pulso
do usuário traz uma potencial melhora, visto que aquele fica com uma sensibilidade
maior ao movimento.
Nesse sentido, torna-se desejável uma solução que tange todos esses aspectos,
buscando desenvolver um algoritmo que detecte quedas da própria altura, entregando
segurança aliada a privacidade.
1.4 – Objetivos
O objetivo geral desse projeto é, então, desenvolver dois aplicativos: um no
Smartwatch, e um no Smartphone, que juntos sejam capazes de detectar quedas da
própria altura, e posteriormente, reportar essa informação a alguém. Desta forma, tem-
se como objetivos específicos: (1) desenvolver um algoritmo capaz de detectar quedas
seguidas de desmaio; (2) desenvolver um software para obter a localização do usuário;
(3) desenvolver um software para aferir a frequência cardíaca do usuário; (4)
desenvolver um software para tratar as informações recebidas do detector, concatenar
com as demais informações, e enviá-las via SMS para outro Smartphone.
1.5 – Metodologia
O projeto consistirá de duas partes: uma do lado do Smartwatch, aparelho
pertencente ao autor, e outra do lado do Smartphone, aparelho emprestado.
A primeira será feita no Tizen IDE for Wearable, com programação em
JavaScript. Como esse projeto será feito para propósitos de prototipação, haverá apenas
uma tela com os botões “Connect”, “Disconnect”, “Emergency”, “Abort”, e “Clear”, e
um log reportando o que está acontecendo num determinado momento.
Devido às limitações do projeto, o algoritmo será feito utilizando apenas um
acelerômetro. Com isso, por facilidade, as quedas estudadas serão aquelas seguidas de
desmaio, o que torna a detecção mais simples, visto que há a suposição de que o usuário
estará imóvel após a queda.
Quando uma queda for detectada, o Smartwatch irá vibrar por cinco segundos,
tempo escolhido randomicamente, com uma mensagem no log dizendo “Você está bem?
Você tem cinco segundos para abortar”. Caso o botão “Abort” seja apertado dentro dos
cinco segundos, o processo todo será cancelado. Caso contrário, o Smartwatch irá medir
a frequência cardíaca do usuário, através de um sensor embutido no Smartwatch, e
mandá-la para o Smartphone, via Bluetooth, reportando a queda. Em seguida, o
Smartphone irá, através do GPS, capturar a localização, e mandar um SMS para um
número pré-programado reportando a queda, com as informações de frequência cardíaca
e localização já com o link do Google concatenadas, para que a pessoa que receba a
mensagem apenas tenha que apertar no link e uma página do Google Maps irá abrir no
navegador, mostrando a localização do usuário.
No caso de uma queda em que, posteriormente, a pessoa fique consciente, a
queda provavelmente não será detectada. Por esta razão, um botão “Emergency” foi
implementado. Quando ele é apertado, uma mensagem dizendo “Botão de emergência
apertado” será mandada instantaneamente para o número pré-programado.
O acelerômetro (MPU-6500) utilizado tem taxa máxima de uma medida por
250us. Serão utilizadas as plataformas Android Studio para a parte do Smartphone, e
Tizen SDK para a parte do Smartwatch.
1.6 – Descrição
O capítulo 1 é a introdução do projeto.
O capítulo 2 trata de objetos de estudo para a realização do projeto. Dentre eles
estão melhores métodos para se tratar o output do sensor disponível visando detectar a
queda; algoritmo utilizado para, conjuntamente com o output do sensor, realizar a
detecção da queda, onde o usuário posteriormente fica inconsciente; algoritmo para
aferir a frequência cardíaca do usuário utilizando sensor disponível; sistema de
localização através do GPS disponível; e, por fim, método utilizado para fazer a
conexão, via Bluetooth, do relógio com o celular.
O capítulo 3 trata de justificar a utilização dos aparelhos específicos.
O capítulo 4 trata da análise dos resultados como falsos positivos, falsos
negativos.
Por fim, no capítulo 5 são realizadas as conclusões sobre o trabalho bem como a
sugestão de trabalhos futuros.
Capítulo 2
Fundamentação Teórica
2.1 – Quedas da Própria Altura
Segundo a Organização Mundial da Saude, aproximadamente 35% das pessoas
entre 75 e 85 anos sofrerão quedas no próximo ano, com graves consequências [3].
Ainda segundo esse mesmo estudo, as quedas podem ser classificadas como:
quedas da própria altura, em que a queda é acidental, como quando uma pessoa tropeça
num buraco ou cai da escada (por isso a importância da conservação e manutenção de
vias públicas e residências) e também podem ser causadas por outros fatores, como um
tapete mal colocado e sem proteção antiderrapante, animais correndo e fios soltos.
Também pode ser classificada como queda por baixa pressão arterial, que ocorre quando
nos abaixamos e há uma redução natural na pressão, podendo causar tonturas, assim
resultando em uma queda [3].
Outro estudo, realizado em Fortaleza, nos hospitais secundários e no Instituto
José Frota (IJF), mostrou que quedas da própria altura estão se tornando cada vez mais a
causa do alto número de pacientes na emergência, número esse que vem aumentando. É
maior, inclusive, que os acidentes de moto, e lidera o ranking do IJF. Em 2010, foram
6.459 ocorrências contra 6.300 envolvendo motocicletas. As queimaduras estão em
terceiro lugar, com 4.222 atendimentos [4].
Segundo a Secretaria de Estado da Saúde de São Paulo, a cada quatro dias, uma
pessoa morre por causa de um tropeção, escorregão ou queda da própria altura. No
Estado de São Paulo, foram registrados 83 óbitos em 2011. E desses, 55% eram homens
[5]."Além da qualidade e da preservação da pavimentação em que se anda, a ocorrência
de mal súbito, desmaio, labirintite ou até mesmo uma crise provocada por diabetes
podem ser possíveis causas para uma queda da própria altura", explica o supervisor
médico do Grupo de Resgate e Atendimento a Urgência (Grau) da Secretaria, Gustavo
Feriani. ” [5].
Além das estatísticas mostradas acima, que revelam a incidência e a relevância
das quedas no contexto da saúde, outro importante fator a ser considerado é o tempo
entre a queda e o atendimento, que está totalmente relacionado com o sucesso do
tratamento, caso seja necessário. A rapidez na identificação da queda pode acelerar a
abordagem à pessoa, o diagnóstico de eventual dano clínico e o início do tratamento,
que será mais eficaz e evitará riscos como sequelas. Em muitos casos, o idoso/paciente
pode estar sozinho em casa, ou então o cuidador pode demorar para achá-lo. E cada
segundo a menos pode, potencialmente, salvar sua vida.
2.2 – Tecnologias Vestíveis
2.2.1 – Internet das Coisas (IoT)
O termo Internet das Coisas (ou IoT, em inglês) tem se popularizado muito nos
últimos tempos. Refere-se, como o nome diz, a um futuro onde todas as coisas estejam
conectadas à Internet e, por consequência, conectadas entre si.
Há diversos exemplos nas mais variadas aplicações. Entretanto um deles emerge
como sendo o clássico, visto que exemplifica muito bem a ideia central do IoT. Hoje em
dia, em um evento de falta de suprimentos em uma dispensa ou geladeira de uma casa
comum, em qualquer lugar do mundo, o esperado é analisar o que está faltando por
inspeção. Essa, muitas vezes feita quando se quer consumir algo, e não por prevenção.
Posteriormente à inspeção, é feita uma lista com os itens em falta e vai-se ao mercado
comprá-los. Um exemplo da ideia do IoT é ter alguns sensores instalados nas geladeiras
e/ou dispensas para monitorar a quantidade de cada suprimento, vide Figura 1. Quando
a quantidade de um suprimento fica abaixo de um limite pré-estabelecido, um sinal será
mandado para o mercado indicando o que está faltando, e sua quantidade. Logo, sem a
pessoa sequer notar que há algo faltando na geladeira ou dispensa, uma entrega de
mercado será feita à sua casa com os itens em falta.
Figura 2.1 – Sensor na geladeira. Fonte: http://thenewstack.io/grocery-watching-refrigerators-join-internet-things/
Portanto, a geladeira, a dispensa e diversos outros aparelhos estarão conectados
à Internet com o objetivo de otimizar o uso do tempo e, no final, melhorar a qualidade
de vida de todos nós.
A informação disponível através do uso da IoT poderá ser de muita utilidade,
pois definirá melhor os usuários e seus perfis de compras. Um bom processamento
destes dados também passará a ser importante. Por exemplo, por fornecedores de
produtos e serviços em geral que, customizando suas ofertas, campanhas de marketing,
etc. |
2.2.2 – Definição e Introdução de Tecnologias Vestíveis
O termo “computação vestível” ou "tecnologia vestível" refere-se a um novo
paradigma na computação, mudando a interação homem-máquina como a que é
conhecida hoje. Os aparelhos são “vestidos” pelos usuários, e estão diretamente
conectados a eles com a intenção de tornar o usuário o mais “passivo” possível, assim
conseguindo focar no ser humano e suas necessidades. Esta tecnologia geralmente vem
aliada com alguma forma de conexão à internet, mesmo que indiretamente, portanto,
geralmente é relacionada a Internet das Coisas [6].
A figura 2.2 ilustra alguns dos possíveis aparelhos que podem ser integrados e,
portanto, podem vir a ser peças importantes no IoT.
Figura 2.2 – Internet of Things. Fonte: https://www.shutterstock.com/search/internet+of+things+and+services
Assim, é possível observar como IoT e tecnologias vestíveis estão intimamente
ligadas. As tecnologias vestíveis vieram como uma forma de se alcançar IoT, como uma
ferramenta.
Uma forma de aliar as tecnologias vestíveis ao exemplo anterior, seria enviando
um sinal ao Smartwatch do proprietário da casa quando algum suprimento estiver
acabando, avisando que uma compra será feita. O usuário pode confirmar, ou até
mesmo incluir a automação do pagamento no processo.
Com isso, percebe-se o enorme potencial de mudança que essa nova tecnologia,
ainda em fase de maturação, pode nos proporcionar. Com as maiores empresas de
tecnologia do mundo atual investindo fortemente e contribuindo mutuamente para
alavancar o avanço dessa tecnologia, as probabilidades de ela virar realidade, num
futuro próximo, crescem significativamente.
2.2.3 – Relógios e Smartphones
Dentro do universo deste projeto, a principal tecnologia vestível é o Smartwatch,
que, conectando-se com o Smartphone para obter dados e acesso à Internet, tem um
potencial que vai muito além de informar o horário.
Smartphones são celulares com um sistema operacional avançado que
combinam as características de um computador pessoal como calendário, jogos, música,
câmera, GPS, e alguns sensores; e as de um celular como chamadas de voz, troca de
mensagens de texto. Com o advento da internet móvel, hoje é possível ter internet
3G/4G/LTE em um smartphone, assim abrindo o leque de usabilidade do aparelho.
Hoje em dia, os Smartwatches (ou “relógios inteligentes”) vêm se popularizando
muito devido a sua larga aplicabilidade. Uma de suas principais funções é entregar ao
usuário dados prontamente, sem a necessidade de ter que tirar o Smartphone do bolso.
Entretanto, a possibilidade de programar aplicativos nessa plataforma faz com
que a aplicabilidade do aparelho fique no nível da imaginação de quem o faz. Além
disso, dado que o aparelho pode obter Internet através do Smartphone, seu papel como
ferramenta de IoT fica cada vez mais próximo da realidade.
Segundo estudo [7], atualmente no Brasil, as cinco tecnologias vestíveis mais
desejadas são: botão do pânico com 58%; smartwatch com 50%, autenticador de
identidade com 42%, rastreador de atividade fitness com 42% e purificador de água
inteligente com 41%.
Ainda segundo esse estudo, 31% dos usuários de smartphones no Brasil, com
idades entre 15 e 65 anos, já utilizam ou possuem uma tecnologia vestível. A mais
popular são smartwatches (45%) e rastreadores fitness (43%). Relógios inteligentes são
mais atraentes para homens; e cintas fitness para mulheres. Além disso, três quartos dos
usuários de tecnologias vestíveis as recomendariam para outras pessoas no Brasil,
enquanto que apenas a metade dos usuários globais faria o mesmo [7].
2.3 – Apresentação das plataformas
Neste tópico serão apresentadas as duas principais plataformas utilizadas no
projeto, cada uma com o intuito de desenvolver um software em um dispositivo
diferente. Por fim, será apresentado o Samsung Accessory Protocol (SAP) utilizado para
a comunicação entre os dois.
2.3.1 – Android Studio
O Android Studio é o ambiente de desenvolvimento integrado (IDE) oficial para
o desenvolvimento de aplicativos Android e é baseado no IntelliJ IDEA (outra famosa
IDE para desenvolvimento em Java). Além do editor de código e das ferramentas de
desenvolvedor avançados do IntelliJ, o Android Studio oferece ainda mais recursos para
aumentar sua produtividade na criação de aplicativos Android, como:
Um sistema de compilação flexível baseado no Gradle (famoso sistema de au-
tomação de “build”)
Um emulador rápido com muitos recursos, portanto não sendo necessário um
aparelho físico para executar uma aplicação.
Um ambiente unificado onde você pode desenvolver para todos os dispositivos
Android
“Instant Run” para enviar alterações a aplicativos em execução sem compilar um
novo APK (Android Application Package – usado para a distribuição e instalação de
aplicativos mobile), assim com um processo de “build and run” mais rápido e efici-
ente.
Modelos de códigos e integração com GitHub (repositório) para ajudar a criar
recursos comuns de aplicativos e importar exemplos de código, assim possibilitando
um trabalho em conjunto mais eficiente.
Ferramentas e estruturas de teste.
Compatibilidade com C++
Cada projeto no Android Studio contém um ou mais módulos com arquivos de
código-fonte e recursos. Os tipos de módulos incluem:
Módulos de aplicativos Android
Módulos de bibliotecas
Por padrão, o Android Studio exibe os arquivos de projeto na visualização de
projeto Android, como mostrado na figura 2.2. Essa visualização é organizada por mó-
dulos para permitir o acesso rápido aos principais arquivos de origem do projeto.
Figura 2.2 – Barra Android. Fonte: Projeto Fall Detector
No caso de um deploy em um aparelho físico ao invés da utilização do emula-
dor, haverá a necessidade de habilitar o modo developer no smartphone. Isso deverá
ser feito para que se permita a troca de arquivos entre a plataforma e o aparelho via
USB.
Uma aplicação pode ser dividida entre algumas atividades (ou “activities”), que
são, em termos gerais, janelas de interação com o usuário, portanto, janelas de inter-
face gráfica. Estas geralmente irão se comunicar entre si através do disparo de even-
tos, como o clique de um botão. Com isso, haverá uma atividade principal na qual o
aplicativo se inicia. Esta deve ser especificada no campo “Launch Options” dentro de
“Edit Configurations” na aba “Run”. Caso o programa seja um processo que executa
em segundo plano, tal campo deve ficar marcado como “Nothing”. Assim, quando o
aplicativo compilar e executar, não irá procurar uma atividade principal para execu-
tar, logo não será criado um aplicativo físico no aparelho, apenas um processo.
Todos os arquivos da compilação podem ser vistos no nível superior em Gradle
Scripts e cada módulo de aplicativo contém as pastas: manifests, java, assets, e res.
o Manifests: contém o arquivo AndroidManifest.xml.
o Java: contém os arquivos de código-fonte do Java, incluindo o main e o
código de teste.
o Assets: contém os arquivos com extensão wgt.
o Res: contém todos os recursos que não são código, como layouts XML,
strings de IU e imagens em bitmap.
O manifest é um arquivo com extensão xml (AndroidManifest.xml - precisa-
mente com esse nome), vide figura 2.4, obrigatório em todos os aplicativos Android.
Sua principal função é a de apresentar informações importantes ao sistema antes de exe-
cutar o código do aplicativo [8]. Entre outras coisas, serve para:
Nomear o pacote java, que serve como um identificador exclusivo para o aplica-
tivo
Descrever os componentes do aplicativo: atividades (activity), serviços, recepto-
res, e provedores de conteúdo.
Nomear as classes que implementam tais componentes, como por exemplo a
classe “Intent”, que serve como um comunicador, uma interface entre partes do
aplicativo (activities), e delas com serviços externos.
Declarar permissões que o aplicativo deve ter para acessar outros aplicativos, e
permissões que outros aplicativos devem ter para acessar o aplicativo.
Listar bibliotecas que o aplicativo usa.
Figura 2.4 – Arquivo manifest. Fonte: Projeto Fall Detector
A pasta Java composta basicamente por códigos-fonte em Java, com a definição
das classes que o aplicativo utiliza. Nesse sentido, os códigos-fonte nessa pasta são rela-
tivos à lógica do aplicativo, ao “back-end”. Além disso, caso o desenvolvedor queira
desenvolver códigos de teste, o mesmo também seria colocado na pasta Java.
Portanto, é obrigatório uma classe “main” com o código principal, e podem ha-
ver classes auxiliares que funcionam como ferramentas à classe principal.
A pasta Assets é composta por dois arquivos com extensão wgt que desempe-
nham papéis de consumidor e produtor. Um deles será relativo ao próprio aplicativo
Android, e o outro a qualquer aparelho vestível da Samsung que tenha compatibilidade
com o Android. A definição de qual será o consumidor e qual será o provedor dependerá
do tipo de aplicação.
A pasta Res é composta por arquivos do design da aplicação, portanto ao “front-
end”, e arquivos com recursos da aplicação em geral como constantes e configurações.
Dentro desta pasta há mais 4 pastas:
1 – Drawable: pode conter imagens a ser utilizadas no aplicativo;
2 – Layout: contém um arquivo xml relativo às características do design do aplicativo
efetivamente, tais como: largura, comprimento, botões de interação e design gráfico em
geral.
3 – Values: contém arquivos com alguns valores constantes a serem utilizados, como
largura, comprimento, nomes e outros.
4 – Xml: pode conter um arquivo de configuração do serviço.
2.3.2 – Tizen IDE
Tizen é uma plataforma “open-source” de desenvolvimento de software para
múltiplos aparelhos, incluindo: Smartphones, aparelhos vestíveis, tablets, netbooks,
smart TVs e outros.
O Tizen conta com um sistema operacional inovador, um ambiente de
desenvolvimento integrado (IDE), vide figura 2.5, e também oferece portabilidade entre
os diversos aparelhos.
Em contraste com o Android Studio, que é largamente utilizado para o
desenvolvimento de aplicativos em Smartphone, o Tizen IDE ainda é uma tecnologia
pouco documentada na Internet, visto que sua principal funcionalidade é desenvolver
softwares para tecnologias vestíveis, ainda muito recentes no mercado.
Há dois principais tipos de aplicação que podem ser desenvolvidas com o Tizen
no âmbito de tecnologias vestíveis: “Wearable Web Application” e “Wearable Native
Application”. A primeira é uma aplicação web que, basicamente, é um site que ficará
armazenado no aparelho. Logo, suas principais tecnologias são HTML5, CSS e
JavaScript. Já a segunda, “Wearable Native Application”, é uma aplicação nativa que
possui inúmeras interfaces com o hardware do aparelho, assim tornando possível tirar
proveito de várias funcionalidades do mesmo. Logo, sua principal linguagem de
programação é a linguagem C.
Tais aplicações podem ser comparadas de acordo com o seu melhor propósito.
Como a primeira aplicação é web, se faz mais vantajosa para criar softwares que
possuem interface com outros dispositivos externos, utilizando-se de uma camada de
serviço para tal. Por outro lado, a segunda aplicação, sendo nativa, se mostra mais
vantajosa para tirar proveito das funcionalidades internas do aparelho.
Portanto, dado esse enorme leque de funcionalidades e interações, essa
plataforma se torna uma importante ferramenta, com enorme potencial para a criação de
novas tecnologias na área de IoT.
Figura 2.5 – Tizen IDE. Fonte: Projeto Fall Detector
No caso de uma aplicação web, o projeto principal consiste de quatro pastas –
css, js, lib e res – e três arquivos principais. São eles: config.xml, um arquivo com
extensão wgt, e um index.html.
O config é um arquivo de configuração do aplicativo como definição de nome,
versão, e imagem do executável, além de guardar informações de “features” e
“privileges” que são, resumidamente, onde serão colocadas as referências para as
bibliotecas externas utilizadas pelo aplicativo.
O arquivo com extensão wgt é o arquivo do programa compilado, portanto é o
que será passado para o aparelho no qual o aplicativo irá executar. No caso de uma
aplicação orientada a serviço, onde há a comunicação entre 2 dispositivos, este arquivo
deverá ser copiado para a pasta assets do projeto do outro dispositivo. Isso será
explicado com mais detalhes à frente.
O index é um arquivo em HTML onde será desenvolvida a estrutura da tela do
aplicativo, portanto onde cada componente ficará localizado e o que acontece caso
houver um evento, como por exemplo um clique.
A pasta css é composta por um arquivo em CSS que é responsável pelo “front-
end” do aplicativo, pela definição das características da tela, portanto, seu design, como
por exemplo cor e tamanho dos componentes.
A pasta js é composta por arquivos em JavaScript, que é responsável pelo “back-
end” do aplicativo, portanto sua lógica por trás do funcionamento do mesmo. No caso
de um software complexo, poderá haver mais de um arquivo em JavaScript. Entretanto,
um deles será o principal, e os outros auxiliares.
A pasta lib vem do termo “library” – inglês para bibliotecas. Portanto, lá ficarão
as bibliotecas utilizadas pelo sistema, assim como algumas licenças.
Finalmente, a pasta res é composta por um arquivo em xml com os recursos
utilizados, como a configuração de um serviço no caso de um software orientado a
serviço.
Um outro importante recurso presente na plataforma é o emulador, visto que, com ele,
não se faz necessário a presença de um dispositivo físico. Devido à escassez de
documentação online e das burocracias de certificação com o aparelho físico, que torna
a sua conexão bem complexa e cansativa para o desenvolvedor, é preferível que se
utilize o emulador. Com isso contornando a questão de certificação e tirando a
necessidade de ter o aparelho físico. Entretanto, a conexão com esse último é muito
importante para o caso em que há algum aspecto do aplicativo que não dê para simular
no emulador, como alguma movimentação com o dispositivo vestível. Portanto, faz-se
necessário o entendimento do procedimento de conexão de um dispositivo físico com a
plataforma.
Primeiramente, o modo de desenvolvedor tem que ser ativado no dispositivo,
clicando no campo “Enable Debugging”, nas configurações do aparelho. Este passo é
necessário para que seja possível a troca de arquivos entre o dispositivo e a plataforma,
via USB.
Em seguida, o aparelho tem que ser certificado clicando no botão “Register
Certificate”, no IDE. Posteriormente, cria-se um perfil de segurança, um certificado do
autor, e um certificado do distribuidor.
No primeiro, será necessário apenas o nome do perfil. No segundo, cria-se uma
senha para que seja possível utilizar tal certificado de outro computador. Por fim, no
terceiro (ver figura 2.6), quando o dispositivo estiver conectado via USB, o mesmo irá
aparecer na tela de criação de registro de distribuidor para que seja registrado. Também
é necessária a criação de uma senha. O campo “Privilege” será preenchido de acordo
com os privilégios utilizados na aplicação.
Durante esse processo, será pedido para que o desenvolvedor entre com suas
credenciais de usuário do site da Samsung. Portanto, caso ele não possua uma conta,
deverá cria-la. Estas etapas são essenciais para fazer o deploy do aplicativo em um
dispositivo físico.
Figura 2.6 – Tizen IDE – Registro de Certificado. Fonte: Projeto Fall Detector
2.3.3 – Samsung Accessory Protocol (SAP)
O Samsung Accessory Protocol, ou SAP, é uma interface de serviço criada pela
Samsung para tornar possível a comunicação entre os diversos aparelhos da marca,
como Smartwatches, Smartphones, Smart TVs, e outros (figura 2.7). Além disso,
desenvolvedores independentes também podem usufruir da ferramenta para criarem
seus próprios aplicativos que possuem comunicação entre dispositivos Samsung.
Figura 2.7 – Entendendo SAP. Fonte: https://www.youtube.com/watch?v=VzoUeBS71jQ
Esta é uma ferramenta muito poderosa que abriu um grande leque de novas
possibilidades para os desenvolvedores, visto que, com ela, é possível pensar mais
realisticamente em IoT. Como já foi explicado anteriormente, a base desse novo
paradigma, que se mostra cada vez mais alcançável, é um mundo onde todas as “coisas”
estarão conectadas à Internet e entre si mesmas. Portanto, uma ferramenta que permita
isso, é considerada de suma importância.
A metodologia do SAP e seu propósito são razoavelmente fáceis de se
compreender. Em termos gerais, esse protocolo permitirá que os dispositivos Samsung
se comuniquem via Bluetooth, trocando informações livremente. Portanto, pode-se
pensar nos aparelhos conectados entre si como um só, visto que poderão utilizar-se de
seus próprios artifícios como sensores, atuadores, GPS, Internet, e posteriormente
enviar o output do seu processamento para um outro aparelho, assim tornando-se mais
integrado.
Entretanto, com a versão atual do SAP, o aparelho Android deverá ter no mínimo
o sistema operacional Android 4.3 instalado. Além disso, são necessárias outras
complexas configurações de serviço e concessão de privilégios. Portanto, para facilitar,
a Samsung criou alguns arquivos de amostra com algumas das configurações mais
usadas para servir como um esqueleto ao desenvolvedor e diminuir a complexidade da
interface de serviço. As amostras estão divididas em aplicações web e aplicações
nativas. Dentro destas, há uma outra divisão com os exemplos mais comuns, como
transferência de arquivos, segurança habilitada (transferência de texto simples com
autenticação), multiplicidade (múltiplos consumidores), galeria (transferência de
imagens), e a estrutura provedor-consumidor (transferência de texto simples). Serão
apresentados mais detalhes desta última aplicação. As amostras podem ser encontradas
no site de desenvolvimento da Samsung [9].
2.4 – Bibliotecas
Nesse módulo serão apresentadas algumas bibliotecas e esqueletos de código
utilizados no projeto, tanto no lado do Android como no lado do relógio.
2.4.1 – Consumer-Provider
Como já destacado anteriormente, essa estrutura pode ser baixada do site de
desenvolvedores da Samsung, e foi feita para que o desenvolvedor consiga focar mais
em seu projeto/trabalho do que em configurações de serviço. Desta forma, a não ser que
se queira uma configuração muito customizada, muito provavelmente alguma das
amostras irá servir bem como esqueleto para a interface de serviço.
Hoje em dia, um dos paradigmas de programação mais utilizados é o de
orientação a objeto, que realmente se mostra muito útil e eficiente em diversas
aplicações. Entretanto, há outros que também têm sua importância, como a orientação a
serviço, que mostra seu valor quando utilizado em softwares onde há uma comunicação
entre aplicações através de um protocolo de comunicação. Com isso, é importante notar
que esse esqueleto é um grande passo para se alcançar o software orientado a serviço
(SOA, em inglês). Muitas vezes, é uma boa prática para que os módulos de cliente e
serviço fiquem independentes e reutilizáveis, assim tornando o software mais robusto.
Dito isso, a estrutura de consumidor-produtor fornecida pela Samsung
basicamente reflete a responsabilidade de cada dispositivo na aplicação. O dispositivo
que faz o pedido de conexão é o consumidor, e o que aceita tal pedido é o provedor.
Abaixo estão as principais características do caso da amostra em que um Smartphone
Android é o provedor, e um Smartwatch Gear é o consumidor, em uma aplicação web
(ver figura 2.8).
Figura 2.8 – Estrutura consumidor-provedor. Fonte: http://developer.samsung.com/gear/develop/samples/companion/hello-web
Provedor (android):
Fica hospedado no dispositivo “host”, mas não tem interface gráfica
Aceita um pedido de conexão de serviço do Gear
Responde a comandos do Gear com informações de data/hora
Consumidor (Gear):
Fica hospedado no Gear e tem interface gráfica
Inicializa o pedido de conexão de serviço e envia comandos para o
dispositivo “host”
Mostra uma resposta recebida para o usuário
No lado do Smartwatch, adiciona-se um privilégio no arquivo config.xml:
<tizen:privilege
name="http://developer.samsung.com/privilege/accessoryprotocol"/>
No lado do Smartphone, para usar o protocolo de comunicação de Bluetooth,
adicionamos no AndroidManifest.xml:
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission an-
droid:name="com.samsung.accessory.permission.ACCESSORY_FRAMEWORK" />
Outro aspecto importante é que, como não são utilizados robôs de integração
contínua, que seriam responsáveis pelo gerenciamento de repositórios, versionamento e
distribuição do software, faz-se necessário, a cada nova versão do lado do Smartwatch,
compilar tal versão – o que irá gerar um arquivo com extensão wgt – e copiar a versão
compilada (o arquivo wgt) para a pasta assets do programa com o qual ele irá se
comunicar no Android Studio.
2.5 – Algoritmos de Detecção de Queda Existentes
Atualmente, é possível achar muitos trabalhos com o objetivo de detectar que-
das, alguns mais robustos que outros. Porém todos utilizam acelerômetros e/ou giroscó-
pios em diferentes contextos e de diferentes modos.
Alguns confeccionaram placas eletrônicas e a prenderam a algum lugar do corpo do
usuário, como um adesivo, o que se mostra vantajoso porque podem prendê-la no lugar
onde é mais fácil de se detectar a queda. Em contrapartida, é mais invasivo para o usuá-
rio, visto que não é um dispositivo normal em sua vida. Essa versão pode ser vista em
[10].
Outros desenvolveram um cinto que fica na altura do peitoral. Por exemplo [11].
Entretanto possui o mesmo princípio do adesivo, portanto tem vantagens e desvantagens
similares.
Há outro exemplo em que foi usado o próprio Smartphone do usuário para de-
tectar a queda, logo tem a vantagem de não ser invasivo. Pelo contrário, acaba sendo
apenas um aplicativo que o usuário tem que instalar em seu celular. Por outro lado, co-
mo geralmente o celular fica no bolso, a queda fica mais difícil de ser detectada, assim o
algoritmo para tal se torna menos eficiente. Esse exemplo pode ser visto em [12].
Por fim, há também relógios inteiramente fabricados com o objetivo de detectar
quedas. Eles têm a vantagem de ficar em um lugar onde é fácil de se detectar uma que-
da, mas acabam sendo caros e, como só desempenham uma função, ficam com usabili-
dade restrita.
É interessante apontar que a extensa maioria desses trabalhos utiliza acelerôme-
tro de três eixos, e a fórmula da magnitude da aceleração de alguma forma, que pode ser
vista abaixo, com o ‘x’, ‘y’ e ‘z’ sendo a aceleração nos eixos ‘x’, ‘y’, e ‘z’, respectiva-
mente. Alguns utilizam apenas tal fórmula, e outros vão mais além, com algoritmos
mais complexos.
Como pode ser visto em [12], tal fórmula é utilizada com um limiar superior e
um inferior. Se a magnitude tiver um pico que ultrapassa o limiar superior e, posterior-
mente outro pico, menor que o primeiro, mas acima do limiar inferior, e depois voltar
para o valor normal, uma queda será detectada.
Em outro exemplo como em [13], também é usada uma metodologia com limiar
superior e inferior. Entretanto uma queda será detectada quando houver um pico ultra-
passando o limiar superior, e um pico de mínimo menor que o limiar inferior.
O único exemplo encontrado em que não foi utilizada a fórmula da magnitude,
foi em [14], onde o autor utiliza a fórmula do gasto de energia dado pela soma da inte-
gração do quadrado da aceleração dinâmica do usuário, multiplicada por um coeficiente
que, no caso, tem o valor um.
Em outro projeto, usando a fórmula da magnitude, detectava-se se havia um mí-
nimo (início da queda) seguido de um pico de máximo (impacto), numa janela de 1,5
segundos. O exemplo pode ser visto em [15].
No universo de algoritmos mais complexos, há um que tenta aliar mineração de
dados com a detecção. É utilizado um modelo chamado hidden Markov model (HMM)
para fazer o treinamento e o teste dos dados (ver figura 2.9). E os parâmetros utilizados
nesse modelo são: a magnitude da aceleração (Asvm, na figura), e algumas variantes
dela. Contudo, para a utilização dessa metodologia de machine learning, há a necessida-
de de um pesado processamento, portanto necessita de muito recurso computacional, o
que torna esta aplicação difícil de ser implementada. Esse exemplo pode ser visto em
[11].
Figura 2.9 – Método HMM Fonte: https://www.hindawi.com/journals/jam/2014/896030/
Em suma, é possível observar a utilização de diversos dispositivos, em diversos
lugares, com diversos algoritmos. Cada um com suas vantagens e desvantagens. Porém
quase todos se utilizam de acelerômetros, e da fórmula da magnitude da aceleração.
Portanto espero, com esse projeto, contribuir com o desenvolvimento dessa área de es-
tudo importante e com grande potencial, alcançando uma forma fácil e eficiente de de-
tectar quedas.
Capítulo 3
Solução
3.1 – Descrição do Problema
O principal problema a ser resolvido é o do longo período de tempo que um
indivíduo pode ter que esperar no caso de uma queda da própria altura seguida de
desmaio. Além disso, caso ele permaneça consciente, pode não ter acesso a um meio
para comunicar alguém. Nesse último caso, também pode ocorrer de o indivíduo se
lesionar seriamente e não conseguir alcançar algum meio de comunicação.
Um fator alarmante desse problema é a possibilidade de ocorrência de
consequências graves que podem ser agravadas pelo atendimento tardio, como sequelas,
que podem ocorrer quando o indivíduo perde a consciência após a queda e não consegue
alertar outras pessoas.
Segundo o CDC (Center for Disease Control and Prevention) [16], a cada ano
milhões de idosos sofrem algum tipo de queda. Mais de um a cada quatro sofre uma
queda por ano, mas menos da metade avisa ao médico. Alguns dados dos Estados
Unidos que chamam a atenção para o problema:
Uma dentre cinco quedas resulta em uma consequência grave, como uma fratura
ou trauma craniano.
A cada ano, 2,8 milhões de pessoas vão às emergências por causa de uma queda.
Mais de 800 mil pacientes são hospitalizados por ano por causa de um trauma
craniano ou fratura de quadril causados por uma queda.
A cada ano, ao menos 300 mil pessoas são hospitalizadas devido a fraturas de
quadril.
Mais de 95% das fraturas de quadril são causadas por uma queda lateral.
Quedas são a causa mais comum de TCE (traumatismo crânioencefálico).
Os custos médicos de traumas por uma queda, ajustados pela inflação, são de 31
bilhões de dólares por ano.
Segundo a figura 3.1, o número das mortes causadas por quedas vem
aumentando progressivamente a cada ano.
Figura 3.1 – Morte por quedas não intencionais por ano Fonte: http://www.cdc.gov/homeandrecreationalsafety/falls/adultfalls.html
Além disso, um problema colateral identificado está relacionado com a tentativa
de alcançar a solução desse problema, sem invadir a privacidade do indivíduo, isto é,
sem câmeras ou sensores visuais.
3.2 – Solução Proposta
A solução para o problema baseia-se em um sistema de detecção de quedas
seguidas de desmaio, visando, assim, diminuir o problema do longo tempo entre a
queda e a identificação da mesma, caso o indivíduo fique inconsciente. O sistema terá
uma opção para reportar uma emergência, de um modo prático e de fácil acessibilidade.
Com isso, caso o usuário tenha uma lesão grave que o impossibilite de se mover, como
uma fratura, poderá pedir ajuda com mais facilidade.
Além disso, a detecção da queda será especializada para aquelas seguidas de
desmaio, visto que estes casos são mais fáceis de se identificar, além de potencialmente
oferecem maior perigo. Com isso, é esperado uma maior precisão na detecção das
quedas, assim como um sistema que consiga aliar confiabilidade e segurança.
Há, também, outras funcionalidades secundárias no sistema para adicionar maior
robustez a ele, como a medição da frequência cardíaca do usuário e a identificação de
sua localização. Espera-se enviar uma informação mais detalhada para que quem as
receba possa ter mais informações sobre o ocorrido, assim tirando conclusões mais
precisas e fundamentadas.
Outro importante problema que a solução tenta contornar, é o da privacidade do
usuário. Hoje, grande parte dos monitoramentos é feito por câmeras de segurança ou
outros dispositivos visuais (vide figura 3.2). Com o sistema de detecção de quedas, isso
não será necessário, visto que são utilizados acelerômetros.
Figura 3.2 – Detecção de queda via sensor visual Fonte: http://fivedots.coe.psu.ac.th/~kom/?p=622
3.3 – Arquitetura da Solução
A figura 3.3 mostra a arquitetura da solução como um diagrama de
componentes. A objetivo é deixar todo o processamento da detecção para o relógio,
assim como a medição da frequência cardíaca, e enviar esses dados via interface.
Figura 3.3 – Diagrama de Componentes Fonte: Projeto Fall Detector
O celular terá o papel de receber os dados e transmiti-los para o mundo externo,
possivelmente um médico ou parente. Além disso, terá a funcionalidade de detectar a
localização do usuário.
Dito isto, o fluxograma natural do sistema começará com o usuário solicitando,
a partir do relógio, uma conexão com o celular. Caso a conexão seja estabelecida com
sucesso, este irá responder com um “reply” indicando isto. Quando o relógio receber a
confirmação, irá disparar o início do algoritmo de detecção de queda, que é o
componente principal do sistema.
Caso o algoritmo detecte uma queda, irá criar uma notificação informando que
uma queda foi detectada, e passará para a medição de frequência cardíaca, que será feita
através de um sensor já embutido no relógio. Com isso, essa segunda notificação de
informação cardíaca será enviada para o celular através da interface. Assim, quando as
notificações forem recebidas no celular, o mesmo irá detectar a localização do usuário, e
concatenar tais dados. Por fim, um tipo de comunicação será utilizado para enviar o
dado ao mundo externo, com todas as informações coletadas pelos diferentes blocos do
sistema.
Outra funcionalidade do relógio é o botão de emergência que, quando clicado,
irá disparar o envio de dados para o celular, funcionando como um “bypass” da etapa da
detecção da queda. Como é possível observar através da imagem, tal funcionalidade não
terá a medição da frequência cardíaca, entretanto terá a localização.
3.4 – Implementação da Solução
O aplicativo pode ser visto na figura 3.4:
Figura 3.4 – Aplicativo Fonte: Projeto Fall Detector
Ao clicar no aplicativo, a tela inicial será aberta, conforme a figura 3.5.
Figura 3.5 – Tela Inicial Fonte: Projeto Fall Detector
O algoritmo utilizado, que foi desenvolvido pelo autor, começa com o usuário
solicitando a conexão ao celular através do botão ‘Connect’. Posteriormente, o celular
irá responder com uma mensagem - ‘connection reply’ - avisando que a conexão foi
estabelecida com sucesso (vide figura 3.6).
Figura 3.6 – Connection Reply Fonte: Projeto Fall Detector
Esta é uma conexão via Bluetooth, utilizando o método SAP, já explicado
anteriormente. O código contendo toda a parte de conexão pode ser visto no anexo A.
Com isso, será disparado um listener que fica monitorando o acelerômetro até sua
magnitude atingir 25 metros por segundo ao quadrado, conforme o código a seguir:
function start() { try { stop = 0; // Variable to enter the 'if' statement only
once (because of the listener) window.addEventListener( 'devicemotion', function listen(
e ) { ax = e.accelerationIncludingGravity.x;
ay = -e.accelerationIncludingGravity.y;
az = -e.accelerationIncludingGravity.z;
mag = Math.sqrt(Math.pow(ax,2) + Math.pow(ay,2) +
Math.pow(az,2));
if (mag>25 && stop === 0){ stop = 1;
stbTime = stabilizationTime;
intervalWait = setInterval(wait,1000);
}
} );
} catch(err) { console.log("exception [" + err.name + "] msg[" +
err.message + "]"); disconnect(); }
}
Quando tal magnitude é atingida, há um eríodo chamado tempo de estabilização
(escolhido ad hoc como 4 segundos), que se estipulou como o tempo de queda do
usuário. Desta frma, isto representa o tempo entre o começo da queda, com o usuário
em pé, e o fim da queda, com o usuário no chão. A função ‘setInterval’ irá chamar a
função ‘wait’ de 1000 milisegundos em 1000 milisegundos até que seja dado um ‘clear’
na variável ‘intervalWait’. O contador com o tempo de estabilização pode ser visto a
seguir:
function wait() { //Wait for the stabilization time (time to fall) stbTime--;
if (stbTime === 0) { clearInterval(intervalWait);
stTime = 0;
move = 0;
intervalStationary = setInterval(stationary,50); //periods
of 50ms because it's close to the minimum time needed to make an in-
crement } }
Posteriormente, haverá o intervalo estacionário, utilizado para checar se o
usuário, já no chão, está se movendo. Isto será feito com o disparo de outro contador.
Porém, agora uma outra função, stationary, será chamada a cada 50 milisegundos,
checando se o usuário se moveu, ou seja, se a magnitude da aceleração foi menor do que
9.3 ou maior do que 10.9. Para tal, novamente a função setInterval foi utilizada. O
contador com o período estacionário pode ser visto em:
function stationary(){ //Check to see whether the user is stationary
or not stTime = stTime + 50;
if(mag < 9.3 || mag > 10.9) { //User is moving move = 1;
clearInterval(intervalStationary);
createHTML("Moved"); start();
}
if (stTime === stationaryTime && move === 0) { clearInterval(intervalStationary);
abt=0; // Variable to abort operation if abort button is
pressed abtTime = abortTime; // Time to abort operation
tizen.application.launch("qWtLgYR8IM.HelloAccessoryConsumer",
function () { //to launch application if it's on the background delay = setInterval(delayfunc,200); // function to
delay so vibration works }); }
}
Com isso, caso o usuário tenha se movido, o algoritmo irá voltar ao estágio
inicial com o listener monitorando o acelerômetro. Este caso pode ser visto na figura
3.7.
Figura 3.7 – Usuário se moveu após a queda (consciente) Fonte: Projeto Fall Detector
Caso contrário, a função tizen.application.launch será chamada para reabrir o
aplicativo (caso ele esteja em segundo plano) e irá chamar a função delayfunc que pode
ser vista a seguir:
function delayfunc() { clearInterval(delay);
tizen.power.request("SCREEN", "SCREEN_NORMAL"); createHTML("Are you OK? You have " + abortTime.toString() + "
seconds to abort" ); navigator.vibrate([500,500,500,500,500,500,500,500,500,500]); intervalDetect = setInterval(detected, 1000);
}
Tal função irá criar no log uma mensagem perguntando se está tudo bem e
avisando que há 5 segundos para o usuário abortar através do botão ‘Abort’, que pode
ser visto na figura 3.8.
Figura 3.8 – Opção de abortar após uma queda detectada Fonte: Projeto Fall Detector
Caso o usuário o faça, o processo de detecção será cancelado e o algoritmo
voltará ao estágio inicial de monitoramento da aceleração. A função ‘abort’ será
chamada no evento do clique do botão:
function abort() { //Button to abort abt = 1;
}
Este caso pode ser observado na figura 3.9
Figura 3.9 – Botão de abortar pressionado Fonte: Projeto Fall Detector
Caso contrário, será aferida a frequência cardíaca do usuário através da função
webapis.motion.start, conforme o código a seguir:
function detected(){ abtTime--;
if(abtTime === 0 && abt === 0) { clearInterval(intervalDetect);
createHTML("Time's up! Fall Detected. Measuring heart
rate..."); average = 0;
tries = 0;
heartRate = 0;
webapis.motion.start("HRM", onchangedCB); }
if(abtTime === 0 && abt === 1) { clearInterval(intervalDetect);
createHTML("Aborted"); tizen.power.release("SCREEN"); start(); }
}
Dado que o método MotionHRMInfo.heartRate da função onchangedCB retorna
apenas uma medida da frequência cardíaca, é provável que ela seja relativamente
imprecisa. Portanto, tal função possui um loop para calcular a média das medidas, assim
visando aumentar a precisão da mesma:
function onchangedCB(MotionHRMInfo) { tries++;
if (MotionHRMInfo.heartRate > 0) { average++;
heartRate = heartRate + MotionHRMInfo.heartRate;
}
if (heartRate > 0 && tries === 100) { heartRate = heartRate/average;
createHTML("Heart Rate: " +
Math.round(heartRate).toString()); SASocket.setDataReceiveListener(onreceive);
SASocket.sendData(CHANNELID, "Fall Detected" + "\n" +
"Heart Rate: " + Math.round(heartRate).toString()); webapis.motion.stop("HRM"); }
if (heartRate <= 0 && tries === 100) { createHTML("It was not possible to measure the heart
rate"); SASocket.setDataReceiveListener(onreceive);
SASocket.sendData(CHANNELID, "Fall Detected" + "\n" + "It
was not possible to detect the heart rate"); webapis.motion.stop("HRM"); }
}
Assim, se a soma das medidas for menor ou igual a zero, a medida não deu
certo. Caso contrário, será calculada a média e enviada ao celular através da interface do
SAP. Um exemplo pode ser visto na figura 3.10.
Figura 3.10 – Botão de abortar não acionado e medição da frequência cardíaca Fonte: Projeto Fall Detector
Quando o Smartphone receber tais informações, irá concatenar com a
localização e enviará para um número pré cadastrado, via SMS. Um exemplo da
mensagem recebida pode ser visto na figura 3.11.
Figura 3.11 – Celular que recebeu o SMS após a queda Fonte: Projeto Fall Detector
Outra funcionalidade do aplicativo é o botão ‘Emergency’, em que todo o
processo de detecção é ignorado:
function emergency() {
createHTML("Emergency call sent"); SASocket.setDataReceiveListener(onreceive);
SASocket.sendData(CHANNELID, "Emergency button pressed"); }
Um exemplo de tal funcionalidade está a seguir na figura 3.12
Figura 3.12 – Celular que recebeu o SMS após o botão de emergência ser
acionado Fonte: Projeto Fall Detector
Por fim, há também o botão ‘Disconnect’ para fechar a conexão do relógio com
o celular:
function disconnect() { try { if (SASocket !== null) { SASocket.close();
SASocket = null; createHTML("Connection Closed"); }
} catch(err) { console.log("exception [" + err.name + "] msg[" +
err.message + "]"); } }
A tela do aplicativo após o fechamento da conexão pode ser vista a seguir na
figura 3.13
Figura 3.13 – Conexão fechada Fonte: Projeto Fall Detector
3.4.1 – GPS
A ideia central do projeto é detectar quedas da própria altura. Entretanto,
algumas outras funcionalidades foram incluídas para a criação de uma mensagem de
aviso de queda mais robusta e com mais informações. Como o Smartwatch não possui
tal funcionalidade, foi usado um esqueleto de código [17] para encontrar a localização
do usuário via GPS do sistema operacional Android.
Para que o código funcione corretamente, é preciso adicionar três permissões
importantes no AndroidManifest.xml. São elas:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.INTERNET" />
O código possui uma classe principal que é uma subclasse da classe Service,
portanto herda propriedades dela. E implementa a interface LocationListener, e por isto
é obrigada a implementar os métodos dela. Ambas são importadas no código:
import android.location.LocationListener;
import android.app.Service;
public class GPSTracker extends Service implements LocationListener{ … public Location getLocation();
…
}
Dentro da classe principal há o método getLocation(). Esse método tenta
encontrar a localização através do provedor de internet e, se falhar, tenta através do
GPS. Há dois métodos para obter a latitude e a longitude que, se falharem, retornam
zero:
/**
* Function to get latitude
* */
public double getLatitude(){
if(location != null){
latitude = location.getLatitude();
}
// return latitude
return latitude;
}
/**
* Function to get longitude
* */
public double getLongitude(){
if(location != null){
longitude = location.getLongitude();
}
// return longitude
return longitude;
}
Posteriormente, foi feito um método para perguntar ao usuário se deseja habilitar
o GPS, caso esteja desabilitado, através de um alerta. Ele terá a opção “Setting”, que irá
redirecioná-lo para as configurações do GPS, e a opção “Cancelar”, que irá cancelar o
alerta:
public void showSettingsAlert(){
AlertDialog.Builder alertDialog = new AlertDialog.Builder(mContext);
// Setting Dialog Title
alertDialog.setTitle("GPS is settings");
// Setting Dialog Message
alertDialog.setMessage("GPS is not enabled. Do you want to go to set-
tings menu?");
// On pressing Settings button
alertDialog.setPositiveButton("Settings", new
DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog,int which) {
Intent intent = new In-
tent(Settings.ACTION_LOCATION_SOURCE_SETTINGS);
mContext.startActivity(intent);
}
});
// on pressing cancel button
alertDialog.setNegativeButton("Cancel", new
DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int which) {
dialog.cancel();
}
});
// Showing Alert Message
alertDialog.show();
}
O último importante método desta classe pára o serviço de localização, que irá
suspender novas atualizações:
/**
* Stop using GPS listener
* Calling this function will stop using GPS in your app
* */
public void stopUsingGPS(){
if(locationManager != null){
locationManager.removeUpdates(GPSTracker.this);
}
}
3.4.2 – SMS
O último recurso utilizado no lado do Android é o SMS. Primeiro importa-se a
biblioteca SmsManager:
import android.telephony.SmsManager;
Com isso, a utilização do SMS está habilitada. O modo mais simples encontrado
para se enviar uma mensagem de texto simples foi:
SmsManager sms = SmsManager.getDefault();
sms.sendTextMessage("021xxxxxxxxx", null, fall, null, null);
Onde o primeiro argumento é o número de destino e o terceiro é a string a ser
enviada na mensagem.
3.4.3 – Acelerômetro
No caso do Smartwatch, a movimentação do aparelho é considerada um evento.
Portanto, para detectar movimento, cria-se um “listener” de movimento:
window.addEventListener( 'devicemotion', function listen( e ) { ax = e.accelerationIncludingGravity.x;
ay = -e.accelerationIncludingGravity.y;
az = -e.accelerationIncludingGravity.z;
Através da tabela abaixo (figura 3.14), é possível ver o output da aceleração em
algumas situações comuns:
Figura 3.14 – Tabela de aceleração Fonte: https://www.html5rocks.com/en/tutorials/device/orientation/
3.4.4 – Frequência Cardíaca
Este recurso do Smartwatch necessita de dois privilégios:
<tizen:privilege name="http://tizen.org/privilege/healthinfo"/> <tizen:privilege
name="http://developer.samsung.com/privilege/medicalinfo"/>
Com isso, agora é possível criar um “listener” da frequência cardíaca, que deve
ser chamado apenas quando se deseja aferi-la:
webapis.motion.start("HRM", onchangedCB);
Sendo “onchangedCB”, o método que irá aferir a frequência cardíaca. Para tal,
chama-se:
MotionHRMInfo.heartRate
Esta propriedade retornará a frequência cardíaca. Entretanto, é importante
ressaltar que é uma medida muito imprecisa, portanto é aconselhável realizá-la várias
vezes e fazer uma média [18].
3.4.5 – Recursos secundários
Além do que foi mencionado, foram utilizados mais dois recursos para a
elaboração do projeto, que necessitam dois privilégios:
<tizen:privilege
name="http://tizen.org/privilege/application.launch"/> <tizen:privilege name="http://tizen.org/privilege/power"/>
O primeiro é utilizado para que o aplicativo volte para o primeiro plano, no caso
de algum evento importante, caso a aplicação esteja em segundo plano.
O segundo é utilizado quando a aplicação está processando informações impor-
tantes, para que a tela não entre em modo de descanso (apague).
3.5 – Experimentos
Para testar o funcionamento do relógio foram realizados testes em diferentes al-
turas: 14cm, 35cm, 55cm, 75cm. Em seguida foi feito outro teste em que uma pessoa,
utilizando o relógio, simulava uma queda em condições pré-determinadas. Nesse pri-
meiro teste, o objetivo foi avaliar a precisão da detecção das quedas, os falsos positivos,
e os falsos negativos, registrando em cada uma das alturas essas ocorrências. No segun-
do teste o objetivo foi avaliar se é possível simular os mesmos resultados com um usuá-
rio.
Nesses experimentos utilizou-se: o relógio devidamente ligado e conectado, via
Bluetooth, ao celular; o celular conectado a uma rede de telefonia e ao relógio via Blue-
tooth; mesa de altura de 75cm e aparatos de diferentes alturas (14cm, 35cm, 55cm) con-
tados a partir do plano zero (chão); e dois verificadores. No segundo teste substitui-se os
aparatos por um usuário que simula a queda numa condição fixa: 1,70m de altura, 70kg
de massa corporal, realizando queda perpendicular a um colchão.
A verificação dos resultados do teste foi feita de modo que se considera falso
positivo quando o relógio detecta uma queda sem que ela tenha de fato acontecido. O
falso negativo, por sua vez, ocorre quando uma queda não é detectada, quando de fato
ela ocorreu. O relógio tem sucesso no teste quando, após ser empurrado da altura pré-
determinada, o mesmo sinaliza que houve queda, progredindo no algoritmo pós detec-
ção. A verificação ocorre com dois examinadores, um por vez, que olham o relógio e
checam se o mesmo retornou o resultado esperado e se progrediu no algoritmo pós de-
tecção. A verificação do segundo teste foi feita somente no final checando se o algorit-
mo pós queda foi de fato executado.
O primeiro teste consistiu de: cada avaliador empurrou o relógio com força sufi-
ciente para vencer a inércia e fazê-lo cair das alturas pré-determinadas, dez vezes para
cada altura. Ao todo foram realizadas oitenta quedas. O relógio não apresentou nenhuma
detecção sem que houvesse queda e nenhuma queda, que de fato ocorreu, deixou de ser
registrada. Dessa forma, o relógio apresentou 100% de precisão nesse teste.
No segundo teste um usuário colocou o relógio em seu pulso e executou dez
quedas da própria altura, perpendicularmente, em um colchão. Nesse teste o relógio
detectou a queda nove vezes corretamente segundo nossos parâmetros de verificação.
Em uma queda o relógio falhou na sua detecção devido a movimentos realizados pelo
usuário após a queda. Tais movimentos simulam que o usuário está consciente, portanto
fora do escopo de detecção do algoritmo.
Capítulo 4
Conclusão
A cada ano que passa fica cada vez mais evidente a importância das inovações
tecnológicas em todos os aspectos da nossa vida. Não só no entretenimento e no lazer,
mas também em saúde, segurança e bem-estar. A tecnologia vem se desenvolvendo de
forma a ocupar um espaço muito importante no cotidiano de todos. Recentemente, uma
dessas inovações tecnológicas que vem se sobressaindo e, mesmo em seu estágio inicial
de maturação já vem mostrando seu enorme potencial, são as tecnologias vestíveis
juntamente com IoT. Este projeto foi desenvolvido como uma forma de se contribuir
para este novo paradigma e alcançar uma melhor qualidade de vida aliada a maior
segurança e privacidade.
O objetivo geral desse projeto foi desenvolver dois aplicativos. O primeiro foi
feito em uma tecnologia vestível e foi responsável por identificar quedas da própria
altura. O segundo, feito em um Smartphone, serviu de auxílio, sendo uma interface
entre o primeiro e o mundo externo. As principais dificuldades encontradas foram
desenvolver um algoritmo eficiente que detectasse quedas de pessoas através de um
aparelho que possui apenas um sensor (o acelerômetro), e a segunda foi ter a capacidade
técnica para efetivamente transformar a ideia em um software. A primeira foi
contornada modificando o escopo do projeto para detectar quedas em que,
posteriormente, o usuário ficasse inconsciente. O segundo obstáculo foi superado
através de pesquisas sobre programação em plataformas mobile e web em fontes
atualizadas e, posteriormente aprofundando-se nos mesmos. Com isso, o
desenvolvimento desse software foi realizado com sucesso.
No desenvolvimento do algoritmo para a detecção de quedas seguidas de
desmaio, foi encontrado o problema de o usuário cair e ficar consciente. Neste caso, o
relógio não iria detectar a queda por conta dos batimentos cardíacos. Entretanto, mesmo
nesse caso há a possibilidade do usuário se lesionar gravemente. A solução encontrada
foi adicionar um botão de emergência à tela principal do aplicativo do relógio, que
ignora todo o processo de detecção e envia uma mensagem mesmo sem detectar uma
queda.
Outro objetivo foi desenvolver um módulo para obter a localização do usuário.
Como este módulo foi desenvolvido no smartphone, que, diferente do smartwatch,
possui ampla documentação online, foi possível encontrar muitas bibliotecas (DLLs) e
pesquisas explicando as diversas funcionalidades, como a de obtenção da localização
via GPS. Com isso foi possível desenvolver esse módulo.
Uma funcionalidade disponível no smartwatch que não é central quanto ao
escopo do projeto, é a de medição de frequência cardíaca. Tal informação não é
considerada central porque não é utilizada efetivamente para a detecção da queda, mas
sim como um dado adicional, complementar. Entretanto, dado o potencial que essa
informação possui quando entregue a um profissional da área da saúde, juntamente com
o aviso de queda, tal módulo foi incorporado ao escopo do projeto.
Por fim, para fazer a comunicação do relógio com o mundo externo, foi preciso
adicionar um módulo no smartphone para receber as informações do smartwatch,
realizar um processamento, e enviá-las de modo íntegro e de fácil entendimento para
uma terceira pessoa.
Como dito anteriormente, esse projeto foi feito para o meio acadêmico, portanto
para um aperfeiçoamento do mesmo visando seu comércio, poderiam ser feitos
trabalhos futuros como a utilização de redes móveis (3G/4G/LTE) ou redes wi-fi como
meio principal de envio de dados e utilizar o SMS como meio alternativo em caso da
falta de Internet.
Além disso, a interface gráfica foi suficiente para cumprir seu propósito, mas
para uma maior facilidade poderiam ser utilizadas múltiplas telas ao invés de apenas
uma, e com um design mais voltado para grande parte do público-alvo – os idosos –
como botões e mensagens maiores.
Portanto, com o passar do tempo, melhorias tecnológicas serão feitas para um
objetivo final comum de ajudar a sociedade a viver melhor e espero, com esse trabalho,
ter contribuído com tal objetivo. Além disso, espero também ter ajudado um pouco a
comunidade científica no campo de estudo em que se encontra esse projeto.
Bibliografia
[1] Ec.europa.eu,. 'Policy - European Commission'. N.p., 2015. Web. 3 Aug. 2015.
[2] Nhs.uk,. 'Falls - NHS Choices'. N.p., 2015. Web. 6 Aug. 2015.
[3] Jr, Prof. "Quedas Nos Idosos – O Risco Previsível". Medicina Geriatrica. N.p.,
2016. Web. 23 Oct. 2016.
[4] "Queda Da Própria Altura Lidera Lista Das Emergências - Cidade - Diário Do Nor-
deste". Diário do Nordeste. N.p., 2016. Web. 23 Oct. 2016.
[5] "Queda Da Própria Altura Mata 1 Pessoa A Cada 4 Dias Em SP | Noticias | Portal
Do Governo Do Estado De São Paulo". Saopaulo.sp.gov.br. N.p., 2016. Web. 23 Oct.
2016.
[6] "Computação Vestível". Pt.wikipedia.org. N.p., 2016. Web. 23 Oct. 2016.
[7] "Quase Metade Dos Usuários De Smartphones No Brasil Espera Que Tecnologias
Vestíveis Substituam Celulares". ITForum 365. N.p., 2016. Web. 23 Oct. 2016.
[8] "App Manifest | Android Developers". Developer.android.com. N.p., 2016. Web. 30
Oct. 2016.
[9] "Companion | SAMSUNG Developers". Developer.samsung.com. N.p., 2016. Web.
12 Nov. 2016.
[10] Li, Qiang et al. "Accurate, Fast Fall Detection Using Gyroscopes And Accelerome-
ter-Derived Posture Information". (2016): n. pag. Print.
[11] Lim, Dongha et al. "Fall-Detection Algorithm Using 3-Axis Acceleration: Combi-
nation With Simple Threshold And Hidden Markov Model". N.p., 2016. Print.
[12] Kostopoulos, Panagiotis et al. "Increased Fall Detection Accuracy In An Accel-
erometer-Based Algorithm Considering Residual Movement". (2016): n. pag. Print.
[13] Oliveira, Joao Paulo Dupinska et al. “Sistema de Monitoramento de Quedas para
Pessoas com Deficiencia Motora”. Undergraduate. Universidade Tecnologica Federal
do Parana, 2013. Print.
[14] LEMOS, ADMAR AILTON AZEVEDO. "Detector De Quedas De Idosos". Un-
dergraduate. UNIVERSIDADE POSITIVO, 2011. Print.
[15] Piva, Leonardo Sabadini et al. "Falert : Um Sistema Android Para Monitoramento
De Quedas Em Pessoas Com Cuidados Especiais". (2016): n. pag. Web. 12 Nov. 2016.
[16] "Important Facts About Falls | Home And Recreational Safety | CDC Injury Cen-
ter". Cdc.gov. N.p., 2016. Web. 12 Nov. 2016.
[17] Tamada, Ravi. "Android GPS, Location Manager Tutorial". androidhive. N.p.,
2017. Web. 22 Jan. 2017.
[18] Jackson, Aaron. "Accessing The Gear’S Heart Rate Monitor | Aaron Jackson". Aa-
ron.jaxns.net. N.p., 2017. Web. 22 Jan. 2017.
Anexo A
Código de conexão entre o relógio e o celular (no celular):
function onerror(err) { console.log("err [" + err + "]"); }
var agentCallback = { onconnect : function(socket) { SASocket = socket;
alert("Connection established with Smartwatch. Detection
working"); start();
SASocket.setSocketStatusListener(function(reason){ console.log("Service connection lost, Reason : [" +
reason + "]"); disconnect();
});
},
onerror : onerror
};
var peerAgentFindCallback = { onpeeragentfound : function(peerAgent) { try { if (peerAgent.appName == ProviderAppName) {
SAAgent.setServiceConnectionListener(agentCallback);
SAAgent.requestServiceConnection(peerAgent);
} else { alert("Not expected app!! : " +
peerAgent.appName); }
} catch(err) { console.log("exception [" + err.name + "] msg[" +
err.message + "]"); }
},
onerror : onerror
};
var connectioncallback = {
/* Connection between provider and consumer is established */ onconnect: function(socket) {
SASocket = socket;
}
}
SAAgent.setServiceConnectionListener(connectioncallback);
function onsuccess(agents) { try { if (agents.length > 0) { SAAgent = agents[0];
SAAgent.setPeerAgentFindListener(peerAgentFindCallback);
SAAgent.findPeerAgents();
} else { alert("Not found SAAgent!!"); }
} catch(err) { console.log("exception [" + err.name + "] msg[" +
err.message + "]"); }
}
function connect() { if (SASocket) { alert('Already connected!'); return false; }
try { webapis.sa.requestSAAgent(onsuccess, function (err) { console.log("err [" + err.name + "] msg[" +
err.message + "]"); });
} catch(err) { console.log("exception [" + err.name + "] msg[" +
err.message + "]"); } }
Anexo B
Código de conexão entre o relógio e o celular (no celular):
public class HelloAccessoryProviderService extends SAAgent {
public static final int SERVICE_CONNECTION_RESULT_OK = 0;
public static final int HELLOACCESSORY_CHANNEL_ID = 104;
public static final String TAG = "HelloAccessoryProviderService";
public Boolean isAuthentication = false;
public Context mContext = null;
private final IBinder mBinder = new LocalBinder();
// private int authCount = 1;
HashMap<Integer, HelloAccessoryProviderConnection> mConnectionsMap
= null;
public HelloAccessoryProviderService() {
super(TAG, HelloAccessoryProviderConnection.class);
}
@Override
public void onCreate() {
super.onCreate();
SA mAccessory = new SA();
try {
mAccessory.initialize(this);
} catch (SsdkUnsupportedException e) {
// Error Handling
} catch (Exception e1) {
e1.printStackTrace();
/*
* Your application can not use Samsung Accessory SDK. You
application should work smoothly
* without using this SDK, or you may want to notify user
and close your application gracefully (release
* resources, stop Service threads, close UI thread, etc.)
*/
stopSelf();
}
}
@Override
public IBinder onBind(Intent arg0) {
return mBinder;
}
@Override
protected void onFindPeerAgentResponse(SAPeerAgent arg0, int arg1)
{
// TODO Auto-generated method stub
}
protected void onAuthenticationResponse(SAPeerAgent uPeerAgent,
SAAuthenticationToken authToken, int error) {
if (authToken.getAuthenticationType() ==
SAAuthenticationToken.AUTHENTICATION_TYPE_CERTIFICATE_X509) {
mContext = getApplicationContext();
byte[] myAppKey = getApplicationCertificate(mContext);
if (authToken.getKey() != null) {
boolean matched = true;
if (authToken.getKey().length != myAppKey.length) {
matched = false;
} else {
for (int i = 0; i < authToken.getKey().length;
i++) {
if (authToken.getKey()[i] != myAppKey[i]) {
matched = false;
}
}
}
if (matched) {
acceptServiceConnectionRequest(uPeerAgent);
}
}
} else if (authToken.getAuthenticationType() ==
SAAuthenticationToken.AUTHENTICATION_TYPE_NONE)
Log.e(TAG, "onAuthenticationResponse : CERT_TYPE(NONE)");
}
@Override
protected void onServiceConnectionResponse(SAPeerAgent peerAgent,
SASocket thisConnection, int result) {
if (result == CONNECTION_SUCCESS) {
if (thisConnection != null) {
HelloAccessoryProviderConnection myConnection =
(HelloAccessoryProviderConnection) thisConnection;
if (mConnectionsMap == null) {
mConnectionsMap = new HashMap<Integer,
HelloAccessoryProviderConnection>();
}
myConnection.mConnectionId = (int) (Sys-
tem.currentTimeMillis() & 255);
mConnectionsMap.put(myConnection.mConnectionId,
myConnection);
}
}
else if (result == CONNECTION_ALREADY_EXIST) {
Log.e(TAG, "onServiceConnectionResponse, CONNEC-
TION_ALREADY_EXIST");
}
}
@Override
protected void onServiceConnectionRequested(SAPeerAgent peerAgent)
{
/*
* The authenticatePeerAgent(peerAgent) API may not be working
properly depending on the firmware
* version of accessory device. Recommend to upgrade accessory
device firmware if possible.
*/
// if(authCount%2 == 1)
// isAuthentication = false;
// else
// isAuthentication = true;
// authCount++;
isAuthentication = false;
if (isAuthentication) {
Toast.makeText(getBaseContext(), "Authentication On!",
Toast.LENGTH_SHORT).show();
authenticatePeerAgent(peerAgent);
}
else {
Toast.makeText(getBaseContext(), "Device Connected",
Toast.LENGTH_SHORT).show();
acceptServiceConnectionRequest(peerAgent);
}
}
private static byte[] getApplicationCertificate(Context context) {
if (context == null) {
return null;
}
byte[] cert = null;
String packageName = context.getPackageName();
if (context != null) {
try {
PackageInfo pkgInfo = con-
text.getPackageManager().getPackageInfo(packageName,
PackageManager.GET_SIGNATURES);
if (pkgInfo == null) {
return null;
}
Signature[] sigs = pkgInfo.signatures;
if (sigs == null) {
} else {
CertificateFactory cf =
CertificateFactory.getInstance("X.509");
ByteArrayInputStream stream = new
ByteArrayInputStream(sigs[0].toByteArray());
X509Certificate x509cert =
X509Certificate.getInstance(stream);
cert = x509cert.getPublicKey().getEncoded();
}
} catch (NameNotFoundException e) {
e.printStackTrace();
} catch (CertificateException e) {
e.printStackTrace();
} catch (javax.security.cert.CertificateException e) {
e.printStackTrace();
}
}
return cert;
}
public class LocalBinder extends Binder {
public HelloAccessoryProviderService getService() {
return HelloAccessoryProviderService.this;
}
}
public class HelloAccessoryProviderConnection extends SASocket {
private int mConnectionId;
public HelloAccessoryProviderConnection() {
super(HelloAccessoryProviderConnection.class.getName());
}
@Override
public void onError(int channelId, String errorString, int er-
ror) {
}
@Override
//Method that receive the data from the watch
public void onReceive(int channelId, byte[] data) {
final GPSTracker coord = new
GPSTracker(HelloAccessoryProviderService.this);
String fall = new String(data);
String sub = fall.substring(0, 13);
if(coord.canGetLocation()) {
fall = fall + "\n" + "http://maps.google.com?q=" +
String.valueOf(coord.getLatitude()) + "," +
String.valueOf(coord.getLongitude());
Toast.makeText(getBaseContext(), fall,
Toast.LENGTH_SHORT).show();
SmsManager sms = SmsManager.getDefault();
sms.sendTextMessage("021988772502", null, fall, null,
null);
}
else{
coord.showSettingsAlert();
fall = fall + "\n" + "Location not available";
Toast.makeText(getBaseContext(), fall ,
Toast.LENGTH_SHORT ).show();
SmsManager sms = SmsManager.getDefault();
sms.sendTextMessage("021988772502", null, fall, null,
null);
}
final String ack = "Acknowledge";
final HelloAccessoryProviderConnection uHandler =
mConnectionsMap.get(Integer.parseInt(String.valueOf(mConnectionId)));
if (uHandler == null) {
return;
}
new Thread(new Runnable() {
public void run() {
try {
try {
Thread.sleep(2500); //Sleep to give time
for the notification to disappear
} catch (InterruptedException e) {
e.printStackTrace();
}
coord.stopUsingGPS();
uHandler.send(HELLOACCESSORY_CHANNEL_ID,
ack.getBytes()); //Sending the ackowledge
Thread.currentThread().interrupt();
} catch (IOException e) {
e.printStackTrace();
}
}
}).start();
}
@Override
protected void onServiceConnectionLost(int errorCode) {
if (mConnectionsMap != null) {
mConnectionsMap.remove(mConnectionId);
}
}
}
}
