Sistema de visão para detecção de segmentos de planos aplicados em órtese ativa

(1)

UNIVERSIDADEFEDERALDO RIO GRANDE DO NORTE

UNIVERSIDADEFEDERAL DORIOGRANDE DO NORTE

CENTRO DETECNOLOGIA

PROGRAMA DEPÓS-GRADUAÇÃO EMENGENHARIA

MECATRÔNICA

Sistema de Visão para Detecção de Segmentos

de Planos Aplicado em Órtese Ativa

Daniel Henrique Silva Fernandes

Orientador: Prof. Dr. Pablo Javier Alsina

Documento de Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia Mecatrônica da UFRN (área de concentração: Sistemas Mecatrônicos) como parte dos requisitos para obtenção do título de Mestre em Engenharia Mecatrô-nica.

Número de ordem PEM: M021

Natal, RN, 7 de Janeiro de 2020

(2)

Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede

Fernandes, Daniel Henrique Silva.

Sistema de visão para detecção de segmentos de planos aplicados em órtese ativa / Daniel Henrique Silva Fernandes. - 2020.

57 f.: il.

Orientador: Pablo Javier Alsina

Mestrado (dissertação) - Universidade Federal do Rio Grande do Norte, Cen-tro de Tecnologia, Programa de Pós-Graduação em Engenharia Mecatrônica, Na-tal, RN, 2020.

Orientador: Prof. Dr. Pablo Javier Alsina.

1. Visão Computacional - Dissertação. 2. Tecnologia Assistiva - Dissertação. 3. Exoesqueleto Ortopédico - Dissertação. 4. Detecção de planos - Dissertação. I. Alsina, Pablo Javier. II. Título.

(3)

Sistema de Visão para Detecção de Planos para

uma Órtese Ativa

Daniel Henrique Silva Fernandes

Dissertação de Mestrado aprovada em 27 de Novembro de 2019 pela banca examinadora composta pelos seguintes membros:

Prof. Dr. Pablo Javier Alsina (orientador) . . . DCA/UFRN

Prof. Dr. Adelardo Adelino Dantas de Medeiros . . . DCA/UFRN

Prof. Dr. Agostinho de Medeiros Brito Junior . . . DCA/UFRN

(4)

(5)

Aos meus pais, Nadilma Silva e

Juarez Fernandes de Oliveira Junior,

por terem me permitido trilhar meu

próprio caminho na vida.

(6)

(7)

Agradecimentos

Ao meu orientador Prof. Dr. Pablo Javier Alsina

Aos meus colegas do laboratório, em especial à Diego da Silva Pereira, Luis Bruno do Nascimento e Vitor Gaboardi dos Santos

Aos professores que me ensinaram sobre Processamento Digital de Imagens e Visão Com-putacional: Prof. Dr. Agostinho Brito Junior, Prof. Dr. Bruno Motta, Prof. Dr. Rafael Beserra

À minha família pelo apoio durante esta jornada. À CAPES, pelo apoio financeiro.

(8)

(9)

Resumo

Neste trabalho, é proposto, a criação de um sistema de visão computacional para uma órtese ativa com intuito de garantir mais autonomia nos movimentos para seus usuários. Atualmente, no mercado, as principais órteses ativas comercializadas não dispõem de meios para compreender o ambiente ao seu redor, o que impossibilita a órtese de se localizar no ambiente e prever ações dos seus usuários, por exemplo. Nesse contexto, apresenta-se uma estratégia que, através de uma câmera RGB-D, permite obter a nuvem de pontos do cenário para detectar as regiões planares do ambiente. Partindo do principio que, em ambientes urbanos, a grande maioria dos locais de caminhada apresentam regiões planas, podemos classificar regiões transponíveis para a órtese com base no conjunto de pontos que podem ser classificados como o piso, por exemplo. Para que seja possível exe-cutar a detecção e classificação de planos de forma rápida, é necessário que haja uma série de transformações e filtragens com intuito de diminuir a quantidade de dados para proces-samento. Os experimentos tanto em ambiente de simulação quanto práticos detectaram os planos de interesse e, apesar das transformações e filtragens realizadas para garantir maior velocidade de processamento, a forma do plano manteve-se próxima a original. Contudo, o custo computacional para os testes realizados no computador embarcado, demonstram ainda um gargalo que deve ser superado.

Palavras-chave: Visão Computacional, Tecnologia Assistiva, Exoesqueleto Ortopé-dico, Detecção de planos.

(10)

(11)

Abstract

In this work, it is proposed the creation of a computer vision system for an active orthosis in order to guarantee more autonomy movements for its users. Currently, in the market, the main commercialized active orthoses don’t have the means to understand the environment around them, which makes impossible for the orthosis to locate itself in his environment and to predict the user’s actions, for example. In this context, we present a strategy that, using a RGB-D camera, allows to obtain the point cloud of the scenario in order to detect the planar regions of the environment. Assuming that, in urban environments, the vast majority of walking places have plane regions, we can classify transposable regions for the orthosis based on the set of points that can be classified as the floor, for example. In order to be able to quickly detect and classify plans, a series of transformations and filtering is required to reduce the amount of data for processing. Experiments in simulation and practical environments detected the planes of interest and, despite the transformations and filtering performed to ensure faster processing, the shape of the plane remained close to the original one. However, the computational cost for the tested on the embedded computer still demonstrates a bottleneck that must be overcome.

Keywords: Computer Vision, Assistive Technology, Orthopedic Exoskeleton, Plane Detection.

(12)

(13)

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas v

Lista de Símbolos e Abreviaturas vii

1 Introdução 1 1.1 Trabalhos Relacionados . . . 7 1.2 Objetivo . . . 9 1.2.1 Objetivos Específicos . . . 9 1.3 Organização do Trabalho . . . 9 2 Câmeras RGB-D 11 2.1 Câmeras RGB-D . . . 11 2.2 Kinect Sensor v1 . . . 12 2.2.1 Hardware . . . 13 2.2.2 Medição de Distância . . . 14 2.2.3 Software . . . 14

3 Processamento em Nuvem de Pontos 17 3.1 Nuvem de Pontos a Partir de um Mapa de Profundidade . . . 17

3.2 Biblioteca Point Cloud Library (PCL) . . . 18

3.3 Transformações Geométricas em Nuvem de Pontos . . . 19 i

(14)

3.4 Filtros em Nuvem de Pontos . . . 20

3.4.1 Filtro de Distância . . . 20

3.4.2 Filtragem de Pontos Usando Voxel Grids . . . 21

3.5 Definição de Planos . . . 22

3.6 Detecção de Planos Usando o Método de RANSAC . . . 24

4 Modelagem e Implementação 27 4.1 Velocidade Média do ser Humano . . . 27

4.2 Modelagem Geométrica do Problema . . . 28

4.2.1 Principais Eixos do ser Humano . . . 28

4.2.2 Posição e Orientação Iniciais da Câmera . . . 29

4.3 Uso de um Sensor de Medidas Inerciais . . . 30

4.4 Processamento . . . 32

4.5 Implementação . . . 33

4.6 Sistema Robótico Operacional (ROS) . . . 33

5 Resultados 37 5.1 Resultados em Ambiente de Simulação . . . 37

5.1.1 Critérios Usados no Ambiente de Simulação . . . 38

5.2 Resultados em Cenário Real . . . 42

5.2.1 Captura da Nuvem de pontos com a Câmera Fixa . . . 42

5.2.2 Captura da Nuvem de pontos com a Câmera em movimento . . . 44

5.3 Validação do método através da gravação de dados . . . 47

5.3.1 Frequência de Detecção de Planos . . . 48

6 Conclusões e Trabalhos Futuros 51

(15)

Lista de Figuras

1.1 Órtese Ortholeg . . . 3

1.2 Modelo CAD da versão Ortholeg 2.0 . . . 4

1.3 Visualização em duas dimensões dos obstáculos . . . 5

1.4 Modelo CAD com inserção do sistema de percepção sensorial . . . 7

1.5 Uso de um sensor RGB-D para detecção de escadas . . . 8

2.1 Modelo do Sensor Kinect . . . 13

2.2 Campo de Visão do Sensor Kinect . . . 13

2.3 Emissão de Feixes de Luz Infravermelha . . . 14

3.1 Nuvem de Pontos tomada como referência . . . 19

3.2 Nuvem de Pontos tomada como referência (a) e com a remoção de dis-tâncias maiores que 2,5 metros (b) . . . 21

3.3 Nuvem de Pontos tomada como referência (a) e com a aplicação do filtro de Voxel Grid . . . 22

4.1 Eixos e Planos Principais do Corpo Humano . . . 29

4.2 Angulo Mínimo de Orientação da Câmera . . . 30

4.3 Sistema de Coordenas do Sensor Kinect . . . 30

4.4 Sensor de Unidade de Medidas Inerciais BNO055 . . . 31

4.5 Kinect Interligado com o Sensor UMI . . . 31

4.6 Modelo para captura da orientação do UMI . . . 32

4.7 Layout de Conexões Implementado . . . 33

4.8 Diagrama de Blocos a ser Executado no Computador Raspberry PI . . . . 34 iii

(16)

5.1 Cenários em Ambiente Simulado de um Obstáculo Simples (a), de uma escada (b) e suas respectivas nuvens de pontos (c,d) . . . 38 5.2 Nuvem de Pontos após Passar por Processos de Transformação

Geomé-trica e Filtragens . . . 41 5.3 Cenários capturados para validação do método: Piso livre de obstáculos

(a) Rampa (b), Degrau de Escadas (c) e Descida de Escadas (d) . . . 43 5.4 Nuvem de Pontos filtradas para validação do método: Piso livre de

obs-táculos (a) presença de rampa (b), escada ascendente (c) e escada descen-dente (d) . . . 46 5.5 Ponto inicial (a) e final (b) da simulação de caminhada . . . 47

(17)

Lista de Tabelas

5.1 Resultados das Técnicas de Transformações e Filtragens em Ambiente de Simulação . . . 39 5.2 Comparação entre os Valores Obtidos com e sem o uso de Filtros para a

Nuvem de Pontos: Obstáculo . . . 40 5.3 Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo

da distancia entre o componente d : Obstáculo . . . 40 5.4 Comparação entre os Valores Obtidos com e sem o uso de Filtros para a

Nuvem de Pontos: Escada . . . 41 5.5 Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo

da distancia entre o componente d : Escada . . . 41 5.6 Redução do Número de Pontos após os Processos de Filtragem . . . 44 5.7 Comparação entre os Valores Obtidos com e sem o uso de Filtros para a

Nuvem de Pontos: Piso LARS . . . 44 5.8 Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo

da distância entre o componente d: Piso LARS . . . 44 5.9 Comparação entre as Equações Obtidas com e sem o uso de Filtros para

a Nuvem de Pontos: Rampa . . . 44 5.10 Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo

da distancia entre o componente d: Rampa . . . 45 5.11 Comparação entre as Equações Obtidas com e sem o uso de Filtros para

a Nuvem de Pontos: Escada Ascendente . . . 45 v

(18)

5.12 Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo

da distancia entre o componente d: Escada Ascendente . . . 45

5.13 Comparação entre as Equações Obtidas com e sem o uso de Filtros para a Nuvem de Pontos: Escada Descendente . . . 45

5.14 Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo da distancia entre o componente d: Escada Descendente . . . 46

5.15 Número de Mensagens registradas em diferentes cenários . . . 47

5.16 Número de Mensagens Processadas . . . 48

(19)

Lista de Símbolos e Abreviaturas

DCA Departamento de Engenharia de Computação IBGE Instituto Brasileiro de Geografia e Estatística LARS Laboratório de Robótica e Sistemas Dedicados

nPITI Núcleo de Pesquisa e Inovação em Tecnologia da Informação OpenNI Open Natural Inteface

PCL Point Cloud Library

RANSAC Random Sample Consesus ROS Robot Operating System

SAL Sistema de Apoio a Locomoção

SLAM Simultaneos Localization and Mapping SSH Secure Shell

TA Tecnologias Assistivas

UFRN Universidade Federal do Rio Grande do Norte UMI Unidade de Medida Inercial

V-REP Virtual Robot Experimentation Platform

(20)

(21)

Capítulo 1

Introdução

Para a maioria da população, realizar uma caminhada tanto dentro de residências quanto em centros urbanos é uma prática simples. Tarefas como subir escadas, lidar com rampas, desviar de obstáculos ou ultrapassar buracos são procedimentos habituais. Entretanto, antes de executar tais ações, é necessário conhecer o ambiente em que se está inserido. O ser humano, para planejar seus movimentos, utiliza principalmente o sen-tido da visão para interpretar ambiente ao seu redor e detectar, por exemplo, obstáculos e regiões transponíveis para caminhada. A visão humana, fruto de um processo evolutivo de milhões de anos, exerce um papel fundamental para que o ser humano interaja com o ambiente e possa, dentre outras coisas, caminhar com facilidade.

No Brasil, segundo dados do Instituto Brasileiro de Geografia e Estatística (IBGE), cerca de 13,6 milhões de brasileiros possuem deficiência motora permanente, definida como a dificuldade do indivíduo de caminhar ou de subir escadas (Censo Demográfico 2010). Desse total, cerca de 4,4 milhões estão impossibilitados ou com grande dificuldade de realizar tais ações, o que implica na necessidade do uso de equipamentos para auxiliar na execução dessas atividades, classificados como Tecnologias Assistivas (TA).

Nos últimos anos, um ramo da Tecnologia Assistiva vem se expandindo gradativa-mente, impulsionado com os avanços na área de micro e nanotecnologia, de baterias leves e de alta capacidade, de processadores menores, mais rápidos e de baixo consumo: a robótica assistiva (Bien e Stefanov 2004). Quando tratada sobre a ótica de deficiência

(22)

2 CAPÍTULO 1. INTRODUÇÃO

motora, a robótica assistiva visa melhorar a qualidade de vida de pessoas por meio de sistemas autônomos de locomoção (Romero et al. 2014).

Nesse contexto, pesquisas envolvendo órteses ativas ganham mais visibilidade. Uma órtese ativa, ou Órtese Robótica, é definida como uma estrutura mecânica que reproduz algumas funções desempenhadas por membros do corpo humano com o propósito de res-taurar perdas de movimento (Araújo et al. 2015). Consequentemente, órteses ativas para membros inferiores procuram recompor os movimentos relativos à caminhada humana, o que torna o problema não trivial, visto que o movimento de caminhada é exercido por mais de 600 músculos e articulações no corpo humano (Carpentier et al. 2017).

O projeto Ortholeg é um dos exemplos de órtese ativa existentes. Desenvolvida pelo Laboratório de Robótica e Sistemas Dedicados (LARS) do Departamento de Engenharia de Computação e Automação (DCA) da Universidade Federal do Rio Grande do Norte (UFRN), a órtese Ortholeg é um protótipo de órtese ativa para membros inferiores baseado em um exoesqueleto mecânico com quatro graus de liberdade, projetada para usuários pesando entre 50 e 60 quilogramas com uma altura entre 1,55 a 1,65 metros. A órtese Ortholeg foi desenvolvida como um dispositivo de assistência à marcha humana de baixo custo que procura prover os movimentos básicos que ocorrem no caminhar humano. O dispositivo pesa aproximadamente 20 quilogramas e possui quatro atuadores, dois em cada perna, localizados nas articulações do quadril e dos joelhos com intuito de prover movimentos no plano sagital. A Figura 1.1 ilustra o modelo da órtese Ortholeg.

A órtese Ortholeg foi projetada ainda sobre o conceito de transparência. Esse conceito pode ser definido como a capacidade do dispositivo de tornar a experiência de caminhada o mais natural possível, tanto para o usuário quanto para as pessoas ao seu redor. Desta forma, transparência envolve vários aspectos, tais como: projeto mecânico leve e dis-creto; design ergonômico, tal que a órtese ativa não seja desconfortável e seja fácil e rápida de usar; eficiência energética, evitando uma recarga frequente das baterias; sín-tese de movimentos antropomórficos personalizados, que consideram a estrutura física do

(23)

3

Figura 1.1: Órtese Ortholeg

Fonte: Adaptado de (Araújo 2015)

usuário, como peso e altura, para diminuir o tempo de adaptação para uso do aparelho e realizar movimentos naturais; planejamento autônomo de movimentos, de modo que os movimentos são adaptados automaticamente de acordo com o terreno onde o usuário está localizado, diminuindo a frequência com que o usuário intervenha no dispositivo (Santos et al. 2019).

Atualmente, a Ortholeg está em fase de desenvolvimento da sua versão 2.0, tornando-se mais leve, com utilização de materiais mais modernos. O novo design, com uso de tubos e braçadeiras, torna-o também mais compacto, modular e garante melhor ajuste para usuários de proporções corporais variáveis (Melo et al. 2017). A Figura 1.2 ilustra o modelo CAD da nova versão do protótipo Ortholeg.

Com relação a transparência, o planejamento autônomo de movimentos faz parte de um conjunto de etapas tratados no conceito de navegação autônoma. O estudo sobre navegação pode ser subdividido em etapas hierarquizadas que devem ser seguidas e exe-cutadas: Mapeamento de Ambientes, Localização, Planejamento de Caminho, Geração de Trajetória e Execução de Trajetória. Souza (2012) define cada etapa como:

• Mapeamento de Ambientes - percepção e construção de um modelo do ambiente a partir de informações sensoriais

(24)

Figura 1.2: Modelo CAD da versão Ortholeg 2.0

Adaptado de (Melo et al. 2017)

• Localização - baseando-se no modelo obtido na etapa anterior juntamente com in-formações sensoriais extras, é deduzida a pose do robô dentro do ambiente;

• Planejamento de Caminho - o robô calcula um caminho partindo de sua configura-ção inicial até a configuraconfigura-ção final desejada, evitando obstáculos;

• Geração de Trajetória - o caminho gerado é adaptado às restrições temporais e então é calculada a velocidade com que se deseja movimentar;

• Execução da Trajetória - os atuadores são controlados de forma a executarem a trajetória gerada o mais fielmente possível.

No nível de mapeamento de ambientes, o robô deve coletar dados do seu entorno, utilizando sensores, visando gerar modelos computacionais com as principais caracterís-ticas estruturais do ambiente. Para isso, é necessário que os robôs sejam equipados com dispositivos de percepção capazes de fornecer algum tipo de informação de seu entorno, de modo que, a partir de algum processamento, essas informações sejam empregadas na construção de um mapa do ambiente. Além disso, para que um sistema robótico possa

(25)

5

construir um mapa consistente, é necessário determinar sua pose (posição e orientação) com relação a algum referencial fixo no mundo. Esse processo de obtenção de dados sen-soriais, seu subsequente processamento mais a inferência da pose do robô, tendo como objetivo a construção de um mapa do espaço no qual o robô está inserido, é chamado de mapeamento robótico (Souza 2012).

Para ilustrar a importância do mapeamento robótico para a órtese, observe a Figura 1.3, que mostra o problema a tratado. Dado que a órtese esteja localizada na posição inicial, é necessário que a mesma ultrapasse o buraco, a rampa e as escadas para conseguir chegar a posição final. Com isso, através do sistema de visão computacional, o objetivo deve ser obter as informações do ambiente com intenção de prever as ações de controle a serem tomadas a medida que os empecilhos no caminho se aproximam e são ultrapassados.

Figura 1.3: Visualização em duas dimensões dos obstáculos

Fonte: Adaptado de Araújo (2015)

Desde o início, o projeto Ortholeg já previa a inclusão de um sistema de percepção sensorial do ambiente. Esse sistema de percepção serviria, dentre outras funções, como entrada para o Sistema de Auxílio à Locomoção (SAL) da órtese, responsável pelo plane-jamento de passos com base nas informações do ambiente e em dados antropométricos e temporoespaciais fornecidos pelo usuário (Araújo 2015).

Para que o SAL consiga realizar o planejamento de passos de forma adequada, faz-se necessário que o sistema de percepção faz-sensorial do ambiente faz-seja capaz de fornecer informações em três dimensões de onde esteja inserido. Uma possível maneira de obter profundidade é através do uso câmeras estéreo, que consistem em duas ou mais câmeras

(26)

apontadas para o mesmo cenário com uma distância entre elas. Explicando de maneira sucinta, a diferença entre as imagens fornecidas das câmeras permite calcular, por meio de triangulação, o mapa de profundidade do cenário. No entanto, essa correspondência estéreo é um processo computacionalmente dispendioso e pode falhar em áreas de baixa textura. Outra abordagem baseia-se no uso de sensores LIDAR, mas que também deman-dam muito esforço computacional e são equipamentos que possuem normalmente um alto custo de aquisição. Outra alternativa válida está no uso de câmeras do tipo RGB-D que permitem a obtenção direta de uma representação do ambiente em três dimensões, chamada comumente de nuvem de pontos. Seu baixo custo, aliado a um menor esforço computacional de obtenção de dados, possibilitou que esse tipo de tecnologia fosse em-pregado em diversas áreas e será o foco desse trabalho.

Partindo desse principio, neste trabalho, uma câmera RGB-D foi escolhida como o sensor para executar a percepção sensorial do ambiente. Porém, como será visto poste-riormente, esse tipo de sensor muitas vezes fornece uma quantidade de dados que para aplicação ser executada no menor tempo possível, demanda-se o uso de filtros que man-tenham apenas a informação essencial. Outro ponto é que, como o intuito inicial é de utilizar órteses em ambientes urbanos, podemos tomar como base que o solo, na maior parte das caminhadas feitas nesse tipo de ambiente, possui uma forma plana. Com isso, é possível definir regiões transponíveis por meio de uma classificação do campo de visão em regiões planares, onde o piso pode ser classificado como um ambiente livre de obs-táculos. Ademais, formas comuns em centros urbanos, como escadas e rampas também podem ser classificadas, permitindo que se agrupe uma determinada região do ambiente como uma forma conhecida. Além disso, é possível ainda receber a nuvem de pontos e transformá-la de modo a facilitar estrategias de planejamento de caminhos, como, por exemplo, com o uso de grades de ocupação. Para se trabalhar com sistemas autônomos que trabalham com caminhada, entretanto, é necessário que se crie um representação em grade de ocupação do tipo 2.5D (Fankhauser et al. 2014).

(27)

1.1. TRABALHOS RELACIONADOS 7

Dado todos esses fatos, o novo modelo da Ortholeg 2.0, além de receber os aprimo-ramentos de design, teria como acréscimo a inserção do sistema de percepção sensorial baseado em um sensor RGB-D. A Figura 1.4 ilustra o modelo da Ortholeg 2.0 com uma câmera acoplada para captura do ambiente.

Figura 1.4: Modelo CAD com inserção do sistema de percepção sensorial

Adaptado de (Melo et al. 2017)

1.1 Trabalhos Relacionados

Classificar regiões transponíveis em nuvem de pontos possui diversas aplicações. Em seu trabalho, Talhada (2012) classificou como região navegável para um carro autônomo um conjunto de pontos no plano que foram classificados como estradas, tomando como base de antemão, que as ruas em centros urbanos possuem um forma constante, com poucas variações.

Na área de tecnologia assistiva, um trabalho bastante próximo ao proposto foi reali-zado por Zhao et al. (2018), que utilizou uma câmera RGB-D do tipo Kinect sensor v2 com intuito de detectar escadas para pessoas que utilizavam exoesqueletos nos membros inferiores. Em seu trabalho, Zhao et al. (2018) posicionou a câmera de modo a observar o

(28)

piso logo à frente do usuário utilizando o exoesqueleto, conforme mostra a Figura 1.5, e através de técnicas de semântica aplicadas em imagens e para detectar regiões planas em nuvem de pontos, pôde realizar detecção de escadas no ambiente.

Figura 1.5: Uso de um sensor RGB-D para detecção de escadas

Fonte: Adaptado de Zhao et al. (2018)

Com a criação de uma bengala inteligente, que possuía uma câmera RGB-D, Qian e Ye (2013) aplicaram a detecção de planos para auxiliar a pessoas com deficiência visual a caminharem em ambientes internos usando uma câmera RGB-D.

Com isso, trabalhar com nuvens de pontos para determinar regiões navegáveis é uma estratégia bastante utilizada pois discretiza o ambiente em três dimensões, simplificando o problema a ser tratado.

(29)

1.2. OBJETIVO 9

1.2 Objetivo

Esse trabalho propõe elaborar um sistema percepção sensorial com o uso de uma câ-mera RGB-D capaz de fornecer informações essenciais sobre o ambiente de trabalho para garantir um planejamento seguro de movimentos para uma órtese ativa, planejamento esse que já está sendo desenvolvido por trabalhos como (Nascimento et al. 2018). As infor-mações fornecidas pelo sistema de percepção devem passar por um processo de filtragem de dados e a sua saída consistirá da nuvem de pontos filtrada aliada a informações sobre os segmentos de planos no campo de visão do usuário, agrupando regiões que possuem as mesmas caraterísticas. Além disso, o sistema de percepção sensorial terá uma aborda-gem robocêntrica, onde a localização do robô será considerada como a oriaborda-gem em todo o experimento, logo tanto a parte de mapeamento quanto localização serão contempla-dos. O estudo de caso aplicado será realizado sob a perspectiva de se trabalhar na órtese Ortholeg.

1.2.1 Objetivos Específicos

A premissa inicial do sistema será de ser capaz de extrair informações essenciais do ambiente e de executar o processamento de forma rápida e com baixo custo computacio-nal, necessitando então de técnicas de transformações e filtros para diminuir a quantia de dados a serem processados.

1.3 Organização do Trabalho

Neste documento, os capítulos se dividem da seguinte forma:

• Capítulo 2: Aborda a tecnologia de câmeras RGB-D com ênfase no tipo de sensor que será usado nesse trabalho, o Kinect Sensor v1.

(30)

• Capítulo 3: Inicia com uma definição sobre o que é nuvem de pontos e como cria-lo a partir de um mapa de profundidade, citando em seguida as principais transforma-ções, técnicas e software que serão abordados.

• Capítulo 4: Mostra como foi feita a implementação física do trabalho, citando os matérias e ferramentas computacionais usadas.

• Capítulo 5: Apresenta os resultados que foram obtidos em ambiente de simulação e em ambiente real.

• Capítulo 6: Faz uma conclusão sobre o trabalho desenvolvido juntamente com algumas propostas para trabalhos futuros.

(31)

Capítulo 2

Câmeras RGB-D

Este capítulo introduz uma breve explicação sobre o conceito de câmeras RGB-D e, em seguida, dará ênfase ao modelo de sensor a ser usado em experimentos simulados e práticos, como suas características físicas, o método de aquisição do mapa de profundi-dade e o software que será utilizado para acessar as informações do sensor.

2.1 Câmeras RGB-D

Câmeras RGB-D podem ser definidas como um sistema de aquisição de imagens que fornece informações seguindo o padrão de sistema aditivo de representação de cores, o RGB (Red, Green e Blue), e para cada pixel associa um valor referente à distância do ponto nas coordenadas do mundo para o plano da imagem. Logo, na prática, é um sistema que além de fornecer três matrizes referentes às tonalidades vermelho, verde e azul, fornece mais uma matriz de profundidade discretizada. Esses tipos de sensores são largamente utilizados na área de visão computacional, em aplicações como detecção de obstáculos (Mojtahedzadeh 2011), mapeamento em tempo real (Endres et al. 2014), odometria visual (Kerl et al. 2013), dentre outras.

Há diversos modelos de câmera RGB-D disponíveis no mercado, cada um seguindo uma configuração particular quanto aos seus parâmetros intrínsecos, taxa de aquisição de informação, dentre outros. A versão que deu início à popularização desse tipo de

(32)

12 CAPÍTULO 2. CÂMERAS RGB-D

tecnologia definitivamente foi o modelo Kinect v1 da Microsoft Corporation. Contudo, novas marcas foram surgindo e ganhando tanto o mercado quanto a academia.

Existem três tipos de tecnologias principais usadas em câmeras RGB-D capazes de fornecer a profundidade do ambiente: Time of Flight (ToF), padrão infravermelho e visão estéreo ativa. Os sensores ToF transmitem pulsos de luz para medir o tempo necessário para os pulsos viajarem da fonte de luz para um objeto e de volta para o sensor. Essa duração determina a distância até o objeto. Sensores de padrão infravermelho projetam um padrão nas superfícies observadas e extraem a informação de profundidade usando o princípio da triangulação. Câmeras estéreo ativas combinam a ideia de um projetor ativo e um par passivo de câmera estéreo. Em contraste com as câmeras estéreo clássicas, as câmeras estéreo ativas também projetam sua própria textura. Assim, eles são capazes de coletar informações mesmo em superfícies de textura reduzida, (Halmetschlager-Funek et al. 2018).

Neste trabalho, o Kinect Sensor v1, da Microsoft Corporation, que usa um padrão de feixes de luz infravermelha, foi utilizado tanto em sua versão em ambiente de simulação quanto em ambientes reais.

2.2 Kinect Sensor v1

Lançado em novembro do ano de 2010, o Kinect Sensor v1 foi desenvolvido inicial-mente como uma plataforma com intuito de garantir interatividade para usuários do con-sole de games Xbox 360. Contudo, por possuir um sistema inovador de baixo custo capaz de processar uma profundidade, esse dispositivo foi amplamente utilizado em diversos tipos de pesquisas, com foco principal na área de visão computacional, (Han et al. 2013). A Figura 2.1 mostra o modelo do Kinect Sensor v1 que foi utilizado neste trabalho.

(33)

2.2. KINECT SENSOR V1 13

Figura 2.1: Modelo do Sensor Kinect

Fonte: Própria do autor (2019)

2.2.1 Hardware

O Kinect Sensor v1 é capaz de realizar a aquisição de imagens a uma taxa de 30 frames por segundo. O seu sistema de cores RGB utiliza uma representação de 8 bits a uma resolução de 640 x 480 pixels, enquanto seu sistema de detecção de distância fornece 11 bits de resolução, provendo então 2048 níveis de intensidade (do valor 0 a 2047). O Kinect Sensor v1ainda trabalha com uma distância mínima e máxima para calcular profundidade de 0,4 metros e 4 metros, respectivamente. Seu campo de visão é de 57°no eixo horizontal e 43°no eixo vertical, conforme mostra a Figura 2.2 .

Figura 2.2: Campo de Visão do Sensor Kinect

(34)

14 CAPÍTULO 2. CÂMERAS RGB-D

2.2.2 Medição de Distância

A forma de medição de distância do Kinect Sensor é baseado na tecnologia desen-volvida e patenteada pela empresa PrimeSense (Freedman et al. 2012). Contudo, inicial-mente, o desenvolvedor do produto não especificou detalhes quanto à forma de calcular profundidade, mas com técnicas de engenharia reversa foi possível entender o funciona-mento do mesmo (Mojtahedzadeh 2011). A câmera e o projetor infravermelho formam um par estéreo de visão, com uma distância entre eles de cerca de 7,5 centímetros. O projetor emite um padrão de feixes de luz infravermelha como mostrado na Figura 2.3.

Figura 2.3: Emissão de Feixes de Luz Infravermelha

Fonte: Adaptado de ROS.org (n.d.)

Logo após essa etapa, a câmera de infravermelho captura esse padrão, e, através de cálculos de triangulação, consegue determinar a distância de cada projeção para o sensor, fornecendo assim, o mapa de profundidade do cenário (Mojtahedzadeh 2011).

2.2.3 Software

Seguindo tendência da academia de se trabalhar com o Kinect, vários frameworks foram desenvolvidos com objetivo de facilitar a interação entre o Kinect Sensor e o

(35)

am-2.2. KINECT SENSOR V1 15

biente de desenvolvimento. Uma grande ferramenta nessa área foi desenvolvida pelo projeto Open Natural Interface (OpenNI). Desenvolvido em linguagem C++, o OpenNI fornece um framework capaz de interagir com todas as funcionalidades do Kinect. Apesar do projeto ter sido descontinuado em 2013, o OpenNI continua disponível para ser usado com as características de ser Open Source, ou seja, livre para distribuição e edição.

Além do drivers da OpenNI, existe também a biblioteca lib-freenect (Joseph e Cacace 2018), que, apesar de não possuir todos os recursos do OpenNI, como a capacidade de acionar o motor do Kinect quanto fazer o reconhecimento de pessoas, permitem obter a nuvem de pontos de maneira similar.

(36)

(37)

Capítulo 3

Processamento em Nuvem de Pontos

Este capítulo, inicialmente, trata da obtenção de uma nuvem de pontos a partir de um mapa de profundidade fornecido. Em seguida, serão abordadas as principais estratégias de transformações e filtragens em nuvem de pontos e, por fim, sobre a definição e detecção de planos.

3.1 Nuvem de Pontos a Partir de um Mapa de

Profundi-dade

Para se criar uma nuvem de pontos partindo de um mapa de profundidade, é neces-sário que se conheçam os parâmetros intrínsecos da câmera previamente. Parâmetros intrínsecos são o conjunto de parâmetros que descrevem as características ópticas da câ-mera. Essas características incluem principalmente informações como distância focal ( f ) e as coordenadas do centro óptico (cu,cv).

Com a disponibilidade de se obter um valor de profundidade zd atribuído a cada pixel

de uma determinada imagem I(u, v), é possível criar uma representação em três dimensões do campo de visão do sensor, onde as coordenadas da nuvem de pontos com relação à câmera Pc= [Xc,Yc, Zc] são dadas pelas equações 3.1, 3.2 e 3.3

X_c= (u − cu)

(38)

18 CAPÍTULO 3. PROCESSAMENTO EM NUVEM DE PONTOS

Y_c= (v − cv)

f × zd (3.2)

Zc= zd (3.3)

O algoritmo 1 ilustra como se obter a nuvem de pontos na imagem recebendo como entrada os parâmetros intrínsecos, a imagem RGB e o mapa de profundidade

Algoritmo 1: Profundidade Para Nuvem de Pontos

Entrada: I: imagem;D: Mapa de Profundidade; f : distância focal;cu, cv: centro

óptico da imagem; Saída: ptc: Nuvem de Pontos

1 Altura, Largura ← tamanho(I); 2 para (v = 0; v < Altura; v + +) faça 3 para (u = 0; u < Largura; u + +) faça 4 z← D(v, u); 5 x←(u−cu)_f × z; 6 y←(v−cv) f × z; 7 ptc(v, u, 0) ← x; 8 ptc(v, u, 1) ← y; 9 ptc(v, u, 2) ← z; 10 fim 11 fim 12 retorna ptc;

3.2 Biblioteca Point Cloud Library (PCL)

Criado com a demanda de se trabalhar com nuvem de pontos de forma mais acessível, quando, na época, apenas sistemas de alto custo estavam disponíveis, impossibilitando o trabalho em diversas aplicações principalmente na área da robótica, a Point Cloud Library (PCL) é uma biblioteca Open Source, escrita em linguagem C++, que contém o estado-da-arte de diversas técnicas comumente usadas ao se trabalhar com nuvem de pontos, tais como filtros, reconstrução de superfície, segmentação, percepção, dentre outros (Rusu e

(39)

3.3. TRANSFORMAÇÕES GEOMÉTRICAS EM NUVEM DE PONTOS 19

Cousins 2011). Além desses fatores, a biblioteca PCL ainda esta integrada com o fra-meworkROS, que será melhor abordado na seção 4.6, o que possibilita a integração dessa ferramenta com outros sensores e facilita a criação de algoritmos para se trabalhar em aplicações de tempo real.

A biblioteca PCL foi utilizada para aplicar todas técnicas em nuvem de pontos neste trabalho. Com intuito de demonstrar os efeitos das técnicas em nuvem de pontos que serão usadas neste trabalho, a Figura 3.1, capturada no LARS, será tomada como referência para observar os efeitos das técnicas que serão tratadas.

Figura 3.1: Nuvem de Pontos tomada como referência

Fonte: Própria do autor

3.3 Transformações Geométricas em Nuvem de Pontos

Como a nuvem de pontos obtida no Algoritmo 1 segue como referência o sistema de coordenadas da câmera, muitas vezes se faz necessário referenciar para um sistema de coordenadas externo, que neste trabalho é definido como o sistema de coordenadas do mundo. A transformação do sistema de coordenadas da câmera com relação ao mundo é influenciada pelos parâmetros extrínsecos da câmera. Parâmetros extrínsecos representam a posição e orientação da câmera segundo algum referencial de coordenadas externo.

(40)

da câmera Pc= [Xc,Yc, Zc]T para o mundo Pm= [Xm,Ym, Zm]T dado uma rotação R e uma translação T é dada pela equação 3.4.

      Xm Ym Zm       =       r₁₁ r₁₂ r₁₃ r₂₁ r₂₂ r₂₃ r31 r32 r33             Xc Yc Zc       +       T_x T_y T_z       (3.4) Ou : Pm= RPc+ T (3.5)

3.4 Filtros em Nuvem de Pontos

Por possuir uma resolução de 480x640 pixels, um único frame pode representar um conjunto de 307200 pontos. Essa quantidade de informação, além de muitas vezes ser redundante em muitas aplicações, dificulta seu processamento rápido. Além disso, algu-mas dessas medições podem possuir erros relacionados a problealgu-mas na medição, gerando pontos errôneos na nuvem de pontos, chamados de outliers. Com isso, algumas técnicas de filtragens de pontos serão apresentadas no intuito de que se reduza a quantidade de pontos na nuvem a serem tratados.

3.4.1 Filtro de Distância

Filtrar distâncias permite eliminar um conjunto da nuvem de pontos que não esteja inserido em algum intervalo de interesse, garantindo mais eficiência computacional pro-cessando apenas uma região de interesse. Essa abordagem permite remover regiões dis-tantes, onde alguns sensores costumam possuir um erro maior devido a ruídos externos. A Figura 3.2b demonstra a retirada de pontos da nuvem de pontos de referência 3.2a cuja distância ao sensor Kinect são maiores que 2,5 metros.

(41)

3.4. FILTROS EM NUVEM DE PONTOS 21

Figura 3.2: Nuvem de Pontos tomada como referência (a) e com a remoção de distâncias maiores que 2,5 metros (b)

(a) (b)

3.4.2 Filtragem de Pontos Usando Voxel Grids

A técnica de filtragem de voxel grids consiste na aplicação de volumes elementares (voxels) tridimensionais sobre todo o espaço ocupado pela nuvem de pontos. Para cada um desses volumes (voxels), todos os pontos contidos nos mesmos são aproximados pe-los centroides dos volumes elementares correspondentes. Esta aproximação permite que se faça uma redução da densidade dos dados, preservando, dentro de certos limites, a estrutura e suavidade das superfícies (Talhada 2012).

Aplicar essa técnica permite reduzir de forma considerável a quantidade de pontos a ser tratada. Porém, para que não haja perda da informação de interesse, é necessário analisar qual o valor ideal para aproximar os Voxels. Neste trabalho, como o intuito é de detectar planos para que seja possível, futuramente, mapear o ambiente, variações pequenas nas regiões planares podem não ser um problema grave. A Figura 3.3b ilustra a nuvem nuvem de pontos após o processo de filtragem de Voxel Grid com voxels de 2 centímetros de lado.

(42)

Figura 3.3: Nuvem de Pontos tomada como referência (a) e com a aplicação do filtro de Voxel Grid

(a) Referência (b) Distância Removida

3.5 Definição de Planos

Para caracterizar um plano π são necessários três pontos no espaço (Mello 2011). Por exemplo, para caracterizar um plano usando os pontos A = [x0, y0, z0], B = [x1, y1, z1] e

C= [x2, y2, z2], é necessário criar os vetores ~u e ~v através das equações 3.6 e 3.7.

~u = [l, m, n] = [x0− x1, y0− y1, z0− z1] (3.6)

~v = [p, q, r] = [x0− x2, y0− y2, z0− z2] (3.7)

Se ~u e ~v forem linearmente independentes, qualquer ponto P = [x, y, z] pertence ao plano se satisfizer a equação 3.8.

x− xo y− yo z− zo l m n p q r = 0 (3.8)

(43)

3.5. DEFINIÇÃO DE PLANOS 23 (m × r − n × q) × x + (n × p − l × r) × y + (l × q − m × p) × z− (m × r − n × q) × x0− (n × p − l × r) × y0− (l × q − m × p) × z0= 0 (3.9) Simplificando as equações: a= m × r − n × q (3.10) b= n × p − l × r (3.11) c= l × q − m × p (3.12) d= (m × r − n × q) × x0− (n × p − l × r) × y0− (l × q − m × p) × z0 (3.13)

Com a, b, c não podendo ser nulos ao mesmo tempo, ou seja:

a2+ b2+ c26= 0 (3.14)

Como x0, y0, z0, l, m, n, p, q e r são números reais não nulos, o determinante acima

pode ser rearrumado para uma equação de primeiro grau nas variáveis x,y e z, como mostra a equação 3.15:

ax+ by + cz + d = 0 (3.15)

Analisando a matriz em 3.8 e as equações 3.10, 3.11, 3.12 e 3.13, podemos encontrar os valores de a, b, c e d rearranjando no formato de determinante de matriz, conforme

(44)

24 CAPÍTULO 3. PROCESSAMENTO EM NUVEM DE PONTOS mostrado em 3.16, 3.17, 3.18 e 3.19. a= m n q r (3.16) b= l n p r (3.17) c= l m p q (3.18) d= −xo −yo −zo l m n p q r (3.19)

Com a definição da equação plano, dado um plano qualquer π definido pela equação ax+ by + cz + d = 0, a distância D de um ponto P = [xp, yp, zp] a esse plano é dado pela

equação 3.20. D= ax_p+ byp+ czp+ d √ a2+ b2_{+ c}2 (3.20)

3.6 Detecção de Planos Usando o Método de RANSAC

O método Random Sample Consesus (RANSAC) (Fischler e Bolles 1981) para de-tecção de planos em nuvem de pontos consiste em procurar a melhor equação do plano, conforme 3.15, que abranja a maior quantidade de pontos possível considerando algum determinado limiar ε, de modo que o cálculo da equação 3.15 seja modificada para 3.21. Os pontos que se encaixam na equação de plano são chamados de inliers, enquanto pontos que não se encaixam são chamados de outliers.

(45)

3.6. DETECÇÃO DE PLANOS USANDO O MÉTODO DE RANSAC 25

|ax + by + cz + d| ≤ ε (3.21)

O método de RANSAC escolhe aleatoriamente 3 pontos na nuvem de pontos, encontra a equação do plano p = [a, b, c, d] e procura todos os pontos na nuvem de pontos que se encaixam na equação. Essa ação é executada N vezes e a equação que retornar o maior número de inliers é escolhida. O Algoritmo 2 demonstra o procedimento para a definição de um plano baseado no trabalho de Yang e Förstner (2010).

Para que seja possível detectar múltiplos planos em uma mesma nuvem de pontos, é necessário que o método de RANSAC seja executado repetidas vezes, de modo que a cada plano detectado, se retire os inliers da nuvem de pontos e execute o método de RANSAC com o restante da nuvem de pontos.

(46)

Algoritmo 2: Algoritmo de Detecção de Planos usando RANSAC

Entrada: ptc: nuvem de pontos; N: número máximo de iterações para definir o plano; ε: limiar para determinar se algum ponto pertence ao plano Saída: MelhorPlano: Parâmetros do Plano (a, b, c, d)

1 pontos← 0; 2 i← 0;

3 MelhorDesv← inf; 4 enquanto i ≤ N faça

/* Seleciona trés pontos randômicos da nuvem de pontos */

5 j← selecionar3(ptc);

/* Encontra a equação do plano ax + by + cz + d = 0 para os três pontos j, conforme as equações 3.16,3.17,3.18 e 3.19 */

6 eqp← eqplanp( j);

/* Determina a distância de cada ponto ao plano */

7 dis← distanciaparaplano(eqp, ptc);

/* Encontrar os pontos cuja distância ao plano é, em valor

absoluto, menor que limiar, conforme 3.20 */

8 inliers← encontrar(dis, ε, ptc);

/* Verifica o desvio padrão do conjunto de pontos encontrados

com relação a equação do plano */

9 st← desviopad(inliers, eqp);

/* Os valores da equação só serão atualizados caso a nova equação encontrada englobe um maior número de pontos ou tiver a mesma quantidade de pontos e um desvio padrão menor */

10 se (tamanho(inliers) > pontos) ∨ ((tamanho(inliers) = pontos ∧ st <

MelhorDesv)) então

11 pontos← tamanho(inliers); 12 Melhor plano← eqp; 13 MelhorDesvPad← st; 14 fim

15 i← i + 1; 16 fim

(47)

Capítulo 4

Modelagem e Implementação

Para que o sistema de visão seja implementado de forma otimizada, é necessário de-finir alguns parâmetros específicos, tal como delimitar o conjunto de pontos que devem ser tratados pelo algoritmo. Para isso, é necessário compreender certos conceitos, tais como a velocidade média do ser humano e uma análise do ponto de vista geométrico do problema, esses tópicos serão vistos nas seções 4.1 e 4.2, respectivamente.

Em seguida, esse capítulo trata da parte de implementação prática do problema, par-tindo da importância de se utilizar um sensor para medir orientações (seção 4.3), dos re-cursos computacionais responsáveis pelo processamento utilizados (seção 4.4), da imple-mentação prática realizada (seção 4.5) e, por fim, na seção 4.6 será abordado o framework que foi usado para gerenciar os recursos computacionais.

4.1 Velocidade Média do ser Humano

Como o objetivo do projeto Ortholeg é de garantir uma órtese transparente para o usuário, é interessante que, na versão final do equipamento, seja possível garantir uma velocidade média de caminhada próxima à humana. Tendo isso em mente, o sistema de visão deve, por consequência, ser capaz de processar seus dados de modo a garantir que, a uma caminhada humana média, a área de caminhada esteja devidamente processada durante todo o tempo.

(48)

28 CAPÍTULO 4. MODELAGEM E IMPLEMENTAÇÃO

Para um adulto médio, sua velocidade média de caminhada gira em torno de 1,4m/s ((Browning et al. 2006), (Mohler et al. 2007), (Levine e Norenzayan 1999)). Logo, a capacidade de processamento deve levar em conta esse parâmetro, de modo a ter uma capacidade de processar mais metros à frente do usuário, a um tempo menor.

Contudo, para pacientes em reabilitação, é necessário enfatizar que, com uma ca-pacidade de locomoção reduzida, sua distância percorrida será bastante reduzida, o que diminui a necessidade de um sistema de visão com processamento equivalente ao de uma caminhada normal.

4.2 Modelagem Geométrica do Problema

Por esse trabalho possuir um conjunto de sistemas de referências, é necessário a forma como foi definido certos parâmetros, como o sistema de referência humano e o posicio-namento e orientação inicias da câmera.

4.2.1 Principais Eixos do ser Humano

Os principais eixos do ser humano serão os mesmos utilizados por Araújo (2015), onde os eixos x,y e z representarão os eixos frontal, transversal e longitudinal, respecti-vamente. A órtese Ortholeg foi projetada para se deslocar sobre o plano sagital, que é formado pelos eixos longitudinal e frontal, que foram o foco deste trabalho. A Figura 4.1 ilustra o modelo de eixos e planos que serão considerados.

Essas considerações são importantes para realizar as transformações homogêneas, como mostrado no Capítulo 3, entre o sistema de coordenadas da câmera para o sistema de coordenadas do mundo.

(49)

4.2. MODELAGEM GEOMÉTRICA DO PROBLEMA 29

Figura 4.1: Eixos e Planos Principais do Corpo Humano

Fonte: Adaptado deAraújo (2015)

4.2.2 Posição e Orientação Iniciais da Câmera

O começo da área de observação do sensor foi considerado a uma distância de 30 centímetros à frente do usuário, visto que a distâncias menores, a medida que o usuá-rio caminhasse, seus membros infeusuá-riores iriam bloquear o campo de visão e afetariam a detecção de planos. A Figura 4.2 ilustra o modelo do campo de visão do sensor Ki-nect em duas dimensões (plano sagital) dada uma distância mínima de mapeamento de 30 centímetros à frente e uma altura h, ajustável conforme a altura do usuário da órtese.

O ângulo inclinação mínima θ com relação à altura h levando em consideração o campo de visão de 43°do Kinect v1 pode ser definido pela equação 4.1.

θ = 43 2 + arctan 0, 3 h (4.1)

(50)

Figura 4.2: Angulo Mínimo de Orientação da Câmera

4.3 Uso de um Sensor de Medidas Inerciais

A nuvem de pontos obtida é representada no sistema de coordenadas do sensor Kinect, conforme mostra a Figura 4.3. Com isso, como foi dito no Capítulo 3, faz-se necessário conhecer os parâmetros extrínsecos da câmera em todo instante em que houve a captura da nuvem de pontos, pois por mais que se considere os parâmetros obtidos na equação 4.1 como fixos, o próprio ato de caminhar, por possuir oscilações sinusoidais, altera a orien-tação da câmera no usuário.

Figura 4.3: Sistema de Coordenas do Sensor Kinect

(51)

4.3. USO DE UM SENSOR DE MEDIDAS INERCIAIS 31

Para contornar esse fato, foi usado a mesma abordagem de Zhao et al. (2018) que re-solveu esse problema com a instalação de um sensor de unidade de medida inercial (UMI) ligado ao sensor Kinect. Com isso, foi possível realizar uma transformação geométrica, conforme mostrado no Capítulo 3, para descrever a nuvem de pontos com o referencial da UMI. O modelo utilizado da UMI foi o BNO055 (BOS 2013), mostrado na Figura 4.4 da Empresa BOSCH, esse modelo provê orientação nas representações em ângulos de Euler, em Quatérnios e também na forma de vetores de rotação. A biblioteca PCL pos-sui ferramentas para realizar transformações geométricas usando todas as formas citadas anteriormente.

Figura 4.4: Sensor de Unidade de Medidas Inerciais BNO055

Para interligar o sensor UMI com o sensor Kinect, foi criado um suporte impresso em uma impressora 3D. A Figura 4.5 mostra o suporte já instalado entre o Kinect Sensor e o UMI.

Figura 4.5: Kinect Interligado com o Sensor UMI

(52)

4.4 Processamento

Com intuito de otimizar o tempo de compilação, toda a elaboração dos códigos foi feita usando um computador de mesa com processador AMD A8-5500B e 8GB de me-moria RAM. Contudo, para os teste práticos, o equipamento responsável por receber os dados foi o computador Raspberry Pi 3 Model B (RAS 2016). Sua escolha se deve ao fato de sua portabilidade e de seu poder de processamento, além do fato de já ser utilizado no projeto Ortholeg (Melo et al. 2017). O computador Raspberry possui um processador Broadcom BCM2837B0, Cortex-A53 64-bit SoC @ 1.4GHze memória RAM de 1 Giga-bites. No trabalho de Zheng et al. (2016), esse minicomputador já foi utilizado ligado ao Sensor Kinect para realizar técnicas de Localização e Mapeamento Simultâneos (Simul-taneous Localization and Mapping- SLAM).

Para a aquisição dos dados da UMI, o microcontrolador Arduino foi utilizado como intermediário. Esse fato se deu devido à intenção de fazer com que o Raspberry fosse responsável de receber os dados tratados, ou seja, de forma a não se esforçar compu-tacionalmente para aquisição. Para esse trabalho, a UMI teve como propósito fornecer os ângulos no formato em quatérnios. A Figura 4.6 ilustra o modelo usado para fazer a captura dos dados da UMI usando o Arduino.

Figura 4.6: Modelo para captura da orientação do UMI

(53)

4.5. IMPLEMENTAÇÃO 33

4.5 Implementação

Para os testes inicias, o Sensor Kinect e o sensor UMI foram conectados ao Raspberry Pi 3 b+. A comunicação com o Raspberry Pi se deu via protocolo Secure Shell (SSH) com intuito de garantir que o Raspberry não consumisse poder de processamento inicializando sua interface gráfica.A Figura 4.7 ilustra o layout físico em ambiente de testes realizado.

Figura 4.7: Layout de Conexões Implementado

Após a criação da nuvem de pontos e com os valores referentes aos ângulos da UMI, o computador Raspberry teve a função de realizar a transformação da nuvem de pontos para o sistema de coordenadas do mundo, retirar longas distâncias, aplicar o filtro de Voxel Gridse extrair as equações dos plano. A Figura 4.8, ilustra o diagrama de blocos que foi implementado, a saída do programa são as equações de plano no cenário em questão juntamente com os seus respectivos inliers.

4.6 Sistema Robótico Operacional (ROS)

O Sistema Robótico Operacional (Robot Operating System - ROS) é um framework para escrever softwares na área da Robótica. Esse framework consiste em uma coleção de ferramentas, bibliotecas e métodos convencionais que visam simplificar a tarefa de criar um comportamento complexo e robusto de um robô em uma ampla variedade de

(54)

Figura 4.8: Diagrama de Blocos a ser Executado no Computador Raspberry PI

plataformas robóticas (Quigley et al. 2015).

Um sistema ROS em execução, simplificadamente, consiste em uma série de progra-mas diferentes sendo executados simultaneamente e se comunicando entre si através do uso de mensagens.

Em se tratando da aquisição da nuvem de pontos, o framework ROS possui em seu repositório os pacotes OPENNI e libfreenect que permitem obter a nuvem de pontos di-retamente do sensor Kinect. Esse fato permite que o programador não se preocupe, por exemplo, em elaborar um código que crie a nuvem de pontos, aproveitando com isso pro-gramas já fundamentados no meio acadêmico e comercial. Além disso, a ferramenta ROS também possui em seu repositório a biblioteca Point Cloud Library (PCL). Esses dois fatores permitem que seja possivel que haja comunicação para receber a nuvem de pontos e convertê-la de modo que a implementar os processos de filtragens disponíveis no PCL.

Para se comunicar com a UMI conectado ao microcontrolador Arduíno, a ferramenta rosserial presente no ROS permite estabelecer uma comunicação serial entre os micro-controladores Arduino e Raspbery, garantindo assim uma troca de mensagens entre eles.

Além do que foi descrito, a biblioteca ROS possui algumas ferramentas úteis para esse trabalho, tais como gravação dos dados dos sensores e do sensor Kinect, verificação da

(55)

4.6. SISTEMA ROBÓTICO OPERACIONAL (ROS) 35

frequência com que a mensagens são publicadas, entre outras funcionalidades que serão abordados futuramente nesse trabalho.

(56)

(57)

Capítulo 5

Resultados

Este capítulo apresenta os resultados obtidos em ambiente de simulação e em ambi-ente real. No ambiambi-ente de simulação, serão apresentados alguns resultados que serviram como guia para a implementação dos testes em ambiente real. Em seguida, serão apre-sentados sobre os resultados obtidos em ambiente real e as estratégias para verificar a acurácia do algoritmo desenvolvido.

5.1 Resultados em Ambiente de Simulação

A plataforma Virtual Robot Experimentation Platform (V-REP) (Rohmer et al. 2013) é um software de simulação de experimentos na área de robótica bastante utilizado para execução de testes iniciais de algoritmos que futuramente serão implementados em am-biente real. Sua principal vantagem está em abstrair problemas relacionados ao uso de sensores em ambiente real, tais como ruídos, problemas na leitura e tempo de resposta. Nesse ambiente foi testado um modelo representando um obstáculo simples e uma escada, onde a nuvem de pontos de ambos são adquiridas com um sensor Kinect posicionado e orientado de modo similar ao proposto na seção 4.2.2. As Figuras 5.1a e 5.1b demonstram os cenários com um obstáculo simples e uma escada, respectivamente, onde foram feitos os testes para aquisição, filtragem e detecção de planos. As respectivas nuvens de pontos obtidas são ilustradas nas Figuras 5.1c e 5.1d .

(58)

38 CAPÍTULO 5. RESULTADOS

Figura 5.1: Cenários em Ambiente Simulado de um Obstáculo Simples (a), de uma escada (b) e suas respectivas nuvens de pontos (c,d)

(a) (b)

(c) (d)

5.1.1 Critérios Usados no Ambiente de Simulação

As técnicas utilizadas no ambiente de simulação utilizaram os critérios definidos no Capítulo 4. Com isso, foram aplicadas as seguintes abordagens:

• Transformação Geométrica: A câmera ficou fixa na posição x = 0 m, y = 0 m e z= 0, 8 m, logo a posição da câmera com relação ao mundo foi Pc = [0 0 0, 8]T.

Com relação à orientação, a câmera foi inclinada em -45°em torno do eixo x com relação às coordenadas de mundo Pm= [0 0 0]T.

(59)

5.1. RESULTADOS EM AMBIENTE DE SIMULAÇÃO 39

• Filtro de distância: Foram removidas distâncias maiores que 1,5 metros no eixo X do mundo , ou seja Xm. Para o eixo Ym, pontos fora do intervalo compreendido entre [−0, 3 0, 3] metros foram também removidos. Esses critérios foram escolhidos pois atendem a uma área retangular a frente do usuário de até 3 passos médios a frente do usuário e 60 centímetros de forma horizontal, o que permitiria focar em uma região de interesse que a órtese pudesse se locomover.

• Voxel Grid: Pontos contidos em um volume elementar de 0, 02 m × 0, 02 m × 0, 02m foram fundidos, reduzindo-se assim o número de pontos para serem trabalhados. Esses valores foram usados no trabalho de (Zhao et al. 2018), apresentando resul-tados satisfatórios que foram replicados nesse trabalho.

• Detecção de Planos pelo Método de RANSAC: Limiar ε com valor igual a 0,01 metros e valor N de iterações igual a 1000. Esses critérios são os padrões da ferra-menta PCL ao utilizar o método de RANSAC.

Os resultados em nível de simulação foram capazes de demonstrar uma redução drás-tica na quantidade de dados para definir o ambiente. Apesar disso, essa diminuição de informação não representou perda substancial no que se refere a sua qualidade. A Ta-bela 5.1 ilustra o nível percentual de dados que foram retirados após as transformações e filtragens. Com isso, em ambos os cenários, mais de 99% dos pontos foram descartados sem, contudo, apresentar grande perda substancial.

Tabela 5.1: Resultados das Técnicas de Transformações e Filtragens em Ambiente de Simulação

Etapas Escada Obstáculo

Quantidade de Pontos Absoluta Quantidade de Pontos Percentual Quantidade de Pontos Absoluta Quantidade de Pontos Percentual Tamanho Original 262144 100,00% 262144 100,00% 1 – Transformação Geométrica 262144 100,00% 262144 100,00% 2 – Filtro de distância 219870 83,87% 126992 48,44%

3 – Filtro de Voxel Grid 1920 0,73% 1477 0,56%

(60)

Uma forma de demonstrar que a redução da quantidade de pontos não afetou de forma drástica a equação que determina cada segmento de plano se dá através da comparação dos componentes [a, b, c, d] obtidos dos segmentos de plano referentes às nuvens de pontos que passaram pelos pelos processos de filtragem com relação às que não passaram. É possível ainda comparar o produto vetorial dos componentes [a, b, c] de cada parâmetro obtido e verificar o quanto são próximos a zero juntamente com o modulo da distância entre os componentes d de cada valor obtido. As Tabela 5.2 e 5.4 ilustram o comparativo desses valores usando o método de RANSAC, enquanto as Tabelas 5.3 e 5.5 mostram os respectivos produtos vetoriais e os módulos das diferenças entre as distâncias d . Para concluir, visualizando as nuvem de pontos pelas transformações e filtragens através das Figuras 5.2, é possível verificar que a redução da quantidade de pontos não alterou as formas básicas do cenário.

Tabela 5.2: Comparação entre os Valores Obtidos com e sem o uso de Filtros para a Nuvem de Pontos: Obstáculo

Mapa: Obstáculo

Planos Com filtro Sem Filtro

1 [0 0, 094 0, 995 − 0, 075] [0 0, 094 0, 995 − 0, 075] 2 [0 0, 093 0, 995 − 0, 254] [0 0, 093 0, 995 − 0, 254] 3 [0 − 0, 995 − 0, 095 0, 797] [0 − 0, 995 − 0, 091 0, 798]

Tabela 5.3: Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo da distancia entre o componente d : Obstáculo

Mapa: Obstáculo

Planos Produto Vetorial Modulo da Distância

1 [0 0 0] 0

2 [0 0 0] 0

3 [−0.004 0 0] 0, 001

(61)

5.1. RESULTADOS EM AMBIENTE DE SIMULAÇÃO 41

Tabela 5.4: Comparação entre os Valores Obtidos com e sem o uso de Filtros para a Nuvem de Pontos: Escada

Mapa: Escada

1 [0 0, 092 0, 995 − 0, 254] [0 0, 087 0, 996 − 0, 252] 2 [0 0, 081 0, 996 − 0, 426] [0 0, 077 0, 997 − 0, 424] 3 [0 − 0, 996 − 0, 082 0, 390] [0 − 0, 995 − 0, 095 0, 391] 4 [0 − 0, 995 − 0, 095 0, 662] [0 − 0, 994 − 0, 105 0, 664] 5 [0 − 0, 995 − 0, 095 0, 933] [0 − 0, 992 − 0, 119 0, 940] 6 [0 0, 094 0, 995 − 0, 075] [0 0, 064 0, 997 − 0, 065]

Tabela 5.5: Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo da distancia entre o componente d : Escada

Mapa: Escada

Planos Produto Vetorial Modulo da Distância

1 [0.005 0 0] 0, 002 2 [0.004 0 0] 0, 002 3 [0, 013 0 0] 0, 001 4 [0, 010 0 0] 0, 002 5 [0, 024 0 0] 0, 007 6 [0, 030 0 0] 0, 010

Figura 5.2: Nuvem de Pontos após Passar por Processos de Transformação Geométrica e Filtragens

(a) Obstáculo (b) Escada

(62)

5.2 Resultados em Cenário Real

Os critérios aplicados em ambiente real foram os mesmos definidos em ambiente de simulação, como foi mostrado na seção 5.1.1, com exceção do filtro de Voxel Grid, onde o volume elementar passou para 0, 01 m × 0, 01 m × 0, 01m, esse fato se deu a necessidade de garantir mais segurança, pois fundir pontos em um volume elementar maior poderia remover informações importantes, como pequenos objetos no cenário, por exemplo.

Para realizar os testes em cenário real, foram seguidas duas abordagens: testes com o sensor Kinect fixo e testes com o sensor em movimento de caminhada em um piso livre de obstáculos. Os testes com a câmera fixa serviram inicialmente para verificar se a correção da orientação do UMI agiu de acordo com o esperado e para corrigir eventuais problemas no algoritmo. Após essa etapa, foram feitos testes práticos com a câmera fixa no corpo do usuário em movimento com a orientação predefinida de acordo com a altura fornecida da câmera. Nessa etapa foram corrigidos os problemas referentes à sincronização das leituras entre a UMI e o sensor Kinect.

É importante ressaltar que, quando se trabalha com capturas em ambientes reais, é necessário que haja um processo de filtragem que retire regiões onde não foi possível rea-lizar medições de profundidade. Essas impossibilidades muitas vezes se dão por limitação do próprio hardware. No caso do sensor Kinect v1, por exemplo, distâncias abaixo de 0,4 metros e mais distantes que 4 metros não podem ser calculadas. Logo, por mais que a resolução da imagem do sensor se mantenha em 640 × 480, alguns pixels não terão um valor registrado de distância. Onde o sensor não retornou leitura de profundidade válida em alguns pontos, tais pontos são removidos na etapa de pré-processamento.

5.2.1 Captura da Nuvem de pontos com a Câmera Fixa

As capturas iniciais foram feitas com cenários bastante comuns na caminhada hu-mana: Piso Livre de Obstáculos, Rampas, Subidas e Descidas de escadas. A Figura 5.3

(63)

5.2. RESULTADOS EM CENÁRIO REAL 43

mostram alguns frames capturados no Núcleo de Pesquisa e Inovação em Tecnologia da Informação (nPITI), na UFRN.

Figura 5.3: Cenários capturados para validação do método: Piso livre de obstáculos (a) Rampa (b), Degrau de Escadas (c) e Descida de Escadas (d)

(a) (b)

(c) (d)

A Tabela 5.6 ilustra a quantidade absoluta e o percentual das nuvens de pontos que foram retiradas com o decorrer dos processos de filtragem. Com isso, é possível constatar que o processo de filtragem reduziu em mais de 95% o montante de pontos com relação ao número original, o que implica em reduzir o processamento que ocorre após essa etapa. As equações obtidas com e sem o processo de filtragem apresentaram similaridades às obtidas em ambiente de simulação e são mostrados nas Tabelas 5.7, 5.9, 5.11 e 5.13 com os devidos comparativos enquanto as Tabelas 5.8, 5.10, 5.12 e 5.14 ilustram os produtos vetoriais entre os componentes [a, b, c] que passaram pelo processo de filtragem com os que não passaram juntamente com o modulo da diferença do componente d de cada.

As nuvens de pontos das respectivas imagens pós processo de filtragem podem ser vistas nas Figuras 5.4.

(64)

Tabela 5.6: Redução do Número de Pontos após os Processos de Filtragem

Mapa Tamanho Original Leituras Obtidas Filtro de Voxel Grid Filtro de distância

Piso LARS Absoluto 307200 252296 18029 10642

Percentual 100% 82,13% 5.87% 3.46%

Rampa Absoluto 307200 252210 24768 11733

Percentual 100% 82,1% 8,06% 3,82%

Escada Ascendente Absoluto 307200 250309 32379 13317 Percentual 100% 81,48% 10,54% 4,33% Escada Descendente Absoluto 307200 221506 75351 4771

Percentual 100% 72,10% 24,52% 1,55%

Tabela 5.7: Comparação entre os Valores Obtidos com e sem o uso de Filtros para a Nuvem de Pontos: Piso LARS

Mapa: Piso LARS

1 [0, 025 0, 010 0, 999 0, 011] [0.012 0, 011 0, 999 0, 010]

Tabela 5.8: Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo da distância entre o componente d: Piso LARS

Mapa: Piso LARS

Planos Produto Vetorial Diferença em Modulo 1 [−0, 001, −0, 012987, 0] 0, 001

Tabela 5.9: Comparação entre as Equações Obtidas com e sem o uso de Filtros para a Nuvem de Pontos: Rampa

Mapa: Rampa

1 [0, 040 − 0, 082 0, 996 0, 027] [−0.003 − 0, 037 0, 999 − 0, 002] 2 [0.036 − 0, 024 0.999 0.007] [0.016 − 0, 088 0, 996 0, 032]

5.2.2 Captura da Nuvem de pontos com a Câmera em movimento

Funcionando como esperado, o passo seguinte então foi realizar uma caminhada para simular a execução de forma aproximada do que aconteceria em ambiente real, ou seja, com a câmera localizada na região da cintura do usuário.

(65)

5.2. RESULTADOS EM CENÁRIO REAL 45

Tabela 5.10: Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo da distancia entre o componente d: Rampa

Mapa: Rampa

Planos Produto Vetorial Diferença em Modulo 1 [−0.045, −0.043, −0.002] 0, 029

2 [0.064, −0.019, −0.003] 0, 029

Tabela 5.11: Comparação entre as Equações Obtidas com e sem o uso de Filtros para a Nuvem de Pontos: Escada Ascendente

Mapa: Escada Ascendente

1 [0, 036 0, 003 0, 999 − 0, 003] [0.002 0, 001 0, 999 − 0, 002] 2 [−0.069 − 0, 998 0, 002 1, 109] [−0.067 − 0.998 − 0.014 1.111] 3 [−0.013 − 0, 999 − 0, 018 1, 405] [−0.074 − 0.997 − 0.029 1.425] 4 [0.035 0, 001 0.999 − 0.226] [0.001 0.002 0.999 − 0.228]

Tabela 5.12: Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo da distancia entre o componente d: Escada Ascendente

Mapa: Escada Ascendente

Planos Produto Vetorial Diferença em Modulo 1 [0, 002 − 0, 034 0] [0, 001]

2 [0, 016 − 0, 001 0.002] [0, 002] 3 [0, 011 0.001 − 0.061] [0, 020] 4 [−0, 001 − 0.0340 0.001] [0, 002]

Tabela 5.13: Comparação entre as Equações Obtidas com e sem o uso de Filtros para a Nuvem de Pontos: Escada Descendente

Mapa: Escada Descendente

1 [0, 030 0, 003 0, 999 0.160] [−0, 004 0.006 0.999 0.157] 2 [0, 026 0, 555 0, 832 − 0, 333] [0, 005 0.529 0.848 − 0.318] 3 [0, 033 0, 075 0, 996 0, 261] [−0, 008 0.037 0.999 0.305] 4 [0, 052 0, 508 0, 859 − 0, 315] [−0, 017 − 0.015 0.999 0.557]

A simulação de caminhada foi feita em um ambiente indoor, também no nPITI, onde a região de interesse à frente fosse livre de obstáculos. Nessa aplicação, foi necessário

(66)

Tabela 5.14: Produto vetorial entre os Componentes [a, b, c] de cada plano e o modulo da distancia entre o componente d: Escada Descendente

Mapa: Escada Descendente

Planos Produto Vetorial Diferença em Modulo 1 [−0, 003, −0, 034, 0] [0, 003]

2 [0, 030, −0, 018, 0.011] [0, 015] 3 [0.038, −0.041, 0.002] [0, 044] 4 [0.520, −0.066, 0.008] [0.872]

Figura 5.4: Nuvem de Pontos filtradas para validação do método: Piso livre de obstáculos (a) presença de rampa (b), escada ascendente (c) e escada descendente (d)

(a) (b)

(c) (d)

Fonte: Própria do autor(2019)

assegurar o número máximo de registros de mudança de orientação do sensor UMI, para que, no momento da captura da nuvem de pontos, a orientação obtida fosse a mais pró-xima do momento da sua captura. As Figuras 5.5 ilustram os pontos inicias e finais da caminhada realizada.