UNIVERSIDADE ANHEMBI MORUMBI ANA PAULA TEIXEIRA SANTOS ANDRE LUÍS MOSER FELIPE MOREIRA CRUZ LUCAS GONÇALVES ODA THIAGO MATOS ROCCO

Transcrição

1 UNIVERSIDADE ANHEMBI MORUMBI ANA PAULA TEIXEIRA SANTOS ANDRE LUÍS MOSER FELIPE MOREIRA CRUZ LUCAS GONÇALVES ODA THIAGO MATOS ROCCO KINLIB - PROTÓTIPO DE ENSINO DE LIBRAS UTILIZANDO O KINECT São Paulo 2011

2 ANA PAULA TEIXEIRA SANTOS ANDRE LUÍS MOSER FELIPE MOREIRA CRUZ LUCAS GONÇALVES ODA THIAGO MATOS ROCCO KINLIB - PROTÓTIPO DE ENSINO DE LIBRAS UTILIZANDO O KINECT Trabalho de Conclusão Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Ciência da Computação da Universidade Anhembi Morumbi. Orientador: Msc. Simone de Abreu São Paulo 2011

3 K63 Kinlib : protótipo em ensino de libras utilizando o kinect / Ana Paula Bento Teixeira [et al.] f.: il.; 30 cm. Orientadora: Simone de Abreu. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Universidade Anhembi Morumbi, São Paulo, Bibliografia: f Ciência da Computação. 2. Libras. 3. Acessibilidade. 4. Ensino-ferramenta. I. Título. CDD 004

4 ANA PAULA TEIXEIRA SANTOS ANDRE LUÍS MOSER FELIPE MOREIRA CRUZ LUCAS GONÇALVES ODA THIAGO MATOS ROCCO KINLIB - PROTÓTIPO DE ENSINO DE LIBRAS UTILIZANDO O KINECT Trabalho de Conclusão Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Ciência da Computação da Universidade Anhembi Morumbi, sob a orientação da Prof.ª Simone de Abreu. Aprovado em Prof.ª Msc. Simone de Abreu Prof.ª Greice Martins Prof.ª Msc. Roberta Beatriz Aragon Bento

5 AGRADECIMENTOS Agradecemos aos professores, por todo suporte durante o desenvolvimento do projeto, principalmente a Professora Simone de Abreu nossa orientadora que nos incentivou a prosseguir com nosso objetivo inicial. Agradecemos às nossas famílias e amigos, por toda paciência durante esse período. Eu André, agradeço muito a minha esposa Juliana Starosky e a meu querido filho Gabriel pela compreensão e ajuda nos momentos mais difíceis e nas longas noites que me mantive a frente de meu notebook nas quais, infelizmente, não podia estar ao lado deles. Eu Ana Paula, agradeço ao meu marido Everson Silva Santos que esteve ao meu lado em todos os momentos e por toda paciência. Agradecemos primeiramente a Deus, que permitiu que tudo isso fosse possível.

6 RESUMO Este trabalho tem como intuito mostrar e explicar o desenvolvimento de um protótipo para ensino da Língua Brasileira de Sinais (LIBRAS), utilizando um sistema de captura de movimentos e SDKs de código aberto desenvolvido pela comunidade OpenSource. Mostrando assim que, com um baixo investimento é possível criar uma ferramenta de ensino para deficientes auditivos que visa facilitar a difusão da língua de sinais. O sistema de captura escolhido foi o Microsoft Kinect, conectado a um computador rodando Microsoft Windows. Este projeto aborda o desenvolvimento de um protótipo de ensino, o entendimento do framework Candescent e cenários de teste. PALAVRAS-CHAVE: Acessibilidade. Microsoft Kinect. Ferramentas de código aberto. Língua Brasileira de Sinais.

7 ABSTRACT This work has the intention to show and explain the development of a prototype to teach Brazilian Sign Language (LIBRAS), using a movement capture system and Open Source SDKs developed by the community Open Source, showing that even with low investment it is possible to create a tool to teach the hearing impaired aiming to promote the sign language. The movement capture system chosen was the Microsoft Kinect, connected to a computer running Microsoft Windows. This project addresses the development of a prototype of teaching, understanding of framework Candescent and test scenarios. KEYWORDS: Accessibility. Microsoft Kinect. Open source tools. Brazilian Sign Language.

8 LISTA DE FIGURAS Figura 1 - Alfabeto em Libras (Língua de Sinais Brasileira) Figura 2 - Alfabeto em Signwriting Figura 3 - Dicionário de Libras Figura 4 - ASUS Wavi Xtion Figura 5 - The PrimeSensor Figura 6 - Estrutura OpenNI Figura 7 - Esqueleto de Calibração (FAAST) Figura 8 - Na esquerda o Vídeo-Game Xbox 360 e na direita o Microsoft Kinect Figura 9 - Sensores Kinect Figura 10 - Movimento padrão de reconhecimento do kinect Figura 11 - Visão Infravermelho, pattern do Kinect Figura 12 - Arquitetura do framework Candescent Figura 13 - Visualização do esqueleto SDK Microsoft Figura 14 - Execução do Candescent a partir do Visual Studio Figura 15 - Seleção de middleware (OpenNI/SDK Microsoft) Figura 16 - Coleta de dados de imagem através do framework Candescent Figura 17 - Coleta de dados em Infravermelho no Candescent Figura 18 - Sobreposição das imagens de infravermelho e detecção Figura 19 - Detecção de mãos e dedos no framework Candescent Figura 20 - Detecção de mãos e dedos no framework Candescent Figura 21 - Exibição de imagens no framework Candescent Figura 22 - Interação com imagens no framework Candescent Figura 23 - Manipulação de imagens no framework Candescent Figura 24 - Mecanismos fornecidos pelo framework Candescent Figura 25 - Componentes da arquitetura do KINLIB Figura 26 - Componentes da Arquitetura do KINLIB Figura 27 - Diagrama de classe dos componentes do KINLIB Figura 28 - Sinais reconhecidos pelo KINLIB Figura 29 - Diagrama de Seqüência dos componentes do KINLIB Figura 30 - Estrutura projeto KINLIB no Visual Studio Figura 31 - Código de apresentação de informações no Painel de Informações Figura 32 - Estruturas de armazenamento e pesquisa de Gestos no KINLIB... 60

9 Figura 33 - Algoritmos de interpretação de Gestos do KINLIB Figura 34 - Acionamento dos métodos de interpretação de Gestos no KINLIB Figura 35 - Layout do KINLIB no Microsoft Visual Studio Figura 36 - Layout do KINLIB Figura 37 - Layout do aplicativo KINLIB em execução Figura 38 - Conexão do KINLIB ao Kinect via OpenNI Figura 39 - Quadro de informações do KINLIB Figura 40 - Acionamento dos métodos de interpretação de Gestos no KINLIB Figura 41 - Interpretação e reconhecimento do Número 1 do KINLIB Figura 42 - Interpretação e reconhecimento do Número 2 do KINLIB Figura 43 - Interpretação e reconhecimento do Número 3 do KINLIB Figura 44 - Interpretação e reconhecimento do Número 4 do KINLIB... 70

10 LISTA DE TABELAS Tabela 1 - Características da língua de Sinais (LIBRAS) Tabela 2 - Especificação técnica da câmera Kinect Tabela 3 - Requisitos para instalação do SDK Tabela 4 - Vantagens e Desvantagens dos Frameworks Tabela 5 - Analise dos Acertos e Erros no processo de reconhecimento dos dedos 70

11 LISTA DE ABREVIATURAS E SIGLAS API BSD CMOS E3 FAAST GDI INES IR LED LIBRAS NI OPENNI PC PCL RAM RGB-D ROS SDK TOF WPF Application Programming Interface Berkeley Software Distribution Complementary Metal-Oxide-Semiconductor Electronic Entertainment Expo Flexible Action and Articulated Skeleton Toolkit Graphics Device Interface Instituto Nacional de Educação de Surdos Infra Red Light-emitting diode Língua Brasileira de Sinais Natural Interaction Open Natural Interaction Personal Computer Point Cloud Library Random Access Memory Red Green Blue Dense Robot Operating System Software Development Kit Time of Flight Windows Presentation Foundation

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVO JUSTIFICATIVA ABRANGÊNCIA ESTRUTURA DO TRABALHO LÍNGUA DE SINAIS SURGIMENTO DA LÍNGUA DE SINAIS LIBRAS: LÍNGUA DE SINAIS BRASILEIRA Métodos utilizados no aprendizado de Libras Características da língua de sinais SOFTWARES E PROJETOS PARA ENSINO DE LIBRAS SignWriting Ve-Libras Dicionário de Libras TLibras CAPTURA DE MOVIMENTO FORMAS DE CAPTURA DE MOVIMENTOS MICROSOFT KINECT HISTÓRIA, TECNOLOGIA E SOFTWARE CARACTERÍSTICAS DO KINECT FRAMEWORKS OPENNI SOFTWARE DEVELOPMENT KIT (SDK) ROBOT OPERATING SYSTEM (ROS) CANDESCENT NUI Funcionalidades... 36

13 4.4.2 Arquitetura do Candescent METODOLOGIA INSTALAÇÃO, ANALISE E RESULTADOS DOS FRAMEWORKS PROJETO MODELAGEM Arquitetura do KINLIB Design DESENVOLVIMENTO Estrutura do projeto Desenvolvimento do projeto PROTÓTIPO Conexão ao Kinect Quadro de informações TESTES CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRAFIAS ANEXO A Exemplo de código com as funções de mapeamento... 78

14 14 1 INTRODUÇÃO Cada vez mais o mundo se preocupa com a acessibilidade para os deficientes físicos, seja com rampas para os paraplégicos, closed caption para os deficientes auditivos em televisores, braile em elevadores para os deficientes visuais, entre outros. E para auxiliar a comunicação dos deficientes auditivos, foi desenvolvida a língua de sinais e o alfabeto manual, que utiliza os movimentos das mãos, braços e da face para simbolizar palavras e expressões (CUORE, 2009). No Brasil essa linguagem foi adaptada dando origem a Língua Brasileira de Sinais mais conhecida como LIBRAS, atualmente a única forma de ensino dessa linguagem é realizada, através de aulas presenciais, apostilas ou vídeos, não existe uma forma dinâmica que possa aplicar exercícios e corrigi-los sem que haja outra pessoa envolvida (MONTEIRO, 2006). Sendo assim, surge uma nova tecnologia que permite a captura de movimentos do corpo humano, possibilitando a criação de um protótipo de ensino de LIBRAS de forma relativamente simples e de baixo custo. O Microsoft Kinect foi lançado inicialmente com o intuito de ser uma nova forma de controle de jogos, desenvolvido para ser utilizado no video game Xbox 360 (MICROSOFT, 2011). O seu conceito é utilizar apenas o corpo do jogador como controlador, sem a necessidade de um joypad ou joystick. Porém, logo após o seu lançamento, centenas de pessoas começaram a explorar outras possibilidades do hardware, lançando APIs e escrevendo programas com os mais variados usos (WASH, 2010). Permitindo também sua utilização em pesquisas médicas, como cirurgias e em reabilitação de pacientes através de fisioterapia, fazendo com que as máquinas possam enxergar o mundo, em três dimensões e em tempo real (REVERBEL, 2011). 1.1 OBJETIVO O objetivo do trabalho é desenvolver um protótipo de ensino de Libras simplificado e interativo denominado KINLIB, que irá utilizar a Língua de Sinais Brasileira e os recursos de captura de movimentos do Microsoft Kinect. No qual o

15 15 usuário irá realizar o movimento indicado e o dispositivo irá informar se a reprodução estava correta ou não. Esse protótipo visa facilitar o aprendizado de deficientes auditivos e profissionais da área de Libras, e ampliar a divulgação desse novo dispositivo de captura de movimento. 1.2 JUSTIFICATIVA Com o lançamento do periférico desenvolvido pela Microsoft para controle de jogos utilizando apenas o corpo humano, abriu-se a possibilidade de criar softwares com interface simplificada a um custo relativamente baixo e de complexidade reduzida. Despertando o interesse do grupo em desenvolver um protótipo, para utilização desses recursos em prol dos deficientes auditivos, proporcionando a essas pessoas uma forma prática e divertida de aprendizado. 1.3 ABRANGÊNCIA Neste trabalho será utilizado apenas APIs desenvolvidas pela comunidade OpenSource e eventuais SDKs liberados pela empresa Microsoft, não serão desenvolvidos novos algoritmos para manipulação do hardware. O protótipo reconhecerá apenas os movimentos das mãos e dedos. Não serão desenvolvido APIs novas, e também não será utilizado o microfone do Kinect para realização do projeto de ensino utilizando a língua de sinais LIBRAS. Neste projeto não serão utilizados todos os sinais de LIBRAS ou do alfabeto manual, devido sua complexidade no reconhecimento dos dedos através do equipamento de estudo, e também não será implementado o reconhecimento facial através do Microsoft Kinect. O dispositivo utilizado para realização do projeto será o Microsoft Kinect um sensor de captura de movimento desenvolvido pela empresa Microsoft para ser utilizado no video game Xbox, tornando os jogos mais interativos onde o próprio usuário controla as ações do jogo.

16 ESTRUTURA DO TRABALHO A estrutura deste trabalho está divida em seis capítulos, em que no segundo capítulo é abordada a história da língua de sinais no Brasil (LIBRAS) e em outros países e suas características, e fazendo um comparativo com outros dispositivos de ensino de Libras utilizando algum tipo de tecnologia. No terceiro capítulo são analisados alguns dispositivos de captura de movimentos, as características e especificações do Microsoft Kinect e sua ligação com a língua de sinais. No quarto capítulo são analisados os frameworks desenvolvidos pra o Kinect. No quinto capítulo é descrito a metodologia utilizada para o desenvolvimento do projeto. No sexto e último capítulo é realizada a arquitetura, modelagem, Interface e desenvolvimento do protótipo de ensino utilizando a língua Brasileira de sinais e o Microsoft Kinect, seguido de conclusão, projetos futuros e referências bibliográficas.

17 17 2 LÍNGUA DE SINAIS Este capítulo aborda o surgimento da língua de sinais, as características da língua Brasileira de sinais, sua relação com a tecnologia e o que vem sendo desenvolvido através da tecnologia para auxiliar, no desenvolvimento do deficiente auditivo. 2.1 SURGIMENTO DA LÍNGUA DE SINAIS A língua de sinais surgiu na Europa por volta do século XVI, quando iniciou as primeiras metodologias voltadas ao desenvolvimento e a comunicação dos deficientes auditivos, pois até então eram tratados pela sociedade como seres invisíveis, nesta época surgiram as primeiras representações, através de gestos do alfabeto (OLIVEIRA, 2011). O instituto Nacional de Jovens Surdos, localizado em Paris na França, iniciou o desenvolvimento da metodologia desenvolvida por Charles Michel de I Epée, realizada para instruir jovens surdas, através da datilografia, alfabeto manual e gestos desenvolvidos por ele (RAMOS, 2006). Através desses métodos outros países passaram a desenvolver suas próprias metodologias para auxiliar na comunicação entre surdos e ouvintes (RAMOS, 2006). A língua de sinais auxilia o deficiente auditivo no seu desenvolvimento e comunicação com outros deficientes e com os ouvintes. A língua de sinais não é baseada somente no alfabeto, também é baseada em expressões e gestos, que podem possuir diversas representações (PACHECO, ESTRUC e ESTRUC, 2008). Atualmente cada país possui uma língua de sinais particular, com movimentos significativos para cada expressão, ou seja, essa linguagem não é universal, nem padronizada, cada palavra pode ser interpretada de forma independente variando conforme o país (PACHECO, ESTRUC e ESTRUC, 2008). As palavras e sensações também podem ser expressadas de forma distintas, dependendo da região, e devido à necessidade de comunicação, cada país desenvolveu uma metodologia e métodos para se comunicar com os deficientes auditivos. (PACHECO, ESTRUC e ESTRUC, 2008). 2.2 LIBRAS: LÍNGUA DE SINAIS BRASILEIRA

18 18 No Brasil a língua de sinais teve seu início por volta de 1856 através do Professor francês Ernest Huet, sendo portador de deficiência auditiva, trouxe ao Brasil o alfabeto gestual Frances, e através desse alfabeto começou a surgir à língua brasileira de sinais (Figura 1), até chegar ao que é atualmente, conhecida como LIBRAS (RAMOS, 2006). Figura 1 - Alfabeto em Libras (Língua de Sinais Brasileira) Fonte: ARAUJO (2007) Porém, todo o processo até a língua de sinais, chegar de fato a ser reconhecida, passou por diversas dificuldades, muitos pais tinham vergonha de ter filhos surdos, não permitindo sua inclusão na sociedade (MONTEIRO, 2006). Naquela época qualquer tipo de gesto era considerado algo fora dos padrões, e os próprios deficientes se sentiam desestimulados a se comunicar, o que acabou prejudicando no avanço da língua de sinais. Com o passar dos anos, a comunicação foi ganhando real importância e o deficiente auditivo, passou a ser reconhecido na sociedade como um individuo. A primeira escola para surdos no Brasil foi fundada em 1857, Instituto Nacional da Educação de Surdos (INES), no estado do Rio de Janeiro, esse instituto abrigava deficientes auditivos de todas as regiões Brasileiras (MONTEIRO, 2006). A comunicação através de sinais no Brasil passou por diversas dificuldades, e chegou a ser proibida, sendo praticada informalmente nas escolas. Somente em 24

19 19 de Abril de 2002, foi sancionada a lei nº que regulamentaria a língua de sinais brasileira (LIBRAS), e após esse período, a língua de sinais sofreu diversas alterações, por essa razão não pode ser dita como sendo uma língua universal, pois possuem também características regionais. Os deficientes auditivos vêm ganhado espaço na sociedade, mas ainda existe uma grande necessidade de modificações para que a comunicação entre ouvintes e surdos seja plena (RAMOS, 2006). Em 22 de dezembro de 2005, pelo decreto n º5.626 foi regulamentada a Lei que estabelece a LIBRAS como disciplina curricular de caráter obrigatório na formação de professores, devido à grande dificuldade de aprendizado do deficiente auditivo, e sua inclusão na sociedade (CUORE, 2009). A língua Brasileira de sinais possui uma estrutura gramatical independente, sendo um sistema lingüístico legítimo que oferece ao surdo a integração com a sociedade, o que demonstra que essa linguagem possui uma grande semelhança a língua oral (OLIVEIRA, 2011). Pode-se, dizer que essa linguagem é desenvolvida através de gestos, realizada por movimentos das mãos e expressões faciais utilizados como forma de comunicação, sendo extremamente complexa. Pois utilizada o próprio corpo e seus movimentos da forma mais expressiva possível, demonstrando atitudes e sentimentos dos mais diversos (RAMOS, 2006) Métodos utilizados no aprendizado de Libras Conforme orientações do curso de libras realizado por Jonas Pacheco (2008) existem alguns métodos que devem ser realizados para facilitar o aprendizado em LIBRAS e uma comunicação eficiente com o deficiente auditivo: A. Para que todo sinal seja realizado corretamente, é necessário observar, a configuração da mão, articulações, movimentos e expressões faciais. B. O foco principal deve ser o rosto e não as mãos, dessa forma sendo ampliado seu campo de visão.

20 20 C. Haverá casos onde o sinal realizado terá mais de um significado, ou não exista a palavra na língua de sinais, nestes casos o recomendado é que seja utilizada uma palavra semelhante. D. Em caso de termos muito técnicos deve-se soletrar a palavra, ou digitálo para a melhor compreensão do deficiente auditivo Características da língua de sinais Como relatado anteriormente por Jonas Pacheco (2008), a língua de sinais possui características lingüísticas muito parecidas com a linguagem oral e escritas da língua portuguesa, conforme descritas na tabela 1 a seguir: Tabela 1 - Características da língua de Sinais (LIBRAS) Características da língua de sinais Variações Lingüísticas São variações que podem ser definidas por regiões, culturas e sociais; Iconicidade e Arbitrariedade São representações através de gestos e imagens; Estrutura Gramatical Forma como as palavras são representadas através de tipos de movimentos e expressões; Estrutura Sintática Forma como são representados e montadas estruturalmente a frases para o entendimento do surdo; Formação de Palavras Formações de palavras de qualquer tipo. Alfabeto Manual Representação do alfabeto na língua de sinais. Fonte: PACHECO, ESTRUC E ESTRUC (2008)

21 SOFTWARES E PROJETOS PARA ENSINO DE LIBRAS Apesar de vivermos na era da tecnologia, os recursos existentes ainda são bastante limitados, em prol dos deficientes auditivos. No final da década de 80 surgiu à tecnologia assistida que foi desenvolvida, com o intuito de proporcionar ao deficiente físico, uma interação com o mundo a sua volta, da forma mais independente possível utilizando recursos e metodologias, que promova a funcionalidade e capacitação de pessoas com deficiência física (PONTES e ORTH, 1999). Existe no mercado alguns protótipos e softwares desenvolvidos para ensino da Língua Brasileira de Sinais (Libras), neste projeto analisamos alguns como: SignWriting Com o auxilio da tecnologia vem sendo desenvolvido algumas ferramentas que utilizam a língua de sinais, através de representações escrita visual, um exemplo é uma ferramenta de representação gráfica chamada SignWriting, que utiliza símbolos visuais, esse sistema foi desenvolvido em 1974 por Valerie Sutton na Califórnia, para auxilio na alfabetização de deficientes auditivos (SOUZA e PINTO, 2003). Figura 2 - Alfabeto em Signwriting Fonte: NETO (2008) Para utilizar a escrita gráfica SignWhiting, como mostra a (Figura 2) foi desenvolvido o software Sign Webmessage com o intuito de tornar mais simples a

22 22 comunicação entre os surdos e ouvintes, devido o sistema permitir a interação entre ambas as línguas, portuguesa ou Libras. (SOUZA e PINTO, 2003) Ve-Libras O software VE-LIBRA é um protótipo que traduz a fala e a escrita para língua de sinas desenvolvido por Noelle Nascimento Buffa Furtado, ex-aluna do curso de engenharia da Faculdade Veris. O software funciona da seguinte forma: o sistema grava a voz de uma pessoa e através de um processo de reconhecimento de voz, ocorre a conversão de fala em texto, que é traduzido por um programa chamado Rybená, que é um tradutor de textos em português para Libras (PORTA, 2010) Dicionário de Libras O software LibrasNet (Figura 3) é uma aplicação destinada ao ensino de libras, o programa funciona como um dicionário, onde ao selecionar um determinado tema, lista se uma serie de palavras, ao clicar na palavra abre um vídeo, realizados por surdos e filhos de surdos (DICIONARIO DE LIBRAS, 2011). Figura 3 - Dicionário de Libras Fonte: LIBRASNET (2010) O dicionário de Libras é fornecido gratuitamente e para sua utilização é necessário instalar um plugin da Adobe o Shockwave (DICIONARIO DE LIBRAS, 2011).

23 TLibras O TLIBRAS é um projeto destinado à construção de um tradutor automatizado de Português para LIBRAS, para ser utilizando em sala de aula, através da televisão, em videos, internet, entre outros, onde será utilizado sinais animados (ACESSIBILIDADE BRASIL, 2011).

24 24 3 CAPTURA DE MOVIMENTO Este capítulo aborda os tipos de capturas de movimentos existentes, os dispositivos que utilizam esse recurso como o Microsoft Kinect, descrevendo suas características, desenvolvimento e tecnologia utilizada. 3.1 FORMAS DE CAPTURA DE MOVIMENTOS Existem novas formas de captura de movimento no mercado conforme a tecnologia avança. Um exemplo é o novo produto desenvolvido pela ASUS para PCs, fabricado pela empresa PrimeSense, a mesma que atuou como parceira da Microsoft e se juntou com a Asus para desenvolver um sistema semelhante para os PCs, essa novidade se chama WAVI Xtion (Figura 4), que é uma câmera 3D que faz o reconhecimento de profundidade. (ASUS, 2011) O Produto funciona através de conexão Wireless, e será possível transmitir as imagens capturadas para uma TV, seu lançamento foi realizado na data de 30 de maio de 2011 na Computex 2011, e virá acompanhada de três títulos: MayaFit, Beat Booster e DanceWall, todos com foco na diversão em família. (GUGELMIN, 2011) Figura 4 - ASUS Wavi Xtion Fonte: AGOSTINI (2011) Outro dispositivo que utiliza recursos semelhantes à tecnologia licenciada da PrimeSense é o The PrimeSensor (Figura 5) é um dispositivo de entrada do computador do usuário, contendo exemplos de projetos similares ao Kinect, que possui somente duas câmeras RGB, Infravermelho IR (Infra-Red serve para reconhecer movimento e profundidade) e microfones, não possui o motor de inclinação como o Kinect. Contém as bibliotecas previstas no openkinect.org, ou seja, libfreenect, que com a liberação de novos SDK s (Software Development Kit, isto é, Kit de Desenvolvimento de Software ou Aplicativos) para projetos Open

25 25 source, irá permitir que novos programadores possam realizar a integração do software com o hardware, podendo desenvolver novos recursos através da captura de movimentos (BOURKE, 2010). Figura 5 - The PrimeSensor Fonte: BOURKE (2010) A arquitetura utilizada no Microsoft Kinect e em outros dispositivos do mesmo tipo, pode ser classificada em três fases conforme demonstrado a seguir (Figura 6) (H-ONLINE, 2010): Figura 6 - Estrutura OpenNI Fonte: H-ONLINE (2010) I. Application (Aplicação): onde são localizados os dispositivos como vídeo games, TV, Navegadores entre outros, que permite a visualização por parte do usuário de seus movimentos;

26 26 II. Driver OpenNI: onde é realizada a junção entre a interface, middleware e os componentes gestuais, ou seja, que captura os movimentos das mãos e corpo, (esse drive por ser OpenSource, possui seu código fonte aberto); III. Hardware: definido pelos dispositivos de áudio e vídeo, e sensores de captura de movimento do usuário ou objetos. O OpenNI inclui uma API (Application Programming Interface) ou Interface de Programação de Aplicações, completa para controlar as câmeras 3D incluídas no hardware da Microsoft Kinect (OPENNI, 2011). Esse aplicativo tem uma vasta documentação online, como por exemplo, Flexible Action and Articulated Skeleton Toolkit (FAAST). O FAAST é um middleware desenvolvido pela Universidade da Califórnia do Sul, que reconhece o usuário, neste software são incluídas mais de vinte e quatro articulações do esqueleto humano, e apartir desse esqueleto (Figura 7) é possível adicionarmos eventos e gerar várias animações (KINECTHACKS, 2010). Figura 7 - Esqueleto de Calibração (FAAST) Fonte: USC (2011) 3.2 MICROSOFT KINECT O produto escolhido para a realização deste projeto é o Microsoft Kinect, desenvolvido pela empresa Microsoft Corporation, uma empresa multinacional de

27 27 tecnologia, dos Estados Unidos da América, que desenvolve e fabrica licenças e suporta uma ampla gama de produtos e software para dispositivos de computador, e nos últimos anos vem desenvolvendo também consoles de vídeo game (Figura 8) (MICROSOFT, 2011). Figura 8 - Na esquerda o Vídeo-Game Xbox 360 e na direita o Microsoft Kinect Fonte: MICROSOFT (2011) Em sua área de produção o Microsoft Kinect, possui parte de seu processo terceirizado por outras empresas como a PrimeSense, uma empresa Israelense líder em detecção 3D e reconhecimento, que foi responsável pela parte técnica da tecnologia utilizada no Kinect (GOHRING, 2010). Seu desenvolvimento de hardware e software foi baseado na tecnologia desenvolvida pela empresa Rare (Rareware) que é uma empresa desenvolvedora de video game Britânica fundada em 1983.Em 2002 a empresa Rare foi adquirida pela empresa Microsoft, sendo a desenvolvedora do jogo chamado Kinect Sports lançado em 2010, e que atualmente desenvolve para outras empresas do ramo de video games como a Nintendo (REYNOLDS, 2010). 3.3 HISTÓRIA, TECNOLOGIA E SOFTWARE O Microsoft Kinect foi anunciado pela primeira vez em Junho de 2009, na conferência E3 (Electronic Entertainment Expo), que acontece anualmente para expor novas tecnologias de computadores e vídeo-game (EURO GAMER, 2011). Inicialmente o Kinect ganhou o apelido (ou código) do criador dessa tecnologia chamado de Project Natal, onde o Natal referencia a cidade de Natal

28 28 no Rio Grande do Norte. O autor Brasileiro Alex Kipman, que escolheu o nome como um tributo a seu País. Além disso, ele sabia que Natal também significa nascer, em latim. Considerado a data da nova geração de entretenimento, a Microsoft enviou uma mensagem para salvar a estréia num evento chamado World Premiere Project Natal para demonstração na E (EURO GAMER, 2011). O evento que aconteceu num domingo, 13 de junho e contou com uma performance do Cirque du Soleil, anunciando que o sistema iria ser chamado oficialmente, uma junção das palavras kinetic (cinética, em potuguês) e connect (conectividada, devido a possibilidade de usá-lo para video chat), que descrevem os principais aspectos da iniciativa, a empresa também anunciou que a data de lançamento norte-americano seria em 4 de novembro de 2010 (WASH, 2010). O orçamento de publicidade do Kinect, foi U$ 500 milhões, uma quantia maior que o investimento no lançamento do console Xbox 360, a campanha de marketing Você é o controle!, teve objetivo de atingir novos públicos, incluindo os anúncios nas caixas de cereais Kellogg s e garrafas de Pepsi, entre outras formas de propaganda. (LEVINE, 2010). 3.4 CARACTERÍSTICAS DO KINECT Uma das caracteristicas do Kinect é a câmera. Esse periférico é baseado no estilo add-on webcam, que permite aos usuários controlar e interagir sem a necessidade de usar um Joystick, através da uma interface natural usando gestos e comando de voz (LEVINE, 2010). A técnica 3D utilizada na câmera do Kinect é conhecida como time-of-flight (TOF), que foi baseada no eco; você emite um som ou pulso de rádio, e mede o tempo que demorá até o som bater em um determinado objeto e retornar, sendo assim, podemos cálcular a distância entre o objeto que o som atingiu, pois conhecemos a velocidade do som ou da luz, o mesmo processo da câmera fotografica, só que neste caso cada sensor possui um radar independente, de qualquer forma, seria muito complicado realizar esse cálculo se o objeto estivesse a uma longa distância, devido o tempo para se realizar esse cálculo, pensando nisso e que foi determinado a distânica entre o objeto e o raio de luz, para que o cálculo pudesse ser mais simples (QUEIROZ, 2010).

29 29 Conforme a Tabela 2, segue informações técnicas da câmera do dispositivo. Tabela 2 - Especificação técnica da câmera Kinect ESPECIFICAÇÃO Campo de visão (Horizontal, 58º H, 45º V, 70º D vertical, Diagonal) Profundidade do tamanho da VGA (640x480) imagem Resolução espacial x/y (a 2m de 3mm distância do sensor) Profundidade da resolução z(a 2m 1cm de distância do sensor) Rendimento máximo da imagem 60FPS (frame-rate) Alcance da operação 0.8m to 3.5m Tamanho de imagens a cores UXGA(1600x1200) Audio, Microfones incorporados Dois Audio entradas digitais Quatro Interface dos dados/alimentação de USB 2.0 energia Consumo 2.25W Ambiente da operação Fechado, todas as condições de iluminação Temperatura ambiente 0º C 40ºC Fonte: EUROGAMER(2011). A Figura 9 demonstra suas funcionalidades, o dispositivo fica sobre uma base com eixo-motorizado, permitindo que o sensor se mova de acordo com as necessidades do usuário (ABRÃO, 2010). Tendo como principal obrigatoriedade que o usuário fique a uma distância mínima de 1,2 metros e máxima de 3,5 metros, para que o dispositivo possa reconhecer o usuário como jogador (ABRÃO, 2010).

30 30 Figura 9 - Sensores Kinect Fonte: GUGELMIN (2010) A área de jogabilidade para usuário capturado pelo dispositivo é de 6m², um campo de visão angular de 57 graus na horizontal e de 43 graus na vertical, enquanto o pivô motor é capaz de inclinar-se até 27 para cima ou para baixo, conforme pode ser visto na Figura 9 (ABRÃO, 2010). Esse sensor funciona em qualquer condição de iluminação, onde o periférico projeta o infravermelho IR, e o sensor CMOS (complementary metal-oxidesemiconductor), na língua portuguêsa significa semicondutor metal-óxidocomplementar. É um tipo de tecnologia empregada na fabricação de circuitos integrados de lógica digital (portas-lógicas, flip-flops, contadores, decodificadores, etc.), microprocessadores, memórias RAM, entre outros, tudo isso para capturar informações em 3D (ABRÃO, 2010). A outra câmera, RGB-D (permitindo distinção do eixo Z, reconhecendo objetos em 3D) é utilizada em celulares, que reconhece o rosto e exibe vídeos, esse dispositivo tem resolução de 640x480 pixels e captura imagem em 30 vezes por segundo (QUEIROZ, 2010). O segredo são os feixes infravermelhos, lançados sob o ambiente e que fica imperceptível, assim o sensor CMOS, (Figura 10) faz o restante da análise, que é a uma câmera ativa de detecção de profundidade utilizando uma abordagem estruturada de luz (usando o que parece ser um laser L.E.F. infravermelho e espelhando uma matriz de micro pontos), que também envia profundidade de

31 31 imagens de 640x480 pixels, embora pareça que nem todos os pixels são mostrados em cada frame (QUEIROZ, 2010). Figura 10 - Movimento padrão de reconhecimento do kinect Fonte: GUGELMIN (2010) O microfone multidirecional faz com que o sensor identifique a acústica do ambiente não capturando os ruídos, reconhecendo somente a voz do usuário. Esses microfones são espaçados um a esquerda e os outros três a direita, voltados para baixo de forma que a frente do dispositivo permança livre, e o reconhecimento de voz possui um sistema chamado de open-mic, pronto para receber o comando do usuário (FISHER, 2010). Já o driver do dispositivo, é um software de baixo nível que depende do hardware e do sistema operacional específicos, para atuar como um tradutor entre o dispositivo, o hardware, aplicações ou sistemas operacionais que utiliza-lo permitindo assim que o Kinect seja instalado como um dispositivo, podendo interagir com programas de computador de nível superior (MAN e MINTZ, 2011). Esse equipamento pode ser utilizado para o desenvolvimento multi-plataforma e multi-programação em PCs e outros dispositivos, aproveitando a cor e profundidade (RGB-D) de detecção de câmera, acelerômetros e microfones ou controlar o motor em rotação e inclinação (QUEIROZ, 2010). Os benefícios dessa tecnologia são amplos e potencialmente, podem ser aplicados em diversas áreas como a robótica, virtual multi-touch, interação homemmáquina, vigilância, educação, captura de movimento, ou objetos de rastreamento,

32 32 captura de vídeo 3D ou detecção de imagem (scanning), entre outros (MAN e MINTZ, 2011). Figura 11 - Visão Infravermelho, pattern do Kinect Fonte: STANFORD (2011) A Figura 11 mostra uma câmera com sensor que envia os raios infravermelhos. O cálculo da distância entre o objeto, baseia-se no raio de retorno. Quanto menor é a distância, mais brilhante é o ponto (FISHER, 2010). Então, o Kinect pode ser definido como um dispositivo, onde o sensor de profundidade projeta o laser infravermelho combinado com o sensor CMOS monocromática, que capta dados de vídeo em 3D, sob quaisquer condições de luz ambiente, sendo a distância de detecção do sensor de profundidade ajustável, e o software é capaz automaticamente, de calibrar o sensor baseado nas caraciterísticas física do jogador e seu ambiente, acomodando a presença de móveis ou outros obstáculos para reconhecimento total do corpo (BOURKE, 2010). E possível localizar um exemplo de código com as funções utilizadas para mapear apartir das câmeras do Kinect uma imagem em 3D, que foi desenvolvido por Mattheus Fischer, e possivel visualizar um trecho desse código em ANEXO A (FISHER, 2010).

33 33 4 FRAMEWORKS Este capítulo aborda os tipos de frameworks existentes desenvolvidos para ser utilizado em conjunto com o dispositivo Microsoft Kinect, descrevendo suas características e funcionalidades. 4.1 OPENNI O Microsoft Kinect utiliza como já citado anteriormente, o framework OpenNI que foi desenvolvido para realizar a interação entre dispositivos, aplicações e middleware, essa organização sem fins lucrativo, fornece sua API em código aberto (OPENNI, 2011). OpenNI que significa Open Natural Interaction, é um framework multi-idioma e multi-plataforma que define as APIs para o desenvolvimento de aplicações utilizando dispositivos de interação natural (OPENNI, 2011). O OpenNI, fornece diversos módulos e bibliotecas, que permite o desenvolvedor utiliza-lo com qualquer equipamento que possua um sensor, esse algoritmo pode ser calculado pela entrada de dados no sensor, podendo ser o corpo humano, mãos, mapas (OPENNI, 2011). Esse framework atende as seguintes linguagens: C++ e C#, e sua principal vantagem é ser utilizado em outros sensores visuais e dispositivos além do Microsoft Kinect (SEN, 2011). O framework OpenNI permite conectar sensores que enviam dados brutos ao middleware que vai analisar esses dados e encaminhar para outros middleware, onde finalmente esses dados serão enviados para a aplicação, que pode ser um dispositivo, como uma TV ou vídeo game (SEN, 2011). 4.2 SOFTWARE DEVELOPMENT KIT (SDK) O Software Development Kit (SDK) Beta da Microsoft Research foi desenvolvido para facilitar pesquisas acadêmicas e auxiliar as comunidades a desenvolver novas ferramentas através da tecnologia do sensor do Microsoft Kinect em computadores que executa o Windows Seven (RESEARCH MICROSOFT, 2011). A seguir a tabela 4 indica os principais requisitos de hardware e software para a instalação do SDK (RESEARCH MICROSOFT, 2011).

34 34 Tabela 3 - Requisitos para instalação do SDK REQUISITOS DE HARDWARE: Computador com um processador dual - core 2,66 GHz ou mais rápido Capacidades 2GB de RAM Kinect para Xbox 360 sensor edição especial que inclui cabo USB Para a amostra de fala (x86 apenas) REQUISITOS DE SOFTWARE: - Windows seven compatível com placa gráfica que suporte o Microsoft DirectX 9.0c (x86 ou x64) - Microsoft Visual Studio 2010 Express ou outra edição do Visual Studio Microsoft. NET Framework 4 (instalado com o Visual Studio 2010). Para C++ amostras Skeletal Viewer - DirectX Software Development Kit Junho de 2010 ou versão posterior. - DirectX End-User Runtime Web Installer - Plataforma Microsoft Speech - Runtime Server = Versão 10.2 (Edição x86) - Plataforma Microsoft Speech - Software Development Kit, Versão 10.2 (Edição x86) - Kinect para Windows Runtime versão 0.9. (modelo acústico da Microsoft Speech Plataforma SDK beta). Fontes: Research Microsoft (2011) O SDK Beta da Microsoft possui (RESEARCH MICROSOFT, 2011): I. Drivers para a utilização do dispositivo Kinect em um computador que está executando o Windows Seven; II. APIs e interfaces do dispositivo, juntamente com a documentação técnica para desenvolvedores; III. Amostras de código fonte. O Windows SDK beta para Kinect inclui drivers e APIs, para os fluxos de

35 35 sensor e rastreamento de movimento humano, documentação, instalação e recursos materiais. Esse material fornece capacidades para os desenvolvedores que criam aplicativos com C++, C# ou Visual Basic, usando o Microsoft Visual Studio 2010 (RESEARCH MICROSOFT, 2011). Para o rastreamento do esqueleto é necessário que as figuras em movimento não fiquem muito próximas a câmera, pois pode produzir resultados não confiáveis ou ímpar. A faixa ideal é de aproximadamente cerca de 1,2 a 3,5 metros (RESEARCH MICROSOFT, 2011). Esse framework suporta o rastreamento de pipeline esqueleto, mas não inclui suporte para velocidade ou rotação. Existem duas versões da amostra SkeletalViewer que estão no SDK beta (RESEARCH MICROSOFT, 2011): I. C++ versão que usa o Microsoft Direct3D 9 e do Windows display gráfico (GDI) para renderizar imagens em uma janela; II. C# versão que demonstra o uso da interface Microsoft Research Kinect Nui usa o gerenciados e Windows Presentation Foundation (WPF) para processamento e gerenciamento de janelas. 4.3 ROBOT OPERATING SYSTEM (ROS) O Robot Operating System, mais conhecido como ROS, é um conjunto de ferramentas e bibliotecas que visa ajudar o desenvolvedor. Foi criado em 2007 pelo Laboratório de AI de Stanford, nele é feita a parte de abstração em relação ao hardware, sua funcionalidade mais utilizada em troca de mensagens em nós (ROS.ORG, 2011). O ROS atualmente tem sua versão recomendada para Ubuntu tendo o Windows como parcialmente atendido, apesar de ser mais utilizado em robôs, este trabalho tem uma biblioteca chamada PCL que será utilizada em conjunto com o ROS, por isso é de extrema importância conhecer o ROS e suas funcionalidades uma vez que em conjunto com o PCL o ROS consegue atender o requisito de trabalhar com as mãos.

36 36 O ROS também é multi-plataforma, com isso qualquer desenvolvedor pode utilizar-lo, pois possui interação com equipamentos como o Kinect (ROS.ORG, 2011). 4.4 CANDESCENT NUI Conhecido sob o nome de Candescent, o framework Candescent NUI é uma coleção de componentes de software que formam um framework desenvolvido por um grupo de estudantes independentes e foi disponibilizado na Internet para compartilhamento e desenvolvimento cooperativo, através do mundo de uma plataforma de software para visualização, reconhecimento e manipulação de gestos humanos através de dispositivos de detecção de movimentos, como por exemplo, o dispositivo Kinect da Microsoft (STEGMUELLER, 2011). Desenvolvido na linguagem de programação C# e tendo como base para o framework Candescent encontra-se disponível para livre download no site do CandescentNui sob a modalidade de licenciamento New BSD License (BSD) (STEGMUELLER, 2011) Funcionalidades O Candescent é um framework que permite aos seus desenvolvedores a possibilidade de através do seu uso abstrair uma série de conceitos e técnicas que são necessários de serem entendidos e desenvolvidos quando da construção de sistemas de software e/ou algoritmos de manipulação e reconhecimento de gestos (STEGMUELLER, 2011). Suportando essa abstração que é muito importante para os desenvolvedores que utilizam este framework no capitulo a seguir será abordado mais detalhadamente às funcionalidades deste framework. O Candescent disponibiliza uma série de funcionalidades que são suportadas através de suas classes e métodos, e que permitem ao desenvolvedor criar e estender mecanismos de detecção e reconhecimento de gestos, essas funcionalidades são suportadas por componentes de softwares e algoritmos construídos em C# e que constituem o cerne do framework do Candescent.

37 37 Em sua versão mais recente, a versão Release Candidate 9489, o Candescent disponibiliza um projeto que permite a visualização de exemplos de funcionalidades que atualmente são suportadas no framework (STEGMUELLER, 2011) Arquitetura do Candescent A arquitetura do framework Candescent descreve o conjunto de componentes físicos e lógicos que permitem seu funcionamento. Cada camada da arquitetura do framework (Figura 12) endereça um componente que é acionada por outro componente em outra camada e que aciona outros componentes em outras camadas (STEGMUELLER, 2011). Figura 12 - Arquitetura do framework Candescent Fonte: Autores (2011) O framework Candescent está localizado entre a camada de aplicação (camada da arquitetura onde se localizam as aplicações onde os usuários interagem) e a camada de middleware, camada onde se localizam os softwares que

38 38 são responsáveis por disponibilizar meios de acesso aos dispositivos de captura de movimento (STEGMUELLER, 2011). Através da tabela 4 é possível visualizar as vantagens e desvantagens dos frameworks analisados. Tabela 4 - Vantagens e Desvantagens dos Frameworks FRAMEWORK VANTAGENS DESVANTAGENS OPENNI SDK MICROSOFT ROS CANDESCENT NUI - Multi-plataforma; - Módulos e bibliotecas; - Perfeita conexão com o Kinect; - Reconhecimento do esqueleto humano; - Software livre; - Documentação; - Mãos e dedos; - Processo de Instalação, - Variedades de bibliotecas; - Baixo nível; - Reconhecimento de Mãos e dedos; - Instalação complicada; - Execução de códigos; - Falta documentação, - Complexidade; Fonte: Autores (2011)

39 39 5 METODOLOGIA Uma prova de conceito se baseia no princípio de que é possível se provar que algo possa ser imaginado, desenhado e construído atendendo a requisitos préestabelecidos como, por exemplo, requisito de qualidade, de preço, de tecnologia de normas e independentemente de quais requisitos atendidos a premissa é a mesma, se provar que o conceito funciona (MARTINS, 2010). O desenvolvimento desse trabalho tem como objetivo a prova de conceito de que tecnologias de captura e reconhecimento de movimentos podem ser utilizadas como ferramentas para interpretação de gestos e sinais e para suportar as inúmeras variáveis inseridas nesse contexto, várias pesquisas foram iniciadas, várias instalações de componentes de software foram realizadas, testes executados e análises feitas. Este capítulo aborda o conjunto de procedimentos (metodologia) realizados durante o projeto incluindo os procedimentos de instalação, análise e resultados obtidos referentes às pesquisas feitas sobre os frameworks selecionados para o desenvolvimento do protótipo KINLIB. Este estudo foi fundamental para a escolha do framework que melhor atendese o desenvolvimento do KINLIB. 5.1 INSTALAÇÃO, ANALISE E RESULTADOS DOS FRAMEWORKS Como já informado anteriormente, o Microsoft Kinect foi desenvolvido para utilização no vídeo game Xbox 360, e para realizar esse projeto foi necessário a instalação do dispositivo em um computador, sendo assim possível sua analise interna e desenvolvimento. A instalação do OpenNI foi realizada em um sistema operacional Windows Seven Profissional de 64 bits e para que o computador reconheça o Kinect foi necessário utilizar os seguintes aplicativos (KINECTHACKS, 2010): 1 - Driver para reconhecimento do kinect: dpinst-amd64.exe; 2 - OPENNI-Win exe; 3 - SensorKinect-Win exe; 4 - NITE-Win exe.

40 40 Além dos aplicativos informados anteriormente, são necessários alguns arquivos XML's do NITE e do OpenNI, localizados no site dos desenvolvedores dos Frameworks (KINECTHACKS, 2010). O ambiente de desenvolvimento e testes utilizado foi o Visual Studio C+ e a linguagem utilizada C++. Também foi necessário utilizar o SDK do DIRECTX, o pacote do Visual Studio 2010 e o drive Nvidia CG. Além desse procedimento de instalação, existem outros para a plataforma Windows e versões anteriores, também é possível utilizar outras linguagens de programação para o desenvolvimento de novos recursos do Microsoft Kinect, contudo para este framework não foram realizados testes em plataformas de 32 bits (KINECTHACKS, 2010). A vantagem de se utilizar OpenNI é porque ele trabalha sobre Windows e Linux, dando maior liberdade de desenvolvimento, porém esse framework é muito complexo para ser instalado, além disso juntamente com esses SDK s ele apresentou conflito na máquina. O SDK da Microsoft como informado anteriormente é o framework liberado pela própria Microsoft para que estudantes, acadêmicos e desenvolvedores, pudessem exploras os recursos e funcionalidades do Kinect e desenvolver outras aplicações voltadas para o dispositivo. Para o procedimento de Instalação do SDK da Microsoft, o instalador deve ser baixado no site da Microsoft Research, lembrando que essa é a versão beta, sendo suportado apenas pelo Windows Seven (RESEARCH MICROSOFT, 2011). Figura 13 - Visualização do esqueleto SDK Microsoft Fonte: MICROSOFT RESEARCH (2011)

41 41 A vantagem de utilizar o SDK é sua perfeita conexão com o Microsoft Kinect uma vez que possui todos os drives necessários e códigos fontes de exemplos para poder manipular o dispositivo, esse framework permite também reconhecer até dois esqueletos simultaneamente (Figura 13) utilizando o Kinect. A desvantagem encontrada ao utilizar o SDK da Microsoft é que o ele ainda não permite o reconhecimento dos dedos e palma das mãos (Figura 13) fazendo com que esse framework fosse inviável para a realização do presente trabalho. O ROS é um framework desenvolvido a principio para utilização em Robôs, porém esse framework foi selecionado para analise devido o grande número de desenvolvedores o utilizar em conjunto com o Kinect. Para o procedimento de instalação e analise do ROS foi utilizado os comandos do próprio site do ROS, onde se deve primeiramente adicionar o http no arquivo source.list, após atualizar o sistema e instalar a chave do mesmo, deve-se usar o comando apt-get para instalar o pacote ros-electric-desktop-full (ROS.ORG, 2011). Para criar o ambiente do ROS é necessário criar a pasta chamada ros_workspace no home do usuário, como está sendo baseando na versão estável do ROS, está sendo usado o Ubuntu Apos criar o ambiente deve-se executar o arquivo setup.sh através do comando (. setup.sh) (ROS.ORG, 2011). A simulação do ROS no kinect deve-se aos exemplos executados do próprio site, onde se deve criar o ambiente de acordo com a estrutura de pastas e através do comando roslauch executar o mesmo, no caso foi utilizado o exemplo do hand_tracking que foi criado através do comando rosmake nome do projeto. Depois de criado deve-se criar a estrutura de diretórios com os arquivos responsáveis pela execução, para executar o projeto precisa estar na pasta lauch e executar o comando roslaunch (ROS.ORG, 2011). Uma das vantagens do ROS e a vasta documentação que permite ao desenvolvedor conhecimento amplo em relação a ferramenta, o software e livre neste caso seu código e aberto, o que torna possível trabalhar em baixo nível. Devido sua utilização principalmente no Linux, encontramos dificuldades na montagem do ambiente de teste, e execução dos códigos de exemplo. O Candescent é um framework que possui algumas premissas de instalação que devem ser atendidas para que funcione sem problemas, seja através de seus executáveis ou através da compilação dos seus códigos fontes.

42 42 Os componentes de software ou middlewares que o framework Candescent necessita são o OpenNI, o Kinect Drivers, e o NITE os quais são pré-requisitos para a instalação do Candescent. Os middlewares citados, o OpenNI, o Kinect Drivers, e o NITE, irão dar suporte apenas a seleção de middleware do OpenNI quando da execução do Candescent, por isso, caso seja preciso selecionar o middleware SDK Kinect quando da execução do Candescent é necessário instalar o SDK Microsoft do Kinect na máquina. Como alternativa para a instalação do pacote de software para o OpenNI é possível acessar fazer o download de um instalador (disponibilizado gratuitamente), o qual realiza de forma transparente e automática toda a instalação OpenNI, o Kinect Drivers, e o NITE (BREKEL, 2011). Com relação ao processo de instalação do SDK Kinect da Microsoft é necessário acessar o site da Microsoft e fazer o download do instalador do SDK (RESEARCH MICROSOFT, 2011). Após a instalação de todos os componentes de software mencionados, o Candescent (Figura 14) poderá ser executado. Figura 14 - Execução do Candescent a partir do Visual Studio Fonte: Autores (2011) Através dessa profunda análise foi tomada a decisão de escolher o Candescent como framework de suporte para construção da prova de conceito do projeto.

43 43 Entre os pontos levados em consideração está principalmente à funcionalidade de captura de movimentos das mãos e dedos a qual foi um diferencial de todos os outros frameworks estudados e será a base para inicio do desenvolvimento da prova de conceito. Essa funcionalidade é fundamental dentro do framework Candescent no sentido de ser a funcionalidade que gera as informações fundamentais para a exibição das linhas e contornos das mãos e dedos e a partir das quais é possível se determinar a posição corrente de cada elemento em tela. E essas funcionalidades são detalhadas a seguir: A. Seleção de Middleware Essa funcionalidade é uma das mais importantes do framework, pois permite ao desenvolvedor escolher e selecionar através de qual middleware o framework irá funcionar interagindo com o dispositivo físico de detecção de movimento. O Candescent permite a seleção de dois middleware (Figura 15), o OpenNI e o SDK Kinect. O OpenNI e SDK, atuais alternativas no framework Candescent, possuem cada um suas vantagens e desvantagem as quais devem ser levadas em conta no momento da escolha e isso possibilita ao desenvolvedor a capacidade de trabalhar com o middleware que mais possui conhecimento e experiência. Figura 15 - Seleção de middleware (OpenNI/SDK Microsoft) Fonte: Autores (2011)

44 44 B. Coleta de dados em RGB A coleta de dados de imagem é fundamental para que qualquer framework que se proponha a detecção de movimento funcione e tenha alto grau de eficiência e qualidade, pois é através dos dados das imagens coletadas (Figura 16), que todo o processamento computacional e gráfico acontece. Essa funcionalidade de coleta de dados de imagem não é primariamente um mérito do framework Candescent, mais sim dos dois middlewares, OpenNI e SDK da Microsoft que trabalham abaixo do Candescent trazendo esses dados do dispositivo físico, contudo, o framework Candescent possui o mérito de conter estruturas de dados e algoritmos capazes de absorver esses dados e expô-los em um nível de abstração mais elevado aos desenvolvedores que o utilizam. Figura 16 - Coleta de dados de imagem através do framework Candescent Fonte: Autores (2011) C. Coleta de dados de IR Uma das funcionalidades mais interessantes que o framework Candescent suporta é a capacidade de coletar os dados de IR (infravermelho) provenientes dos equipamentos físicos de captura de movimento, como por exemplo, o Kinect. A coleta de imagem em infravermelho (Figura 17) permite a detecção de profundidade da cena exposta ao equipamento físico de captura de imagem bem como o reconhecimento de movimento e é somente através da capacidade do

45 45 framework Candescent absorver essa funcionalidade que o desenvolvedor pode utilizar os recursos de reconhecimento de movimento. Figura 17 - Coleta de dados em Infravermelho no Candescent Fonte: Autores (2011) Ainda como parte da funcionalidade de coleta de dados de imagem em infravermelho IR o framework Candescent possui a característica de fusão de imagens, sobreposição de imagens permitindo ao desenvolvedor a capacidade de visualizar ao mesmo tempo os dados coletados da imagem em infravermelho e as informações geradas pelo framework, como por exemplo, conforme mostra a Figura 18, a detecção em tempo real de movimento. Figura 18 - Sobreposição das imagens de infravermelho e detecção Fonte: Autores (2011)

46 46 D. Detecção de mãos e dedos A funcionalidade de detecção de mãos e dedos é uma das funcionalidades mais interessantes que existem no framework, pois antes de qualquer outro ponto, essa funcionalidade é totalmente desenvolvida dentro do framework Candescent através do processamento dos dados obtidos dos dispositivos de captura de movimento suportados. Através das funcionalidades de captura de dados de RGB e IR o framework Candescent realiza uma série de processamentos com o auxilio de suas estruturas de dados e algoritmos permitindo a detecção de pontos dentro do mapa da imagem processada. O rastreamento desses pontos permite ao desenvolvedor manipular suas estruturas a fim de detectar não somente a quantidade de mãos e dedos como também a sua posição nas coordenadas X, Y e Z (Figuras 19 e 20). Figura 19 - Detecção de mãos e dedos no framework Candescent 1 Fonte: Autores (2011) Figura 20 - Detecção de mãos e dedos no framework Candescent 2 Fonte: Autores 2011)

47 47 E. Manipulação de imagens Outra funcionalidade muito interessante do framework Candescent é a possibilidade de ver através do aplicativo de exemplo, a fusão das funcionalidades de captura de dados de infravermelho e detecção de movimentos de mãos e dedos aplicados à manipulação de imagens (Figura 21). Figura 21 - Exibição de imagens no framework Candescent Fonte: Autores(2011) A funcionalidade de captura de infravermelho fornece ao desenvolvedor a possibilidade de detecção do movimento e profundidade das mãos e dos dedos. Através da funcionalidade de detecção de mãos e dedos é possível se determinar a trajetória que a imagem deve percorrer. No caso do aplicativo de exemplo é uma fotografia (Figura 22). Figura 22 - Interação com imagens no framework Candescent Fonte: Autores (2011)

48 48 Figura 23 - Manipulação de imagens no framework Candescent Fonte: Autores (2011) Na Figura 23 é possível verificar a funcionalidade de manipulação de imagens em funcionamento na qual o usuário através de um dispositivo de captura de movimentos, como por exemplo, o Kinect, pode, ao movimentar suas mãos, manipular as imagens exibidas na tela. Figura 24 - Mecanismos fornecidos pelo framework Candescent Fonte: Autores (2011)

49 49 É essa funcionalidade do framework Candescent que será estendida através de várias novas classes e algoritmos a fim de complementar essa versão do framework do Candescent com um novo módulo adicional de interpretação dos movimentos capturados, sejam esses movimentos das mãos ou dos dedos (Figura 24), realizando dessa forma não somente a apresentação dos movimentos capturados das mãos e dedos, mas sim a captura, análise, interpretação e apresentação dos resultados obtidos.

50 50 6 PROJETO Este capítulo tem como objetivo abordar as fases envolvidas no ciclo de vida de desenvolvimento do protótipo que suportará a prova de conceito de reconhecimento de sinais através da análise dos dados coletados no dispositivo físico de captura, da interpretação de movimentos e do reconhecimento dos gestos das mãos e dedos. Utilizando o dispositivo físico Microsoft Kinect para captura de movimentos e o framework Candescent como base da arquitetura de software. Ao final desse capítulo será possível entender através de registros documentais o processo de construção do KINLIB, incluindo as decisões sobre os protótipos das telas, das decisões de modelagem da arquitetura e componentes core para interpretação e reconhecimento dos dedos, e os mecanismos de testes a fim de garantir que a prova de conceito seja possível e viável. 6.1 MODELAGEM Baseado na premissa de suportar a prova de conceito de reconhecimento de sinais, o protótipo KINLIB tem como uma das suas principais metas o suporte ao reconhecimento dos dedos e através do uso e customização das funcionalidades embarcadas e disponíveis dentro do framework Candescent. Visando a necessidade de atender aos requisitos funcionais da prova de conceito, o projeto construiu a modelagem do aplicativo com o objetivo que essa modelagem fosse ao mesmo tempo totalmente aderente à plataforma e arquitetura do Candescent, e flexível ao ponto de permitir a construção de customizações que visa desenvolver o reconhecimento dos dedos. Para composição e documentação da modelagem do KINLIB são expostos a seguir os dois principais componentes produtos da fase de Modelagem do KINLIB Arquitetura do KINLIB A arquitetura de software é o conjunto de componentes de softwares organizados de forma estruturada que servirá de base para provisão de serviços ao aplicativo a ser desenvolvido.

51 51 No escopo da Prova de Conceito do KINLIB, a arquitetura foi projetada baseando-se nos componentes de software encontrados durante a pesquisa bibliográfica e que principalmente atenderam as necessidades funcionais do escopo da Prova de Conceito, como por exemplo, e crucial, capacidade de capturar e reconhecer movimentos. Nesse cenário, dois componentes foram cruciais no desenho de escopo da arquitetura do KINLIB, são eles o OpenNI e Candescent. O OpenNI como já comentado nos capítulos anteriores, é responsável, dentro da arquitetura de software do KINLIB, pela leitura e disponibilização para os aplicativos de mais alto nível dos dados das imagens capturadas, sejam em RGB ou Infravermelho permitindo dessa forma que outros componentes de software, com abstrações ainda maiores sejam construídas, como no caso, o próprio framework Candescent, que está presente na arquitetura do KINLIB como parte integrante e crucial da Prova de Conceito. O KINLIB foi desenvolvido como uma customização do Candescent, adicionando componentes de software, algoritmos e estendendo funcionalidades existentes criando dessa forma uma versão personalizada, com o objetivo de atender as necessidades da Prova de Conceito do KINLIB. A Figura 25 apresenta a arquitetura em alto nível da Protótipo KINLIB e as camadas existentes. Figura 25 - Componentes da arquitetura do KINLIB 1 Fonte: Autores(2011)

52 52 É possível identificar claramente na Figura 25 duas camadas acima do framework Candescent e isso existe devido ao fato do KINLIB criar no nível lógico, ainda que dentro do Candescent, duas camadas de abstração adicionais, sendo uma camada dedicada aos componentes de reconhecimento de gestos e a outra camada é a própria Prova de Conceito do KINLIB, que está no topo da arquitetura consumindo todos os recursos disponibilizados pela arquitetura. A seguir são descritas cada uma das camadas da Arquitetura do KINLIB. A) Camada de Componentes de Hardware: Na arquitetura de software do KINLIB se encontram os dispositivos físicos de captura de movimento. Conforme indicado na Figura 25 existem três tipos possíveis de captura de movimento, mesmo que ainda unificados dentro de um mesmo equipamento físico, no caso o Kinect.Os tipos de captura de movimentos indicado são: o áudio, a imagem normal e a imagem em infravermelho. Através da captura de áudio é possível haver reconhecimento do mesmo e interação com o usuário. As câmeras de RGB e Infravermelho permitem não somente a visualização de imagens normais, quanto à detecção de movimentos em infravermelho. O KINLIB não faz uso do suporte a áudio do Kinect, pois usa somente as câmeras de RGB e Infravermelho dentro da prova de conceito. B) Camada de Middleware: A camada de middleware é a camada na qual se encontram os componentes de software do aplicativo de middleware que é responsável pela abstração das funcionalidades do componente físico de captura de movimentos. Atualmente na versão Release Candidate 9489, o framework Candescent suporta a conexão com dois tipos de middleware, o OpenNI e o SDK Microsoft, contudo apenas o OpenNI está sendo utilizado no KINLIB conforme indicado na Figura 25. C) Camada de Framework (Candescent): A camada de framework é a camada mais importante do projeto de Prova de Conceito do KINLIB uma vez que é onde se localiza dois componentes cruciais do

53 53 projeto, o framework Candescent e dentro dele o módulo de interpretação de gestos, chamado de Gesture Recognition Components Implementation, ele é o componente dentro da arquitetura do KINLIB responsável por abstrair as funcionalidades dos níveis mais abaixo da arquitetura e por fornecer as condições para que o módulo de interpretação de gestos possa ser desenvolvido. O módulo de interpretação de gestos está logicamente acima da camada do framework Candescent apesar de tecnicamente ser um projeto dentro dele. Dessa forma, como um projeto dentro da solução do Candescent, o KINLIB pode utilizar-se de todos os recursos disponibilizados pelo Candescent. Dentro do módulo de interpretação de gestos do KINLIB está a lógica de interpretação de gestos capturados pelo dispositivo físico. A Figura 26 demonstra os componentes lógicos da arquitetura do KINLIB envolvidos na interpretação de gestos. Repare que diferentemente da Figura 25, a arquitetura apresentada na Figura 31 se diferencia da arquitetura original do Candescent por apresentar mais um componente, o componente #3, localizado logo após a etapa de processamento de dados de imagem e antes da etapa apresentação dos mesmos, o qual é chamado de etapa de Reconhecimento de Dados. Essa nova etapa, suportado por um novo componente de software, permite ao Candescent, através do KINLIB, a capacidade de reconhecimento de gestos pré-determinados. Figura 26 - Componentes da Arquitetura do KINLIB 2 Fonte: Autores(2011)

54 54 D) Camada de Usuário (KINLIB) Visa atender as expectativas dos usuários quando o KINLIB foi desenvolvido uma nova tela para interação do usuário, conforme já visto anteriormente. Essa tela é suportada pela camada da arquitetura que é chamada de Camada de Usuário. Nessa tela são apresentados valores, dados e informações cruciais ao entendimento da Prova de Conceito. É a partir dessa camada que todas as chamadas de métodos são acionadas e então todo o processamento do KINLIB é iniciado e é justamente por essa razão que essa camada se localiza no topo da arquitetura Design A fase de Design é a fase que antecede o desenvolvimento e é por meio dessa fase que os principais artefatos de software são gerados. No protótipo KINLIB a modelagem foi criada a partir do estudo, análise e construção dos diagramas de classe e diagramas de seqüência para posterior desenvolvimento do projeto. A primeira atividade na fase de Design foi à criação do diagrama de classe que representa os componentes de software responsáveis pelo KINLIB dentro da ferramenta de desenvolvimento Visual Studio Figura 27 - Diagrama de classe dos componentes do KINLIB Fonte: Autores(2011)

55 55 A Figura 27 representa o Diagrama de Classe que indica as classes e interfaces envolvidas no pacote de reconhecimento de gestos e o qual é composto por três classes e uma interface. As classes indicadas na Figura 27 foram desenhadas para serem as classes responsáveis pela interpretação e reconhecimentos dos dedos que possibilita a representação da linguagem de Sinais que são capturados através do dispositivo físico, que no caso do KINLIB, é o Kinect. As funções de cada uma das classes e interfaces são descritas brevemente a seguir: A) Classe Gesture É responsável por suportar as estruturas de armazenamento e pesquisa dos nomes dos gestos que são reconhecidos através do KINLIB e que são quatro: o gesto que representa os números um, dois, três e quatro. A Figura 28 indica a representação desses gestos na língua de Sinais. Figura 28 - Sinais reconhecidos pelo KINLIB Fonte: Autores(2011) B) Classe RecognitionData Estrutura simples de Value Object que é responsável por transportar as informações de identificador único do gesto (ID) bem como o texto que representa o seu nome (Nome do gesto). A classe RecognitionData é instanciada a cada vez que um novo gesto é reconhecido e então a mesma é enviada a camada de apresentação do KINLIB e então apresentada em tela.

56 56 C) Classe RecognitionGesture Foi criada com o objetivo de ser a classe que concentraria os algoritmos de reconhecimento de gestos, ou seja, a classe que é responsável por determinar se algum dos gestos reconhecidos pelo KINLIB (Figura 28) foi possível de ser reconhecido. Para realizar esse trabalho de reconhecimento de gestos, a classe RecognitionGesture possui um método chamado scangesture o qual contém todas as regras de reconhecimento de gestos. D) A Interface IRecognitionGesture A criação dessa interface se destinou a permitir o encapsulamento das funcionalidades da classe RecognitionGesture no sentido que somente as funcionalidades métodos existentes na interface IRecognitionGesture poderiam ser visíveis ao projeto KINLIB uma vez que a classe RecognitionGesture realiza a interface IRecognitionGesture. A segunda grande atividade foi entender em que momento o conjunto de classes e interfaces seriam utilizados dentro do KINLIB incluindo quem iria os acionar, como iriam ser acionado e quem eles iriam acionar. Para atender essa demanda foi criado um Diagrama de Seqüência, o qual é apresentado na Figura 29. Figura 29 - Diagrama de Seqüência dos componentes do KINLIB Fonte: Autores(2011)

57 57 É possível verificar que o Diagrama de Seqüência inicia no método Paint e a partir dele aciona as classes envolvidas no reconhecimento e exibição das informações. 6.2 DESENVOLVIMENTO O desenvolvimento do projeto KINLIB foi realizado na ferramenta Visual Studio 2010 utilizando-se a linguagem C#. A escolha da linguagem de programação C# também ocorreu devido ao fato do framework Candescent ter sido desenvolvido nessa linguagem o que permitiu ao projeto integrar e transacionar com o framework de modo transparente. Visando demonstrar como o projeto do KINLIB foi desenvolvido, a seguir serão apresentadas as visões de como o projeto foi estruturado e como os códigos desenvolvidos suportaram o reconhecimento de gestos dentro do KINLIB Estrutura do projeto A estrutura do projeto KINLIB foi baseada na mesma estrutura de Solução do Candescent uma vez que seria transparente ao projeto a integração do KINLIB ao Candescent. Para suportar integração entre a Solução do Candescent e o projeto do KINLIB (dentro do Visual Studio 2010) o projeto adotou a estratégia de criar um novo projeto, chamado CCT.NUI.Recognition, dentro da Solução do Candescent o qual está atrelado através de referência entre os projetos. Dessa forma, todos os componentes da Solução do Candescent ficam disponíveis ao KINLIB e vice-versa. Todos os projetos possuem a mesma precedência de CCT.NUI no nome do projeto, logo, com exceção do projeto Recognition ainda existem mais quatro projetos dentro da solução do Candescent, sendo eles Core, o qual possuí todas as classes core do framework, o projeto HandTracking o qual possui as classes que dão suporte a detecção das mãos, o projeto Samples a qual possui a tela inicial do KINLIB, e por ultimo o projeto Visual o qual possui as classes atreladas a camada de apresentação. Na Figura 30 é apresentada a estrutura do projeto KINLIB e da Solução Candescent dentro do Visual Studio 2010.

58 58 Figura 30 - Estrutura projeto KINLIB no Visual Studio 2010 Fonte: Autores(2011) Desenvolvimento do projeto O projeto KINLIB gerou vários desafios durante a sua fase de desenvolvimento, programação propriamente dita, uma vez que houve a necessidade de entendimento de boa parte do framework Candescent (estrutura e dinâmica) para que fosse possível a perfeita utilização/consumo dos recursos providos pelos seus componentes de software e a perfeita integração entre o KINLIB e ele. Uma grande parte desse esforço foi realizada na fase de Modelagem, contudo, a parte prática desse desafio ficou para a fase de desenvolvimento no qual foram realizados os testes e a verificação de sucesso da Prova de Conceito. Para atingir esse objetivo foram desenvolvidas algumas customizações e extensões de componentes de software do framework Candescent e a integração deles, contudo, o mais importante foi entender perfeitamente a onde integrar esses desenvolvimentos e customizações.

59 59 A seguir são listados os principais pontos de desenvolvimento feitos para se atingir os objetivos do protótipo KINLIB com as explicações do porque e como foram realizadas. A) Exibição das informações Figura 31 - Código de apresentação de informações no Painel de Informações Fonte: Autores(2011) Um dos primeiros problemas encontrados durante o desenvolvimento foi a criação de uma nova tela principal (customizada) que permitisse a visualização das informações coletadas, processadas e interpretadas pelo Candescent e KINLIB. Para a exibição dessas informações na tela principal foi criada a classe PanelInformation, classe a qual recebeu esse nome por ser responsável de exibir

60 60 as informações processadas pelo KINLIB dentro de um novo painel de informações que é exibido à direta na tela principal. O principal método dessa classe (Figura 31) é drawdatainformation, o qual é responsável por exibir e atualizar as informações dentro do Painel de Informação da tela principal. Existem mais um método dentro dessa classe que se chama drawlabelinformation o qual possui a responsabilidade de imprimir dentro do painel de informações apenas os títulos das informações, como por exemplo, o título Status, Gesto reconhecido entre outros. B) Gestos (Sinais) Visando suportar o reconhecimento dos gestos foi criada uma classe, já demonstrada anteriormente, chamada Gesture a qual possui estruturas de informações para armazenagem e pesquisa dos tipos de Gestos reconhecidos. Os Gestos reconhecidos pelo KINLIB (nessa versão) são os Gestos de Número 1, Número 2, Número 3 e Número 4. A Figura 32 demonstra as estruturas internas da classe. Figura 32 - Estruturas de armazenamento e pesquisa de Gestos no KINLIB Fonte: Autores(2011)

61 61 C) Reconhecimento de Gestos Figura 33 - Algoritmos de interpretação de Gestos do KINLIB Fonte: Autores(2011) A classe mais importante do protótipo KINLIB é a classe criada chamada RecognitionGesture a qual é responsável por conter toda a lógica de reconhecimento de padrões para a tentativa de interpretação dos Gestos processados. Através dessa classe é possível determinar se um dos movimentos previamente suportados pelo KINLIB foi ou não reconhecido e em caso positivo um Value Object é retornado ao chamador da execução o qual obtêm através dessa estrutura o identificador e o nome do gesto reconhecido. Os algoritmos criados para reconhecimento dos Gestos são simples, porém demonstram de forma eficaz a confirmação de que é possível se integrar uma lógica de interpretação de Gestos à arquitetura do Candescent fazendo com que ele não somente capte, processe e exiba as informações como também interprete os Gestos reconhecidos e essa classe é prova de que essa abordagem é possível. Na Figura

62 62 33 é demonstrada a classe RecognitionGesture e seu principal método, o scangesture que é responsável por conter as regras de interpretação de gestos. D) Acionamento do Reconhecimento de Gestos Figura 34 - Acionamento dos métodos de interpretação de Gestos no KINLIB Fonte: Autores(2011) O protótipo KINLIB possui classes e interfaces que são responsáveis pela camada de apresentação do projeto e as quais são herdadas do framework Candescent. Através do estudo e customização de algumas dessas classes é possível realizar o trabalho de integração do framework Candescent com o protótipo KINLIB através do uso dos componentes de software descritos nos itens A, B, C e D anteriormente. A principal classe da camada de apresentação a ser customizada foi a classe HandLayer, a qual é responsável por exibir em tela as informações do contorno da mão, da ponta dos dedos e dos círculos indicando o centro da palma e do centro da mão. Essa classe foi customizada para acionar os componentes de software responsáveis pela interpretação dos gestos quando da apresentação das

63 63 informações em tela, permitindo dessa forma ao KINLIB interpretar os gestos e alimentar o painel de informações com os resultados obtidos, conforme demonstrado na Figura PROTÓTIPO Uma das fases mais importantes no ciclo de vida do desenvolvimento de software e o desenvolvimento do protótipo na qual a forma de acesso e manipulação do software é definida e desenhada. Através da técnica da criação de um protótipo é possível gerenciar de forma simples e com baixo custo às expectativas dos usuários e pessoas envolvidas na utilização do mesmo. Construído na linguagem C# dentro da ferramenta de desenvolvimento Microsoft Visual Studio 2010, o Layout do protótipo do KINLIB é demonstrado nas Figuras 35 e 36. O KINLIB foi elaborado e desenhado tendo como meta a necessidade do software suportar a Prova de Conceito de Reconhecimento de Sinais e atendendo ao mesmo tempo requisitos funcionais como usabilidade, fácil entendimento e visualização das funcionalidades propostas. O protótipo atende um dos mais importantes requisitos coletados durante o projeto que foi a restrição de reconhecimento dos dedos de somente uma das mãos por vez, dado que essa restrição é proveniente do mecanismo de interpretação desenvolvido no KINLIB. Figura 35 - Layout do KINLIB no Microsoft Visual Studio 2010 Fonte: Autores(2011)

64 64 Figura 36 - Layout do KINLIB Fonte: Autores(2011) As preocupações com usabilidade, entendimento e visualização foram endereçadas no Layout do KINLIB através do desenvolvimento de mecanismos na tela de apresentação que são possíveis de serem vistos em tempo de execução do protótipo conforme a Figura 37. Figura 37 - Layout do aplicativo KINLIB em execução Fonte: Autores (2011)

65 65 Esses mecanismos desenvolvidos e inseridos no protótipo facilitam o entendimento do protótipo KINLIB e são descritos nas seções a seguir Conexão ao Kinect O mecanismo de conexão ao Kinect foi inserido no KINLIB como uma forma de permitir ao usuário a possibilidade de visualizar o momento em que o software KINLIB se conecta ao dispositivo físico de detecção de movimento, no caso o Kinect, através do middleware OpenNI (Figura 38). Dessa forma é possível ao usuário final, que utiliza o protótipo KINLIB, saber e detectar quando o seu dispositivo físico apresenta problemas ou quando a conexão entre o aplicativo e o hardware, não pode ser feita com sucesso por qualquer motivo. Figura 38 - Conexão do KINLIB ao Kinect via OpenNI Fonte: Autores(2011) Quadro de informações O quadro de informações foi um mecanismo criado dentro do Layout do KINLIB de forma a auxiliar os usuários a visualizarem as informações produzidas pelo software, uma vez que o objetivo do KINLIB é suportar a prova de conceito e

66 66 para tal todas as principais informações devem estar disponíveis e de fácil visualização. Exibidas dentro do quadro estão às informações a seguir: 1. Status: Indica o status do KINLIB com relação ao reconhecimento de sinais e apresenta os valores Reconhecendo, quando o software está tentando reconhecer os padrões nos gestos lidos, e quando nenhum movimento das mãos e dedos está sendo realizado, o que impede a tentativa de reconhecimento de sinais pelo software; 2. Quantidade de mãos: Exibe a quantidade de mãos detectadas pelo KINLIB e exibidas na tela de apresentação; 3. Quantidade de dedos: Exibe a quantidade total de dedos detectados pelo KINLIB e exibidas na tela de apresentação; 4. Gesto reconhecido: Informação de que alguns dos gestos (dedos) possíveis de serem reconhecidos pelo KINLIB foram lidos, processados, interpretados e reconhecidos como um gesto válido na língua dos sinais; 5. Nome do sinal: Uma vez reconhecido como um gesto válido, essa informação indica o nome de qual gesto foi reconhecido. Figura 39 - Quadro de informações do KINLIB Fonte: Autores(2011)

67 67 A Figura 39 a seguir demonstra o quadro de informações do KINLIB quanto a execução e funcionamento do mesmo. 6.4 TESTES O protótipo KINLIB teve como proposta central a realização da Prova de Conceito para validação da possibilidade de interpretação e reconhecimento de gestos através de um dispositivo físico, que no KINLIB foi o dispositivo Kinect da Microsoft. Essa premissa, definida no início do projeto, é o requisito funcional principal que serviu de insumo e guia para toda a fase de Testes no KINLIB. Os testes realizados nessa fase irão garantir não somente que os quatro gestos, serão reconhecidos e interpretados de forma correta, mas também irão garantir, de forma indireta, que toda a integração entre o protótipo KINLIB e o framework Candescent esteja funcionamento de forma adequada, conforme foi modelado e desenvolvido. Para cada um dos gestos possíveis de serem reconhecidos, os gestos referentes aos números 1, 2, 3, 4, foram executados testes individuais e coletadas evidências garantindo dessa forma a formalização do sucesso dos testes. A seguir são descritos os testes realizados e as evidências coletadas no protótipo KINLIB. A) Caso Base Nenhum gesto Figura 40 - Acionamento dos métodos de interpretação de Gestos no KINLIB Fonte: Autores(2011)

68 68 Foi definido como premissa o cenário de Teste de Caso Base, ou seja, o reconhecimento de nenhum dedo como premissa para o inicio dos testes. Na Figura 40 é demonstrado o não reconhecimento de gestos. B) Teste do Gesto Número 1. Figura 41 - Interpretação e reconhecimento do Número 1 do KINLIB Fonte: Autores(2011) Os testes referentes à interpretação e reconhecimento do número 1 é demonstrado na Figura 41. Pode ser notado que o teste foi realizado com sucesso e o KINLIB reconheceu o gesto. C) Teste do Gesto Número 2. O teste referente à interpretação e reconhecimento do número 2 é demonstrado na Figura 42. Pode ser notado que o teste foi realizado com sucesso e o KINLIB reconheceu o gesto.

69 69 Figura 42 - Interpretação e reconhecimento do Número 2 do KINLIB Fonte: Autores(2011) D) Teste do Gesto Número 3. Os testes referentes à interpretação e reconhecimento do número 3 é demonstrado Figura 43. Pode ser notado que o teste foi realizado com sucesso e o KINLIB reconheceu o gesto. Figura 43 - Interpretação e reconhecimento do Número 3 do KINLIB Fonte: Autores(2011)

70 70 E) Teste do Gesto Número 4. Figura 44 - Interpretação e reconhecimento do Número 4 do KINLIB Fonte: Autores(2011) Os testes referentes à interpretação e reconhecimento do número 4 é demonstrado na Figura 44. Pode ser notado que o teste foi realizado com sucesso e o KINLIB reconheceu o gesto. A tabela 5 a seguir demonstra uma analise dos acertos e erros no processo de reconhecimentos dos dedos utilizando o protótipo KINLIB e o dispositivo de captura de movimentos Microsoft Kinect, com uma amostragem de 30 gestos para cada dedos possível de reconhecimento. Tabela 5 - Analise dos Acertos e Erros no processo de reconhecimento dos dedos GESTO ACERTOS ERROS NENHUM DEDOS 70% 30% UM DEDO 24% 76% DOIS DEDOS 40% 60% TRÊS DEDOS 37% 63% QUATRO DEDOS 20% 80% Fonte: Autores (2011)