Integração de Linguagens de Programação para Uso de

X Symposium of Virtual and Augmented Reality
Integração de Linguagens de Programação para Uso de
Dispositivos Não-Convencionais: Possível Solução para
Construir Aplicações com Baixo Custo
Cléber Gimenez Corrêa, Fátima de L. S. Nunes, Adriano Bezerra
Centro Universitário Eurípides de Marília – UNIVEM
Laboratório de Aplicações de Informática em Saúde - LApIS
Marília, SP, Brasil
[email protected], [email protected], [email protected]
Abstract
This paper presents a detailed technical description
about the inclusion of non-conventional devices in
Virtual Reality (VR) applications, integrating
programming languages, as Java and C, aiming at
obtaining realism during the interaction in order to
ensure the quality of the training. Thus, it is possible
to integrate equipments, whose manufacturers offer
drivers in C language, to applications built in Java
language, contributing to the implementation of
projects using free technologies.
Keywords: Integration of languages, Medical
training, Nonconventional devices, Virtual Reality.
Resumo
Este artigo apresenta uma descrição técnica
detalhada sobre a inclusão de dispositivos
nãoconvencionais em aplicações de Realidade
Virtual (RV), integrando linguagens de programação,
como Java e C, visando à obtenção de realismo
durante a interação, para garantir a qualidade do
treinamento. Desta forma, é possível integrar
equipamentos, cujos fabricantes disponibilizam
drivers na linguagem C, a aplicações construídas em
linguagem Java, contribuindo para a implementação
de projetos utilizando tecnologias gratuitas.
Palavras-chave: Integração de linguagens,
Treinamento médico, Dispositivos nãoconvencionais, Realidade Virtual.
1. Introdução
Em aplicações de RV, principalmente aquelas voltadas
ao treinamento médico, é desejável, entre outras
características, precisão e respostas em tempo real, para
que a interação torne-se mais próxima da ação realizada
em situações reais [1].
Neste contexto, as exigências para imprimir realidade
aos treinamentos tornam indispensáveis a inclusão de
dispositivos de entrada e saída, responsáveis pela
comunicação entre o usuário e o sistema
computacional, classificados geralmente em
convencionais (teclado, mouse, entre outros), e nãoconvencionais (luva de dados, equipamento háptico,
entre outros). Estes últimos podem permitir um maior
grau de realismo durante a interação. Como exemplo
desse realismo, pode ser citada a luva de dados, pois
segundo [2], o reconhecimento de gesto é uma forma
de interação eficiente e altamente intuitiva para
Ambientes Virtuais (AVs).
Estes dispositivos geralmente possuem drivers e
bibliotecas com funções prontas, implementadas pelos
fabricantes, que, em geral utilizam linguagens de
programação com funções em baixo nível. Entretanto,
percebe-se que diversos projetos de RV estão sendo
construídos em linguagens de mais alto nível, como a
linguagem Java, com a finalidade de aproveitar
características intrínsecas dessas ferramentas, como
gratuidade, disponibilização de classes diversas para a
criação e manipulação de AVs, que contribuem para o
baixo custo e o aumento de produtividade,
respectivamente, durante o projeto, implementação e
documentação do software.
O ViMeT (Virtual Medical Training) é um exemplo de
aplicação que utiliza tecnologia Java, consistindo em um
framework para geração de aplicações voltadas ao
treinamento médico, fornecendo funcionalidades como:
deformação, criação dinâmica de AVs, detecção de
colisão, estereoscopia e interação por meio de diversos
tipos de dispositivos [3].
Para viabilizar a integração de dispositivos nãoconvencionais em aplicações implementadas em
linguagem Java, quando o fabricante não disponibiliza
drivers nesta linguagem, duas estratégias são possíveis:
construção de drivers próprios, ou integração de
linguagens de programação, possibilitando o uso do
driver fornecido pelo fabricante. A primeira abordagem
envolve alguns problemas, como a necessidade de
abranger diversos tipos de portas de entrada para
conexão dos equipamentos, programação em baixo
nível, tempo de resposta e grande quantidade de tempo
266
X Symposium of Virtual and Augmented Reality
dedicada ao desenvolvimento e aos testes, que poderia
ser empregada no aperfeiçoamento da aplicação. A
segunda abordagem elimina alguns desses problemas e,
adicionalmente, permite a utilização de um driver que já
foi especificamente desenvolvido pelo fabricante, sendo
devidamente testado e aprovado para uso.
No entanto, a adoção da segunda abordagem exige
também o domínio da programação das linguagens
envolvidas e uma pesquisa intensa sobre
funcionalidades de ambas, a fim de que a integração
omita detalhes técnicos do usuário final e, ao mesmo
tempo, proporcione uma interação adequada.
Entretanto, na literatura da área, este assunto é escasso,
motivo pelo qual este artigo é apresentado tendo o
objetivo de auxiliar desenvolvedores a realizar tal tarefa,
oferecendo detalhes que podem ser úteis na solução de
problemas encontrados durante a implementação.
2. Metodologia
No presente trabalho, dois dispositivos nãoconvencionais estão sendo utilizados. O primeiro é uma
luva de dados 5DT DataGlove 5 Ultra, fabricada pela
5DT (Fifth Dimension Technologies), e que possui cinco
sensores para captar a flexão dos dedos, conforme a
Figura 1a [4].
(a)
(b)
Figura 1. (a) DataGlove 5 Ultra e (b) Phantom Omni [5]
O Ambiente Virtual (AV) gerado com o auxílio do
framework já existente, (Figura 2), é constituído por três
objetos: um instrumento médico, um órgão humano e
uma mão virtual. Definiu-se que a luva representa a
ação de segurar e soltar o objeto que simula o órgão
durante o exame de punção.
O segundo dispositivo é um equipamento háptico
Phantom Omni, desenvolvido pela SensAble Technologies e
apresentado na Figura 1b, o qual permite um retorno
de força, e detecta informações de rotação e translação
nos três eixos [5]. No AV, o dispositivo háptico está
relacionado com o instrumento médico utilizado para
simular a coleta de material em um exame de biópsia.
As informações captadas por estes dispositivos devem
ser transferidas para a aplicação e determinar o
comportamento de objetos no AV. No caso da luva de
dados, os movimentos resultam em alterações na mão
virtual, e a posição dos dedos é modificada. Já no caso
do dispositivo háptico, os movimentos são
reproduzidos pelo instrumento médico virtual. A força
aplicada também é calculada pela aplicação e, quando é
detectada uma colisão entre os objetos que representam
o instrumento médico e o órgão humano, uma
deformação deste último é gerada.
Para integrar os recursos provenientes das linguagens
de programação C e Java, foi utilizada uma interface de
programação nativa, denominada de JNI (Java Native
Interface), que permite a interoperação entre o código
Java e bibliotecas e programas desenvolvidos em outras
linguagens, como C, C++, Assembly [6]. Para isso, a
linguagem Java utiliza os arquivos jni.h e jni_md.h,
sendo que o primeiro deve ser incluído no cabeçalho
do programa em C e é também utilizado no arquivo de
cabeçalho a ser gerado.
Para se trabalhar com métodos nativos, deve-se colocar
a palavra-chave native na definição dos métodos da
classe em Java, indicando à máquina virtual que estes
métodos serão executados em uma outra linguagem
(código nativo). Além disso, deve estar presente o
método System.loadLibrary, que recebe como parâmetro
a biblioteca de ligação a ser gerada, no caso de sistemas
operacionais Windows, as denominadas DLLs
(Dynamic-Link Libraries) [6].
A Figura 3 apresenta parte do código implementado,
com a palavra-chave native indicando que o método
“NomeMetodo” será executado em outra linguagem, a
palavra “ArquivoDLL” representa a biblioteca de
ligação a ser carregada e a nomenclatura short[] indica
que um vetor do tipo short será retornado.
public class ClasseNativa {
public native short[] NomeMetodo();
static
{
System.loadLibrary(“ArquivoDLL”);
}
…
Figura 3. Código exemplo de uma classe.
Figura 2. Aplicação gerada.
267
X Symposium of Virtual and Augmented Reality
Em seguida, é necessário gerar um arquivo de
cabeçalho com a extensão .h, o que pode ser realizado
com o uso da ferramenta javah, que acompanha o JDK
(Java Development Kit) [6], a partir do arquivo .class, criado
na compilação da classe [5]. Pode-se notar a assinatura
do método em código nativo, presente no arquivo de
cabeçalho (Figura 4), e no programa em C (Figura 5),
que contém o prefixo Java, o nome do pacote, o nome
da classe, e o nome do método, separados por underline.
/*DO NOT EDIT THIS FILE – it is machine
generated*/
#include <jni.h>
/*Header for class Pacote_ClasseNativa*/
#ifndef_Included_Pacote_ClasseNativa
#define_Included_Pacote_ClasseNativa
#ifdef__cplusplus
extern “C” {
#endif
/*
*Class:
Pacote_ClasseNativa
*Method:
NomeMetodo
*Signature: ()[S
*/
JNIEXPORT jshortArray JNICALL
Java_Pacote_ClasseNativa_NomeMetodo
(JNIEnv*, jobject);
#ifdef__cplusplus
}
#endif
#endif
Figura 4. Exemplo de arquivo de cabeçalho.
As strings JNIEXPORT e JNICALL, definidas no
arquivo jni.h, são usadas para especificar as chamadas e
as ligações entre os métodos JNI e as funções nativas.
JNIEnv é o ponteiro da interface JNI, que aponta para
uma matriz de ponteiros, que por sua vez apontam para
as funções JNI. O tipo jobject indica que um método
não-estático está sendo usado, e este obtém uma
referência para o objeto, como um argumento this
implícito.
Os tipos de dados e arrays da linguagem Java possuem
tipos correspondentes na linguagem C. No exemplo, o
tipo Java short[] corresponde ao tipo C jshortArray,
indicando um vetor do tipo short [7]. Em seguida, o
programa em linguagem C é elaborado contendo as
funções que serão chamadas pelos métodos escritos em
Java. No cabeçalho deste programa devem ser
invocados os arquivos de cabeçalho e jni.h, que serão
utilizados pelo compilador para gerar a biblioteca.
E assim, por último é preciso gerar uma biblioteca de
ligação, procedimento realizado com o auxílio de
compiladores [6], tais como: Microsoft Visual C++,
Borland C++ Compiler, Bloodshed Dev-C++, sendo que os
dois últimos são disponibilizados gratuitamente.
#include <jni.h>
#include “NativeGlove.h”
…
JNIEXPORT jshortArray JNICALL
Java_Pacote_ClasseNativa_NomeMetodo
(JNIEnv *env, jobject obj)
{
//Função para obter valores dos
sensores
}
Figura 5. Exemplo de código nativo.
3. Resultados
Os procedimentos da seção anterior foram seguidos
para realizar a integração entre a aplicação codificada
em Java e um programa em C com funções fornecidas
pelo fabricante da luva de dados, as quais permitem
iniciar e terminar a conexão com a luva, além de
capturar valores dos sensores.
Desta forma, construiu-se a classe denominada
NativeGlove, composta de métodos para acessar as
funções do código nativo escrito em C, e o método
especial System.loadLibrary para carregar a biblioteca de
ligação, no caso, o arquivo 5DTGlove.dll. Em seguida,
gerou-se um arquivo de cabeçalho (NativeGlove.h), e um
programa com funções em C foi desenvolvido para
acessar a luva de dados. Um compilador é necessário
com o objetivo de gerar a DLL no ambiente Windows
XP. Optou-se pelo aplicativo Microsoft Visual C++ 6.0
para testes iniciais por uma questão de familiaridade
com o aplicativo; entretanto, o intuito é utilizar
compiladores gratuitos. Os valores dos sensores são
enviados para a aplicação, e os dedos da mão virtual se
movem de acordo com os movimentos do usuário e
são apresentados no monitor e vídeo. O diagrama da
Figura 6 define a interação do usuário com o sistema, a
qual ocorre por meio da luva de dados e de um monitor
comum, e a integração entre as linguagens C (Funções
da luva de dados), e Java (Geração da aplicação a partir
do framework), bem como o arquivo 5DTGlove.dll, que é
a biblioteca de ligação.
Os procedimentos para a integração da luva de dados
foram realizados também com o dispositivo háptico.
No entanto, funções de retorno de força e de obtenção
informações de translação e rotação deverão ainda ser
implementadas a fim de obter-se uma avaliação mais
adequada. A Figura 7 apresenta os movimentos do
objeto mão no AV em momentos distintos, conforme a
flexão dos dedos do usuário.
268
X Symposium of Virtual and Augmented Reality
Computador
comprometer o treinamento.
Aplicação gerada
Linguage Java e
Java 3D
5DTGlove.dll
Biblioteca de Ligação
Usuário
A opinião de médicos e estudantes da área também será
coletada, levando em consideração a experiência com
equipamentos de RV e procedimentos de biópsia,
facilidade de uso e conforto com os dispositivos, e uso
da intuição durante a interação.
5. Referências
[1] F. L. S. Nunes et al., “Aplicações Médicas usando
Realidade Virtual e Realidade Aumentada”, In Livro do
9º SVR, Petrópolis, RJ, Brasil, 2007, pp. 234-235.
Bibliotecas do
Fabricante
Linguagem C
[2] J. Eisenstein et al., “Device Independence and
Extensibility in Gesture Recognition”, In Proceedings of
the IEEE Virtual Reality, 2003, pp.207-214.
Figura 6. Diagrama de interação e integração.
[3] A. C. M. T. G. Oliveira et al. “Virtual Reality
Framework for Medical Training: Implementation of a
deformation class using Java”. In Proceedings of ACM
Siggraph International Conference on Virtual Reality
and its applications in industry, Hong Kong, Nova York:
ACM Press, 2006, pp. 347-351.
[4] 5DT - Fifth Dimension Technologies, Disponível
em: http://www.5dt.com/hardware.html, Acesso em:
Março 2007.
Figura 7. Movimentos da mão virtual.
[5] SensAble Technologies. Disponível em:
http://www.sensable.com, Acesso em: Março 2007.
4. Conclusão e discussões
Este artigo apresentou uma forma de integrar a
aplicações escritas em Java, dispositivos cujos drivers são
disponibilizados em linguagem C. Seguindo os passos
aqui descritos, é possível a adição de tais equipamentos
de forma prática e sem permuta de tecnologias.
Verifica-se que esta forma de integração pode ser
generalizada, considerando a portabilidade da
linguagem Java, e pode contemplar, inclusive, drivers
fornecidos para outros Sistemas Operacionais.
[6] G. Cornell, C. S. Horstmann. “Métodos Nativos”.
Core Java 2, Volume II, Recursos Avançados. Pearson
Education do Brasil, São Paulo, 2003, pp. 755-785.
[7] JNI, “Java Native Interface Specification”,
Disponível em:
http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/jniTO
C.html, Acesso em: Março 2007.
Além do realismo proporcionado pelo uso desses
dispositivos em aplicações de treinamento médico,
salienta-se que é possível atender as necessidades do
usuário sem demandar tempo do projeto para a
implementação de novos drivers, e ainda manter o custo
reduzido, visto que a aquisição de equipamentos nãoconvencionais, por si só já representa uma elevação no
custo de aplicações.
Até o presente momento, o tempo de resposta da
aplicação está em um nível satisfatório, mensurado
empiricamente, isto é, o usuário não percebe atrasos
nas respostas às interações, mesmo com a integração
entre as linguagens. Entretanto, uma avaliação com
protocolo mais adequado será realizada para mensurar
este tempo de resposta e a quantidade de quadros por
segundo, e conseqüentemente, avaliar o desempenho da
aplicação, pois a interação não pode ser prejudicada e
269