UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SOFTWARE DE ARMAZENAMENTO DE POSES CAPTURADAS PELO MICROSOFT KINECT por Natália Ellery Ribeiro Couto

2 Itajaí (SC), novembro de 2012

3 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SOFTWARE DE ARMAZENAMENTO DE POSES CAPTURADAS PELO MICROSOFT KINECT Área de Jogos Digitais por Natália Ellery Ribeiro Couto Relatório apresentado à Banca Examinadora do Trabalho Técnico-científico de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Benjamin Grando Moreira, M.Eng. Itajaí (SC), novembro de 2012

4 AGRADECIMENTOS Agradeço ao meu pai por tornar possível meu estudo, por ter paciência na dúvida que tive sobre o futuro. A minha mãe por me ajudar a escolher o que eu gosto e assim conhecer o curso de computação mudando toda a visão do que queria pra minha vida. Agradeço aos dois por serem pessoas tão boas, por me fazerem tão feliz e pelo apoio e ajuda nas decisões mais difíceis. Agradeço ao meu irmão Gabriel por sempre me fazer rir e por me mostrar as coisas como elas realmente são, principalmente nas horas mais confusas. Agradeço aos meus irmãos Lucas e Matheus, que apesar de muitas vezes me atrapalharem com a bagunça, são na verdade minha inspiração. Agradeço ao meu orientador Benjamin Grando Moreira por toda a ajuda com o trabalho final e ao professor Rudimar Scaranto Dazzi por todas as oportunidades de pesquisa. Agradeço aos meus amigos Rodrigo Lyra, Jailson Nicoletti, Humberto Di Paolo, Gabriel Armando Delgado por tudo que me ensinaram, e por mais mal-humorada que eu estivesse, sempre ficaram ao meu lado.

5 If you can't explain it simply, you don't understand it well enough.

6 RESUMO COUTO, Natália E. R. Software de Armazenamento de Poses Capturadas pelo Microsoft Kinect. Itajaí, Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, O trabalho trata do desenvolvimento de um software capaz de comunicar-se com o Microsoft Kinect, capturando poses num primeiro momento, armazenando-as e usando-as para comparação com poses executadas num momento posterior. Com a criação do Microsoft Kinect surgiu a oportunidade de criar aplicações que envolvem atividades físicas, porém, existe uma dependência com o desenvolvedor de software. Este trabalho possibilita o desenvolvimento de um software que permite o armazenamento de uma pose, ou seja, o usuário pode gravar posturas e disponibilizar para que ele mesmo ou um outro usuário execute as poses em um momento posterior, desta maneira o usuário cria uma pose nova abstraindo todo o processo de desenvolvimento de software. Para armazenar uma pose, o Microsoft Kinect captura os pontos do esqueleto do usuário, o software trata os mesmos, e os armazena em uma estrutura de dados. Depois de armazenados, é possível tentar realizar a pose, momento em que os novos pontos do esqueleto serão capturados e também tratados para fazer uma comparação aos que estão armazenados. O software auxilia o usuário a realizar a pose armazenada, corrigindo o que está errado e orientando a realização correta da pose. Durante os testes do software foi possível validar o armazenamento e reconhecimento de poses, permitindo que uma pose seja reconhecida não importando a estatura da pessoa que a realizou. Palavras-chave: Microsoft Kinect. Comparação de poses. Armazenamento de poses.

7 ABSTRACT The Project is about the development of a software which communicate with Microsoft Kinect, capturing new poses, storing them and using them to compare with other poses. With the appearance of Microsoft Kinect there are new opportunities of create applications that involve physical activities, but there is still a huge dependence on the software developers. This project made possible to create a software that allows a person to record postures and provide them to himself or another person to perform it, that way the user can create a new pose without participating of an entire process of software development. To store a pose, Microsof Kinect capture the user s skeleton points, and then it do an algorithm to treat them and store them in a data structure. After stored, anyone is able to perform the pose, and then the new captured skeleton points are compared with those stored. The software assist the user to perform the pose stored, instructing what is wrong and how he must act to perform correctly the pose During testing of the software it was able to validate the storage and recognition of poses, allowing a pose to be recognized no matter the stature of the person who performed it. Keywords: Microsoft Kinect. Comparison of poses. Storage of poses.

8 LISTA DE FIGURAS Figura 1. Representação da divisão das partes do corpo Figura 2. Composição do Kinect Figura 3. Bits que representam profundidade e identificação do jogador Figura 4. Representação do jogador adquirida através dos bits Figura 5. Pontos do esqueleto acessíveis através do Kinect for Windows Figura 6. (a) Representação de uma árvore de XML; (b) XML referente à árvore Figura 7. Imagem ilustrando a relação dos pontos y em um braço levantado Figura 8. Exemplo de uma mesma pose executada com pequenas diferenças nos ângulos Figura 9. Pose Atual do jogador comparada com a pose armazenada Figura 10. Exemplo de uma pessoa entrando em colisão com uma bola virtual Figura 11. (a) Aviso de proximidade; (b) Personagem piscando Figura 12. Jogador executando um movimento incorretamente Figura 13. Um jogador não realizando os movimentos Figura 14. (a) Jogador realizando movimentos corretamente; (b) Jogador errando uma parte do movimento Figura 15. (a) Jogador acertando o movimento; (b) Jogador errando o movimento Figura 16. O jogador da esquerda está errando e o jogador da direita acertando Figura 18. Caso de Uso do Módulo de Captura Figura 19.(a) Pontos na visão X e Y(b) Pontos na visão Z e Y (c) Pontos na visão X e Z Figura 20. Pontos utilizados para descobrir um ângulo Figura 21. Teorema de Pitágoras aplicado aos pontos da Figura Figura 22. Fórmula para descobrir a altura e as projeções dos catetos Figura 23. Cálculo do seno dos ângulos Figura 24. Valores do ângulo em relação ao seno Figura 25. Ângulos iguais para poses diferentes Figura 26. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no primeiro quadrante Figura 27. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no segundo quadrante Figura 28. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no terceiro quadrante Figura 29. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no quarto quadrante Figura 30. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no terceiro e/ou quarto quadrante Figura 31. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no primeiro e/ou segundo quadrante Figura 32. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no primeiro e/ou terceiro quadrante Figura 33. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no segundo e/ou quarto quadrante Figura 34. Caso onde a articulação anterior (segmento verde) está no primeiro quadrante e a articulação posterior (segmento vermelho) está no quarto quadrante Figura 35. Caso onde a articulação anterior (segmento verde) está no segundo quadrante e a articulação posterior (segmento vermelho) está no terceiro quadrante Figura 36. Caso onde a articulação anterior (segmento verde) está no terceiro quadrante e a articulação posterior (segmento vermelho) está no segundo quadrante... 61

9 Figura 37. Caso onde a articulação anterior (segmento verde) está no primeiro quadrante e a articulação posterior (segmento vermelho) está no quarto quadrante Figura 38. Caso de Uso do Módulo de Comparação Figura 39. Tela inicial Figura 40. Contagem regressiva que ao chegar a zero armazena a pose Figura 41. Opções que permitem gerenciar uma pose Figura 42. Fluxograma representando a edição de uma pose Figura 43. Ângulo da execução em tempo real maior que o ângulo armazenado e menor que o limite superior dividido por dois Figura 44. Ângulo da execução em tempo real maior que o ângulo armazenado e menor que o limite superior Figura 45. Ângulo da execução em tempo real menor que o ângulo armazenado e maior que o limite inferior dividido por dois Figura 46. Ângulo da execução em tempo real menor que o ângulo armazenado e maior que o limite inferior dividido por dois Figura 47. Ângulo da execução em tempo real menor que o ângulo armazenado e maior que o limite inferior Figura 48. Ângulo da execução em tempo real menor que o ângulo armazenado e menor que o limite inferior Figura 49. Feedback com exibição do vulto Figura 50. Feedback através de setas Figura 51. Feedback através de cores do esqueleto Figura 52. Feedback através de texto Figura 53. Feedback através de vértices coloridos... 73

10 LISTA DE QUADROS Quadro 1. Exemplo de código para criar um gerador de profundidade Quadro 2. Resoluções e formatos que podem ser utilizados Quadro 3. Comparação entre os trabalhos similares Quadro 4. Parte do XML representando uma articulação... 62

11 LISTA DE ABREVIATURAS E SIGLAS API DSL GUI IHC JNA JNI KGL OS QVGA RGB SDK SVM TTC UNIVALI USB VGA XML YUV Application Programming Interface Digital Subscriber Line Graphical User Interface Interface Humano Computador Java Native Access Java Native Interface Kinect Gesture Language Operational System Quarter Video Graphics Array Red Blue Green Software Development Kit Support Vector Machine Trabalho Técnico-científico de Conclusão de Curso Universidade do Vale do Itajaí Universal Serial Bus Video Graphics Array Extensible Markup Language Y é brilho, U e V são os componentes de crominância da cor

12 SUMÁRIO 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA INTERAÇÃO HUMANO COMPUTADOR Computação Ubíqua Interface Natural para o Usuário MICROSOFT KINECT Seleção e Feedback FRAMEWORKS DE DESENVOLVIMENTO OpenNI FUNCIONALIDADES BÁSICAS GRAVAÇÃO DE DADOS EXECUTAR DADOS SALVOS Kinect for Windows SDK IDENTIFICAÇÃO DO SENSOR FLUXO DE CORES DAS IMAGENS FLUXO DE PROFUNDIDADE DAS IMAGENS RASTREAMENTO DE ESQUELETO RECONHECIMENTO DE VOZ OpenKinect Comparação entre os Frameworks Pesquisados ARMAZENAMENTO DE DADOS XML TÉCNICAS DE COMPARAÇÃO DE POSES Técnica Algorítmica Matching Comparação de Ângulos Comparação de Pixel Análise das Técnicas de Comparação de Gestos Pesquisadas ANÁLISE DE FEEDBACK TRABALHOS SIMILARES Kinect SDK Dynamic Time Warping Gesture Recognition Recognizing Hands Gestures with Microsoft s Kinect Human Detection Using Depth Information by Kinect Construindo uma DSL para Reconhecimento de Gestos Utilizando Kinect Vitruvius Um Reconhecedor de Gestos para o Kinect Análise dos Trabalhos Similares DESENVOLVIMENTO... 50

13 3.1 ANÁLISE DE REQUISITOS E CASOS DE USO Módulo de Captura CÁLCULO E ARMAZENAMENTO DOS ÂNGULOS Módulo de Comparação FLUXO DE TELAS TESTES DIFICULDADES ENCONTRADAS NOS TESTES Conclusões... 76

14 12 1 INTRODUÇÃO Com a criação do computador surgiu a necessidade da criação de uma interface para que os humanos pudessem comunicar-se com a linguagem de máquina de alguma forma. Essa interface que realiza a comunicação, busca a forma mais natural de interação humana, de acordo com a tecnologia disponível na época, para que os usuários possam trabalhar com o computador da maneira mais agradável possível. A interface é muito importante, pois é ela que proporciona a satisfação do usuário durante a experiência com o computador. Com uma boa interface o usuário será mais eficiente, terá mais segurança, pois não terá acesso a comandos que possam causar estragos. (LIMA, 2006). O mouse surgiu quando os computadores evoluíram a ponto de exibir gráficos, surgindo também a necessidade de manipular esses gráficos através de um dispositivo. A partir da evolução da tecnologia surgiu o conceito da Natural User Interface, que permite que o usuário manipule os dados computacionais de forma natural em seu dia-a-dia, esse tipo de interface está presente em dispositivos diversos como celulares, porta-retratos, caixa eletrônica, e graças a esse conceito o computador está cada vez mais se integrando na sociedade e atingindo diversos públicos (OLIVEIRA, 2010). Quando a tecnologia começou a ser utilizada para entretenimento, foram criados consoles de jogos que necessitavam de uma interface diferenciada para que o jogador controlasse o jogo. Um tipo de interface entre o jogador e o jogo é o joystick, que disponibiliza botões para controlar o jogo. A forma convencional de interação favorece uma postura ruim e sedentária, onde não se realiza atividade física durante o jogo, provocando esforços repetitivos, e após um período de tempo, o uso torna-se desconfortável (ABRAHAM e NATH, 2004). Para tornar a interação com o jogo ainda mais dinâmica, foram criados diferentes tipos de joysticks que imitavam a realidade, como volante, freio, acelerador e embreagem de carro para jogos de corrida, armas para jogos de tiro, tapetes para jogos de dança. Com a evolução da tecnologia foi possível criar detectores de movimento como o Wii remote, que funciona através de um acelerômetro de três eixos com sistemas microeletromecânicos (TURNER, 2007), e o Playstation Move, que além do acelerômetro de

15 13 três eixos, também conta com um giroscópio que permite o reconhecimento de intensidade do movimento (LANDIM, 2010). Mesmo com detectores de movimento, ainda era necessário o uso de um joystick. Então, a tecnologia de interação evoluiu para a detecção através da webcam, a qual dispensa qualquer periférico, fazendo com que a interação seja natural ao ser humano e atraindo novos públicos para a tecnologia de entretenimento. Utilizando esse conceito surgiu a Touchless SDK (Software Development Kit), que captura a posição e o movimento de um objeto através de sua cor, ela foi criada para ser utilizada com tecnologia de baixo custo e software livre (ZEID et al, 2011). Apesar de uma tecnologia inovadora, a detecção através da cor possui algumas irregularidades, pois dependendo da distância, luz e qualidade da câmera, a cor de um mesmo objeto pode variar muito, fazendo com que a captura seja falha em alguns momentos (WU; YU, 2011). Gomide et al (2009) citam dois diferentes modos de capturar movimentos, como o acústico, onde marcadores que emitem som são posicionados no sujeito, e a captura magnética, onde os marcadores emitem campos magnéticos. Estes movimentos são adquiridos na etapa de criação do jogo, além disso, é necessário o uso de equipamentos caros, que possuem taxa de importação alta, e sua utilização possui complexidades intrínsecas. Em 2010 foi lançado o Microsoft Kinect(MICROSOFT, 2012), no decorrer do presente TTC ele irá ser chamado apenas de Kinect. O Kinect possui duas câmeras e um projetor infravermelho baseado em laser. O conjunto de uma das câmeras com o infravermelho é responsável por calcular a profundidade dos objetos capturados, a câmera RGB é utilizada na detecção das cores (KONOLIGE, MIHELICH, 2010). Através da inovação que o Kinect trouxe, ficou mais acessível criar jogos e softwares controlados por movimentos e posturas. Em 2011, a Microsoft disponibilizou o SDK (Software Development Kit) para o Kinect (Oficina da net, 2011) possibilitando o desenvolvimento de softwares para a interação com o computador, inovando a interface de controle com a linguagem de máquina. Utilizando-se desta nova forma de interação, através da detecção de movimentos, este trabalho permitiu o desenvolvimento de um software que e armazena poses estáticas representadas por pontos do esqueleto de uma pessoa através do Kinect, para que um jogo

16 14 possa dinamicamente utilizar novas poses que não foram planejadas durante a criação deste. Este armazenamento permite que o jogador adicione novas poses que posteriormente serão comparadas com as poses de outro jogador através dos pontos de esqueleto adquiridos. Durante a comparação de poses é necessário fornecer ao jogador um feedback relacionado a pose que ele está fazendo, podendo afirmar se ela é similar a uma pose anteriormente armazenada. Vários jogos atualmente utilizam diferentes tipos de feedback para que o jogador perceba se está realizando a pose corretamente. Este trabalho pesquisou as formas de feedback e comparação de poses utilizadas atualmente e realizou testes com quatro modelos de feedback com o objetivo de encontrar o modelo que melhor auxilie os jogadores. 1.1 PROBLEMATIZAÇÃO O Microsoft Kinect oferece a oportunidade de criar aplicações utilizando poses, mas é necessário o conhecimento de desenvolvimento de software para criar uma aplicação personalizada Formulação do Problema Muitas pessoas gostariam de utilizar o Kinect para criar aplicações e jogos utilizando poses e conceitos diferentes dos que existem atualmente, mas nem todas as pessoas possuem conhecimento para desenvolver aplicativos. Além disso, alguns jogos existentes atualmente, como por exemplo, o Just Dance, não fornecem um feedback instrutivo para os usuários, muitas vezes o usuário não sabe o que fazer para corrigir o que está errado na realização da postura Solução Proposta A criação de um software que abstrai a definição de uma pose e sua verificação quando está sendo executada, para que possa ser usado por pessoas que não possuem conhecimento em desenvolvimento, possibilitando o uso de novas poses para diferentes finalidades. O software fornece um feedback que auxilia a pessoa a realizar a pose corretamente, indicando o que ela está fazendo de errado e o que deve fazer para corrigi-la. As poses armazenadas no software possuem dados relevantes, como posição x, y e z e ângulos referentes à visão frontal, lateral e de cima das articulações do esqueleto da pose, armazenados em um arquivo XML, podendo servir de referência para criação de jogos e

17 15 aplicativos. Caso o desenvolvedor pretende criar um aplicativo ou um jogo, ele não precisa criar um algoritmo para calcular os dados angulares das articulações do esqueleto do jogador, ele pode utilizar o software criado neste projeto para auxiliá-lo.

18 OBJETIVOS Objetivo Geral Desenvolver um software que armazena poses representadas por pontos do esqueleto de um jogador captados através do Kinect, e os compara com uma execução futura Objetivos Específicos Pesquisar sobre Interação Humano Computador e as contribuições do Kinect; Analisar ferramentas que auxiliem na etapa de identificação do esqueleto através do Kinect; Analisar métodos de armazenamento de dados compatíveis com a ferramenta escolhida; Analisar métodos de comparação de poses captadas pelo Kinect; Elaborar a especificação e modelagem do software proposto; Realizar a implementação do software de acordo com a modelagem desenvolvida; Efetuar testes visando a avaliação do funcionamento do software em relação ao armazenamento de posturas, à funcionalidade do feedback e à comparação de posturas. 1.3 Metodologia Para alcançar os objetivos do trabalho proposto, foi realizada uma pesquisa sobre a evolução das interfaces entre humano computador e analisado os conceitos que coincidem com a interface utilizada pelo Kinect. Durante a pesquisa foi encontrado o conceito de interface natural (WEISER, 1991; ARAÚJO, 2003; SANTOS, 2009) e computação ubíqua (SOARES, 2011; BUXTON, 2010; BLAKE, 2011; PORTELLA, 2008; PAULA, 2011; AZUMA, 2011; WEBB E ASHLEY, 2012; NUNES et al, 2011), os quais possuem uma relação muito grande com o Kinect e puderam esclarecer como pode ser construída uma interface para um aplicativo que se comunica com o Kinect. A principal fonte de pesquisa foi a internet, verificando artigos relacionados a interface natural, pois não foi possível encontrar livros que abordam o modelo de interface ideal para aplicativos desenvolvidos para o uso com

19 17 o Kinect, portanto informações retiradas de livro foram apenas sobre a abordagem básica que deve ser verificada quanto à construção de interface em geral. Para encontrar as ferramentas que auxiliam na etapa de captura do esqueleto através do Kinect, foram analisados diversos artigos com trabalhos similares que especificam o tipo de ferramenta utilizada para desenvolver aplicações com o Kinect. Assim, foram identificadas as três principais: OpenKinect (OPENKINECT, 2011), OpenNI (PRIMESENSE, 2011; OPENNI, 2011) e Kinect for Windows SDK (MICROSOFT RESEARCH, 2011; WEBB; ASHLEY, 2012). Para conhecer suas funcionalidades foi acessado o site oficial de cada uma e verificada a documentação disponível. No site do OpenNI e do OpenKinect foi possível analisar as funcionalidades facilmente, já no site do Kinect for Windows SDK não existem muitas informações. As funcionalidades disponíveis do Kinect for Windows SDK foram encontradas no livro Beginning Kinect Programming with the Microsoft Kinect SDK onde foi possível analisar os pontos positivos e negativos deste framework. Depois de analisar as ferramentas, foi necessário encontrar uma estrutura de armazenamento adequado para os dados utilizados no software. Para encontrá-los foi necessário pesquisar os tipos de armazenamento de dados mais simples para o tipo de dado textual, e os mais simples encontrados foram o arquivo de texto e o XML (Extensible Markup Language). Analisando os documentos encontrados na internet, foi possível verificar qual deles é mais organizado e fácil de usar. O próximo passo para definir conceitos do software, foi pesquisar sobre métodos de comparação entre poses capturadas pelo Kinect, para isso foram analisados diversos trabalhos similares que apresentam diferentes soluções para este problema. Cada método encontrado foi detalhado e analisado para descobrir qual é o mais adequado à proposta do software. Com todos os itens anteriores analisados e definidos foi possível construir a modelagem do software, definindo com que ferramentas ele será desenvolvido, que estrutura de armazenamento será usada, qual o método de comparação das poses capturadas e que tipo de feedback será fornecido aos usuários, focando bastante no auxílio à realização da pose. Para desenvolver o software foi utilizada a linguagem C# em conjunto com a Kinect for Windows SDK. No módulo de captura foi desenvolvido o algoritmo para tratar os pontos capturados pelo Kinect, e calcular os ângulos que são armazenados na estrutura XML. Também foi desenvolvido um algoritmo que faz uma série de verificações e altera os valores

20 18 do limite superior e inferior do ângulo armazenado, para que seja possibilitado um aumento na precisão quando ocorrer a comparação de ângulos. Para o módulo de comparação de ângulos foi desenvolvido um algoritmo que possa calcular a diferença entre os ângulos de uma postura já armazenada e uma nova postura que está sendo realizada em tempo real. Foram desenvolvidas algumas maneiras de auxiliar o usuário a realizar a pose corretamente. O software foi testado por 3 pessoas que não fizeram parte do desenvolvimento para verificar se os objetivos foram cumpridos. As pessoas salvaram uma pose, e tentaram executála em um momento posterior. Com os testes realizados foi possível identificar algumas dificuldades na movimentação da mão seletora, no comando de voz e na comparação entre ângulos. Após os testes foram modificados alguns algoritmos para melhorar os itens onde houve dificuldade de utilização. 1.4 Estrutura do Trabalho Este documento está estruturado em quatro capítulos: Capítulo 1: Introdução: apresenta uma visão geral do trabalho. Capítulo 2: Fundamentação Teórica, na qual é apresentada uma revisão bibliográfica sobre trabalhos similares, métodos de armazenamento de dados, algoritmos que efetuam a comparação entre poses, ferramentas que possibilitam a captura de dados do Kinect, assim como uma análise a respeito de qual ferramenta será utilizada para desenvolver o software, qual o método de armazenamento de dados que será utilizado e qual método de comparação de poses é mais adequado. Capítulo 3: Apresenta o projeto detalhado do sistema desenvolvido, incluindo sua especificação e a sua modelagem em UML. O capítulo também discute como foi implementado o sistema proposto, apresentando a metodologia utilizada no desenvolvimento, dificuldades que surgiram durante o desenvolvimento, e resultados de testes. Capítulo 4: É apresentada a conclusão, na qual é abordado o resultado do desenvolvimento do software, dificuldades encontradas e trabalhos futuros.

21 19 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo tratará dos seguintes temas: Interface Humano Computador, Microsoft Kinect, Frameworks, Armazenamento de dados, Trabalhos Similares e Técnicas de comparação de poses. Para o desenvolvimento do software deve ser estudado como funciona a interface humano computador a fim de planejá-la de maneira mais agradável possível ao usuário, como o software irá comunicar-se com o Kinect, é necessário estudá-lo, assim como os frameworks que permitem a interação com ele. O software proposto necessita do armazenamento de dados para funcionar adequadamente, por isto é necessário que sejam avaliadas as estruturas de armazenamento de textos mais simples, mas que também ofereçam uma certa organização. Trabalhos similares serão analisados para tomar conhecimento do que já foi criado e o que pode ser reaproveitado para o desenvolvimento do software proposto assim como serão analisadas as técnicas de comparação existentes e que já foram utilizadas em outros projetos. 2.1 Interação Humano Computador Segundo Lima (2006), o computador necessita uma interface para que as pessoas possam comunicar-se com a linguagem de máquina. Essa interface que realiza a comunicação sempre busca a forma mais natural de interação humana para que estes possam trabalhar com o computador da maneira mais agradável possível. A interface é muito importante, pois é ela que proporciona: A satisfação que o usuário sente durante sua experiência com o computador; A eficiência, pois com uma boa interface o usuário será muito mais eficiente em seu serviço; A segurança, pois o usuário não terá acesso a comandos que possam causar estragos; Entre outras características. O termo interface foi criado em 1880, e a indústria computacional começou a utilizá-la em 1960 significando a interação entre um computador e outra entidade, que normalmente são operadores humanos ou outros dispositivos. Em 1970 pesquisadores

22 20 começam a se preocupar com estudos sobre a interface criando assim o termo IHC (Interface Humano Computador) (REBELO, 2012). A era da computação em lote ainda não utilizava interface gráfica e linha de comando, o poder de processamento computacional era inteiramente focado em uma atividade específica, ou seja, quando uma tarefa era iniciada o computador utilizava todos seus recursos para entregar o resultado. O modo que acontecia a entrada de dados era por cartão perfurado, e a saída era feita por impressoras. Não era possível uma interação em tempo real, uma tarefa só poderia ser executada caso a anterior já estivesse concluída (OLIVEIRA, 2010 ). Após a computação em lote, surgiu a interação por linha de comando, ela é baseada em uma série de pedidos e respostas escritos em uma linguagem de comando. Com esta tecnologia o tempo de resposta tornou-se bem menor que o da computação em lote, quase em tempo real, mas um problema ainda não havia sido solucionado: a dificuldade de aprendizado da linguagem e o esforço para utilizá-la. Apesar do problema de aprendizado e esforço, ela ainda é uma das mais ágeis, por isso continua sendo usada em configuração de roteadores, servidores e alguns sistemas operacionais onde não há preocupação com a usabilidade. Com o passar do tempo, computadores começaram a ganhar capacidade de exibir gráficos e com isso surgiu a necessidade do uso de um dispositivo que pudesse manipular as informações na tela, o mouse e o teclado. Este tipo de interação foi chamado de GUI (Graphical User Interface) e é até hoje o modelo de interação mais utilizado, marcado pelo conceito de janelas o qual está presente na maioria dos dispositivos computacionais (OLIVEIRA, 2010 ) Computação Ubíqua Segundo Weiser(1991), Araújo(2003) e Santos(2009) a computação tende a tornar-se ubíqua, ou seja, tornar-se imperceptível, indistinguível para os usuários, sendo assim, parte do cotidiano. Ela representa uma evolução na área de tecnologia da informação, devido ao seu paradigma, os sistemas pretendem coletar informações dos ambientes onde estão presentes e utilizar estas informações dinamicamente para os modelos computacionais embutidos, ou seja, controlar, configurar e ajustar a aplicação para melhor uso e necessidades do usuário. O foco que costumava estar na interface passa a estar em novos desafios ou objetivos.

23 21 Para que seja possível a computação ubíqua, é necessário um novo conceito de interface, que não se preocupe apenas com a manipulação dos dados na tela e sim como estes dados são manipulados, focando em formas diferentes e criativas para capturar os dados de entrada e fornecer os dados de saída Interface Natural para o Usuário Com a computação ubíqua é possível identificar um novo tipo de interface mais natural que a metáfora do desktop do computador pessoal, possibilitando que a relação entre o homem e o computador possa tornar-se cada vez mais parecida com as ações dos humanos no mundo real, no dia-a-dia. Para isso são usados gestos, movimentos, comando de voz, expressões e a visão de um mundo pela manipulação de objetos físicos (SOARES, 2011). As interfaces naturais são as interfaces presentes nos dispositivos de computação ubíqua, através delas o usuário controla de forma tão natural que esse controle é transparente. Uma interface é natural se ela faz uso das mesmas ações que o usuário utiliza para interagir com o mundo durante a vida (BUXTON, 2010). Por ser uma interface natural ao ser humano, ela deve ser de simples e de rápido aprendizado, assim como também deve adaptar-se aos movimentos do corpo humano. O aprendizado pode ser realizado através da observação da demonstração do uso por outra pessoa com poucas repetições (BLAKE, 2011). Com o surgimento de diferentes tipos de interação, surgem novas necessidades e problemas. Já que a entrada de dados é bem diferente da tradicional, são necessários dispositivos que possam capturar esses novos tipos de dados, e novas ferramentas capazes de desenvolver aplicativos que funcionem de acordo com a interface natural. Deverão ser formados novos meios de tratamento de erros, pois da mesma maneira que os dados de entrada serão diferentes do padrão, os dados de saída também o serão (PORTELLA, 2008). Netto (2004) afirma que para uma interface ser eficiente o designer precisa escolher as ações e comando das funções para interação com o sistema mais indicado. É preciso escolher os elementos para representação de interface mais significativos a fim de transmitir a informação desejada, e as opções de feedback mais representativas possível, pois quanto menor for a diferença entre a linguagem de interface e a necessidade do usuário, mais ele poderá alcançar seu objetivo com o menor esforço cognitivo possível.

24 22 Segundo Paula (2011), atualmente existem alguns exemplos de interfaces naturais que já estão em uso na área de jogos, as quais seriam: o Wiimote, Playstation Eye Toy Camera, Genesis Activator e tapetes de dança. Fora da área de jogos ainda existem os trabalhos de realidade aumentada, na qual objetos virtuais aparecem em conjunto com objetos existentes no mundo real, reaproveitando o ambiente que rodeia o usuário e complementando-o com gráficos computacionais (Azuma, 2011). A interface entre computador e humano evoluiu bastante com o surgimento do Kinect, já que o dispositivo elimina a necessidade do uso de qualquer controle físico. Através dele o ser humano pode agir normalmente em frente a uma câmera que captura a posição x, y e z de um conjunto de pontos que representam as articulações mais importantes do corpo humano: cabeça, mãos, cotovelos, pernas, entre outros (PAULA, 2011). Segundo Webb e Ashley (2012), o desafio que o Kinect superou foi de transformar o vulto de uma pessoa em algo que pudesse ser rastreado. O problema inicial era quebrar o vulto fornecido pelo fluxo de dados de profundidade em partes do corpo reconhecíveis. Destas partes, articulações podem ser identificadas, e destas articulações, um esqueleto pode ser reconstruído. Shotton, Andrew Fitzgibbon e Andrew Blake chegaram a um algoritmo que poderia distinguir 31 partes de corpo, conforme mostra a Figura 1 Destas partes a versão do Kinect demonstrada na E3 em 2009 podia reproduzir 48 articulações. Figura 1. Representação da divisão das partes do corpo Fonte: Webb e Ashley (2012). Com os recursos oferecidos pelo Kinect é possível criar uma série de inovações de interação com o usuário, serviços e aplicações computacionais. Com o aparecimento do

25 23 Kinect foram criadas novas abordagens da captação dos dados de entrada para a comunicação com o computador. Esses dados capturados terão sua interpretação computacional influenciada pelo histórico das ações do usuário, ou até mesmo pelo modo que ele os projeta, já que eles vêm de uma interação natural com o mundo real (NUNES et al, 2011). A interação com o usuário é tão grande que o usuário pode se sentir dentro do jogo. O Kinect utiliza da computação ubíqua tanto na transparência do controle do usuário quanto na integração com as tecnologias já existentes (SOARES, 2011). 2.2 Microsoft Kinect Paula (2011) explica que o Kinect é formado por um projetor de luz infravermelha, que não pode ser visto ao olho humano, uma câmera infravermelha, uma câmera RGB comum, um conjunto de microfones e um motor. Atualmente já existem duas versões deste dispositivo, uma que é usada em conjunto ao console XBOX, que para ser usada com um computador tradicional necessita de um cabo especial de alimentação, a outra já possui este cabo integrado e sua interface de dados é via USB (Universal Serial Bus) e não é criptografada, o que facilita bastante sua utilização fora do XBOX. Figura 2. Composição do Kinect Fonte: Paula (2011). O desenvolvedor pode utilizar os seguintes dados retirados do Kinect: Fluxo de cores imagem: onde cada pixel representa uma cor, a resolução pode ser de 640x480 pixels com 30 imagens por segundo ou 1280x1024 com no

26 24 máximo 15 imagens por segundo. Existe a possibilidade de obter tanto a imagem da câmera RGB quando a da câmera infravermelha; Fluxo de profundidade: onde cada pixel indica a distância entre o ponto em questão e o aparelho. É possível detectar cerca de 2000 níveis de sensibilidade e são percebidos os objetos posicionados de 1,2 a 3,5 metros à frente do aparelho. Além dos dados de profundidade é possível verificar com exatidão se o pixel faz parte do corpo de um ser humano. O Kinect consegue diferenciar até 6 corpos humanos em sua detecção; Fluxo de áudio: Através do conjunto de quatro microfones, e um sistema de anulação de ruído e eco, o Kinect pode gravar o áudio e reconhecer comandos de voz em inglês. Com a captura dos dados do sensor de profundidade e comando de voz em jogos e aplicativos, é possível proporcionar uma interface mais natural aos jogadores e usuários. O sensor de profundidade obtém com exatidão a distância de objetos em relação ao sensor, ele não se baseia em princípio estereoscópico como as câmeras tradicionais de profundidade, um padrão infravermelho é projetado e a deformação neste é medida, permitindo a inferência da distância. O Kinect não se limita em apenas informar a distância de um objeto em relação ao sensor, ele obtém informação do esqueleto de até dois jogadores simultâneos, cada esqueleto possuindo 20 pontos de articulação, disponibilizando a posição x, y e z de cada uma delas Seleção e Feedback A análise visual feita pelo Kinect é impressionante, mas ainda não é hábil o suficiente para lidar bem com a coordenação motora, fazendo com que usuários acabem selecionando acidentalmente opções que não desejam acessar. Na transição de paradigmas de interface com o usuário de aplicações controladas por linha de comanto para aplicações com guias, de interface gráfica utilizando mouse para interface natural com touchscreen cada interface sempre providenciou um fácil comando para a ação de seleção. E ainda, cada tecnologia de interface de usuário nova que surgiu, aumentou a habilidade em selecionar coisas, já o Kinect não seguiu o mesmo curso.

27 25 A seleção acabou tornando-se uma das ações mais complicadas na utilização do Kinect. O problema para realizar um ato de seleção com o Kinect pode ser resolvido de forma relativamente fácil pela combinação de reconhecimento de comando de voz com o rastreamento de esqueleto para criar um gesto híbrido: fala e gesto (WEBB; ASHLEY 2012). Sarter (2006) discute sobre o problema do feedback de dados, pois se uma interface natural é transparente no cotidiano do usuário, o feedback será uma interferência na normalidade da aplicação. Logo ele deve ser configurado para que seja o mais verossímil possível. 2.3 Frameworks de Desenvolvimento Segundo Paula (2011), quando o Kinect foi lançado já havia a possibilidade de desenvolver jogos e aplicativos para computador, pois foi lançado um concurso aberto ao mundo. O produtor de kits eletrônicos Adafruit Industries lançou uma iniciativa no dia do lançamento do Kinect oferecendo mil dólares para a primeira pessoa que conseguisse desenvolver um aplicativo que fizesse a interação entre o Kinect e um computador. Como a Microsoft anunciou que não apoiaria modificações não autorizadas ao Kinect, o valor aumentou para dois mil dólares, e após um tempo para três mil dólares para quem criasse tal aplicativo. Poucos dias depois foi apresentado um aplicativo que criou a interação entre o Kinect e um computador com o uso de um analisador de USB (GILES, 2010). Assim surgiu uma comunidade chamada OpenKinect que disponibilizou um conjunto de drivers livres para o Kinect (OPENKINECT, 2011). O framework utilizado neste projeto será o Kinect for Windows SDK, por este motivo ele será mais explorado do que os demais OpenNI A fabricante do sensor que serviu de base para a criação do Kinect, PrimeSense, resolveu disponibilizar o código de seu próprio driver e framework juntamente com o módulo de rastreamento de esqueleto (PRIMESENSE, 2011). A PrimeSense resolveu criar uma iniciativa chamada OpenNI, que é uma organização sem fins lucrativos, disponibilizando uma API (Application Programming Interface Interface de Programação de Aplicativos) para desenvolver aplicações para dispositivos utilizando interação natural (OPENNI, 2011). A API

28 26 é utilizada como uma camada intermediária entre os dispositivos de nível baixo, como câmeras, microfones, sensores, e soluções middleware de nível alto, como por exemplo algoritmos de visão computacional. A OpenNI e a OpenKinect são abordagens abertas e gratuitas, não possuem restrição de uso ou licença com restrições muito amplas, e possuem versões para Windows, MacOS e Linux. É possível trabalhar com as linguagens, C, C++, Java, C# e Processing. O Kinect for Windows SDK é gratuito, mas é limitado a aplicações não comerciais Funcionalidades básicas As principais funcionalidades básicas são: Profundidade e cor: Com um gerador de profundidade, o OpenNI permite a captura de imagens com informações sobre a profundidade de cada pixel em relação a distância do dispositivo, e permite também que esses valores possam ser alterados e utilizados como dado de saída, imprimindo as imagens modificadas, o Quadro x exemplifica a criação de um gerador de profundidade; Manipulação de esqueleto: O OpenNI disponibiliza funções que permitem a identificação de um novo usuário; ele espera que este usuário realize uma pose específica, e calibra o mesmo enquanto ele está realizando a pose para conseguir rastreá-lo. Especificamente ele informa a localização da cabeça do usuário enquanto ele é rastreado; Rastreamento de mãos: Possui funções que procuram por gestos de mão, e quando o gesto for identificado, começa a rastrear a mão identificada; Geradores de áudio: Acumulam dados até que uma chamada de função é realizada, então todo o áudio acumulado em buffer é retornado para a aplicação. O tamanho do buffer de áudio pode variar de uma chamada para outra, e a aplicação deve sempre chamar uma função para saber qual o tamanho do buffer atual Gravação de Dados Para gravar dados, uma aplicação deve criar um nodo de gravação, e especificar o destino. A aplicação deve adicionar ao nodo de gravação, todo objeto que ela quer gravar.

29 27 Quando um objeto é adicionado ao nodo de gravação, ela lê a sua configuração e então o grava. Ela também registra todos os eventos possíveis ao nodo, para que, quando houver alguma mudança de configuração, esta também seja gravada. Quando todos os objetos forem adicionados, a aplicação pode ler os dados de cada um e gravá-los através de uma função. Para gravar dados usando XML, o processo é semelhante, é necessário adicionar um nodo no arquivo XML para realizar o papel de gravador e adicionar os objetos neste nodo Executar Dados Salvos Para executar um arquivo salvo, basta executar uma função e o OpenNI abre um arquivo, cria um nodo para cada nodo existente no arquivo, e preenche estes nodos com a configuração gravada. Uma função retorna os nodos necessários do arquivo salvo, para poderem ser manipulados. Nodos criados pelo jogador são bloqueados e não podem ser alterados, então a configuração deve continuar de acordo com as configurações salvas. Aplicações que inicializam OpenNI usando um arquivo XML podem facilmente alterar os dados de entrada, isso significa que ao invés de ler de um dispositivo em tempo real, é lido de uma gravação substituindo os nodos em um arquivo XML com um elemento de gravação. Podem existir vários tipos de nodo, os mais utilizados são: O nodo de imagem, que é configurado para usar uma saída QVGA (Quarter Video Graphics Array) de 60 imagens por segundo, com um formato de RGB de 24 pixels. Ele também pode espelhar uma área selecionada; O nodo de profundidade, que é configurado para utilizar uma saída VGA (Video Graphics Array) de 30 imagens por segundo. Ele também define a posição do usuário; O nodo de áudio, que é configurado para ser amostrado em Hz, no modo stereo e com 16bit por amostra.

30 28 xn::depthgenerator depth; nretval = depth.create(context); XnMapOutputMode outputmode; outputmode.nxres = 640; outputmode.nyres = 480; outputmode.nfps = 30; nretval = depth.setmapoutputmode(outputmode); nretval = context.startgeneratingall(); while (bshouldrun){ nretval = context.waitoneupdateall(depth); if (nretval!= XN_STATUS_OK){ printf("failed updating data: %s\n", xngetstatusstring(nretval)); continue; } const XnDepthPixel* pdepthmap = depth.getdepthmap(); } Quadro 1. Exemplo de código para criar um gerador de profundidade Kinect for Windows SDK Em 2011, a Microsoft disponibilizou sua própria ferramenta gratuita de desenvolvimento para o Kinect, e sem licença comercial, ou seja, limitado a aplicações não comerciais (MICROSOFT RESEARCH, 2011). Com o Kinect for Windows SDK, é possível desenvolver nas linguagens C++, C# e VisualBasic e, do mesmo jeito que as plataformas abertas, disponibiliza o acesso a informações das câmeras do sensor e ao rastreamento de esqueleto, mas também permite que os desenvolvedores utilizem o reconhecimento de fala em seus aplicativos Identificação do Sensor Uma aplicação só poderá rodar corretamente se o status do dispositivo seja Connected, por este motivo a aplicação deve monitorar os status e agir apropriadamente conforme a mudança de status Fluxo de Cores das Imagens Para trabalhar com o fluxo de cores das imagens, é efetuado um processo com três passos: primeiro o fluxo deve ser ativado, no segundo a aplicação deve extrair dados de imagem do fluxo, e por último a aplicação pode processar os dados da imagem. Os últimos dois passos continuam rodando enquanto existir dados de imagem disponíveis (WEBB; ASHLEY, 2012).

31 29 O valor retornado das imagens é de dados de pixel no formato de vetores de bytes. Esses bytes representam o RGB de cada pixel. O valor pode variar dependendo da escolha de que tipo de dados será adquirido, o que pode ser determinado pela funcionalidade ColorImageFormat. Conforme Quadro 2. ColorImageFormat Undefined RgbResolution640x480Fps30 RgbResolution1280x960Fps12 YuvResolution640x480Fps15 RawYuvResolution640x480Fps15 Quadro 2. Resoluções e formatos que podem ser utilizados Fonte: Webb e Ashley (2001). Significado A resolução da imagem é indeterminada. A resolução da imagem é 640x480, os dados do pixel são de formato RGB32 a 30 imagens por segundo. A resolução da imagem é 1280x960, os dados do pixel são de formato RGB32 a 12 imagens por segundo. A resolução da imagem é 640x480, os dados do pixel são de formato YUV a 15 imagens por segundo. A resolução da imagem é 640x480, os dados do pixel são de formato YUV em estado natural a 15 imagens por segundo. No formato RGB32 significa que são utilizados quatro bytes por pixel, o primeiro representando o canal azul, o segundo o verde, o terceiro o vermelho e o quarto determina a transparência ou a opacidade do pixel Fluxo de Profundidade das Imagens Diferente do OpenNI e OpenKinect a SDK oficial não provê o acesso aos dados brutos do fluxo infravermelho, ao invés disso ela processa os dados infravermelhos e produz uma imagem de profundidade. Trabalhar com a imagem de profundidade é semelhante com a de RGB. O valor de profundidade de cada pixel mapeia uma distância física no campo de visão, e é representado por 16 bits. O valor da profundidade está presente nos 13 primeiros bits, pois os outros três estão destinados ao identificador do jogador, logo, é necessário aplicar uma máscara de bits para obter o valor (WEBB; ASHLEY, 2012).

32 30 Figura 3. Bits que representam profundidade e identificação do jogador Fonte: Webb e Ashley (2012). Caso o valor de profundidade seja zero, quer dizer que o Kinect não conseguiu determinar a profundidade do pixel, na maioria das vezes o valor zero deve ser tratado como um objeto muito próximo do Kinect (WEBB; ASHLEY, 2012). O SDK tem uma funcionalidade que analisa os dados de profundidade e detecta o formato do jogador, conforme a Figura 4, podendo detectar até seis jogadores. É possível descobrir quais bits são referentes a um jogador. Figura 4. Representação do jogador adquirida através dos bits Fonte: Webb e Ashley (2012). Os dados de profundidade permitem uma fácil filtragem de pixels que não pertencem ao jogador. Informações irrelevantes como a cor e a textura das roupas do jogador também são filtradas pelos dados da câmera de profundidade. O que resta é basicamente um vulto do jogador representado por posições de pixels. Os dados da câmera de profundidade também

33 31 fornecem informações sobre a altura e largura do jogador em metros (WEBB; ASHLEY, 2012) Rastreamento de Esqueleto O rastreamento do esqueleto se dá através do processamento da profundidade das imagens estabelecendo a posição de várias articulações de esqueleto de uma forma humana, ele disponibiliza a posição x, y e z de cada articulação. O dado proveniente do rastreamento do esqueleto vem separado em 20 articulações, que são ilustradas na Figura 5, e cada uma delas é um objeto com uma identificação, que no caso é o nome da articulação, e um vetor 3D que disponibiliza a posição x, y e z da articulação em metros da distância entre o esqueleto e o sensor (WEBB; ASHLEY, 2012). Figura 5. Pontos do esqueleto acessíveis através do Kinect for Windows Fonte: Webb e Ashley (2012) Reconhecimento de Voz O áudio é criado por quatro microfones separados e posicionados linearmente na parte de baixo do Kinect. Comparando quais microfones capturam o mesmo sinal de áudio, o grupo de microfones pode ser usado para determinar a direção de onde o sinal está vindo. Esta técnica também pode ser usada para fazer com que o grupo de microfones preste mais atenção

34 32 a um som de uma direção em particular do que de outra. Algoritmos podem ser aplicados ao fluxo de áudio capturado do grupo de microfones para efetuar efeitos sonoros complexos e para remover barulho ambiente irrelevante (WEBB; ASHLEY, 2012). A classe principal para trabalhar com o áudio é a KinectAudioSource. O propósito dela é capturar o fluxo bruto ou modificado do som do grupo de microfones. O fluxo de som pode ser modificado por uma variedade de algoritmos para ser melhorado, incluindo supressão de ruídos, controle automático de ganho e cancelamento de eco acústico. Ele também pode ser usado para configurar o grupo de microfones para trabalhar em diferentes modos e detectar a direção a qual o áudio veio, também podendo forçar o grupo de microfones em uma direção dada. O reconhecimento de fala é dividido em duas categorias: reconhecimento de comandos e reconhecimento de forma livre ditada. Ao invés de tentar reconhecer tudo o que é dito, o reconhecimento de comandos restringe o vocabulário a algumas palavras esperadas. Baseado em uma lista de comandos limitada, o reconhecimento de comandos é capaz de fazer hipóteses do que a pessoa está dizendo, sem precisar ser familiar com a sua voz. É adquirido o fluxo de áudio processado pelo sensor do Kinect e então a emissão vocal é analisada e interpretada como um comando reconhecido. São verificados os elementos de áudio, e se for decidido que o áudio contém elementos conhecidos, é passado para um evento e processado, caso o áudio não possua elementos conhecidos, aquela parte do fluxo de áudio é descartada. É necessário informar qual palavra que se espera ser pronunciada, incluindo a ordem da sentença OpenKinect O OpenKinect disponibiliza todo o código necessário para ativar, inicializar e fazer a comunicação de dados com o Hardware do Kinect, incluindo drivers e uma API que funciona no Windows, Linux e OS X. A API pode utilizar as seguintes linguagens e plataformas: C; C++;.NET(C#/VB.NET); Java(JNA e JNI);

35 33 Python; C Synchronous Interface. Não existe uma lista oficial das funcionalidades que estão dentro da biblioteca do OpenKinect, mas é possível informar que algumas funcionalidades analisam e abstraem dados brutos retirados do Kinect: Rastreamento das mãos; Rastreamento do esqueleto; Processamento de dados de profundidade; Reconstrução 3D; Entre outros. Na documentação do OpenKinect também é possível encontrar códigos de exemplo, demos e outras aplicações Comparação entre os Frameworks Pesquisados A Tabela 1 demonstra uma comparação entre os frameworks relacionada às funcionalidades que são necessárias para desenvolver o projeto. Tabela 1. Comparação entre Freameworks Framework OpenKinect OpenNI Kinect for Windows Acesso aos pontos x, y e Sim Sim Sim z do esqueleto Reconhecimento de comandos de voz Não Não Sim Todos os frameworks pesquisados disponibilizam acesso aos pontos x, y e z do esqueleto do jogador, mas apenas o Kinect for Windows fornece reconhecimento de comandos de voz, o que é importante para a fase de armazenamento de poses para o projeto e para ações de seleção de opções, por este motivo ele é o framework utilizado no desenvolvimento do projeto. 2.4 Armazenamento de Dados

36 34 Os dados obtidos pelo Kinect são números referente a posição X, Y e Z de articulações no corpo do jogador, esses dados serão tratados por um algoritmo que os transformam em ângulos. Para salvar estes números referentes aos ângulos das articulações é necessário uma estrutura de armazenamento de dados, e por serem dados numéricos simples, podem ser usadas soluções igualmente simples como XML e o arquivo texto comum. Segundo Minghim (2004), o arquivo de texto utiliza uma sequencia de caracteres para ser tratado como dado, permite que seja gravado qualquer sequencia de dados simples, que serão convertidos para caractere no processo de escrita. Com este tipo de documento não é possível acesso direto, o único controle admitido do ponteiro do arquivo é reinicializá-lo. Além do arquivo texto comum ainda existe o XML que é um tipo de arquivo um pouco mais elaborado, permitindo um nível maior de organização, seleção, edição e inserção de dados XML Segundo W3C (2012), XML é um formato de texto simples derivado do SGML (uma metalinguagem que possibilita definir linguagem de marcação para documentos). Criada a princípio para enfrentar os desafios de publicações eletrônicas de larga escala, ela também está desempenhando um papel cada vez mais importante na troca de dados extremamente variados pela Internet. Segundo Furtado Júnior (2012), um documento XML é basicamente uma árvore onde os nós externos possuem: dados de caracteres, instruções de processamento, comentário, declaração de uma entidade e outros nós. Um nó interno é um elemento que possui nome e conjunto de atributos. A Figura 6 demonstra uma árvore XML e o documento respectivo a ela.

37 35 (a) (b) Figura 6. (a) Representação de uma árvore de XML; (b) XML referente à árvore Geralmente a árvore possui um nó raiz acima do elemento raiz. O documento é um texto em formato Unicode, e possui tags de marcação seguidas de informações. 2.5 Técnicas de Comparação de Poses Podem ser usadas diferentes técnicas para reconhecer poses e gestos que são capturados pelo Kinect, podem ser usados os dados de profundidade, os dados de pontos de esqueletos e até mesmo os pixels referentes ao usuário. A pose é uma postura estática, então é necessário fazer uma verificação se duas posturas estáticas estão iguais ou semelhantes, já o gesto depende de fatores como tempo de execução, transição entre poses, então ele não será abordado, já que o software proposto se trata da comparação entre poses e não gestos Técnica Algorítmica Segundo Sá (2011), a técnica algorítmica identifica o gesto através de um algoritmo que especifica exatamente como esse gesto é realizado. É definida uma sequência temporal onde deve ser realizada uma sequência de poses. Um exemplo é o aceno de mão, o algoritmo deverá verificar se: a mão está acima do cotovelo e na frente do ombro, se ela está se movendo na mesma direção e em certa velocidade, e também se a quantidade de vezes que aconteceu a mudança de direção é a necessária. Para ser usada a fim de reconhecer apenas uma pose, basta definir qual a posição das articulações esperada para reconhecer a pose sem utilizar uma sequência temporal. Um

38 36 exemplo de pose a ser reconhecida é um braço levantado, o algoritmo deve verificar se a mão está levantada acima da cabeça e se o cotovelo está acima do ombro através de comparações com os pontos e relação ao eixo y, conforme Figura 7. Figura 7. Imagem ilustrando a relação dos pontos y em um braço levantado A técnica algorítmica só funciona para gestos já definidos anteriormente, mas ela possui as vantagens de fácil entendimento, implementação e teste. Porém a escolha de valores para os parâmetros é crucial para a sensibilidade do reconhecimento do gesto, e pode tornar-se uma escolha difícil de acordo com a complexidade do gesto. Por este motivo ela é uma técnica mais recomendada para reconhecimento de gestos simples Matching O Matching define o gesto de acordo com animações, ou apenas bitmaps no caso de poses, gravadas anteriormente, diferentes pessoas devem executar o gesto diversas vezes para poder se chegar a um parâmetro aceitável, na utilização de uma pose basta executar apenas a pose ao invés de um gesto. Essa técnica é ideal para comparar um gesto ou pose com outro, e para isso são usadas bitmaps dos esqueletos e comparados. Na comparação de imagens devese definir uma métrica de erros para a posição dos esqueletos, e então calcular a diferença angular para cada articulação deles. São utilizados classificadores como Dinamic Time Warping e o Modelo oculto de Markov para definir quais imagens melhor correspondem ao gesto desejado (SÁ 2011). A Figura 8 demonstra uma pessoa fazendo a mesma pose diversas vezes, e cada gravação possui uma pequena diferença entre os ângulos, o valor a ser

39 37 armazenado como representação da pose será uma média calculada entre os ângulos e será definida uma métrica de erros para reconhecimento. Figura 8. Exemplo de uma mesma pose executada com pequenas diferenças nos ângulos A vantagem desta técnica é que ela pode definir gestos complexos com facilidade, e reconhecer variações deles, mas requer muitos execuções da pose para ser aceitável, pois quanto mais comparações com novas pessoas realizando gestos, mais correto será o reconhecimento dos futuros gestos, e quanto maior o número de comparações a se fazer mais processamento e memória é exigido do computador. Por este motivo esta técnica é recomendada apenas para o reconhecimento de gestos mais complexos (SÁ, 2011) Comparação de Ângulos Segundo Silveira (2011), a técnica de comparação de ângulos utiliza o fluxo de profundidade gerado, ela é ideal para ser utilizada em uma pose estática. Com o fluxo de profundidade, detectam-se as posições do esqueleto, seus segmentos e articulações. Calcula-se o ângulo formado pelo segmento entre dois pontos, e com esse valor, executa-se a ação definida ou não. Os pontos de esqueleto adquiridos pelo Kinect são tridimensionais, para se trabalhar com apenas dois eixos o terceiro deve ser descartado utilizando a projeção ortográfica, a qual representa a visualização de um objeto tridimensional sendo observado pela vista frontal, lateral ou superior (MACHADO, 2002).

40 38 Para facilitar o uso das coordenadas, elas devem ser normalizadas com valores de 0 a 1, e a variável Y invertida para considerar o canto inferior esquerdo com o ponto de origem do sistema de coordenadas e evitar números negativos. É criada uma função para calcular o ângulo formado por dois pontos, dadas as suas coordenadas, e deve retornar um valor de 0 a 359, e outra função para verificar se um ângulo está entre dois outros ângulos dados, que retorna um valor booleano. A cada imagem capturada pelo Kinect, é analisada a estrutura do esqueleto apenas nos eixos X e Y em busca das coordenadas que possuem os valores das articulações. Ao serem encontradas, é verificado se o ângulo formado por estas articulações está dentro da região definida como aceitável, caso ele estiver, é ativada uma variável booleana referente àquela articulação, e no momento que o ângulo sai da região aceitável a variável é desativada. Quando todas as variáveis referentes às articulações desejadas estiverem ativadas, então a pose está sendo executada. Um exemplo é um usuário tentar realizar uma pose onde os dois braços devem estar levantados, enquanto os braços estiverem abaixados, o ângulo referente a articulação dos ombros estará fora do limite definido como "braços levantados", se ele levantar um dos braços, o ângulo do ombro deste estará marcado como correto, mas o do outro braço ainda estará marcado como fora do limite. Quando todos os ângulos do corpo do usuário estiverem dentro do limite que o aplicativo reconhece como correto, então o usuário alcançará o objetivo da realização da pose. A Figura 9 mostra que o ângulo referente a um dos ombros na pose atual está marcando 250, e na pose armazenada está marcando 100º. O ângulo do ombro da pose atual está fora do limite do ângulo armazenado, supondo que o limite seria aproximadamente 15º, então a pose atual não deveria marcar mais do que 115º.

41 39 Figura 9. Pose Atual do jogador comparada com a pose armazenada Comparação de Pixel Segundo Webb e Ashley (2012), a SDK oficial permite identificar quais pixels pertencem a um ser humano, então é possível rastrear a imagem e identificar onde ele está, assim como salvar imagens antigas e verificar onde um jogador estava antes e para onde ele se moveu na imagem seguinte, identificando assim um movimento. Em aplicações e jogos que envolvem realidade aumentada é possível verificar colisões com os objetos virtuais através da verificação dos pixels que pertencem ao jogador com os pixels que pertencem aos objetos virtuais, se a posição coincidir quer dizer que está acontecendo uma colisão, conforme representa a Figura 10.

42 40 Figura 10. Exemplo de uma pessoa entrando em colisão com uma bola virtual Análise das Técnicas de Comparação de Gestos Pesquisadas A Tabela 2 faz uma análise dos pontos positivos e negativos entre as técnicas de comparação de gestos. Tabela 2. Técnicas de comparação de gestos Técnica Vantagem Desvantagem Técnica Algorítmica Simples implantação e entendimento É usada para gestos prédefinidos Matching Reconhecimento de gestos e posturas genéricos Precisa que o usuário realize o gesto ou pose diversas vezes para se chegar a uma Comparação de ângulos Comparação de pixel Reconhecimento de gestos e posturas genéricos Identifica a posição e movimento do usuário, podendo também identificar colisões com objetos virtuais média aceitável e salvá-la O limite de aceitação do ângulo utilizado pode não ser adequado para a comparação Identifica apenas o vulto do usuário, e não seu esqueleto e posição A técnica algorítmica pode ser utilizada para gestos simples como troca de páginas, pausar a aplicação e seleção de botões, mas não pode ser usada para comparar poses genéricas, para esta função, a técnica mais indicada é a comparação de ângulos, a qual permite que uma pose possa ser adquirida com apenas uma execução. A comparação de ângulos ainda pode ser utilizada em conjunto com a técnica matching, podendo calcular uma nova média de aceitação com novas execuções. A comparação de pixel poderia ser utilizada

43 41 para a seleção de botões, já que para um botão ser selecionado é necessário verificar se houve colisão entre a mão do usuário e o objeto virtual do botão, mas como ela não realiza diferenciação entre a mão e o restante do corpo, ela não é a mais indicada para esta ação. Para o desenvolvimento do projeto foi escolhida a técnica de comparação de ângulos com duas adaptações: a posição Y das articulações não é invertida, e as coordenadas não são normalizadas com valores de 0 a 1. Para resolver o problema de valores negativos será utilizado o valor absoluto das coordenadas. 2.6 Análise de Feedback Foram pesquisados diversos jogos e o modelo de feedback utilizado por cada um deles. Os jogos pesquisados foram: Kinect Adventures, Dance Central, Your Shape, Zumba e Just Dance. O Kinect Adventures utiliza um modelo 3D que realiza os movimentos conforme os pontos capturados do jogador, imitando assim seus movimentos. Os feedbacks que ele apresenta ao jogador são apenas para que ele se posicione na área de captura do Kinect, quando ele está muito perto do sensor, ele mostra um aviso em vermelho nos cantos superiores da tela avisando que o jogador está perto e ele deve se afastar, e seu personagem começa a piscar, conforme Figura 11. (a) (b) Figura 11. (a) Aviso de proximidade; (b) Personagem piscando Para a seleção o Kinect Adventures posiciona uma imagem de mão na posição da mão do jogador, e quando esta mão está posicionada em cima da opção um tempo começa a correr, e quando ele acaba quer dizer que o jogador selecionou esta opção.

44 42 O Dance Central utiliza um vulto 2D para representar os movimentos do jogador, que fica posicionado de maneira bem discreta, e um personagem 3D é apresentado para que o jogador saiba quais movimentos deve fazer. Para o feedback, o jogo identifica quais membros que não estão sendo movimentados corretamente e cria um contorno vermelho em volta do membro correspondente no personagem 3D, conforme Figura 12. Quando o movimento é realizado corretamente, um círculo verde e brilhante aparece em volta do personagem 3D. Figura 12. Jogador executando um movimento incorretamente Para a seleção o jogador deve posicionar seu braço direito esticado para o lado e movendo-o para cima e para baixo ele pode mudar de uma opção para outra, e puxando o braço para o lado esquerdo é como acontece a seleção da opção. O Your Shape utiliza uma representação do próprio jogador para que ele possa visualizar como está realizando os movimentos. Na maioria das vezes o feedback de que o jogador está fazendo o movimento corretamente é quando as bolinhas localizadas no canto superior direito se transformam em visto, e quando o jogador errou a bolinha não se transforma em nada, conforme Figura 13. Algumas vezes aparece um esqueleto na representação do jogador, e quando ele está todo verde quer dizer que o jogador está realizando o movimento corretamente, caso algum segmento fique branco, significa que aquele segmento do corpo do jogador está posicionado de forma errada, conforme Figura 14.

45 43 Figura 13. Um jogador não realizando os movimentos (a) (b) Figura 14. (a) Jogador realizando movimentos corretamente; (b) Jogador errando uma parte do movimento Para a seleção de opções, o Your Shape utiliza uma representação apenas da mão real do jogador em forma de vulto, quando a mão está posicionada em cima da opção, o jogador deve empurrar a mão para frente para selecioná-la, como se estivesse apertando um botão. O Zumba utiliza um vulto 2D muito semelhante ao Dance Central, e também utiliza um personagem em 3D que representa os movimentos a serem realizados. Diferente do Dance Central ele não faz o contorno vermelho em volta do membro que está realizando o movimento errado, ele possui uma barra que apresenta o feedback do movimento, quando o movimento esta errado a barra pisca em vermelho, quando está correto ela lança elogios como Hot, Zumba entre outros, conforme Figura 15.

46 44 (a) (b) Figura 15. (a) Jogador acertando o movimento; (b) Jogador errando o movimento Para a seleção é utilizado um sistema quase idêntico ao Kinect Adventures, o Zumba posiciona uma imagem de mão na posição da mão do jogador, e quando esta mão está posicionada em cima da opção um tempo começa a correr, e quando ele acaba quer dizer que o jogador selecionou esta opção. O Just Dance utiliza um vulto 2D muito semelhante ao Dance Central, e Zumba, e também utiliza um personagem em 3D que representa os movimentos a serem realizados. Para informar ao jogador se ele acertou, aparecem as palavras Ok, Perfect, entre outros. Quando o jogador erra, aparece um x vermelho, conforme Figura 16. Figura 16. O jogador da esquerda está errando e o jogador da direita acertando Para a seleção, é utilizado um sistema igual ao do Dance Central, o jogador deve posicionar seu braço direito esticado para o lado e movendo-o para cima e para baixo ele pode

47 45 mudar de uma opção para outra, e puxando o braço para o lado esquerdo é como acontece a seleção da opção. Todos os jogos pesquisados não possuem um sistema de instruir ao usuário diretamente o que ele deve fazer para arrumar o que está realizando errado. 2.7 Trabalhos Similares Muitos trabalhos sobre este assunto estão surgindo devido ao preço do Kinect ser baixo e as disponibilidades de frameworks. Os trabalhos pesquisados tratam do reconhecimento de gestos, que são basicamente um conjunto de poses realizadas em um tempo pré-definido, utilizando movimentos de transição entre elas. Durante a pesquisa não foi possível encontrar trabalhos que tratam do reconhecimento de posturas estáticas Kinect SDK Dynamic Time Warping Gesture Recognition O Kinect SDK Dynamic Time Warping Gesture Recognition é um projeto que utiliza a SDK oficial da Microsoft para gravar gestos realizados por um jogador, armazená-los em um documento de texto e interpretar as ações do jogador de acordo com os gestos armazenados. Para realizar a gravação de um gesto o jogador deve escolher seu nome em uma lista, e executar o gesto em 32 imagens. O documento de texto gerado possui 12 pontos X e Y do modelo do jogador em 32 imagens. Os pontos utilizados são apenas da parte superior do corpo: cabeça, centro dos ombros, ombros, coluna, centro do quadril, cotovelos, pulsos e mãos. O reconhecimento dos gestos armazenados é realizado por um algoritmo baseado em vetores e vizinhos próximos. Ou seja, não importa a velocidade que o jogador irá realizar o gesto (KINECT SDK DYNAMIC TIME WARPING GESTURE RECOGNITION, 2011). Foi bem sucedido para seu propósito, que é limitado ao 2D, mas captura o gesto na limitação das 32 imagens. O software desenvolvido está disponível no site oficial do projeto e é livre para ser testado, possui uma comunidade que serve para feedback e contribuições ao projeto. A única limitação que foi possível perceber no site oficial é sobre a edição do nome do gesto que o usuário deseja gravar, ele não pode digitar um nome para o gesto, apenas

48 46 escolher um nome pré-definido em uma lista, como por exemplo, mão direita se movimentando para a esquerda, e gravar o gesto desejado Recognizing Hands Gestures with Microsoft s Kinect Este trabalho propõe uma técnica de reconhecimento de gestos feitos apenas com a mão, utilizando o OpenNI e NITE para o desenvolvimento. NITE é uma coleção de ferramentas usadas para permitir que a aplicação crie um fluxo baseado no movimento das mãos do usuário. O movimento da mão é reconhecido como um gesto e é rastreado, para fornecer "pontos da mão" (PRIMESENSE, 2011). Para identificar a posição da mão é capturada uma sequencia de imagens de resolução 64x64 pixels, e a mão deve estar posicionada na área de captura de imagem. Desta sequencia, as imagens são analisadas e é atribuída a cada pixel uma probabilidade de fazer parte da mão ou não (TANG, 2011). A abordagem escolhida envolveu uma rede Bayesiana em nível de pixel, superpixels, um gráfico cluster criado a partir dos superpixels, uma SVM, e uma rede Bayesiana temporal. A chave para fazer a rede Bayesiana funcionar foi a escolha dos parâmetros mais adequados. A princípio os parâmetros trouxeram resultados que não eram confiáveis, então foram ajustados e atualizados cuidadosamente, fazendo com que a rede conseguisse convergir e trazer resultados muito próximos dos reais. A SVM utilizada permitiu que as melhorias do algoritmo de localização da mão pudessem ser quantificadas. Foi possível estimar uma precisão de 74% que foi possível aumentar para 80% com o algoritmo de localização da mão Human Detection Using Depth Information by Kinect O objetivo deste projeto é criar uma abordagem baseada em um modelo que detecta os seres humanos através de um contorno pré-estabelecido 2D e um preenchimento 3D. Após a filtragem do modelo, aplica-se um esquema de segmentação baseado em um ponto de detecção para separar a pessoa do ambiente ao seu redor. Também é explorado o algoritmo de rastreamento baseado no resultado da abordagem criada (XIA et al, 2012).

49 47 Os resultados experimentais mostram que o algoritmo pode efetivamente detectar as pessoas em todas as poses e aparências através dos dados de profundidade, fornecendo também uma estimativa precisa do contorno do corpo inteiro da pessoa. Também foi explorado um algoritmo de rastreamento com base nos resultados da detecção.o algoritmo pode facilmente se ajustar a novos conjuntos de dados sem necessidade de treinamento, ele utiliza um processo de detecção de duas camadas reduzindo uma grande medida do custo computacional. A limitação é que o algoritmo tem uma alta dependência da precisão de detecção da cabeça, o que implica em se a cabeça não estiver aparecendo ou a pessoa estiver usando um chapéu com um formato estranho, ela provavelmente não será detectada Construindo uma DSL para Reconhecimento de Gestos Utilizando Kinect Esse projeto propõe a criação de uma DSL (Digital Subscriber Line) em linhas de produtos de software para o sensor Kinect. Colocando em prática a metodologia SharpLupus a DSL é construída para um domínio restrito de jogos para Kinect. Com os resultados a DSL Kinect Gesture Language é definida, com o objetivo de aumentar a produtividade e reduzir o tempo de desenvolvimento de aplicações para o Kinect (SÁ, 2011). A análise do domínio foi realizada com sucesso, fazendo com que uma linguagem de domínio específico, chamada KGL fosse criada. Ela permite uma fácil utilização e configuração de um grupo de gestos que pode ser usado em diferentes contextos nos jogos, mas a biblioteca de gestos criada é muito pequena em relação ao conjunto de gestos que pode existir no ambiente de jogos, e ainda é necessário novos estudos, executando diferentes iterações para enriquecer a precisão dos gestos Vitruvius Um Reconhecedor de Gestos para o Kinect O trabalho consiste numa aplicação desenvolvida usando o Kinect, que aprende gestos com as mãos executados por usuários para posteriormente fazer o reconhecimento deles. Foi usada uma sequência de processamento formada por extração de vetores de características, filtragem, quantização e Modelo Oculto de Markov (TOGORES, 2011). Os algoritmos criados foram eficientes o bastante, rodando em tempo real e testados em máquinas com poder de processamento comum atualmente, conforme o objetivo

50 48 estipulado no projeto. Em relação aos parâmetros testados o melhor caso obteve uma porcentagem de acerto de 96%, um resultado bastante satisfatório Análise dos Trabalhos Similares Os trabalhos encontrados durante a pesquisa se tratam de reconhecimento do corpo humano e seus gestos, com a pesquisa foi possível encontrar métodos de comparação entre gestos, e analisá-los para retirar o que é aplicável na comparação entre poses. Também foi possível perceber que os trabalhos pesquisados não exploraram métodos de feedback da execução de gestos, então não foi possível se basear neles para a definição de feedbacks para a comparação entre poses. O Quadro x faz uma comparação entre o framework utilizado, o esforço para armazenar um gesto, qual a parte do corpo analisada, a técnica de detecção do corpo humano, o tipo de dado manipulado e o feedback utilizado. Trabalho Framework Esforço para armazenar o gesto Kinect SDK Dynamic Time Warping Gesture Recognition Recognizing Hands Gestures with Microsoft s Kinect Kinect for Windows SDK OpenNI e NITE Executar o movimento 32 vezes para gravar A mão deve estar em uma área de 64x64 pixels para ser identificada Parte do corpo armazenada Membros da parte superior do corpo Técnica utilizada Algoritmo baseado em vetores vizinhos Dados manipulados Pontos X e Y Mão Rede Bayesiana Verificação por pixel de profundidade Human Detection Using Depth Information by Kinect - O algoritmo depende da precisão da detecção da cabeça Corpo Inteiro É explorado o array de profundidade para encontrar regiçoes que podem indicar pessoas, e é utilizado um algoritmo de chanfro 2D. Verificação por pixel de profundidade Construindo uma DSL para Reconhecimen to de Gestos Utilizando Kinect Kinect for Windows SDK Foi criado um grupo específico de gestos que podem ser detectados Corpo Inteiro Técnica Algoritmica Frames do esqueleto

51 49 Vitruvius Um Reconhecedor de Gestos para o Kinect OpenNI e NITE Necessita treinamento aproximado de 40 execuções do gesto Mão Quadro 3. Comparação entre os trabalhos similares Sequência de processamento formada por extração de vetores de características, filtragem, quantização e Modelo Oculto de Markov Verificação por pixel de profundidade

52 50 3 DESENVOLVIMENTO Este capítulo tratará do detalhamento da fase de desenvolvimento do software, especificando as ferramentas escolhidas para o desenvolvimento, as técnicas que foram aplicadas para alcançar o objetivo e o resultado obtido através da análise dos testes. O software foi desenvolvido utilizando o Kinect for Windows SDK devido a funcionalidade de reconhecimento de comandos de voz, o qual é importante durante o armazenamento de uma pose, fazendo com que o usuário possa movimentar-se livremente para realizar a pose, e utilizar a fala para acionar a ação de armazenamento. Para o desenvolvimento gráfico do software, foi utilizado o XNA, já que este é um framework que possui muita documentação online. O software desenvolvido é capaz de armazenar dados dos ângulos referentes aos pontos do esqueleto de uma postura estática gerada por uma pessoa, capturados através do Kinect. Os pontos capturados são tratados por um algoritmo de comparação para que o reconhecimento da postura tenha um limite de aceitação, já que existem diferentes biótipos de pessoas. Depois de armazenada, a postura pode ser utilizada para ser comparada com posturas geradas por outras pessoas em tempo real, através de um algoritmo de comparação, e o software fornece um feedback que auxilia o usuário a realizar a postura armazenada de maneira correta. O software é dividido em dois módulos, o primeiro, focado no armazenamento de novas poses, o segundo permite que o usuário selecione uma pose que foi armazenada no primeiro módulo, e possa editar, deletar ou tentar executá-la, fornecendo feedback para auxiliar à execução correta da pose. 3.1 Análise de Requisitos e Casos de Uso A modelagem do software foi dividida em duas partes: uma referente ao módulo de captura de poses, e a outra referente ao módulo de comparação das poses já armazenadas.

53 Módulo de Captura Os requisitos funcionais, não funcionais e regras de negócio foram conceituados da seguinte maneira: Requisito funcional: o O software deve permitir que o usuário cadastre, edite, exclua e visualize poses. Requisito não funcional: o Usabilidade: Para realizar a função de seleção, o usuário usará o comando de voz ou um gesto para especificar qual ação ele deseja realizar, ou qual item ele deseja selecionar. Regras de Negócio: o Uma pose só será armazenada se estiver no campo de captura do Kinect; o A pose armazenada será referente aos pontos de apenas um esqueleto; o A pose se refere a uma pose final e não a um movimento. O caso de uso e os cenários do módulo de captura funcionam como o diagrama de caso de uso da Figura 18. Em seguida são descritos os cenários de cada caso de uso. Figura 17. Caso de Uso do Módulo de Captura Salvar pose: o Usuário executa comando de voz ou gesto referente a salvar nova pose; o Sistema entra em um estado de espera até ouvir o comando de gravar, cancelar ou a ativação do botão cancelar;

54 52 o Usuário realiza a pose desejada e executa comando de voz referente a gravar a pose; o Sistema captura os dados dos pontos x,y,z de cada articulação do esqueleto da pose realizada no momento em que o comando de voz gravar foi executado; o Sistema realiza cálculo de ângulo 2D para os eixos X e Y, X e Z, e Y e Z de cada articulação; o Sistema salva no arquivo XML 3 ângulos referentes a cada articulação do esqueleto e salva também um angulo limite de erro referentes a cada ângulo salvo, com um padrão inicial de 15 graus a mais e 15 graus a menos; o Sistema informa ao usuário que a pose foi salva com sucesso e informa o número de identificação dela. Editar pose: o Usuário executa comando de voz ou gesto referente a visualizar todas as poses; o Sistema apresenta uma representação gráfica das poses; o Usuário executa comando de voz ou gesto referente a um número de identificação de uma pose; o Sistema apresenta uma representação gráfica da pose escolhida; o Usuário executa comando de voz ou gesto referente a editar a pose selecionada; o Sistema entra em um estado de espera até ouvir o comando de gravar ou cancelar; o Usuário realiza a pose desejada e executa comando de voz referente a gravar a pose; o Sistema captura os dados dos pontos x,y,z de cada articulação do esqueleto da pose realizada no momento em que o comando de voz gravar foi executado;

55 53 o Sistema realiza cálculo de ângulo para cada eixo de cada articulação; o Sistema realiza uma comparação dos ângulos capturados recentemente com os que estavam salvos anteriormente; o Sistema modifica o limite de erro conforme uma comparação entre os limites de erro dos ângulos gravados anteriormente e o ângulo recémcapturado; o Sistema informa ao usuário que a pose foi editada com sucesso. Excluir pose: o Usuário executa comando de voz ou gesto referente a visualizar uma pose; o Sistema apresenta uma representação gráfica da pose; o Usuário executa comando de voz ou gesto referente a excluir a pose selecionada; o Sistema confirma com o usuário se ele realmente deseja excluir a pose; o Usuário executa comando de voz ou gesto referente à confirmação da exclusão; o Sistema exclui a pose do arquivo XML e informa ao usuário que a pose foi excluída. Visualizar pose: o Usuário executa comando de voz referente a visualizar uma pose; o Sistema apresenta uma representação gráfica da pose; o Usuário executa comando de voz ou gesto referente a cancelar; o Sistema volta para o estado inicial Cálculo e armazenamento dos ângulos Os pontos do esqueleto capturados são transformados em ângulos representando as articulações: pescoço, ombros, cotovelos, pulsos, coluna, quadris, joelhos e tornozelos. São criados três ângulos para cada uma destas articulações, um ângulo é calculado a partir dos

56 54 pontos x e y, o outro a partir dos pontos y e z e o terceiro a partir dos pontos x e z, conforme a Figura 19. Como são utilizados apenas dois eixos para se calcular o ângulo, o terceiro eixo é descartado utilizando a projeção ortográfica. (a) (b) (c) Figura 18.(a) Pontos na visão X e Y(b) Pontos na visão Z e Y (c) Pontos na visão X e Z Os ângulos que representam os pontos de esqueleto precisam ser calculados antes de armazenados no XML, para isso é necessário obter um ponto de esqueleto anterior e o próximo, a fim de formar um triângulo, conforme a Figura 20. Figura 19. Pontos utilizados para descobrir um ângulo Depois de identificados os pontos é necessário calcular o valor das retas formadas entre eles, para isso é usado o teorema de Pitágoras, que se trata de uma relação matemática

57 55 entre os lados de qualquer triângulo retângulo, o teorema afirma que em qualquer triângulo retângulo o quadrado do comprimento da hipotenusa é igual à soma dos quadrados dos comprimentos dos catetos. Para aplicar o teorema são criados triângulos retângulos com outras retas imaginárias, a Figura 21 demonstra como ficaria o cálculo resultante dos pontos da Figura 20. Figura 20. Teorema de Pitágoras aplicado aos pontos da Figura 20 Quando o valor das retas é encontrado, o triângulo deve ser dividido em dois, para se obter dois triângulos retângulos, e em seguida é aplicada uma fórmula para descobrir o valor da altura e das projeções dos catetos, conforme mostra a Figura 22. Figura 21. Fórmula para descobrir a altura e as projeções dos catetos Com os valores da altura e projeções dos catetos do triângulo, é possível descobrir o ângulo que agora está dividido em dois, será necessário calcular cada ângulo separadamente para depois somá-los e obter o resultado. O cálculo do ângulo pode ser obtido através do seno,

58 56 cosseno ou tangente. Como todos os lados do triângulo já foram encontrados, qualquer um dos três cálculos pode ser usado, então, sem critério de escolha, será usado o seno, conforme mostra a Figura 23. Figura 22. Cálculo do seno dos ângulos Com o seno do ângulo identificado, ainda é necessário localizar o valor correspondente do seno para identificar o valor do ângulo. A Figura 24 mostra os dados correspondentes de ângulo e seno. Figura 23. Valores do ângulo em relação ao seno Fonte: Adaptado de Noé (2012). Quando o ângulo é descoberto, ele faz parte de um triângulo, ou seja ele jamais será maior ou igual que 180, mas algumas articulações do corpo são capazes de fazer uma rotação de 360 graus, como por exemplo, o cotovelo. Em certos casos a articulação possuirá o mesmo ângulo para posições diferentes, como é o caso da Figura 25. Neste caso existem duas poses diferentes, que são consideradas iguais devido a classificação dos ângulos.

59 57 Figura 24. Ângulos iguais para poses diferentes Para resolver o problema da Figura 25, é necessário fazer com que em um dos dois casos, seja calculado o ângulo replementar 1 daquele que foi encontrado, ou seja, o ângulo deve ser subtraído do valor 360. Esse cálculo é efetuado em situações diversas: Quando a articulação anterior e a articulação posterior estão no primeiro quadrante, e a posição x da articulação anterior é menor que a posição x da articulação posterior ou a posição y da articulação posterior é menor que a posição y da articulação anterior, conforme a Figura 26. Figura 25. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no primeiro quadrante Quando a articulação anterior e a articulação posterior estão no segundo quadrante, e a posição x da articulação anterior é menor que a posição x da articulação posterior ou a posição y da articulação posterior é maior que a posição y da articulação anterior. 1 Replementar: quando a soma de suas medidas é igual a 360º (COSTA, et al, 2012).

60 58 Figura 26. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no segundo quadrante Quando a articulação anterior e a articulação posterior estão no terceiro quadrante, e a posição x da articulação anterior é maior que a posição x da articulação posterior ou a posição y da articulação posterior é menor que a posição y da articulação anterior. Figura 27. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no terceiro quadrante Quando a articulação anterior e a articulação posterior estão no quarto quadrante, e a posição x da articulação anterior é maior que a posição x da articulação posterior ou a posição y da articulação posterior é menor que a posição y da articulação anterior. Figura 28. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no quarto quadrante

61 59 Quando a articulação anterior e a articulação posterior estão no terceiro quadrante e/ou quarto quadrante, e a posição x da articulação anterior é maior que a posição x da articulação posterior. Figura 29. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no terceiro e/ou quarto quadrante Quando a articulação anterior e a articulação posterior estão no primeiro quadrante e/ou segundo quadrante, e a posição x da articulação anterior é menor que a posição x da articulação posterior. Figura 30. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no primeiro e/ou segundo quadrante Quando a articulação anterior e a articulação posterior estão no primeiro quadrante e/ou terceiro quadrante, e a posição y da articulação posterior é menor que a posição y da articulação anterior. Figura 31. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no primeiro e/ou terceiro quadrante

62 60 Quando a articulação anterior e a articulação posterior estão no segundo quadrante e/ou quarto quadrante, e a posição y da articulação posterior é maior que a posição y da articulação anterior. Figura 32. Caso onde a articulação anterior (segmento verde) e a articulação posterior (segmento vermelho) estão no segundo e/ou quarto quadrante Quando a articulação anterior está no primeiro quadrante e a articulação posterior está no quarto quadrante, e a subtração entre a posição x da articulação atual e a posição x da articulação anterior é menor que a subtração entre posição x da articulação posterior e a posição x da articulação atual ou a subtração entre a posição y da articulação atual e a posição y da articulação anterior é maior que a subtração entre a posição y da articulação posterior e a posição y da articulação atual. Figura 33. Caso onde a articulação anterior (segmento verde) está no primeiro quadrante e a articulação posterior (segmento vermelho) está no quarto quadrante Quando a articulação anterior está no segundo quadrante e a articulação posterior está no terceiro quadrante, e a subtração entre a posição x da articulação anterior e a posição x da articulação atual é maior que a subtração entre posição x da articulação atual e a posição x da articulação posterior ou a subtração entre a posição y da articulação atual e a posição y da articulação

63 61 anterior é menor que a subtração entre a posição y da articulação posterior e a posição y da articulação atual. Figura 34. Caso onde a articulação anterior (segmento verde) está no segundo quadrante e a articulação posterior (segmento vermelho) está no terceiro quadrante Quando a articulação anterior está no terceiro quadrante e a articulação posterior está no segundo quadrante, e a subtração entre a posição x da articulação atual e a posição x da articulação anterior é maior que a subtração entre posição x da articulação posterior e a posição x da articulação atual ou a subtração entre a posição y da articulação anterior e a posição y da articulação atual é menor que a subtração entre a posição y da articulação atual e a posição y da articulação posterior. Figura 35. Caso onde a articulação anterior (segmento verde) está no terceiro quadrante e a articulação posterior (segmento vermelho) está no segundo quadrante Quando a articulação anterior está no quarto quadrante e a articulação posterior está no primeiro quadrante, e a subtração entre a posição x da articulação anterior e a posição x da articulação atual é menor que a subtração entre posição x da articulação atual e a posição x da articulação posterior ou a subtração entre a posição y da articulação anterior e a posição y da

64 62 articulação atual é maior que a subtração entre a posição y da articulação atual e a posição y da articulação posterior. Figura 36. Caso onde a articulação anterior (segmento verde) está no primeiro quadrante e a articulação posterior (segmento vermelho) está no quarto quadrante Para armazenar os dados é utilizado o XML, pois ele permite que os dados possam ser gravados no formato de objetos, o que facilita bastante a manipulação destes dados. Dentro do XML, cada pose possui a informação de todas as 14 articulações citadas anteriormente, cada articulação possui a informação de três ângulos, e cada um destes ângulos possui um limite inferior e superior de ângulo, conforme Quadro 4. <articulacao nome="pescoco"> <posicao x="0, " y="0, " z="1,719159" /> <angulo tipo="x" valor="134"> <limite superior="60" inferior="60" /> </angulo> <angulo tipo="y" valor="174"> <limite superior="60" inferior="60" /> </angulo> <angulo tipo="z" valor="86"> <limite superior="60" inferior="60" /> </angulo> <posicaotela x="320,8924" y="167,3631" /> </articulacao> Quadro 4. Parte do XML representando uma articulação Módulo de Comparação Os requisitos funcionais, não funcionais e regras de negócio foram conceituados da seguinte maneira: Requisito funcional: o O software deve permitir selecionar uma pose para execução e auxiliar o usuário a realizar a pose.

65 63 Requisito não funcional: o Usabilidade: Para realizar a função de seleção, o usuário usará o comando de voz ou gesto para especificar qual ação ele deseja realizar, ou qual item ele deseja selecionar; o Usabilidade: O software deve instruir ao usuário o que está errado na execução de uma pose; o Usabilidade: Uma representação da pose é mostrada para que o usuário tenha uma referência da pose que precisa ser feita. Regras de Negócio: o A pose em execução será referente aos pontos de apenas um esqueleto; o A pose se refere a uma pose final e não a um movimento. O caso de uso e os cenários do módulo de comparação funcionam como o diagrama de caso de uso da Figura 26. Em seguida são descritos os cenários do caso de uso. Figura 37. Caso de Uso do Módulo de Comparação Executar pose: o Usuário executa comando de voz referente a visualizar uma pose; o Sistema apresenta uma representação gráfica da pose; o Usuário executa comando de voz referente a executar a pose; o Sistema entra em estado de avaliação capturando os pontos x,y e z de todas as articulações, realizando o cálculo de ângulos, oferecendo

66 64 feedback de como posicionar o corpo corretamente até que os dados capturados estejam coerentes com os dados salvos referente a pose sendo executada ou até que o usuário execute um comando de voz de cancelamento; o Sistema informa ao usuário que ele efetuou a pose com sucesso; o Sistema volta para o estado inicial. A técnica de comparação utilizada é uma mistura da comparação entre os ângulos e a matching. Quando o usuário armazena a pose, o cálculo do ângulo das articulações já é efetuado e junto com ele é criado um limite pré-definido. Quando a pose é executada, são capturados os dados desta nova pose e efetuado o cálculo dos ângulos dos novos pontos, esses novos ângulos são comparados com os armazenados e se estiverem dentro do limite superior e inferior estarão corretos, caracterizando a técnica de comparação de ângulos. O matching é opcional, se a pessoa quiser adicionar mais precisão à comparação da pose, ela pode ir na opção de editá-la e realizá-la novamente, com estes novos dados é ajustado o limite inferior e superior de todas as articulações conforme uma comparação entre a pose antiga e a pose nova. Para seleção de botões é usada a técnica algorítmica, através da verificação da posição da mão direita. Também é utilizado o comando de voz para acessar as opções. A técnica de comparação por pixel não consegue lidar com dados específicos das articulações do usuário, consegue apenas identificar onde ele está, por isso ela não terá utilidade no projeto. O software desenvolvido neste projeto utiliza um método para auxiliar o usuário em realizar a pose, informando quais partes do corpo estão posicionadas incorretamente e o que ele deve fazer para resolver este problema. Para descobrir a direção que o usuário deve movimentar-se para corrigir a pose, são analisadas as comparações entre os ângulos, então o software utiliza as direções para cima e para baixo referente ao ângulo formado pelos pontos x e y, esquerda e direita referente ao ângulo formado pelos pontos z e x, e frente e trás referente ao ângulo formado pelos pontos y e z, para informar a direção que o usuário deve se movimentar. Por exemplo, na comparação entre os ângulos referentes aos pontos x e y, caso o ângulo adquirido em tempo real seja maior que o limite superior do ângulo armazenado, o software irá informar ao usuário que ele deve mover este membro para baixo. Para informar o usuário as direções, o usuário poderá escolher que tipo de feedback ele deseja receber, podendo ser textual, o qual informa o nome da articulação que deve ser movimentada e a

67 65 direção; através de setas, as quais são desenhadas na articulação que está errada apontando para a direção que deve ser movimentada; através de cores, as quais são pintadas no esqueleto representativo do usuário marcando verde como correto, amarelo como próximo do correto e vermelho como errado; ou/e através de uma imagem do esqueleto armazenado para referência. 3.2 Fluxo de Telas Para iniciar o software é necessário que o Kinect esteja capturando o corpo inteiro do usuário, para isso o software verifica a posição da cabeça do usuário e, caso ela esteja muito abaixo ou acima do limite superior da tela, é inicializado um comando que abaixa ou levanta o dispositivo do Kinect. Este procedimento ocorre na primeira tela, e demora alguns segundos para acontecer. Após a calibragem, são oferecidas duas opções ao usuário: Save Pose, onde ele poderá salvar uma nova pose; e Select Pose, onde ele poderá selecionar uma pose já existente. Para escolher as opções, o usuário pode posicionar sua mão direita sobre um dos botões e esperar alguns segundos, então aparecerá um círculo em volta da mão representando quanto tempo falta para o botão ser ativado. O usuário também pode falar Save Pose para acessar a opção de salvar uma pose ou Select Pose para acessar a opção de selecionar uma pose existente, conforme ilustra a Figura 27. Figura 38. Tela inicial Quando o usuário acessa a opção de salvar uma nova pose, é apresentada para o usuário uma representação gráfica de seu esqueleto visto de frente e de lado, o botão Back para que ele possa voltar para a tela anterior. Para salvar a pose, o usuário deverá falar Save

68 66 Pose ou ativar o botão Start Timer, que começará uma contagem regressiva, conforme ilustra a Figura 28. Ao término da contagem o software irá adicionar informações a um XML já existente, chamado Poses. Neste XML serão salvas as posições X, Y e Z de 20 articulações do esqueleto do usuário, os ângulos XY, ZY e XZ de 15 articulações do esqueleto do usuário e um limite de ângulo superior e inferior de 45 graus para cada uma delas. Figura 39. Contagem regressiva que ao chegar a zero armazena a pose Enquanto a pose está sendo salva, a imagem atual da tela é copiada para um arquivo, para que ela possa ser apresentada futuramente na tela de selecionar poses. Na tela de selecionar poses aparece até quatro poses, se houver mais poses salvas, aparece uma seta apontando para a direita indicando que existem outras páginas com mais poses. Para selecionar uma pose o usuário deve posicionar a mão direita sobre a imagem da pose que ele deseja selecionar e aguardar alguns segundos. Após selecionar a pose, aparecem algumas opções que permitem deletar, editar ou executar a pose selecionada, conforme a Figura 29. Caso o usuário selecione o botão para deletar a pose, o sistema apresenta uma tela para que o usuário confirme se realmente deseja deletar a pose, ou se ele entrou naquela opção sem intenção. Figura 40. Opções que permitem gerenciar uma pose

69 67 Caso o usuário selecione a opção de editar a pose, o sistema apresenta uma tela com a representação gráfica de seu esqueleto visto de frente e de lado, então o usuário deverá refazer a pose selecionada e falar Save Pose ou ativar o botão Start Timer para iniciar uma contagem regressiva. Após reconhecer o comando para salvar uma nova pose, o sistema irá comparar os dados da nova pose com a antiga, e conforme o resultado da comparação ele poderá alterar os dados dos limites superiores e inferiores dos ângulos das articulações salvas de acordo com a Figura 30. Figura 41. Fluxograma representando a edição de uma pose Podem ocorrer seis possibilidades de edição diferentes: Quando o ângulo armazenado é menor que o ângulo capturado em tempo de execução, e a subtração entre o ângulo capturado em tempo de execução e o ângulo armazenado é menor ou igual ao limite superior armazenado dividido por dois, conforme a Figura 43 ilustra. Neste caso é subtraído 5 graus do limite superior e inferior.

70 68 Figura 42. Ângulo da execução em tempo real maior que o ângulo armazenado e menor que o limite superior dividido por dois Quando o ângulo armazenado é menor que o ângulo capturado em tempo de execução, e a subtração entre o ângulo capturado em tempo de execução e o ângulo armazenado é menor ou igual ao limite superior armazenado, conforme a Figura 44 ilustra. Neste caso é subtraído 5 graus do limite inferior. Figura 43. Ângulo da execução em tempo real maior que o ângulo armazenado e menor que o limite superior Quando o ângulo armazenado é menor que o ângulo capturado em tempo de execução, e a subtração entre o ângulo capturado em tempo de execução e o ângulo armazenado é maior que o limite superior armazenado, conforme a Figura 45 ilustra. Neste caso é subtraído 5 graus do limite inferior e somado 5 graus ao limite superior.

71 69 Figura 44. Ângulo da execução em tempo real menor que o ângulo armazenado e maior que o limite inferior dividido por dois Quando o ângulo armazenado é maior que o ângulo capturado em tempo de execução, e a subtração entre o ângulo armazenado e o ângulo capturado em tempo de execução é menor que o limite inferior armazenado dividido por dois, conforme a Figura 46 ilustra. Neste caso é subtraído 5 graus do limite superior e inferior. Figura 45. Ângulo da execução em tempo real menor que o ângulo armazenado e maior que o limite inferior dividido por dois Quando o ângulo armazenado é maior que o ângulo capturado em tempo de execução, e a subtração entre o ângulo armazenado e o ângulo capturado em tempo de execução é menor que o limite inferior armazenado, conforme a Figura 47 ilustra. Neste caso é subtraído 5 graus do limite superior.