modelo de tcc para o curso de ciência da computação da …siaibib01.univali.br/pdf/gabriel schade...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
BIBLIOTECA DE FUNÇÕES PARA UTILIZAÇÃO DO KINECT EM
APLICAÇÕES NUI E JOGOS ELETRÔNICOS
por
Gabriel Schade Cardoso
Itajaí (SC), junho de 2012
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
BIBLIOTECA DE FUNÇÕES PARA UTILIZAÇÃO DO KINECT EM
APLICAÇÕES NUI E JOGOS ELETRÔNICOS
Interação Humano Computador, Computação Gráfica e Jogos eletrônicos
por
Gabriel Schade Cardoso
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.
Orientadora: Dra. Ana Elisa Ferreira Schmidt
ITAJAÍ (SC), JUNHO DE 2012
Dedico este projeto inteiramente à minha família e meus amigos, pois sem eles eu não teria
forças para realiza-lo.
AGRADECIMENTOS
Agradeço primeiramente a minha família, namorada e amigos por todo o suporte dado
durante este período.
Agradeço à minha mãe Eulália por dar todo o suporte emocional que eu precisei e por
ter compreendido os momentos de mau humor e estresse dos dias difíceis. Agradeço também
ao meu pai João pelo suporte financeiro sempre que precisei. Graças a estas duas pessoas me
tornei hoje a pessoa que sou e sempre vou amá-los por isso.
Agradeço também à minha namorada Priscila e ao meu grande amigo Rafael que são
duas grandes pessoas que me ajudaram a passar noites e mais noites em claro estudando e
pesquisando, que acreditaram em mim e que me deram as forças necessárias para que eu
sempre pudesse me levantar e seguir em frente até nos momentos mais difíceis.
Agradeço também a minha irmã Juliana, que cedeu seu notebook para que eu pudesse
terminar o trabalho no momento em que mais precisei.
Agradeço ainda, a meus amigos de meu antigo trabalho Bona, Victorino e Fran que
sempre me apoiaram e me deram forças para seguir em frente, acreditando em meu potencial.
É claro que não posso deixar de agradecer a todos os professores que, de uma forma
ou de outra, agregaram conhecimento e lições valiosas que me tornarem o profissional que
sou hoje e que ajudaram a moldar um pouco de minha personalidade, certamente coisas que
terei para o resto da vida.
Entre os professores fica um agradecimento especial para o professor Bughi, que fez
com que eu me apaixonasse por desenvolvimento e avaliou este projeto com rigidez, tornando
o resultado final melhor, ao professor Adhemar que também avaliou este projeto e o fez um
projeto melhor, ao professor Rudimar, por ter apresentado o artigo desenvolvido a partir deste
projeto no SBGames 2012 e claro, para a professora Ana Elisa, que além de ter se tornando
uma grande amiga neste ano, que acreditou em mim e em meu potencial, teve papel
fundamental neste trabalho, me ajudando muito a crescer e a me tornar uma pessoa e um
profissional melhor.
A todas estas pessoas fica o meu sincero obrigado.
“Saudações aos loucos. Aos desajustados. Aos rebeldes. Aos criadores de caso. As peças
redondas nos buracos quadrados. Os que veem as coisas de forma diferente. Eles não gostam de
regras. E eles não têm nenhum respeito pelo status quo. Você pode citá-los, discordá-los,
glorificá-los ou difamá-los. Mas a única coisa que você não pode fazer é ignorá-los. Porque eles
mudam as coisas. Eles empurram a raça humana para frente. Enquanto alguns os veem como
loucos, nós vemos como gênios. Porque as pessoas que são loucas o suficiente para achar que
podem mudar o mundo, são as que de fato, mudam...”
(Rob Siltanen e Ken Segall)
RESUMO
SCHADE, Gabriel. Biblioteca de Funções para utilização do Kinect em Aplicações GUI e
Jogos Eletrônicos. Itajaí, 2012. 62. 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í, 2012.
Formas inovadoras de interação têm sido propostas por interfaces focadas ao paradigma de
interface natural ao longo dos anos. Os usuários não necessitam ter grande conhecimento em
computação para interagir com softwares em diversas áreas. A primeira interface de usuário a
aparecer foi a CLI (Command Line Interface) que utiliza comandos de entrada textuais
específicas para desempenhar funções em um aplicativo, em seguida, surgiu a GUI (Graphical
User Interface) que utilizam janelas gráficas e são as mais utilizadas em sistemas operacionais
e aplicações até hoje; e finalmente a NUI (Natural User Interface) que visa utilizar uma
linguagem natural para a interação humana com o aplicativo, como gestos, poses e comandos
de voz. Algumas empresas como Microsoft e Nintendo desenvolveram hardwares que
possuem o propósito de tornar estas interfaces naturais presentes em algumas aplicações,
principalmente na área de jogos. O presente projeto apresenta uma biblioteca de funções que
foi desenvolvida para facilitar aos desenvolvedores migrar da interface padrão de suas
aplicações para a interface cinética do hardware Microsoft Kinect. Isto pode ser feito através
de poses, comandos de voz e gestos, sem que seja necessário um conhecimento aprofundado
no Kinect e em sua SDK. Também foi criada uma integração com a engine de jogos Unity já
que esta engine não possui integração nativa com o Kinect. Para testar e validar o
funcionamento da biblioteca criada foi alterada a interface de um projeto de um jogo já
desenvolvido pela ferramenta Unity para a interface do Kinect.
Palavras-chave: Kinect. Unity. NUI. Software Development Toolkit. Integração
ABSTRACT
Innovative ways of interaction have been proposed by user interfaces oriented towards
natural interface paradigm over the past few years. Users don’t need to be computer savvy
anymore in order to be able to interact with software in many areas. Drawing an evolution
timeline, the first type of UI to appear was the CLI (Command Line Interfaces) which use
textual input specific commands to perform functions in an application; then GUI (Graphical
User Interfaces) which use graphical windows and are used in most operating systems and
applications up to today; and finally the NUI (Natural User Interfaces) that aims to use
natural language for human interaction with the application, such as gestures, poses, or voice
commands. Some companies like Microsoft and Nintendo have developed hardware for the
purpose of making these natural interfaces present in many applications, especially in the
games area. This project created a development library to easy up the migration of standard
interface’s applications to a NUI interface using the Microsoft Kinect resources. This library
created a integration between Kinect resources and the game engine Unity, as this engine
does not have native integration with Kinect. To test and validate the operation of the library
created, was changed the interface of a game ever developed by Unity to the Kinect interface.
Keywords: Kinect. Unity. NUI. Software Development Toolkit. Integration
LISTA DE FIGURAS
Figura 1. Captura de tela de uma interface CLI no Windows 7 ............................................... 25
Figura 2. Screenshot do sistema operacional Windows 3.11 ................................................... 26 Figura 3. Gestos em uma tela de toque. .................................................................................... 29 Figura 4. Xbox dashboard. ....................................................................................................... 30 Figura 5. Jogos eletrônicos utilizando NUI .............................................................................. 32 Figura 6. Sensor 3D PrimeSense .............................................................................................. 33
Figura 7. Sensor Kinect ............................................................................................................ 35 Figura 8. Principais funcionalidades do SDK .......................................................................... 37 Figura 9. Exemplo de utilização de Mocap .............................................................................. 38
Figura 10. Articulações disponibilizadas pela SDK do Kinect ................................................ 39 Figura 11. Ângulo entre articulações ........................................................................................ 40 Figura 12. Vetores e articulações no espaço R3 ....................................................................... 41 Figura 13. Vetores com as distâncias no espaço R3 ................................................................. 42
Figura 14. Cálculo do ângulo entre os vetores V e W .............................................................. 43 Figura 15. Exemplo da utilização da lei dos cossenos ............................................................. 44 Figura 16. Exemplo de utilização da projeção ortográfica paralela ......................................... 45 Figura 17. Visão principal da ferramenta Unity ....................................................................... 47
Figura 18. Inputs da engine Unity ............................................................................................ 49 Figura 19. Comunicação entre a ferramenta de captura de entradas e o Kinect ....................... 52
Figura 20. Organização dos componentes na tela .................................................................... 53 Figura 21. Formulário “Home” ................................................................................................ 55 Figura 22. Formulário “Record New Pose”.............................................................................. 56
Figura 23. Formulário “Compose Subposes”. .......................................................................... 57
Figura 24. Esqueleto de feedback para testar a pose ................................................................ 58 Figura 25. Pose reconhecida X Pose não reconhecida ............................................................. 59 Figura 26. Formulário “Test Pose”. .......................................................................................... 60
Figura 27. Formulário “Compose Voice Command Group” .................................................... 61 Figura 28. Formulário “Test Voice Command Group” ............................................................ 62 Figura 29. Estrutura do arquivo XML de um grupo de comandos de voz. .............................. 63
Figura 30. Estrutura do arquivo XML de pose. ........................................................................ 65 Figura 31. Fluxograma de funcionamento da KinectServer ..................................................... 72
Figura 32. Interface da KinectServer ........................................................................................ 74 Figura 33. Comunicação entre a KinectUnity de entradas e o Kinect ...................................... 75 Figura 34. Poses aceitas no jogo ............................................................................................... 78
Figura 35. Jogo em execução ................................................................................................... 79
Figura 36. Gráfico de comparação entre os algoritmos para cálculo de ângulos ..................... 82
Figura 37. Criando uma conexão com o sensor via KinectScan .............................................. 83 Figura 38. Criando uma conexão com o sensor via KinectServerClient .................................. 84
Figura 39. Criando uma conexão com o sensor via KinectUnity através de scripts na Unity . 84 Figura 40. Comunicação das threads da aplicação cliente e da KinectScan ............................ 93 Figura 41. Arquivo XML de um grupo de comandos de voz ................................................... 94
Figura 42. Arquivo XML de uma pose .................................................................................... 95 Figura 43. Casos de uso para ferramenta de criação de poses .................................................. 98 Figura 44. Diagrama de Classe resumido da DLL KinectScan .............................................. 103 Figura 45. Documentação do projeto ..................................................................................... 106
LISTA DE QUADROS
Quadro 1. Comparativo entre CLI e GUI .......................................................................................... 27
Quadro 2. Configurações do sensor PrimeSense ............................................................................... 34 Quadro 3. Exemplo de código fonte utilizando a classe Input .......................................................... 49 Quadro 4. Legenda para diagramas de classe .................................................................................... 51 Quadro 5. Atributos da tag Voice Commands ................................................................................... 64 Quadro 6. Atributos da tag Commands ............................................................................................. 64
Quadro 7. Atributos da tag Pose ........................................................................................................ 66 Quadro 8. Atributos da tag Joint ........................................................................................................ 66 Quadro 9. Atributos da tag SubPose .................................................................................................. 67
Quadro 10. Atributos da tag Angle .................................................................................................... 67 Quadro 11. Atributos da tag Law_Of_Cosines_Result ..................................................................... 67 Quadro 12. Principais métodos da KinectScanner ............................................................................ 71 Quadro 13. Objetos para efetuar a requisição.................................................................................... 73
Quadro 14. Detecção de uma pose com 1 subpose............................................................................ 81 Quadro 15. Detecção de uma pose com 10 subpose.......................................................................... 81 Quadro 16. Detecção de uma pose com 20 subpose.......................................................................... 81
LISTA DE EQUAÇÕES
Equação 1 ................................................................................................................................. 41
Equação 2 ................................................................................................................................. 42 Equação 3 ................................................................................................................................. 43 Equação 4 ................................................................................................................................. 43
LISTA DE ABREVIATURAS E SIGLAS
CLI Command Line Interface
DLL Dynamic-Link Library
GUI Graphical User Interface
IHC Interação humano-computador
IR Infra-Red
NUI Natural User Interface
RF Requisito Funcional
RGB Red, Green, Blue
RGBD Red, Green, Blue, Depth
RNF Requisito Não Funcional
RN Regra de Negócio
SDK Software Development Kit
15
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................. 17
1.1 PROBLEMATIZAÇÃO .......................................................................... 18
1.1.1 Formulação do Problema ............................................................................... 18
1.1.2 Solução Proposta ............................................................................................. 18
1.2 OBJETIVOS ............................................................................................. 20
1.2.1 Objetivo Geral ................................................................................................. 20
1.2.2 Objetivos Específicos ...................................................................................... 20
1.3 METODOLOGIA .................................................................................... 21
1.4 ESTRUTURA DO TRABALHO ............................................................ 23
2 FUNDAMENTAÇÃO TEÓRICA ................................................................................ 24
2.1 INTERFACES COM O USUÁRIO ....................................................... 24
2.1.1 Interfaces CLI e GUI ...................................................................................... 24
2.1.2 Interfaces NUI ................................................................................................. 27
2.2 JOGOS ELETRÔNICOS ........................................................................ 30
2.2.1 O que são jogos eletrônicos? .......................................................................... 30
2.2.2 Motores de jogos eletrônicos .......................................................................... 31
2.2.3 Jogos eletrônicos utilizando NUI ................................................................... 31
2.3 MICROSOFT KINECT .......................................................................... 32
2.3.1 Detalhando o Microsoft Kinect ...................................................................... 34
2.3.2 Microsoft Kinect SDK .................................................................................... 36
2.3.3 Esqueleto .......................................................................................................... 37
2.3.4 Mapeamento de movimentos ......................................................................... 39
2.3.5 Reconhecimento de Fala ................................................................................. 46
2.4 UNITY ....................................................................................................... 47
2.4.1 O que é a Unity? .............................................................................................. 47
2.4.2 Scripts ............................................................................................................... 48
3 Desenvolvimento ........................................................................................................... 50
3.1 TECNOLOGIAS UTILIZADAS NA CRIAÇÃO DA
BIBLIOTECA ............................................................................................................ 50
3.2 FERRAMENTA PARA REGISTRAR ENTRADAS ........................... 52
3.3 KINECTSCAN ......................................................................................... 68
3.4 KINECTSERVER .................................................................................... 72
3.5 KINECTEVENTS .................................................................................... 74
3.6 KINECTUNITY ....................................................................................... 75
3.7 PROJETO FEITO NA UNITY MODIFICADO .................................. 77
3.8 RESTRIÇÕES .......................................................................................... 79
4 CONCLUSÕES ............................................................................................................. 80
4.1 OBJETIVOS ............................................................................................. 80
4.2 RESULTADOS ......................................................................................... 80
4.2.1 Algoritmos para cálculo do ângulo ............................................................... 80
4.2.2 Complexidade de utilização da biblioteca proposta .................................... 82
16
4.3 TRABALHOS FUTUROS ...................................................................... 85
4.4 CONSIDERAÇÕES FINAIS .................................................................. 86
APÊNDICE A. FUNCIONAMENTO ENTRE AS THREADS DA
KINECTSCAN E SEU LISTENER ........................................................ 92
APÊNDICE B. EXEMPLO DE ARQUIVOS XML DE
ENTRADAS 94
APÊNDICE C. PROJETO DA FERRAMENTA PARA
REGISTRAR ENTRADAS ...................................................................... 96
APÊNDICE D. PROJETO DA DLL KINECTSCAN .......................102
D.1. REQUISITOS ......................................................................................... 102
D.2. Diagrama de classe ........................................................................................ 103
APÊNDICE E. PROJETO DA KINECTSERVER ...........................104
E.1. Requisitos ....................................................................................................... 104
APÊNDICE F. PROJETO DA DLL KINECTUNITY .....................105
F.1. Requisitos ....................................................................................................... 105
APÊNDICE G. DOCUMENTAÇÃO DO PROJETO .......................106
17
1 INTRODUÇÃO
O desenvolvimento de jogos digitais no Brasil é um mercado que vem crescendo a
cada ano incentivando a oferta de vários cursos de graduação e pós-graduação voltados para
esta área (SANTOS, 2012). A etapa de desenvolvimento dos jogos tornou-se menos
complexa, comparada a realidade de alguns anos atrás, devido às diversas ferramentas de
codificação, frameworks e bibliotecas que auxiliam os desenvolvedores e designers durante o
projeto, desenvolvimento, teste e publicação dos games. A ferramenta Unity (UNITY, 2012) é
um exemplo de ferramenta que veio facilitar e agilizar o projeto de desenvolvimento de jogos
digitais.
A Unity ou Unity 3D como também é conhecida, é uma engine para jogos
(TECMUNDO, 2011) em 3D criado pela empresa Unity Tecnologies (UNITY, 2012). Este
software possui duas versões principais, sendo elas: a versão paga, Unity Pro, que pode ser
comprada e a versão gratuita conhecida apenas por Unity (UNITY, 2012).
Um elemento importante na criação de um jogo é a definição da forma de interação
com o usuário, este elemento vem se modificando muito nos últimos anos indo além dos
controles dos consoles. A Interface com o usuário é parte fundamental de todo o software, a
forma de comunicar-se com uma aplicação pode alterar o resultado da experiência de um
usuário tanto positivamente, quanto negativamente (OLIVEIRA NETTO, 2004),
especialmente para os jogos eletrônicos.
Para dar flexibilidade, naturalidade e fácil aprendizado às interfaces com o usuário a
empresa Microsoft desenvolveu o hardware Microsoft Kinect(KINECT, 2011) onde uma
forma de interface totalmente inovadora capta movimentos do usuário, criando assim, uma
possibilidade de interação com softwares e jogos apenas com linguagem natural do corpo. O
Microsoft Kinect inicialmente era chamado de Projeto Natal, fazendo referência a cidade
brasileira Natal, isso ocorreu devido ao fato de um dos pesquisadores da equipe da Microsoft,
Alex Kipman ser brasileiro. O Kinect foi lançado no Brasil no dia 18 de novembro de 2010 e
vem atraindo novos usuários para esta nova forma de interface que revolucionou a maneira de
interagir com aplicações e jogos (INFOWESTER, 2012).
Em fevereiro de 2011 a Microsoft anunciou um kit de desenvolvimento (SDK) do
Kinect para a plataforma Windows (MICROSOFT, 2012) que pode ser obtido de forma
gratuita. Com este kit a Microsoft permite que desenvolvedores possam criar aplicativos nas
linguagens C++, C# e Visual Basic utilizando os recursos de hardware do Kinect. Com as
18
funcionalidades fornecidas no SDK do Kinect é possível utilizar todos os recursos do sensor,
tais como: câmera RGB, câmera de profundidade (infravermelho) e microfones.
Além do SDK oficial existem algumas implementações não Microsoft, destacando-se,
o chamado OpenNI (OPENNI,2012) que possibilita desenvolver programas com a interface
do Kinect em linguagens como C++.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
O hardware Microsoft Kinect oferece uma interface mais natural com o usuário e suas
aplicações, mas desenvolver uma aplicação nova com esta interface ou migrar a interface de
aplicações já existentes pode se tornar um trabalho custoso e complexo.
Uma integração entre uma aplicação e os sensores de movimentos e sons do Microsoft
Kinect pode gerar resultados muito positivos para a experiência do usuário, já que o hardware
visa oferecer interfaces naturais.
Esta integração deve levar em conta o caráter genérico das aplicações, oferecendo
assim um framework de integração. Mantendo as características customizáveis em relação à
associação dos movimentos de entrada do usuário através do Kinect com os comportamentos
da aplicação em relação a cada entrada.
1.1.2 Solução Proposta
Como uma proposta de integração, foi desenvolvida uma biblioteca de funções que
permite que diversas aplicações utilizem as funções do sensor de movimento. A biblioteca de
funções visa facilitar o trabalho do desenvolvedor/programador possibilitando que, com o
mínimo de alterações, sua aplicação possa migrar da interface padrão para a interface natural
do Kinect.
A biblioteca que foi criada mapeia os movimentos do usuário obtidos através do
Kinect em tempo real durante a execução da aplicação e compara com arquivos de entrada
(poses e comandos de voz) previamente gravados na pasta do projeto. Estes arquivos
previamente gravados são utilizados para identificar tipos de entrada válidos, ou seja, entradas
que alteram o comportamento da aplicação.
19
Para criar os arquivos de entradas pré-definidas foi desenvolvida uma ferramenta de
captura de entradas, onde o usuário pode criar suas entradas personalizadas.
A biblioteca foi modelada e implementada de forma com que a comunicação do
Kinect fique encapsulada em uma DLL. Desta forma, a DLL que se comunicará com o Kinect
apenas despacha o reconhecimento de alguma entrada, seja ela através de uma pose ou de um
comando de voz, sem necessidade de conhecer a aplicação final, o que torna a biblioteca
extensível para diversos tipos de aplicação, bastará criar um listener que interprete os eventos
despachados.
Além dos arquivos dos eventos de reconhecimento de alguma entrada customizada, a
biblioteca também disponibiliza alguns eventos prontos, sendo eles: reconhecimento de gestos
pré-definidos, imagem da câmera RGB, esqueleto do usuário, alteração do estado do sensor e
alteração no estado de um evento.
A biblioteca também conta com uma aplicação que se conecta com o Kinect através da
DLL desenvolvida neste projeto para encapsular as funções do Kinect. Esta aplicação tem
como funcionalidade fornecer os serviços do Kinect via sockets, propondo assim, uma
segunda forma de comunicação entre o Kinect e a aplicação final.
Para estudo de caso foi utilizado um projeto desenvolvido na ferramenta Unity, pois
apesar do amplo conjunto de funcionalidades já existentes, esta engine ainda não possui uma
forma de interação nativa com o periférico Microsoft Kinect.
20
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver uma biblioteca de funções - SDK -, juntamente com uma proposta de
framework que ofereça um subconjunto de funcionalidades do Kinect para integração das
funções de entrada através de poses e comandos de voz para outras aplicações, utilizando
como estudo de caso a integração com a ferramenta Unity.
1.2.2 Objetivos Específicos
Pesquisar e estudar a respeito do desenvolvimento de aplicações utilizando os kits
de desenvolvimentos existentes para o Microsoft Kinect, especialmente o SDK
oficial fornecido pela Microsoft;
Estudar a ferramenta Unity para desenvolvimento de jogos;
Estudar formas para se desenvolver uma biblioteca de funções que integrem a
captura de movimentos a partir do Kinect com a ferramenta Unity;
Estudar métodos computacionais para detecção e comparação de poses definidas a
partir das informações capturadas pelo Kinect;
Implementar a biblioteca de integração do Kinect com outras aplicações de acordo
com os estudos e análises anteriores;
Utilizar a biblioteca criada para adaptar um projeto de jogo digital já elaborado
anteriormente com a Unity para integrar sua interface com o Kinect;
Efetuar testes de funcionalidade visando à validação das ferramentas
implementadas de acordo com os requisitos especificados;
21
1.3 Metodologia
Foram necessárias cinco etapas para o êxito deste projeto, afim de cumprir os
objetivos específicos descritos. Sendo estas etapas: estudos e análises, modelagem,
implementação, testes e documentação.
Na etapa de estudos e análises, foi definido exatamente o tema/problema deste
projeto e adquirido o conhecimento necessário sobre as soluções e tecnologias existentes com
o objetivo de propor a melhor solução para a problemática proposta. Foram analisadas
ferramentas para desenvolvimento com o Kinect; feito um estudo sobre diferentes técnicas
para detecção de movimentos; e também foi estudado sobre a engine para desenvolvimento de
jogos - Unity.
Em função do conhecimento adquirido durante a fase de estudos e análises, algumas
modificações no projeto proposto foram realizadas:
Não será implementado a detecção de gestos customizados, apenas a detecção
de poses e de comandos de voz (vide seção 3.3);
O escopo de utilização do SDK desenvolvido foi ampliado, não sendo mais
exclusivamente direcionado para a engine Unity como havia sido proposto; a
estrutura do SDK permitirá a integração de qualquer outra aplicação que
possua entradas compatíveis com os recursos oferecidos pelo Microsoft
Kinect.
Para uma integração com a engine Unity foi desenvolvido uma aplicação que
fornece as funcionalidades da biblioteca através de sockets.
Na etapa de modelagem foram definidas as especificações para o funcionamento da
solução proposta, sendo estes especificados de forma descritiva, através de figuras e
diagramas.
Na etapa de implementação foram codificadas todas as ferramentas e DLLs
propostas neste projeto, sendo especificados os padrões e o funcionamento da biblioteca de
forma descritiva e através de figuras (vide seção 3 ).
22
Na etapa de testes foram testadas as funcionalidades propostas pelo projeto e
analisado os resultados, visando ter um melhor resultado final. Estes testes e resultados são
especificados através de figuras e de forma descritiva na seção 4 .
A etapa documentação visou registrar todo o processo pertinente à pesquisa
científica, desde a apresentação do problema, a modelagem da solução, padrões utilizados na
implementação e resultados obtidos. Nesta etapa é registrado o problema e a justificativa da
solução proposta, fornecendo uma fundamentação teórica.
23
1.4 Estrutura do trabalho
Este documento está estruturado em quatro capítulos. O primeiro capítulo, Introdução,
oferece uma visão geral sobre a problemática e define os objetivos que devem ser cumpridos
ao longo do desenvolvimento deste trabalho.
O capítulo 2, Fundamentação Teórica, apresenta em mais detalhes as pesquisas e
análises que foram feitas para que seja possível efetuar o desenvolvimento do projeto
proposto. Além disso, neste capítulo também há uma imersão breve no histórico e na
descrição dos softwares e hardwares que serão utilizados.
O capítulo 3, Desenvolvimento, apresenta a definição do design da biblioteca de
funções proposta neste trabalho, mostrando detalhes que foram utilizados para o
desenvolvimento do projeto, desde a modelagem até a implementação.
Por fim o capítulo 4, Conclusão, é feito um fechamento do trabalho, onde são
mostrados os resultados do projeto como um todo, além das dificuldades encontradas e suas
resoluções.
24
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são apresentados os principais conceitos envolvidos no projeto
proposto: interfaces e tipos de interação; jogos eletrônicos e sua interação com o usuário; uma
abordagem mais aprofundada sobre o sensor Microsoft Kinect e sobre a engine para criação
de jogos Unity.
2.1 Interfaces com o Usuário
O conceito de formas de interfaces com o usuário evoluiu e se alterou ao longo do
tempo. No início a interface era vista como a forma de que o hardware e um software
aplicativo promoveriam a comunicação entre o humano e o computador. Atualmente dentro
do conceito de interface encontram-se também os aspectos relativos à percepção; cognição e
habilidades motoras e viso-motoras do usuário (OLIVEIRA NETTO, 2004).
É por meio da interface que o usuário interage com a aplicação, o que a torna parte
essencial de toda e qualquer aplicação. Na construção de qualquer software deve ser analisada
tanto a parte funcional quanto a parte de interface. A interface tem como objetivo fornecer
uma interação com o usuário da forma mais amigável possível, ou seja, oferecer ao usuário
maneiras simples e consistentes de interação. Para o projeto de um software também é
interessante analisar tanto a perspectiva do desenvolvedor, quanto a perspectiva do designer
na etapa de definição da interface com o usuário (WINOGRAD, 1996).
O modo como os usuários e os sistemas computacionais interagem é chamada de estilo
de interação (SHNEIDERMAN, 1998). Os estilos de interação que compõe as interfaces mais
conhecidas são: CL (Command Line), GUI (Graphical User Interface) e NUI (Natural User
Interface).
2.1.1 Interfaces CLI e GUI
A interface CLI (Command Line Interface) é um dos estilos de interação mais
conhecidos, esta interface foi a primeira a ser oferecida nos sistemas operacionais DOS, MAC
OS e outros. Atualmente ela ainda pode ser utilizada em um sistema operacional como o
Windows 7, por exemplo, através da aplicação Command Prompt. A Figura 1 mostra um
exemplo de interface CLI.
25
Figura 1. Captura de tela de uma interface CLI no Windows 7
O usuário interage diretamente com o sistema ou aplicação CLI através da utilização
de comandos de texto específicos, como o comando “dir”, na imagem acima. Este tipo de
interação também permite ao usuário uma maior liberdade de iniciativa e flexibilidade ao
usuário, pois oferece a funcionalidade de criação de comandos parametrizados para executar
determinadas funções (OLIVEIRA NETTO, 2004).
Por estes motivos as interfaces baseadas em linguagens de comandos são consideradas
mais eficientes que os outros tipos existentes (PREECE, Jenny et al. 1994), porém para os
usuários iniciantes essa linguagem pode ser complicada, pois exige domínio sobre a
linguagem de comandos. Outro fator que dificulta a utilização das interfaces CLI deve-se ao
fato de que, sistemas operacionais diferentes podem oferecer comandos totalmente distintos
em sua interface CLI, fazendo com que o usuário de aplicações CLI multi-plataformas tenha
de aprender múltiplos conjuntos de comandos para poder interagir com os aplicativos através
de suas interfaces CLI.
Em busca de interfaces mais intuitivas para usuários iniciantes surgiu o estilo de
interação conhecido como GUI (Graphical User Interface). Este tipo de interação pode ser
definido como sendo um conjunto de opções exibidas em uma tela para o usuário. Ao
contrário da CLI, o tipo de interface baseada no conceito GUI possui botões, menus, caixas de
26
seleção e marcação, ícones e outros recursos gráficos que possam indicar ao usuário como
interagir com a máquina (OLIVEIRA NETTO, 2004).
A Figura 2 mostra uma das primeiras interfaces GUI oferecidas ao usuário em um
sistema operacional.
Figura 2. Screenshot do sistema operacional Windows 3.11
Outra novidade introduzida através das interfaces gráficas foi o uso do mouse, um
periférico que é controlado via software e simula um ponteiro através do qual o usuário
consegue pressionar os botões e os outros componentes visuais da interface apresentada na
tela.
Segundo Preece et al. (1994) as aplicações que utilizam o tipo de interação GUI
possuem um nível de manipulação e aprendizado bastante simples, basta que a interface seja
bem projetada em termos de design e usabilidade para que o usuário consiga navegar pelo
sistema sem muitas dificuldades.
27
Profissionais da área de IHC (Interação humano-computador) possuem papel
fundamental na construção de um software que utilize interfaces gráficas, pois quando as
formas de interação através de uma interface GUI são bem projetadas e construídas, o
software pode aumentar em muito sua produtividade (OLIVEIRA NETTO, 2004).
O Quadro 1 faz uma comparação das características dos tipos de interface CLI e GUI:
Propriedade CLI GUI
Facilidade Devido à memorização e
familiaridade necessária para usuários
operarem nesta interface ela se torna
muito difícil para novos usuários.
Alguns usuários possuem dificuldade
para operar o mouse no início, mas o
tempo necessário para aprendizado é
muito menor
Controle Usuários possuem muito mais
controle do sistema de arquivos e do
sistema operacional, para efetuar uma
cópia de um arquivo para outro
diretório, por exemplo, basta uma
linha de comando.
Também oferece bastante controle ao
usuário, mas algumas tarefas podem
ser mais trabalhosas nesta interface,
usuários avançados às vezes optam
pela CLI ao fazer algumas operações
mais específicas.
Multitarefa São capazes de executar processos em
multitarefa, mas não oferecem a
possibilidade de ver vários
formulários abertos, por exemplo.
Possui um sistema de janelas que
permitem ao usuário visualizar,
manipular e controlar vários
formulários simultaneamente
Velocidade A digitação de comandos para
executar tarefas pode ser mais veloz
do que procurar a mesma
funcionalidade com o mouse, mas
requer muito mais treinamento.
Com o mouse e o teclado a
navegação entre as janelas se torna
rápida com pouco tempo de
aprendizado.
Recurso
necessário
Um computador que execute somente
uma interface CLI não necessita de
muito recurso.
Para a visualização de elementos
como ícones, fontes imagens e
vídeos, as interfaces gráficas
demandam mais recursos.
Acesso remoto Alguns computadores ou dispositivos
só podem ser acessados através de
CLI.
Não são todos os computadores ou
dispositivos de rede que podem ser
acessados via interfaces gráficas.
Quadro 1. Comparativo entre CLI e GUI
Fonte: Adaptado de ComputerHope (2012).
2.1.2 Interfaces NUI
Entre os estilos de interação de interfaces a NUI (Natural User Interface) é sem dúvida
uma das formas mais eficientes de interação com o usuário, já que permite ao usuário utilizar
a linguagem natural do próprio corpo, como por exemplo, gestos e falas em sua língua
tradicional.
28
Ainda não é possível criar um sistema que compreenda totalmente as especificidades
da linguagem natural humana, já que muitos dos gestos comuns às pessoas possam parecer
vagas ou ambíguas no meio computacional.
Na construção de uma aplicação que possua este estilo de interação são utilizados
algoritmos para interpretar um subconjunto de comandos, como por exemplo, gestos e
comandos de voz já previstos pelo sistema. (OLIVEIRA NETTO, 2004).
A NUI é um termo utilizado em vários tipos de tecnologia, tais como reconhecimento
de voz, periféricos com touchscreen (telas sensíveis ao toque) e algumas interfaces
conhecidas como cinéticas, ou seja, ligadas diretamente a movimentos do corpo, como por
exemplo, o Microsoft Kinect.
O maior objetivo da NUI é criar interfaces que sejam de fácil manipulação para os
usuários, onde não necessitaria de uma curva de aprendizagem tão longa quanto nas interfaces
CLI ou GUI. As aplicações que oferecem interfaces NUI, como o próprio termo diz, devem
ser naturais aos usuários, oferecendo formas de interação com a aplicação que seja
independente de conhecimento computacional. Um grande exemplo são as interfaces
oferecidas em dispositivos como os tablets e smartphones, onde usuários como crianças e
idosos conseguem interagir com aplicações com uma curva de aprendizagem bastante rápida e
intuitiva (ASHLEY; WEBB, 2012).
Segundo Bill Buxton (2012), pesquisador da Microsoft Research reconhecido como
um dos pioneiros na área de IHC (interação humano-computador), a forma mais natural de um
usuário utilizar uma interface é quando o usuário faz o uso de habilidades que foram
previamente aprendidas sem que o mesmo note isto.
Em geral, os usuários que estão acostumados com as interfaces GUI, ao se deparar
com um botão em uma aplicação que segue os conceitos NUI, executada em um dispositivo
touchscreen, entendem que devem pressionar a tela no local do botão, o que é feito
normalmente com o mouse nas aplicações que não possuem touch, ou seja, uma habilidade
previamente desenvolvida que dá sentido a um gesto. (ASHLEY, James; WEBB, Jarret,
2012).
A Figura 3 ilustra os gestos mais comuns em uma superfície touchscreen, que são
respectivamente: pressionar a tela e retirar o dedo rapidamente (tap) em um ponto, pressionar
29
a tela e permanecer segurando por um tempo maior, deslizar o dedo pela tela (geralmente
ligado à barra de rolagem) e por último o movimento de pinça (geralmente ligado ao efeito de
zoom).
Figura 3. Gestos em uma tela de toque.
Fonte: ASHLEY e WEBB (2012).
Uma vantagem que os gestos em superfícies sensíveis ao toque e interfaces cinéticas
possuem em relação ao reconhecimento de comandos por voz é a independência do idioma
nativo de cada usuário.
A criação de um reconhecimento de voz é um procedimento complexo já que é
necessário que a aplicação possua um algoritmo com certa inteligência a fim de identificar o
comando de forma correta, independente, por exemplo, dos sotaques diferentes entre os
usuários.
A linguagem gestual de qualquer interface cinética, incluindo o Kinect, é considerada
boa e de fácil adaptação, quando são tratados dois dos conceitos essenciais da área de
usabilidade, que são o affordance e o feedback (ASHLEY; WEBB, 2012).
O feedback em uma aplicação NUI geralmente consiste em notificar o usuário quando
uma pose ou um gesto são reconhecidos. No XBox dashboard, por exemplo, ao reconhecer
que a mão do usuário está sobre algum quadro em que o usuário possa interagir, o sistema
30
exibe uma animação para notificar o usuário que, caso ele não altere a posição de sua mão, o
sistema acionará ação correspondente.
Neste mesmo dashboard quando o usuário diz em voz alta a palavra XBox, é exibido
um ícone em forma de microfone e uma mensagem ao usuário notificando que ele pode
executar algum comando de voz juntamente com todos os comandos de voz que podem ser
reconhecidos são exibidos abaixo de cada quadro, como a Figura 4 ilustra.
Figura 4. Xbox dashboard.
O affordance são os indicativos da aplicação que guiam o usuário, como por exemplo,
na Figura 4 do dashboard do Xbox, o ícone do microfone exibido indica que o usuário pode
utilizar um comando de voz.
As respostas da aplicação ao usuário (feedback) e os indicativos certos (affordance),
somados a interface NUI, tornam a experiência de uso fácil, simples e intuitiva, cumprindo os
requisitos da NUI.
2.2 Jogos Eletrônicos
2.2.1 O que são jogos eletrônicos?
Jogos eletrônicos são um nicho de programas de computador focados principalmente
em prover o entretenimento ao usuário. No cenário atual este tipo de aplicação possui uma
grande indústria cultural que evolui constantemente (MENDES, 2006).
31
Os jogos eletrônicos atualmente estão presentes em plataformas diversas e com
diferentes grupos de jogadores. Praticamente todo o tipo de pessoa possui um perfil para certo
grupo de jogos específicos; qualquer tipo de dispositivo capaz de executar um programa de
computador pode executar algum tipo de jogo (MENDES, 2006). Segue a lista com os
principais tipos de aparelhos que podem executar este tipo de programa:
Computadores;
Consoles específicos;
Celulares e Smartphones;
Televisores e Smart Tvs;
Hardwares voltados para este tipo de software, como por exemplo, minigames.
2.2.2 Motores de jogos eletrônicos
Os chamados motores de jogos, são componentes de softwares que disponibilizam
funcionalidades focadas e específicas para o desenvolvimento de um jogo. Basicamente, é um
agrupador de funcionalidades fundamentais ao desenvolvimento de um projeto de jogos, que
podem variar desde a interoperabilidade entre os periféricos de controle até a renderização dos
objetos de uma cena (BESSA et al. 2007).
A quantidade de componentes providos por um motor de jogo pode variar muito; em
sua maioria, são feitos com diferentes módulos para diferentes funcionalidades, como por
exemplo, módulo para renderização de personagens, controle da física sobre a cena, controle
de entrada de dados do usuário, controle de áudio, controle de threads e vários outros pontos,
que podem tornar o desenvolvimento de um motor de jogo mais complexo até do que o
desenvolvimento do próprio jogo. Alguns dos motores mais utilizadas são: Unity, 3D
GameStudio, Truevision3D, Unreal Engine e Microsoft XNA Game Studio (GREGORY,
2009).
2.2.3 Jogos eletrônicos utilizando NUI
A NUI provê benefícios a qualquer tipo de aplicação, mas a área de jogos em especial
busca a melhor interação com o usuário a todo o momento (OLIVEIRA NETTO, 2004).
32
Os jogos eletrônicos também podem ser considerados sistemas de computadores. A
experiência que um jogo transfere ao usuário é passada através de uma série de regras,
somadas com objetivos, atividades e ações dinâmicas do usuário. Este processo é comumente
chamado de “Jogabilidade” (VALE, 2005).
Ao longo dos anos, para diferenciar a “jogabilidade”, o mercado de consoles vem
buscando alternativas com diferentes tipos de hardware, desde controles mais específicos e
cheios de botões até as interfaces mais naturais fornecidas pelos consoles Nintendo Wii, Wii
U e o Microsoft Xbox que possui o acessório para comandos de voz e interface cinética
Kinect (VALE, 2005). A Figura 5 mostra respectivamente os hardwares supracitados.
Figura 5. Jogos eletrônicos utilizando NUI
2.3 Microsoft Kinect
O Microsoft Kinect foi uma criação da empresa Microsoft, utilizado inicialmente
como acessório ao console Xbox 360, o aparelho possui cerca de vinte e cinco centímetros de
largura e possui alguns componentes que o permitem captar movimentos do corpo humano e
mapear o “esqueleto” de uma pessoa em até 20 pontos diferentes.
33
O Microsoft Kinect nasceu de uma parceria entre a empresa Microsoft e uma empresa
israelita chamada PrimeSense, ambas possuíam a mesma visão para o quesito interface: “A
tecnologia torna-se mais abrangente, mais intuitiva e mais fácil de se familiarizar quando
interage diretamente com o corpo humano” citou Aviad Maizels, fundador e presidente da
Prime Sense(LEADBETTER, 2010). A Figura 6 mostra o layout do hardware da PrimeSense.
Figura 6. Sensor 3D PrimeSense
Fonte: Adaptado de LEADBETTER (2010).
O sensor PrimeSense é menor que o sensor da Microsoft possuindo quatorze
centímetros de largura, possui dois microfones, ao invés de quatro como o Kinect e não possui
o eixo motorizado para direcionar a câmera( PRIMESENSE, 2011).
O Quadro 2 mostra as configurações gerais do sensor da empresa PrimeSense:
34
Propriedade Especificação
Campo de visão horizontal 58 graus
Campo de visão vertical 45 graus
Campo de visão diagonal 70 graus
Profundidade do tamanho da imagem VGA (640 x 480)
Resolução espacial x/y a dois metros de distância do sensor 3 mm
Profundidade da resolução z a dois metros de distancia do sensor 1 cm
Rendimento máximo da imagem (frame-rate) 60 FPS
Alcance da operação 0.8 metros à 3.5 metros
Tamanho de imagens e cores UXGA (1600 x 1200)
Número de microfones Dois
Entradas digitais de áudio Quatro
Interface dos dados e alimentação de energia USB 2.0
Consumo 2.25 W
Dimensões 14cm x 3.5cm x 5cm
Ambientes de operação Fechado
Iluminação do ambiente Qualquer tipo
Temperatura do ambiente 0°C - 40°C
Quadro 2. Configurações do sensor PrimeSense
Fonte: Adaptado de LEADBETTER (2010).
2.3.1 Detalhando o Microsoft Kinect
O sensor da Microsoft foi bastante aprimorado em relação ao PrimeSense, o software
interno, conhecido como NITE foi descartado fazendo com que o Kinect tenha um
reconhecimento do esqueleto do corpo e um sistema para reconhecimento de comandos de
voz totalmente diferente do PrimeSense.
O hardware possui quatro microfones, duas câmeras, um emissor de luz infravermelha
e um eixo motorizado, conforme Figura 7.
35
Figura 7. Sensor Kinect
Fonte: Adaptado de Microsoft (2012).
A câmera RGB do sensor é utilizada para captar imagens do mundo real de forma
similar a uma webcam, esta câmera permite que o Kinect tenha um reconhecimento facial
muito bom, além de permitir que o sensor tire fotos ou grave vídeos. O emissor e a câmera de
luz infravermelha permitem que o sensor consiga captar a distância de um objeto em relação
ao sensor, ou seja, reconhecer a profundidade, além de altura e largura como na câmera RGB.
A tecnologia utilizada pela PrimeSense e adquirida pelo Kinect chama-se Light
Coding (LEADBETTER, 2010). Esta técnica se baseia basicamente em luz infravermelha. O
emissor de luz infravermelha do Kinect projeta a luz por todo o ambiente. Em seguida a
câmera infravermelha obtém estes pontos luminosos, através de um processamento interno
também herdado da PrimeSense o sensor traduz estes pontos para um mapa de profundidade,
somando este mapa com a imagem da câmera RGB obtém-se uma imagem onde cada pixel
possui um componente de profundidade também conhecida como imagem RGBD (Red-
Green-Blue-Depth), ou seja, as imagens da câmera RGB e da câmera de profundidade são
sincronizadas no espaço e no tempo (ALBITAR, chadi; GRAEBLING, Pierre; DOIGNOM,
Christophe, 2007).
Através do resultado obtido pelas câmeras, o Kinect passa por um processo de
avaliação da imagem capturada a fim de reconhecer cada articulação de cada esqueleto de
cada pessoa presente na cena. Para efetuar este processo a Microsoft desenvolveu um
algoritmo próprio com dois objetivos principais: eficiência computacional e robustez.
Os quatro microfones que ficam ao longo do sensor, permitem que o periférico receba
como entrada de informação o som. Estes microfones ficam espalhados pelo Kinect e desta
36
forma, é possível perceber de onde o som está vindo. Além disso, com um processamento
interno feito pelo próprio Kinect estes microfones são capazes de entender comandos feitos
por meio da voz.
O eixo motorizado é utilizado apenas para movimentar a parte superior do sensor para
cima ou para baixo, alterando assim o posicionamento das câmeras.
2.3.2 Microsoft Kinect SDK
A Microsoft disponibiliza em seu site o download gratuito do SDK (software
development kit) para implementações utilizando o hardware Microsoft Kinect
(KINECTSDK, 2012).
O SDK é composto por várias aplicações que mostram o funcionamento básico do
Kinect, como por exemplo mapear um esqueleto ou exibir a imagem da câmera RGB. Além
das aplicações também é fornecida a DLL Microsoft.Kinect, onde estão contidas todas as
classes, enumerados e estruturas necessárias para manipular o Kinect em uma aplicação
(MSDN, 2012).
A classe principal do SDK é a KinectSensor, através dela é possível manipular todas
as funcionalidades do Kinect. Esta classe também define quais as funcionalidades do sensor
estão ligadas e desligadas; inicialmente o KinectSensor vem com todas as funcionalidades
desligadas.
Estas funcionalidades são acessadas através das propriedades ColorStream que
controla a funcionalidade interligada a câmera RGB do sensor; DepthStream que está ligada
diretamente com a captação da profundidade dos objetos em frente ao sensor; SkeletonStream
que é a propriedade que mapeia o corpo humano dos jogadores em frente ao sensor e
AudioSource que controla as funcionalidades interligadas aos microfones do sensor. Além
destas propriedades principais a classe também oferece acessos às propriedades
ElevationAngle que retorna o ângulo de elevação do eixo motorizado; Status, que pode
indicar se o Kinect está ligado, desconectado, com algum erro e outros tipos de status;
KinectSensors, para acessar uma coleção com todos os Kinects ligados a máquina que está
executando a aplicação e outras propriedades para controle de IDs dos sensores, utilizados
para controle em situações em que há mais de um sensor simultaneamente.
37
A Figura 8 ilustra como a classe KinectSensor e suas propriedades interagem no
sensor Kinect.
Figura 8. Principais funcionalidades do SDK
2.3.3 Esqueleto
Apesar de utilizar o hardware proposto pela PrimeSense o Kinect possui uma forma
própria para reconhecer o esqueleto do usuário através de uma rede neural desenvolvida pela
própria Microsoft (LEADBETTER, 2010). Para efetuar o reconhecimento de diferentes tipos
de movimentos a Microsoft treinou a rede neural que reconhece esqueletos com diferentes
tipos de mocaps. A Figura 9 ilustra a utilização de um mocap para gravação de um
movimento para um jogo de golf.
38
Figura 9. Exemplo de utilização de Mocap
Fonte: http://freemotionfiles.blogspot.com.br/2009/05/game-
motion-capture-data.html (2010)
A detecção do esqueleto do usuário através do SDK do Kinect é disponibilizado por
meio de 20 articulações que são mapeadas pelo software interno do Kinect. Desenvolvido e
treinado pela Microsoft, através destas 20 articulações é possível identificar e distinguir todos
os pontos relevantes para interpretar um movimento de um usuário. Através destes pontos é
possível obter as posições espaciais X,Y e Z de cada articulação, permitindo a descrição
tridimensional dos movimentos capturados. A Figura 10 ilustra a disposição bidimensional
das articulações no esqueleto de um usuário.
39
Figura 10. Articulações disponibilizadas pela SDK do Kinect
Fonte: http://blogs.microsoft.co.il/blogs/shair/archive/2011/06/17/kinect-
getting-started-become-the-incredible-hulk.aspx
2.3.4 Mapeamento de movimentos
As expressões corporais das pessoas podem ser classificadas em duas principais
categorias de acordo com o tipo de movimento: as poses e os gestos (ASHLEY, James;
WEBB, Jarret, 2012).
A diferença entre estes dois tipos de movimento pode ser explicada de forma bastante
simples: a pose é uma forma estática de manter o corpo enquanto o gesto é um movimento em
um espaço de tempo.
Estes dois tipos de movimento são utilizados na linguagem corporal humana. Em uma
partida de futebol, quando um jogador encontra-se em posição de impedimento, o árbitro
auxiliar levanta sua bandeira mantendo-se em uma pose para comunicar ao árbitro que a
jogada deve ser paralisada. Quando duas pessoas se despedem geralmente utilizam o gesto de
aceno de forma automática, pois é natural às pessoas executar este gesto nesta situação.
O Microsoft Kinect SDK não oferece nenhum tipo de biblioteca ou API para mapear
gestos ou poses. Para efetuar os processos para detecção destes movimentos é necessário ao
desenvolvedor criar algoritmos de detecção e reconhecimento de poses e gestos.
40
2.3.4.1 Detecção de poses
A posição tridimensional das articulações do esqueleto de um usuário em frente ao
sensor define a pose em que o usuário se encontra. Para efetuar a detecção e reconhecimento
dessas poses deve sempre ser analisado o relacionamento entre as articulações de um mesmo
esqueleto e nunca suas posições espaciais, pois os usuários podem estar posicionados
espacialmente em coordenadas distintas ou possuir estaturas diferentes, mas ainda assim
estarem realizando a mesma pose.
Existem variadas técnicas para fazer o reconhecimento de uma pose, dentre as quais se
destaca como mais utilizada o método de cálculo de ângulo entre articulações, conforme
ilustra a Figura 11. Nesta técnica efetua-se o reconhecimento da posição relativa de uma
articulação em relação à outra através do ângulo formado entre os dois vetores definidos pelos
pontos das articulações (KEAN, Sean; HALL, Jonathan; PERRY, Phoenix, 2012) (ASHLEY,
James; WEBB, Jarret, 2012).
Figura 11. Ângulo entre articulações
Fonte: (ASHLEY, James; WEBB, Jarret, 2012)
Segundo Ashley, Webb (2012) e Kean, Hall, Perry (2012) o método de cálculo de
ângulo entre três articulações é capaz de mapear um maior número de poses. Para distinguir
corretamente uma pose é necessário selecionar as três articulações que estejam envolvidas,
41
pode-se efetuar dois diferentes cálculos: o produto escalar, para calcular o ângulo entre os
vetores no espaço 3D e a lei dos cossenos para se calcular o ângulo sobre um plano 2D.
Para o produto escalar devem ser utilizadas três articulações, onde suas coordenadas
espaciais são definidas como vértices de dois vetores (V e W) definidos no espaço R3
(FOLEY, James D. et al. 1997), como ilustra a Figura 12.
Figura 12. Vetores e articulações no espaço R3
Após estabelecer as articulações que serão utilizadas no cálculo do ângulo e obtermos
o vetor é necessário aplicar o cálculo chamado produto escalar, onde conseguimos identificar
um ângulo entre dois vetores em um sistema de coordenadas 3D euclidiano (FOLEY, James
D. et al. 1997), abaixo segue a Equação 1 que é a equação para calcular o produto escalar.
Equação 1
42
Para efetuar este cálculo é necessário possuir as informações referentes a distância do
vetor em cada eixo, para continuar com o exemplo da Figura 12, a Figura 13 ilustrará
distâncias hipotéticas em cada coordenada de cada vetor.
Figura 13. Vetores com as distâncias no espaço R3
Para efetuar o cálculo V.W é utilizado o produto escalar de vetores, ou seja, soma-se o
resultado do produto de cada coordenada dos vetores (FOLEY, James D. et al. 1997), a
Equação 2 ilustra o cálculo citado.
Equação 2
Por fim o cálculo também utiliza o produto entre o módulo do vetor V (|| V ||) e o
módulo do vetor W (|| W ||) (FOLEY, James D. et al. 1997), esta multiplicação pode ser
executada através do cálculo descrito na Equação 3.
43
Equação 3
Seguindo o exemplo da Figura 12 e da Figura 13 a resolução do cálculo seria da forma
que a Figura 14 ilustra abaixo. Como foram usados valores hipotéticos o resultado é apenas
ilustrativo.
Figura 14. Cálculo do ângulo entre os vetores V e W
Para efetuar o cálculo do ângulo 2D, utiliza-se a fórmula da lei dos cossenos. Nesta
fórmula são utilizadas as articulações e suas respectivas coordenadas X e Y (após a conversão
para o plano 2D), de forma arbitrária as três articulações são classificadas em dois pontos
auxiliares e um ponto central, após ter sido feito o processo de classificação das articulações
aplica-se a lei dos cossenos conforme a Equação 4. Isso ocorre devido ao fato de que a
trigonometria básica não é aplicável a triângulos obtusângulos, ou seja, triângulos que
possuam um ângulo maior do que 180 graus (ASHLEY, James; WEBB, Jarret., 2012).
Equação 4
44
Através desta fórmula é possível calcular o ângulo referente à articulação definida
como ponto central, os valores listados na fórmula são: a é igual à distância entre o ponto
central e um dos pontos auxiliares, b é igual à distância entre o ponto central e o outro ponto
auxiliar e c é igual à distância entre os pontos auxiliares, formando assim o triângulo que
mapeia estes pontos (ASHLEY, James; WEBB, Jarret., 2012). A Figura 15 exemplifica com o
mesmo exemplo do cálculo do produto escalar.
Figura 15. Exemplo da utilização da lei dos cossenos
A lei dos cossenos é utilizada sobre superfícies planas, ou seja, em duas dimensões,
para tanto, uma etapa de projeção das coordenadas 3D para os planos frontal (XY), lateral
(YZ) e superior (XZ) é necessária. Neste trabalho foi selecionada a projeção ortográfica
paralela para implementar esta transformação (FOLEY, James D. et al. 1997).
Neste trabalho foi implementada a projeção ortográfica paralela (FOLEY, James D. et
al. 1997) para efetuar o cálculo do ângulo 2D através da lei dos cossenos. Nesta etapa um dos
eixos do espaço 3D é simplesmente descartado. A Figura 16 ilustra o funcionamento dessa
projeção sobre um objeto em um sistema de coordenadas em 3D.
45
Figura 16. Exemplo de utilização da projeção ortográfica paralela
2.3.4.2 Detecção de gestos
Para detecção de gestos a bibliografia pesquisada se refere às três seguintes técnicas:
por algoritmo especializado; por redes neurais ou por comparação à um gesto previamente
armazenado (ASHLEY, James; WEBB, Jarret., 2012).
A detecção de gestos por algoritmo especializado é a forma menos complexa para se
detectar um gesto. Neste modelo de detecção é implementado uma série de regras e condições
que produzem um resultado no fim do processamento, indicando se o gesto a ser detectado foi
ou não executado pelo usuário (ASHLEY, James; WEBB, Jarret., 2012). Esta forma é
eficiente para detectar gestos simples, mas cada gesto precisa ser implementado com
diferentes parâmetros o que cria um problema a respeito do reuso de códigos; a cada gesto
novo inserido na aplicação terá de ser feita uma nova implementação para detecção do
mesmo.
O processo de detecção por rede neural é uma forma complexa e não trivial, não muito
indicada para aplicações simples. Este processo consegue detectar e classificar com facilidade
gestos similares, porém o processo de criação de uma rede neural é algo custoso e além da
criação a rede também deve passar por processos de treinamentos para que ela se torne
efetivamente boa em reconhecer os gestos para qual foi treinada (KEAN, Sean; HALL,
Jonathan; PERRY, Phoenix, 2012).
46
A detecção por um exemplo previo consiste em registrar os movimentos de um
usuário através de um software especializado em captura e em tempo de execução da
aplicação comparar por frames os possíveis gestos a serem detectados. É um processo custoso
e complexo, pois envolve o tempo de execução do gesto como quarta dimensão, além do
movimento no espaço (BUXTON, 2012).
2.3.5 Reconhecimento de Fala
Conforme pesquisas da Microsoft, interagir com comandos de voz em uma aplicação é
geralmente a forma que os usuários preferem como interface em relação a interfaces de gestos
e interfaces com algum tipo de controle (KINECTAUDIO, 2011).
O hardware do Kinect possui quatro microfones dispostos ao longo do sensor, além de
reconhecer os comandos de voz, também identificam qual a direção do áudio. Os dados
referentes aos comandos de voz são previamente tratados pelo próprio Kinect antes de serem
enviados ao Xbox ou ao PC (KINECTAUDIO, 2011).
O sistema para reconhecimento de voz também possui uma funcionalidade para
cancelamento de eco acústico, que visa diminuir o ruído e melhorar a eficiência do
reconhecimento destes comandos. A Microsoft também utilizou uma rede neural para treinar
o reconhecimento de voz devido à quantidade de sotaques diferentes além das diferenças de
articulações e velocidades da fala que mudam para cada individuo (KINECTVIDEOAUDIO,
2011).
Apesar do SDK do Kinect possuir a integração com os comandos de voz do hardware
é necessário efetuar o download da SDK para reconhecimento de voz, já que não é feito todo
o processamento no próprio Kinect, a SDK para reconhecimento de voz se encontra
disponível para download no próprio site da Microsoft sem custo nenhum (KINECTSDK,
2012).
Como ilustrado na Figura 8, através da propriedade AudioSource é possível interagir e
definir quais os comandos de voz que serão utilizados e se deve ser utilizado o cancelamento
do eco acústico. Inicialmente os comandos de voz são reconhecidos apenas no inglês dos
Estados Unidos, mas é possível fazer o download de pacotes de extensão de reconhecimento
para as linguagens: inglês para Grã-Bretanha, Irlanda, Austrália, Nova Zelândia e Canadá,
47
francês para França e Canadá, italiano para a Itália, japonês para o Japão e espanhol para a
Espanha e México (KINECTSDK, 2012).
2.4 Unity
2.4.1 O que é a Unity?
A Unity oferece um conjunto de ferramentas voltadas a auxiliar os desenvolvedores
durante as etapas básicas de desenvolvimento de jogos desde a programação, oferecendo uma
API; até a publicação, oferecendo uma maneira fácil de tornar o jogo multiplataforma. É
possível, por exemplo, publicar o trabalho final para as plataformas: Mac OSX App,
Windows, Navegadores Web; dispositivos móveis com sistemas iOS e Android; para
desenvolvedores autorizados também é possível disponibilizar o trabalho final para os
consoles Wii, Playstation 3 e Xbox 360 (UNITY,2012).
A Figura 17 ilustra a tela principal da ferramenta que é composta pelos painéis: Scene,
que mostra a cena do jogo que está sendo desenvolvida; Game, que mostra como a cena
iniciará no jogo; Hierarchy, que mostra as informações referentes aos objetos que estão
inseridos na cena; Project, que exibe todos os artefatos do projeto e o painel Inspector que
exibe informações do item ou opção selecionada.
Figura 17. Visão principal da ferramenta Unity
48
2.4.2 Scripts
A ferramenta Unity provê ao desenvolvedor um mecanismo de Scripts que podem ser
codificados nas linguagens JavaScript, C# e Boo (Unity,2012). Os scripts são trechos de
código escritos pelo desenvolvedor do jogo que implementam a parte da animação dos
personagens e objetos de uma cena através de chamadas às funções de animações oferecidas
pela Unity; sem eles nada se moveria ou interagiria dentro do universo virtual.
Como citado anteriormente, a Unity permite a utilização de scripts na linguagem C#,
esta linguagem faz parte do framework .NET desenvolvido pela Microsoft. Apesar disso,
existe um projeto open-source de um compilador paralelo chamado Mono (MONO, 2012).
Este compilador tem como principal objetivo tornar o C# multiplataforma e, para que isso seja
possível este compilador não permite a utilização de nenhuma classe base do Windows.
A Unity, desde sua versão 3 até atualmente na versão 4, utiliza o compilador Mono em
sua versão 2.6, que inicialmente aceita apenas as classes do framework .NET em sua versão
2.0, mas é possível utilizar plug-ins no projeto com DLLs na versão 3.5 do .NET framework,
desde que, nesta DLL não haja nenhuma classe incompatível com a versão anterior do
framework. A Unity fornece uma tabela que mostra a compatibilidade entre o Mono e o
framework .NET (MONOCOMPATIBILITY, 2012).
Os scripts criam as funcionalidades dos objetos no mundo virtual, incluindo a parte de
interação entre o personagem principal e o jogador. A forma como os jogadores interagem
com o personagem na Unity são definidos pelos Inputs (entradas) criados pelo desenvolvedor.
A ferramenta Unity fornece a classe estática Input para a detecção de quando o jogador está
jogador está ou não pressionando uma das entradas configuradas pelo desenvolvedor. O
Quadro 3. Exemplo de código fonte utilizando a classe Input
ilustra um pequeno trecho de código onde esta classe é utilizada. Para manter a
compatibilidade de métodos, o projeto desenvolvido utiliza os métodos da classe Input, como
descrito na seção 3.4.
49
// Método chamado a cada frame da cena do jogo void Update()
{
if (Input.GetAxis("Horizontal") > 0)
{
/* A entrada Horizontal pode possuir valor positivo ou negativo
* para saber qual o valor acionado nesta input deve-se
* avaliar o valor da entrada.
* Neste caso a entrada foi acionada com o valor positivo.
*/
}
else if (Input.GetAxis("Horizontal") < 0)
{
// Neste caso a entrada foi acionada com o valor negativo.
}
if ( Input.GetButtonDown("Jump") )
{
// Neste caso a input possui apenas um valor.
}
}
Quadro 3. Exemplo de código fonte utilizando a classe Input
Inputs podem possuir somente valores positivos, ou valores positivos e negativos, por
exemplo, conforme ilustrado na Figura 18, a entrada cujo nome é Horizontal possui os botões
right e left definidos como positivos e negativos respectivamente, pois o usuário pode se
mover para frente e para trás, representando dois estados inversos; já a entrada cujo nome é
Jump possui apenas o botão space definido como positivo, pois o usuário possui apenas um
estado (valor positivo) para poder pular.
Figura 18. Inputs da engine Unity
50
3 DESENVOLVIMENTO
Neste capítulo serão descritos os processos que foram utilizados para desenvolver o
projeto, desde seu planejamento e modelagem até a implementação, descrevendo os padrões
utilizados e os resultados gerados.
O objetivo geral deste projeto foi desenvolver uma biblioteca de funções - SDK - que
permita criar uma integração entre a forma de interface cinética do Microsoft Kinect e
diferentes tipos de aplicação que possam ser beneficiadas pela interface NUI.
Para estudo de caso será feito uma integração com o motor para criação de jogos
Unity. O SDK a ser desenvolvido tem por objetivo facilitar o trabalho de um desenvolvedor
que busca utilizar o Kinect como interface para controlar sua aplicação, oferecendo um nível
de abstração em relação à API a ser aprendida, exigindo o mínimo possível de conhecimento
a respeito deste periférico e seu respectivo SDK.
3.1 Tecnologias Utilizadas na Criação da Biblioteca
Para criação desta biblioteca foi escolhido utilizar a linguagem de programação C#, já
que esta é uma das linguagens da Microsoft que podem ser utilizadas para desenvolvimento
de aplicações que utilizam o SDK oficial do Kinect e também é uma das linguagens utilizadas
para a criação de scripts na Unity, evitando assim a necessidade da criação de uma
interoperabilidade entre linguagens diferentes.
Como ferramenta de desenvolvimento foi utilizado o Microsoft Visual Studio 2010
(VISUALSTUDIO, 2012) até setembro, após isso foi utilizado sua atualização, o Microsoft
Visual Studio 2012, através dessas ferramentas também foram criados os diagramas de classe,
pois dessa forma foi possível criar as classes a partir dos diagramas, simplificando a criação
da estrutura da biblioteca.
Os diagramas de classe criados no Visual Studio possuem ícones para diferenciar
propriedades, métodos, atributos, eventos, etc. O Quadro 4 possui as legendas dos ícones:
51
Ícone Legenda
Atributos Privados
Propriedades Públicas
Métodos
Eventos
Herança de classe
Associação (multiplicidade = 1)
Associação (multiplicidade = N)
Quadro 4. Legenda para diagramas de classe
A biblioteca criada é uma solução .NET nomeada de KinectProject, esta solução é
composta pelos projetos:
Ferramenta para captura de entradas;
DLL para interação com o Kinect que foi nomeada de KinectScan;
Aplicação para se conectar com o Kinect através de sockets que foi nomeada
de KinectServer;
DLL que contém todos os eventos de interação entre o KinectProject e a
aplicação cliente, que foi nomeada de KinectEvents;
DLL para plugin no Unity que foi nomeada de KinectUnity.
Esta biblioteca foi desenvolvida de forma que seja possível mapear uma série de
eventos do Kinect para diferentes tipos de aplicações. Para que este objetivo possa ser
alcançado, foi feita a separação entre as DLLs do projeto conforme citado acima, buscando
seguir a filosofia dispatcher-listener.
No início do projeto, o Kinect não reconhecia o idioma português para
reconhecimento de fala, então nesta biblioteca todos os comandos de voz a serem executados
estão em inglês. Além disso, esta biblioteca deve ser desenvolvida para auxiliar
desenvolvedores independentemente de sua nacionalidade, para isso, foi escolhido o idioma
inglês para as descrições na aplicação, bem como para nome de métodos e classes e seus
respectivos comentários que poderão ser utilizados por futuros desenvolvedores na produção
de novos listeners.
52
Todas as entradas customizáveis (poses e comandos de voz) que devem fazer parte do
jogo que está sendo criado pelo usuário utilizando a ferramenta Unity que não estão no pacote
inicial devem ser registradas a partir da ferramenta que é disponibilizada junto à biblioteca.
Esta aplicação utilizará as câmeras e os microfones do Kinect e algumas informações
oferecidas pelo próprio usuário para registrar arquivos de poses e comandos de voz.
3.2 Ferramenta para registrar entradas
A ferramenta para registrar as entradas foi desenvolvida após a criação da DLL
KinectScan, pois toda a interação desta aplicação com o Kinect é feita a partir da KinectScan,
ou seja, esta aplicação não possui nenhuma utilização direta do SDK do Kinect o que a torna
um listerner para os eventos gerados pela KinectScan. A Figura 19 exibe o fluxograma para
comunicação entre o Kinect e esta aplicação.
Figura 19. Comunicação entre a ferramenta de captura de entradas e o Kinect
Esta ferramenta deve ser utilizada para a criação das entradas customizáveis (poses e
comandos de voz). Ela busca oferecer uma interface simples e objetiva, seguindo em parte os
padrões para as “Modern UI style applications” propostos pela Microsoft.
Esta aplicação possui uma única janela dividida em três principais painéis:
53
Painel do formulário corrente;
Painel de configurações;
Barra de comandos de voz.
O painel de configurações e a barra de comandos de voz ficam ocultos inicialmente,
liberando mais espaço para o formulário principal. A Figura 20 ilustra a organização dos
componentes citados.
Figura 20. Organização dos componentes na tela
A classe que gerencia a janela principal possui os métodos que inicializam a
KinectScan e assinam seus eventos, além disso, a janela principal também possui seu próprio
evento: KinectEventReceived, que é utilizado para repassar o evento da KinectScan para o
formulário corrente.
Os comandos de voz que esta aplicação interpreta podem ser utilizados por todos os
formulários da aplicação. Para iniciar o reconhecimento de comandos de voz basta dizer a
palavra “Kinect” e a aplicação entrará em modo “Speech”.
54
No modo “Speech” é mostrado ao usuário todos os comandos de voz que podem ser
ditos com uma funcionalidade similar ao reconhecimento de voz no console Xbox 360. Ao
entrar no modo “Speech” a aplicação exibe o componente “barra de comandos de voz”. Este
componente indica ao usuário as ações que ele pode executar através de comandos de voz.
Este componente é separado dos formulários e da janela principal, ou seja, há um
desacoplamento entre os componentes da aplicação, para que os formulários sejam alertados
quando a aplicação está no modo “Speech” a classe referente à barra de comandos de voz
possui os eventos: SpeechModeOn e SpeechModeOff que são interpretados pelo formulário
corrente.
Para efetuar a comunicação entre os três painéis da aplicação há uma classe estática
chamada UIFunctionsManager, esta classe encapsula todo o funcionamento da interface do
usuário, desde as funções para exibir formulários de diálogos ao usuário até as funções de
navegação. Esta classe gerencia todos os formulários da aplicação e os eventos que são
interpretados pelos mesmos.
A aplicação descarta o uso da barra de título padrão do Windows e possui uma própria
barra de título. Esta barra de título possui as funcionalidades “Home” e “Settings”, que
respectivamente, leva o usuário de volta a tela inicial ou abre o painel de configurações do
formulário corrente.
O painel de configurações da aplicação é sensível a contexto, ou seja, o seu conteúdo
varia de acordo com o formulário corrente. Tornando consistente o modo de o usuário
interagir com as configurações da aplicação. Toda configuração da aplicação é armazenada
em um arquivo XML para que o usuário não precise reconfigurar ao reabrir a aplicação.
Para manter a consistência de navegação entre os formulários a aplicação possui os
botões para navegação entre os formulários (exceto no formulário “Home”) sempre nos
mesmos locais (Canto superior direito), além disso, toda navegação pode ser feita por
comandos de voz, a palavra necessária é exibida na barra de comandos de voz.
Em seu formulário principal “Home”, esta aplicação conta com seis live tiles que
oferecem informações sobre as tarefas que o usuário pode executar ao entrar nelas. Estas
informações são fornecidas através de um ícone como affordance, do título da tile (localizado
no canto inferior e esquerdo) e em frases que contam ao usuário a respeito da tarefa antes dele
iniciar. A Figura 21 ilustra este formulário da aplicação.
55
Estas tiles também foram implementadas para possuir um redimensionamento
inteligente. Este redimensionamento oculta as informações por ordem de prioridade de acordo
com o tamanho disponível na tile. A Figura 21 mostra as tiles com todas as informações, caso
a tile tenha o tamanho reduzido por redimensionamento da janela é oculto primeiramente o
ícone e após isso, caso seja mais reduzida ainda, as frases são removidas, deixando apenas o
título visível.
Figura 21. Formulário “Home”
No formulário “Home” o usuário possui as seguintes opções: criar uma nova pose,
editar uma pose, ver a documentação do projeto, criar um novo comando de voz, editar um
comando de voz e contatar o desenvolvedor.
3.2.1.1 Criar uma nova pose
Ao pressionar o tile “Create a new pose” o usuário é enviado para o módulo de criação
de pose, este módulo é subdividido em três formulários, onde cada formulário tem sua
respectiva função. Estas funções são: gravar, compor e testar a pose.
Durante a função de gravar uma pose o formulário “Record New Pose” é exibido, este
formulário é dividido em três painéis principais: o painel da esquerda contém a visualização
da câmera RGB com o esqueleto sobreposto ao corpo (isto pode ser alterado nas
configurações deste formulário); o painel da direita contém uma imagem do esqueleto do
56
usuário (apenas depois do usuário executar a gravação da pose); e por fim acima destes dois
painéis existem dois campos que são necessários para a gravação da pose: nome e tempo de
espera para que a pose seja ativada. A Figura 22 ilustra o formulário “Record New Pose” após
a pose ter sido gravada.
Figura 22. Formulário “Record New Pose”
Para gravar uma pose o usuário simplesmente deve preencher os campos e posicionar-
se em frente ao sensor de forma que todo seu corpo esteja sendo rastreado, posicionar-se na
pose que deseja gravar e dizer a frase “Record Pose” com a aplicação no modo “Speech”,
lembrando que para entrar no modo “Speech” é necessário dizer a palavra “Kinect”.
Caso o esqueleto do usuário não esteja todo rastreado pelo Kinect, como por exemplo,
algum objeto em frente a uma articulação do usuário, o sistema exibe um alerta notificando o
problema, neste caso em especial o alerta desaparece após 5 segundos, não exigindo que o
usuário retorne ao computador para ajustar o problema da pose.
Caso a operação tenha sido feita com sucesso a imagem do esqueleto é jogada no
painel ao lado e permanecerá sendo exibida a pose capturada de forma estática, ao contrário
do painel que exibe a imagem da câmera RGB que sempre permanece em movimento, mesmo
que o usuário já tenha gravado a pose.
57
Para passar para o próximo formulário é necessário que todos os campos (incluindo a
pose no painel) tenham sido informados pelo usuário, caso ele tente prosseguir o sistema
exibe um alerta notificando o problema.
3.2.1.2 Compor subposes
O formulário “Compose Subposes” é onde o desenvolvedor criará as subposes que dão
significado para o reconhecimento da pose, a Figura 23 ilustra uma pose composta por quatro
subposes.
Durante a fase de reconhecimento de poses na aplicação, tomando-se como exemplo a
pose exibida na Figura 23, será necessário calcular os ângulos envolvendo as articulações dos
braços e a posição das pernas. Cada conjunto de três articulações (subposes) formam um
ângulo que é calculado através do cálculo do produto escalar em 3D e da lei dos cossenos
sobre as projeções em 2D ( vide seção 2.3.4.1).
Figura 23. Formulário “Compose Subposes”.
Ao clicar no botão “Save” a aplicação executa algumas validações (as validações são
especificadas nos cenários dos casos de uso), caso estas validações se cumpram o sistema
registra um arquivo XML contendo as informações necessárias para posterior tratamento da
pose pela aplicação.
58
É fortemente aconselhável utilizar a ferramenta de teste desta aplicação antes de
gravar o arquivo, para uma melhor calibragem na margem de erro e melhorar a escolha das
subposes envolvidas.
3.2.1.3 Testar Pose
O formulário “Test Pose” é utilizado para verificar o reconhecimento da pose que está
sendo criada. Este formulário possui uma opção (no painel de configurações) para exibir um
esqueleto de feedback ao usuário, caso esta opção esteja ativada, a aplicação desenha um
esqueleto de referência com as articulações envolvidas na pose circuladas no fundo do painel
onde o esqueleto do usuário é exibido em tempo real. A Figura 24 ilustra a imagem do
esqueleto de feedback.
Figura 24. Esqueleto de feedback para testar a pose
Para notificar se a pose que o usuário está executando está ou não reconhecida, a
aplicação exibe uma mensagem em um quadro acima do painel que pode variar entre
“Recognized” (para quando a pose está reconhecida) ou “Unrecognized” (para quando a pose
não está sendo reconhecida). A aplicação também altera a cor do esqueleto do usuário em
tempo real. Estas diferenças podem ser visualizadas na Figura 25.
59
Figura 25. Pose reconhecida X Pose não reconhecida
Este formulário também exibe uma tabela contendo as informações das subposes que
compõe a pose a ser testada e as informações do esqueleto do usuário em tempo real para cada
ângulo entre as articulações de cada subpose.
Este formulário visa facilitar o acerto do desenvolvedor em relação à criação de
subposes e definição da margem de erro, pois sem um teste efetivo é complicado definir se
uma pose está ou não bem definida, já que em alguns casos as subposes a serem utilizadas não
são naturais de se pensar. A Figura 26 mostra uma pose sendo testada e reconhecida.
60
Figura 26. Formulário “Test Pose”.
3.2.1.4 Criar um novo comando de voz
Ao acessar a tile para “Create a new voice command” a aplicação envia o usuário para
o formulário “Compose Voice Command Group”, ou seja, compor grupo de comandos de
voz, neste formulário o usuário deve informar qual o nome e o nível de confiança referente ao
grupo de comandos de voz e quais os comandos contidos neste grupo. Para efetuar a
manutenção dos itens inclusos a aplicação oferece uma barra com os botões para incluir e
excluir um comando de voz. Neste mesmo formulário também é exibido o botão de gravar,
que ao ser pressionado gera o arquivo referente ao grupo de comando de voz. A Figura 27
exibe um grupo de comando de voz referente a cumprimentos sociais entre pessoas.
61
Figura 27. Formulário “Compose Voice Command Group”
3.2.1.5 Testar um grupo de comandos de voz
A aplicação também conta com um formulário de teste de comandos de voz, neste
formulário é exibido uma barra com o botão para iniciar o teste e uma grade contendo todos
os comandos de voz que o usuário inseriu no grupo.
A grade onde ficam os comandos de voz apresenta algumas colunas que,
respectivamente exibem o melhor nível de confiança obtido no teste daquele comando, e um
check box indicando se o comando foi ou não aceito (para um comando ser aceito o melhor
nível de confiança obtido deve ser maior ou igual ao nível de confiança informado pelo
usuário no formulário de composição de grupo de comandos de voz). Quando todos os
comandos de voz são aceitos a aplicação exibe uma mensagem de sucesso ao usuário e
retorna ao formulário de composição.
Ao pressionar o botão para iniciar o teste dos comandos a aplicação automaticamente
entra em modo “Speech”, mas a frase da barra indica que também podem ser ditos todos os
comandos de voz exibidos na grade. A Figura 28 ilustra o grupo de comando de voz exibido
na Figura 27 sendo testado.
62
Figura 28. Formulário “Test Voice Command Group”
3.2.1.6 Editar uma pose ou um comando de voz
Quando o usuário pressiona a tile para editar um grupo de comando de voz ou editar
uma pose a aplicação exibe um diálogo para o usuário informar o arquivo XML que contém a
entrada que será editada, em ambos os casos, após a confirmação do arquivo, a aplicação
direciona o usuário para o formulário de composição de poses (vide item 3.2.1.2) ou
composição de grupo de comandos de voz (vide item 3.2.1.4), dependendo do arquivo.
63
3.2.1.7 Documentação
Ao pressionar a tile “Documentation”, é exibida ao usuário a documentação de todas
as DLLs que podem ser utilizadas pelo desenvolvedor em seu projeto, para facilitar o uso, a
documentação do projeto segue o padrão de documentação da MSDN.
3.2.1.8 Contatar Desenvolvedor
A tile “Contact Me” direciona o usuário para a página do Facebook do autor da
aplicação (Gabriel Schade Cardoso), esta tile também informa um e-mail para contato.
3.2.1.9 Documentação e Requisitos da Aplicação
Para maiores detalhes referentes à documentação e requisitos gerados durante a etapa
de projeto verificar APÊNDICE C.
3.2.1.10 Arquivo de grupos de comandos de voz
A Figura 29 ilustra a hierarquia do arquivo XML gerado para o registro de um grupo
de comandos de voz.
Figura 29. Estrutura do arquivo XML de um grupo de comandos de voz.
O arquivo de um grupo de comandos de voz será do tipo XML e deve conter as
informações suficientes para que seja possível mapear os grupos a partir da DLL KinectScan.
Um arquivo deste tipo pode ser visualizado no APÊNDICE B, Figura 41.
64
O Quadro 8 mostra os atributos de uma tag do tipo Voice_Commands, estes atributos
armazenam as informações necessárias para identificar as propriedades referentes aos grupos
de comandos de voz.
Atributo Tipo Legenda Ocorrência
Name String Identifica o nome do grupo de comandos de
voz
1
Confidence
Level
Double Identifica o nível de confiança mínimo para
que uma das palavras da lista seja reconhecida
1
Commands Tag Commands Tag referente aos comandos de voz N
Quadro 5. Atributos da tag Voice Commands
O Quadro 8 mostra os atributos de uma tag do tipo Command, estes atributos
armazenam as informações necessárias para identificar cada comando de voz dentro de um
grupo de comandos de voz.
Atributo Tipo Legenda Ocorrência
Command String Identifica o comando de voz 1
Quadro 6. Atributos da tag Commands
3.2.1.11 Arquivo de pose
Para o arquivo de pose devem ser armazenados, tanto os dados da pose quanto os
dados do esqueleto do usuário, para que posteriormente este arquivo possa ser editado através
da aplicação de registro de entradas. A Figura 30 ilustra a hierarquia do arquivo XML gerado
para o registro de uma pose.
65
Figura 30. Estrutura do arquivo XML de pose.
O arquivo de poses também é do tipo XML e contém as informações necessárias para
que seja possível mapear a pose a partir da DLL KinectScan. Este arquivo pode ser
visualizado no APÊNDICE B, Figura 42.
66
Abaixo segue os quadros para descrever os atributos de cada tipo de tag, o tipo do
atributo, a legenda e o número de vezes que o atributo aparece na tag.
O Quadro 7 mostra os atributos de uma tag do tipo Pose que é a tag principal do
arquivo, estes atributos armazenam as informações necessárias para que seja possível avaliar
se a pose do usuário em tempo de execução é igual a pose armazenada no arquivo.
Atributo Tipo Legenda Ocorrência
Name String Nome da Pose 1
Waiting_Time Int Tempo de espera em frames para
ativar a pose
1
User_Skeleton Tag User_Skeleton Tag que armazena a posição de
cada uma das articulações do
usuário
1
SubPoses Tag SubPoses Tag que armazena o conjunto de
subposes
1
Quadro 7. Atributos da tag Pose
A tag User_Skeleton possui como atributo um conjunto de vinte tags do tipo Joint, ou
seja, esta tag armazena todas as articulações mapeáveis do esqueleto do usuário e suas
posições nos eixos X, Y e Z. O Quadro 8 exibe os atributos da tag Joint.
Atributo Tipo Legenda Ocorrência
ID Int Identifica qual a articulação do esqueleto esta tag se
refere.
1
X Double Posição no eixo X 1
Y Double Posição no eixo Y 1
Z Double Posição no eixo Z 1
Quadro 8. Atributos da tag Joint
A tag SubPoses possui como atributo um conjunto de N tags do tipo subpose, onde N
é o número de subposes que o usuário da aplicação selecionou para dar significado para a
pose. O Quadro 9 mostra os atributos de uma tag do tipo Subpose, estes atributos armazenam
as informações necessárias para identificar cada subpose para reconhecimento posterior.
67
Atributo Tipo Legenda Ocorrência
Angle_Error_Margin Double Indica qual a margem de erro permitida para
o ângulo ser aceito
1
Auxiliary_Joint_1 Tag Joint Tag para identificação da articulação auxiliar
um
1
Center_Joint Tag Joint Tag para identificação da articulação central 1
Auxiliary_Joint_2 Tag Joint Tag para identificação da articulação auxiliar
dois
1
Angle Tag Angle Tag para armazenar os resultados dos
cálculos dos ângulos
Quadro 9. Atributos da tag SubPose
Por fim, o Quadro 10 exibe os atributos da tag Angle, onde são armazenados os
resultados dos cálculos, tanto por produto escalar quanto por lei dos cossenos, o resultado do
cálculo da lei dos cossenos é composto por três valores, um em cada plano de projeção, esta
separação também é feita no arquivo XML, o Quadro 11 exibe os atributos da tag
Law_Of_Cosines_Result.
Atributo Tipo Legenda Ocorrência
Scalar_Product_Result Double Indica o resultado do
cálculo do produto escalar
feito através das
articulações que compõe a
subpose
1
Law_Of_Cosines_Result Tag
Law_Of_Cosines_Result
Tag para armazenar os
valores do resultado do
cálculo do produto escalar
em cadaplano de projeção
1
Quadro 10. Atributos da tag Angle
Atributo Tipo Legenda Ocorrência
Plan XY Double Indica o resultado do cálculo da lei dos
cossenos sobre o plano de projeção XY
1
Plan XZ Double Indica o resultado do cálculo da lei dos
cossenos sobre o plano de projeção XZ
1
Plan YZ Double Indica o resultado do cálculo da lei dos
cossenos sobre o plano de projeção YZ
1
Quadro 11. Atributos da tag Law_Of_Cosines_Result
68
3.3 KinectScan
A DLL KinectScan efetua a interação diretamente com o dispositivo Kinect através de
seu SDK. A aplicação cliente criada pelo desenvolvedor deve interagir com esta DLL, pois
ela que possui a responsabilidade de efetuar a varredura do usuário durante a execução da
aplicação final que visa ter o Kinect como interface.
Apesar do SDK do Kinect permitir múltiplos sensores, a KinectScan possui a
limitação de somente um sensor Kinect na aplicação. Então para garantir que haja somente
uma instância de um objeto KinectScanner (principal classe da KinectScan) esta classe segue
o padrão de projeto Singleton.
Esta DLL funciona seguindo a filosofia “dispatcher-listener”. Com isto é possível
criar uma comunicação fracamente acoplada entre um “disparador” de eventos e um
“ouvinte”.
A KinectScan possui um conjunto de eventos para que a aplicação cliente interaja com
o sensor. Cada evento pode ser assinado de forma independente, ou seja, esta DLL só
executará o processamento necessário para disparar os eventos assinados pela aplicação
cliente. Os objetos referentes a eventos fornecidos pela DLL são:
Imagem da câmera RGB;
Informações do esqueleto do usuário;
Detecção de gestos pré-definidos na DLL;
Detecção de poses gravadas na aplicação para registro de entradas;
Detecção de comandos de voz gravados na aplicação para registro de entradas;
Alteração do estado do sensor;
Alteração do estado de algum outro evento.
O evento de imagem de câmera RGB simplesmente repassa o vetor de bytes
correspondente a imagem, quadro por quadro, o que quer dizer que evento será disparado a
cada quadro do Kinect (cerca de 30 quadros por segundo).
No evento que retorna as informações do esqueleto do usuário existe uma conversão
de tipos, partindo das premissas que esta DLL visa evitar a comunicação entre o SDK do
Kinect e a aplicação final. O esqueleto do usuário é representado pela classe Skeleton presente
no namespace do SDK do Kinect e é necessário convertê-la para um tipo que represente o
esqueleto do usuário no namespace da biblioteca.
69
O evento de detecção de gestos não é customizável como os eventos de detecção de
poses e comandos de voz. A KinectScan atualmente reconhece somente os gestos de “Swipe”
para a direita e/ou para a esquerda. O gesto conhecido como “Swipe” significa mover a mão
para alguma direção em um espaço de tempo, um movimento similar ao que é feito na maioria
dos smartphones com o dedo para desbloquear a tela. Caso a aplicação assine este evento,
toda vez que este gesto é detectado pela KinectScan um evento é disparado contendo a
informação referente a direção do gesto que foi reconhecido. Para esta funcionalidade foi
utilizado uma biblioteca de terceiros conhecida como KinectToolBox (KINECTTOOLBOX,
2012).
O evento de reconhecimento de poses feito pela KinectScan rastreia o esqueleto do
usuário em tempo de execução e compara com os arquivos previamente gravados pela
aplicação de registro de entradas. Para comparação das poses gravadas com o esqueleto atual
do usuário, esta DLL compara os ângulos de cada subpose, que são calculados através do
produto escalar. O cálculo do ângulo pela lei dos cossenos utilizando a projeção ortogonal
paralela nos planos XY, XZ e YZ também foi implementado, mas por possuir um custo
computacional maior, foi selecionado o cálculo do produto escalar, conforme resultados
apresentados na seção 4.2.1 .
Quando o evento de reconhecimento de poses é ligado, a KinectScan abre todos os
arquivos gravados pela aplicação de registro de entradas (os arquivos devem estar no mesmo
diretório e este diretório deve ser informado pelo usuário) e inicia uma coleção de objetos do
tipo Pose. A cada quadro do esqueleto do usuário, a KinectScan efetua uma comparação das
poses com a posição atual do usuário.
Este procedimento de comparação possui três comportamentos dependendo do estado
atual da coleção de objetos de pose. Cada objeto deste tipo possui a propriedade status, que é
utilizada nesta comparação.
Caso todas as poses estejam com o status igual a “not_started”, ou seja, não iniciada, a
KinectScan efetua uma busca em toda a coleção de poses para verificar se alguma pose pode
ser reconhecida de acordo com o esqueleto atual do usuário. Caso alguma possa ser
reconhecida, a DLL atualiza a propriedade status para “in_progress”.
Caso alguma das poses possua o status “in_progress” a DLL verifica apenas se a pose
com este estado pode ser reconhecida de acordo com o atual esqueleto do usuário. Caso seja,
70
a DLL efetua uma contagem de quantos quadros esta pose está marcada com este estado e,
quando esta contagem alcança o tempo definido na propriedade WaitingTime o status da pose
é marcado como “accepted” sendo gerado um evento de reconhecimento de pose, notificando
que esta pose foi reconhecida. Caso a pose não seja mais reconhecida o contador é zerado e o
status retorna para “not_started”.
Caso alguma das poses possua o status “accepted” a DLL verifica apenas se a pose
com este estado ainda é reconhecida de acordo com o atual esqueleto do usuário, caso a pose
ainda seja reconhecida a DLL não efetua nenhuma operação. Caso não seja reconhecida, a
DLL gera um novo evento notificando que esta pose foi interrompida e reinicia o status dela
para “not_started”.
O evento de reconhecimento de comando de voz inicia o serviço de comando de voz
do Kinect através do SDK passando como parâmetro para comandos aceitáveis, todos os
comandos de voz contidos nos arquivos. A classe principal que efetua a comunicação com o
Kinect se chama KinectScanner. Esta classe conta com uma coleção de objetos do tipo
KinectSpeechScanner, onde cada objeto se encarrega de verificar o reconhecimento de um
grupo de comandos de voz. Estes SpeechScanners podem ser ativados e desativados
livremente através de métodos fornecidos pela KinectScan.
Cada vez que um comando de voz é dito, é verificado se o scanner do comando que foi
dito está ativo e se o nível de confiança do comando foi maior do que o nível de confiança
mínimo do grupo; caso estas condições sejam cumpridas é gerado um evento de comando de
voz pela KinectScan.
O evento de alteração do estado do sensor é disparado sempre que o estado do
sensor Kinect é alterado, ou seja, caso ele seja desconectado do computador, desconectado da
energia ou alterado seu estado para qualquer outro. O evento gerado notifica o usuário em
qual estado o sensor está.
O funcionamento do evento de alteração de estado dos outros eventos é necessário,
pois a KinectScan funciona de forma assíncrona em relação à seu listener. Quando o listener
solicita a alteração de estado de um evento, há um tempo de sincronização entre a solicitação
e a alteração de fato. Para permitir que o listener execute alguma operação no momento em
que um evento possui o estado alterado existe este evento, que é disparado quando o evento
71
de fato alterou seu estado. Este evento envia as seguintes informações para o listener: evento
que alterou o estado, estado anterior e novo estado.
Os principais métodos fornecidos pela KinectScanner são listados no Quadro 12. Estes
métodos podem alterar o estado da KinectScanner e dos eventos. Os possíveis estados dos
eventos são: running, stopped e paused. Estes e os demais métodos, eventos e propriedades
públicas das classes KinectScanner, KinectSpeechScanner e EventQueue podem ser
visualizados no diagrama de classe mostrado na documentação do projeto no APÊNDICE D.
Método Comportamento
Initialize() Inicia a conexão com o sensor Kinect.
StartNomeDoEvento(?) Inicia o evento descrito no nome do método (existem vários
métodos de start, pois dependendo do tipo do evento ele requer
parâmetros de tipos diferentes).
Stop(EventType event) Para o evento referente ao valor do enumerado passado por
parâmetro.
Pause(EventType event) Pausa o evento referente ao valor do enumerado passado por
parâmetro.
Resume(EventType event) Retoma o evento referente ao valor do enumerado passado por
parâmetro.
Status(EventType event) Retorna o estado atual do evento referente ao valor do
enumerado passado por parâmetro.
Terminate() Finaliza a conexão com o sensor e para todos os eventos
correntes da KinectScanner.
Quadro 12. Principais métodos da KinectScanner
Quando um evento é iniciado através do método “Start”, a KinectScan inicializa os
serviços do Kinect e começa a processar as informações necessárias para o reconhecimento da
pose ou comando de voz associado a este evento; quando este for detectado, o evento é
enviado para a aplicação cliente.
No estado de pausa, todos os serviços com o Kinect e processamento interno
permanecem, porém o evento pausado não é mais adicionado na fila de eventos. Para
interromper o processamento e desligar os serviços do sensor é necessário utilizar o método
“Stop”.
Além destas três classes principais a DLL KinectScan também encapsula todas as
funções para comparação de poses, funções matemáticas e funções para leitura e escrita dos
arquivos XML referentes às entradas customizadas.
72
3.4 KinectServer
Esta aplicação, assim como a ferramenta para captura de poses também é um cliente
da DLL KinectScan. A principal finalidade da KinectServer é criar uma forma de acesso
remoto as funcionalidades disponíveis na KinectScan, para que dessa forma, aplicações que
não suportem o framework .NET 4.5 possam interagir com o sensor.
A KinectServer permite ao usuário iniciar um serviço que pode ser acessado via TCP
IP para interação com o Kinect, ou seja, a aplicação final pode fazer requisições por socket
para o servidor interagir com o Kinect utilizando a DLL KinectScan.
Por padrão, foi definido que o serviço fica no endereço IP de loopback, ou seja,
127.0.0.1 (mesma máquina que está fornecendo o serviço também está consumindo) e na
porta 1234, mas há uma classe que permite a configuração destas propriedades.
A aplicação que consumir o serviço do KinectServer deve conectar-se através do IP e
porta citados acima e oferecer um stream de conexão para que as informações possam ser
compartilhadas (classe NetworkStream na plataforma .NET (MSDN[2], 2012)). A Figura 31
ilustra o fluxograma de funcionamento entre uma aplicação cliente e a KinectServer.
Figura 31. Fluxograma de funcionamento da KinectServer
73
Para a interação entre a KinectServer e a aplicação cliente trafegam pela stream de
conexão compartilhada os objetos serializados (convertidos para bytes). Estes objetos variam
entre: eventos (disparados da KinectServer para a aplicação cliente) e requisições (disparados
da aplicação cliente para a KinectServer).
Os eventos em sua maioria são os mesmos eventos disparados pela KinectScan, porém
no caso da KinectServer existem alguns eventos exclusivos para que o servidor sempre
entregue uma resposta para qualquer requisição. Estes eventos são: ResponseEvent e
GetElevationAngleEvent. O evento ResponseEvent simplesmente retorna uma mensagem ao
usuário notificando o sucesso ou a falha de alguma operação, enquanto que o
GetElevationAngleEvent retorna o ângulo de elevação do sensor Kinect, quando este é
solicitado.
O Quadro 13 ilustra todos os tipos de objetos de requisição que a aplicação cliente
pode utilizar para efetuar a comunicação com a KinectServer.
Requisições Comportamento
ClearEventQueueRequest Solicita que o servidor limpe a fila de eventos da KinectScan.
GetElevationAngleRequest Solicita que o servidor retorne o ângulo de elevação do sensor.
SetElevationAngleRequest Solicita que o servidor insira o valor enviado em uma
propriedade deste objeto ao ângulo de elevação do sensor.
StartNomeDoEventoRequest Existem vários objetos para iniciar os eventos da KinectScan,
um para cada tipo de evento, já que alguns eventos necessitam
de parâmetros para serem inicializados. Esta requisição solicita
ao servidor que inicie um evento.
PauseRequest Solicita ao servidor que o evento enviado em uma propriedade
deste objeto seja pausado.
ResumeRequest Solicita ao servidor que o evento enviado em uma propriedade
deste objeto seja retomado.
StopRequest Solicita ao servidor que o evento enviado em uma propriedade
deste objeto seja parado.
StatusRequest Solicita ao servidor que retorne o estado do evento enviado em
uma propriedade deste objeto.
TryGetEventRequest Solicita ao servidor que envie o primeiro objeto da fila de
eventos, caso a fila esteja vazia o servidor retorna um evento
de mensagem para notificar isso a aplicação cliente.
Quadro 13. Objetos para efetuar a requisição
Para atender estas requisições o servidor conta com um sistema multithreads, ou seja,
cada requisição é tratada em sua própria thread. Sempre há uma, e somente uma thread
escutando a porta definida para a conexão com o servidor (padrão 1234). Quando o servidor
74
recebe uma requisição, é aberta uma nova thread para esta requisição e a thread principal
volta a escutar a porta de conexão novamente.
Esta aplicação oferece uma interface gráfica para que seja possível iniciar e parar o
servidor e visualizar as informações referentes ao sensor Kinect e a DLL KinectScan. Na
interface também é possível visualizar um log do servidor, que descreve cada requisição,
resposta ou evento reconhecido pelo servidor, esta interface pode ser visualizada na Figura 32.
Figura 32. Interface da KinectServer
A documentação do projeto da aplicação KinectServer pode ser visualizada no
APÊNDICE E.
3.5 KinectEvents
A KinectEvents é uma DLL que funciona em conjunto com a KinectScan. A
KinectEvents possui as classes de modelo da aplicação (poses, comandos de voz, subposes,
etc); as classes que representam dados do Kinect, como por exemplo, a classe que representa
o esqueleto do usuário, e os enumerados e as classes de comunicação (requests para o
75
KinectServer e events disparados da KinectScan), enquanto que a KinectScan encapsula a
conexão com o sensor e as funções referentes às operações com o sensor.
As únicas funções encapsuladas nesta DLL são as funções para serializar e
desserializar os objetos de comunicação, pois todo o tráfego de bytes que ocorre entre o
KinectServer e seu cliente são objetos de comunicação convertidos em bytes.
Caso a aplicação final seja cliente direto da KinectScan não é necessário utilizar
nenhuma função de serialização, pois o objeto retornado é um Event no seu estado original.
Esta aplicação também possui uma classe chamada KinectServerClient que deve ser
utilizada para criar a comunicação com o servidor da aplicação KinectServer. Esta classe
possui as propriedades para configurar a porta e o IP de conexão. Além disso, ela possui o
método público SendRequest, que espera como parâmetro um objeto do tipo Request.
Este método se encarrega de converter o objeto de Request para bytes e enviá-lo ao
servidor. Para que a aplicação cliente possa obter a resposta do servidor esta classe conta com
o evento ResponseFromServer, este evento é disparado toda vez que o servidor responde a
uma requisição, passando por parâmetro o evento disparado pelo servidor.
3.6 KinectUnity
A DLL KinectUnity tem como principal característica ser um consumidor dos eventos
da DLL KinectScan, ou seja, todo o tratamento aos eventos disparados pela classe
KinectScanner da DLL KinectScan serão implementados nesta DLL. A Figura 33 ilustra a
comunicação entra a KinectUnity e o sensor Kinect.
Figura 33. Comunicação entre a KinectUnity de entradas e o Kinect
76
Esta DLL faz a integração entre a ferramenta Unity e o sensor de movimento Kinect.
Esta DLL possui códigos que interagem diretamente com as classes que manipulam a entrada
de dados nos projetos da Unity, sobrecarregando uma classe chamada Input.
A KinectInput (classe utilizada para sobrecarregar a classe Input) possui todos os
métodos da classe Input e os métodos para verificar se alguma entrada (pose, gesto ou
comando de voz) foi ativada pelo usuário.
Quando a classe KinectInput é criada ela cria três objetos do tipo Dictionary
(Hashtable). Estes dicionários utilizam uma chave contendo o nome das entradas que o
usuário pode efetuar através de poses, gestos ou comandos de voz e um valor ligado a esta
chave que pode variar entre verdadeiro ou falso.
O método que verifica as entradas do KinectInput simplesmente verifica o valor do
campo no dicionário de dados e retorna ao script do jogo se a entrada está ou não acionada,
para que o script efetue o tratamento relativo à entrada.
Assim como a KinectScanner esta classe também é um Singleton, não permitindo que
haja mais de uma instância dela mesma na aplicação.
A classe KinectInput também possui o método SendRequest que recebe um objeto do
tipo Request por parâmetro, internamente o método é simplesmente repassado para a classe
KinectServerClient, permitindo assim que o usuário envie uma requisição do servidor através
de um script C# de um projeto na Unity.
A proposta inicial desta DLL era efetuar uma comunicação entre o Kinect e a Unity
através da DLL KinectScan, porém, mesmo com a Unity utilizando scripts na linguagem C#,
ela não possui um compilador .NET padrão da Microsoft e sim o compilador Mono, explicado
anteriormente, e desta forma, existe um atraso na implementação dos recursos mais atuais
disponibilizados pela Microsoft.
Em sua versão 3.5.6f4(versão atual na data deste trabalho) a Unity possui este
compilador na versão 2.6. Esta versão do compilador não aceita nenhuma DLL .NET que
esteja ou que possua uma dependência no framework 4.0 ou superior.
A DLL do Kinect é executada sobre o framework 4.0, logo, a KinectScan possui uma
dependência no framework .NET 4.0, o que impossibilita a conexão direta entre a
KinectUnity e a KinectScan.
Após perceber este problema foram pesquisadas soluções alternativas em alguns
trabalhos similares: Kinect Wrapper, que utilizava o Kinect SDK em sua versão em C++
(KINECTWRAPPER, 2012) e o Kinect Daemon, onde a conexão com o Kinect era feita
através de um servidor Socket (KINECTDAEMON, 2012).
77
Apesar de contribuírem com ideias para a solução implementada, nenhuma das
soluções apresentadas nos dois projetos poderiam ser diretamente utilizadas neste trabalho,
pois eles fazem conexão diretamente com o Kinect e a Unity e a proposta do trabalho era
conectar a Unity ao Kinect através da KinectScan.
A primeira tentativa de solução para a dependência do .NET 4.0 foi seguir o exemplo
da Kinect Wrapper, visto que baseado nas pesquisas iniciais ela parecia oferecer melhores
resultados, já que não dependia de uma segunda aplicação executando (serviço).
Foi escrito uma nova versão da KinectScan em C++, porém o funcionamento interno
das threads na KinectScan utilizava DLLs no namespace do Windows (classe Dispatcher) e
estas DLLs não podem ser utilizadas no compilador Mono, o que impossibilitou a adoção
desta solução.
Então, uma segunda implementação baseada na ideia de serviço apresentada no
trabalho KinectDaemon, foi criada a aplicação KinectServer e a classe KinectServerClient,
permitindo desta forma que a KinectUnity se conecte à KinectScan através da aplicação
servidor.
3.7 Projeto feito na Unity modificado
O projeto feito na Unity selecionado para efetuar a modificação de sua interface foi
baixado através da AssetStore (loja disponível dentro da ferramenta Unity). Este projeto (5
Unity games examples: C#) é um exemplo de cinco jogos que utilizam scripts na linguagem
C#. Para alteração da interface, foi selecionado o jogo Jump Game.
Para que este jogo pudesse ter sua interface alterada, do teclado para o Kinect, foi
necessário criar uma pasta chamada “Plugins”, dentro desta pasta é necessário importar as
DLLs KinectEvents e KinectUnity.
Após a importação das DLLs foi possível instanciar um objeto da classe KinectInput
via script e interagir com a aplicação de servidor KinectServer. É necessário também que a
aplicação KinectServer esteja sendo executada, visto que é através dela que ocorre a
comunicação entre o jogo e o Kinect.
O jogo Jump Game trata-se de um jogo plataforma em 2D, onde o personagem fica
constantemente pulando e são sorteados os locais de várias plataformas, o dever do jogador é
saltar entre estas plataformas e não deixar o personagem cair delas.
78
Após sair do chão o personagem não pode mais cair das plataformas. Inicialmente o
personagem utilizava as setas no teclado para se movimentar, após a adaptação da interface
utilizando a biblioteca criada neste projeto, o usuário deve posicionar-se na frente do Kinect e
executar as poses que foram introduzidas ao jogo ou os comandos de voz: “Right” e “Left”
tanto as poses quanto os comandos de voz são utilizados para movimentar o personagem para
as direções direita ou esquerda. A Figura 34 ilustra as poses que são aceitas no jogo
(lembrando que a imagem que é obtida da câmera do Kinect é invertida entre direita e
esquerda como um espelho).
Figura 34. Poses aceitas no jogo
A pontuação do jogador é acumulada pela altura máxima que o usuário conseguiu
chegar com o personagem. A Figura 35 ilustra a imagem do jogo sendo executado.
79
Figura 35. Jogo em execução
3.8 Restrições
O projeto possui algumas restrições descritas na lista abaixo devido à inviabilidade de
de implementação no tempo estabelecido e ao escopo do trabalho:
Não foi implementado nenhum algoritmo para detecção de gestos (foi utilizado
um projeto de terceiros);
Não foi implementado nenhum algoritmo para reconhecimento de voz, mas foi
utilizado o disponibilizado pela Microsoft;
Não foi implementado o reconhecimento de voz em nenhum outro idioma além
do padrão (inglês – Estados Unidos);
O algoritmo para detecção de pose foi feito no mínimo com três articulações;
Os problemas com detecção do esqueleto do Kinect, como por exemplo, luz ou
falta de espaço não foram considerados.
80
4 CONCLUSÕES
Neste capítulo estão descritos os resultados obtidos após a implementação e testes
deste projeto, sugestões para trabalhos futuros, cumprimento dos objetivos e conclusões que
podem ser obtidas após a realização deste projeto.
4.1 Objetivos
Todos os objetivos específicos listados na seção 1.2.2 foram cumpridos ao longo do
desenvolvimento deste projeto. Todos os estudos e pesquisas podem ser visualizados na seção
FUNDAMENTAÇÃO TEÓRICA, onde constam especificações sobre o Kinect, a Unity, as
formas para comparação de pose e sobre o Microsoft Kinect SDK.
A implementação e utilização da biblioteca pode ser visualizada na seção
Desenvolvimento, onde é exibida de forma descritiva e através de figuras desde a criação até
a utilização da biblioteca.
Todos os resultados dos testes de acordo com os requisitos propostos podem ser
visualizados na seção seguinte (Resultados).
O objetivo geral (vide seção 1.2.1 ) mostra-se cumprido ao longo deste projeto, visto
que ao final da implementação e após algumas adaptações foi possível integrar a biblioteca
criada com um projeto na ferramenta Unity.
4.2 Resultados
Nesta subseção são descritos os resultados obtidos através de testes e análises, bem
como as conclusões que se pode tirar a partir dos mesmos.
4.2.1 Algoritmos para cálculo do ângulo
Os dois algoritmos para detecção de poses foram analisados no que diz respeito a sua
performance em tempo de resposta. Foram implementados e avaliados os algoritmos para
cálculo de ângulo através do produto escalar e através da lei dos cossenos, descritos na seção
3.1
81
O experimento utilizado para tal avaliação entre os dois algoritmos de cálculos para
detecção de pose consiste em um teste de repetição onde eram cálculados várias vezes os
ângulos de um conjunto de subposes. Estes testes foram medidos por tempo na unidade
milisegundos e foi extraido uma amostragem de 101 testes. Houve o descarte da primeira
rodada de teste, pois na primeira execução os objetos são alocados em memória influenciando
no tempo final, o que torna o primeiro teste sempre mais lento que os demais. Os quadros 14,
15 e 16 ilustram o resultado extraido desta avaliação.
Avaliação por tempo Lei dos Cossenos Produto Escalar
Mais rápido: 3,546675 ms < 0 ms
Mais lento: 3,6014 ms < 0 ms
Média: 3,580317 ms < 0 ms
Total: 358,0317 ms < 0 ms
Quadro 14. Detecção de uma pose com 1 subpose
Avaliação por tempo Lei dos Cossenos Produto Escalar
Mais rápido: 15,4671 ms < 0 ms
Mais lento: 15,686 ms 1,3028 ms
Média: 15,60167 ms 0,073018 ms
Total: 1560,167 ms 7,3018 ms
Quadro 15. Detecção de uma pose com 10 subposes
Avaliação por tempo Lei dos Cossenos Produto Escalar
Mais rápido: 15,5461 ms < 0 ms
Mais lento: 31,2006 ms 15,6545 ms
Média: 15,7582 ms 0,312154 ms
Total: 1575,82 ms 31,2154 ms
Quadro 16. Detecção de uma pose com 20 subposes
82
Com o resultado destes testes é possível visualizar que o cálculo de ângulos através do
produto escalar se mostra mais eficiente independente do número de subposes. Portanto, a
DLL KinectScan passou a utilizar apenas o cálculo de ângulos através do algoritmo produto
escalar. O gráfico na Figura 36 ilustra a comparação entre os algortimos testados utilizando o
tempo médio.
Figura 36. Gráfico de comparação entre os algoritmos para cálculo de ângulos
4.2.2 Complexidade de utilização da biblioteca proposta
Ao longo da implementação do projeto ocorreu um problema de compatibilidade entre
o compilador Mono e o SDK proposto pela Microsoft, para mitigar este problema foi
desenvolvida a aplicação KinectServer (vide seção 3.4) e a classe KinectServerClient. Através
destas duas implementações a integração entre o hardware Kinect e a ferramenta Unity se
mostrou bem sucedida.
Como exemplo de funcionamento este projeto apresenta as duas formas de conexão
com o sensor Kinect: a primeira através da utilização direta da KinectScan (demonstrada na
aplicação para registro de entrada) e a segunda através da utilização do KinectServerClient
(implementado na KinectUnity).
83
Todos os eventos possíveis disparados pela KinectScan são exemplificados neste
projeto na ferramenta para registro de entradas (vide seção 3.2), exceto a detecção de gestos.
O projeto alterado na Unity (vide seção 3.7) também exemplifica a detecção de poses e
comandos de voz a partir de arquivos XML via scripts.
Para exemplificar as diferentes formas de utilização do sensor Kinect e a facilidade de
interação com o mesmo através da biblioteca proposta, a Figura 37, Figura 38 e a Figura 39
mostram as linhas de código necessárias para integrar uma aplicação ao Kinect.
Figura 37. Criando uma conexão com o sensor via KinectScan
84
Figura 38. Criando uma conexão com o sensor via KinectServerClient
Figura 39. Criando uma conexão com o sensor via KinectUnity através de scripts na Unity
85
Em todos os exemplos é possível estabeler a comunicação com o sensor e assinar
eventos em menos de dez linhas, o que mostra o sucesso quanto facilidade de utilização do
sensor com a biblioteca proposta.
Para um auxílio sobre a forma de se utilizar as DLLs, o projeto também oferece a
documentação das DLLs que podem ser utilizadas pelo desenvolvedor (vide APÊNDICE C).
4.3 Trabalhos Futuros
Durante o desenvolvimento deste trabalho foram identificadas algumas
funcionalidades interessantes de serem incorporadas ao projeto, que ficam como sugestões
para trabalhos futuros.
A remoção da limitação de um único sensor ligado a KinectScan pode prover um
mecanismo interessante para certos tipos de aplicações, como por exemplo, aplicações que
visam efetuar um mapeamento 3D de locais ou objetos, ou para aplicações que necessitam de
mais usuários. Para efetuar isso deve-se pensar em uma forma de gerenciamento dos sensores
através do Id de cada sensor e utilizar uma coleção de objetos do tipo KinectScanner ao invés
de apenas uma instância.
A remoção da limitação de um cliente para o KinectServer também pode ter um
resultado interessante, algo similar a um broadcast entre várias aplicações executando em
paralelo conectadas ao servidor.
Apesar de possuir o reconhecimento para gestos, a KinectScan provê apenas o
reconhecimento do gesto swipe para as duas direções. Incluir um catálogo maior de gestos, ou
criar um mecanismo de customização de gestos pode gerar grandes avanços neste trabalho,
visto que gestos assim como poses e comandos de voz são uma forma de interação bastante
natural ao usuário.
Uma extensão de idiomas para reconhecimento de fala pode ser uma nova
funcionalidade interessante, permitindo uma interação mais natural, já que o usuário não
precisaria falar somente em inglês.
E por fim, a própria utilização do sensor para aplicações fora da solução proposta na
área de jogos pode demonstrar mais ainda os resultados positivos da NUI dentro da
computação.
86
4.4 Considerações Finais
Da maneira com que foi projetado o desenvolvimento da biblioteca será possível
integrá-la com qualquer tipo de aplicação que aceite o uso dos recursos do Kinect como forma
de interface, o que amplia o alcance do uso da biblioteca proposta.
Ao decorrer das pesquisas e análises também foi notado que o reconhecimento de
gestos genéricos não tem uma implementação trivial e nem genérica. Após alguns estudos
mais aprofundados foi concluído que a implementação de reconhecimento de gestos genéricos
fugiria do escopo de complexidade inerentes ao TTC e portanto esta característica não será
agregada à biblioteca.
Optou-se por incluir no projeto além dos reconhecimentos de entradas customizadas
(poses e comandos de voz) mais funcionalidades do Kinect (vide seção 3.3). Desta forma,
além de customizar diferentes tipos de entradas também é possível utilizar recursos do Kinect,
como por exemplo a câmera RGB.
A implementação deste projeto foi desafiadora e inovadora. O trabalho proposto não
somente criou uma conectividade do Kinect com uma aplicação ou um jogo específico, como
ofereceu uma integração que busca ser a mais genérica e flexível possível para tornar o
desenvolvimento com o Kinect mais simples e rápido.
Com a ferramenta proposta os desenvolvedores de aplicações e jogos podem migrar
para esta interface de forma mais simples, sem exigir conhecimento aprofundado no
desenvolvimento focado para o hardware Kinect.
Foram seguidas as específicações propostas no capítulo Desenvolvimento e houve um
bom gerenciamento das mudanças ao longo do desenvolvimento, o que fez com que este
projeto alcansasse todos os seus objetivos, conforme descrito na seção 4.1.
87
REFERÊNCIAS
ALBITAR, Chadi; GRAEBLING, Pierre; DOIGNOM, Christophe. Robust Structured Light
Coding for 3D Reconstruction. 2007. Disponível em:
<http://nguyendangbinh.org/Proceedings/ICCV/2007/data/papers/ICCV/145.pdf>. Acessado
em 26 abr. 2012.
ASHLEY, James; WEBB, Jarret. Beginning Kinect Programming with the Microsoft Kinect
SDK. 1. ed. Apress. 2012.
BESSA, Aline; SOUSA, Caio T.; BEZERRA, Carlos E.; MONTEIRO, Ivan; BANDEIRA,
Humberto; SOUZA, Rodrigo. O Desenvolvimento de um Motor Multiplataforma para Jogos
3D. Disponível em:< http://indigente.ufba.br/pt-br/system/files/inge-sbgames2007.pdf >
BLAKE, Andrew; KIPMAN, Alex; MOORE, Richard; FINOCCHIO, Mark; SHARP, Toby;
COOK, Mat; FITZGIBBON Andrew; SHOTTON Jamie. Real-Time Human Pose
Recognition in Parts from Single Depth Images. Disponível em:
<http://research.microsoft.com/pubs/145347/BodyPartRecognition.pdf>. Acessado em 26 abr.
2012.
BLAKE, Andrew; KIPMAN, Alex; MOORE, Richard; FINOCCHIO, Mark; SHARP, Toby;
COOK, Mat; FITZGIBBON Andrew; SHOTTON Jamie. Real-Time Human Pose
Recognition in Parts from Single Depth Images: Supplementary Material. 2011. Disponível
em: < http://research.microsoft.com/pubs/145347/SupplementaryMaterial.pdf>. Acessado em
26 abr. 2012.
BUXTON, Bill. Gesture Based Interaction. Disponível em:
<http://www.billbuxton.com/input14.Gesture.pdf>. Acessado em 10 jun. 2012.
COMPUTERHOPE. Command Line VS GUI. 2012. Disponível em:
<http://www.computerhope.com/issues/ch000619.htm>. Acessado em 28 abr. 2012.
FOLEY, James D.; DAM, Andries van; FEINER, Steven K.; HUGHES, Jhon F. Computer
Graphics: Principles and Practice. 2. ed. Boston: Addison-Wesley, 1997.
GREGORY, Jason. Game engine architecture. 1. Ed. New York: A K Peters/CRC Press,
2009.
88
INFOWESTER. Microsoft lança Kinect para Windows. 2012. Disponível em:
<http://www.infowester.com/noticias/alem-do-xbox-microsoft-lanca-kinect-para-windows/>.
Acessado em 15 mar. 2012
KEAN, Sean; HALL, Jonathan; PERRY, Phoenix. Meet the Kinect. 1. ed. Apress. 2012.
KINECT. Apresentando o Kinect. 2011. Disponível em: <http://www.xbox.com/pt-
BR/kinect>. Acessado em 15 mar. 2012.
KINECTWRAPPER. Microsoft Kinect – Bringing the Kinect SDK in to Unity. 2012.
Disponível em: <http://wiki.etc.cmu.edu/unity3d/index.php/Microsoft_Kinect_-
_Microsoft_SDK>. Acessado em 20 set. 2012.
KINECTDAEMON. Unity3d and Microsoft Kinect SDK. 2012. Disponível em:
<http://www.see seethroughskin.com/blog/?p=1159>. Acessado 22 de set. 2012.
KINECTTOOLBOX. Kinect Toolbox. 2012. Disponível
em:<http://kinecttoolbox.codeplex.com/>. Acessado em 18 set. 2012.
KINECTSDK. Kinect for Windows. 2012. Disponível em:< http://www.microsoft.com/en-
us/kinectforwindows/develop/developer-downloads.aspx>. Acessado em 15 mar. 2012
KINECTAUDIO. Kinect Audio: Preparedness Pays Off. 2011. Disponível em:
<http://research.microsoft.com/en-us/news/features/kinectaudio-041311.aspx>. Acessado em
25 abr. 2012
KINECTVIDEOAUDIO. Audio and Video Research in Kinect. 2011. Disponível em:
<http://research.microsoft.com/en-
us/um/redmond/events/latamfacsum2011/presentations/day_2/plenaries/alex_acero.pdf>.
Acessado em 25 abr. 2012.
LEADBETTER, Richard. PrimeSense: Além do Natal. 2010. Disponível em:
<http://www.eurogamer.pt/articles/digitalfoundry-primesense-artigo>. Acessado 26/04/2012
MENDES, Cláudio Lúcio. Jogos Eletrônicos: diversão, poder e subjetivação 1. ed. Campinas:
Papirus, 2006.
89
MICROSOFT. Kinect for Windows. 2012. Disponível em:< http://www .microsoft.com/en-
us/kinectforwindows/discover/features.aspx>. Acessado em: 10 mar. 2012.
MONO. Mono Project. 2012. Disponível em:< http://www.mono-project.com/Main_Page>.
Acessado em: 22 out. 2012.
MONOCOMPATIBILITY. Mono Compatibility. Disponível
em:<http://docs.unity3d.com/Documentation/ScriptReference/MonoCompatibility.html>.
Acessado em: 22 out. 2012.
MSDN. Microsoft.Kinect. 2012. Disponível em:<http://msdn.microsoft.com/en-
us/library/hh855419.aspx>. Acessado em: 24 abr. 2012.
MSDN[2]. NetworkStream Class. 2012. Disponível em:<http://msdn.microsoft.com/en-
us/library/system.net.sockets.networkstream.aspx>. Acessado em: 20 set. 2012.
OLIVEIRA NETTO, Alvin Antônio de Oliveira. IHC: Interação Humano Computador -
Modelagem e Gerência de Interfaces com o Usuário. 1. ed. Florianópolis: VisualBooks, 2004.
OPENNI. OpenNI. 2012. Disponível em:< http://openni.org>. Acessado em: 10 mar. 2012.
PREECE, Jenny; ROGERS, Yvonne; SHARP, Helen; BENYON, David; HOLLAND, Simon;
CAREY, Tom. Human-Computer Interaction. 1. ed. Nova Jersey: Addison-Wesley, 1994.
PRIMESENSE. Natural Interaction. 2011. Disponível em:< http://www.primesense.com >.
Acessado em 26 abri. 2012.
SANTOS, Rafael. “Desenvolvimento de games no Brasil Vale a Pena?”. 2012. Disponível
em: <http://www.techtudo.com.br/platb/desenvolvimento/2011/06/11/desenvolvimento-de-
games-no-brasil-vale-a-pena/>. Acessado em 15 mar. 2012.
SHNEIDERMAN, Ben. Designing the User Interface: Strategies for Effective Human-
Computer Interaction. 3. ed. Nova Jersey: Addison Wesley, 1998.
TECMUNDO. O que é engine ou motor gráfico?. 2011. Disponível
em:<http://www.tecmundo.com.br/video-game/9263-o-que-e-engine-ou-motor-grafico-.htm>.
Acessado em: 15 mar. 2012
90
UNITY. Site do fabricante. 2012. Disponível em: < http://unity3d.com/#unity35 >. Acesso
em: 09 mar. 2012.
UNITY3DBRASIL. Fórum brasileiro. 2012. Disponível
em:<http://forum.unity3dbrasil.com>. Acessado em: 10 mar. 2012
VISUALSTUDIO. Visual Studio. 2012. Disponível em:
<http://www.microsoft.com/visualstudio/pt-br >. Acessado em: 10 mar. 2012.
VALE, Felique Roque do. “Jogos de Computador e Sistemas Emergentes”. 2005. Disponível
em:< http://recil.grupolusofona.pt/bitstream/10437/648/1/vale_jogoscomp>. Acessado em 16
maio. 2012.
WINOGRAD, Terry. ”Bringing Design to Software”. 1996. Disponível em:
<http://hci.stanford.edu/publications/bds/>. Acessado em 21 abr. 2012.
91
GLOSSÁRIO
SDK Um software development kit (SDK), nada mais é do que uma coleção
de funções pré-desenvolvidas que um desenvolvedor pode utilizar na
criação de sua aplicação, como por exemplo, o SDK do Kinect, que
fornece métodos para acessar o periférico em linguagem de alto nível
Socket Portas virtuais para a conexão de programas em um computador via
um protocolo de rede.
Dispatcher Programa que despacha eventos para outros programas.
Listener Programa que “escuta” os eventos de um programa dispatcher.
Motor de Jogos Programa utilizado para criação de jogos que fornece várias
funcionalidades aos desenvolvedores e designers.
92
APÊNDICE A. FUNCIONAMENTO ENTRE AS THREADS DA
KINECTSCAN E SEU LISTENER
A interação da KinectScan (dispatcher) com seu listener ocorre principalmente a partir
da classe KinectScanner.
Quando a propriedade Instance da classe KinectScanner é acessada pela primeira vez
o objeto é criado, nas demais vezes o objeto é apenas repassado, utilizando a mesma instância.
Quando este objeto é criado ele executa um método de processamento em um thread paralela
à thread da aplicação, este método fica varrendo constantemente a lista de eventos verificando
se algum evento dentre os fornecidos teve seu estado alterado, caso sim, são executadas as
operações necessárias para cumprir o que foi solicitado. Todo o processamento quando o
evento está sendo executado e quando um evento é disparado ocorre nesta thread de
processamento.
Desta forma a thread em que a KinectScanner executa a comunicação com o Kinect é
separada da thread da aplicação final. Então para comunicação entre a aplicação final e a
thread da KinectScanner existe um objeto chamado EventQueue (fila de eventos). Este objeto
está agregado a classe KinectScanner e é inicializado juntamente com a própria
KinectScanner (antes da KinectScanner entrar no método de processamento). Este objeto é
inicializado na thread da aplicação cliente e em seu próprio construtor este objeto armazena a
thread da aplicação cliente em um objeto do tipo Dispatcher, este tipo de objeto é fornecido
na DLL WindowsBase, do framework .NET e é utilizado para despachar métodos para uma
outra thread paralela a que este objeto está sendo usado.
Cada vez que um evento é gerado ele é adicionado nesta fila de eventos, o listener
desta DLL pode consumir estes eventos através do método GetEvent() na classe EventQueue.
Caso o listener deseje também é possível interpretar o evento EventAdded, este evento
notifica a aplicação sempre que um novo objeto de evento é adicionado no objeto
EventQueue. A Figura 40 ilustra a comunicação entre as threads da aplicação e a thread de
processamento da KinectScan.
93
Figura 40. Comunicação das threads da aplicação cliente e da KinectScan
94
APÊNDICE B. EXEMPLO DE ARQUIVOS XML DE
ENTRADAS
A Figura 41 e a Figura 42 ilustram os arquivos XML de grupo de comandos de voz e
de pose respectivamente.
Figura 41. Arquivo XML de um grupo de comandos de voz
95
Figura 42. Arquivo XML de uma pose
96
APÊNDICE C. PROJETO DA FERRAMENTA PARA
REGISTRAR ENTRADAS
Este apêndice lista os requisitos funcionais, não funcionais, regras de negócio, casos
de uso e seus respectivos cenários, ou seja, toda a documentação relacionada ao projeto da
ferramenta para registrar entradas.
C.1. Requisitos
Abaixo segue a lista com os requisitos funcionais relacionados à ferramenta para
registrar entradas:
RF01 – Esta aplicação deve reconhecer o esqueleto do usuário;
RF02 – Esta aplicação deve permitir ao usuário criar uma pose;
RF03 – Esta aplicação deve permitir ao usuário criar um conjunto de subposes
dentro de uma pose;
RF04 – Esta aplicação deve permitir ao usuário criar um conjunto de comandos
de voz;
RF05 – Esta aplicação deve gerar um arquivo XML para que seja possível
armazenar as informações necessárias para o reconhecimento de uma pose ou
comando de voz;
RF06 – Esta aplicação deve permitir ao usuário efetuar o teste de sua pose e
calibre o grau de tolerância de erro;
RF07 – Esta aplicação deve permitir ao usuário efetuar testes em seus
comandos de voz para que calibre seu grau de confiança.
Abaixo segue a lista com os requisitos não funcionais:
RNF01 – O framework desenvolvido deve ser flexível para a facilidade da
migração de uma interface padrão de uma aplicação para a interface do Kinect;
97
RNF02 – Esta aplicação deve ser desenvolvida de forma que seja possível
interagir com comandos de voz para criar uma pose;
RNF03 – Esta aplicação deve utilizar a câmera RGB e o reconhecimento de
esqueletos do Kinect.
Abaixo segue a lista com as regras de negócio:
RN01 – O formulário “Compose Pose” só deve ser habilitado após a criação de
uma pose;
RN02 – Uma pose deve ser formada por uma ou mais subposes;
RN03 – Uma subpose deve ser formada por três articulações.
98
C.2. Casos de Uso e Cenários
Segue os casos de uso e seus respectivos cenários para a aplicação que registra e gera
os arquivos XML referente às entradas. A Figura 43 ilustra os quatro casos de uso principais
desta aplicação e suas dependências.
Figura 43. Casos de uso para ferramenta de criação de poses
Cenário do caso de uso “UC01 – Criar uma pose”
Cenário principal
1. O usuário entra na tile “Create a New Pose”
2. O usuário digita no formulário “Record Pose” os campos obrigatórios: “Name” e
“Waiting Time”;
3. O usuário fica em frente ao Kinect, fica na pose em que deseja gravar e diz a frase
“Record Pose” em voz alta;
4. A aplicação deve jogar a imagem do esqueleto do usuário para o painel ao lado da câmera
RGB.
99
Cenário do caso de uso “UC02 – Criar a composição de subposes dentro de uma
pose”
Pré-condição
1. O usuário deve executar os processos descritos no caso de uso anterior (“UC01 – Criar
uma pose”) e entrado no formulário para compor um pose;
Cenário principal
1. O usuário deve digitar o valor da margem de erro do ângulo da subpose no campo Error
Margin, após isso pressionar o botão “Add” cujo ícone é o sinal de soma;
2. A aplicação deve alterar o ícone e a descrição do botão “Add” para a descriçao “Cancel” e
para o ícone de pausar ( | | );
3. O usuário deve pressionar as três articulações que compões a subpose (cada joint
pressionado possui a cor alterada para branco para que a aplicação não permita adicionar
duas vezes a mesma articulação);
4. A aplicação deve pintar novamente o esqueleto da cor padrão e inserir um registro de
subpose na grade da direita.
Cenário alternativo
No passo 1 caso o usuário não digite o valor da margem de erro do ângulo a aplicação
exibirá uma mensagem de notificação e não permitirá proceguir.
No passo 3 o usuário pode pressionar o botão “Cancel” que substituiu o botão “Add”.
3.1. O usuário deve clicar no botão “Cancel” cujo ícone é o caractere “X”;
3.2. A aplicação deve pintar novamente o esqueleto da cor padrão.
Cenário de exceção
Caso o usuário não tenha registrado nenhuma pose o sistema não permitirá ao usuário
entrar na aba “Compose”.
Cenário do caso de uso “UC03 – Testar uma pose”
Pré-condição
1. O usuário deve executar os processos descritos nos casos de uso anteriores (“UC01 –
Criar uma pose” e “UC02 – Criar a composição de subposes dentro de uma pose”) e após
isso o usuário deve ter entrado no formulário para testar uma pose;
Cenário principal
1. O usuário deve se posicionar de frente ao Kinect;
100
2. O sistema deve exibir as informações referentes a pose a ser testada e a pose atual do
usuário, exibindo os valores dos ângulos;
3. O usuário deve efetuar a pose que deseja testar;
4. O sistema deve exibir a mensagem de feedback para identificar se a pose foi ou não
reconhecida.
Cenário do caso de uso “UC04 – Criar um arquivo XML de uma pose”
Pré-condição
1. O usuário deve executar os processos descritos nos casos de uso anteriores (“UC01 –
Criar uma pose” e “UC02 – Criar a composição de subposes dentro de uma pose”);
Cenário principal
1. A aplicação possuir uma configuração para o usuário selecionar o diretório em que o
arquivo será gravado;
2. O usuário deve selecionar o diretório;
3. O usuário deve pressionar o botão “Save” cujo ícone é um disquete.
4. A aplicação deve gerar um arquivo XML no formato descrito no projeto (Arquivo de
pose) conforme as informações do usuário.
Cenário de exceção
Após o passo 3 a aplicação deve validar os campos obrigatórios: “Name” e “Waiting
Time” da aba “Record” e também deve ser verificado se há uma ou mais subposes
adicionadas, caso estas validações não sejam cumpridas deve ser exibida uma mensagem ao
usuário notificando o que falta ser preenchido.
Caso o usuário não selecione um diretório válido a aplicação deve exibir uma
mensagem notificando que o diretório é inválido.
Cenário do caso de uso “UC05 – Criar Comandos de Voz”
Cenário principal
1. O usuário deve entrar na tile “Create a New Voice Command”;
2. O usuário deve preencher os campos: “Group Name” e “Confidence Level”;
3. O usuário deve preencher o campo “Command” e pressiona o botão “Add” cujo ícone é o
sinal de soma;
4. A aplicação possuir uma configuração para o usuário selecionar o diretório em que o
arquivo será gravado;
5. O usuário deve selecionar o diretório;
6. O usuário pressiona o botão “Save” cujo ícone é um disquete.
5. A aplicação deve gerar um arquivo XML no formato descrito no projeto (Arquivo de
grupos de comandos de voz) conforme as informações do usuário.
101
Cenário de exceção
Após o passo 6 a aplicação deve validar os campos obrigatórios: “Group Name” e
“Confidence Level” e também deve ser verificado se há um ou mais comandos de voz
adicionados, caso estas validações não sejam cumpridas deve ser exibida uma mensagem ao
usuário notificando o que falta ser preenchido.
No passo 6 caso o usuário não selecione um diretório válido a aplicação deve exibir
uma mensagem notificando que o diretório é inválido.
Cenário do caso de uso “UC06 – Testar Comandos de voz”
Pré-condição
1. O usuário deve executar os processos descritos no caso de uso anterior (“UC05 – Criar
Comandos de Voz”) e entrar no formulário para teste de grupo de comandos de voz;
Cenário principal
1. O usuário deve pressionar o botão “Test”;
2. A aplicação deve permitir ao usuário dizer os comandos do grupo;
3. Quando o comando dito pelo usuário atingir o nível de confiança necessário para ser
reconhecido a aplicação deve marcar o check box da grade de teste como verdadeiro;
Cenário alternativo
Após o passo 1 o botão “Test” é substituído pelo botão “Stop”.
2.1. O usuário deve clicar no botão “Stop”;
2.2. A aplicação deve cancelar o teste dos comandos de voz e retornar ao estado anterior.
102
APÊNDICE D. PROJETO DA DLL KINECTSCAN
D.1. Requisitos
Abaixo segue a lista com os requisitos funcionais relativos à KinectScan:
RF01 – Esta DLL deve reconhecer poses e falas através das entradas fornecidas
pelo sensor Kinect;
RF02 – Esta DLL deve abrir e mapear todos os arquivos de poses gravados
pela aplicação;
RF03 – Esta DLL deve possibilitar ao desenvolvedor criar vários vocabulários
de reconhecimento de fala (scanners) diferentes;
RF04 – Esta DLL deve possibilitar ao desenvolvedor ativar ou desativar
diferentes scanners de fala em diferentes momentos;
RF05 – Esta DLL deve disparar um evento quando reconhecer uma pose;
RF06 – Esta DLL deve disparar um evento quando reconhecer uma fala com o
grau de confiança maior do que o proposto pelo desenvolvedor.
Abaixo segue a lista com os requisitos não funcionais relativos à KinectScan:
RNF01 – Esta DLL deve ser desenvolvida de forma que seja possível interagir
com diferentes tipos de aplicação.
Abaixo segue a lista com as regras de negócio relativas à KinectScan:
RN01 – Esta DLL possui dependência do framework .NET 4.5.
103
D.2. Diagrama de classe
A Figura 44 ilustra um diagrama de classes resumido da DLL KinectScan, contendo
somente suas principais classes com seus respectivos atributos, propriedades, métodos e
eventos públicos(as).
Figura 44. Diagrama de Classe resumido da DLL KinectScan
104
APÊNDICE E. PROJETO DA KINECTSERVER
Este apêndice lista os requisitos funcionais, não funcionais, regras de negócios
relacionadas ao projeto da aplicação KinectServer.
E.1. Requisitos
Abaixo segue a lista com os requisitos funcionais da KinectServer:
RF01 – Esta aplicação deve se conectar com o sensor Kinect;
RF02 – Esta aplicação deve permitir ao usuário utilizar todos os eventos da
KinectScan;
RF03 – Esta aplicação deve permitir conexão de um cliente via sockets;
RF04 – Esta aplicação deve responder todas as requisições do cliente com um
evento.
Abaixo segue a lista com os requisitos não funcionais da KinectServer:
RNF01 – Esta aplicação deve utilizar a DLL KinectScan para comunicação
com o sensor Kinect.
Abaixo segue a lista com as regras de negócio da KinectServer:
RN01 – Esta aplicação suporta apenas um cliente;
105
APÊNDICE F. PROJETO DA DLL KINECTUNITY
Este apêndice lista os requisitos funcionais e não funcionais relacionados ao projeto da
DLL KinectUnity.
F.1. Requisitos
Abaixo segue a lista com os requisitos funcionais relativos à KinectUnity:
RF01 – Esta DLL deve implementar os eventos disparados pela DLL
KinectScan;
RF02 – Esta DLL deve interligar o reconhecimento de uma pose, gesto ou de
um comando de voz com uma entrada da ferramenta Unity.
Abaixo segue a lista com os requisitos não funcionais relativos à KinectUnity:
RNF01 – Esta DLL deve permitir criar uma integração entre o hardware Kinect
e o software Unity.
106
APÊNDICE G. DOCUMENTAÇÃO DO PROJETO
Para auxiliar os desenvolvedores que utilizarão esta biblioteca de funções todo o
projeto foi documentado no padrão XML oferecidos pela linguagem C#. Como resultado a
ferramenta para registro de entradas possui uma tile para abrir esta documentação com um
formato similar ao da documentação padrão do MSDN (MSDN, 2012). A Figura 45 ilustra a
primeira página de abertura da documentação, onde são exibidos os namespaces do projeto.
Figura 45. Documentação do projeto