2017 - 2sem - Luiz Gabriel Pigalo Aparecido

Instituto Federal de Educação, Ciência e
Tecnologia de São Paulo

Campus São João da Boa Vista
Luiz Gabriel Pigato Aparecido
Dispositivo Wearable para monitoramento

médico remoto: proposta de design
acessível utilizando Arduino e sensores
São João da Boa Vista - SP

2017
Dispositivo Wearable para monitoramento

médico remoto: proposta de design
acessível utilizando Arduino e sensores
Trabalho de Conclusão de Curso

apresentado ao Instituto Federal de
São Paulo, como parte dos requisitos
para a obtenção do grau de Tecnólogo
em Sistemas para Internet.
Área de Concentração: Desen-

volvimento de Software e Eletrônica
Industrial
Orientador: Prof. Breno Lisi Romano

2017
Folha destinada à inclusão da Catalogação na Fonte - Ficha Catalográfica (a ser solicitada à
Biblioteca IFSP – Câmpus São João da Boa Vista e posteriormente impressa no verso da Folha de Rosto
(folha anterior).
Catalogação na Fonte preparada pela Biblioteca Comunitária “Wolgran Junqueira Ferreira” do IFSP –
Câmpus São João da Boa Vista

Dispositivo Wearable para monitoramento médico remoto: proposta de design
acessível utilizando Arduino e sensores/ Luiz Gabriel Pigato Aparecido. – São João da
Boa Vista - SP, 2017-
66 p. : il. (algumas color.) ; 30 cm.
Orientador: Prof. Breno Lisi Romano
Tipo – Instituto Federal de Educação, Ciência e Tecnologia de São Paulo

Campus São João da Boa Vista , 2017.
1. Dispositívos Wearable. 2. Arduino na Medicina. 3. Dispositívo de Monitoramento
Corporal. I. Orientador Prof. Breno Lisi Romano. II. Instituto Federal de Educação,
Ciência e Tecnologia de São Paulo. III. Dispositivo Wearable para monitoramento
médico remoto: proposta de design acessível utilizando Arduino e sensores
Dispositivo Wearable para monitoramento médico

remoto: proposta de design acessível utilizando
Arduino e sensores
Trabalho de Conclusão de Curso apresentado

ao Instituto Federal de São Paulo, como
parte dos requisitos para a obtenção do
grau de Tecnólogo em Sistemas para Internet.
Área de Concentração: Desenvolvimento de

Software e Eletrônica Industrial
Aprovado em DIA(número) de MÊS(por extenso) de ANO(Número).
Breno Lisi Romano

Orientador
Titulação
Instituição
Professor Convidado 1
Titulação
Instituição
Professor Convidado 2
Titulação
Instituição

2017
A minha mãe e avó por me apoiarem
sempre e ao meu orientador pela confi-
ança
AGRADECIMENTOS
Gostaria de agradecer a minha família pelo apoio, especialmente minha mãe e avó.
Gostaria de agradecer também ao meu orientador pela grande ajuda e confiança.
“You can’t trust code that you
did not totally create yourself ”.
Ken Thompson
APARECIDO, Luiz Gabriel Pigato. Dispositívo Wearable para monitoramento mé-
dico remoto: proposta de design acessível utilizando Arduino e sensores. 2017. Monografia
(Graduação de Tecnologia em Sistemas para Internet) – Instituto Federal de Educação,
Ciência e Tecnologia de São Paulo, São João da Boa Vista. 2017.
RESUMO
Este trabalho tem como objetivo analisar componentes eletrônicos disponíveis para a
plataforma Arduino e projetar um dispositivo Wearable, de baixo custo, para monitoramento
vital, com fins médicos, de pacientes à distância. É muito comum a consulta de rotina
de idosos nos postos de saúde locais para a manutenção de suas prescrições médicas e
verificação da necessidade de alteração nas dosagens. O produto deste projeto tem como
objetivo tornar este acompanhamento em algo contínuo e facilitá-lo para pessoas que
moram em áreas distantes de postos de saúde, assim como auxiliar no atendimento de
emergência fornecendo informações, em tempo real, assim como alarmes relacionados ao
estado vital dos usuários.
Palavras-chave: Dispositívos Wearable. Arduino na Medicina. Dispositívo de Monitora-

mento Corporal.
APARECIDO, Luiz Gabriel Pigato. Wearable Devices for remote medical moni-
toring: an accessible Design proposal using Arduino and sensors. 2017. Monografia
(Graduação de Tecnologia em Sistemas para Internet) – Instituto Federal de Educação,
Ciência e Tecnologia de São Paulo, São João da Boa Vista. 2017.
ABSTRACT
This paper aims to analyze electronic components available for the Arduino platform and
to design a low cost, wearable device for vital medical monitoring of patients at remote
locations. It is very common to routinely consult the elderly at the local health posts for
a maintenance of their medical prescriptions and check the need for changes in dosages.
The product of this project aims to make this follow-up on something continuous and to
facilitate this for people living in areas far from health posts, as well as assist in emergency
care providing real-time information as well as alarms related to vital status of users.
Keywords: Wearable Devices. Arduino in Medicine. Body Monitoring Device.

LISTA DE ILUSTRAÇÕES
Figura 1 – Distribuição dos Serviços de Saúde no município de São João da Boa

Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 2 – Tempo total de atendimento do SAMU . . . . . . . . . . . . . . . . . . 28
Figura 3 – Análise univariada do tempo de deslocamento das ambulâncias do
SAMU do município de Teresina no período de 2005 a 2011 . . . . . . 29
Figura 4 – Interfaces com um Arduino . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 5 – Placa Arduino LilyPad . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 6 – Protótipo mão robótica com LilyPad . . . . . . . . . . . . . . . . . . . 31
Figura 7 – Representação de saída Analógica e Digital . . . . . . . . . . . . . . . . 33
Figura 8 – Diagrama de conexão para estação meteorológica com Arduino . . . . . 34
Figura 9 – Absorção de onda NIR em solução de glicose aquosa analisada pelo
espectrofotômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 10 – Absorção de onda NIR estimada pela pele em uma concentração de
10mg/dL de glicose presente no sangue . . . . . . . . . . . . . . . . . . 36
Figura 11 – Diagrama do circuito desenvolvido. . . . . . . . . . . . . . . . . . . . . 37
Figura 12 – Dispositivo corporal: a) Rádio XBee Pro 2; b) Acelerómetro 3D; c)
Arduíno WEE; d) Sensor de temperatura. . . . . . . . . . . . . . . . . 38
Figura 13 – Módulo Ambiental: a) Arduino Diecimila + XBee shield; b) Rádio XBee
Pro 2; c) Sensor analógico de temperatura. . . . . . . . . . . . . . . . . 38
Figura 14 – Gateway XBee-GPRS: a) Módulo GPRS Hilo SAGEM; b) Arduíno
Mega; c) Rádio XBee Pro 2. . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 15 – Uso do dispositivo no contexto urbano e rural . . . . . . . . . . . . . . 41
Figura 16 – Passos tomados para o desenvolvimento deste projeto . . . . . . . . . . 42
Figura 17 – Tela inicial do aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 18 – Dados coletados durante o dia atual (período de 24 horas) . . . . . . . 44
Figura 19 – Dados coletados em datas anteriores . . . . . . . . . . . . . . . . . . . 45
Figura 20 – Módulo MLX90614ESF AAA . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 21 – Módulo Pulse Sensor Amped . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 22 – Módulo HC-06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 23 – Tela inicial do aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 24 – Saída no formato de notação de objeto do JavaScript . . . . . . . . . . 56
LISTA DE TABELAS
Tabela 1 – Quantidade de solitações de socorro em 2013 no município de Porto

Alegre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Tabela 2 – Componentes utilizados no protótipo . . . . . . . . . . . . . . . . . . . 37
Tabela 3 – Custo dos sensores em diferentes lojas online . . . . . . . . . . . . . . . 47
Tabela 4 – Coleta de Dados: Usuário em estado de repouso . . . . . . . . . . . . . 57
Tabela 5 – Coleta de Dados: Usuário após 20 minutos de atividade moderada
(caminhada) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Tabela 6 – Especificações de baterias do tipo Zinco-ar encontradas a venda . . . . 58
LISTA DE ABREVIATURAS E SIGLAS
APH Atendimento Pré-Hospitalar
SAMU Serviço de Atendimento Móvel de Urgência
MR Médico Regulador
TARM Telefonista Auxiliar de Regulação Médica
IPO Input–Process–Output
IoT Internet of Things
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
NIR Near-infrared
LED Light-emitting Diode
RGB Red Green Blue
LDR Light Dependent ResistorLight Dependent Resistor

SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1 Justificativa/Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3 Organização Deste Trabalho . . . . . . . . . . . . . . . . . . . . . . . 26
2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Serviços da Área da Saúde . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Linguagem C e Arduino Sketches . . . . . . . . . . . . . . . . . . . . 31
2.4 Arduino I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1 Passo 1: Definição da Arquitetura . . . . . . . . . . . . . . . . . . . . 42
3.2 Passo 2: Definição dos Sensores . . . . . . . . . . . . . . . . . . . . . 45
3.3 Passo 3: Concepção do Dispositivo . . . . . . . . . . . . . . . . . . . 47
3.3.1 Código da plataforma embarcada/Dispositivo vestível . . . . . . . . . . . . 48
3.3.2 Código do aplicativo para comunicação e armazenamento de dados . . . . . 52
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1 Aplicação do Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Análise dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Análise do Consumo Elétrico . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Discussões Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5 Dificuldades e Limitações . . . . . . . . . . . . . . . . . . . . . . . . . 59
5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1 Baixo custo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2 Sugestões para trabalhos futuros . . . . . . . . . . . . . . . . . . . . . 62
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
23
1 INTRODUÇÃO
Os serviços de saúde públicos são um direito de todos. De acordo com a portaria

o
N 2.814, de 29 de Novembro de 2011, todas as cidades foram concedidas com verbas
para a reinstituição e manutenção de diversos serviços de saúde como Unidades Básicas
de Saúde (UBS) para controle e atendimento de pacientes sob o uso de medicamentos
contínuos, Unidades de Pronto Atendimento (UPA) para casos gerais, pronto atendimento
e emergências, Serviços de Atendimento Especializado (SAE) para consultas e exames
mais avançados e outros programas. A distribuição destes centros é dada pela prefeitura
de forma que todos os bairros da cidade tenham acesso a estes serviços, ou ao menos esta
é a ideia. Segundo o Decreto No 5.055, de 27 de Abril de 2004 os municípios também
recebem suporte financeiro para manutenção do Serviço de Atendimento Móvel de Urgência
(SAMU) para o atendimento de casos de extrema urgência.
Através de informações presentes no site da prefeitura (VISTA, 2016), podemos
perceber que nem todas as UBS ou SAE, são exatamente iguais, ou seja, nem todas
dispõem do mesmo tipo de especialistas em todas as unidades, vemos que mesmo quem
reside dentro da cidade pode acabar encontrando algum tipo de incômodo ao ter que se
dirigir a outro centro de saúde para exames de rotina. Considerando a população que
reside em áreas rurais do município que, muitas vezes, pouco vêm a cidade, notamos que a
consulta de rotina para a manutenção de algum medicamento ou acompanhamento após
algum incidente pode se tornar algo um pouco custoso e desgastante.
No SAMU, devemos notar que o atendimento de algum tipo de acidente, por
exemplo, só é iniciado sob uma circunstância: alguém, entre os envolvidos ou espectadores,
contate o SAMU com informações sobre o acidente. Em alguns casos de acidentes em
rodovias, por exemplo, aonde os envolvidos foram para fora da pista, pode-se demorar para
que o acidente seja notado e reportado. Observando também as normas complementares
de implantação do atendimento de emergência expressa na Portaria No 1.864, de 29 de
Setembro de 2003 percebemos que não existe a definição de nenhuma forma de tempo de
resposta a um chamado.
Nestes 2 exemplos podemos perceber que nessa corrente do serviço de saúde de
um município temos, e sempre tivemos, um elo fraco. Uma vez que temos um paciente
ou um chamado de emergência, estes serviços se encarregam dos cuidados, porém estes
serviços dependem de que o paciente vá até eles. Aqui podemos propor uma forma de
monitoramento contínuo e não invasivo para monitoramento e possível prevenção de
incidentes de forma a minimizar, porém não eliminar, todo tipo de consulta presencial
mantendo médicos atualizados sobre informações de um paciente a qualquer momento.
24 Capítulo 1. Introdução
Atualmente, várias startups e empresas tem pesquisado no campo de dispositivos

wearable para fins médicos e um exemplo de alta tecnologia é o cc, desenvolvido pela
empresa americana VitalConnect (VITALCONNECT, 2017). Com esta pequena "fita"presa
a pele do usuário através de uma vestimenta de Hidrocolóide, uma substância biodegradável,
médicos conseguem medições perfeitas de ECG (Eletrocardiograma), postura, temperatura
corporal e até mesmo leituras de variação de frequência cardíaca e respiratória. Outra
solução é a WristOx2 da empresa Nonin (MEDICAL, 2016), uma empresa especializada em
soluções não invasivas, utilizado para medição da saturação de oxigênio do usuário. Uma
solução também para pacientes diabéticos foi feita pela empresa européia Abbott, chamada
de FreeStyle Libre (BRASIL, 2016), é um dispositivo subcutâneo utilizado para medição
de glucose no sangue. Este dispositivo é pareado com uma unidade de processamento para
exibição de informações sobre os níveis de glucose no sangue do usuário e algumas outras
informações.
Todas as soluções apresentadas aparentam ser precisas e confiáveis, porém elas
sofrem de alguns problemas e o primeiro a ser considerado é a taxa de adoção. A maioria
das empresas fazem grandes afirmações sobre seus produtos e o quanto eles são voltados
para o uso pessoal tanto quanto o uso profissional em instituições de saúde, porém, para
ambas as partes, o preço acaba sendo sempre o ponto decisivo, e estas solução são acabam
sendo caras por conta do nível de tecnologia envolvido em sua produção. Apesar de serem
tecnologias muito promissoras, o maior problema é também a maior deficiência destas
tecnologias: elas não se integram com nada, elas não conversam com outras tecnologias.
Assim, o resultado desta pesquisa tem como foco soluções para as 2 deficiências apontadas
anteriormente: preço e integração. A ideia é utilizar componentes de baixo custo, porém
precisos e confiáveis, juntamente com uma base que permitirá não somente a integração
mas também a expansão por parte de qualquer desenvolvedor.
1.1 JUSTIFICATIVA/MOTIVAÇÃO
Tendo em vista o baixo custo de produção de dispositivos como o que será proposto
por este trabalho e visando a melhoria não só de atendimentos emergenciais, mas também
do controle e monitoramento de pacientes em áreas periféricas ou remotas, o objetivo
deste trabalho é incentivar a pesquisa e produção de dispositivos, não só wearables de
monitoramento, mas também promover a integração deste tipo de tecnologia no sistema
de saúde pública brasileiro.
Tomando como exemplo o município de São João da Boa Vista, os moradores são
atendidos por diversos programas de saúde como por exemplo as Unidades Básicas de
Saúde e Unidades de Saúde da Familia (Pontos vermelhos e verdes na Figura 1) que contam
com Clínicos Gerais, Pediatras e Obstetras. Existem também os Centros de Especialidades
1.2. Objetivos 25
(Ponto amarelo na Figura 1) para consultas oftalmológicas, doenças respiratórias e até

gastro cirurgias, porém quando olhamos o crescimento do município de São João da Boa
Vista e levarmos em conta que o município vizinho mais próximo, Águas da Prata, não
possui tais postos de saúde e acabam por serem encaminhados aos existentes em São
João, vemos pelo mapa que a expansão dos postos de saúde não consegue acompanhar o
aumento da densidade demográfica dos municípios que atendem.
Figura 1 – Distribuição dos Serviços de Saúde no município de São João da Boa Vista
Fonte: Google Maps
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo deste estudo é propor um projeto para construção de um dispositivo
Wearable para monitoramento de pacientes a distância melhorando diversas áreas/aspectos
do serviço de saúde público. Este projeto utilizará componentes de baixo custo já existentes.
A base deste projeto será um microcontrolador Arduíno (ATmega328P) e contará com
sensores para as funções de: Medição dos batimentos cardíacos, Tempo entre batimentos e
temperatura corporal.
1.2.2 Objetivos Específicos

Para cumprir o objetivo geral desta pesquisa, as seguintes etapas serão desenvolvi-
das.
26 Capítulo 1. Introdução
• Identificar módulos de sensores corporais e pesquisas relacionadas;
• Criar e adaptar, a partir de módulos existentes, medições relacionadas ao corpo;
• Calibrar sensores;
• Projetar um design que permita o uso, de forma simples e discreta, dos sensores
(pulseira/wearable);
• Testar o dispositivo em cenários do dia-a-dia e reportá-los;
1.3 ORGANIZAÇÃO DESTE TRABALHO

No presente capitulo, foram abordados alguns pontos relacionados aos serviços
de saúde publico que levam a acreditar que o desenvolvimento deste dispositivo traga
grandes benefícios a comunidade como um todo. Vimos também que este dispositivo tem
capacidade não só de minimizar o deslocamento de grandes distâncias para consultas de
escopo menor, mas também de auxiliar de forma significativa no tempo de atendimento
de emergências.
Durante o capitulo 2 vemos com mais detalhes alguns estudos relacionados ao
funcionamento e qualidade do SAMU em 2 cidades e o ponto de vista de alguns profissionais
da saúde em relação a esse tópico. Tem-se também um estudo da placa de prototipagem
Arduino e sua variante para dispositivos wearables, o LilyPad, que será utilizada para
a construção dos protótipos desta pesquisa, e como é feita a interação deste dispositivo
com o mundo através de sensores. Por fim, são apresentados trabalhos relacionados de
dispositivos e estudos para medições relacionadas ao corpo humano de forma a agregar
funcionalidades a um dispositivo deste escopo.
No capitulo 3 é detalhado o funcionamento do dispositivo proposto de forma a
entender sua arquitetura para que possamos separar cada parte da concepção do dispositivo
até sua construção e testes. Neste capitulo também serão apresentados os sensores utilizados
para realizar as leituras desejadas. Por fim, após testes no dia-a-dia e uma análise de dados
para calibração dos sensores, será proposta uma análise do consumo elétrico do dispositivo
de forma a melhorar a autonomia de baterias fazendo com que o dispositivo passe a maior
parte de seu tempo em funcionamento.
Durante o capitulo 4, serão apresentados e discutidos os resultados obtidos após a
construção do dispositivo e seu uso para as leituras propostas.
Por fim, no capitulo 5, discutiremos o que foi ou não cumprido dos objetivos desta
pequisa, descrevendo o que foi considerado como concluido ou estado parcial de conclusão
e, logo após, serão expostos possíveis avanços e contribuições a este trabalho e ao campo
de pesquisa em forma de trabalhos futuros.
27
2 REVISÃO DA LITERATURA
2.1 SERVIÇOS DA ÁREA DA SAÚDE

Um dos objetivos deste trabalho ao propor um dispositivo de monitoramento
remoto que, através de padrões analisados em dados coletados sobre os sinais vitais do
paciente, uma equipe médica possa solicitar o comparecimento do mesmo em posto de
saúde já sabendo de sua situação atual de forma a reduzir o atendimento apenas aos
exames necessários sem a necessidade de uma visita tão constante por parte do paciente.
Porém, o objetivo deste dispositivo não é só o acompanhamento de pacientes em lugares
remotos, mas também a redução do tempo de resposta de alarmes e serviços de APH
(Atendimento Pré-Hospitalar), como por exemplo o SAMU (Serviço de Atendimento Móvel
de Urgência).
No ano de 2015, foi feita uma análise do tempo de resposta das solicitações de
socorro feitas em 2013 ao SAMU no municio de Porto Alegre. Podemos ver na Tabela 1
a relação do tipo e a quantidade de ocorrências. Segundo (CICONET, 2015), ocorreram
98.697 solicitações de socorro sendo enviado atendimento em 47.147 casos.
Tabela 1 – Quantidade de solitações de socorro em 2013 no município de Porto Alegre
Tipo de Ocorrência No de Atendimentos % do total de solicitações

Clínicas 24.063 51,03%
Traumáticas 16.556 35,1%
Psiquiátricos 2.545 5,4%
Obstétricos 949 2,01%
Transportes 2.974 6,3%
Fonte: Adaptada de (CICONET, 2015)
Visando avaliar o tempo de resposta médio do atendimento do SAMU, no ano de

2015 a pesquisadora Rosane Mortari, aluna da Escola de Enfermagem da Universidade
Federal do Rio Grande do Sul, estudou 1580 de atendimentos realizados pelo SAMU
no ano de 2013. Durante esta análise, a pesquisadora especifica os 2 grandes tipos de
incidentes atendidos: agravos clínicos, que compuseram 793 atendimentos, são compostos
por conhecidos como tempo dependentes por se tratarem de síndromes neurológicos,
cardiovasculares e respiratórias, e 787 atendimentos resultantes de agravos traumáticos
constituídos de acidentes de trânsito e quedas.
O resultado desta análise demonstrou que o tempo resposta total foi de mediana1
de 19 minutos, sendo os atendimentos relacionados ao maior tempo diretamente ligados a
1
Valor que separa a metade maior e a metade menor de uma amostra.
28 Capítulo 2. Revisão da Literatura
decisão tomada pelo MR (Médico Regulador) de enviar uma equipe básica. Como pode-se
notar, o tempo de resposta entre um colapso, toda informação necessária pelo TARM
(Telefonista Auxiliar de Regulação Médica) e real envio de ajuda pode ser separado da
seguinte maneira como proposto pela doutoranda na Figura 2.
Figura 2 – Tempo total de atendimento do SAMU
Fonte: Adaptado de (CICONET, 2015)
Durante sua pesquisa, (CICONET, 2015) destaca que o maior número de casos
ainda são entre adultos e jovens (21 a 40 anos), sendo estes, em sua maioria, casos
traumáticos. Mais a seguir, a autora destaca um dado muito importante que, devido
o atual envelhecimento da população, após os 60 anos existe uma grande queda nos
casos traumáticos fazendo com que agravos clínicos, os quais já mencionados pela autora
necessitam do atendimento mais rápido possível, tem um grande crescimento.
A pesquisadora também deixa claro que um dos princípios do SAMU é a chegada
precoce à cena de eventos no menor tempo de resposta possível de forma a minimizar
mortes evitáveis, reduzir sequelas e melhorar a sobrevida dos atendidos (CICONET, 2015).
Uma pesquisa bastante semelhante também foi conduzida na cidade de Teresina no
Piauí por 2 pesquisadoras (SILVA; NOGUEIRA, 2012) aonde foram analisadas a natureza
das ocorrências e seus tempos de resposta. Nesta pesquisa, foram utilizados registros de
ocorrências do ano de 2005 a 2011 totalizando 445.238 atendimentos realizados.
Como citado pela pesquisadora Naldiana Cerqueira em sua dissertação de mestrado,
a urgência e emergência no Brasil são setores da área de saúde deficientes e são geralmente
áreas problemáticas do SUS (Sistema Único de Saúde) (SILVA; NOGUEIRA, 2012). Como
já fica claro pela autora, o maior número de solicitações foram de urgências clínicas em
adultos e um número ascendente para acidentes de trânsito e que também foi constatado
que o tempo de deslocamento até o local foi maior que o recomendado tanto para zonas
2.2. Arduino 29
rurais quanto para zonas urbanas.

É possível ver através da Figura 3 que mesmo os piores tempos sendo os que
envolvem zonas rurais, os deslocamentos dentro da própria zona urbana poderiam ser
mais rápidos melhorando a disposição de bases e hospitais da região, como complementa a
autora.
Figura 3 – Análise univariada do tempo de deslocamento das ambulâncias do SAMU do

município de Teresina no período de 2005 a 2011
Fonte: (SILVA; NOGUEIRA, 2012)
Analisando as medições e a ideia de funcionamento básico de serviços como o

SAMU, nota-se que por mais rápido que estes serviços sejam ainda temos um problema
na cadeia de eventos de um atendimento: de alguma forma, o socorro deve saber sobre
o colapso. Em casos onde o paciente se encontra desacompanhado se tornam um dado
relevante a ponto de sugerir que, mesmo com um tempo de resposta baixo, o serviço
provido pelo SAMU é ainda um pouco “cego”.
2.2 ARDUINO
Neste projeto, o baixo custo vem das placas microcontroladoras Arduino para pro-
totipagem rápida. "As placas Arduino de interface oferecem uma tecnologia de baixo custo
que pode ser usada facilmente para criar projetos baseados em microcontrolador"(MONK,
2014), sendo que projetos baseados em microcontrolador qualquer projeto que se baseie em
Entrada-Processamento-Saída. Neste caso, será utilizado os sensores como entrada para o
microcontrolador que processará e transmitirá esses dados. As "entradas"utilizadas neste
projeto poderão ser sensores "nativos", ou seja, foram feitos para o propósito e algumas
entradas serão a adaptação de componentes eletrônicos para dada finalidade. Como pode-se
ver na Figura 4, a placa Arduino possui várias entradas "genéricas"que nos auxiliam na
coleta de dados para o processamento de informações.
Figura 4 – Interfaces com um Arduino
Fonte: (MONK, 2014)
Como é possível observar no site dos desenvolvedores do Arduino (ARDUINO,

2017b), a placa foi concebida pela Ivrea Interaction Design Institute como uma forma
rápida para prototipagem com foco em estudantes sem nenhum conhecimento prévio de
eletronica e programação, e logo quando foi descoberto por uma comunidade maior, a placa
de prototipagem foi tomando várias novas formas e solucionando diversos desafios como
aplicações IoT (Internet das Coisas) e, que será o caso, dispositivos wearable (vestíveis)
com a placa LilyPad.
A ideia da placa de prototipagem LilyPad (ARDUINO, 2017a) é de ter o menor
tamanho possível a fim de poder ser costurada e usada em elementos vestíveis. Como se
pode notar na Figura 5, a placa LilyPad possui um número reduzido de entradas devido
seu tamanho, porém para fins deste projeto de pesquisa ela se enquadra perfeitamente no
dispositivo a ser proposto.
Figura 5 – Placa Arduino LilyPad
Fonte: www.arduino.cc
Nos fóruns oficiais do Arduino, um usuário conhecido como Gabry295 utilizou o

LilyPad para criar uma luva e um braço robótico que reproduzia os movimentos de quem
vestisse a luva (ARDUINO, 2016b). Pode-se ver na Figura 6, uma imagem retirada do
2.3. Linguagem C e Arduino Sketches 31
vídeo feito pelo próprio criador do projeto, que a luva reproduz o aperto de mãos do
usuário.
Figura 6 – Protótipo mão robótica com LilyPad
Fonte: Usuário Gabry295 nos fóruns oficiais do Arduino
2.3 LINGUAGEM C E ARDUINO SKETCHES

No desenvolvimento para a plataforma Arduino, os código-fonte são chamados
de Sketches (ARDUINO, 2016a). Programas ou Sketches são escritas em linguagem C
e a maior parte do código é contida entre 2 blocos principais de código: void setup() e
void loop(). A função setup é chamada uma única vez quando o programa é iniciado e
geralmente é utilizado para definição de pinModes e inicialização de bibliotecas. A função
loop é o coração de todo programa para Arduino sendo chamada continuamente durante
toda a execução do programa.
A linguagem C foi concebida como uma linguagem procedural para fins gerais
desenvolvida por Dennis Ritchie nos anos 70 no AT&T Bell Laboratories com o objetivo
de implementar o sistema Unix a fim de obter o maior grau possível de independência
do hardware. Devido à grande portabilidade do compilador C e sua característica de ser
“hardware independente” ele se tornou a linguagem padrão para construção de Sketches
no Arduino (PRINZ; CRAWFORD, 2015).
O código a seguir é o mais básico possível para iniciar o entendimento das placas
Arduino e sua programação. A Sketch a seguir, chamada de Blink, é o comparável ao Hello
World em outras linguagens e plataformas.
1 /*
2 Blink
3 Turns on an LED on for one second , then off for one second , repeatedly
.
4
5 Most Arduinos have an on - board LED you can control . On the UNO , MEGA
and ZERO
6 it is attached to digital pin 13 , on MKR1000 on pin 6. LED_BUILTIN is

set to
7 the correct LED pin independent of which board is used .
8 If you want to know what pin the on - board LED is connected to on your
Arduino model , check
9 the Technical Specs of your board at https :// www . arduino . cc / en / Main /
Products
10
11 This example code is in the public domain .
12
13 modified 8 May 2014
14 by Scott Fitzgerald
15
16 modified 2 Sep 2016
17 by Arturo Guadalupi
18
19 modified 8 Sep 2016
20 by Colby Newman
21 */
22
23
24 // the setup function runs once when you press reset or power the board
25 void setup () {
26 // initialize digital pin LED_BUILTIN as an output .
27 pinMode ( LED_BUILTIN , OUTPUT ) ;
28 }
29
30 // the loop function runs over and over again forever
31 void loop () {
32 digitalWrite ( LED_BUILTIN , HIGH ) ; // turn the LED on ( HIGH is the
voltage level )
33 delay (1000) ; // wait for a second
34 digitalWrite ( LED_BUILTIN , LOW ) ; // turn the LED off by making the
voltage LOW
35 delay (1000) ; // wait for a second
36 }
Na função void setup() inicializamos o LED embutido na placa como saída e durante
a função void loop() acenda, após 1 segundo fazemos com que ele se apague, esperamos
mais 1 segundo e finalizamos o método. Como o próprio nome indica (loop) as instruções
contidas nesse bloco são repetidas indefinidamente.
2.4. Arduino I/O 33
2.4 ARDUINO I/O

Para que possamos utilizar a plataforma Arduino, necessitamos da criação de uma
rede de sensores de forma a coletar dados úteis e pertinentes ao nosso objetivo. Sensores
são dispositivos utilizados para a interação do microcontrolador com o ambiente em que
se encontra de forma a tomar ações com base nos dados obtidos (MARCHESAN, 2012).
No geral, os sensores podem ser utilizados para a medição de quaisquer grandezas físicas
como, por exemplo, temperatura, umidade e peso/pressão. Essas medições são convertidas
em sinais analógicos ou digitais que são passados ao microcontrolador através de suas
portas de entrada e saída.
Para os sensores, temos os com saída analógica e digital. Os sensores analógicos tem
como sua saída uma oscilação de valores conforme a grandeza mensurada. Já os sensores
com saída digital assumem 2 valores pré definidos, normalmente binário, em resposta a
grandeza mensurada (MARCHESAN, 2012). Na Figura 7 podemos ver como o resultados
de saídas digital e analógica podem ser representados.
Figura 7 – Representação de saída Analógica e Digital
Fonte: (MARCHESAN, 2012)
A quantidade de sensores existentes para o Arduino é imensa e com uma grande

gama de aplicações. Um exemplo prático é uma estação meteorológica desenvolvida com
base no microcontrolador. Com o desenvolvimento da técnologia, foi possível a criação

de estações compactas com uma alta precisão e confiabilidade, porém um alto preço que
justifica a criação de alternativas utilizando Arduino (TORRES et al., 2015).
O diagrama apresentado na Figura 8 retrata esta estação meteorológica de baixo
custo utilizando 3 sensores para a coleta de dados: Um sensor de temperatura modelo
DS18B20, um sensor de umidade do ar modelo DHT11 e um sensor de luminosidade do
tipo Light Dependent Resistor (Resistor Dependente de Luz). Vale notar que, devido a
fama e utilidade de microcontroladores, atualmente, encontrar não só estas mesmas partes,
mas também alternativas mais baratas ou com mais funcionalidades é algo trivial devido
a grande quantidade de fornecedores e lojas.
Figura 8 – Diagrama de conexão para estação meteorológica com Arduino
Fonte: (TORRES et al., 2015)
2.5 TRABALHOS RELACIONADOS

Por este trabalho ter uma face mais voltada à tecnologia envolvida para medições
utilizando sensores não específicos medicamente, meios de aquisição de dados através
de formas não invasivas serão os únicos procedimentos utilizados. Em 2003, Hidenobu
Arimotoa, e uma equipe de pesquisadores do National Institute of Advanced Industrial
Science and Technology no Japão, propôs um método para medição de glicose presente no
sangue através da refletância difusa do espectro próximo ao infravermelho (NIR) tendo em
vista que, mesmo que atualmente seja uma commodities, os medidores atuais que utilizam
uma lamina reagente ainda estão associados a dores e o risco, mesmo que baixo, a doenças
infecciosas (ARIMOTOA et al., 2003).
2.5. Trabalhos Relacionados 35
Durante o artigo publicado, é descrito que para uma medição precisa era necessário,
primeiramente, conhecer como a onda se comportaria em tecidos humanos para fazer
uma comparação com uma solução de glicose aquosa. Arimotoa descreve que apesar de
vários trabalhos anteriores e estudos pioneiros, a medição de glicose não invasiva com uma
precisão aceitável ainda é um problema. Ele explica que a maior dificuldade em determinar
os níveis de glicose no sangue com espectroscopia é que a sua concentração no sangue é
muito baixa se comparado com outros elementos (ARIMOTOA et al., 2003). Ele também
cita elementos como água, albumina, globulina, hemoglobina e triglicéride, porém deixa
claro que o maior problema na verdade para a medição com precisão é que, em comparação
com outros elementos, é que a concentração de glicose no sangue é muito baixa.
Utilizando os valores e relações encontrados por Arimotoa na Figura 9, pode-se
aproximar que a refletância utilizando um LED infravermelho com um comprimento de
onda de 1,600nm é possível realizar algumas leituras a partir de tecidos finos do corpo. Na
Figura 10 o autor realiza uma estimativa da refletância da glicose presente no sangue.
Figura 9 – Absorção de onda NIR em solução de glicose aquosa analisada pelo espectro-
fotômetro
Fonte: (ARIMOTOA et al., 2003)

Figura 10 – Absorção de onda NIR estimada pela pele em uma concentração de 10mg/dL
de glicose presente no sangue
Fonte: (ARIMOTOA et al., 2003)
Com a mesma ideia de monitoramento não invasivo, pode-se ter como exemplo a
utilização da placa Arduino na construção de um monitor cardíaco que, como explica o
pesquisador Marciel de Liz dos Santos, tem como objetivo a expansão do "E-health", onde
aparelhos utilizados para monitoração e diagnósticos possam ser deslocados dos centros
de saúde mas que possam ser controlados e remotamente pelo médico ou equipe médica
(SANTOS; TELLES, ). O pesquisador cita que a ideia de "Home Care"é datada do século
passado e surgiu nos Estados Unidos quando profissionais da saúde realizavam serviços
na casa dos pacientes, porém como levantado também por Marciel, estas consultas eram
feitas de forma precária e que devido a pobreza relacionada à época, pacientes tratados
em casa, a grande quantidade de doenças infectocontagiosas e o alto nível de mortalidade
relacionado a estes atendimentos eram os principais problemas do Home Care.
Com esse ponto, se justifica, de um ponto de vista médico, que as práticas de
Home Care demandassem um profissional deslocado para atender o paciente a todo
momento, porém não justifica financeiramente os custos envolvidos com este deslocamento.
Partindo dessa ideia, é possível justificar protótipos como o proposto por Marciel para
o desenvolvimento de um monitor cardíaco para Arduino possibilitando a que médicos
possam se manter informados sobre a condição atual de pacientes remotamente.
Para a construção deste protótipo o autor tomou como base para suas modificações
um aparelho hospitalar já conhecido, o pletismógrafo, um instrumento para determinar
variações no tamanho de um órgão em razão do afluxo do sangue. No protótipo proposto,
as medidas são feitas a partir da pulsação no dedo utilizando utilizando um sensor Light
Dependent Resistor (Resistor Dependente de Luz) de um lado e uma fonte de luz na outra
extremidade, senda esta um Light Emitting Diode (Diodo Emissor de Luz) comum de 3mm.
Neste caso, a luz emitida refletira no osso acima do sensor onde se encontram os grupos
de artérias aonde o volume de sangue pulsa de acordo com o coração, essa sintonia é que
modulará a resistência do sensor. Na Figura 11, tem-se o diagrama do circuito proposto.
Podemos perceber a grande quantidade de partes envolvidas no protótipo.
Figura 11 – Diagrama do circuito desenvolvido.
Fonte: (SANTOS; TELLES, )
Tabela 2 – Componentes utilizados no protótipo
Diagrama Descrição Valor méd. (R$)

R1 e R10 Resistor 270 ohms x 1/8W R$0,05 (R$0,10)
R2 Resistor 39K ohms x 1/8W R$0,06
R3 e R6 Resistor 68K ohms x 1/8W R$0,11 (R$0,22)
R4 Resistor 8K2 ohms x 1/8W R$0,07
R5 Resistor 1M ohms x 1/8W R$0,05
R9 Resistor 1K8 ohms x 1/8W R$0,08
P1 Potenciômetro 10K linear R$3,53
LED 1 e LED 2 Led vermelho 3 mm R$0,69 (R$1,38)
LDR LDR R$1,96
C1 e C3 Capacitor 1uF x 25V R$0,16 (R$0,32)
C2 e C4 Capacitor 100nF R$0,11 (R$0,22)
CI1 LM - 358N dual opamp R$ 0,89
Fonte: Adaptada de (SANTOS; TELLES, )
Com o auxilio da Tabela 2 é possível realizar uma análise financeira obtendo-se

o valor de R$9,042 para a compra dos componentes eletrônicos para a produção deste
2
Valores com base nos sites http://www.soldafria.com.br/ e http://www.mercadolivre.com.br/ quando
comprados em atacado
protótipo (placa Arduino não inclusa) e podemos afirmar que o baixo custo de um protótipo
pode ser refletido de forma até maior na produção em larga escala deste tipo de dispositivo.
O criador deste protótipo conclui que o protótipo foi desenvolvido com sucesso
seguindo o diagrama proposto na Figura 11, tendo em vista que durante a pesquisa nenhum
sensor específico foi encontrado.
O recolhimento de dados não é considerado uma vantagem se não pensarmos em
seu processamento por um especialista da área e, por esse motivo, pesquisadores da UFP
propuseram através de um artigo a criação de uma rede de sensores sem fio em malha. A
ideia é a criação de um sistema inteligente sensível ao contexto relacionado um paciente
e seu ambiente. Os pesquisadores propõem a criação de uma rede de sensores sem fio
onde cada nó pode ter, simultaneamente, duas funções: um nó de coleta de dados e um
nó que encaminha os dados para o próximo nó da rede (FERRAZ et al., 2010). A ideia
apresentada é de que os sensores comuniquem entre si através de uma rede de baixo alcance
ZigBee de forma a obterem leituras e repassarem os dados a uma rede General Packet
Radio Service (Serviços Gerais de Pacote por Rádio), de maior alcance. Na Figura 12 está
retratado o dispositivo para letiuras corporais desenvolvido pelos autores e a seguir, na
Figura 13, ve-se o módulo desenvolvido para leituras ambientais também desenvolvido
pelos autores.
Figura 12 – Dispositivo corporal: a) Rádio XBee Pro 2; b) Acelerómetro 3D; c) Arduíno

WEE; d) Sensor de temperatura.
Fonte: (FERRAZ et al., 2010)
Figura 13 – Módulo Ambiental: a) Arduino Diecimila + XBee shield; b) Rádio XBee Pro
2; c) Sensor analógico de temperatura.

Estes nós, para medição de temperatura corporal e ambiental, respectivamente,

são capazes, teoricamente, de se reorganizarem de forma que hora são sensores e hora são
encaminhadores de dados para um nó desta malha chamado de gateway para o repasse
de dados a uma rede de maior alcance. O dispositivo desenvolvido com a função de nó
gateway pode ser vista na Figura 14.
Figura 14 – Gateway XBee-GPRS: a) Módulo GPRS Hilo SAGEM; b) Arduíno Mega; c)

Rádio XBee Pro 2.
Os autores concluem que dado o envelhecimento da população mundial com os

avanços da medicina e industria farmacêutica, coloca-se fortes pressões sobre os sistemas de
saúde cuja viabilidade está associada a uma crescente procura de soluções para contenção
ou mesmo redução de custos. Apoiando a necessidade de acompanhamentos contínuos,
os autores afirmam que uma solução eficaz e de baixo custo é, atualmente, algo que a
medicina não possui. Segundo os autores, tal solução contribuiria com uma gestar mais
inteligente da saúde sem comprometer a qualidade dos cuidados prestados (FERRAZ et
al., 2010).
41
3 METODOLOGIA
Esta pesquisa tem como objetivo a proposta de um dispositivo vestível de baixo

custo e uma proposta de integração com serviços públicos de saúde de forma a atender o
tratamento de pacientes em determinados cenários como, por exemplo, a existência de
uma pré condição ou histórico de colapso em um paciente que passa a maior parte de seu
tempo não assistido ou que se encontra em uma zona remota dos centros urbanos.
A ideia principal deste dispositivo wearable é a integração com serviços de saúde
público já existentes para que o atendimento seja mais eficiente. A Figura 15 representa a
ideia desta comunicação. Em qualquer área que possua uma cobertura GSM, é possível que
o paciente seja monitorado por uma equipe médica e que seu histórico vital seja registrado
para consultas futuras.
Figura 15 – Uso do dispositivo no contexto urbano e rural
Fonte: Autor
Com a proposta deste dispositivo de baixo custo e sua disseminação através dos
centros tecnológicos, espera-se que aconteça um incentivo para a pesquisa de dispositivos
similares com diferentes funções e arquiteturas mais eficientes. A proposta do dispositivo
desenvolvido, juntamente com listas de materiais e códigos desenvolvidos pelo autor,
estarão disponíveis através de forma digital para que sirva como base a possíveis pesquisas
futuras.
Assim, a Figura 16 apresenta a metodologia desta pesquisa, destacando os passos
para cumprimento do objetivo proposto.
42 Capítulo 3. Metodologia
Figura 16 – Passos tomados para o desenvolvimento deste projeto
Fonte: Autor
3.1 PASSO 1: DEFINIÇÃO DA ARQUITETURA

A arquitetura adotada consiste de 3 pontos principais: o dispositivo/a coleta de
dados, o canal de comutação e o ponto concentrador dos dados para monitoração. O
dispositivo e suas capacidades são definidas pelos sensores abordo do circuito embarcado e
estarão dispostos de forma a obterem a melhor leitura possível. O formato de pulseira é
adotado devido a quantidade de leituras vitais possível na região do pulso. A comunicação
de longa distância para comutação de dados pode se dar através das redes GSM tendo em
vista que esta já possuí uma infra-estrutura existente consolidada. O ponto de concentração
de monitoramento tem como objetivo ser uma unidade de pronto atendimento ou até
mesmo a unidade de atendimento de emergência mais próxima. No ponto atual do trabalho,
a coleta de dados é feita através de uma rede local Bluetooth entre o dispositivo e o celular
do usuário para fins de auto-monitoramento e simplicidade do design proposto.
3.1. Passo 1: Definição da Arquitetura 43
Figura 17 – Tela inicial do aplicativo
Fonte: Autor
O aplicativo utilizado foi desenvolvido para fins de testes sem a aplicação de

nenhuma análise de UI (User Interface) e UX (User Experience). Como pode-se ver
na Figura 17, o aplicativo apresenta uma interface com as informações fornecidas pelo
dispositivo de forma simples e organizada.
O dispositivo inicialmente apenas realiza a coleta de dados quando existe uma
conexão com o celular e a fim de reduzir o consumo de bateria, de ambos os eletrônicos,
uma leitura é realizada a cada 45 segundos. Como pode-se ver na Figura 18, existe um
histórico de leituras realizadas e, ao fim de um ciclo de 24 horas, é feito um agrupamento
dos dados para consultas posteriores (Figura 19).
Figura 18 – Dados coletados durante o dia atual (período de 24 horas)
Fonte: Autor
O aplicativo, devido ao seu desenvolvimento híbrido, pode ser executado nas

plataformas mobile Android e Windows sem nenhuma modificação e com todas suas
funcionalidades. O aplicativo também pode ser executado na plataforma iOS, porém
devido a limitações do módulo Bluetooth HC-06 não é possível estabelecer uma conexão
nesta plataforma.
3.2. Passo 2: Definição dos Sensores 45
Figura 19 – Dados coletados em datas anteriores
Fonte: Autor
3.2 PASSO 2: DEFINIÇÃO DOS SENSORES

Foram definidos que as informações vitais a serem coletadas serão a posição do
corpo, temperatura corporal, a frequência cardíaca e a saturação de oxigênio no sangue.
Para atender as necessidades, já foram definidos os sensores.
É possível obter informações valiosas sobre o estado de um paciente através de
sua temperatura corporal. Esta leitura será realizada pelo módulo MLX90614ESF AAA
(Figura 20) que realiza esta leitura a partir de um sensor em contato com a pele.
Figura 20 – Módulo MLX90614ESF AAA
Fonte: Melexis Technologies NV

Outros fatores que também são de extrema importância no monitoramento de

pacientes de idade avançada ou de portadores de problemas cardíacos ou pulmonares é
a frequência cardíaca juntamente com a saturação de oxigênio no sangue (quantidade
de oxigênio transportado pelo sangue). A leitura referente aos batimentos cardiacos é
realizada pelo Pulse Sensor Amped, Figura 21, que utiliza de luz verde para a detecção do
pulso do usuário.
Figura 21 – Módulo Pulse Sensor Amped
Fonte: World Famous Electronics llc
A fim de coletar os dados de forma que estes estejam disponíveis ao usuário

necessita-se de uma conexão com algum dispositivo que seja capaz de processar estas
informações de uma forma compreensível ao usuário e que o acompanhe durante o dia-a-dia.
O celular é um equipamento que se tornou parte da vida da maioria das pessoas e sua
capacidade de se comunicar com dispositivos bluetooth o torna o dispositivo perfeito para
complementar as funcionalidades da pulseira. Com o uso do módulo HC-06, Figura 22,
pode-se nos conectar a um celular e realizar a transferência e armazenamento de dados.
Figura 22 – Módulo HC-06
Fonte: cFeon
Como pode-se observar na Tabela 3, o custo da placa Arduino e dos sensores

utilizados tem uma grande variação no mercado, porém estes ainda podem ser considerados
de baixo custo. As maiores fontes deste tipo de mercadoria no Brasil são lojas de hobby e
lojas que trabalham com importação em atacado.
3.3. Passo 3: Concepção do Dispositivo 47
Tabela 3 – Custo dos sensores em diferentes lojas online
Placa MercadoLivre AliExpress

Arduino LilyPad R$ 18,00 R$ 6,62
Sensor Cardíaco R$ 13,00 R$ 7,06
Sensor de Temperatura R$ 40,00 R$ 20,16
Módulo Bluetooth HC-06 R$ 19,00 R$ 9,75
TOTAL R$ 90,00 R$ 43,59
Fonte: Autor
Vale ressaltar que os preços acima não incluem os valores dos custos de envio e
que estes podem variar. Pode-se notar que os preços obtidos através do site AliExpress
são mais baixos que os obtidos comprando nacionalmente, porém os tempos de entrega
são geralmente grandes e, em alguns casos, pode até exceder o tempo apresentado pelo
vendedor. Outro problema recorrente ao se comprar pelo AliExpress é a existência de
partes defeituosas aonde é necessário que a parte defeituosa seja enviada de volta ao
vendedor para que ele possa fornecer uma nova. Comprando nacionalmente,este risco não
é eliminado, porém os prazos de entrega e retornos são mais previsíveis e estáveis.
3.3 PASSO 3: CONCEPÇÃO DO DISPOSITIVO
Inicialmente, serão concebidos 2 dispositivos iguais para fins de teste e resguarda

em caso de falhas de hardware em um dos protótipos. Estes protótipos inicialmente serão
usados no corpo através de uma pulseira comum adaptada para que os sensores possam
se prender a ela da melhor forma possível assim como o LilyPad, que foi feito para ser
costurado a coisas.
Após a concepção o primeiro protótipo “vestível” de forma a se acomodar no pulso,
será necessário realizar uma calibração dos sensores para que discrepâncias possam ser
corrigidas através do código embarcado. A maior parte dos sensores utilizados apresentados
no Passo 2 possuem um Data Sheet com especificações dos valores de leituras, porém ainda
é necessário que estes valores sejam confirmados.
Com a ajuda de manuais não oficiais encontrados na Internet, o código para cada
um dos sensores foi desenvolvido e testes simples de funcionamento foram realizados. Sem
o acesso a um monitor cardíaco de nível médio, um outro dispositivo vestível voltado para
esportes e fitness, Mi Band 2 da empresa chinesa Xiaomi, foi utilizado e a leitura do sensor
implementado neste trabalho está a par da leitura realizada pelo dispositivo comercial.
Devido a posição do termômetro utilizado (pulso) em relação a um termômetro comum
(de axila) só é possível realizar algumas aproximações em relação a leitura.
3.3.1 Código da plataforma embarcada/Dispositivo vestível

A seguir, o código principal da aplicação pode ser visualizado e foi quebrado em
partes para fins de apresentação e entendimento. O código completo da plataforma embar-
cada/dispositivo vestível encontra-se disponível no seguinte link para futuras contribuições
da comunidade externa: https://github.com/notmrrobot/vitalband-tcc-ifsp-sbv
Logo no inicio tem-se a importação de algumas bibliotecas para a comunicação
com os sensores. Estas bibliotecas, na ordem em que aparecem, são utilizadas para
a comunicação através do Bus I2C do microcontrolador Arduino juntamente com a
inicialização da biblioteca, fornecida pelo fabricante, do sensor de temperatura utilizado.
A biblioteca ArduinoJson.h é utilizada para auxiliar na montagem de objetos JSON,
uma notação de objetos representada por uma string de caracteres, facilitando assim a
compreensão e processamento dos dados por parte do dispositivo celular. Pode-se notar
também neste trecho, a inicialização das variáveis que indicaram o pino em que a leitura
será recebida e um pino utilizado para o fornecimento de energia ao diodo emissor de luz
verde utilizado no sensor cardíaco.
Logo após cria-se a instância de um objeto da classe, fornecida pelo fabricante do
sensor de temperatura, com os métodos auxiliares para facilitar o desenvolvimento. Em
seguida, cria-se uma árvore JSON com 200 bytes. Para este projeto, 200 bytes de memória
é mais do que o suficiente, porém deve-se ter ciência da pequena quantidade de memória
presente para uso, então para este projeto esta quantidade de memória alocada não irá
interferir no funcionamento do código e pode acomodar até mais sensores em sua saída
que será apresentada adiante.
1 # include < Wire .h >
2 # include < Adafr uit_M LX9061 4 .h >
3 # include < ArduinoJson .h >
4
5 // Pinos
6 int pinoPulso = 0; // Pino Analogico
7 int pinoPulsoEnergia = 8; // Pino Digital para
controle de estado ( liga e desliga ) do sensor cardiaco
8
9 // I2C
10 Ada fruit_ MLX906 14 mlx = Ad afruit _MLX90 614 () ; // Monitor de
temperatura corporal
11
12 // Arvore JSON para transmissao de dados
13 StaticJsonBuffer <200 > jsonBuffer ;
14 JsonObject & root = jsonBuffer . createObject () ;
Na segunda parte do código embarcado no dispositivo vestível realiza-se a criação

de algumas variáveis de controle utilizadas para o monitor cardíaco. Pela leitura dos
batimentos cárdicos se tratar de uma leitura analógica, ou seja, é transformado um sinal

elétrico que acende um diodo emissor de luz verde e depois realiza-se a leitura da taxa e
períodos de refletância, o valor retornado é salvo na variável Signal para processamento
pela biblioteca fornecida pelo fabricante de forma que o valor já processado e limpo é
armazenado na variável BPM. Este sensor também nos fornece o tempo, em milissegundos,
entre cada batimento cardíaco medido, este valor se encontra na variável IBI e também é
transmitido ao aparelho celular conectado. A seguir, os valores guardados nas linhas 5 e 6
são utilizados novamente pela biblioteca para limpeza do sinal evitando que um “falso
pulso” seja lido, como por exemplo se encostarmos o sensor em um espelho.
1 // Volatile Variables ( Utilizadas pelo monitor cardiaco )
2 volatile int BPM ; // Valor do sinal ( Batimentos por
Minuto )
3 volatile int Signal ; // Valor nao processado do sinal
4 volatile int IBI = 600; // Valor do intervalo entre cada
batimento
5 volatile boolean Pulse = false ; // Variavel para limpeza do sinal (
Evitar )
6 volatile boolean QS = false ; // Variavel de controle para definir
se existe uma leitura valida do batimento cardiaco
Na plataforma Arduino, o código possui dois métodos principais chamados de

setup() e loop(). Apresentado a seguir é o metodo setup() e sua funcionalidade é inicializar
valores e definir pinos para que o a função loop() seja executada corretamente. A função
setup() só é executada apenas uma vez durante o ciclo de execução do código embarcado e
é chamada logo que o microcontrolador recebe energia.
Para o funcionamento neste caso, inicia-se a saída Serial para que se possa transmitir
os dados para o adaptador Bluetooth. Em seguida, chama-se uma função criada pelos
fabricantes do monitor cardíaco e que tem como propósito garantir que uma leitura do
sensor seja realizada a cada 2 milissegundos. A função pinMode() faz parte das bibliotecas
de desenvolvimentos do Arduino e é utilizada para informar o microcontrolador a função
de um pino específico sendo elas ENTRADA ou SAÍDA. Aqui encontra-se utilizando
a variável pinoPulsoEnergia para informar que o pino com valor registado terá função
de SAÍDA de um sinal a 5 volts. Na linha 7 inicia-se a comunicação com o sensor de
temperatura e devido ao baixo consumo elétrico de diodos emissores de luz infravermelha
pode-se deixar esta comunicação aberta durante toda a execução do código.
1 void setup () {
2 Serial . begin (9600) ; // Inicia a saida serial
3 interruptSetup () ; // Codigo utilizado para realizar uma
leitura cardiaca a cada 2 ms
4
5 pinMode ( pinoPulsoEnergia , OUTPUT ) ; // Pino utilizado para ligar
e desligar o monitor cardiaco ( economia de energia )
6
7 mlx . begin () ; // Inicia o sensor de temperatura
8 }
Após a execução do método setup(), o fluxo da aplicação segue para o método

loop() que é executado indefinidamente até que o microcontrolador não receba mais energia
ou até que o mesmo receba um sinal de reinicio.
Para fins de melhor entendimento o código, a seguir, é apresentado em 3 partes.
Inicialmente, verifica-se se a comunicação Serial com dispositivos está disponível, linha 3, e
se estiver aguarda-se pela entrada de um comando. Este comando é enviado do dispositivo
móvel ao Arduino indicando que o celular está pronto para receber novas informações. Neste
caso existem 2 comando possíveis: o inteiro 0 e o inteiro 1 que representam, respectivamente,
o desligamento dos sensores para economia de bateria ou a preparação e realização de uma
leitura completa utilizando todos os sensores. A primeira parte do código apresentada a
seguir representa a rotina executada caso o dispositivo celular envie o comando 0 para
simbolizar o final da coleta de dados.
1 void loop () {
2
3 if ( Serial . available () > 0) {
4 // Aguardamos pelo comando do celular antes de iniciar os sensores
5 int comando = Serial . read () ;
6
7 if ( comando == 0) {
8 // Desligamos os sensores para economia de energia
9 digitalWrite ( pinoPulsoEnergia , LOW ) ;
O código a seguir representa o caso onde a entrada recebida é 1, simbolizando que

o dispositivo na outra ponta da comunicação está pronto para receber os dados de uma
leitura. Na linha 3 liga-se o sensor cardíaco e, logo em seguida, cria-se 3 nós no objeto
JSON que será enviado. Estes três nós são respectivamente os batimentos cardíacos por
minuto (BPM), o intervalo entre cada pulso (IBI) e a temperatura corporal (TMP). Estes
valores são inicializados com 0 para que nenhuma sujeira de memória seja atribuída a eles e,
logo na linha 11, realiza-se a leitura da temperatura através do método readObjectTempC()
do objeto mlx iniciado anteriormente.
Como mencionado anteriormente, a variável QS é utilizada para que nenhuma
“sujeira” gere uma leitura incorreta. Para isso, aguarda-se através de uma estrutura de
repetição que a biblioteca gere uma leitura de pulso válida e assim fazendo com que a
condição da estrutura de loop seja inválida. Assim que esta leitura estiver disponível, ela é
adicionada ao ao objeto JSON que será enviado ao celular. Este envio é realizado na linha
22 aonde utiliza-se o método printTo() e passa-se uma referência a comunicação Serial.
Para fins de organização e depuração, retornamos o cursor na saída Serial para

uma nova linha ao final da transmissão da leitura atual.
1 } else if ( comando == 1) {
2 // Ligamos os sensores para enviarmos uma medicao
3 digitalWrite ( pinoPulsoEnergia , HIGH ) ;
4
5 // Iniciamos o array JSON que enviara os dados
6 root [ " BPM " ] = 0;
7 root [ " IBI " ] = 0;
8 root [ " TMP " ] = 0;
9
10 // Realizamos a leitura da temperatura corporal
11 root [ " TMP " ] = mlx . readObjectTempC () ;
12
13 // Aguardamos ate o sensor produzir uma leitura limpa
14 while (! QS ) {
15 root [ " BPM " ] = BPM ;
16 root [ " IBI " ] = IBI ;
17
18 QS = true ;
19 }
20
21 // Utilizamos a saida serial para envio do objeto JSON
22 root . printTo ( Serial ) ;
23
24 // Para fins de organizacao , enviamos o cursor para a proxima
linha
25 Serial . println ( " " ) ;
26 }
Ao final das possiveis ações requisitadas pelo dispositivo celular, aguarda-se um

segundo antes de tentarmos realizar uma nova checagem da ação a ser tomada. A finalidade
dessa pausa é economizar alguns ciclos de coleta de dados para economia de energia e
uma menor amostragem de dados. Ao final desta pausa programada, o método loop() e
finalizado e iniciado novamente logo em seguida.
1 // Independente da acao , aguardamos alguns ciclos (1 s ) a fins de

economia energia
2 delay (1000) ;
3 }
4
5 }
O código embarcado para o funcionamento em conjunto dos dispositivos foi desen-

volvido de forma a transmitir ao celular os dados brutos coletados, sem nenhum tipo de
tratamento realizado. O aplicativo tem por sua vez a finalidade de agrupar e categorizar
os dados coletados.
Para que os dados coletados pelo dispositivo possam ser utilizados pelo usuário
para tomada de decisões, os dados são transmitidos para uma aplicação móvel que tem
por finalidade exibir, armazenar e agrupar os dados para que o usuário tenha um melhor
entendimento das leituras realizadas ao longo do uso do dispositivo. O código da aplicação
desenvolvida será apresentado no próximo tópico.
3.3.2 Código do aplicativo para comunicação e armazenamento de dados

A aplicação responsável pela coleta, armazenamento e categorização dos dados
coletados será executada em um celular devido a disseminação destes e também a grande
quantidade de opções para conectividade. Para o desenvolvimento desta aplicação, a
abordagem híbrida foi adotada por possuir a vantagem da reutilização total de código
independente da plataforma móvel adotada, sendo estas iOS, Android ou Windows.
Para o desenvolvimento, o conjunto de ferramentas atrelados ao pacote Ionic
Framework foi utilizado. O Ionic é um conjunto de bibliotecas gráficas de formatação e
marcação, conectados com outras ferramentas de desenvolvimento que permite a utilização
de linguagens já conhecidas para desenvolvimento de web sites (HTML, CSS e JavaScript)
sejam utilizadas para o desenvolvimento de aplicações nativas com acesso aos diversos
recursos do dispositivo móvel utilizado (IONIC, 2016).
A seguir, o código produzido será apresentado de forma a exibir apenas os códigos
relacionados a comunicação e armazenamento dos dados devido a grande quantidade de
código de base gerada automaticamente pela ferramenta.
No código a seguir foram importadas algumas classes referentes a ferramenta utili-
zada para desenvolvimento e na linha 3 realiza-se a importação do plugin necessário para
a comunicação serial através do Bluetooth, BluetoothSerial e logo em seguida importa-se o
plugin que abstrai as funcionalidades de armazenamento nativo da plataforma NativeSto-
rage. Nas linha seguintes, foram informadas que a visualização atrelada a este controlador
se chama agora.html. O código desta tela não está presente neste documento para fins de
simplicidade, porém o layout resultante pode ser conferido na Figura 23.
Após definida a classe AgoraPage, cria-se o seu construtor e utiliza-se os plugins
importador através da funcionalidade de injeção de dependência, aonde os parâmetros são
requisitados pelo método construtor e a plataforma se encarrega de atender as dependências
para que a classe possa ser instanciada. Dentro do construtor nos conectamos ao módulo
bluetooth utilizado e logo em seguida, na linha 17, enviamos o comando 0 para que o
dispositivo embarcado possa iniciar as rotinas de coleta de dados.
Uma particularidade da linguagem de programação utilizada é o esquema de push -
subscribe, aonde uma fonte produtora de dados coloca estes dados para consumo e aguarda
que alguém leia este buffer. No caso, a cada nova coleta de dados enviada pelo Arduino,
guarda-se o valor na variável data e chama-se a função guardarDados() que criará um
registro no banco com a data, hora, minuto e segundo da leitura recebida como chave e as
medições recebidas como valor no banco de dados nativo da plataforma.
1 import { Component } from ’ @angular / core ’;
2 import { IonicPage , NavController , NavParams } from ’ ionic - angular ’;
3 import { BluetoothSerial } from ’ @ionic - native / bluetooth - serial ’;
4 import { NativeStorage } from ’ @ionic - native / native - storage ’;
5
6 @IonicPage ()
7 @Component ({
8 selector : ’ page - agora ’ ,
9 templateUrl : ’ agora . html ’ ,
10 })
11 export class AgoraPage {
12
13 private data : any ;
14
15 constructor ( public navCtrl : NavController , public navParams : NavParams
, private bluetoothSerial : BluetoothSerial , private nativeStorage :
NativeStorage ) {
16 this . bluetoothSerial . connectInsecure ( " 00:21:13:00:4 F :0 D " ) ;
17
18 this . bluetoothSerial . write ( " 0 " ) . then ( data = > {
19
20 this . bluetoothSerial . subscribe ( ’\ n ’) . read () . then ( data = > {
21 this . data = data ;
22
23 this . guardarDados () ;
24 }) ;
25
26 }) ;
27 }
28
29 private guardarDados () {
30 this . nativeStorage . setItem ( new Date () , { sensores : this . data })
31 . then (
32 () = > console . log ( ’ Valores salvos ! ’) ,
33 error = > console . error ( ’ Erro ao salvar dados . ’ , error )
34 );
35 }
36
37 }
Figura 23 – Tela inicial do aplicativo
Fonte: Autor
A organização e apresentação dos dados salvos é representada nas Figuras 18 e 19.

A comutação dos dados armazenados com um servidor de dados na nuvem assim como
uma melhoria na interface do aplicativo podem ser vistos como possíveis trabalhos futuros.
Após estes passo, a concepção do dispositivo tanto em hardware como em software
foi finalizada e as leituras obtidas assim como a análise das mesmas serão apresentadas no
Capítulo 4.
55
4 RESULTADOS
Após a concepção do dispositivo e da sua interface com o usuário, alguns dados

foram coletados para fins de testes e melhor compreensão do funcionamento dos sensores
em conjunto. A seguir pode ser visto os passos referentes a aplicação do dispositivo, análise
dos dados obtidos e uma proposta para funcionamento em baterias.
4.1 APLICAÇÃO DO DISPOSITIVO

A fim de aferir a precisão dos sensores não só em ambientes controlados mas também
durante um uso no dia-a-dia, o dispositivo foi colocado em uso simples, consistindo de usos
por curtos períodos de tempo a fim de realizar apenas as coletas de dados. O dispositivo
foi aplicado em apenas uma pessoa do sexo masculino e com perfil não-atlético para fins
de validação da proposta apresentada e análise dos dados coletados.
Devido a falta de mobilidade do dispositivo em seu estado atual por ser necessária
a conexão a uma fonte de energia externa, as leituras foram limitadas a apenas estado de
repouso e após uma caminhada moderada. A ideia destes testes foram apenas entender o
funcionamento do dispositivo não só em relação a precisão de suas medições, mas também
o tempo que elas demoram para ser feitas.
A principio, o módulo utilizado para medição de temperatura leva um tempo, pois o
sensor infravermelho precisa se estabilizar com a temperatura do alvo. O monitor cardíaco
necessita também de algumas medições de tempo entre cada batimento cardíaco antes
de produzir um valor correto. No geral, a leitura de temperatura acontece com precisão
após aproximadamente 2 segundos de contato com o usuário e a medida de batimentos
cardíacos leva alguns segundos a mais dependendo da variação nos batimentos.
Na Figura 24 pode-se ver a saída de dados de uma leitura realizada em estado
de repouso. No caso, o aplicativo desenvolvido não foi utilizado para que fosse possível
demonstrar o que se passa na comunicação Serial com o dispositivo. Na leitura apresentada,
o sensor de temperatura não possuía contato com o usuário. Os dados coletados são melhor
analisados e descritos no Passo 5: Análise de Dados.
56 Capítulo 4. Resultados
Figura 24 – Saída no formato de notação de objeto do JavaScript
Fonte: Autor
Recomenda-se como trabalho futuro, a separação dos sensores para aplicação em

grupo de controle maior. Com a separação dos sensores fica mais fácil a calibração para
cada tipo de cenário. Exemplo: medir e armazenar somente a temperatura em diferentes
estados de atividade.
4.2 ANÁLISE DOS DADOS

Após a utilização do dispositivo da forma mais simples possível, apenas tocando os
sensores para medições, sem o uso continuo do mesmo, os dados coletados durante o uso
do dispositivo serão analisados, juntamente com dados coletados em ambiente controlado e
suas leituras apresentadas no Data Sheet do fabricante, em busca de anomalias nas leituras
de forma a fornecer falsas leituras.
Analisando os dados presentes na folha de especificação do sensor e os dados
coletados em ambiente controlado apresentados na notação de objeto do JavaScript na
Figura 24, é possível perceber que há uma certa variação com o sensor de batimentos
cardíacos e uma leitura da temperatura ambiente, por parte do sensor de temperatura,
4.2. Análise dos Dados 57
quando o usuário não está em contato com o mesmo. Após consulta no manual do fabricante,
o sensor cardíaco, devido seu escape de luz verde, é um pouco mais intolerante mesmo com
seu circuito para limpeza do sinal recebido. Logo, para uma medida precisa é necessário
um tempo maior de amostragem para que uma média aritmética auxilie no alinhamento
dos valores recebidos.
Nas tabelas a seguir, pode-se acompanhar 4 medições realizadas antes e após um
exercício moderado de 20 minutos. Na Tabela 4 observa-se 2 leituras com o usuário em
estado de repouso e pode-se notar que a temperatura corporal a principio remete a mesma
de um estado de febre (37,5 graus), porém é necessário entender que o estado febril é
verificado com termômetros caseiros convencionais que realizam suas leituras em baixo da
axila enquanto as leituras apresentadas são retiradas da região do pulso. Uma sugestão
de trabalho futuro é criar uma tabela de relação entre as temperaturas obtidas com um
termômetro convencional e as leituras do sensor no pulso. Dessa forma, é possível criar
uma tabela de relação ou escala para podermos aproximar os resultados ao que já se é
comum encontrar e também validar o posicionamento do sensor no corpo.
Tabela 4 – Coleta de Dados: Usuário em estado de repouso
Coleta # BPM IBI (ms) Temperatura (o C)

1 88 452 39,25
2 90 596 40,01
Fonte: Autor
Na tabela 5 são apresentados os dados após 20 minutos de exercícios feitos pelo

usuário. O exercício realizado foi uma caminhada em terreno com declives e aclives de
forma equivalentes. Ao final do exercício, o usuário teve 5 minutos de repouso até a primeira
leitura ser realizada. Nos dados coletados, pode-se notar que os batimentos cardíacos por
minuto subiram e que o tempo médio entre eles diminuiu. Uma sugestão de trabalho futuro
é o isolamento do sensor cardíaco para fins de facilidade de manuseio e a comparação dos
valores obtidos com algum aparelho de mesma funcionalidade de nível comercial, para
se poder quantificar o dispositivo desenvolvido em relação ao mercado mais acessível, e
se possível uma comparação também com aparelhos de nível médio para verificação da
precisão das leituras obtidas.
Tabela 5 – Coleta de Dados: Usuário após 20 minutos de atividade moderada (caminhada)
Coleta # BPM IBI (ms) Temperatura (o C)

3 110 201 44,36
4 112 316 43,95
Fonte: Autor
Através das leituras apresentadas pode-se ver que os sensores obtiveram uma leitura
e estas apresentam variações aceitáveis com relação ao usuário e seu estado de atividade.
Como não é possível verificar a precisão destas medidas devido a falta de equipamento
para comparação e também a necessidade de estabelecer uma relação entre a temperatura
obtida na região do pulso que fica exposta ao ambiente durante o uso do sensor, é válido
afirmar, com base nas especificações oferecidas pelos fabricantes, que os sensores cumprem
seu trabalho de forma satisfatória até que mais testes de uso e de precisão sejam realizados
em trabalhos futuros.
4.3 ANÁLISE DO CONSUMO ELÉTRICO

Até então o dispositivo está sendo utilizado plugado diretamente a um computador
através da porta USB limitando a portabilidade e casos de uso do mesmo. Devido a
conexão Bluetooth presente no dispositivo é interessante que o este seja capaz de funcionar
a partir de baterias embutidas para que ele possa funcionar em ambientes mais abertos.
Uma porta USB tem por padrão as especificações de 5 volts e 500 miliamperes/hora.
Como não é possível realizar uma leitura do consumo durante operação, utilizou-se as
especificações máximas das portas USB como o pior cenário para uma aproximação usando
pilhas do tipo Zinco-ar. Pilhas do tipo Zinco-ar levam este nome, pois diferente de pilhas
convencionais e baterias, aonde a reação química acontece em um compartimento selado,
estas necessitam do contato com ar antes de iniciar sua vida útil. Desta forma, estas baterias
só começam a liberar energia quando removidas do pacote. Devido a não necessidade de
um compartimento 100% selado e a remoção de 1 dos reagentes, o zinco se encontra na
bateria e este reage com ar quando removido do pacote, este tipo de bateria possui um
tamanho muito reduzido e é comumente utilizado em aparelhos auditivos que, por sua
vez, já são aparelhos pequenos. A seguir na Tabela 6, nota-se as especificações energéticas
deste tipo de bateria de algumas marcas no mercado.
Tabela 6 – Especificações de baterias do tipo Zinco-ar encontradas a venda
Marca e Tipo Voltagem Capacidade (mAh)

Elgin 675 PR44 1,45 650
Panasonic 675P PR44 1,4 605
Power One A13/P13/PR48 1,45 260
Fonte: Autor
Para que todos os sensores funcionem em suas devidas voltagens recomendadas

pelo fabricante, uma corrente de 5 volts é necessária. Utilizando-se 4 pilhas de zinco-ar
do tipo P13 em série obtém-se 5,8 volts, o que não é um problema, pois o Arduino pode
trabalhar em qualquer voltagem entre 3.3 e 12 volts, e teremos 1.040 miliamperes/hora
garantindo que se encontra até acima das especificações energéticas de uma porta USB.
Com este tipo de pilha também garante-se que o tamanho do dispositivo não é impactado
por elas, pois na especificação de tamanho das baterias do tipo P13, vemos que uma
4.4. Discussões Gerais 59
possui aproximadamente 8 milímetros de largura e 5 milímetros e meio de altura, fazendo

com que 4 destas ligadas em série possuam 8 milímetros de largura e aproximadamente 2
centímetros e meio se empilhadas.
Vale notar que a capacidade energética apresentada é baseada na capacidade
nominal apresentada pelo fabricante e em casos de uso real podem apresentar valores
menores. Por esse motivo sugere-se, como tema para trabalhos futuros, que um estudo
seja realizado no sentido exploratório experimental para a definição do melhor tipo de
bateria ou pilhas para dispositivos vestíveis ou internet-das-coisas, tendo em vista que na
maioria dos casos destes tipos de dispositivos, uma fonte de energia constante nem sempre
é existente.
4.4 DISCUSSÕES GERAIS

A ideia inicial deste projeto tinha como proposta uma grade sensores e dados
coletados muito maior, porém para fins de simplicidade e tempo, este projeto teve seu
escopo reduzido, porém o projeto ainda se justifica uma vez que as leituras coletadas,
temperatura e batimentos cardíacos, e o método de integração com o dispositivo celular
do usuário oferecem informações valiosas de forma rápida e simples para que o usuário
possa entender o que acontece com o seu corpo durante o dia.
Um dos problemas da proposta inicial era a falta de armazenamento de dados
"local", o que significa que, baseado na proposta inicial, estes dados não seriam acessíveis
de forma prática ao usuário do dispositivo. E também seria um problema depender durante
todo o tempo de uso da rede móvel. Para acomodar uma solução a estes problemas, a ideia
de armazenamento foi refeita pensando no usuário. Através de redes Bluetooth pode-se
transferir não só os dados, mas também o processamento e agrupamento destes à um
dispositivo móvel de forma a tornar o código embarcado mais simples e o dispositivo mais
modular e simples de se desenvolver.
A precisão das leituras dos sensores não puderam ser avaliadas por falta de um
equipamento de nivel médico para qualificação por comparação. Apesar das medidas
estarem nos valores esperados pela folha de especificações do fabricante, as leituras
realizadas por este dispositivo devem ser consideradas apenas como uma referência geral e
em qualquer caso de duvida ou discrepância, é recomendado que exames sejam realizados
por profissionais da saúde qualificados em postos de saúde.
4.5 DIFICULDADES E LIMITAÇÕES

Devido a compra em forma de importação dos dispositivos e módulos utilizados,
algumas funcionalidades tiveram que ser revisadas e até removidas para que o projeto
tivesse ao menos um produto capaz de realizar leituras. Esta é uma dificuldade enfrentada
regularmente com este tipo de importação e pode ser resolvido através da compra dos
módulos necessários em lojas nacionais, porém o preço final do dispositivo pode sofrer um
aumento considerável. Ao final, a funcionalidade de oximetria foi a maior afetada devido a
um módulo que foi entregue com defeitos de fabricação impossibilitando seu uso nesta
pesquisa.
Uma limitação do estado atual do dispositivo apresentado é a incapacidade de ser
utilizado como um dispositivo vestível, como proposto inicialmente, devido o uso de uma
placa Arduino Uno no lugar da placa Lilypad. Essa troca se deu ao fato da placa Lilypad
utilizada inicialmente no desenvolvimento dessa pesquisa ter parado de funcionar devido a
um curto causado durante o manuseio do aparelho enquanto conectado a energia. Tendo
em vista os prazos desta pesquisa, a substituição por outra placa Lilypad não poderia ser
feita a tempo, fazendo com que uma placa do tipo Arduino Uno fosse utilizado para fins
de apresentação da coleta dos dados.
Devido a complexidade dos sistemas de saúde atuais e os poucos testes realizados
com os módulos utilizados, uma integração tais sistemas de saúde não pode ser desenvolvida
por completo. Porém vale notar que esta limitação está mais relacionada com o baixo
número de testes realizados com os sensores, pois o código embarcado e código do dispositivo
móvel desenvolvidos são capazes de transmitir os dados coletados para um servidor na
internet de forma simples.
Tendo em vista os problemas com entregas de partes defeituosas e a base atual do
dispositivo utilizar uma placa Arduino Uno, um estudo mais aprofundado do consumo
energético para o uso como dispositivo vestível não pode ser desenvolvido. Uma proposta
teorica foi apresentada e uma sugestão para trabalhos futuros também foi feita. Um estudo
nesta área beneficiaria não só este trabalho mas também todo o campo de dispositivos do
tipo Internet-das-coisas como um todo.
61
5 CONCLUSÕES
Tendo em vista que, ao final desta pesquisa, foi produzido um dispositivo com
capacidade de monitoramento corporal, esta pesquisa cumpriu seus objetivos de maneira
satisfatória.
O objetivo geral desta pesquisa mencionada uma proposta de integração com os
serviços existentes de saúde público, porém dada a falta de equipamentos para aferimento
da qualidade das medições produzidos e sem um tempo maior para testes, não é possíveis
realizar tal integração devido a possível problemas que possam fazer com que as leituras
recebidas não apresentem o estado atual real do usuário. Devido a disponibilidade de
compra e entrega dos sensores pelos Correios, a matriz de sensores utilizados foi reduzida
para apenas um monitor cardíaco e termômetro corporal. Com base nas referência sobre
o espectro próximo ao infravermelho contidas nesta pesquisa, uma sugestão de trabalho
futuro é o desenvolvimento de um monitor de glicose não invasivo para monitoramento
constante.
Os objetivos específicos foram cumpridos em quase que sua totalidade. A identifi-
cação de módulos de sensores corporais foi feita e os sensores encontrados estão descritos
neste trabalho e pesquisas relacionada formam a base do referencial teórico deste trabalho
de forma a suportar a ideia que dispositivos vestíveis e redes de sensores podem auxiliar
no monitoramento de sinais vitais de pacientes.
A partir de sensores existentes, foi possível realizar medições relacionadas ao corpo.
Ao final desta pesquisa, 2 sensores foram encontrados para os fins específicos de medição
dos batimentos cardíacos e temperatura e nenhuma “adaptação” de contexto foi necessária
para leituras corporais. A aplicação destes sensores para o conceito vestível se da por conta
de seu tamanho e simplicidade de uso.
A calibração dos sensores foi objetivo atendido parcialmente, uma vez que não foi
possível criar uma tabela de relação entre as medidas obtidas do dispositivo produzido e
um dispositivo de nível médico para as mesmas medidas. No caso do sensor de temperatura
é necessário a criação de uma tabela de relação com um termômetro convencional a fim de
relacionar as medidas obtidas na axila com as obtidas pelo sensor no pulso do usuário.
Para fins de simplicidade dos testes e também da troca de partes caso necessário, o
dispositivo foi inicialmente concebido em uma placa do tipo Arudino UNO por possuir
todos os pinos populados com pontos de conexão headers e uma conexão USB mais acessível.
Porém, a portabilidade do projeto para a placa Arduino Lilypad pode ser considerada um
processo simples uma vez que só é necessária a solda dos sensores diretamente a placa por
esta versão do Arduino não possui pinos header.
62 Capítulo 5. Conclusões
Os testes do dispositivo foram feitos parcialmente. Devido ao estado atual do

protótipo não funcionar a partir de baterias, os testes puderam ser apenas realizados em
ambientes controlados e os dados coletados são referentes a apenas um usuário. Porém os
resultados mostram que os sensores aparentam estar funcionando corretamente e leituras
aceitáveis estão sendo produzidas. De qualquer forma, mais testes do dispositivo e dos
sensores são definitivamente necessários e aqui tiveram seu escopo reduzido por questões
de tempo.
5.1 BAIXO CUSTO

Um dos pontos mais recorrentes durante esta pesquisa é o baixo custo. Como foi
possível observar no Passo 2 da metodologia, comprando as partes utilizadas nacionalmente,
obteve-se um custo de R$ 90,00 para a construção de um dispositivo capaz de fornecer
informações vitais sobre o usuário. Atualmente no mercado, existem dispositivos para fins
esportivos que realizam o mesmo tipo de leitura a um custo reduzido, o que se dá pelo
fato da produção em larga escala destes aparelhos realizada, na maioria dos casos, em
países com uma mão de obra barata.
Para fins de pesquisa, o aparelho desenvolvido teve uma boa relação de custo e que
poderia ter sido um valor menor, R$ 43,59, se todas as partes adquiridas tivessem vindo
da opção mais barata, AliExpress, o que não foi possível devido a problemas com partes
defeituosas e tempos de entregas dilatados.
Vale ressaltar que os valores obtidos não incluem os respectivos custos de entrega e
que o custo das partes utilizadas pode variar indefinidamente em ambas as fontes.
5.2 SUGESTÕES PARA TRABALHOS FUTUROS

Como propostos durante a metodologia, alguns pontos desta pesquisa podem ser
melhorados e expandidos a outros assuntos pertinentes.
Como este trabalho envolve a criação de uma interface para organização dos dados
que será interpretada por um usuário comum e não uma equipe médica, uma análise da
interface de usuário e experiencia de usuário através do protótipos apresentados pode
refletir em uma interface mais simples e mais organizada.
A utilização de sensores prontos e provenientes de manufaturas que geralmente
remetem uma baixo controle de qualidade, o aferimento da qualidade dos sensores e
das leituras produzidas pode também ser expandido de forma a complementar e dar
continuidade a esta pesquisa. Uma pesquisa neste sentido pode também dar credibilidade
ou describilidade as leituras obtidas durantes os testes realizados, abrindo possibilidades
para uma recriação do dispositivo produzido para realização de novas leituras.
5.2. Sugestões para trabalhos futuros 63
Uma proposta também bastante relevante para trabalhos futuros é uma análise do
consumo energético deste tipo de dispositivos (vestíveis e internet-das-coisas). Durante
a metodologia deste trabalho, uma solução utilizando baterias de zinco-ar foi proposta,
porém esta pode não ser a melhor solução existente. A criação de um trabalho relacionado
a eficiência energética deste tipo de dispositivo pode beneficiar em grande quantidade
não só este trabalho, mas também a comunidade acadêmica comercial como um todo
promovendo a utilização de fontes de energias mais adequadas e eficientes para os produtos
comerciais da linha de vestíveis e internet-das-coisas.
65
REFERÊNCIAS
ARDUINO. How to Make a Remote Controlled Robotic Hand with Ar-

duino. 2016. Disponível em: <https://create.arduino.cc/projecthub/Gabry295/
how-to-make-a-remote-controlled-robotic-hand-with-arduino-32b0f5>. Citado na página
31.
ARDUINO. Sketch. 2016. Disponível em: <https://www.arduino.cc/en/tutorial/sketch>.

Citado na página 30.
ARDUINO. LilyPad Arduino USB. 2017. Disponível em: <https://www.arduino.cc/en/

Main/ArduinoBoardLilyPadUSB>. Citado na página 30.
ARDUINO. What is Arduino? 2017. Disponível em: <https://www.arduino.cc/en/Guide/

Introduction>. Citado na página 30.
ARIMOTOA, H. et al. Instrumental requirements for blood glucose sensing based on

diffuse reflectance NIR spectroscopy. Optical Diagnostics and Sensing in Biomedicine III,
p. 170, 2003. Citado 3 vezes nas páginas 34, 35 e 36.
BRASIL, A. L. do. FreeStyle Libre - Sistema Flash de Monitoramento de Glicose. 2016.

Disponível em: <https://www.freestylelibre.com.br/index.html>. Citado na página 24.
CICONET, R. Tempo Resposta de um Serviço de Atendimento Móvel de Urgência.

p. 124, 2015. Citado 2 vezes nas páginas 27 e 28.
FERRAZ, D. et al. Monitorização Vital e Ambiental para Grupos de Pacientes recorrendo

a Redes de Sensores. Optical Diagnostics and Sensing in Biomedicine III, p. 6, 2010.
Citado 2 vezes nas páginas 38 e 39.
IONIC. Ionic Core Concepts. 2016. Disponível em: <https://ionicframework.com/docs/

intro/concepts/>. Citado na página 52.
MARCHESAN, M. Sistema de monitoramento residencial utilizando a plataforma arduino.

Santa Maria, 2012. Citado na página 33.
MEDICAL, N. The WristOx2, Model 3150 Wrist-worn Pulse Oximeter. 2016. Disponível
em: <http://www.nonin.com/OEMSolutions/WristOx23150-OEM/>. Citado na página
24.
MONK, S. Programação com Arduino. Passos Avançados com Sketches - Volume 2. Série
Tekne. 1. ed. Porto Alegre: Bookman, 2014. 260 p. Citado 2 vezes nas páginas 29 e 30.
PRINZ, P.; CRAWFORD, T. C in a Nutshell. 2. ed. [S.l.]: O’Reilly Media, 2015. 650 p.
Citado na página 31.
SANTOS, M.; TELLES, F. Protótipo de monitor cardiaco para Arduino. p. 18. Citado 2
vezes nas páginas 36 e 37.
SILVA, N.; NOGUEIRA, L. Avaliação de Indicadores Operacionais de um Serviço de

Atendimento Móvel de Urgência. p. 7, 2012. Citado 2 vezes nas páginas 28 e 29.
66 Referências
TORRES, J. D. et al. Aquisição de dados meteorológicos através da plataforma arduino:

construção de baixo custo e análise de dados. Scientia Plena, v. 11, n. 2, 2015. Citado na
página 34.
VISTA, P. M. de São João da B. Unidades e Serviços de Saúde. 2016. Disponível em:

<http://www.saojoao.sp.gov.br/home/departamento_saude.php>. Citado na página 23.
VITALCONNECT. VitalPatch - VitalConnect. 2017. Disponível em: <https:

//vitalconnect.com/solutions/vitalpatch/>. Citado na página 24.

2017 - 2sem - Luiz Gabriel Pigalo Aparecido

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2017 - 2sem - Luiz Gabriel Pigalo Aparecido

Enviado por

Direitos autorais:

Formatos disponíveis

Instituto Federal de Educação, Ciência e

Tecnologia de São Paulo

Luiz Gabriel Pigato Aparecido

Dispositivo Wearable para monitoramento

São João da Boa Vista - SP

Dispositivo Wearable para monitoramento

Trabalho de Conclusão de Curso

Área de Concentração: Desen-

Orientador: Prof. Breno Lisi Romano

São João da Boa Vista - SP

Luiz Gabriel Pigato Aparecido

Orientador: Prof. Breno Lisi Romano

Tipo – Instituto Federal de Educação, Ciência e Tecnologia de São Paulo

Dispositivo Wearable para monitoramento médico

Trabalho de Conclusão de Curso apresentado

Área de Concentração: Desenvolvimento de

Aprovado em DIA(número) de MÊS(por extenso) de ANO(Número).

Breno Lisi Romano

São João da Boa Vista - SP

Palavras-chave: Dispositívos Wearable. Arduino na Medicina. Dispositívo de Monitora-

Keywords: Wearable Devices. Arduino in Medicine. Body Monitoring Device.

Figura 1 – Distribuição dos Serviços de Saúde no município de São João da Boa

Tabela 1 – Quantidade de solitações de socorro em 2013 no município de Porto

APH Atendimento Pré-Hospitalar

SAMU Serviço de Atendimento Móvel de Urgência

TARM Telefonista Auxiliar de Regulação Médica

IoT Internet of Things

GPRS General Packet Radio Service

GSM Global System for Mobile Communications

LED Light-emitting Diode

RGB Red Green Blue

LDR Light Dependent ResistorLight Dependent Resistor

Os serviços de saúde públicos são um direito de todos. De acordo com a portaria

Atualmente, várias startups e empresas tem pesquisado no campo de dispositivos

(Ponto amarelo na Figura 1) para consultas oftalmológicas, doenças respiratórias e até

Fonte: Google Maps

1.2.2 Objetivos Específicos

• Identificar módulos de sensores corporais e pesquisas relacionadas;

• Criar e adaptar, a partir de módulos existentes, medições relacionadas ao corpo;

• Testar o dispositivo em cenários do dia-a-dia e reportá-los;

1.3 ORGANIZAÇÃO DESTE TRABALHO

2.1 SERVIÇOS DA ÁREA DA SAÚDE

Tabela 1 – Quantidade de solitações de socorro em 2013 no município de Porto Alegre

Tipo de Ocorrência No de Atendimentos % do total de solicitações

Visando avaliar o tempo de resposta médio do atendimento do SAMU, no ano de

Figura 2 – Tempo total de atendimento do SAMU

Fonte: Adaptado de (CICONET, 2015)

rurais quanto para zonas urbanas.

Figura 3 – Análise univariada do tempo de deslocamento das ambulâncias do SAMU do

Fonte: (SILVA; NOGUEIRA, 2012)

Analisando as medições e a ideia de funcionamento básico de serviços como o

Figura 4 – Interfaces com um Arduino

Fonte: (MONK, 2014)

Como é possível observar no site dos desenvolvedores do Arduino (ARDUINO,

Figura 5 – Placa Arduino LilyPad

Nos fóruns oficiais do Arduino, um usuário conhecido como Gabry295 utilizou o

Figura 6 – Protótipo mão robótica com LilyPad

Fonte: Usuário Gabry295 nos fóruns oficiais do Arduino

2.3 LINGUAGEM C E ARDUINO SKETCHES

6 it is attached to digital pin 13 , on MKR1000 on pin 6. LED_BUILTIN is

2.4 ARDUINO I/O

Figura 7 – Representação de saída Analógica e Digital