This work presents a method of creating compatibility between previously incompatible joysticks and desktop games. To facilitate connectivity the VRPN protocol was used. The ultimate goal is to enable the use of new input devices for rehab games and save the generated data for later viewing. Resumo. Este trabalho apresenta um método de criar compatibilidade entre joysticks e games desktop anteriormente incompatíveis. Para facilitar a conectividade o protocolo VRPN foi utilizado. O objetivo final é permitir o uso de novos dispositivos de entrada para games de reabilitação e salvar os dados gerados para posterior visualização.
Para a resolução desse problema, foi proposta a criação de uma interface que permitirá a utilização dos dispositivos com os games já desenvolvidos de forma não invasiva, ou seja, dispensando a modificação do código-fonte dos games.
2.1 Flexible Action and Articulated Skeleton Toolkit - (FAAST)
Esse middleware1 realiza a conversão de gestos para inputs de teclado ou mouse. Na
prática o usuário realiza gestos que podem ser configurados para acionar eventos de
teclado no sistema operacional (SO). Atualmente possui compatibilidade com Kinect e
PrimeSensor, encontra-se na versão 1.2 e não possui código aberto. Foi implementado
um Virtual Reality Peripheral Network (VRPN) para o FAAST, trata-se de um
protocolo que permite o uso de equipamentos de Realidade Virtual (RV) em re
Com esse protocolo é possível ter vários dispositivos de entrada ligados a um ou
mais servidores VRPN que por sua vez, enviarão todo o fluxo de inputs para o cliente
onde a aplicação de RV estará em execução [
O FAAST pode reconhecer gestos como: Andar, pular, girar corpo à direita ou esquerda, levantar a mão na altura da cabeça, realizar movimento com a mão à 20cm/s, flexionar o braço em 45°, entre outros.
O projeto proposto nesse trabalho também irá utilizar VRPN. Ao contrário do
FAAST, não será necessário codificar um novo VRPN, será utilizado o protocolo oficial
uma vez que ele possui código aberto.
2.2 IGER
Com o propósito de se obter as vantagem do reuso,
A IGER foi proposta com alguns objetivos em comum com o projeto proposto neste artigo: Permitir o uso de diversos dispositivos de entrada com os jogos, manter um histórico do desempenho dos pacientes para que eles possam ser acompanhados por um terapeuta mesmo que à distância e detectar e alertar quando movimentos incorretos são realizados.
É permitido o uso de diversos dispositivos de entrada, todavia além da obrigatoriedade de criá-los dentro dessa game engine, é necessário codificar os games 1 Middleware - Software que faz a mediação entre software e demais aplicações. para cada dispositivo de entrada que será utilizado. A game engine apenas fornece métodos mais fáceis de acesso aos inputs dos dispositivos.
O RehabConnex é um middleware para conexão entre games e diferentes tipos de controles, com o intuito da utilização em terapia e exercício físico.
Esse framework foi testado com alguns jogos do Rehab Games, uma coleção de
jogos para reabilitação, como: Gabarello 1.3 e 2.0, Magic Castle, Tornalino e FlyVinci.
Foram testados diferentes tipos de equipamentos como: Lokomat, ChARMin, PITS,
RowingMachine e câmeras com software de reconhecimento [
Os games Gabarello 1.3 e 2.0 foram originalmente construídos para serem controlados com o WaterRower, um equipamento de remo, porém por intermédio do framework ambos os jogos funcionaram com o Gait Robot Lokomat e o PITS que funcionam como uma esteira e uma luva respectivamente. O RehabConnex utiliza conexões TCP/IP2. Nos projetos da UFRN nenhum dispositivo possui conexões de rede, existe somente USB e Bluetooh, porém é importante considerar que pode-se desenvolver um equipamento que use TCP/IP, então o projeto deverá ser facilmente adaptável para essa situação.
O ponto principal dessa arquitetura é a possibilidade de configuração do modo de jogo pelo fisioterapeuta sem a necessidade de programação. É possível usar o Kinect e definir com quais movimentos o game será controlado, configurando, por exemplo, que somente movimentos com o tronco irão mover o personagem e ele irá atacar com os movimentos de braço.
Uma das justificativas para a criação desse projeto é que, devido a existência de diversos mini games de baixo custo, os terapeutas precisam ter uma atenção maior na escolha do game ideal, uma vez que os jogos para reabilitação normalmente são codificados para atenderem diversos exercícios, não permitindo uma configuração do quanto que o paciente terá que se mover. Dessa forma, foi construída a ferramenta que permite que qualquer jogo possa ser controlado com o exercício desejado.
Com o objetivo de apresentar uma visão ampla entre os trabalhos relacionados e o projeto proposto neste artigo, listamos as similaridades entre as ferramentas. A Tabela 1 2 TCP/IP - Conjunto de protocolos de comunicação entre computadores em rede. Projeto FAAST IGER RehabConnex
TeamBridge
apresenta esses dados, o trabalho 2.4 Jogos sérios para reabilitação não está presente na tabela por não apresentar detalhes técnicos.
Tabela 1 - Comparativo entre as ferramentas apresentadas.
X
X X X X X A solução proposta neste trabalho terá como objetivo principal a simplificação do desenvolvimento de novos dispositivos de entrada e games terapêuticos.
Para obter uma arquitetura mais adaptável, o sistema será dividido em dois módulos, módulo de compatibilidade e o módulo terapêutico, o primeiro será independente do segundo. Os objetivos específicos deste trabalho também serão divididos de acordo com os módulos propostos. Para o módulo de compatibilidade temos dois objetivos específicos: • • • •
A criação de uma arquitetura que solucione a incompatibilidade entre os dispositivos e os games, preferencialmente de maneira que este não necessite modificações no código-fonte.
Documentação da arquitetura proposta.
No módulo terapêutico também teremos dois objetivos específicos: Salvar os dados gerados pelos dispositivos de acordo com o seu tipo. O Kinect gera uma quantidade de dados maior em relação a uma luva de dados, logo a forma de salvá-los os poderá ser diferente.
Identificar movimentos incorretos e alertar ao paciente. Para esta pesquisa um movimento incorreto será aquele que seja realizado com uma velocidade acima do normal ou quando o paciente estiver em uma pose onde o seu equilíbrio esteja em risco.
Neste projeto o protocolo VRPN disponível no GitHub3 será utilizado para intermediar os dispositivos de entrada e a aplicação. Para poder utilizar a estrutura do VRPN será necessária a criação do modelo de cliente e servidor conforme exemplificado na Figura 1: 3 VRPN – Repositório oficial: https://github.com/vrpn/vrpn
Servidor - Possuirá os drivers4 necessários para ler os dados gerados pelos dispositivos de entrada. Todos os dados serão repassados sem a realização de nenhum tratamento.
Cliente - Irá receber e interpretar os dados brutos, convertendo para eventos no sistema operacional. O cliente contará com uma lista de gestos que poderão ser configurados para acionamento de comandos, essa configuração será feita pelo terapeuta em um arquivo de texto.
As vantagens da utilização do VRPN já existente são: já possuir uma estrutura testada e documentada e compatibilidade com mais de 60 dispositivos de entrada, para este projeto será necessário a criação de drivers apenas para os dispositivos já construídos pela UFRN e para o Leap Motion, o Kinect já é compatível com o VRPN. Apesar de existir um cliente e servidor, ambos serão aplicações que poderão estar na mesma máquina física.
Figura 1 - Arquitetura proposta
Conforme apresentado na Figura 1, além de converter os dados gerados o sistema também irá armazená-los. Essa etapa não será obrigatória, visto que essa funcionalidade será do módulo de terapia. Para obter maior eficiência os dados não serão salvos diretamente no banco de dados, e sim em um arquivo de texto. Somente quando o utilizador desejar eles serão enviados para o banco de dados. Esse artifício é necessário pois alguns dispositivos como o Kinect podem gerar mais de 9 mil linhas por segundo. Posteriormente o terapeuta poderá visualizar os dados salvos em uma aplicação, onde os dados serão representados através de um esqueleto em 3d que irá executar exatamente os mesmos movimentos que foram capturados pelo dispositivo. Dados mais simples como a altura que o paciente conseguiu levantar o braço poderão ser exibidos em gráficos.
A abordagem de gerar eventos no sistema operacional permite que qualquer game desktop seja compatível com o projeto proposto sem a necessidade de modificação do seu código-fonte, desde que o game tenha sido desenvolvido para ser utilizado com teclado ou mouse. 4 Driver - Software que permite a utilização do dispositivo.
Ocasionalmente o paciente pode realizar movimentos incorretos, uma vez que
esteja em casa longe da supervisão do terapeuta. Para a realização adequada da terapia, a
aplicação deverá estimular o paciente a executar os movimentos da forma mais correta o
possível, medindo velocidade e postura, tais parâmetros deverão ser configuráveis pelo
terapeuta. Quando o movimento for executado com velocidade acima do normal ou
pondo em risco o seu equilíbrio, o cliente deverá exibir uma mensagem ao jogador,
informando que o movimento deve ser corrigido. Movimentos muito bruscos podem
prejudicar o tratamento [
Dispositivos como o Kinect e o Leap Motion fornecem um tipo de dado que possibilita uma interpretação mais rica, o dispositivo pode ser utilizado para um número maior de exercícios, sendo assim, além de ser requisitar um driver no servidor também se faz necessário uma classe para reconhecer gestos específicos do dispositivo. Este projeto contará com uma classe de reconhecimento para cada um desses dispositivos.
Para o reconhecimento de gestos será utilizada programação convencional, impossibilitando que novos gestos sejam inseridos de maneira simples. A gravação de novos gestos para reconhecimento requer aprendizado de máquina.
Um exemplo de gesto que estará presente na aplicação é a altura da mão. Esse gesto será utilizado em um game onde o jogador deve levantar a mão para capturar itens enquanto anda em um ambiente virtual através do movimento de marcha estacionária. A Figura 2 exemplifica uma versão inicial do game que será utilizado e o movimento de altura da mão, o terapeuta poderá configurar 5 alturas.
A altura da mão está relacionada à altura da cabeça. Com isso pretende-se facilitar a configuração, permitindo o uso sem precisar de calibração, ao mesmo tempo que espera-se reduzir qualquer possível confusão do jogador, ele saberá que se o item aparecer na altura da cabeça do personagem ele deverá elevar a mão até a altura da própria cabeça, da mesma forma se o item vier na altura do peito ou muito alto. Na Figura 2 temos do lado esquerdo a numeração para a altura desejada, essa numeração é utilizada no arquivo de configuração e do lado direito a altura em relação à cabeça, presumindo que a cabeça esteja na altura 1,0.
O game apresentado na Figura 2 será utilizado para tratamento de equilíbrio. O personagem irá seguir um caminho. E, ao longo do percurso, degraus irão aparecer. Para subir os degraus o paciente terá que subir em um step, degrau físico. Feito isso, a classe de reconhecimento do Kinect irá detectar uma variação no eixo Y da cabeça que por sua vez acionará o comando para subir o degrau no game. Figura 2 - Game para reabilitação de steps e Visualização dos dados gerados com a configuração das possíveis alturas.
Espera-se que o desenvolvimento de novos games e dispositivos avance mais rapidamente, já que não será necessário o desenvolvimento de um novo game para cada dispositivo, bem como será possível o desenvolvimento de games terapêuticos sem a necessidade de ter acesso aos dispositivos de entrada.
Apesar de poder utilizar jogos que inicialmente não foram desenvolvidos para gameterapia, a escolha desses games deverá ser cuidadosa, pois tais jogos podem frustrar o paciente, uma vez que sua dificuldade pode não ser projetada para as necessidades do paciente. O jogo pode acabar progredindo a dificuldade muito rapidamente ou solicitando que o paciente se mova muito rápido, podendo agravar o estado atual do paciente ou até causar um acidente. Ainda recomenda-se utilizar jogos inicialmente desenvolvidos para esse fim.
Sugestões para trabalhos futuros: Incluir a gravação de novos gestos para reabilitação em tempo de execução com aprendizado de máquina; a criação de um driver e um app para smartphone a fim de permitir a utilização dos dados gerados no dispositivo, tornando-o um joystick; utilização de óculos de realidade virtual para enviar e receber dados para a aplicação VR através do TeamBridge e a implementação de um fluxo contrário de dados para permitir o desenvolvimento de dispositivos hápticos5 ou dispositivos que gerem algum tipo de feedback para o usuário. 5 Dispositivos hápticos – Dispositivos que simulam o toque em um ambiente virtual realizando uma força contrária.