Embed Size (px)
Citation preview
Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Pós-Graduação em Sistemas e Computação
KonectFramework de Desenvolvimento para
Aplicações do Microsoft Kinect
Rômulo de Oliveira Nunes
Natal-RN
Agosto de 2014
Rômulo de Oliveira Nunes
Konect: Framework de Desenvolvimento para
Aplicações do Microsoft Kinect
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação de Sistemas e Com-putação da Universidade Federal do RioGrande do Norte .
Orientador
Prof. Dr. André Maurício Cunha Campos
Universidade Federal do Rio Grande do Norte � UFRN
Departamento de Informática e Matemática Aplicada � DIMAp
Natal-RN
Agosto de 2014
Dissertação de Mestrado sob o título Konect: Framework de Desenvolvimento para Apli-
cações do Microsoft Kinect apresentada por Rômulo de Oliveira Nunes e aceita pelo
Programa de Pós-Graduação de Sistemas e Computação da Universidade Federal do Rio
Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo
especi�cada:
Prof. Dr. André Maurício Cunha CamposOrientador
Departamento de Informática e Matemática Aplicada - DIMAp
Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. Leonardo Cunha de MirandaDepartamento de Informática e Matemática Aplicada - DIMAp
Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. Selan Rodrigues dos SantosDepartamento de Informática e Matemática Aplicada - DIMAp
Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. André Luís de Medeiros SantosCentro de Informática
Universidade Federal de Pernambuco - UFPE
Natal-RN, 27 de Agosto de 2014.
Konect: Framework de Desenvolvimento paraAplicações do Microsoft Kinect
Autor: Rômulo de Oliveira Nunes
Orientador(a): Prof. Dr. André Maurício Cunha Campos
Resumo
O desenvolvimento para a plataforma Microsoft Kinect (ou simplesmente Kinect) vem
se intensi�cando à medida que o hardware apresenta-se constantemente como parte in-
tegrante de soluções para problemas importantes nas áreas de Computação Médica, Re-
alidade Virtual ou mesmo seu propósito básico inicial: a indústria de Entretenimento.
Com a sua popularização, as ferramentas básicas de desenvolvimento oferecidas pela Mi-
crosoft têm apresentado ao público geral complicações que poderiam ser evitadas, como
a correta con�guração e inicialização dos recursos oferecidos pelo hardware. Assim, este
trabalho tem como objetivo desenvolver e avaliar um framework especí�co para a plata-
forma Kinect, que auxilie usuários que estão começando a desenvolver aplicações para essa
plataforma, apresentando os principais componentes e como eles foram testados e avalia-
dos pelos usuários. Este trabalho também apresenta uma pesquisa realizada com os jogos
mais vendidos e melhores avaliados do Kinect, visando extrarir os principais componentes
neles presentes para formar a estrutura do framework.
Palavras-chave: Kinect, Framework, SDK, aplicações, jogos, componentes.
Konect: a development framework for KinectAplications
Author: Rômulo de Oliveira Nunes
Advisor: Prof. Dr. André Maurício Cunha Campos
Abstract
The development of aplications using the Microsoft Kinect plataform (or simply Kinect)
has been intensi�ed as the hardware is constantly shown as part of solutions to importante
problems on areas of Medical Computation, Virtual Reality or even for its basic initial
purpose: the Entertainment industry. With its popularization the basic development tools
o�ered by Microsoft presents to the general public complications that could be avoided,
such as the correct con�guration and initialization of the resources o�ered by the hardware.
Therefore, this work objectives to develop and evaluate a speci�c framework to the Kinect
plataform, to assist users who are beginning to develop applications for this platform,
showing the main components and how it was tested and evaluated by users. This work
also presents a research of the best-selling and reviews games for Kinet, to extract the
main components that were the basis for the framework.
Keywords : SDK, Kinect, framework, SDK, aplications, games, components.
Lista de �guras
1 Hardware Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2 0 pontos do corpo detectados pelo Kinect . . . . . . . . . . . . . . . . . p. 19
3 Jogo MasterMind. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
4 Jogo Soletrando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
5 Jogo Conectando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
6 Tipos de menus utilizados . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
7 Utilização da Câmera . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
8 Detecção de fala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
9 Esquematização da arquitetura do framework Konect . . . . . . . . . . p. 35
10 Mapeamento do esqueleto desenvolvido sem o framework . . . . . . . . p. 37
11 Mapeamento do esqueleto desenvolvido com o framework . . . . . . . . p. 37
12 Esquematização do diagrama de classes do framework Konect . . . . . p. 38
13 Fontes de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
14 Qualidade documentação Microsoft SDK . . . . . . . . . . . . . . . . . p. 47
15 Qualidade documentação do framework . . . . . . . . . . . . . . . . . . p. 48
16 Quantidade de versões . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
17 Di�culdade esperada x Di�culdade real - Grupo de controle . . . . . . . p. 50
18 Di�culdade esperada x Di�culdade real - Grupo de estudo . . . . . . . p. 50
19 Usaria novamente a ferramenta . . . . . . . . . . . . . . . . . . . . . . p. 51
20 Exemplo de Interface para a aplicação desenvolvida . . . . . . . . . . . p. 61
21 Tabela sobre fontes de pesquisa do questionário . . . . . . . . . . . . . p. 62
22 Selecionando um ponto do corpo . . . . . . . . . . . . . . . . . . . . . . p. 66
Lista de tabelas
1 Jogos mais vendidos para Kinect e seus componentes . . . . . . . . . . p. 30
2 Jogos com melhores avaliações para Kinect e seus componentes . . . . . p. 31
3 Divisão dos grupos e equipes para realização do experimento . . . . . . p. 40
4 Componentes implementados pelo grupo de controle . . . . . . . . . . . p. 44
5 Componentes implementados pelo grupo de estudo . . . . . . . . . . . p. 44
6 Tempo gasto para desenvolver a aplicação . . . . . . . . . . . . . . . . p. 44
7 Quantidade de linhas de código de cada aplicação . . . . . . . . . . . . p. 45
Lista de abreviaturas e siglas
UFRN � Universidade Federal do Rio Grande do Norte
DIMAp � Departamento de Informática e Matemática Aplicada
SDK � Software Development Kit
IDE � Integrated Development Enviroment
VGA � Video Graphics Array
Sumário
1 Introdução p. 11
1.1 Objetivo do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
2 Contextualização do Trabalho p. 13
2.1 Ferramentas de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . p. 13
2.1.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13
2.1.2 SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
2.1.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
2.1.4 IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
2.1.5 Biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
2.2 Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2.3 Microsoft Kinect SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.4 Outros Frameworks e Ferramentas Existentes . . . . . . . . . . . . . . p. 20
2.4.1 Open Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2.4.2 OpenNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
2.4.3 GEMINI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.4.4 Kiosk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.4.5 Multi-Kinect Framework . . . . . . . . . . . . . . . . . . . . . . p. 23
2.4.6 DepthJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.4.7 Outras Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
3 Framework Konect p. 25
3.1 Metodologia de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . p. 25
3.1.1 Descrição das aplicações desenvolvidas . . . . . . . . . . . . . . p. 25
3.1.1.1 Mastermind . . . . . . . . . . . . . . . . . . . . . . . . p. 25
3.1.1.2 Soletrando . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
3.1.1.3 Conectando . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3.1.1.4 Características extraídas . . . . . . . . . . . . . . . . . p. 28
3.1.2 Levantamento de componentes em aplicações do Kinect . . . . . p. 28
3.1.3 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.1.4 Arquitetura do Framework . . . . . . . . . . . . . . . . . . . . . p. 35
4 Avaliação do Framework p. 39
4.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
5 Resultados p. 43
5.1 Análise do código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
5.2 Análise do questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
6 Considerações �nais p. 53
7 Referências p. 55
Apêndice A -- Especi�cação da aplicação p. 59
A.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
A.2 Funcionalidades do sistema . . . . . . . . . . . . . . . . . . . . . . . . . p. 60
Apêndice B -- Questionário p. 62
Apêndice C -- Documentação Konect p. 64
C.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
C.2 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
C.3 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
C.3.1 Mapeamento do esqueleto . . . . . . . . . . . . . . . . . . . . . p. 65
C.3.2 Câmera RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
C.3.3 Criação de menus(Manipulação de botões) . . . . . . . . . . . . p. 67
C.3.4 Poses pré-de�nidas . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
C.3.5 Drag and drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69
C.3.6 Detecção da fala . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70
11
1 Introdução
O Kinect é um sensor de movimentos desenvolvido pela Microsoft para o Xbox 360 e
Xbox One, junto com a empresa Prime Sense. Foi lançado nos EUA em 4 de novembro de
2010 e chegou ao Brasil em 18 de novembro do mesmo ano, inovando com sua tecnologia
capaz de permitir aos jogadores interagir com os jogos eletrônicos sem a necessidade de
ter em mãos um controle/joystick. Desde o seu lançamento mostrou-se um sucesso de
vendas entre o público gamer, sendo certi�cado pelo Guinness como o periférico de jogos
eletrônico com a venda mais rápida de todos os tempos (GUINNES WORLD RECORDS,
2011). O recorde se baseou nos primeiros 60 dias de venda do aparelho, quando foram
vendidas oito milhões de unidades, uma média de 133.333 unidades por dia.
Além disso, a aplicabilidade da nova interface criada pela Microsoft se estendeu a
outras aplicações de campos distintos do Entretenimento Digital, como Visão Compu-
tacional e Computação Médica, trazendo inovação a alguns métodos de Fisioterapia,
como por exemplo, na utilização do Kinect como ferramenta no atendimento �siotera-
pêutico de pacientes neurológicos(Rocha, Defavari, Brandão, 2012). A própria Microsoft
investe em pesquisa Médica utilizando o Kinect. Sua ala de Pesquisa, a Microsoft Rese-
arch (http://research.microsoft.com/), tem divulgado diversos trabalhos importantes que
utilizam o dispositivo como parte integrante de sistemas médicos (INNER EYE, 2013)
(CRIMINISI, 2013) (KONTSCHIEDER, 2013) (GLOCKER, 2013) (YE, 2013) (ZIKIC,
GLOCKER, CRIMINISI, 2013).
Existem diversas di�culdades em se desenvolver para o Kinect, a maioria delas ligada
à fase inicial, na qual é necessário aprender a utilizar de maneira adequada os recursos
disponíveis no SDK. Além de se tratar de algo relativamente novo, o SDK do Kinect
passou por constantes mudanças, di�cultando a busca por documentações, trabalhos e
exemplos compatíveis ao SDK atual.
12
Já existem padrões de�nidos para o desenvolvimento de aplicações para Desktop e
web, por isso é comum encontrar frameworks seguindo esses padrões de desenvolvimento.
Leva-se um tempo para consolidar esses padrões em novas interfaces, como o Kinect. O
SDK foi criado com um propósito genérico, tentando atender aos diversos tipos de apli-
cações que venham a ser criadas usando o corpo como interface. Mesmo assim, muitas
aplicações possuem padrões repetidos de interação, como por exemplo um menu, reco-
nhecimento de esqueleto, reconhecimento de gestos, etc. A maior parte desses padrões
repetidos são derivados da interação com o Kinect, e são formados por códigos grandes e
com uma alta curva de aprendizado, como será apresentado nos resultados presentes no
Capítulo 5. O presente trabalho visa, portanto, reduzir este problema desenvolvendo um
framework que auxilie iniciantes em aplicações usando Kinect.
A primeira parte deste projeto consistiu no desenvolvimento do framework. Para isso,
adotou-se como estratégia a implementação de três jogos que utilizam os elementos básicos
de qualquer motor para desenvolvimento em Kinect (carregamento de imagens, construção
e mapeamento de esqueleto, frame bu�er de vídeo, drag and drop, etc). Paralelamente, foi
feita uma análise de jogos populares, para que fosse possível estabelecer quais os elementos
necessários do framework e como eles seriam introduzidos e instanciados por um código
cliente. Por �m, o próximo passo foi avaliar o framework através de experimentos com
usuários, tanto com aqueles que possuem experiência em programação para a plataforma,
quanto com aqueles que nunca programaram para o Kinect.
1.1 Objetivo do trabalho
O trabalho proposto tem como objetivo desenvolver um framework para auxiliar na
criação de aplicações para o Kinect, permitindo que o programador desenvolva uma apli-
cação Kinect sem necessariamente conhecer o funcionamento do SDK, preocupando-se
apenas em programar a sua aplicação.
O framework é direcionado a programadores que não possuem conhecimento em de-
senvolvimento para Kinect, que desejam criar sua aplicação de maneira rápida e prática,
sem necessitar aprender todos os detalhes da tecnologia utilizada.
13
2 Contextualização do Trabalho
Este capítulo está dividido em três seções, contendo o embasamento teórico para o
desenvolvimento desse trabalho.
A primeira seção apresenta o conceito de framework, mostrando o que se espera do
produto desenvolvido. Apresenta também os conceitos de SDK, IDE, API e biblioteca,
por vezes utilizados erroneamente como sinônimos, mesmo sendo conceitos diferentes.
A seção seguinte apresenta o dispositivo de controle gestual utilizado para desenvolver
o framework Konect, no caso o Kinect. Por �m, é apresentado o SDK o�cial da Microsoft
para o Kinect e alguns outros frameworks e ferramentas existentes para o desenvolvimento
de aplicações usando o Kinect.
2.1 Ferramentas de desenvolvimento
Nesta seção serão apresentados os conceitos de algumas ferramentas que auxiliam no
processo de desenvolvimento de um software. Serão apresentado os conceitos de framework,
SDK, API, IDE e bibliotecas. Esses conceitos serão apresentados para situar a ferramenta
desenvolvida dentro do contexto das várias ferramentas existentes.
2.1.1 Framework
Geralmente, aplicações do mesmo domínio de problema possuem muitas característi-
cas em comum. Essas características se referem principalmente às funcionalidades e como
as mesmas são implementadas. Frameworks são criados para trabalhar com esses tipos de
aplicações. Seu objetivo �ca claro em suas diversas de�nições presentes na literatura.
Para Johnson(1991) e Gamma et al (1995), um framework é um conjunto de objetos
que colaboram com um objetivo de atender a um conjunto de responsabilidades para uma
aplicação especí�ca ou um domínio de aplicação.
14
Segundo Buschmann et al. (1996), Pree (1995) e Pinto (2000) um framework é de�nido
como um software parcialmente completo projetado para ser instanciado. O framework
de�ne portanto uma arquitetura para uma família de subsistemas e oferece os construtores
básicos para criá-los.
Para Mann (2005), os framework podem ser considerados esqueletos de componentes
de softwares já implementados, que auxiliam na implementação de funcionalidades espe-
cí�cas de uma arquitetura de um domínio de aplicação em particular. Esses esqueletos
são soluções genéricas para um problema comum enfrentado no desenvolvimento de um
determinado tipo de aplicação (Dantas, 2008).
Todas as de�nições citadas acima partem do mesmo princípio, o de um framework ser
uma ferramenta que captura a funcionalidade comum a várias aplicações da mesma fa-
mília, criando um esqueleto padrão para facilitar o desenvolvimento de aplicações futuras
para o mesmo domínio do problema e seguindo essas de�nições o framework proposto foi
criado.
2.1.2 SDK
SDK (Software Development Kit) é um conjunto de ferramentas que pode ser utili-
zado para desenvolver aplicações de software que tenham por objetivo uma plataforma
especí�ca. Um SDK pode incluir bibliotecas, documentações e exemplos de códigos que
podem ajudar o programador a desenvolver uma aplicação. (Lucena,2012).
De acordo com Carvalho e Vera (2005), um SDK deve ser estruturado respeitando
alguns requisitos:
• Modularidade: O acoplamento entre os componentes oferecidos por um SDK deve
ser pequeno, para que o programador tenha liberdade para utilizar somente os com-
ponentes que ele necessite.
• Reuso: Os componentes de um SDK devem ser extensíveis, para que o programador
possa, com alguma adaptação, reutilizá-los, de acordo com as necessidade especí�cas
da sua aplicação. Além disto, devem poder ser utilizados em diversos contextos e
realizar diferentes tarefas.
• Interface com múltiplas linguagens de programação: É desejável que um SDK dispo-
nibilize APIs para mais de uma linguagem de programação. Para isto, o SDK deve
15
ser pensando como uma especi�cação genérica a partir da qual as APIs devem ser
implementadas. Isto garante a compatibilidade entre as implementações, ao mesmo
tempo que mantém a independência.
Para o desenvolvimento do framework Konect, foi utilizado as funcionalidades dispo-
níveis no SDK Kinect for Windows da Microsoft.
2.1.3 API
No mundo virtual, os programas, ou softwares, fazem solicitações diversas entre si.
Para tanto, é necessário que haja algo que estabeleça esta comunicação. Esse é, portanto,
o papel da API (Application Programming Interface)(Lucena, 2012).
Uma API é um conjunto de de�nições que permitem acesso às funcionalidades e
serviços de um determinado software ou biblioteca. Este conjunto pode ser disponibilizado
como funções de uso comum (ex. funções para desenhar janelas e ícones), permitindo que
programadores não precisem programar tudo do início (Carvalho e Vera, 2005).
O SDK Kinect for Windows da Microsoft, provê um conjunto de ferramentas e APIs,
que permitem o desenvolvimento de aplicações para o Kinect. Ele disponibiliza APIs para
detecção do esqueleto, captura de áudio, etc.
2.1.4 IDE
IDE (Integrated Development Environments), ou em português "Ambiente de Desen-
volvimento Integrado", é uma de�nição das aplicações desenvolvidas para criar facilidades
na construção de software, que tem como principal objetivo maximizar a produtividade
do programador. As IDEs devem oferecer alguns recursos como escrever e editar códigos,
highlight para destacar sintaxe, além de automatizar tarefas repetitivas (Nourie, 2005).
Elas são componentes essenciais para qualquer sistema de desenvolvimento de software,
economizando tempo e dinheiro no ciclo de desenvolvimento (Rehman e Paul, 2002).
Segundo (Myatt, 2007), ambientes de desenvolvimento integrados, literalmente, pro-
vém um ambiente completo para o trabalho de um desenvolvedor, oferecem diversas fer-
ramentas e um caminho coerente a serviços que são necessários para o desenvolvimento.
Alguns benefícios técnicos das IDEs são:
16
• Interface grá�ca.
• Integração com compilador.
• Podem trabalhar com repositório de código.
• Código agrupado e arquivos de con�guração em conceito de projeto.
• Analisar e carregar código de teste.
• Integração com frameworks de teste reutilizáveis.
• Padrão no processo desenvolvimento de software.
O framework Konect foi desenvolvido para ser utilizado com a IDE Microsoft Visual
Studio, versão superior a 2010, pois o framework faz uso do SDK da Microsoft, que foi
desenvolvido para ser utilizado nessa IDE.
2.1.5 Biblioteca
Bibliotecas são compostas por classes separadas que podem ser usadas independente-
mente umas das outras: o usuário instancia as classes e chama os métodos delas.(Ferreira,
2005).
Nas bibliotecas de classes, cada classe independe das outras e a colaboração entre
estas é determinada pela própria aplicação, por outro lado nos frameworks as colaborações
entre as classes que os compõem já são pré-determinadas (Silva,2007), assim, o framework
geralmente faz o papel de programa principal, coordenando e sequenciando as atividades
da aplicação. Essa inversão de controle dá força ao framework para servir de esqueletos
extensíveis (Maldonado, Braga, Germano e Masiero, 2009).
O Konect é composto por conjunto de classes que implementam as funções que o usuá-
rio utiliza para desenvolver a aplicação e uma classe que de�ne o seu �uxo, disponibilizando
a estrutura de um programa, para que o programador possa utilizar as funcionalidades
desenvolvidas de maneira adequada. Sendo assim, a presença desta estrutura contendo o
esqueleto da aplicação, faz com que o Konect seja um framework e não uma biblioteca.
17
2.2 Kinect
O aparelho Kinect é composto basicamente por quatro partes: uma câmera de vídeo
VGA , sensores de profundidade 3D, microfone multi-vetorial e uma base Motorizada.
Figura 1: Hardware Kinect - Fonte: Autor Desconhecido
A câmera de vídeo é responsável pelo reconhecimento facial e pela detecção de outras
características, como as cores dos objetos. Essa câmera possui uma detecção de vídeo
em RGB, combinando vermelho, verde e azul para formar as imagens captadas em uma
resolução de 640x480 a 30 quadros por segundos, apresentando para o usuário a imagem
que o Kinect está captando de maneira real.
Os sensores de profundidade 3D são responsáveis por projetar os raios infravermelhos.
Eles trabalham com um sensor CMOS, responsável por converter a luz em um padrão de
cargas elétricas que se traduz em dados digitais, funcionamento semelhante ao das câme-
ras digitais. Juntos, esses sensores são capazes de mapear o ambiente e os objetos em 3D,
distinguindo a distância entre eles, o volume e a movimentação de cada um deles sem que
seja visível a olho nu.
O Microfone multi-vetorial consiste em uma série de quatro microfones capazes de
isolar as vozes dos usuários dos outros sons presentes no ambiente. Eles também são
responsáveis por captar comandos de voz de usuários a poucos metros de distância do
aparelho.
A base motorizada é responsável por movimentar a câmera e os sensores 3D do apa-
18
relho verticalmente, visando ajustar o mapeamento da cena com a altura em que o sensor
Kinect se encontra.
O Kinect não é composto apenas por um conjunto de hardwares, ele também possui
uma camada de software responsável por coordenar as ações do hardware durante o uso do
aparelho. Logo na inicialização, o Kinect mapeia o ambiente e ajusta automaticamente as
suas con�gurações de acordo com o ambiente em que o sensor esteja inserido. Em seguida,
ele procura os pontos do corpo de cada jogador para formar uma réplica digital em 3D
necessária para a interação do usuário com a aplicação, mapeando inclusive os detalhes
faciais. O software foi desenvolvido para se portar de maneira evolutiva, aprendendo a
cada interação, ou seja, quando mais o usuário utiliza o Kinect, mais preciso ele �ca.
2.3 Microsoft Kinect SDK
O Microsoft Kinect SDK 2.0 é a mais nova versão do kit de desenvolvimento de soft-
ware. O SDK oferece uma gama de novas ferramentas, amostras e recursos para ajudar
os desenvolvedores a simpli�car o desenvolvimento de aplicativos que respondam à voz
humana e gestos. A versão 2.0 inclui suporte para vídeo em 1080p, melhorias na detecção
do esqueleto e nova tecnologia de infravermelho.
O Microsoft Kinect SDK possibilita grande entendimento de características humanas,
inclusive delimitação do rosto, esqueleto e reconhecimento gestual. Trabalha também com
reconhecimento de áudio e reconstrução de dados escaneados pelo aparelho em modelos
tridimensionais através da nova ferramenta Kinect Fusion, integrada ao SDK. Expõe uma
ordem de dados sensoriais e fornece ferramentas para otimizar o uso desses dados: os
desenvolvedores podem acessar dados de profundidade extendida e do sensor de radiação
infravermelha, além de bu�ers de cores captadas pela câmera.
O SDK Kinect for Windows é programado para suportar até 4 sensores em um com-
putador e pode ser usado em qualquer máquina virtual cujo sistema operacional execute o
Windows 7 ou 8. O SDK da suporte a 6 jogadores diferentes, sendo apenas 2 jogadores por
vez, mapeando os 20 pontos do seu corpo (como mostrado na Figura 2) e reconhecendo
rapidamente a posição de cada jogador. O SDK foi desenvolvido para ser utilizado nas
19
seguintes linguagens de programação: C++, C #, ou Visual Basic.
Figura 2: 0 pontos do corpo detectados pelo Kinect - Fonte: http://www.100loop.com/
destaque/comeando-a-usar-o-sdk-do-kinect/
Todos os recursos disponíveis no SDK Kinect for Windows possuem um custo asso-
ciado, seja na limitação de uso apenas para Windows ou na di�culdade de se utilizar.
Por isso, existem diversas ferramentas de desenvolvimento para Kinect, que trabalham
sob o SDK ou de forma independente. Algumas dessas ferramentas serão apresentadas na
próxima seção.
20
2.4 Outros Frameworks e Ferramentas Existentes
Nessa seção serão apresentados alguns frameworks existentes para Kinect, mostrando
as suas funcionalidades. Também serão apresentadas outros tipos de ferramentas, desen-
volvidas para trabalhar com o Kinect. Para ilustrar os diferentes públicos e objetivos que
cada uma dessas ferramentas possuem.
2.4.1 Open Kinect
OpenKinect é ferramenta desenvolvida por uma comunidade aberta de pessoas in-
teressadas em fazer uso do hardware Xbox Kinect em computadores pessoais e outros
dispositivos. Inclui os códigos necessários para ativar, inicializar e comunicar dados com
o hardware do Kinect, drivers e uma plataforma API que funcionam em Windows, Linux
e OS X. A API terá ligações e extensões para as seguintes linguagens/plataformas:
• C
• C ++
• .NET (C sharp/VB.NET)
• Java ( JNA and JNI)
• Javascript
• Python
• C Synchronous Interface
• Common Lisp
Sua biblioteca OpenKinect Analysis tem comunicação com o API do OpenKinect e
analisa a informação crua, transformando-a em abstrações mais úteis. A comunidade tem
contribuído em ferramentas e códigos para a análise dos seguintes elementos:
• Localizador de mão
21
• Localizador corporal
• Processamento de profundidade
• Som 3D
• Cancelamento de áudio
• Geração de nuvens de pontos
• Reconstrução em 3D
• Aceleração GPU
Claramente esse é um grande esforço e requer disciplina e coordenação com especialis-
tas acadêmicos, desenvolvedores, testadores e usuários, havendo a necessidade de muitos
meses ou anos para completar esse trabalho. Ainda assim, tem se tornado bastante popu-
lar, mostrando-se como uma das alternativas favoritas para os desenvolvedores de Kinect
que não querem restringir-se ao desenvolvimento para plataformas Windows.
2.4.2 OpenNI
OpenNI ou Open Natural Interaction (Interação Natural Aberta) é uma organização
industrial não lucrativa focada em certi�car e melhorar a interoperabilidade de dispo-
sitivos de interação natural, aplicativos que usam esses dispositivos e mediadores que
facilitam o acesso e uso de tais dispositivos.
A organização foi criada em Novembro de 2010, tendo seu website publicado em 08 de
dezembro. Um dos principais membros é a PrimeSense, a companhia por trás da tecnologia
usada no Kinect, o dispositivo de percepção motora da Microsoft para o console Xbox 360.
Em dezembro de 2010, a PrimeSene, que projetou o sensor de profundidade no qual
o Kinect é baseado, lançou seus próprios drivers de fonte aberta junto com um mediador
de captação de movimento chamado NITE.
Seu software está sendo usado atualmente numa gama de projetos de fonte aberta
dentre academia e a comunidade entusiasta. Recentemente, companhias de software ten-
22
taram expandir a in�uência do OpenNI, fazendo o trabalho com o framework, assim como
a integração de tecnologia, muito mais simples (FAIRHEAD, 2013).
A framework do OpenNI fornece uma variedade de APIs de fonte aberta. Essas APIs
deverão se tornar um padrão para aplicativos que acessem dispositivos de interação na-
tural (VILLAROMAN, ROWE, SWAN, 2011). As APIs fornecem suporte para:
• Reconhecimento de voz e comandos de voz
• Gestos manuais
• Captação de movimento corporal
2.4.3 GEMINI
GeMiNi é um framework que permite que qualquer periférico de computador com-
patível possa funcionar como entrada para um jogo. Ele atua como uma abstração entre
os eventos do dispositivo e controles padrões do jogo. Isso permite que os usuários ex-
perimentem novos métodos de interação que não foram originalmente planejados pelos
desenvolvedores do jogo. Por exemplo: um jogo de tiro em primeira pessoa, desenvolvido
para ser jogado com mouse e teclado, pode ser jogado usando comandos de voz e movi-
mentos do corpo para realizar ações do jogo (TEOFILO, NOGUEIRA e SILVA, 2013).
GeMiNi utiliza o Microsoft Kinect SDK para realizar o mapeamento dos pontos do
corpo e gerar um conjunto de 20 gestos, como por exemplo, o movimento de soco. To-
dos os gestos foram implementados usando os pontos do corpo, através de funções que
calculavam a distância e se um ponto estava acima, abaixo, na frente ou atrás de outro.
Também faz uso do sistema de reconhecimento de fala do SDK da Microsoft.
2.4.4 Kiosk
É um web framework desenvolvido com o objetivo de criar apresentações interativas
com o uso do Kinect. A ideia do Kiosk é criar uma plataforma para a implantação de
23
apresentações em formato pré-de�nido para exibições públicas. A interação com a apre-
sentação é através de gestos, que permitem aos usuários navegar pelo conteúdo de maneira
não-linear, resultando em uma melhor experiência(BOHAK,2013).
2.4.5 Multi-Kinect Framework
Um único Kinect suporta apenas um número limitado de usuários em uma determi-
nada área. Esse framework tem como objetivo fazer com que uma aplicação possa suportar
o uso de vários Kinects, fazendo com que a mesma seja utilizada por uma grande quan-
tidade de usuários em um grande espaço. Esse framework faz uso das funcionalidades
presentes no OpenNI e foi desenvolvido para ser utilizado em Python, C ++ e C# .
2.4.6 DepthJS
Framework que permite a interação de aplicações web com o Kinect, realizando um
mapeamento da API do SDK da Microsoft para JavaScript. Sua ideia é permitir que pro-
gramadores especializados em JavaScript, possam desenvolver suas aplicações para Kinect
sem precisar utilizar uma outra linguagem de programação.
2.4.7 Outras Ferramentas
Existem algumas interfaces criadas para facilitar o manuseio das classes e métodos
providas pelo SDK o�cial da Microsoft. Enquanto algumas funcionam apenas como wrap-
pers para outras Linguagens (como o KinectJLib para Java e o DepthJS para JavaScript),
outras como o CLNUI Java vai além, provendo métodos que abstraem a inicialização e o
funcionamento da câmera, sendo possível obter e manipular facilmente os dados de cor e
profundidade obtidos através do dispositivo.
Outro tipo de ferramenta são os plug-ins, como o Jnect, plug-in do Eclipse, que per-
mite que o usuário navegue na IDE fazendo uso do Kinect. Através de gestos e comandos
de voz, e possível realizar operações na ferramenta.
24
Também é muito comum encontrar bibliotecas que possibilitam o uso do Kinect para
desenvolver aplicações, como O KinectJS, uma biblioteca feita com JavaScript e HTML5,
que permite interação de forma natural para aplicações desktop, web e móveis. Ela permite
desenhar as imagens e formas, adicionar eventos, mover, escalar e rotacionar um objeto
de maneira independente.
Cada framework e ferramenta apresentada tem o seu proposito especí�co, ou seja, é
direcionado a algum domínio de aplicação. Os mais famosos, OpenNi e OpenKinect são
mais usados por programadores que desejam utilizar o Kinect, sem se limitar ao Windows
e as linguagens suportadas pelo SDK da Microsoft. Já o GeMiNi é voltado para o público
que deseja jogar um game, fazendo uso do Kinect. O Kiosk é voltado para criação de
apresentações. Assim como eles, o Konect tem o seu público alvo, e suas funcionalida-
des foram desenvolvidas focando esse grupo. Todo o seu funcionamento foi desenvolvido
pensando em atender pessoas que nunca programaram para Kinect e que desejam criar
uma aplicação sem aprender os detalhes da tecnologia utilizada, pois é comum que quem
comece a programar para Kinect busque utilizar o SDK da Microsoft, se deparando com
as di�culdades apresentadas neste trabalho.
25
3 Framework Konect
Neste capítulo será apresentado o framework Konect e como foi a sua concepção, ou
seja, como o mesmo foi gerado e quais os componentes que o mesmo possui. Por �m,
será apresentada a arquitetura do framework, detalhando-a através diagrama de classes
do projeto desenvolvido.
3.1 Metodologia de desenvolvimento
Para dar início ao desenvolvimento do framework proposto foi necessária a implemen-
tação de três diferentes aplicações e a análise de aplicações (jogos) populares existentes
para Kinect, visando a extração de fatores (componentes, métodos, objetos, classes, tipos)
comuns a elas para compor a base do framework. Assim, três diferentes mini games foram
desenvolvidos, são eles: Mastermind, Soletrando e Conectando.
3.1.1 Descrição das aplicações desenvolvidas
Nesta seção será apresentado o funcionamento das três aplicações desenvolvidas que
deram base à construção do framework Konect.
3.1.1.1 Mastermind
Mastermind é um jogo de tabuleiro, cujo objetivo é a descoberta de uma senha atra-
vés de previsões e de respostas obtidas em tentativas anteriores. Inicialmente, o jogo foi
lançado para ser jogado por duas pessoas, porém já se encontra na internet aplicativos que
permitem ao usuário jogar contra o computador, tentando descobrir uma senha gerada
26
randomicamente.
Figura 3: Jogo MasterMind.
O jogo é composto por um conjunto de pinos coloridos (para a formação da senha e
dos palpites), um conjunto de pinos menores (brancos e pretos) e um conjunto de �leiras
(equivalente ao número de tentativas que o usuário tem para descobrir a senha escondida).
Para que o jogo comece, é necessário que uma senha, formada pelos pinos coloridos,
seja determinada e escondida (seja pelo computador ou por outro jogador). A cada palpite
de senha, o usuário recebe como resposta uma quantidade de pinos brancos e pretos para
que o mesmo possa veri�car a qualidade da sua previsão e assim, ir melhorando a cada
tentativa o seu palpite. Para cada cor colocada exatamente no canto correto, o jogador
recebe um pino da cor branca. Os pinos pretos são distribuídos quando uma cor que o
usuário colocou no seu palpite está na senha, porém na posição errada.
A vitória ao jogador é concedida quando o mesmo obtém uma quantidade de pinos
brancos igual ao tamanho da senha. Caso o número de tentativas (�leiras) estoure, o jo-
gador perde a partida, não conseguindo descobrir qual senha foi inicialmente escondida.
3.1.1.2 Soletrando
O jogo Soletrando tem como objetivo fazer com que o usuário escreva corretamente
cada palavra solicitada. Quando o jogo começa, o usuário se depara com uma imagem,
um teclado e um conjunto de botões para realizar determinadas ações. O jogo é composto
de dez imagens para que o usuário possa veri�car e aprimorar o seu conhecimento sobre
27
as palavras. O mesmo também dispõe de três botões, são eles: veri�car resposta (veri�ca
se a palavra digitada pelo usuário está correta), pular (possibilita que o usuário ignore
determinada imagem, saltando para a próxima) e limpar (permite que o usuário limpe a
palavra digitada caso o mesmo ache necessário, possibilitando corrigir erros).
Figura 4: Jogo Soletrando.
Para determinar se o jogador conseguiu atingir o objetivo foi estipulado uma nota. O
mesmo começa com pontuação nula, para cada acerto o usuário ganha um ponto adicio-
nal e para cada erro o mesmo perde meio ponto. Ao �m do jogo, o usuário é declarado
vencedor se o mesmo obtiver sete pontos ou mais.
3.1.1.3 Conectando
O jogo Conectando tem como objetivo fazer com que o usuário conecte palavras já
escritas com a sua imagem correspondente. Quando o jogo começa, o usuário se depara
com uma tela contendo dez imagens e dez nomes (correspondentes a cada imagem e dis-
postos de maneira aleatória). Abaixo de cada imagem existe um espaço azul, destinado a
ser preenchido com a palavra correta. O usuário utiliza apenas a mão direita para mover
cada palavra para o seu respectivo local, associando-a com a sua imagem correspondente.
Ganha o jogo aquele usuário que conseguir conectar todas as palavras de maneira correta.
28
Figura 5: Jogo Conectando.
3.1.1.4 Características extraídas
Os três jogos apresentados nesta seção possuem características próprias e comuns que
foram extraídas para dar origem ao framework. São elas:
• Todas as aplicações realizam detecção do esqueleto e mapeamento dos pontos.
• Duas das aplicações (Mastermind e Soletrando) utilizam detecção de fala para sele-
cionar algumas opções.
• Todas as aplicações possuem seleção de opções através do uso de pontos do corpo.
• Todas as aplicações possuem uma câmera.
• Em todas as aplicações foi necessário habilitar os sensores de profundidade do Ki-
nect.
• Em todas as aplicações foi necessário vincular objetos a partes do corpo e movimentá-
los na tela de acordo com o movimento do jogador.
• Apenas o jogo Conectando faz uso do Drag and Drop.
• Apenas o jogo Conectando utiliza gestos simples (poses) para realizar ações.
3.1.2 Levantamento de componentes em aplicações do Kinect
Além da criação das três aplicações citadas anteriormente, foi feito um levantamento
dos principais componentes presentes em jogos populares para o Kinect. Foi analisado os
29
principais componentes da lista de jogos mais vendidos e melhores avaliados para Kinect,
presente no site www.xbox.com, em Março de 2014.
Nesse levantamento, foi veri�cado os seguintes itens:
• Menu: Foi analisado o tipo de menu presente em cada uma das aplicações. A maioria
das aplicações para o Kinect utilizam 4 tipos de menu. Para facilitar a leitura,
estamos de�nindo uma nomenclatura para os diferentes tipos, são eles:
� Hover Button: Esse menu, consiste em o jogador manter a mão parada sobre
a opção desejada por um determinado tempo.
� Book Button: Esse menu consiste em o jogador colocar a mão sobre uma opção
desejada e realizar um movimento semelhante ao de folhear um livro.
� Touch Button: Esse menu consiste em o jogador posicionar a mão sobre uma
determinada opção e realizar o movimento de toque, projetando a mão para
frente.
� Voice Selection: Esse menu consiste em o jogador fazer uso da voz para acessar
uma opção desejada, utilizando os comandos de fala cadastrados pela aplicação.
• Detecção do esqueleto: Foi levantado se a aplicação realizava a detecção do esqueleto
do jogador.
• Detecção de poses: Foi analisado se a aplicação fazia uso de gestos simples, conhe-
cidos como poses, (formado apenas com o uso dos pontos do corpo) para interação
do usuário com o jogo.
• Câmera: Foi analisado se era mostrado a imagem do jogador durante a aplicação, seja
ela apenas de maneira ilustrativa, possibilitando que o usuário se veja realizando os
movimentos do jogo, ou de maneira a inserir o jogador dentro da aplicação, fazendo
com que o mesmo faça parte do jogo, e não apenas controle um avatar.
• Detecção de fala: Foi analisado se as aplicações faziam uso de comandos de voz para
realizar ações no jogo.
• Drag and Drop: Foi levantado se essa interação estava presente nas aplicações ana-
lisadas;
30
A Tabela 1 apresenta o resultado do levantamento feito com os 10 jogos mais vendidos
para Kinect.
Tabela 1: Jogos mais vendidos para Kinect e seus componentes
A Tabela 2 apresenta o resultado do levantamento feito com os 10 jogos que tiveram
as melhores avaliações. Nela estão presentes apenas 7 dos 10 jogos, pois 3 deles estavam
na lista dos mais vendidos, apresentados na Tabela 1.
31
Tabela 2: Jogos com melhores avaliações para Kinect e seus componentes
Através dos dados obtidos no levantamento apresentado nas Tabelas 1 e 2, é possível
retirar informações importantes para de�nição dos componentes presentes no framework.
Como por exemplo:
• Criação de menus : O tipo de menu mais utilizado foi o "Tipo 1", como pode ser
visto na Figura 6. Por isso, o mesmo foi o escolhido para fazer parte do framework.
• Detecção do esqueleto: É necessário realizar esse processo sempre que a aplicação
deseja que o usuário utilize o corpo para realizar ações no jogo. Algumas aplicações,
como Halo e Mass Efect 3, que são jogadas com o controle, fazem uso do Kinect
como um auxiliar durante jogo, utilizando o comando de voz para realizar algumas
operações de maneira ágil. Apenas nesse tipo de aplicação não é necessário realizar
a detecção do esqueleto.
• Detecção de poses: Toda aplicação que utiliza o corpo do jogador faz uso de poses
para acessar informações e realizar operações.
• Câmera: Esse componente foi utilizado na maioria dos jogos, como mostrado na
32
Figura 6: Tipos de menus utilizados
Figura 7. Em todos os casos, a câmera foi utilizada apenas de maneira ilustrativa,
presente na cena com o intuito de fazer com que o usuário se veja jogando o jogo
enquanto controla o seu avatar. Sendo assim, a câmera presente no framework terá
esse mesmo papel, apenas exibindo a imagem que o Kinect está captando ao usuário.
Figura 7: Utilização da Câmera
• Detecção da Fala: Esse componente foi utilizado em algumas das aplicações analisa-
das. Mesmo não sendo utilizado na maioria dos jogos, como pode-se ver na Figura
8, constitui em um importante componente das aplicações para Kinect.
33
Figura 8: Detecção de fala
• Drag and Drop: Esse gesto estava presente em alguma das aplicações analisadas. É
comum encontrar esse tipo de gesto em aplicações para o Kinect, por isso, o mesmo
está presente no framework.
3.1.3 Componentes
Após a criação das aplicações e o levantamento dos componentes em jogos conheci-
dos, foi de�nido um conjunto de componentes quer serviram como base na criação do
framework. Esses componentes estão presentes em todas ou em alguma dessas aplicações,
e consistem em importantes mecanismos para se desenvolver uma aplicação para o Kinect.
Os componentes implementados foram:
• Detecção do esqueleto e mapeamento dos pontos do corpo: Essa funcionalidade é a
base da maioria das aplicações desenvolvidas para o Kinect e foi implementada para
as três aplicações. Ela consiste em reconhecer que existe alguém utilizando o Kinect
e detectar o esqueleto da mesma, possibilitando o mapeamento de 20 diferentes pon-
tos do corpo humano, como por exemplo, a cabeça, as mãos, os pés, entre outros,
como mostrado na Figura 2. Esses pontos detectados são usados para possibilitar a
interação do usuário com a aplicação.
• Uso da câmera RGB do Kinect: Essa funcionalidade foi implementada nas três apli-
cações e consiste em uma funcionalidade bastante presente em aplicações Kinect. A
34
câmera RGB mostra a imagem captada pelo Kinect da maneira real, possibilitando
que o usuário se situe na cena ou que o mesmo faça parte dela.
• Criação de Menus e Manipulação de botões: Essa é uma funcionalidade bastante
importante e foi implementada em todas as três aplicações. Ela permite que o usuá-
rio interaja com a aplicação através de um conjunto de operações sobre um botão.
Ela foi implementada para que o usuário consiga adicionar e veri�car se um botão
está sendo pressionado ou não, para poder ativar operações na aplicação. O tipo
de menu presente no framework será o "Hover Button", pois o mesmo é o mais
presente nas aplicações analisadas.
• Funções de movimentação: Essa funcionalidade foi implementada nas três aplicações
e consiste em uma funcionalidade essencial para interação com a aplicação. Ela é
responsável por vincular um objeto a uma parte do corpo, permitindo que o mesmo
se movimente na cena de acordo com a movimentação do usuário. Quando o esque-
leto é mapeado, o usuário só consegue visualizá-lo na aplicação se o mesmo tiver
objetos vinculados a algum ponto do corpo detectado, permitindo que o usuário
realize as ações necessárias para utilizar a aplicação.
• Detecção de fala: Essa funcionalidade esteve presente em duas das aplicações imple-
mentadas, pois é comum encontrá-la em jogos populares para Kinect e constitui uma
funcionalidade necessária para o andamento de um determinado tipo de aplicação.
Um grupo de palavras é adicionada a um dicionário da aplicação, toda vez que o
aparelho identi�car um som, o mesmo faz uma checagem se aquele som coincide com
alguma das palavras do dicionário e realiza uma determinada ação, dependendo da
palavra falada.
• Drag and Drop: O Drag and Drop é uma operação bastante comum em aplicações
do Kinect. Consiste na operação de pegar um objeto da cena e arrastá-lo para outro
local, soltando-o na hora que for desejada. Essa funcionalidade foi implementada no
jogo "Conectando"e estava presente em alguma dos jogos analisadas.
• Detecção de poses: Essa funcionalidade permite que o usuário utilize um conjunto
35
de gestos pré-de�nidos para realizar operações durante a aplicação, assim, o Kinect
detecta o gesto que está sendo executado e realiza a ação correspondente a ele. Um
conjunto de gestos foi implementado, utilizando a posição dos pontos do esqueleto
do usuário, foram eles: "Mão direita acima da mão esquerda", "Mão esquerda acima
da mão direita", "Mão direita acima da cabeça", "Mão esquerda acima da cabeça",
e "Duas mãos acima da cabeça". O Drag and Drop utiliza gestos para ser realizado,
o mesmo segura uma imagem sempre que a mão direita estiver acima da esquerda,
e solta o objeto quando a mão esquerda �ca acima da direita, facilitando o processo
de desenvolvimento da funcionalidade.
É importante ressaltar que essas funcionalidades podem ser implementadas usando
apenas o SDK Kinect for Windows da Microsoft, porém o framework foi desenvolvido
para minimizar o custo de desenvolvimento, reaproveitando uma estrutura de aplicação
com os elementos descritos.
3.1.4 Arquitetura do Framework
O framework desenvolvido se relaciona diretamente com o Microsoft Kinect SDK.
Ele trabalha como uma camada intermediária entre a aplicação desenvolvida e o SDK
da Microsoft. Ao se instanciar o framework, a classe responsável pelo �uxo da aplicação
é criada. Ela pode utilizar todas as funções desenvolvidas para o framework. Caso a
aplicação deseje utilizar uma função não disponível framework, a mesma pode trabalhar
diretamente com o Microsoft Kinect SDK, como mostrado na Figura 9.
Figura 9: Esquematização da arquitetura do framework Konect
.
A Figura 12 apresenta o diagrama de classes do framework desenvolvido. A classe
MainWindow é onde o usuário criará sua aplicação Kinect, ela se relaciona diretamente
36
com a classe KinectServices, classe onde quase todas as funções do framework é chamada.
A única função chamada fora da classe KinectServices é a detecção da fala, isso se deu
pelo tamanho da sua classe, e o grande número de métodos. A classe KinectServices,
implementa o padrão de projeto Facade, portanto provê ao programador um único ponto
de acesso a todos os outros componentes desenvolvidos. Todas as classes do diagrama são
pertencentes ao framework e utilizam funções e tipos de�nidos pelo SDK do Kinect.
Para estabelecer um relacionamento entre as principais classes, foi escolhido associá-
las sem utilizar herança. A classe KinectServices precisa utilizar métodos e atributos de
mais do que uma classe, por isso, foi necessário utilizar o relacionamento de agregação, e
não herança, visando minimizar o acoplamento entre as classes. A agregação representa
um vínculo fraco entre duas classes, ou seja, a subclasse faz sentido mesmo se a super-
classe deixar de existir. Se superclasse for apagada, a subclasse continuará existindo sem
problemas.
As classes que formam a KinectServices consistem em componentes criados para au-
xiliar o desenvolvimento de um aplicação. Cada uma dessas classes contém as funções
que compõem o framework. MainWindow é a classe na qual o programador desenvolverá
a sua aplicação, ela trabalha diretamente com a classe KinectServices e a classe Audio,
utilizando os métodos e atributos que as compõem para desenvolver seu programa. Um
único objeto é criado na classe MainWindow para utilizar todos os recursos da Kinect-
Services. Para utilizar a detecção de fala, é necessário criar um outro objeto, responsável
por realizar o tratamento do áudio e o reconhecimento dos padrões de fala.
As Figuras abaixo ilustram bem o funcionamento do framewor, apresentando como é
feito o mapeamento do esqueleto sem o uso do framework, e como o mesmo é implementado
no framework desenvolvido.
37
Figura 10: Mapeamento do esqueleto desenvolvido sem o framework
.
A Figura 10 mostra o código do mapeamento de esqueleto desenvolvido apenas usando
o SDK da Microsoft, utilizando os tipos e funções disponíveis no mesmo.
Figura 11: Mapeamento do esqueleto desenvolvido com o framework
.
A Figura 11 apresenta como o usuário trabalha com o esqueleto no framework Ko-
38
nect, conseguindo realizar todo o mapeamento, criando apenas as funções que utilizam
esse esqueleto, pois o mesmo já vem implementado através da função mostrada na imagem.
Além do KinectServices, existem as classes associadas ao padrão de projeto Adapter
(FREEMAN, 2013), visando proteger o framework de eventuais mudanças de tecnologia
ou mesmo hardware, de forma que estas alterações sejam partes isoladas de outros mó-
dulos, facilitando manutenção do framework. A classe cliente (KinectServices) acessa a
interface do Adaptador e a partir desta interface ele fará uma solicitação ao adaptador.
O Adaptador, por sua vez, implementa a interface alvo (KinectTarget) e comunica-se com
o Adaptado (IOptionsKinectAdaptee). O Adaptado é a nova biblioteca do fornecedor que
está sendo inserida no sistema.
Figura 12: Esquematização do diagrama de classes do framework Konect
.
Maiores detalhes sobre o funcionamento dos componentes e como seus métodos po-
dem ser utilizados pelo programador, podem ser encontrados no apêndice C, que consiste
na documentação fornecida aos desenvolvedores durante o experimento para testar o fra-
mework.
39
4 Avaliação do Framework
Um dos principais aspectos na criação de um framework é a sua validação, pois através
dela pode-se assegurar que o framework esteja trabalhando da maneira como foi planejado
e objetivado. Nesse capítulo, será apresentado como funcionou o experimento que teve por
objetivo validar o framework desenvolvido veri�cando se o mesmo atende as expectativas
e alcança os objetivos estabelecidos, ou seja, se o através do Konect um programador
iniciante consegue desenvolver aplicações para o Kinect de maneira rápida e prática, sem
ser necessário conhecer a tecnologia utilizada.
4.1 Metodologia
Nesta seção serão apresentadas as etapas que formaram o experimento, os recursos
necessários, os critérios para escolha dos participantes e divisão dos grupos e as caracte-
rísticas a serem avaliadas.
Para realizar os experimentos, foi selecionado um grupo de pessoas com diferentes
níveis de programação. Também dispomos de 2 sensores Kinect e um laboratório para
realização dos experimentos.
O experimento foi dividido nas seguintes etapas:
Etapa 1: O primeiro passo consistiu em dividir em dois grupos os usuários que re-
alizaram o experimento. Dentre os usuários selecionados estavam presentes pessoas com
diferentes graus de conhecimento. A divisão dos grupos foi feita de maneira que possibi-
lite o melhor balanceamento possível, obtendo dois grupos semelhantes quanto ao nível
de conhecimento em programação .
40
Os participantes foram divididos em dois grupos, um grupo de estudo e um grupo
de controle. O grupo de estudo foi formado por aqueles programadores que usaram o
framework para desenvolver a sua aplicação, enquanto o grupo de controle usou apenas o
SDK da Microsoft para o mesmo propósito.
Para a pesquisa, foram selecionados colegas de graduação do autor deste trabalho,
que voluntariamente se dispuseram para contribuir com a pesquisa. Para assegurar a
homogeneidade entre os grupos, foram selecionados aleatoriamente os voluntários que se
enquadravam nos níveis de conhecimento de�nidos.
Cada grupo foi composto por 6 participantes, totalizando assim, 12 programadores
que realizam o experimento. Esse número se deu ao fato da di�culdade de encontrar vo-
luntários para esse tipo de experimento, pois não é qualquer pessoa que pode participar.
Além de ser necessário que o voluntário dedique um tempo razoavelmente grande (de
5 a 7 horas para os participantes do grupo de controle) para o experimento, é necessá-
rio que os grupos e equipes atendam a critérios especí�cos para realização do experimento.
Cada grupo foi dividido em 3 níveis. A divisão dos grupos e equipes é mostrada na
tabela abaixo. Todos os participantes do experimento cursaram as disciplinas de pro-
gramação (Conceitos e técnicas de programação/Introdução a técnicas de programação,
Algoritmos e estruturas de dados I/II) do curso de Ciência da Computação, da Universi-
dade Federal do Rio Grande do Norte.
Tabela 3: Divisão dos grupos e equipes para realização do experimento
41
As equipes que compõem cada grupo foram divididas de maneira a atender a seguinte
con�guração:
• Nível 1: Dois programadores que já programaram para o Kinect.
• Nível 2: Dois programadores que já programaram em C #, mas não para o Kinect.
• Nível 3: Dois programadores que nunca tenham programado em C# e nem para o
Kinect, mas quem tenham experiência com outras linguagens (Java, C, C++,...).
Etapa 2: Para os participantes do nível 3, foi dada um curso introdução à linguagem
C#, para que os mesmos possam se familiarizar com os conceitos básicos da linguagem
e nivelando os participantes para poder dar prosseguimento ao experimento. Também foi
permitido que os mesmos �zessem consultas durante o experimento sobre elementos da
sintaxe da linguagem de programação C#.
Nessa etapa, cada participante teve 2 horas para se adaptar a ferramenta que utilizou,
seja o framework ou o SDK da Microsoft. Esse tempo serviu para que os participantes
tenham uma introdução aos principais conceitos, porém, os detalhes que levaram mais
tempo é um dos objetos de estudo desta pesquisa e, por isso, o tempo determinado não é
tão longo quanto o necessário para se dominar uma determinada tecnologia.
Etapa 3: Uma aplicação, com especi�cação presente no Apêndice A, contendo alguns
dos componentes básicos e formas de interação do Kinect, foi implementada por cada
um dos programadores, como explicado anteriormente. Apenas um grupo utilizou o fra-
mework, enquanto o outro desenvolveu a mesma aplicação utilizando apenas o SDK da
Microsoft.
A aplicação a ser desenvolvida conteve os seguintes componentes e formas de interação
básicas:
• Detecção do esqueleto e mapeamento dos pontos do corpo.
• Uso da câmera RGB do Kinect.
• Manipulação de botões.
42
• Vinculação de objetos da cena a partes do corpo.
• Drag and Drop.
• Detecção de poses.
• Detecção de fala.
Etapa 4: Ao acabar o desenvolvimento da aplicação, foram obtidos os seguintes dados:
• Linhas de código: Para obtenção dessa métrica, foi utilizado o CodeMetrics, ferra-
menta da Microsoft para obtenção de métricas de desenvolvimento. Foram contadas
apenas as linhas de código implementadas pelo usuário, obtendo assim, a diferença
entre se desenvolver com e sem o framework.
• Tempo de desenvolvimento: O tempo total de desenvolvimento foi marcado, ou seja,
o tempo de implementação e o tempo de obtenção do conhecimento. Assim, pudemos
veri�car o tempo que foi necessário para aprender a utilizar o framework e o SDK da
Microsoft. Também foi veri�cado o tempo gasto apenas para desenvolver a aplicação,
tendo em vista que em ambos os grupos estarão pessoas que já desenvolveram para
o Kinect, ou seja, não precisaram passar pela fase do aprendizado.
• Componentes implementados: Além das 2 horas dadas para adaptação a tecnologia,
foram dadas 5 horas para o desenvolvimento da aplicação. Foi necessário atribuir
um tempo máximo para o experimento a pedido dos participantes. Ao �m do tempo
total, foram contabilizado quantos componentes foram implementados por cada par-
ticipante.
• Questionário: Foi pedido para que cada um dos participantes responda um questio-
nário sobre o experimento realizado, onde o mesmo pode falar sobre as di�culdades
encontradas e o conhecimento adquirido durante a realização do experimento. O
questionário, presente no Apêndice B, foi respondido online e pode ser encontrado
no seguinte endereço: <http://goo.gl/q4bEma>.
Os resultados obtidos com o experimento serão apresentados no próximo capítulo.
43
5 Resultados
Esse capítulo tem como objetivo apresentar os resultados obtidos com a realização
do experimento, analisando de maneira quantitativa e qualitativa os dados extraídos do
experimento.
5.1 Análise do código
O primeiro critério avaliado foi o número de componentes programados por cada um
dos participantes na aplicação desenvolvida. No total, para que a aplicação fosse inteira-
mente desenvolvida, era necessário implementar 7 componentes, são eles:
• Componente 1: Detecção do esqueleto e mapeamento dos pontos do corpo.
• Componente 2: Uso da câmera RGB do Kinect.
• Componente 3: Manipulação de botões.
• Componente 4: Vinculação de objetos da cena a partes do corpo.
• Componente 5: Drag and Drop.
• Componente 6: Detecção de poses.
• Componente 7: Detecção de fala.
A Tabela 4 apresenta quais componentes foram implementados pelos participantes
do grupo de controle, ou seja, que não fez uso do framework. O campo marcado com
um "Ok"representa que o participante conseguiu implementar o componente, enquanto o
o campo vazio mostra que o mesmo não conseguiu implementar determinado componente.
44
Tabela 4: Componentes implementados pelo grupo de controle
Do grupo de controle, apenas 1 participante conseguiu desenvolver a aplicação por
completa. O grupo de estudou, ou seja, o que utilizou o framework durante o experimento,
apresentou melhores resultados, pois todos os participantes conseguiram implementar to-
dos os componentes da aplicação, como visto na tabela abaixo (Tabela 5).
Tabela 5: Componentes implementados pelo grupo de estudo
O tempo de desenvolvimento também foi marcado durante o experimento. O tempo
máximo que cada participante possuía era de 5 horas. A Tabela 6 apresenta o resultado
de cada um dos participantes.
Tabela 6: Tempo gasto para desenvolver a aplicação
Apenas um participante do grupo de controle não alcançou o tempo limite, enquanto
todos os outros utilizaram as 5 horas disponíveis. O grupo de estudo obteve resultados me-
lhores, pois todos os participantes realizaram o experimento em um curto tempo, abaixo
45
de 1 hora de duração.
Analisando a Figura 15, percebe-se que mesmo para os participantes que já sabiam
programar para o Kinect, o uso do framework se mostrou vantajoso, pois o tempo gasto
para se aprender a utilizar o framework é compensado pelo baixo tempo de desenvolvi-
mento levado para se implementar a aplicação.
Os resultados foram os mesmos quando se tratou de linhas de código. O grupo que
utilizou o framework precisou de bem menos linhas de código para desenvolver os compo-
nentes da aplicação. Foram medidas apenas o número de linhas de código que o usuário
teve que programar, �cando de fora da contagem as linhas pertencentes ao framework. O
resultado da contagem está apresentado na Tabela 7.
Tabela 7: Quantidade de linhas de código de cada aplicação
Como apresentado pelos dados contidos nas tabelas 4, 5, 6 e 7, os participantes que
utilizaram o framework obtiveram resultados superiores ao grupo de controle. Esse resul-
tado foi superior inclusive para os participantes do "nível 1", que já sabiam programar
para o Kinect. O tempo gasto para se aprender a utilizar a ferramenta e desenvolver a
aplicação utilizando o framework é menor que o tempo de desenvolvimento de uma apli-
cação utilizando o Microsoft SDK.
Percebe-se também, que não houve diferença de desempenho entre os participantes
do níveis 2 (A3, A4, B3 e B4) e 3 (A5, A6�, B5 e B6), mostrando que o fato de não ser
experiente com a linguagem de programação não afetou no desempenho dos participantes.
Para entender melhor os resultados obtidos com o desenvolvimento da aplicação pelos
dois grupos, foi solicitado que cada um dos participantes respondesse um questionário
46
online sobre o experimento realizado, que se encontra no apêndice B.
5.2 Análise do questionário
A primeira pergunta do questionário teve como objetivo levantar dados para saber
quais foram as fontes de pesquisa mais utilizadas, perguntando o quanto cada participante
teria utilizado as seguintes fontes de pesquisa: Documentação o�cial, livros, exemplos o�-
ciais, sites/blogs, vídeos e exemplos encontrados na internet. Os grá�cos abaixo, presentes
na Figura 13, apresentam as respostas dadas pelos participantes. Como o framework pos-
sui apenas sua própria documentação, essa pergunta levou em conta apenas as respostas
do grupo de controle.
Figura 13: Fontes de pesquisa
O primeiro fator a se observar é o pouco uso da documentação o�cial. Para entender
melhor o porquê desse fato, perguntamos o que cada participante achou da documentação
o�cial do SDK da Microsoft. O resultado está presente no grá�co abaixo (Figura 14).
47
Figura 14: Qualidade documentação Microsoft SDK
Para os participantes, a qualidade da documentação deixa a desejar, fazendo com que
os usuários tenham que buscar outras fontes de pesquisa.
Foi perguntado para o grupo de estudo, como eles avaliaram a documentação do fra-
mework, o resultado está disposto no grá�co abaixo, na Figura 15.
48
Figura 15: Qualidade documentação do framework
A documentação do framework foi bem avaliada. Apesar de ser pequena, foi con-
siderada su�ciente para o desenvolvimento de uma aplicação básica para o Kinect. O
participante B5 fez a seguinte observação: "A documentação era boa, apesar de ter apenas
texto, foi o su�ciente para o propósito, seguindo a documentação é possível implementar
qualquer aplicação com esses componentes.".
Como pode-se ver na Figura 13, as maiores fontes de pesquisa utilizadas foram os
exemplos encontrados na internet e os sites/blogs. Normalmente, quando se utiliza esse
tipo de fonte, é comum encontrar conteúdo referende há várias versões que o SDK já
possuiu até chegar na versão atual. Foi perguntado aos participantes, se esse número de
versões atrapalhou durante o processo de aprendizagem. O resultado está mostrado no
grá�co abaixo (Figura 26).
49
Figura 16: Quantidade de versões
A maioria dos participantes achou que esse é um fator que atrapalha bastante o pro-
cesso de aprendizado da ferramenta, inclusive o participante A2, que escolheu a opção
"Não atrapalhou", adicionou o seguinte comentário: "Nesse experimento não atrapalhou,
pois já sabia identi�car quais as versões anteriores", mostrando que esse fator realmente
atrapalha bastante para quem está começando a desenvolver aplicações para Kinect uti-
lizando o SDK da Microsoft. O grande número de versões é também um fator pelo qual
os livros foram tão pouco utilizados, como a�rma o participante A6: "A quantidade de
bibliogra�a é grande, porém a incompatibilidade entre as versões as tornam obsoletas."
Dentre todos os fatores já apresentados, era importante também avaliar a di�cul-
dade encontrada durante o experimento. Foi perguntado a cada um dos participantes, de
ambos os grupos, qual a di�culdade que os mesmos esperavam ter logo após de conhe-
cer a aplicação que deveriam desenvolver e a di�culdade que realmente tiveram após o
término do experimento. Os resultados estão dispostos nos grá�cos abaixo, Figura 18 e 19.
50
Figura 17: Di�culdade esperada x Di�culdade real - Grupo de controle
Figura 18: Di�culdade esperada x Di�culdade real - Grupo de estudo
Para os participantes do grupo de controle, com exceção dos participantes A1 e A2,
que já programavam pra Kinect, a di�culdade do experimento foi maior do que a di-
�culdade que eles esperavam encontrar, fazendo com que todos os outros participantes
considerassem o experimento "Muito difícil".
51
O contrário aconteceu com o grupo de estudo, que utilizou o framework. Todos os
participantes, inclusive os que já sabiam programar para Kinect, consideraram o experi-
mento com um grau de facilidade maior do que o que esperavam encontrar após conhecer
a aplicação que seria desenvolvida.
Para �nalizar, foi perguntado se os participantes utilizariam a mesma ferramente caso
tivessem que desenvolver uma outra aplicação para Kinect. As respostas estão presentes
no grá�co abaixo, Figura 24.
Figura 19: Usaria novamente a ferramenta
Dentre os participantes do grupo de estudo, todos continuariam utilizando o fra-
mework, alegando que o fato de ter uma estrutura pronta de um programa torna o uso
do framework vantajoso. Dentre os participantes do grupo de controle, apenas os partici-
pantes que já programavam para Kinect continuariam utilizando apenas o SDK, pois já
estavam acostumandos a tal ferramenta. Todos os outros participantes procurariam outro
meio para desenvolver uma aplicação, como comentou o participante A4: "Procuraria um
framework, pois só em ter alguns componentes prontos, já facilitaria bastante o desenvol-
vimento".
52
Também foi perguntado aos participantes do grupo de estudo, ou seja, que utilizaram
o framework, o que poderia ser feito para melhorar o framework utilizado. Entre os pontos
citados, estão:
• Maior conjunto de gestos.
• Possibilitar o uso de mais de um esqueleto.
• Criar um mecanismo para trocas de tela na aplicação.
Ao �nal do experimento foi possível veri�car que o framework alcançou o objetivo es-
perado, pois todos os participantes, especialmente aqueles que não possuíam experiência
com programação para Kinect, obtiveram bons resultados, ou seja, conseguiram desen-
volver integralmente a aplicação em um curto tempo de desenvolvimento.
53
6 Considerações �nais
Neste trabalho, foi apresentado um framework de desenvolvimento para aplicações
Kinect, mostrando como o mesmo foi concebido e como ele foi avaliado. Também foi
apresentado o funcionamento do dispositivo Kinect e outros frameworks e ferramentas
existentes.
Ainda existem algumas melhorias a serem realizadas no framework, a maioria delas
sugeridas pelos participantes do experimento. Esses novos componentes serão adiciona-
dos ao framework, assim que o mesmo for disponibilizado para o público, bem como um
conjunto de exemplos do seu funcionamento. A grande di�culdade encontrada foi na reali-
zação do experimento, principalmente na etapa de seleção dos participantes, pois foi difícil
encontrar programadores com disponibilidade e vontade de aprender uma nova tecnologia
e que se encaixassem nos critérios estabelecidos.
O framework apresenta limitações quando o assunto é o tratamento de gestos, pois
o mesmo foi desenvolvido para ser utilizado em aplicações simples que pretendem inte-
ragir com o usuário através de poses. A adição de um conjunto de gestos será feita por
usuários que desejem aprimorar o framework para utilizá-lo em aplicações mais complexas.
Os resultados do experimentos foram satisfatórios, pois grupo que utilizou o framework
conseguiu desenvolver a aplicação com facilidade, já que ao �nal deste trabalho esperava-
se obter um framework capaz de facilitar o desenvolvimento de aplicações Kinect para
iniciantes, ou seja, permitir que uma pessoa consiga desenvolver uma aplicação Kinect
apenas com o conhecimento de programação, sem necessariamente conhecer o funciona-
mento do Microsoft SDK. .
Assim, com a realização deste trabalho, foi possível:
54
• Identi�car os principais problemas em se aprender a desenvolver para Kinect.
• Identi�car os principais componentes em aplicações/jogos para Kinect.
• Apresentar ferramentas alternativas para o desenvolvimento de aplicações para o
Kinect.
• Desenvolver e validar uma ferramenta criada para auxiliar o desenvolvimento de
aplicações Kinect, voltada para o público iniciante, que não possuía conhecimento
sobre a tecnologia.
55
7 Referências
• Bohak, C. : Kinect Web Kiosk, Proceedings of the 4TH International Conference
Wolrd Usability Day, Slovenia, 2013.
• Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerland, P.; Stal, M: Pattern-
Oriented Software Architectur A System of Patterns, John Wiley Sons,
1996.
• Carvalho, M; Vera, M:Desenvolvimento de aplicativos com a TerraLib. Banco
de Dados Geográ�cos, cap 14, pag. 463, 2005.
• Criminisi, Antonio; SHOTTON, J..Decision Forests for Computer Vision and
Medical Image Analysis. Cambridge: Springer, 2013.
• Dantas, A.M: Avaliação de reusabilidade de aplicações web baseadas em
frameworks orientados a ações e a componentes: Estudo de caso sobre
os Frameworks Apache Struts e JavaServer Faces, Dissertação de Mestrado,
Departamento de Informática e Matemárica Aplicada - DIMAp, UFRN, 2008.
• Fairhead, H.: OpenNI 2.0 - Another Way To Use Kinect.Disponível em:
<http://www.i-programmer.info/news/194-kinect/5241-openni-20-anothe-\
\-way-to-use-kinect.html >. Acesso em: 25 mar. 2014.
• Ferreira, F: Desenvolvimento e Aplicações de um Framework Orientado a
Objetos para Análise Dinâmica de Linhas de Ancoragem e de Risers..
56
Dissertação de mestrado, 2005.
• Freeman, E. et al.: Head First: Design Patters. Sebastopol: O'reilly Media, 2013,
p.244.
• Gamma, E.; Helm, R.; Johnson R.; Vlissides, J.: Design patterns: elements of
reusable object-oriented software. Addison-Wesley, Reading, MA, 1995.
• Guinness World Records, 2011. Disponível em: <http://www.guinnessworldrecords.
com/records-9000/fastest-selling-gaming-peripheral/>. Acesso em: 17 jul.
2014.
• Glocker, B, et al. Vertebrae Localization in Pathological Spine CT via
Dense Classi�cation from Sparse Annotations.. Medical Image Computing
and Computer-Assisted Intervention, MICCAI 2013. Springer Berlin Heidelberg,
2013. 262-270.
• Hinchman, W.: Kinect for Windows SDK beta vs. OpenNI. Disponível em:
<http://labs.vectorform.com/2011/06/windows-kinect-sdk-vs-openni-2/>.
Acesso em: 25 mar. 2014.
• Inner, E.:Medical Image Analysis. Disponível em: <http://research.microsoft.
com/en-us/projects/MedicalImageAnalysis/>. Acesso em: 25 mar. 2014.
• Johnson, R. E.: Reusing Object-Oriented Design, University of Illinois, Te-
chnical Report UIUCDCS 91-1696, 1991.
• Kontschieder, P, et al. GeoF: Geodesic forests for learning coupled predic-
tors. Computer Vision and Pattern Recognition (CVPR), 2013 IEEE Conference
on. IEEE, 2013.
57
• Lucena, B: Realidade aumentada em celulares: um estudo sobre a tecno-
logia e seus potenciais: Dissertação de Mestrado, Departamento de Informática
PUC-Rio, 2012.
• Myatt, A.: Pro NetBeans IDE 5.5 Enterprise Edition, Nova Iorque, 2007.
• Maldonado, J.C.; Braga, R. T.V.; Germano, F.S.R.; Masiero, P.C.: Padrões e Fra-
meworks de Software . Notas didáticas. Instituto de Ciências Matemáticas e de
Computação. Universidade de São Paulo, 2009. Disponível em: <http://www.icmc.
usp.br/pessoas/rtvb/apostila.pdf>. Acesso em: 15 jul. 2014.
• Nourie, D: Getting Started With the NetBeans IDE Tutorial. Disponí-
vel em: <http://www.oracle.com/technetwork/java/netbeans-part1-142734.
html>. Acesso em: 9 jul. 2014.
• Pinto, S. C. C. S.: Composição em WebFrameworks, tese de doutorado, Depar-
tamento de Informática PUC-Rio, 2000.
• Pree, W.: Design Patterns for Object-Oriented Software Development,
Addison-Wesley, 1995.
• Rehman, R; Paul, C: The Linux Development Platform: Con�guring, Using,
and Maintaining a Complit Programming Environment , 2002.
• Rocha, P.; Defalvari, A.; Brandão, P.;: Estudo da viabilidade da utilização
do Kinect como ferramenta no atendimento �sioterapêutico de pacientes
neurológicos Proceedings of SBGames 2012, Brasil, DF, 2012.
• Silva, C: MCF: Um Framework de conectividade para aplicações móveis
em Java ME. Trabalho de Conclusão de Curso. Universidade Federal de Pernam-
buco, 2007.
58
• Teo�lo, L; Nogueira, P; Silva, P: GEMINI: A Generic Multi-Modal Natural
Interface Framework for Videogames , 2013.
• Villaroman, N.; Rowe, D.; Swan, B.: Teaching natural user interaction using
OpenNI and the Microsoft Kinect sensor. In: SIGITE, 12., 2011, New York.
• Ye, D et al. Modality Propagation: Coherent Synthesis of Subject-Speci�c
Scans with Data-Driven Regularization.Medical Image Computing and Computer-
Assisted Intervention?MICCAI 2013. Springer Berlin Heidelberg, 2013. 606-613.
• Zikic, D; Glocker, B; Criminisi, A. Atlas encoding by randomized forests for
e�cient label propagation. Medical Image Computing and Computer-Assisted
Intervention?MICCAI 2013. Springer Berlin Heidelberg, 2013. 66-73..
59
APÊNDICE A -- Especi�cação da aplicação
O objetivo deste experimento de programação é desenvolver uma aplicação grá�ca
interativa utilizando o sensor Kinect. O desenvolvimento desta aplicação vai proporcionar
a oportunidade de estudar e utilizar os conhecimentos sobre: a) habilitação de sensores
do Kinect; b) mapeamento do esqueleto; c)criação de menu e manipulação de botões; d)
uso da câmera RGB do Kinect; e) criação de gestos; f)manipulação de objetos em cena;
g)reconhecimento de áudio;
A.1 Introdução
Sua tarefa consiste em desenvolver uma aplicação interativa utilizando o Kinect e uma
ferramenta de desenvolvimento, SDK da Microsoft ou framework Konect. A aplicação con-
siste em uma tela de pintura, onde o usuário pode desenhar utilizando os movimentos do
seu corpo e �guras disponíveis na aplicação. A aplicação conterá um menu de cores, onde
deve ser selecionado qual cor o usuário deseja utilizar. A seleção da cor também deverá
ser feita através da fala.
O desenho deve seguir o rastro da mão direita do usuário, porém a pintura só ocorrerá
no memento em que o usuário estiver com a mão direita acima da mão esquerda. Abaixo
do menu de cores estará presente uma imagem, que o usuário pode arrastar para a sua
tela, compondo a pintura.
A aplicação deve ser desenvolvida utilizando o Kinect e o Visual Studio C#, versão
superior a 2010.
60
A.2 Funcionalidades do sistema
O sistema a ser desenvolvido deverá oferecer as seguintes funcionalidades:
A1 - Mapeamento do esqueleto: A aplicação deve mapear o esqueleto e detectar
os 20 pontos que o compõe, para que o usuário possa utilizar a aplicação através dos
movimentos do seu corpo.
A2 - Criação de menu (manipulação de botões): Deverá ser criado um menu,
onde estará presente as cores que o usuário pode utilizar. Esse menu deve ser do tipo
Hover Button, ou seja, para selecionar uma cor o usuário mantém a mão sobre a opção
escolhida por um intervalo de tempo para que a mesma possa ser selecionada.
A3 - Uso da câmera RGB: A aplicação deverá possuir uma câmera em um local
da tela, que mostre o usuário realizando os seus movimentos. Essa câmera terá um papel
ilustrativo na aplicação, possibilitando que o usuário o veja enquanto desenha.
A4: Detecção de poses: Consiste em uma importante funcionalidade para apli-
cações Kinect. Para essa aplicação será necessário implementar uma única pose, "Mão
direita acima da mão esquerda". Esse gesto será utilizado durante o desenho, ou seja,
sempre que for detectado esse gesto será possível desenhar algo na tela. Se o mesmo não
ocorrer, ou seja, a mão esquerda que estiver a cima da direita, nenhum desenho deverá
aparecer na pintura enquanto isso ocorrer.
A5 - Drag and Drop: O Drag and drop consiste em selecionar um elemento e
arrastá-lo até a posição desejada. Nessa aplicação haverá uma imagem, abaixo do menu
de cores, que poderá ser arrastada pelo usuário até a "área de desenho"para compor a
pintura.
A6 - Detecção de fala: Nesta aplicação também será possível selecionar uma cor no
menu através da fala. Ou seja, assim que o usuário falar a cor desejada (blue, red, green
ou yellow), a opção correspondente a cor falada deve ser selecionada.
A Figura 20 apresenta uma estimativa de como deve �car sua aplicação ao �nal do
experimento.
61
Figura 20: Exemplo de Interface para a aplicação desenvolvida
62
APÊNDICE B -- Questionário
1 - Quais foram suas fontes de pesquisa?
Figura 21: Tabela sobre fontes de pesquisa do questionário
Se utilizou "Outros", cite quais:
2 - Quando a aplicação foi apresentada, o quão fácil ou difícil você achou que seria?
( ) Muito Difícil ( ) Difícil ( ) Normal ( ) Fácil ( ) Muito Fácil
3 - Qual o grau de di�culdade você considera que teve no desenvolvimento da aplica-
ção?
( ) Muito Difícil ( ) Difícil ( ) Normal ( ) Fácil ( ) Muito Fácil
4 â O quanto te atrapalhou a grande quantidade de versões anteriores existentes
( ) Não atrapalhou ( ) Atrapalhou pouco ( ) Atrapalhou muito
63
5 - Como você avalia a qualidade da documentação do SKD da Microsoft/Framework?
( ) Muito Rui ( ) Ruim ( ) Normal ( ) Boa ( ) Muito Boaz
6 - Como você avalia a quantidade de bibliogra�a encontrada?
( ) Raro ( ) Pouco ( ) Normal ( ) Muito ( ) Abundante
7 - A quantidade de bibliogra�a foi:
( ) Su�ciente ( ) Insu�ciente
8 - Como você avalia a quantidade de exemplos o�ciais disponíveis?
( ) Raro ( ) Pouco ( ) Normal ( ) Muito ( ) Abundante
9 - A quantidade de exemplos o�ciais foi:
( ) Su�ciente ( ) Insu�ciente
10 - Se fosse necessário desenvolver algum tipo de aplicação para o Kinect, você
utilizaria novamente a mesma ferramenta.
( ) Sim ( ) Não
11 (Framework) - Os componentes desenvolvidos são os essenciais para uma aplicação
Kinect.
( ) Sim ( ) Não
12 (Framework) - Cite quais outros componentes seriam necessários para o framework :
64
APÊNDICE C -- Documentação Konect
C.1 Introdução
Esse documento consiste na documentação do Framework Konect, que foi criado com
o objetivo de facilitar o desenvolvimento de aplicações para o sensor Kinect.
O Framework foi implementado inteiramente utilizando a linguagem de programação
C# e tendo como base o SDK o�cial da Microsoft. Para utilizá-lo é necessário ter o Visual
Studio (versão superior a 2010), bem como o sistema operacional Windows 7 ou 8.
Konect contém um conjunto de funcionalidades implementadas que visam proporci-
onar ao usuário um rápido e prático desenvolvimento de aplicações para o Kinect, são
elas:
• Mapeamento do esqueleto;
• Vinculação de objetos a pontos do corpo;
• Criação de menus (manipulação de botões);
• Câmera RGB;
• Poses pré-de�nidas;
• Drag and Drop;
• Detecção de fala;
Nas próximas seções serão explicados o funcionamento do framework, apresentando a
sua estrutura e as funcionalidades que o mesmo dispõe. Será mostrado como utilizar cada
uma das funcionalidades necessárias para desenvolver uma aplicação.
65
C.2 Estrutura
O framework apresenta uma estrutura composta por um conjunto de classes e refe-
rências inclusas no sistema. Ao iniciá-lo, o usuário tem acesso a um conjunto de classes
representando os componentes principais para a criação de uma aplicação Kinect, bem
como um conjunto de exceções e uma classe principal, onde está presente o esqueleto de
uma aplicação, na qual o programador vai trabalhar para criar o seu programa.
Na aba "References", estão presentes todas as referências necessárias para utilização
dos componentes presentes no framework, inclusive as referências do próprio SDK da
Microsoft: Microsoft.Kinect e Microsoft.Speech.
No framework também se encontra uma pasta, chamada "Resources". É nela que
deverão ser incluídos todos os objetos (imagens e áudios) que estarão presentes na aplica-
ção desenvolvida. As imagens incluídas devem estar no formato png, enquanto os áudios
devem estar no formato mp3.
A classe principal, aquela que o usuário vai trabalhar para desenvolver sua aplicação,
é a classe MainWindow. Essa classe é dividida em duas sub-classes: MainWindow.xaml
(nela que serão inclusos os elementos que v¿o compor a interface grá�ca da aplicação)
e MainWindow.xaml.cs ( nesta classe o usuário irá programar a sua aplicação, nela está
presente uma estrutura de um programa, no qual o usuário deve preencher para criar a
sua aplicação).
C.3 Componentes
Nesta seção serão apresentados o funcionamento dos componentes presentes no fra-
mework, como e onde utilizá-los durante o desenvolvimento da aplicação.
C.3.1 Mapeamento do esqueleto
O mapeamento do esqueleto é uma das principais funcionalidades presentes em quase
todas as aplicações para o Kinect. No framework essa funcionalidade já vem implemen-
tada, e pode ser vista função runtime_SkeletonFrameReady.
O trecho de código abaixo mostra como essa funcionalidade é chamada no framework
66
Konect.
Skeleton novo = app.SkeletonFrameReady(sender, e);
A criação do esqueleto se da através da chamada da função SkeletonFrameReady no
objeto app. A partir desse ponto um esqueleto chamado novo foi criado, assim como os
seus 20 pontos foram mapeados.
Para acessar um desses pontos, basta digitar novo.Joints[JointType.ponto dese-
jado]. Logo ap± o JointType. aparecerá uma caixa contendo os 20 pontos mapeado, como
mostrado na �gura abaixo.
Figura 22: Selecionando um ponto do corpo
C.3.2 Câmera RGB
O uso da câmera RGB presente no sensor é bastante comum em aplicações para o
Kinect. Essa funcionalidade já vem implementada no framework.
A câmera é adicionada como uma imagem na classe MainWindowl.xaml, como apre-
sentado na linha de código abaixo. Nela estão presentes o nome da imagem (como a
câmera será chamada), sua localização e o seu tamanho (altura e largura).
<Image Name= "videoImage"Canvas.Left="39"Canvas.Top="448"Width="216"
Height="108�> </Image>
A câmera é mapeada como uma imagem, que é atualizada a cada fração de segundo,
gerando a sensação de que o usuário está vendo um vídeo em tempo real dos seus mo-
vimentos. Para mudar o local ou o tamanho da mesma, basta alterar esses campos ou
modi�cá-los com o mouse aumentado/diminuindo ou deslocando a imagem na tela.
67
Essa funcionalidade é implementada na classe MainWindow.xaml.cs na seguinte fun-
ção:
void runtime_ColorFrameReady(object sender, ColorImageFrameReadyEventArgs e)
{
videoImage.Source = app.sensor_ColorFrameReady(sender, e);
}
C.3.3 Criação de menus(Manipulação de botões)
Um botão é representado por uma borda transparente que se coloca ao redor de um
objeto, transformando aquele simples objeto (imagem, elipse, etc) em um botão. Para criar
essa borda, é necessário digitar a seguinte linha de código na classe MainWindow.xaml.
<Controls:HoverButton x:Name="Button1"ImageSize="100"TimeInterval="1000"
Height="46"Width="38"Canvas.Left="217"Canvas.Top="170"/>
Na linha de código acima, estáo presentes o nome do botão, o seu tamanho, sua locali-
zação na tela e o intervalo de tempo que o mesmo deve �car pressionado para constar que
o usuário escolheu aquela opção. No framework o tipo de menu utilizado é o HoverButton,
aquele em que o usuário mantém a mão parada sobre uma opção por um determinado
tempo para selecioná-la.
Depois de criar a borda, é necessário arrastá-la para cima do objeto que se deseja
tornar um botão. A partir desse momento aquele objeto passa a ser um botão, e todas as
operações sobre ele são chamadas com o seu nome, que nesse caso é "Button1".
O próximo passo é vincular um evento a esse botão, ou seja, o que acontecerá quando
esse botão for pressionado. Para isso é necessário adicionar a seguinte linha de código
dentro da do construtor public MainWindow().
Button1.Click += new RoutedEventHandler(Button1_Click);
Depois disto, é necessário criar a função "Button1_Click", onde estará programado o
que vai acontecer quando o botão for pressionado.
void Button1_Click(object sender, RoutedEventArgs e)
{
Ação que ocorrerá quando o botão for pressionado.
68
}
O próximo passo é fazer a veri�cação de se o botão está pressionado ou não. Essa
veri�cação �ca ocorrendo a cada momento, e é feita através do uso da função CheckButton,
como mostrado na linha de código abaixo:
app.CheckButton(Button1, Elipse1);
Essa função veri�ca se a "Elipse1"(elipse vinculada há um ponto do corpo, por exemplo
"mão direita") está pressionando o botão Button1. A linha de código acima deve ser
incluída na função runtime_SkeletonFrameReady.
C.3.4 Poses pré-de�nidas
A maioria das poses são criadas utilizando os pontos mapeados do corpo. No fra-
mework, um conjunto de cinco poses já estão implementados. São elas:
• MDacimaME: Mão direita acima da mão esquerda.
• MEacimaMD: Mão esquerda acima da mão direita.
• MDacimaCabeca: Mão direita acima da cabeça.
• MEacimaCabeÃ�a: Mão esquerda acima da cabeça.
• DuasMaosAcimaCabeca: Duas mãos levantadas acima da cabeÃ�a.
Essas cinco funções retornam um valor booleano (true ou false), que serve para veri-
�car se essas poses estão acontecendo no exato momento. Para se utilizar de um desses
gestos é necessário obter os seguintes pontos: Mão direita, mão esquerda e/ou cabeça.
Para obter esses pontos, basta utilizar os seguintes comandos:
var MaoDireita = novo.Joints[JointType.HandRight];
var MaoEsquerda = novo.Joints[JointType.HandLeft];
var Cabeca = novo.Joints[JointType.Head];
Depois da obtenção desses pontos, basta chamar as funções citadas e guardar a infor-
mação, se a pose está ou não acontecendo naquele momento em uma, variável booleana.
Por exemplo:
69
Boolean gesto1 = g.MDacimaME(MaoDireita, MaoEsquerda);
Sempre que a função for ser utilizada, os parâmetros são mão direita, mão esquerda
e/ou cabeça respectivamente.
C.3.5 Drag and drop
O Drag and Drop consiste em arrastar uma imagem pela tela e soltá-la no momento
e local desejado. Para isso, é necessário tratar a imagem que deve ser arrastada como um
botão, seguindo os procedimentos da seção de manipulação de botões.
O primeiro passo é criar uma variável booleana global, e inicializá-la com o valor false,
por exemplo:
Boolean drag1 = false;
O segundo passo, consiste em seguir os procedimentos de manipulação de botões, ou
seja, vincular o evento e criar a função que realiza a operação sobre o botão. Para realizar
o Drag and Drop, o único procedimento necessário dentro da função é modi�car o valor
da variável global para true, ou seja:
void drag1_Click(object sender, RoutedEventArgs e)
{
drag1 = true;
}
Por �m, basta chamar a função abaixo, dentro da função runtime_SkeletonFrameReady.
Boolean DragDrop(Image imagem, HoverButton botao, Joint joint, Boolean segurado,
Boolean condicao)
A função acima retorna um booleano, para dizer se a imagem está sendo arrastada ou
não. Para isso, é necessário mandar como parâmetro, respectivamente, o nome da imagem,
o nome do botão, o ponto do corpo que se está utilizando para arrastar, a variável global
e uma condição para se realizar a operação.
Ou seja, se o usuário desejar arrastar a imagem "img1"(com o botão "button1"),
70
usando a mão direita, sempre que a mesma estiver acima da mão esquerda, basta utilizar
a função da seguinte maneira.
drag1 = app.DragDrop(img1, button1, novo.Joints[JointType.HandRight], drag,
novo.Joints[JointType.HandRight].Position.Y>novo.Joints[JointType.HandLeft].Position.Y);
C.3.6 Detecção da fala
A detecção da fala consiste em o programa identi�car a palavra dita pelo usuário e
executar uma ação pré-de�nida. Essa operação reconhece apenas palavras em inglês.
O primeiro passo é a criação da gramática, ou seja, de�nir o conjunto de palavras que
serão utilizadas durante o procedimento de identi�cação. Para criar a gramática, basta
ir na função SpeechRecognitionEngine CreateSpeechRecognizer() e adicionar as palavras
desejada. Para isso, utiliza-se o comando grammar.Add();. Por exemplo, para adicio-
nar as palavras "one", "two"e "three", basta realizar o seguinte procedimento na seção
reservada para criação da gramática.
grammar.Add("one");
grammar.Add("two");
grammar.Add("three");
Depois da criação da gramática, é necessário de�nir as operações que serão reali-
zadas quando uma das palavras for utilizada pelo usuário. Para isso, basta ir na função
SreSpeechRecognized(object sender, SpeechRecognizedEventArgs e) e adicionar os seguintes
comandos:
if (e.Result.Text.ToLower() == "one" & & e.Result.Con�dence >= 0.5)
//Operação que ocorrerá quando o usuário falar "One"
else if (e.Result.Text.ToLower() == "two" & & e.Result.Con�dence >= 0.5)
//Operação que ocorrerá quando o usuário falar "Two"
else if (e.Result.Text.ToLower() == "three" & & e.Result.Con�dence >= 0.5)
//Operação que ocorrerá quando o usuário falar "Three"
O grau de con�ança de�ne a precisão com que a palavra deve ser dita, e varia de 0.1
a 1 . Quanto maior o grau de con�ança, maior a precisão necessária para que o programa
reconheça a palavra falada.
![FRAMEWORK PARA APLICAÇÕES EM …lvelho.impa.br/hp/files/Hallison-Monografia.pdfem dispositivos móveis. O framework será implementado para a plataforma iOS [22], utilizada pelos](https://img.document.onl/doc/110x75/5f6297184d062e47541336e4/framework-para-aplicaes-em-em-dispositivos-mveis-o-framework-ser-implementado.jpg)
