sistema de navegac˘ao para~ deficientes visuais€¦ · intel, que e capaz de captar...
TRANSCRIPT
AMAURI SAULO SHIMABUKURO
LUCAS HIDEKI HIROKI
LUCAS HIDEYUKI CHINA
SISTEMA DE NAVEGACAO PARADEFICIENTES VISUAIS
Sao Paulo2018
AMAURI SAULO SHIMABUKURO
LUCAS HIDEKI HIROKI
LUCAS HIDEYUKI CHINA
SISTEMA DE NAVEGACAO PARADEFICIENTES VISUAIS
Trabalho apresentado a Escola Politecnica
da Universidade de Sao Paulo para ob-
tencao do Tıtulo de Engenheiro Eletricista
com enfase em Computacao.
Sao Paulo2018
AMAURI SAULO SHIMABUKURO
LUCAS HIDEKI HIROKI
LUCAS HIDEYUKI CHINA
SISTEMA DE NAVEGACAO PARADEFICIENTES VISUAIS
Trabalho apresentado a Escola Politecnica
da Universidade de Sao Paulo para ob-
tencao do Tıtulo de Engenheiro Eletricista
com enfase em Computacao.
Area de Concentracao:
Engenharia de Computacao
Orientador:
Reginaldo Arakaki
Sao Paulo2018
AGRADECIMENTOS
Aos meus pais, Osmar e Midori, pelo carinho e compreensao em todos momentos aolongo da minha vida. Sao eles que me proporcionaram condicoes para realizar minhasescolhas.
Amauri
Aos meus pais, Eder e Akemi, pelo suporte e apoio durante todos estes anos. Aosamigos que tive a oportunidade de conhecer durante a graduacao.
Lucas C.
Aos meus pais, Juscelino e Nair pelo suporte ao longo da graduacao,
Lucas H.
Agradecemos tambem a Reginaldo Arakaki, pela supervisao e apoio essenciais no de-senvolvimento do projeto, a Santiago Villalobos pelo auxılio no design no projeto e nodesenolvimento dos prototipos e a Scopus Tecnologia pelo suporte financeiro e tecnologico.
Grupo
RESUMO
Nos ultimos anos houve um grande desenvolvimento da computacao ubıqua e perva-siva e de tecnologias de Internet das Coisas (IoT). Dispositivos portateis com uma grandevariedade de sensores e consideravel poder de processamento estao disponıveis comerci-almente e sao acessıveis ao consumidor medio. Um desses dispositivos e o RealSense daIntel, que e capaz de captar informacoes precisas sobre a distancia de obstaculos e obje-tos em um ambiente fechado. A proposta principal do projeto e desenvolver um sistemaassistivo que auxilie a navegacao de deficientes visuais em ambientes fechados atraves dacaptacao e mapeamento de informacoes do ambiente fısico pelo dispositivo RealSense daIntel e eventuais sensores complementares, aplicando algoritmos de reconhecimento deobjetos e obstaculos, gerando saıdas que sejam facilmente lidas e utilizadas pelos usuariosdo sistema.
Palavras-Chave – Sistema Assistivo, Deficientes Visuais, Intel RealSense, Nuvem dePontos.
ABSTRACT
In recent years there has been a great development of computing and Internet ofThings (IoT) technologies. Portable devices with a wide range of sensors and processingpower are commercially available for the average consumer. One such technology is IntelRealSense, which can get accurate information about obstacles and objects in a indoorenvironment. The main proposal of the project is to develop an aid system that assistsnavigation of visually impaired people by capturing and mapping information from thephysical environment through Intel RealSense device and other complementary features,applying object and obstacle recognition algorithms, generating outputs that are easilyunderstood and used by system users.
Keywords – Assistive System, Visually Impaired, Intel RealSense, Point Cloud.
LISTA DE FIGURAS
1.1 Obstacle Avoidance System . . . . . . . . . . . . . . . . . . . . . . . . p. 13
1.2 Miniguide Mobility Aid . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
1.3 NavBelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
2.1 Arquitetura de sistemas de processamento de imagem . . . . . . . . . . p. 19
2.2 Ciclo de vida de projeto dividido por pontos de vista . . . . . . . . . . p. 21
2.3 Exemplo de execucao do algoritmo RANSAC . . . . . . . . . . . . . . . p. 23
2.4 Versao simplificada do pipeline OpenGL . . . . . . . . . . . . . . . . . p. 24
2.5 Diagrama de modulos da PCL . . . . . . . . . . . . . . . . . . . . . . . p. 25
3.1 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.2 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.3 Raspberry Pi 3 Model B . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.4 Intel Real Sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
3.5 MPU-6050 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40
3.6 Motor Vibracall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41
3.7 Carregador Portatil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
3.8 Pinagem do Raspberry Pi 3 . . . . . . . . . . . . . . . . . . . . . . . . p. 43
3.9 Interface Obstaculos-Vibracao . . . . . . . . . . . . . . . . . . . . . . . p. 45
4.1 Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.2 Versao final do sistema assistivo . . . . . . . . . . . . . . . . . . . . . . p. 49
4.3 Deteccao do chao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
4.4 Mapeamento do espaco fısico . . . . . . . . . . . . . . . . . . . . . . . . p. 52
5.1 Foto com caminhada desacompanhada . . . . . . . . . . . . . . . . . . p. 57
LISTA DE TABELAS
2.1 Domınios de aplicacao IoT . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.2 Requisitos nao funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.3 Especificacao da bateria . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
5.1 Tabela com participantes . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
5.2 Tabela com resultados da caminhada assistida . . . . . . . . . . . . . . p. 56
5.3 Tabela com resultados dos testes individuais dos motores . . . . . . . . p. 58
5.4 Tabela com resultados da caminhada assistida . . . . . . . . . . . . . . p. 59
SUMARIO
1 Introducao e Motivacoes p. 11
1.1 Levantamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
1.2 Solucoes existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
1.2.1 Smart Cane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
1.2.2 Obstacle Avoidance System . . . . . . . . . . . . . . . . . . . . p. 12
1.2.3 Miniguide Mobility Aid . . . . . . . . . . . . . . . . . . . . . . . p. 13
1.2.4 NavBelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
1.2.5 NAVI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
1.3 Justificativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
1.4.1 Visita inicial para entendimento do problema . . . . . . . . . . p. 16
1.4.2 Desenvolvimento agil e exploratorio de um primeiro prototipo . p. 16
1.4.3 Coleta de Feedback e Discussao . . . . . . . . . . . . . . . . . . p. 16
1.5 Objetivo do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
2 Fundamentos Conceituais p. 18
2.1 Processamento de imagem . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.1.1 Arquitetura de sistemas de processamento de imagem . . . . . p. 18
2.2 Arquitetura do modelo ODP . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2.2.1 Especificacoes de ponto de vista . . . . . . . . . . . . . . . . . . p. 20
2.3 Nuvem de pontos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
2.4 Bibliotecas e Algoritmos Utilizados . . . . . . . . . . . . . . . . . . . . p. 22
2.4.1 Algoritmo RANSAC . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.4.2 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.4.3 Point Cloud Library (PCL) . . . . . . . . . . . . . . . . . . . . p. 24
2.4.4 Libfreenect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
2.4.5 Librealsense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
2.5 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
2.5.1 Tecnologias de IoT(Internet of Things) . . . . . . . . . . . . . . p. 26
2.5.2 Aplicacoes de Internet das Coisas . . . . . . . . . . . . . . . . . p. 26
2.6 Deficiencia Visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.6.1 Definicao e classificacao . . . . . . . . . . . . . . . . . . . . . . p. 27
2.6.2 Causas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
3 O Sistema de Navegacao p. 30
3.1 Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.1.1 Domınio do Problema . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.1.2 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.1.3 Adicao de Valor . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
3.2 Requisitos do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
3.2.1 Modelo Estatico . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
3.2.1.1 Classe RealSense . . . . . . . . . . . . . . . . . . . . . p. 32
3.2.1.2 Classe Ponto . . . . . . . . . . . . . . . . . . . . . . . p. 32
3.2.1.3 Classe Piso . . . . . . . . . . . . . . . . . . . . . . . . p. 32
3.2.1.4 Classe Obstaculo . . . . . . . . . . . . . . . . . . . . . p. 32
3.2.1.5 Classe MotorVibraCall . . . . . . . . . . . . . . . . . . p. 32
3.2.2 Modelo Dinamico . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.2.3 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.2.4 Requisitos Nao Funcionais . . . . . . . . . . . . . . . . . . . . . p. 35
3.3 Solucao Tecnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.3.1 Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.3.1.1 Raspberry Pi 3 Model B . . . . . . . . . . . . . . . . . p. 38
3.3.1.2 Intel RealSense D435 . . . . . . . . . . . . . . . . . . . p. 39
3.3.1.3 MPU-6050 (Acelerometro e giroscopio) . . . . . . . . . p. 40
3.3.1.4 Motores Vibracall . . . . . . . . . . . . . . . . . . . . p. 40
3.3.1.5 Carregador Portatil . . . . . . . . . . . . . . . . . . . . p. 42
3.3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
3.3.2.1 Geracao dos Sinais de Vibracao . . . . . . . . . . . . . p. 43
3.3.2.2 Alimentacao do Raspberry Pi . . . . . . . . . . . . . . p. 43
3.3.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
3.3.3.1 Pre-Processamento . . . . . . . . . . . . . . . . . . . . p. 44
3.3.3.2 Acionamento dos Motores . . . . . . . . . . . . . . . . p. 44
3.3.3.3 Interface Obstaculos-Vibracao . . . . . . . . . . . . . . p. 45
4 O Sistema Implementado p. 46
4.1 Visitas preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4.1.1 Instituto Laramara . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4.1.2 Fundacao Dorina Nowill . . . . . . . . . . . . . . . . . . . . . . p. 47
4.2 Desenvolvimento do Prototipo Fısico . . . . . . . . . . . . . . . . . . . p. 47
4.2.1 Primeira Iteracao . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
4.2.2 Segunda Iteracao . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.2.3 Terceira Iteracao . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
4.3 Desenvolvimento do Software . . . . . . . . . . . . . . . . . . . . . . . p. 50
4.3.1 Implementacao Exploratoria Inicial em Python . . . . . . . . . p. 50
4.3.2 Substituicao pela Linguagem C++ . . . . . . . . . . . . . . . . p. 50
4.3.3 Substituicao do Kinect pelo Intel RealSense . . . . . . . . . . . p. 52
4.3.4 Substituicao do Algoritmo RANSAC . . . . . . . . . . . . . . . p. 53
5 Resultados obtidos p. 54
5.1 Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
5.1.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
5.1.2 Participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
5.1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
5.1.3.1 Testes dos Motores . . . . . . . . . . . . . . . . . . . . p. 55
5.1.3.2 Caminhada Assistida . . . . . . . . . . . . . . . . . . . p. 55
5.1.3.3 Caminhada Desacompanhada . . . . . . . . . . . . . . p. 56
5.1.3.4 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . p. 57
5.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58
5.2.1 Testes Individuais dos Motores . . . . . . . . . . . . . . . . . . p. 58
5.2.2 Caminhada Assistida . . . . . . . . . . . . . . . . . . . . . . . . p. 58
5.2.3 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
6 Conclusao p. 61
6.1 Sobre o Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61
6.2 Sobre o Curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
Referencias p. 63
11
1 INTRODUCAO E MOTIVACOES
1.1 Levantamentos
A porcentagem de indivıduos portadores de deficiencia visual vem crescendo rapida-
mente. De acordo com a OMS, sao 246 milhoes de deficientes visuais no mundo, sendo 39
milhoes de cegos e o numero de deficientes visuais cresce a 2 milhoes por ano. Este numero
ocorre com maior frequencia na populacao acima de 50 anos de idade. De acordo com a
OMS sao 20% da populacao mas contam com 65% dos deficientes visuais, e, no caso de ce-
gueira adquirida, 90% dos casos ocorrem em paıses em paıses subdesenvolvidos de acordo
com dados da World Report on Disability 2010 e do Vision 2020. A cegueira tambem
esta altamente relacionada a doencas como catarata, glaucoma, retinopatia diabetica e
degeneracao macular.(1)
No Brasil(IBGE 2010), 528.624 pessoas incapazes de enxergar e 6.056.654 com baixa
visao somam quase 6.6 milhoes de indivıduos com deficiencia visual. Outros 29 milhoes
de pessoas declararam possuir alguma dificuldade de enxergar ainda com oculos ou lente
O indivıduo com deficiencia visual apresenta renda menor que a media em decorrencia
de uma menor empregabilidade, devido a possıveis custos adicionais e por crencas infunda-
das que tal deficiencia visual compromete outras competencias relacionadas ao trabalho,
apesar de haver uma legislacao para evitar esta situacao.A perda da visao reduz signi-
ficativamente a autonomia e mobilidade da pessoa em realizar atividades do cotidiano
e sua locomocao, sujeitando-os a riscos de acidentes e uma forte dependencia da ajuda
de terceiro e de ferramentas auxiliares. Apesar de haver legislacao para auxilia-los nesta
questao, como a Lei no 5.296 (Lei de Acessibilidade), ainda existe uma certa negligencia
nos projetos arquitetonicos e urbanos atuais no sentido de auxilia-los como pisos tateis,
avisos sonoros entre outros.
12
1.2 Solucoes existentes
Atualmente, as principais ferramentas assistivas, ou seja focadas em ampliar habi-
lidades funcionais de pessoas deficientes, mais utilizadas no campo da mobilidade sao
bengalas, que transmitem informacoes do ambiente ao cego atraves do toque, identifi-
cando irregularidades no piso e caes guias, treinados para auxiliar tais deficientes a se
locomover ao longo de vias.
Houve tentativas de incorporar tecnologia para criar ferramentas assistivas, focadas em
ampliar habilidades funcionais de pessoas deficientes e incentivar uma vida independente,
sobretudo desenvolvidas no ambiente academico, mas que nao tiveram grande sucesso
comercial.
1.2.1 Smart Cane
Trata-se de uma smart cane (Bengala inteligente), equipada com sensores ultrassonicos
e vibradores de atuacao e um computador que gera sinais de vibracao conforme distancias
para obstaculos. A proposta seria uma solucao para o alcance baixo de uma bengala
comum e o esforco de procurar obstaculos que reduz significantemente a velocidade de
locomocao do deficiente visual. O projeto apresentou resultados significativos em relacao
a bengala comum em relacao a taxas de colisao com obstaculos. (2)
1.2.2 Obstacle Avoidance System
Trata-se de um sistema de navegacao para deficientes visuais que utiliza componentes
como uma camera kinect para gerar um mapa 3D do ambiente e gera feedback de audio
para o usuario, sendo a computacao feita via smartphone. O camera do Kinect seria
introduzida num cinto que tambem contaria com uma bateria, conforme figura abaixo.
O ponto mais interessante deste projeto foi a enfase em baixo custo, com a utilizacao de
tecnologia de prateleira, como cameras do Kinect e processadores do proprio celular. Um
ponto crıtico, no entanto, foi o uso de sons, que pode interferir com o som ambiente que
tambem e uma ferramenta importante de localizacao do deficiente visual.(3)
13
Figura 1.1: Obstacle Avoidance System
Fonte: (3)
1.2.3 Miniguide Mobility Aid
Trata-se de um pequeno aparelho que utiliza localizacao atraves de eco ultrassonico
para detectar objetos na vizinhanca e vibra baseado na distancia para objetos, contendo
tambem uma saıda de fone de ouvido que traz feedback de audio e seu uso e suplementar a
bengala. Diferente das solucoes anteriores, este e um produto comercial e a documentacao
sobre sua operacao e relativamente escassa. Um ponto positivo e que o sistema inteiro esta
encapsulado em um equipamento pequeno e portatil que pode ser incorporado a bengala.
(4)
14
Figura 1.2: Miniguide Mobility Aid
Fonte: (4)
1.2.4 NavBelt
Este sistema utiliza sensores ultrassonicos e tecnologias para evitar obstaculos vindos
do campo da robotica gerando feedback auditivo para indicar direcao de viagem recomen-
dada transmitida como pequenos beeps discretos.(5)
Figura 1.3: NavBelt
Fonte: (5)
1.2.5 NAVI
Sistema de navegacao utilizando Kinect para deteccao de obstaculos. O grande dife-
rencial deste projeto e, em vez de utilizar feedback contınuo atraves de sons ou vibracao,
utiliza uma voz sintetica que identifica certos obstaculos com base em pontos salvos pelo
15
usuario. Este projeto e construıdo como um cinto contendo um Arduino Lilypad, uma
pequena mochila com uma bateria de 12V e um suporte para o Kinect no peito.(6)
1.3 Justificativas
A bengala comum apresenta grandes limitacoes pois o pequeno alcance de 1 metro
reduz drasticamente a velocidade de locomocao do usuario, que precisa andar numa ve-
locidade tal que consiga fazer o movimento da bengala. Segundo (7), a velocidade de
caminhada e afetada pela extensao de informacao previa do ambiente. Alem disso, nao
identifica obstaculos acima da altura do joelho, que sao particularmente perigosos. Neste
quesito, mesmo os sistemas de bengalas inteligentes falham, pois ainda focam em deteccao
de obstaculos no solo.
Da mesma forma, os caes guias sao de difıcil treinamento em larga escala e criam
uma dependencia do usuario. Alem de trazerem o mesmo problema de nao identificar
obstaculos aereos.
Quanto a infraestrutura de acessibilidade a deficientes visuais, existem artifıcios como
pisos tateis e semaforos sonoros que podem de fato trazer uma grande ajuda aos deficientes
visuais, mas apesar de haver legislacao incentivando seu uso em projetos arquitetonicos e
urbanos, ainda sao pouco utilizados no Brasil e apenas em regioes densamente ocupadas.
Quanto aos sistemas inteligentes apresentados na secao anterior, ainda ha um enfoque
muito grande em detectar obstaculos. Apesar de muito importante, variaveis como altura,
distancia, dimensao e localizacao relativa destes nao e comunicada efetivamente, de forma
que um alerta de obstaculo pode ser interpretada de multiplas formas pelo usuario. Da
mesma forma, o tratamento de multiplos obstaculos ainda nao e abordado de forma
satisfatoria.
Este projeto foi criado na hipotese de que ao ter um senso espacial geral do ambiente,
nao apenas de obstaculos, suplementado pelo uso da bengala, poderia auxiliar o deficiente
visual a se locomover de forma mais rapida e eficiente, dado que saberia quando parar ou
virar com base em informacoes mais distantes que o alcance de 1 metro da bengala. Alem
disso, variaveis como altura, distancia e localizacao relativa dos obstaculos.
16
1.4 Metodologia
Para o desenvolvimento deste projeto, buscou-se algo agil que permitisse o desen-
volvimento de varios prototipos e a busca de feedback o mais rapido possıvel. Isto e
necessario, dado que o projeto atende a necessidades de um publico especıfico e que pos-
sui sensibilidade e impressoes diferentes do publico medio, de forma que a questao do
design e usabilidade e essencial.
1.4.1 Visita inicial para entendimento do problema
Sera feito contato com institutos de apoio a deficientes visuais e a partir de pergun-
tas abertas, identificar necessidades, problemas e desafios do publico alvo em relacao a
mobilidade. Alem disso, sera visado tambem uma parceria na qual o instituto fornecera
feedback ao grupo sobre a tecnologia sendo desenvolvida.
1.4.2 Desenvolvimento agil e exploratorio de um primeiro prototipo
Uma frente cuidara em criar um prototipo e simular sinais de vibracao para simular
ambientes e sera encarregada da criacao do objeto, alimentacao eletrica enquanto outra
frente estara focada em utilizar o Kinect para desenvolver o algoritmo de deteccao de
obstaculos e gerar sinais virtuais para a matriz de motores vibracall.
1.4.3 Coleta de Feedback e Discussao
Cada versao do prototipo sera levado para um dos institutos de pesquisa na qual
foram firmados parcerias e entao sera feito um teste dos prototipos com voluntarios por-
tadores de deficiencia visual. Serao avaliados qualitativamente a autonomia do usuario
em se locomover com e sem a bengala, a quantidade de obstaculos identificados e nao
identificados.
1.5 Objetivo do projeto
A proposta do projeto e desenvolver um sistema assistivo de baixo custo que seja
capaz de transmitir em tempo real informacoes espaciais de altura, dimensao, distancia
e localizacao relativa de multiplos obstaculos atraves de sinais mecanicos de vibracao em
17
uma matriz com nove motores vibratorios para dar ao usuario uma nocao fısica mais
precisa do ambiente utilizando tecnicas de processamento de imagem.
18
2 FUNDAMENTOS CONCEITUAIS
2.1 Processamento de imagem
A area de processamento de imagens surgiu com aplicacoes que remetem ao comeco do
seculo XX, onde buscava-se aprimorar a qualidade de imagens digitalizadas transmitidas
atraves de cabos submarinos entre Londres e Nova Iorque. A tecnica utilizada na epoca
era feita atraves de maquinas especializadas que codificavam a imagem e assim sendo
possıvel transmitir pelo cabo e ser reconstruıdo a partir do codigo recebido.
O surgimento de computadores digitais teve impacto significante para expansao da
area na decada de 60, quando os primeiros computadores conseguiam dar suporte para
o processamento de imagens. Armazenamento em memoria, processamento de dados,
display e transmissao sao recursos que possibilitaram e otimizaram tecnicas e algoritmos
de digitalizacao e processamento de imagens.(8)
Nos dias atuais, as tecnicas desenvolvidas pela area sao utilizadas por varios ramos de
atividades da sociedade. Diversas areas(e.g. medica, biologica, espacial, militar, indus-
trial) utilizam de tecnicas de processamento de imagem e sao beneficiadas com os avancos
realizados na area.
2.1.1 Arquitetura de sistemas de processamento de imagem
Um sistema de processamento de imagens pode ser representado de forma geral atraves
de 4 modulos principais. Os modulos sao aquisicao, processamento, armazenamento e
saıda. (9)
1. Aquisicao
A aquisicao e responsavel por obter a imagem e codificar de forma adequada para
ser processada a seguir pelo sistema. De forma geral e composto por um dispositivo
fısico que capta o ambiente atraves de ondas eletromagneticas(e.g. raio X, ultra-
19
violeta, infravermelho) e converte em sinal eletrico. Um segundo dispositivo fica
responsavel pela discretizacao do sinal eletrico em sinal digital.
2. Processamento
O processamento e responsavel pelo tratamento dos dados obtidos pela aquisicao.
Na maioria dos casos, o tratamento e realizado atraves de algoritmos implementados
em software que manipulam os dados obtidos de forma a gerar resultado a ser
utilizado ou armazenado. Alguns casos especıficos utilizam hardware dedicados a
processamento que possibilitam algumas vantagens, como por exemplo, reducao de
custo, modularidade, reutilizacao de hardware.
3. Armazenamento
O armazenamento e responsavel por guardar a informacao referente aos dados cap-
tados e processados. O armazenamento pode ser diferenciado pela quantidade de
dados a serem armazenados e pela ocorrencia de requisicoes dos dados. Os dados
podem ser reutilizados por varias etapas do algoritmo e armazenados em memoria
de acesso rapido ou podem ser arquivados em disco para serem persistidas.
4. Saıda
A saıda e responsavel pela exibicao de resultados e monitoramento do processamento
de dados. Geralmente sao implementados atraves de display de vıdeo e audio.
Figura 2.1: Arquitetura de sistemas de processamento de imagem
Fonte: Adaptado de (9)
20
2.2 Arquitetura do modelo ODP
O modelo de referencia de processamento distribuıdo aberto(RM-ODP) e um fra-
mework desenvolvido pela Organizacao Mundial de Normalizacao(ISO) e Uniao Inter-
nacional das Telecomunicacoes(ITU) baseado em pontos de vista para estruturar e dar
suporte para integracao da distribuicao, interoperabilidade e portabilidade de sistema
complexos de grande porte.
O padrao RM-ODP possui quatro elementos fundamentais:
1. Abordagem em modelagem orientada a objetos para especificacao de sistemas;
2. Especificacao de sistema em termos de especificacoes de ponto de vista separados,
mas inter-relacionados;
3. Definicao de infraestrutura que prove transparencias de distribuicao para aplicacoes
de sistema;
4. Framework para avaliacao de aderencia do sistema ao padrao;
2.2.1 Especificacoes de ponto de vista
Um ponto de vista pode ser definido como uma abstracao que fornece especificacao
de um sistema baseado em um conjunto particular de interesses(ISO 42010). Utilizando
diferentes pontos de vista e possıvel separar um sistema grande e complexo em partes ge-
renciaveis, cada um focalizando aspectos diferentes e importantes para o desenvolvimento
do sistema original.(10)
O framework RM-ODP fornece 5 pontos de vista complementares:
1. Ponto de vista empresarial
Enfoque em aspectos relacionados ao contexto de empresa e necessidades de usuarios.
O sistema e modelado a partir de funcionalidades requeridas, domınios envolvidos,
atores e seus respectivos papeis;
2. Ponto de vista de informacao
Enfoque em modelagem de fluxo de informacao, provendo uma visao que aborde as
fontes e destinos de informacao;
21
3. Ponto de vista de engenharia
Complementa o ponto de vista computacional com enfoque em mecanismos de dis-
tribuicao;
4. Ponto de vista tecnologico
Enfoque em detalhe de componentes e plataformas nas quais o sistema sera cons-
truıdo;
Os pontos de vista devem ser utilizados nas diversas fases do ciclo de vida do sistema
ODP.
Figura 2.2: Ciclo de vida de projeto dividido por pontos de vista
Fonte: (10)
2.3 Nuvem de pontos
O conceito de nuvem de pontos e chave para a implementacao do projeto, ja que toda
a implementacao do software abstrai a aplicacao do mesmo.
Uma nuvem de pontos e uma estrutura de dados que representa um conjunto de pontos
multi-dimensionais. No presente projeto, esses pontos representam uma localizacao fısica
em um espaco fısico tridimensional. Em outras palavras, cada ponto possui tres dimensoes,
22
as coordenadas geometricas X, Y e Z, e representam uma localizacao de uma superfıcie
de algum objeto/pessoa no espaco.
Atraves do mapeamento de um espaco fısico e obtencao de sua nuvem de pontos
equivalente, e possıvel processar, manipular e aplicar algoritmos nesse conjunto de pontos
a fim de extrair informacoes relevantes quanto a presenca de obstaculos em uma distancia
relevante ao deficiente visual.
2.4 Bibliotecas e Algoritmos Utilizados
2.4.1 Algoritmo RANSAC
O algoritmo RANSAC foi inicialmente introduzido por Fischer e Bolles em 1981 como
um metodo de estimacao de parametros de modelos atraves de um conjunto de dados
contendo grande quantidade de valores outliers. O algoritmo determina a estimacao
do parametro atraves de solucoes candidatas usando uma amostra do menor tamanho
possıvel.(11)
O metodo do algoritmo pode ser dividido em dois passos que sao repetidos em um
processo interativo:
1. Hipotese;
2. Teste;
Alem disso, alguns parametros sao utilizados na determinacao da estimacao do mo-
delo.
1. Tamanho da amostra de dados utilizados para estimacao do modelo.
2. Numero maximo de iteracoes realizadas pelo algoritmo.
3. Tolerancia de erro de aderencia dos dados com o modelo.
A etapa de hipotese e relacionado com a escolha aleatoria de uma amostra de dados
que sao utilizados para criar um modelo de estimacao do parametro desejado. A partir do
resultado obtido, avalia-se os demais pontos do conjunto de dados para avaliar a aderencia
do modelo com uma tolerancia ε pre-determinada e determinar o numero de outliers. Caso
a proporcao de inliers supere a proporcao de outliers, o algoritmo estima mais uma vez
23
usando o mesmo modelo utilizando todos os dados, caso contrario, inicia-se mais uma
nova iteracao do algoritmo.
O numero de iteracoes, N, e escolhido grande o suficiente de forma a garantir que a
probabilidade p de pelo menos um conjunto de dados aleatorios nao inclua um outlier.
Sendo m o numero mınimo de pontos da amostra aleatoria, demonstra-se que o numero
de interacoes N pode ser calculado por:
N =log(1− p)
log(1− (1− v)m)(2.1)
Onde v representa a probabilidade de um dado ser um outlier.(12)
Figura 2.3: Exemplo de execucao do algoritmo RANSAC
Fonte: (13)
2.4.2 OpenGL
OpenGL e uma das APIs graficas mais utilizadas para aplicacoes graficas 2D e 3D
no mundo. Foi desenvolvida pela Silicon Graphics no inıcio dos anos 90. Esta API tem
um esquema de funcionamento de pipeline, onde existe um buffer de comandos. Ao se
esvaziar o buffer, os comandos sao passados para etapas de transformacao e iluminacao,
rasterizacao e por fim sao colocados em um Frame Buffer, ou seja, a imagem e exibida
em um monitor.(14)
24
Figura 2.4: Versao simplificada do pipeline OpenGL
Fonte: (14)
Alem da OpenGL, existem bibliotecas auxiliares que possuem um conjunto de funcoes
que facilitam o uso da API OpenGL. As mais notaveis sao a OpenGL Utility Library
(GLU), que permite a criacao de coordenadas no espaco, facilita o desenho de superfıcies
quadricas e texturas, entre outras funcoes, e a OpenGL Utility Toolkit (GLUT), que
implementa sistema de janelas, tratamento de eventos com mouse e teclado, possibilitando
o desenvolvimento em diferentes plataformas.
Dessa forma, a OpenGL, juntamente com as bibliotecas auxiliares citadas, GLU e
GLUT, foram utilizadas para visualizacao e depuracao da nuvem de pontos obtidas pelas
cameras Kinect e Intel RealSense, que serao apresentadas nas proximas secoes. Alem
disso, foi util para processo de debugging do codigo e de algoritmos.
2.4.3 Point Cloud Library (PCL)
A Point Cloud Library (PCL) consiste em uma biblioteca open-source para imagens
2D e 3D e processamento de nuvem de pontos. Ela possui inumeros algoritmos que
incluem: filtro, estimativa de recurso, reconstrucao de superfıcies, fitting de modelo e
segmentacao. (15)
Para ilustrar a diversidade de aplicacoes e algoritmos presente nesta biblioteca, segue
um diagrama onde cada no representa um modulo da PCL.
25
Figura 2.5: Diagrama de modulos da PCL
Fonte: (16)
Apesar da biblioteca nao ser utilizada na versao do software escrito, ela foi extrema-
mente importante na fase de testes, por conter funcoes de filtro e segmentacao da nuvem,
estruturas de classes propıcias para aplicacoes com nuvens de pontos (classes para pon-
tos, vetores, planos, matrizes de rotacao e translacao, entre outras) e algoritmos como o
proprio RANSAC ja citado anteriormente.
2.4.4 Libfreenect
A Libfreenect e uma biblioteca que faz parte do projeto OpenKinect, e apresenta uma
API que permite interfacear software com os recursos da camera Kinect, da Microsoft.
Entre estes recursos, estao: imagens RGB e de profundidade, motores de inclinacao,
acelerometro, LED e audio. Ela apresenta diversos wrappers que permitem a utilizacao
de diversas linguagens de programacao, como C, C++, Java e Python.
A Libfreenect foi um recurso importante no estagio inicial de desenvolvimento do
software, onde foi utilizada a camera Kinect, tambem capaz de gerar nuvens de pontos.
(17)
2.4.5 Librealsense
Por fim, assim como a Libfreenect possibilita a interface com a camera Kinect, a
Librealsense tem o papel de interfacear os recursos da camera RealSense da Intel com
software. As diferencas e os recursos das duas cameras sao apresentados no proximo
capıtulo.
Entre seus principais recursos estao: uma aplicacao padrao que permite a visualizacao
de imagens 2D e 3D da camera, nuvem de pontos, ferramentas de debug, codigos exemplo
e wrappers para diversas linguagens de programacao. (18)
26
2.5 Internet das Coisas
Segundo a definicao de (19), a internet das coisas se refere a construcao de uma rede
de infraestrutura dinamica e global capaz de se autoconfigurar com base em padroes e
protocolos de comunicacao, nos quais coisas virtuais e fısicas possuem identidade, atri-
butos e interfaces inteligentes para se integrar a rede de informacao. Dentro do universo
de internet das coisas, os objetos ou coisas inteligentes se tornam participantes ativos nos
negocios, na troca de informacoes e em processos sociais. Esses objetos inteligentes sao
caracterizados pela capacidade de interacao e comunicacao entre si atraves da troca de
dados ou informacoes capturadas por meio de sensores eletronicos que convertem os sinais
analogicos do ambiente em sinais digitais. Ao mesmo tempo, esses objetos sao capazes
de comandar dispositivos atuadores que agem de volta no ambiente, ativando processos,
acoes ou reacoes sem a necessidade da intervencao humana.
2.5.1 Tecnologias de IoT(Internet of Things)
Aplicacoes de IoT necessitam que dados sejam coletados, processados, transformados
em informacoes uteis e compartilhados com dispositivos conectados a mesma rede. Dessa
forma, sao utilizados hardwares, softwares e tecnologias de processamento de dados para
compor um sistema inteligente.
O mercado ja oferece diversas opcoes de tecnologias comerciais para desenvolvimento
de projeto de sistemas inteligentes. Plataformas de processamento de dados portateis
como Arduino e Raspberry Pi sao amplamente utilizados com sensores capazes de coletar
dados e converte-los para sinais digitais. Protocolos de comunicacao de dados como WiFi,
Ethernert e Bluetooth sao padronizados pela IEEE e utilizados para diversas aplicacoes
de internet das coisas. Por fim, a nova tendencia de dados massivos(Big Data) e a neces-
sidade alta velocidade de processamento de dados e suportada por uma infraestrutura de
“nuvem” que permite o uso de mais recursos computacionais.
2.5.2 Aplicacoes de Internet das Coisas
As aplicacoes baseadas em IoT podem ser utilizadas em diversas areas para beneficiar a
sociedade e impulsionar o mercado e a industria. Essas tecnologias possibilitam conectar
as pessoas de uma forma mais facil e oferecer informacoes relevantes para tomadas de
decisoes inteligentes no momento adequado.
27
A tabela adaptada de (20) abaixo ilustra uma divisao de tres grandes domınios de
aplicacao de IoT.
Tabela 2.1: Domınios de aplicacao IoT
Domınio Descricao Aplicacoes
SociedadeAtividades relacionadas a melhoria e desen-
volvimento da sociedade, cidades e pessoas
Cidades inteligentes,
Fazendas inteligentes,
Agricultura inteli-
gente, Saude, Au-
tomacao residencial,
Telecomunicacoes,
Energia, Vida inde-
pendente
Meio Ambiente
Atividades relacionadas a protecao, monito-
ramento e desenvolvimento de recursos natu-
rais
Meio ambiente inteli-
gente, Alerta de de-
sastres, Medicao inte-
ligente
Industria
Atividades relacionadas a financas,
transacoes comerciais entre empresas,
organizacoes e outras entidades
Controle indus-
trial, Aeroespacial,
Aviacao, Varejo,
Supply chain
Fonte: Adaptado de (20)
Dentre as aplicacoes apresentadas, e possıvel ver que este projeto tem como foco
a area de tecnologia assistiva voltada para proporcionar mais autonomia para usuarios
com deficiencia visual. Alem disso, procura-se desenvolver um sistema reaproveitando
tecnologias ja encontradas no mercado de forma a disponibilizar para interessados em
investir em projetos voltados para assistencia de deficientes visuais.
2.6 Deficiencia Visual
2.6.1 Definicao e classificacao
Em 1966, a Organizacao Mundial da Saude(OMS) registrou 66 diferentes definicoes de
cegueira, utilizada para fins estatısticos em diversos paıses. Visando simplificar o assunto,
28
um grupo de pesquisa de prevencao da cegueira da OMS, em 1972, propos normas para
definicao de cegueira e para uniformizar as anotacoes dos valores de acuidade visual com
finalidades estatısticas.
O termo cegueira nao e absoluto, pois reune indivıduos com diversos graus de de-
ficiencia visual. Ela nao representa a total incapacidade de ver, mas sim graus de prejuızos
do sentido da visao que impactam nas atividades rotineiras da pessoa.
O termo “cegueira parcial” engloba indivıduos capazes apenas de contar os dedos
a curta distancia e os que reconhecem vultos. Aproximando-se da cegueira total estao
os indivıduos que possuem percepcao de projecoes luminosas. No primeiro caso, existe
apenas a distincao de claro e escuro; no segundo o indivıduo tambem e capaz de identificar
a direcao de onde provem a luz. A cegueira total ou amaurose implica a perda total de
visao que impossibilita a percepcao de luz no ambiente.
Uma pessoa pode ser considerada com “cegueira parcial” se a visao do seu melhor
olho e 6/60 ou menos, isto e, ela pode ver 6 metros o que uma pessoa normal pode ver
a 60 metros, ou se o campo visual corresponde a um arco menor que 20o ainda que sua
acuidade visual supere 6/60.(21)
2.6.2 Causas
De acordo com dados da OMS, as principais causas mais comuns de deficiencia visual
sao:
• erros refrativos incorretos
• cataratas
• degeneracao macular relacionado a idade
• glaucoma
• retinopatia diabetica
• opacidade da cornea
• tracoma
Existe uma variacao das causas de acordo com o paıs. Em paıses subdesenvolvidos
a proporcao de deficientes visuais causados por cataratas e maior em comparacao com
29
paıses ricos. Entre as criancas, as causas variam bastante de acordo com o paıs. Ca-
tarata congenital e uma causa recorrente em paıses subdesenvolvidos enquanto que em
paıses desenvolvidos as causa tendem a ser devido a retinopatia diabetica e nascimento
de prematuros. (1)
30
3 O SISTEMA DE NAVEGACAO
O objetivo deste capıtulo e dar uma visao geral sobre o sistema desenvolvido, com des-
cricoes em seus aspectos conceituais de projetos, com diagramas e algoritmos indicando
sua operacao e tambem entrar em detalhes sobre a tecnologia de hardware e software
utilizada em sua implementacao. Inicialmente, sera abordado aspectos de negocio, em se-
guida serao feitas descricoes de seus requisitos funcionais e nao funcionais, sua modelagem
estatica e dinamica e a engenharia por tras no projeto.
3.1 Negocio
Este subcapıtulo descreve aspectos de negocio do problema a ser abordado nesta
monografia, como o domınio do problema, stakeholders importantes, capacidade de adicao
de valor.
3.1.1 Domınio do Problema
O enfoque do projeto e a questao da mobilidade para deficientes visuais em ambientes
outdoor atraves da comunicacao por uma matriz de motores vibratorios que indicaria
altura, distancia e localizacao relativa de multiplos obstaculos. Note que nao existe uma
preocupacao em identificar o que sao tais obstaculos, apenas detectar sua presenca. Con-
forme discussao inicial com o Instituto Laramara, percebeu-se que o projeto teria um valor
maior em ambientes outdoor pelo fato de que em ambientes indoor deficientes visuais em
contam com ajuda de terceiros e existe um enfoque muito maior em identificar o que e
cada objeto.
3.1.2 Stakeholders
O projeto apresenta dois stakeholders importantes.
31
• Usuario
O usuario e um indivıduo portador de deficiencia visual (Cegueira ou baixa visao).
O principal stakeholder do projeto no sentido de que este foi criado para resolver o
problema da mobilidade destes usuarios. Sendo um indivıduo com necessidades e
sentidos diferentes do publico usual, a questao da experiencia de usuario se torna
muito mais relevante e a necessidade de iterar o projeto com feedback destes usuarios
se torna bastante importante.
• Fundacao Dorina Nowill
A instituicao nos auxiliou reunindo voluntarios para realizacao de testes do sistema e
fornecimento de feedback, o que e crucial para o desenvolvimento do projeto. Alem
disso, tambem nos auxiliou em uma visita tecnica na qual foram apresentadas a
infraestrutura do instituto e artefatos criados para auxiliar deficientes visuais. Por
outro lado, o projeto teria codigo aberto por ser vinculado a universidade podendo
ser aproveitado futuramente.
3.1.3 Adicao de Valor
Este projeto visa adicionar valor ao usuario final em tres pontos:
• Estudos indicam que a velocidade na locomocao de deficientes visuais e diretamente
afetada pela disponibilidade de informacoes previas sobre o ambiente (Clark-Carter
(1985))
• Reducao de riscos de acidentes devido a deteccao de obstaculos aereos.
• O usuario pode se sentir mais seguro conhecendo melhor o ambiente fısico ao seu
redor.
3.2 Requisitos do Sistema
3.2.1 Modelo Estatico
Este projeto apresenta cinco classes, descritas individualmente abaixo.
32
3.2.1.1 Classe RealSense
Esta classe serve para encapsular operacoes de leitura tanto da camera RealSense
quanto do giroscopio de tres eixos. O metodo getPontos() obteria um vetor de 1280x720
pontos a partir da transmissao USB da camera. Note que o hardware da camera fornece
apenas as informacoes X,Y e profundidade, de forma que esta classe faz um rapido pro-
cessamento para transformar em (X,Y,Z). Este conjunto de vetores teria sua resolucao
reduzida no programa principal, visando uma relacao precisao/desempenho superior. O
metodo getInclinacao() obteria um vetor de tres valores flutuantes que indicariam a in-
clinacao do giroscopio, que fisicamente estaria acoplado ao Intel RealSense.
3.2.1.2 Classe Ponto
Esta classe representa um ponto lido pela camera e possui caracterısticas de cor no
padrao RGB (Vermelho, Verde e Azul), valores inteiros que variam de 0 a 255, e tambem
informacoes espaciais (Posicao X,Y,Z).
3.2.1.3 Classe Piso
A partir do conjunto de pontos, um segundo tratamento e necessario. Utilizando-se
o algoritmo RANSAC, o programa principal localiza o conjunto de ponto que compoe o
piso, calculando os parametros a,b,c e d da sua equacao (Equacao do plano: a.x + b.y +
c.z + d = 0), a partir do qual e possıvel obter a altura do piso e entao filtrado os pontos.
Esta classe e criada para auxiliar este processamento.
3.2.1.4 Classe Obstaculo
A partir do conjunto de pontos fornecido pela classe RealSense, o programa principal
identifica um vetor de obstaculos significativos e incluira nele a referencia de todos os
pontos que o compoem, de forma a calcular sua distancia, altura e localizacao media
relativa a camera RealSense.
3.2.1.5 Classe MotorVibraCall
Esta classe serve para encapsular os pinos de saıda e a geracao de PWM. A partir do
vetor de obstaculos obtido, bem como suas distancias, localizacoes e alturas, o programa
principal calcula a intensidade de vibracao de cada motor. Note que, como cada motor
33
esta associado a um pino de saıda, e necessario um identificador de 1 a 9 para que o
desenvolvedor saiba qual pino esta sendo ativado.
Estas informacoes estao sintetizadas no diagrama de classes abaixo:
Figura 3.1: Diagrama de classes
Fonte: Autores
3.2.2 Modelo Dinamico
O modelo dinamico deste projeto e relativamente simples, dado a existencia de apenas
um cenario de uso e cinco classes, no qual o programa principal (Controlador) executa
o codigo em loop contınuo. A figura abaixo indica o diagrama de sequencia do modo de
funcionamento do sistema.
34
Figura 3.2: Diagrama de classes
Fonte: Autores
3.2.3 Requisitos Funcionais
• Requisito #1: O sistema deve identificar o piso e filtrar a uma certa
altura acima do piso.
Este requisito e necessario para que o proprio sistema nao identifique o piso como
obstaculo. Da mesma forma, a identificacao de um piso serve como referencia de
altura dos obstaculos.
• Requisito #2: O sistema deve filtrar pontos cuja distancia ate a camera
excede 4m
Este requisito e necessario para reduzir o numero de alertas gerados por obstaculos
muito distantes e desviar o enfoque para obstaculos mais proximos e que apresentam
maiores riscos ao usuario.
• Requisito #3: O sistema deve identificar a posicao relativa lateral de
obstaculos
• Requisito #4: O sistema deve identificar a distancia media do obstaculo
35
• Requisito #5: O sistema deve identificar a altura media do obstaculo
Os requisitos 3 a 5 sao importantes para obter os componentes da geometria dos
obstaculos e dos arredores mais importantes a serem comunicados ao usuario.
• Requisito #6: O sistema deve deve ser capaz de traduzir distancia, altura
e posicao relativa na vibracao dos nove motores.
Este requisito e central no projeto considerando o objetivo de fazer comunicacao
com o usuario final via sinais de vibracao.
A tabela abaixo resume os requisitos funcionais:
Tabela 3.1: Requisitos funcionais
Fonte: Autores
3.2.4 Requisitos Nao Funcionais
• Requisito #1: O dispositivo deve gerar alertas pelo menos 3m de distancia
do usuario.
Um dos aspectos mais importantes do sistema e o tempo de resposta, dado que
um atraso significante na geracao da respostas a partir da deteccao do obstaculo
apresenta um risco consideravel para o usuario. Definiu-se a distancia mınima como
sendo de 3m pois nao e tao distante a ponto de gerar diversos sinais de obstaculos
muitos distantes confundir o usuario, mas distante o suficiente para que seja possıvel
identificar tais obstaculos antes da bengala.
• Requisito #2: O sistema deve minimizar o numero de erros (Falsos ne-
gativos e falsos positivos)
As informacoes espaciais fornecidas pelo sistema devem ser precisas. Caso contrario
o usuario final nao confiaria em sua capacidade de identificar obstaculos, o que o
tornar inutil. Uma medida simples de erros do sistema e a quantidade de falsos
negativos e falsos positivos ao longo de um trajeto.
36
• Requisito #3: A proporcao entre falsos positivos e falsos negativos deve
ser maior que 10.
Enquanto falsos positivos nao apresentam riscos de acidentes, tendo apenas como
ponto negativo o fato de que o usuario reduzira a velocidade, falsos positivos podem
acarretar em riscos ao usuario. Desta forma, focou-se em criar um sistema com uma
sensibilidade elevada e assim evitar ao maximo a existencia de falsos negativos.
• Requisito #4: O sistema deve apresentar uma aparencia discreta e sim-
ples de vestir e remover.
Outro requisito funcional bastante citado pelos voluntarios durante as pesquisas
iniciais, e a questao estetica. Muitos deles citavam a necessidade do sistema ser
invisıvel ou pelo menos discreto e apresentar poucos fios. Esta questao, de difıcil
medicao, foi levada em consideracao nas iteracoes do design dos prototipos.
• Requisito #5: O sistema deve ter uma autonomia energetica de 3h.
A bateria deve ser dimensionada para suportar no mınimo 3h de operacao contınua
do dispositivo. Este valor de tres horas foi considerada pois um valor muito maior
poderia aumentar o custo do projeto e torna-lo mais pesado e menos discreto. Por
outro lado, valores menores acarretam o risco do sistema ficar indisponıvel apos um
intervalo sem acesso a tomadas mais prolongado. Acredita-se que a 3g seja suficiente
para a maioria das viagens e foi feita a suposicao de que o usuario possui facil acesso
a tomadas.
• Requisito Funcional #6: O sistema deve transmitir as informacoes de
uma forma intuitiva.
A disposicao dos motores que irao alertar o usuario deve ser feita de forma a tornar
intuitivo a forma de interpretar as respostas geradas pelo sistema de navegacao.
A tabela abaixo resume os requisitos nao funcionais:
37
Tabela 3.2: Requisitos nao funcionais
Fonte: Autores
3.3 Solucao Tecnica
Este capıtulo descreve a implementacao do sistema em termos do hardware e software
desenvolvidos para sua realizacao, bem como as tecnologias utilizadas.
3.3.1 Tecnologia
Este subitem descreve os dispositivos necessarios para a construcao do sistema, como
sensores, atuadores e modulos de computacao.
38
3.3.1.1 Raspberry Pi 3 Model B
Figura 3.3: Raspberry Pi 3 Model B
Fonte: (22)
O processamento de dados foi realizado do microcomputador Raspberry Pi. O Rasp-
berry foi escolhido por ser leve e portatil, mas com poder computacional suficiente para
executar os programas de deteccao de obstaculos, planos e objetos, alem de possuir en-
trada USB capaz de fazer interface com o Raspberry Pi e pinos de GPIO que podem ser
usados para gerar os sinais de alerta para a interface de alerta para o usuario. O modelo
Raspberry a ser usado sera o modelo 3 por apresentar melhores recursos mas sem perder
a portabilidade. As especificacoes do hardware do Raspberry Pi estao indicados abaixo
(22):
• SoC: Broadcom BCM2837
• CPU: 1.2 GHZ quad-core ARM Cortex A53 (ARMv8 Instruction Set)
• GPU: Broadcom VideoCore IV @ 400 MHz
• Memoria: 1 GB LPDDR2-900 SDRAM
• Portas USB: 4
• Rede: 10/100 MBPS Ethernet, 802.11n Wireless LAN, Bluetooth 4.0
39
3.3.1.2 Intel RealSense D435
Figura 3.4: Intel Real Sense
Fonte: (18)
O RealSense da Intel e uma tecnologia que realiza o mapeamento do ambiente atraves
da coleta de uma nuvem de pontos. O modelo D435 possui uma camera RGB que coleta
cores dos pontos numa dada resolucao enquanto sensores infravermelhos efetuam a coleta
de distancias. A camera e capaz de cruzar os dados para exportar um conjunto de pontos
com informacao de cor, distancia, localizacao.(18):
Alem disso, o modelo possui as seguintes configuracoes:
• Entrada unica USB tipo C na qual alem da transmissao de dados e feita tambem a
alimentacao da camera, o que reduz a quantidade de fios e o peso do componente.
• Possui dimensoes 90mm x 25mm x 25mm, o que o torna portatil para desenvolvi-
mento de projeto que embarcam o D435.
• O D435 possui operacao melhor em ambientes outdoor, na qual observa-se que o
Kinect apresenta problemas de ruıdo.
40
3.3.1.3 MPU-6050 (Acelerometro e giroscopio)
Figura 3.5: MPU-6050
Fonte: (23)
O MPU-6050 e uma pequena placa que possui acelerometro e giroscopio, criada para
funcionar com baixo gasto energetico, baixo custo e alta performance. Por isso, pode ser
utilizada em smartphones, tablets, wearables e projetos com Arduino e Raspberry por
exemplo. Sua comunicacao com o Raspberry Pi se da pelo barramento I2C. Um de seus
recursos e o Digital Motion Processor (DMP), que e capaz de fundir dados do acelerometro
e do giroscopio, corrigindo erros que sao inerentes a dados exclusivamente captados por
apenas um desses recursos. O DMP realiza calculos diretamente na placa, aliviando o
processamento no Raspberry.(23)
O MPU-6050 foi acoplado ao IntelReal Sense nas versoes finais do prototipo, ja que,
diferentemente do Kinect, nao possui um acelerometro.
Ele foi importante para a obtencao da inclinacao da camera, que por sua vez e essencial
para que o codigo tenha importantes referencias, como planos paralelos e perpendiculares
ao chao.
3.3.1.4 Motores Vibracall
Foram utilizados motores de pequenas dimensoes, muito utilizados em telefones celu-
lares, que vibram quando aplicado uma tensao em seus terminais. A nocao de espaco foi
feita atraves de uma matriz de pontos vibratorios que refletem a’ distancia ate um ponto
equivalente na camera Kinect. Neste caso a vibracao e proporcional a distancia, de forma
41
a dar ao usuario um senso espacial mais detalhado. Os motores Vibracall selecionados
possuem dois terminais: Um terminal terra (GND) e um terminal de 3V, compatıvel com
o GPIO do Raspberry Pi. Pretende-se utilizar sinais de PWM para modular a intensidade
de vibracao destes motores.
Figura 3.6: Motor Vibracall
Fonte: (24)
42
3.3.1.5 Carregador Portatil
Figura 3.7: Carregador Portatil
Fonte: (25)
Utilizou-se um carregador portatil Xiao Mi Bank 2. Este carregador possui saıdas
USB de 5V, compatıveis com a alimentacao do Raspberry, dimensoes pequenas e uma
capacidade de 10000mAh, que possui uma autonomia de 4h.
3.3.2 Hardware
O sistema foi encapsulado em um colete que contem uma camera Intel RealSense
que capta dados 3D do ambiente e os fornece atraves de uma conexao USB para um
Raspberry Pi Model 3, tambem localizado no colete que efetua os calculos necessarios.
Adicionalmente, o colete contem uma bateria reserva para alimentar o Raspberry (Note
que a alimentacao do RealSense e feita por USB do Raspberry Pi). Alem do colete, o
sistema contem com um bracelete sobre o qual estao dispostos uma matriz de 3x3 motores
vibracall que sao responsaveis por dar o feedback tactil necessario.
Os nove motores tem o pino GND soldados juntos entre si e conectados ao de GND
do Raspberry Pi e tem o pino de alimentacao conectado a saıdas digitais GPIO do
Raspberry, na qual sao alimentados por sinais modulados por pulso (PWM) gerados
via software. Os pinos com barragem I2C sao utilizados para conectar o modulo MPU-
6050(acelerometro/giroscopio).
43
O mapa de pinos e apresentado conforme figura abaixo.
Figura 3.8: Pinagem do Raspberry Pi 3
Fonte: (26)
3.3.2.1 Geracao dos Sinais de Vibracao
Como o Raspberry Pi contem apenas 2 pinos de PWM, optou-se por usar pinos de
GPIO digitais e fazer a modulacao em pulso via software. Apesar do PWM gerado ser de
menor resolucao, acredita-se que o usuario final nao tenha sensibilidade para distinguı-
los. O acesso a estes pinos e feito atraves da escrita e leitura de regioes da memoria, que
configuram operacoes bastante lentas.
3.3.2.2 Alimentacao do Raspberry Pi
A alimentacao do Raspberry Pi e feita via entrada micro USB com tensao de 5.1V.
Como a potencia varia com a aplicacao a que se dedica o uso da placa, o fabricante
recomenda a utilizacao de uma fonte que forneca 2.5 A de corrente, sendo que na pratica
o consumo tende a ser muito menor. Para o desenvolvimento deste projeto, utilizou-
se como bateria um carregador portatil Xiaomi Power Bank 2, que possui capacidade
de 10000mAh. Considerando-se no maximo 2.5A de corrente, o tempo de vida mınimo
para consumo da bateria seria em torno de quatro horas. A tabela abaixo resume as
especificacoes da bateria.
44
Tabela 3.3: Especificacao da bateria
Fonte: (25)
3.3.3 Software
3.3.3.1 Pre-Processamento
1. O controlador efetua a leitura do conjunto de pontos a partir do metodo getPontos da
classe RealSense, que obtem um vetor de pontos (R,G,B,X,Y,Depth), efetua calculos
geometricos e retorna um vetor de pontos (R,G,B,X,Y,Z) a partir da propria leitura
do acelerometro acoplado ao Intel RealSense.
2. O controlador reduz a resolucao do conjunto de pontos de 1280 x 720 para 640
x 360 para melhorar o desempenho. Dado que o tempo de resposta do sistema e
um requisito nao funcional crıtico, esta etapa e importante para reduzir o numero
de pontos a serem processados em quatro vezes. Alem disso, como o projeto esta
focado em identificar objetos grandes em vez de pequenos detalhes, esta diminuicao
de resolucao nao leva a reducoes significativas de precisao.
3. O controlador calcula a inclinacao e a altura no piso a partir do algoritmo RANSAC,
que obtem os parametros (a,b,c,d) de sua equacao de reta (a.x+b.y+c.z+d=0),
criando uma instancia da classe piso.
4. O controlador remove os pontos cuja distancia esta acima de um certo limite. Isto
e feito para que nao sejam identificados obstaculos muito distantes, o que reduz
bastante o ruıdo da camera e da maior importancia para obstaculos mais proximos.
3.3.3.2 Acionamento dos Motores
A geracao de sinais de PWM foi encapsulada na classe MotorVibraCall, que possuira
um metodo capaz de ativar um dos motores. Sua identificacao (De 1 a 9) identificar qual
pino sera escrito. Alem disso, possuira um atributo que indicara o nıvel de vibracao,
45
discretizado em quatro nıveis, dado que o usuario nao apresenta sensibilidade suficiente
para distinguir entre um numero maior de nıveis de vibracao. A implementacao e feita
por meio de contadores.
3.3.3.3 Interface Obstaculos-Vibracao
O programa principal contara com um array de nove instancias da classe MotorVi-
braCall. Intensidade da vibracao: Indica o quanto a distancia do obstaculo ao usuario.
A traducao entre a vibracao dos motores para localizacao dos objetos segue as diretrizes:
A localizacao no eixo X indica a posicao relativa lateral do obstaculo. A quantidade de
motores ativados ao longo do eixo y (Paralelo ao antebraco) indica a altura do obstaculo.
Caso apenas o motor mais proximo do tronco esteja ativado, trata-se de um obstaculo de
altura media. Caso trate-se de um obstaculo alto, toda a fileira de motores vibrara. Por
fim, a intensidade de bibracao indica a proximidade do obstaculo.
Figura 3.9: Interface Obstaculos-Vibracao
Fonte: Autores
46
4 O SISTEMA IMPLEMENTADO
Este capıtulo descreve a implementacao do projeto.
4.1 Visitas preliminares
Conforme descrito na metodologia, foram feitas duas visitas a institutos de assistencia
a deficientes visuais para melhor entendimento do problema, que estao descritos abaixo.
4.1.1 Instituto Laramara
A visita foi feita com um representante, tambem deficiente visual, que lida com pro-
jetos do instituto, que apresentou uma postura bastante cetica em relacao ao projeto,
fazendo diversos questionamentos. Por exemplo, indicou a necessidade do sistema lidar
com objetos aereos nao identificados por bengalas ou caes guias e tambem a necessidade
de desenvolver o projeto para ambientes outdoor. A justificativa do representante trouxe
insights importantes. Em estabelecimentos indoor, ha pessoas para auxiliar o deficiente e
existe um enfoque muito maior em identificar o que cada obstaculo representa, enquanto
em ambientes outdoor, o deficiente em geral nao possui ajuda e precisa, muito mais que
identificar o que cada obstaculo e, sua localizacao e geometria. Por fim, destacou a ne-
cessidade do projeto ter um custo reduzido dado que a populacao deficiente visual possui
uma renda abaixo da media.
Diante desses fatos, decidiu-se por uma mudanca de escopo. O projeto inicialmente
estava focado em identificacao de objetos como cadeiras, planos e paredes, sendo voltado
mais para ambientes indoor. Apos estas discussoes, o projeto focou em ambientes outdoor,
optando pela localizacao apenas dos obstaculos, sobretudo aereos.
Da mesma forma, foi necessario adaptacao tecnologica: Como o Kinect possui baixa
precisao em ambientes de iluminacao muito alta ou muito baixa, preferiu-se optar pela
camera RealSense da Intel. De forma geral, esta reuniao trouxe muitos insights e questi-
47
onamentos, mas houve duvidas sobre uma possıvel parceria.
4.1.2 Fundacao Dorina Nowill
Faz parte da polıtica do instituto que parceiros interessados em desenvolver projetos
com a instituicao facam uma visita geral ao instituto. Neste caso, foi possıvel visitar o
instituto e conhecer a historia da empresa, que comecou como uma biblioteca de livros
Braille e hoje e a maior editora do tipo na America Latina, e tambem de Dorina Nowill,
que dedicou sua vida a melhorar a vida dos deficientes visuais. Adicionalmente, foi possıvel
conhecer ferramentas de assistencia ao deficiente visual como livros falados, livros braille,
diferentes tipos de bengala, pisos tateis e calculadoras especiais. Esta visita inicial, por
nao ter alguem que lide com projetos, fui mais produtiva no sentido de iniciar uma parceria
com a instituicao.
4.2 Desenvolvimento do Prototipo Fısico
Este subitem descrevera as atividades envolvidas no desenvolvimento do prototipo,
bem como integracao de feedbacks em sua concepcao.
4.2.1 Primeira Iteracao
Com base nas discussoes com as duas instituicoes e com o aluno Santiago Villalo-
bos, estudante de arquitetura na FAU-USP que trouxe importantes ajudas no design do
projeto, foi feito o primeiro prototipo fısico. A implementacao foi feita com um colete
contendo uma camera RealSense, um Raspberry Pi e uma bateria, alem de um bracelete
de pano com 4 motores vibratorios. A preferencia pelo pano se deve ao fato de que a
ativacao de um motor vibratorio numa estrutura rıgida promove a vibracao da estrutura
inteira em vez de uma vibracao local.
O prototipo foi desenvolvido usando-se cola quente sobre os motores, que tiveram seus
terras conectados. A alimentacao foi padronizada conforme descrito no capıtulo 3 com
os sinais de controle correspondentes ao sinal de alimentacao (VCC) de cada motor. A
figura abaixo indica o prototipo desenvolvido. Note que e um prototipo bastante rustico,
mas que cumpre o objetivo mınimo de associar cada motor a um sinal de vibracao gerado
pelo software.
Neste prototipo, o software ainda nao estava desenvolvido, de forma que utilizou-se
48
um programa que atribuıa valores de vibracao para cada um dos motores. O objetivo deste
primeiro prototipo era verificar, com os proprios integrantes do grupo, se os motores sao
capazes de transmitir a informacao de forma intuitiva.
Figura 4.1: Prototipo
Fonte: Autores
Os testes deste primeiro prototipo indicaram a existencia de vibracoes residuais, de
forma que era muito difıcil identificar qual dos motores estava sendo ativado. Foram
discutidas e aceitas as seguintes mudancas necessarias:
1. Utilizacao de um velcro para apertar mais o bracelete, de forma a restringir a vi-
bracao a regioes mais proximas do motor ativo.
2. Posicionar os motores na maxima distancia entre si, o que e atingido posicionando-os
em angulos de 120 graus entre si no bracelete de pano.
4.2.2 Segunda Iteracao
A figura abaixo indica o desenvolvimento do prototipo apos a implementacao das
mudancas sugeridas. Note a existencia de velcros que tornam possıvel o ajuste do bracelete
em diferentes tamanhos de bracos. Adicionalmente, o grupo optou por esconder os fios
por baixo de panos para que nao gere incomodos no usuario pelo contato com a pele, o
que tambem reduz riscos de mal-contato com o atrito frequente. Substituiu-se os fios por
fios maiores que se estendem desde o bracelete ate o colete central.
49
4.2.3 Terceira Iteracao
Apos o contato com o Instituto Dorina Nowill (Descrito melhor no capıtulo de re-
sultados), decidiu-se implementar algumas mudancas no prototipo como a utilizacao de
um cinturao contendo a matriz de motores em vez do bracelete, motivado sobretudo
pelo fato de que alguns deficientes visuais nao possuem de forma clara o conceito de
lateralidade. Desta forma, utilizou-se vibracoes do lado direito do colete para sinalizar
obstaculos do lado direito e o mesmo caso para obstaculos do lado esquerdo. Da mesma
forma, introduziu-se no colete um bolso grande que conteria o modulo computacional e
uma bateria e os fios foram melhor organizados.
A figura abaixo mostra a versao final do sistema assistivo:
Figura 4.2: Versao final do sistema assistivo
Fonte: Autores
50
4.3 Desenvolvimento do Software
4.3.1 Implementacao Exploratoria Inicial em Python
Inicialmente, foi feita uma implementacao do software em Python em um computador
comum, com o objetivo de explorar diferentes tecnicas e bibliotecas. Neste momento,
o desenvolvimento era feito para a camera Kinect devido a seu baixo custo, a grande
quantidade e suporte online, bem como comunidade de desenvolvedores bastante ativa
e tambem porque integrantes do grupo ja possuıam tal camera em casa. Utilizou-se a
biblioteca Libfreenect para fazer a interface com a camera Raspberry Pi, que tambem
continha um wrapper que permitia a escrita do codigo em Python e sua traducao para C.
A biblioteca ja apresentava metodos que encapsulam a obtencao da nuvem de pontos.
4.3.2 Substituicao pela Linguagem C++
Conforme o software ia sendo desenvolvido, cada vez mais era necessario acessar recur-
sos internos do Kinect que nao eram contemplados pelas funcoes do wrapper Python da
libfreenect. Seu alto nıvel de encapsulamento nao permitia o acesso integral aos recursos
do Kinect, o que acabou pesando na decisao em trocar por outra biblioteca.
A opcao pela wrapper em C++ tambem foi uma vantagem para se utilizar em conjunto
com a biblioteca Point Cloud Library, escrita originalmente para C++. Essa decisao foi
importante porque proporcionou maior controle, maior acesso a mais recursos internos
a camera Kinect e tambem porque apresentou um desempenho, em termos de tempo de
resposta, muito superior.
Outra vantagem eram as estruturas de dados da biblioteca PCL ja voltados para o mo-
delo de nuvem de pontos. Inclusive, a deteccao de planos utilizando algoritmo RANSAC
ja estava implementada na biblioteca, e foi testada com sucesso para se identificar o piso.
No entanto, por iterar sobre cada frame, acabava tornando o sistema muito lento para ser
executado num notebook e inviavel para ser executado no Raspberry Pi. Tentou-se diver-
sas tecnicas para aumento do desempenho, como a escrita do codigo na mao, atualizacao
dos planos numa frequencia menor e a reducao da resolucao. No entanto, era notavel a
perda de precisao conforme estas medidas eram introduzidas.
A seguir, encontram-se imagens da depuracao grafica da deteccao do chao, juntamente
com o mapeamento de obstaculos:
51
Figura 4.3: Deteccao do chao
Fonte: Autores
52
Figura 4.4: Mapeamento do espaco fısico
Fonte: Autores
4.3.3 Substituicao do Kinect pelo Intel RealSense
Apos reuniao com o Instituto Laramara, definiu-se o escopo do projeto como sendo
voltado para ambientes outdoor. Uma caracterıstica do Kinect que inviabiliza seu uso
para ambientes outdoor e uma consideravel perda de precisao quando exposto a altas lu-
minosidades. Por conta deste fator, decidiu-se utilizar o Intel RealSense, que nao possuıa
uma comunidade de desenvolvedores tao ativa, bem como um custo maior (O disposi-
tivo teve de ser importado). Ainda utilizando o Point Cloud Library como biblioteca
de processamento, foram necessarias adaptacoes para que fosse possıvel a realizacao do
projeto com o dispositivo. Uma importante mudanca necessaria foi a necessidade de um
giroscopio/acelerometro avulso. Ao contrario do Kinect que ja apresenta tal dispositivo
internamente e suas medidas sao fornecidas junto com a nuvem de pontos, o modelo uti-
lizado do Intel RealSense nao continha tal sensor, sendo necessario fazer o processamento
dos dados de inclinacao obtidos desse sensor avulso. A biblioteca utilizada para obtencao
dos dados foi a LibRealSense que encapsula operacoes de leitura do camera da Intel.
53
A principal mudanca notada com a mudanca do dispositivo foi um ganho muito sig-
nificativo na velocidade de resposta do sistema, apesar da maior resolucao. Este fator
incentivou a equipe a ja transferir o codigo para prosseguir o desenvolvimento e testes no
proprio Raspberry Pi. E de fato, com pequenos ajustes como a habilitacao de pinos I2C
para a MPU 6050 foi possıvel executar o software no Raspberry, embora com problemas
de tempo de resposta comparado ao notebook.
4.3.4 Substituicao do Algoritmo RANSAC
Por fim, dado que o projeto precisava ser entregue o mais rapido possıvel para a co-
leta de feedback com voluntarios do Instituto Dorina Nowill, optou-se por uma solucao
alternativa ao RANSAC na qual o mapa de pontos era subdividido em 27 quadrantes
tridimensionais e entao a deteccao de obstaculos levava em consideracao a distribuicao
dos pontos 3D ao longo destes quadrantes. Tal abordagem considera apenas a quanti-
dade de pontos. Como o algoritmo RANSAC envolve uma quantidade consideravel de
iteracoes para o calculo de planos, esta alternativa se provou muito mais rapida para uso
no Raspberry Pi e assim viavel para execucao junto aos prototipos desenvolvidos.
54
5 RESULTADOS OBTIDOS
Foi firmada parceria com a Fundacao Dorina Nowill, que trouxe o contato de quatro
voluntarios portadores de deficiencia visual total para realizacao dos testes. Este capıtulo
descreve os resultados obtidos durante este experimento
5.1 Experimento
5.1.1 Ambiente
O experimento foi totalmente realizado dentro do Instituto, sendo feito numa sala
inicial com uma caminhada ate o hall de entrada, num caminho que atravessava uma
porta, continha curvas a esquerda e a direita e uma rampa. Os quatro voluntarios ja
conheciam o ambiente e havia pisos tateis ao longo do caminho.
5.1.2 Participantes
Participaram do experimento quatro voluntarios, os tres integrantes do grupo e San-
tiago Villalobos, que ao longo do desenvolvimento do projeto nos trouxe importantes
auxılios no design do projeto. A divisao de tarefas durante o experimento esta indi-
cado abaixo. Neste caso, a documentacao inclui anotacoes de comentarios pertinentes,
anotacoes de resultados, fotografias e filmagens (Mediante previa autorizacao). O su-
porte tecnico inclui a execucao do codigo fonte e a monitoracao de sinais de debug como
indicadores de quais motores estao conectados, a filmagem obtida pelo Intel RealSense
e a quantidade de pontos medidas, alem de suporte no caso de eventuais falhas. O
acompanhamento sera descrito posteriormente, mas consiste no auxılio as atividades do
experimento.
55
Tabela 5.1: Tabela com participantes
Fonte: Autores
5.1.3 Metodologia
O experimento consistiu em quatro etapas: Um teste com cada motor ativado in-
dividualmente, uma caminhada acompanhada no ambiente interno a Fundacao Dorina
Nowill, uma caminhada desacompanhada e por fim entrevistas individuais. Os subitens
abaixo descrevem a realizacao destes testes.
5.1.3.1 Testes dos Motores
Inicialmente, foi feito um teste na qual cada motor era acionado de forma individual
e pedia-se que o usuario identificasse a localizacao do motor no braco. O objetivo disto
era validar se e possıvel fazer a localizacao da vibracao.
5.1.3.2 Caminhada Assistida
Em seguida, foi feito um passeio com o usuario na qual um dos integrantes do grupo
faria comentarios sobre o ambiente e demonstraria como isso se reflete na vibracao dos
motores. A importancia desta etapa e, alem de criar uma intuicao sobre o funcionamento
do equipamento, validar se os sinais vibratorios estao vibrando em concordancia com o
ambiente. Foram testadas sete situacoes. A resposta esperada para vibracao dos motores
em cada uma destas situacoes estao indicadas abaixo na forma de uma visao top down.
Note que a ativacao do motor implica uma cor azul.
56
Tabela 5.2: Tabela com resultados da caminhada assistida
Fonte: Autores
5.1.3.3 Caminhada Desacompanhada
Terminada a caminhada assistida, seria pedido ao usuario que fizesse o caminho de
volta ate a sala inicial utilizando apenas o sistema. Por motivos de seguranca, um dos
integrantes sempre esteve acompanhando de perto, mas sem fazer comentarios. Apesar
desta etapa ser altamente enviesada como teste, pois os voluntarios ja conheciam o am-
biente, serve para terem uma intuicao sobre a capacidade do sistema de trazer melhores
nocoes de espaco.
57
Figura 5.1: Foto com caminhada desacompanhada
Fonte: Autores
5.1.3.4 Entrevistas
Ao fim da caminhada com os voluntarios, pediu-se que fosse feito um depoimento sobre
o sistema. As entrevistas foram gravadas com permissao dos voluntarios e consistiam
em perguntas abertas sobre o potencial do projeto ajudar de fato, questoes de design e
implementacao e sugestoes de melhoria
58
5.2 Resultados
5.2.1 Testes Individuais dos Motores
Na etapa inicial em que os motores foram testados, pediu-se que cada voluntario
apontasse qual dos motores esta vibrando. Na grande maioria das vezes a identificacao
era feita rapidamente e com assertividade. A matriz abaixo indica quais motores foram
identificados corretamente pelos voluntarios e quais motores foram identificados mas que,
de acordo com estes, o sinal nao estava tao claro. Note que em todos os casos, os motores
foram identificados corretamente. Note tambem que os motores localizados na porcao
superior esquerda e centro esquerda devem ter sua instalacao revisadas no bracelete.
Tabela 5.3: Tabela com resultados dos testes individuais dos motores
Fonte: Autores
5.2.2 Caminhada Assistida
Com base nas situacoes descritas, bem como respostas esperadas, perguntou-se aos
usuarios que tipo de vibracoes estavam sentindo no bracelete. Caso corresponderem ao
esperado, definia-se o experimento como sucesso. A matriz abaixo indica quais obstaculos
foram ou nao identificados com sucesso.
59
Tabela 5.4: Tabela com resultados da caminhada assistida
Fonte: Autores
5.2.3 Entrevistas
Os quatro voluntarios relataram que sentiram-se mais seguros com o sistema ativo,
devido a um ganho de informacao, mas tambem relataram que o sistema teria de ser utili-
zado juntamente com a bengala. Durante os depoimentos foram feitas diversas sugestoes,
voltadas sobretudo sobre o design geral do projeto, que estao sintetizadas nos topicos
abaixo:
1. Vibracoes intermitentes para proximidade
Foi sugerida a possibilidade de implementar a sinalizacao de proximidade atraves
de pulsos de vibracao em vez da intensidade de vibracao. Foi uma possibilidade nao
pensada pelo grupo, mas que poderia trazer maior clareza quanto a proximidade de
obstaculos.
2. Separacao em dois braceletes
A nocao de lateralidade nao e tao obvia para alguns deficientes visuais. Tendo isso
em mente, faz sentido uma implementacao com dois braceletes para evidenciar ainda
mais quando o obstaculo esta vindo a direita (Vibracao apenas no bracelete direito)
ou a esquerda (Vibracao apenas no bracelete esquerdo)
3. Encapsulamento do Sistema num Oculos
Foi questionada a possibilidade de implementar todo o sistema num oculos, junto
com os braceletes, tendo em vista que estes sao amplamente utilizados por deficientes
visuais. No entanto, existem grandes limitacoes tecnologicas nesse sentido sobretudo
quanto ao tamanho da bateria e da camera 3D.
60
4. Necessidade do Sistema ser a Prova d’Agua
Este foi um ponto mencionado bastante e que faz muito sentido, dado que o sistema
e feito para ambientes outdoor, que e exposto a chuva e umidade. A implementacao
deste novo requisito exigiria uma protecao maior do modulo computacional, bem
como uma protecao maior dos fios que deveriam ser menos expostos.
5. Chave de Ligar/Desligar
Embora seja um ponto simples, e necessario um botao para ativar ou desativar os
sinais vibratorios. Esta e uma questao de design e experiencia de usuario relevante
para situacoes em que sinais do sistema podem ser incomodos ou nao trazer muita
informacao (Por exemplo, em locais muito movimentados e que geram muitos falsos
positivos).
6. Aspecto Estetico
E importante tambem que o sistema seja esteticamente atraente e que apresente o
mınimo de fios aparentes. Embora o sistema, no momento do teste, ainda fosse um
prototipo, sempre houve uma preocupacao nesse sentido. No entanto, melhorias sao
necessarias. positivos).
61
6 CONCLUSAO
6.1 Sobre o Projeto
O projeto atingiu os objetivos propostos, no sentido em que utiliza uma camera 3D
para identificar obstaculos e gerar sinais vibratorios para uma matriz de nove motores,
conforme testes realizados. No entanto, existem pontos a melhorar com obstaculos como
grades e rampas, que apresentaram resultados mistos durante os testes. Acredita-se que
existe um potencial real de auxiliar os deficientes na questao da mobilidade pelo diferencial
de utilizar varios motores para transmitir uma gama de informacoes, sem utilizar maos
ou fones de ouvidos, fazendo-o compatıvel com outros dispositivos assistivos. No mınimo,
seria uma informacao a mais para o deficiente se localizar.
Outro ponto a ser mencionado e a interdisciplinaridade deste projeto. Este projeto,
desenvolvido como um trabalho de conclusao de curso de engenharia, contou com o auxılio
de Santiago Villalobos, aluno de Arquitetura, que trouxe grandes insights e auxılios du-
rante a realizacao do projeto. Santiago foi quem sugeriu o design da disposicao dos motores
para a transmissao de informacoes espaciais de altura, distancia e posicao relativa, alem
de ter nos auxiliado bastante na prototipacao.
Os proximos passos incluem o refinamento do codigo fonte para identificar obstaculos
como rampas e obstaculos nao macicos como grades e gerar novas iteracoes de design,
como testar um modelo com dois braceletes, testar novas resolucoes da matriz tatil, que
poderia ter mais motores e um modelo de vibracao intermitente.
Para que o projeto se torne um produto de fato, ainda e necessario a reducao dos
custos do projeto, bem como melhorias no design do projeto no sentido de torna-lo mais
portatil e discreto.
62
6.2 Sobre o Curso
Este projeto encerra as atividades do curso de engenharia dos tres integrantes. O
curso de engenharia eletrica com enfase em computacao apresentou uma base teorica em
topicos essenciais como sistemas operacionais, bancos de dados, redes de computadores,
engenharia de software e arquitetura de computadores. Acredita-se que existem topicos
como gerencia de software e tecnicas de gerenciamento de projetos que deveriam ser
abordados para todos os alunos do curso.
Como integrantes da primeira turma da nova estrutura curricular (EC- 3), pode-
se dizer que a introducao do sistema de modulos vermelhos trouxe vantagens para o
aluno no sentido de direcionar seus interesses e tambem para tornar o currıculo de um
aluno formado neste curso um pouco mais diverso. Uma iniciativa muito bem vista foi a
introducao do curso de inteligencia artificial, cada vez mais importante no atual contexto,
como uma disciplina obrigatoria, indicando uma modernizacao do curso.
Por fim, acredita-se que o engenheiro formado na escola ainda se mantem competitivo
no mercado de trabalho tanto por seus conhecimentos tecnicos quanto habilidades pessoais
desenvolvidas ao longo destes cinco anos.
63
REFERENCIAS
1 VISION impairment and blindness. World Health Organization. [Online; acessadoem 14-Maio-2018]. Disponıvel em: 〈http://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment〉.
2 OKAYASU, M. Newly developed walking apparatus for identification of obstructionsby visually impaired people. Journal of Mechanical Science and Technology, Springer,v. 24, n. 6, p. 1261–1264, 2010.
3 BERNABEI, D. et al. A low-cost time-critical obstacle avoidance system for thevisually impaired. In: International conference on indoor positioning and indoornavigation. [S.l.: s.n.], 2011. p. 21–23.
4 THE Miniguide mobility aid. [S.l.]: Prentice hall Upper Saddle River, NJ, 2002.
5 SHOVAL, S.; BORENSTEIN, J.; KOREN, Y. The navbelt-a computerized travel aidfor the blind based on mobile robotics technology. IEEE Transactions on BiomedicalEngineering, IEEE, v. 45, n. 11, p. 1376–1386, 1998.
6 ZOLLNER, M. et al. Navi–a proof-of-concept of a mobile navigational aid forvisually impaired based on the microsoft kinect. In: SPRINGER. IFIP Conference onHuman-Computer Interaction. [S.l.], 2011. p. 584–587.
7 CLARK-CARTER, D. Factors affecting blind mobility. Tese (Doutorado) —University of Nottingham, 1985.
8 GONZALEZ, R. C.; WOODS, R. E. et al. Digital image processing. [S.l.]: Prenticehall Upper Saddle River, NJ, 2002.
9 FILHO, O. M.; NETO, H. V. Processamento digital de imagens. [S.l.]: Brasport, 1999.
10 GUNJI, T. et al. Plataforma multiware: suporte a objetos em tempo de execucao.[sn], 1995.
11 HARTLEY, R.; ZISSERMAN, A. Multiple view geometry in computer vision. [S.l.]:Cambridge university press, 2003.
12 FISCHLER, M. A.; BOLLES, R. C. Random sample consensus: a paradigmfor model fitting with applications to image analysis and automated cartography.Communications of the ACM, ACM, v. 24, n. 6, p. 381–395, 1981.
13 Wikipedia contributors. Random sample consensus — Wikipedia, The FreeEncyclopedia. 2018. [Online; acessado em 22-Julho-2018]. Disponıvel em: 〈https://en.wikipedia.org/wiki/Random\ sample\ consensus〉.
14 WRIGHT, R. S.; SWEET, M. OpenGL SuperBible with Cdrom. [S.l.]: Sams, 1999.
64
15 RUSU, R. B.; COUSINS, S. 3d is here: Point cloud library (pcl). In: IEEE. Roboticsand automation (ICRA), 2011 IEEE International Conference on. [S.l.], 2011. p. 1–4.
16 PCL. [Online; acessado em 25-Julho-2018]. Disponıvel em: 〈http://pointclouds.org/about/〉.
17 OPENKINECT. OpenKinect/libfreenect. 2018. [Online; acessado em 15-Agosto-2018].Disponıvel em: 〈https://github.com/OpenKinect/libfreenect〉.
18 INTELREALSENSE. IntelRealSense/librealsense. 2018. [Online; acessado em21-Outubro-2018]. Disponıvel em: 〈https://github.com/IntelRealSense/librealsense〉.
19 VERMESAN, O. et al. Internet of things strategic research roadmap. Internetof Things-Global Technological and Societal Trends, Rivers Publishers Aalborg, v. 1,n. 2011, p. 9–52, 2011.
20 DR.R, P.; VELUMANI, B. The internet of things (iot) applications andcommunication enabling technology standards: An overview. In: . [S.l.: s.n.], 2014. p.324–329.
21 CONDE, A. Definindo a cegueira e a visao subnormal. [Online; acessado em22-Agosto-2018]. Disponıvel em: 〈http://www.ibc.gov.br/index.php?query=cegueira&Buscar=Buscar&amount〉.
22 RASPBERRYPI. Raspberry Pi 3 Model B. 2018. [Online; acessado em 05-Agosto-2018]. Disponıvel em: 〈https://www.raspberrypi.org/products/raspberry-pi-3-model-b/〉.
23 MPU-6050 Accelerometer + Gyro. [Online; acessado em 25-Outubro-2018].Disponıvel em: 〈https://playground.arduino.cc/Main/MPU-6050〉.
24 MOTOR VibraCall. [Online; acessado em 25-Julho-2018]. Disponıvel em: 〈https://produto.mercadolivre.com.br/MLB-734641592-micro-vibrador-motor-3v-automaco-arduino-vibracall-\ JM?quantity=1〉.
25 10000MAH Mi Power Bank 2. [Online; acessado em 27-Novembro-2018]. Disponıvelem: 〈https://www.mi.com/sg/battery2/〉.
26 RASPBERRY Pi 2 3 Pin Mappings. [Online; acessado em 6-Outubro-2018]. Disponıvel em: 〈https://docs.microsoft.com/en-us/windows/iot-core/learn-about-hardware/pinmappings/pinmappingsrpi\#gpio-pins〉.