Kinect Gesture: O Modelo Semântico da Linguagem

No projeto de uma linguagem de programação, frequentemente discute-se sobre sintaxe e semântica. A sintaxe captura as expressões válidas nos programas - tudo o que está expresso na sintaxe customizada é capturado pela gramática. A semântica de um programa é o que ele significa, ou seja, o que ele faz quando executado. Nesse caso, é o modelo que define a semântica. No contexto de DSL, podemos considerar um Modelo Semântico como algo muito próximo de um framework.

O Kinect Gesture, da linguagem LEG, é o Modelo Semântico desenvolvido para executar a especificação do gestos escritos em LEG. Nesse caso, representa uma estrutura de dados com todo o comportamento em funções separadas. Um novo gesto pode ser "configurado"ao reusar funções que representam múltiplas regras de relações e ações disponíveis como recursos do modelo.

Tal modelo pode ser evoluído com objetivo de construir novos recursos de reconhe- cimento de gestos, independentemente de existir sintaxe definida para expô-los a partir da linguagem. No entanto, a evolução ideal da linguagem seria evoluir o modelo e a gramática simultaneamente. Nas próximas seções tratamos em detalhes os recursos que fazem parte do Kinect Gesture.

4.3.2.1 Serviço de Reconhecimento de Gestos

O Serviço de Reconhecimento de Gestos é o principal recurso do Kinect Gesture. Ele possui todas as classes ligadas à lógica para rastrear e identificar os gestos descritos na linguagem.

Para tanto, utiliza um Controlador de Gestos, onde a cada quadro capturado do sensor verifica se o usuário está na posição correta conforme a ordem das poses que foi definida. Quando o último segmento é identificado, o evento de gesto reconhecido é disparado pelo Controlador de Gestos. No processo de análise do gesto, o primeiro passo é tratar o gesto em poses que, quando combinadas com outras poses, compõe um gesto específico. Esse verificação é feita aplicando estados de rastreamento a cada pose. Cada pose pode estar em um dos três estados de rastreamento: não identificado, em execução e identificado. A Figura 4.10 ilustra as diferenças entre os estados de rastreamento. Em suma, os estados significam o seguinte:

 Não identificado: a pose falhou. O usuário não se movimento de acordo com a

especificação aguardada. A última pose válida continua sendo a anterior.

 Em execução: o usuário está realizando o movimento. A pose está sendo avaliada.

Se for identificada, passa para a próxima pose.

 Identificado: o usuário realizou o movimento de acordo com o especificado. Caso

seja a última parte que compõe o gesto, o evento de gesto reconhecido será lançado.

Figura 4.10: Estados de Rastreamento do Controlador de Gestos

O conjunto de informações utilizados na análise do gesto são provenientes dos sensores, que por sua vez é fornecido por uma classe a parte que possui a função de auxiliar a inicialização do(s) sensor(es). Essa implementação referencia o Software Development Kit (SDK) do disposi- tivo. Toda o processo de configuração do dispositivo fica encapsulado, sendo necessário apenas conectar o dispositivo ao computador e executar a aplicação final.

O serviço de gestos possui uma interface IRastreador com o método Rastrear que recebe por parâmetro os dados capturados do sensor. A classe Rastreador implementa a interface IRas- treadore o método Rastrear da interface. A lógica para identificação de todos os gestos é igual, por este motivo optou-se por implementar o método Rastrear na classe base de rastreamento. Há também uma classe comum a todas as poses. A classe abstrata Movimento. A classe Rastreador rastreia apenas objetos que herdem da classe Movimento e que sejam concretos.

O anexo C ilustra o diagrama de classes resumido do serviço de gestos, contendo somente suas principais classes com seus respectivos atributos, propriedades, métodos e eventos públicos.

Todas as classes referentes as regras de relação e ação são implementadas como classes concretas tendo como base a classe abstrata Movimento. Ao herdar da classe Movimento torna- se necessário a sobrescrita do método PosicaValida que possui uma lógica própria de acordo com cada regra. Cada regra é baseada em funções matemáticas do espaço de coordenadas tridimensional que serão detalhadas nas próximas seções.

O arcabouço base do Serviço de Gestos é baseado no código fonte escrito por Michael Tsikkose James Glading da equipe do SDK do Kinect for Windows disponível publicamente em: http://blogs.msdn.com/b/mcsuksoldev/archive/2011/08/08/writing-a-gesture-service-with- the-kinect-for-windows-sdk.aspx

4.3.2.2 Sistema de Coordenadas e Orientação das Articulações

Nesta seção, serão apresentados alguns conceitos do sistema de coordenadas e funções matemáticas utilizadas na abstração dos movimentos do corpo humano.

Desde que uma pessoa esteja à frente do dispositivo, é possível obter através do sensor de profundidade, um plano cartesiano de três dimensões referente as coordenadas das articulações do corpo humano. Esse plano tridimensional é uma representação em forma de esqueleto e cada segmento desse modelo é referenciado como junções do corpo do usuário. Portanto, em cada articulação têm-se 3 coordenadas, sendo elas: x → eixo horizontal, y → eixo vertical e z → a distância a partir do centro do dispositivo. A Figura 4.11 ilustra um ponto de articulação e suas coordenadas x, y, z em relação ao sensor de profundidade que, em conjunto, formam o mapa de articulações.

Figura 4.11: Coordenadas x, y, z e Mapa de Articulações

A partir desse mapa de articulações tridimensional, alguns movimentos de um ser humano podem ser identificados de acordo com a posição na qual um articulação está em relação à outra.

Por exemplo, o simples movimento de chutar, pode ser mapeado através de uma regra lógica em que o eixo z da articulação referente ao pé é maior que do outro pé, além disso, ao chutar, o pé também se levanta do chão, o que significa que o eixo y da articulação do pé que realizou o chute é maior que o pé de apoio. Com estas simples regras de comparação podemos definir a relação das posições entre qualquer parte do corpo humano. Uma explanação geral de cada lógica utilizada na regra de relação está presente no quadro 4.1.

Tabela 4.1: Lógica de Coordenadas para Regra de Relação

Relação Lógica to the left of x < x to the right of x > x in front of z > z behind z < z above y > y below y < y

Na lógica descrita anteriormente utilizamos apenas comparações entre as posições das articulações em seus eixos, mas há um um outro tipo de abordagem para comparação de gestos mais complexos, como por exemplo, a rotação e inclinação.

4.3.2.3 Funções Matemáticas Utilizadas na Abstração

Algumas formas de representar rotação e inclinação com relação a um sistemas de coordenados podem ser abordados por matrizes de rotação e ângulos de Euler, cujas funções são apresentadas a seguir:

 A distância Euclidiana entre dois pontos em um espaço de três dimensões é descrita

como :

p(a

− b

)

+ (a

− b

)

+ (a

− b

)

onde a e b são pontos localizados no espaço citado. E, ax e bx, aye by, az e bzsão

valores representando os pontos nos eixos X, Y e Z da articulação. Essa regra permite o cálculo de inclinação dos membros do corpo humano.

 A fim de abstrair a rotação em três dimensões de alguma articulação, o dispositivo

Kinect (v1 e v2) fornece uma matriz de rotação de cada articulação do Mapa de Articulações. Uma articulação pode ter sua rotação tridimensional calculada através da transformação da matriz de rotação, fornecida através da API, em quatérnios. Um quatérnio representa rotação tridimensional. Uma grande vantagem é utilizar o objeto Quaternionda biblioteca Media 3D (System.Windows.Media.Media3D), este objeto oferece o método que retorna o ângulo de rotação, bastando apenas passar os valores da matriz de rotação, cujo exemplo de código é apresentado na Figura 4.12.

Figura 4.12: Código em C# da transformação da matriz de rotação para objeto Quatérnio.

4.3.2.4 Suporte a Diferentes Sensores de Profundidade

Este módulo fornece uma interface genérica para capturar dados de entrada dos senso- res, o que torna a linguagem LEG com suporte a diferentes sensores de profundidade. Uma abordagem similar é utilizada em Khandkar e Maurer (2010).

Devido à arquitetura dos Software Development Kits (SDKs) fornecidos pelos fabricantes de hardware para construir aplicações baseadas em gestos, as aplicações desenvolvidas, muitas vezes tornam-se intimamente ligados com o SDK. Dessa forma, se o dispositivo compatível for substituído por outro mais moderno ou de fabricante diferente, parte significativa das aplicações precisam ser reescritas.

Para superar isso, a arquitetura da linguagem LEG foi projetada para dar suporte a diferentes SDKs sem alterar qualquer código fonte da aplicação baseada em gestos. A camada de abstração de hardware recebe dados de baixo nível a partir dos sensores. Uma classe é responsável por traduzir as entradas do dispositivo em um formato de dados genérico que suporta os descritores do corpo humano utilizados na linguagem LEG. Cada dispositivo suportado tem sua própria implementação e mapeamento de entrada que é desenvolvido através da extensão da classe de entrada base. A Figura 4.13 mostra como podemos selecionar um dispositivo com apenas uma linha de código.

Figura 4.13: Código para modificar dispositivo/sensor da aplicação.