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〉.