DESENVOLVIMENTO DE UMA ARQUITETURA PARA DISTRIBUIÇÃO DE REALIDADE AUMENTADA NA WEB APLICADA AO ENSINO DE MOTORES DE CORRENTE CONTÍNUA Marlus Dias Silva, Eduardo de Souza Santos, Renato Oliveira Abreu Alexandre Cardoso, Edgard Lamounier Universidade Federal de Uberlândia, Uberlândia, MG, Brasil {marlusdias, eduardo}@mestrado.ufu.br, renato.abreu.info@gmail.com, {alexandre, lamounier}@ufu.br Abstract This work deals with the development of an architecture for distribution of Augmented Reality by Web. One of the great advantages of this architecture is the ability to run the application directly into a Web browser through the use of Flartoolkit, Paperpervision3D, and Flash Player for running applications created with Flex 4.0 environment. The validation of the work was done through a case study, which was used in the developed environment for the teaching of DC motors. From this case study, we obtained the evaluation of students and professionals in education, and data for analyzing the performance of the developed architecture. 1 Introdução Com o advento da Educação a Distância (EaD), a necessidade de prover ambientes que facilitem o aprendizado se mostra ainda mais importante, já que alunos dessa modalidade de aprendizado possuem poucas ferramentas que possam estimular a experimentação, dificultando seu aprendizado e, portanto, causando defasagens em relação à educação de um aluno da modalidade presencial [12]. Observa-se que a utilização da Realidade Aumentada (RA), que é definida como uma fusão entre o mundo real e objetos virtuais, criando um cenário no qual as informações contidas no mundo real são incrementadas com objetos virtuais gerados por computador [2], pode oferecer informações sensitivas mais ricas, facilitando a associação e a reflexão sobre o tema que está sendo ensinado [8], possibilitando que o usuário possa lidar de forma mais confortável com conceitos abstratos e contra-intuitivos [9]. Segundo [13], um sistema distribuído é uma coleção de computadores independentes que se apresentam aos usuários como um sistema único e coerente. Levando este conceito para o âmbito da Realidade Aumentada, observa-se que distribuir um ambiente que implemente aplicações de RA se torna muito interessante à medida que usuários em diversas posições geográficas podem interagir, em tempo real, com uma interface mais intuitiva e que favorece a colaboração, facilitando de forma expressiva o aprendizado. Dessa forma, é de suma importância buscar tecnologias que permitam a distribuição de ambientes virtuais, que estejam alinhadas com as atuais necessidades tecnológicas. Nesse âmbito, pode-se destacar as aplicações desenvolvidas no ambiente Flex 3.0, que tem evoluido de forma muito rápida e com uma ótima aceitação tanto por desenvolvedores quanto no mercado consumidor. O lançamento do ActionScript 3.0 (AS3), juntamente com o ambiente de desenvolvimento Flex e o Flash Player 9.0, pela Adobe em 2006, abriu caminho para a evolução das aplicações RIA (Rich Internet Applications - Aplicações Ricas em Internet). O desenvolvimento dessas aplicações possibilitou a criação de ferramentas de apoio para a criação de aplicações de Realidade Virtual (RV) para a web, suportadas pelo Flash Player. Como passo seguinte, a extensão destas tecnologias proveu condições de desenvolvimento de soluções de Realidade Aumentada (RA) para web, com a utilização de uma webcam e marcadores (impressos em papel comum) e da tecnologia FLARToolkit. Neste contexto, este trabalho tem como objetivo mostrar uma arquitetura de distribuição de objetos com de Realidade Aumentada (RA) na web, permitindo que vários usuários, conectados a um servidor, possam interagir com o mesmo objeto virtual que no caso específico é um motor de corrente contínua. Além da possibilidade de criar aplicações de RA na web, o ambiente de desenvolvimento Flex 4.0 oportuniza a utilização das aplicações desenvolvidas em qualquer plataforma, sendo transparente para o usuário, já que não se necessita da instalação da aplicação. Logo, essa aplicação utiliza tal ambiente para o desenvolvimento do front-end,
possibilitando que o aluno/professor, utilize as aplicações em qualquer navegador que possua o plugin Flash Player com a versão 9 ou superior instalado, permitindo sua utilização em sistemas operacionais Windows, Linux, Solaris ou Macintosh. Além da vasta gama de sistemas operacionais, observa-se que o Flash Player 9, possui uma taxa de utilização de aproximadamente 99% nos computadores dos mercados maduros (Estados Unidos, Reino Unido, Alemanha, França e Japão) e cerca de 97% nos mercados emergentes [1]. Com o intuito de abordar o desenvolvimento e utilização da arquitetura desenvolvida, este trabalho será dividido da seguinte forma: a seção 2, trata dos trabalhos correlatos, mostrando a importância da utilização de RV e RA na educação, bem como ferramentas de distribuição dessas tecnologias. A terceira seção relata as ferramentas utilizadas no desenvolvimento da arquitetura proposta. A seção número 4, mostra as definições da arquitetura proposta. A Seção número 5 aborda o estudo de caso proposto, por fim, na sexta sessão são mostrados os resultados e perspectivas para trabalhos futuros. 2 Trabalhos Relacionados Devido às possibilidades de aplicação no ensino, a distribuição de objetos virtuais para ambientes de Realidade Aumentada, tem sido bastante explorada. O trabalho de [6], por exemplo, apresenta uma interface para a distribuição de objetos virtuais utilizando realidade aumentada como ferramenta de apoio de ensino na área fisiologia vegetal. A arquitetura utilizada foi cliente/servidor utilizando o CORBA(Common Object Request Broker Architecture) para a comunicação entre os clientes que executam o AR- Toolkit. Em [8] uma ferramenta de distribuição de ambientes virtuais para apoio a projetos multidisciplinares de ensino. Foram desenvolvidos dois protótipos: um na na área biológica e outro na área de química. Para a distribuição foi utilizado o CORBA, utilizando arquitetura cliente/servidor. No trabalho de Distribuição de Realidade Virtual e Aumentada [10], os autores desenvolveram uma arquitetura que viabiliza a distribuição de objetos virtuais no formato VRML, para todos os participantes através de uma rede de computador, utilizando sockets para a transferência de arquivos. O software desenvolvido por [10] tem um grande apelo educacional possibilitando os usuários visualizarem os objetos virtuais tanto em RA como em RV. De forma semelhante aos trabalhos citados, este trabalho utiliza a arquitetura cliente/servidor, no entanto, com a utilização de tecnologias diferentes, visto que deseja-se distribuir o ambiente de Realidade Aumentada, utilizando o ambiente de desenvolvimento Flex, permitindo que os clientes possam utilizar a ferramenta desenvolvida de forma transparente, necessitando somente de uma webcam e um navegador com o Flash Player instalado. 3 Ferramentas utilizadas As ferramentas utilizadas para o desenvolvimento da arquitetura são apresentados nas seções abaixo : 3.1 Engine 3D Atualmente existem diversas engines para desenvolvimentos de ambientes 3Ds em AS3, como Away3D, Papervision3D e Sandy, logo, é de suma importância definir qual desses conjuntos de bibliotecas serão utilizados no projeto, visto que, dependendo do tipo de aplicação que será desenvolvida, a má escolha da engine pode causar um desempenho ruim do sistema como um todo. Por este motivo, baseado no grau de atividade e avaliação das engines pelos desenvolvedores, optou-se por utilizar o Papervision3D, que surgiu em 2005 e, desde então, vem sendo atualizado pelos desenvolvedores e pela vasta comunidade de utilizadores. Essa engine possui um conjunto de classes que possibilita o tratamento de colisão de forma automatizada, engines para a simulação de física (simulação de fluídos e partículas) possibilitando gerar mundos virtuais com uma maior riqueza de detalhes, aproveitando todos os benefícios da Orientação a Objetos. E, além disso, torna possível a importação de objetos modelados em ambientes de modelagem 3D, como Blender e 3D Studio Max, e exportados nos formatos Collada (COLLAborative Designer Activity), MD2(Quake 2) e 3DS(3D Studio). Outro ponto de destaque, consiste na integração com outra biblioteca AS3, chamada FLARToolkit, que é semelhante ao ARToolkit e, portanto, possibilita o desenvolvimento de aplicações de Realidade Aumentada pela web. 3.2 FLARToolkit O FLARToolkit é um conjunto de classes desenvolvidas em AS3, que juntamente com o Papervision3D possibilita o desenvolvimento de aplicações de Realidade Aumentada. Para executar aplicações utilizando o FLARToolkit o cliente deve instalar no navegador o Flash Player versão 9 ou superior, e permitir o acesso do plugin à webcam. O ARToolKit é uma biblioteca em linguagem C que permite aos programadores desenvolver aplicações de Realidade Aumentada [4]. Desta forma, para executar aplicações utilizando o ARToolkit o usuário deverá ter instalado e configurado o mesmo em seu computador, podendo causar algum desgaste para usuários menos experientes. Em contrapartida, uma aplicação que utiliza o FLARToolkit será
disponibilizada como um arquivo.swf, que é executado no Flash Player do navegador web. 3.3 BlazeDS O BlazeDS é um middleware que se localiza entre o cliente e o servidor, ele é responsável por estabelecer a comunicação entre ambos, utilizando para isso objetos remotos. A aplicação cliente pode ser desenvolvida em linguagem de programação Flex/Flash(Action Script 3) ou Ajax e o servidor obrigatoriamente tem que ser desenvolvido na linguagem de programação Java [3]. Através das chamadas de procedimento remota RCP, o desenvolvedor fica responsável em codificar as interfaces remotas, e o BlazeDS realiza a comunicação entre o cliente e o servidor utilizando seus protocolos Logo, o BlazeDS foi escolhido por possibilitar a utilização com aplicações desenvolvidas em Flex e suportar as vantagens oferecidas por RCP. 4 Arquitetura do sistema O propósito dessa seção é a apresentação de uma arquitetura de Realidade Aumentada que viabilize a interconexão com uma gama de computadores por meio da Internet, possibilitando a interação e a distribuição de objetos virtuais em tempo real, com os computadores conectados no sistema. Para tal efeito, a arquitetura foi montada baseada no modelo Cliente/Servidor como mostra a Figura 1. BlazeDS Client Camada de Comunicação FLARToolkit Web browser Cliente 1 Servidor Web Glassfish BlazeDS Server Internet TCP/IP BlazeDS Client Camada de Comunicação FLARToolkit Web browser Cliente 22... BlazeDS Client Camada de Comunicação FLARToolkit Web browser Cliente n3 Figura 1. Arquitetura do Sistema Proposto. A arquitetura foi desenvolvida utilizando várias camadas de software, tanto no lado do cliente quanto do lado do servidor, com o propósito de facilitar a manutenibilidade do software em questão, possibilitando que desenvolvedor no caso de uma manutenção, necessite apenas de modificar a camada de seu interesse, não havendo risco de inserir códigos defeituosos nas demais camadas da arquitetura. Para a comunicação entre os módulos a arquitetura utiliza à Internet e seus protocolos. No caso do software em questão será utilizando o protocolo TCP/IP para a comunicação entre os módulos cliente e servidor, e seus respectivos usuários conectados na aplicação. 4.1 Módulo Servidor O Módulo Servidor (Figura 2), tem como finalidade gerenciar as conexões dos clientes e possibilitar a distribuição dos objetos virtuais no Ambiente de Realidade Aumentada dos clientes. Outra característica do servidor é possibilitar a sincronização das animações executadas pelos clientes através de um protocolo. Módulo Servidor Servidor Web (GlassFish) JAVA JAVA Action Script 3 BlazeDs Server Internet TCP/IP Figura 2. Arquitetura do Módulo Servidor. Para que o Módulo Servidor consiga enviar, processar e receber informações do cliente o mesmo é dividido em duas camadas: a camada do BlazeDS e a camada do Servidor Web. A camada onde está localizado o BlazeDS Server como pode ser observado na Figura 2 é responsável por receber os dados enviados pelos os clientes na linguagem de programação Action Script. Em seguida ela deve converter para a linguagem de programação JAVA e repassar para o servidor Web GlassFish, onde as mensagens recebidas serão processadas. O servidor Web GlassFish recebe as mensagens na linguagem de programação JAVA, as processa e envia a resposta para a Camada do BlazeDS, onde essa é convertida em ActionScript e enviada aos clientes por intermédio da Internet. 4.2 Módulo Cliente O Módulo cliente possuí várias camadas de software na Arquitetura Proposta como é mostrado na Figura 1, tais camadas são descritas abaixo: A camada do Web browser, é a camada de visão da arquitetura do lado do cliente. Essa camada possibilita ao usuário visualizar o ambiente de Realidade Aumentada. Todas
as ações e interações do usuário com o Ambiente de Realidade Aumentada são repassadas para a camada abaixo do FLARToolkit. A camada onde está localizado o FLARToolkit é a responsável por possibilitar o desenvolvimento de aplicações de Realidade Aumentada. Algumas partes do código original da biblioteca foram modificados para viabilizar a comunicação dessa camada com as demais camadas do sistema. A camada de comunicação é responsável por receber as interações realizadas pela camada do FLARToolkit, processá-las e encaminha-las para a camada do BlazeDs Client. Ela também é responsável por fazer o sentido inverso: ao receber uma mensagem da camada BlazeDS, processar a mensagem recebida e aplicar as alterações cabíveis e repassar para a camada do FLARToolkit. A camada de distribuição BlazeDS Client é uma camada de software responsável pela comunicação entre os módulos cliente e servidor. Os eventos recebidos pela camada do FLARToolkit são enviados para o servidor através da Internet, onde as mesmas serão processadas no lado do servidor e reenviadas para os clientes. As mensagens recebidas são repassadas para a camada o FLARToolkit que é responsável por posicionar/adicionar objetos virtuais na cena. 5 Estudo de Caso Um motor de corrente contínua converte a energia elétrica em energia mecânica, o que o diferencia dos demais motores é que ele deve ser alimentado com corrente de tensão contínua. Essa tensão contínua pode ser adquirida através de pilhas e baterias, no caso de motores pequenos, ou de uma rede alternada após retificação, no caso de motores maiores. Os principais componentes de um motor de corrente contínua são o estator e rotor [14]. Para o estudo de caso, foi desenvolvido no ambiente Flex uma interface gráfica (Figura 3) para avaliar a arquitetura apresentada. Juntamente com o software RANET, que implementa a arquitetura proposta, é possibilitado aos usuários interagir com o objeto virtual presente na cena. Desta forma, todas as ações realizadas pelo usuários através dos menus interativos serão repassadas para todos os usuários conectados ao sistema. Dessa forma, o usuário pode inserir um motor de corrente contínua virtual sobre o marcador, possibilitando a interação dentro de uma gama de ações pré-definidas. No estudo de caso do motor de corrente contínua foram definidas algumas animações de interesse para a aula, as quais foram modeladas em um editor 3D. Essas animações simulam o funcionamento do motor com 3, 6 e 9 volts. É possível visualizar e separar as peças com o motor em funcionamento como mostra a Figura 3b. Visando a utilização de objetos virtuais gerados em qualquer modelador 3D, como o Blender, 3DS MAX e Maya, (a) Motor Fechado. (b) Motor aberto. Figura 3. Interface gráfica do RANET. foi necessário definir algumas regras na criação das animações, a principal, consiste em obedecer uma linha tempo pré-definida, conforme é mostrado na a Tabela 1. Com a criação da animação, o objeto virtual deverá ser exportado para o formado Collada (dae) e adicionado no software (RANET). Tabela 1. Regras definidas para a linha do tempo das animações. Faixa de Tempo Descrição 80 Faixa destinada a primeira animação 160 Faixa destinada a segunda animação 240 Faixa destinada a terceira animação 320 Faixa destinada a quarta animação 400 Faixa destinada a quinta animação 6 Conclusões e Trabalhos Futuros Foram realizados testes de latência e escalabilidade para validar a eficiência da arquitetura desenvolvida. Para a verificação e validação do software RANET foi elaborado, um questionário baseado nos preceitos da ISO- NORM 9241/10 que trata da usabilidade de software [11]. Este questionário foi elaborado no formato de um checklist onde os usuários puderam informar suas opiniões. 6.1 Latência Segundo [5] latência é o tempo decorrido após uma operação de envio ser executada e antes que os dados comecem a chegar em seu destino. Ela pode ser medida como o tempo necessário para transferir uma mensagem. No caso do experimento foi utilizados pacotes de 4 bytes. Segundo [7] se o ambiente distribuído existe para emular o mundo real, deve operar em termos da percepção humana. Este desafio torna-se maior em sistemas que utilizam redes a longa distância.
Dessa forma a latência na comunicação não será o parâmetro principal de análise de desempenho do modelo proposto, mas servirá como suporte para analisar a escalabilidade (capacidade de aumento na quantidade de usuários). Logo, a análise de escalabilidade foi realizada em três etapas: Primeira etapa: foi feito um teste para medir o tempo que o pacote enviado pelo cliente demora para chegar até o servidor; Segunda etapa: utilizou-se o servidor e 3 clientes, medindo o tempo de envio do pacote de um cliente para o servidor e do servidor para outro cliente; Terceira etapa: utilizou-se o servidor e 6 clientes, medindo o tempo de envio do pacote de um cliente para o servidor e do servidor para outro cliente; Figura 5. Escalabilidade. em seis clientes. A escalabilidade foi testada, aumentando esta quantidade para 12, 18, 24 e 30 clientes, respectivamente. O Resultado obtido pode ser observador através da Figura 5. Como pode ser observado a latência do sistema com 30 usuários atingiu o patamar de 1,5 segundos, não afetando o desempenho do software em termos de usabilidade e qualidade da visualização. 6.3 Testes de Usabilidade Figura 4. Latência de Comunicação. A Figura 4 mostra os resultados obtidos. Como pode ser observado o protótipo se comportou satisfatoriamente com a quantidade de usuários à que foi submetido. Para o teste de escalabilidade será utilizado os valores obtidos no teste de latência. O sistema foi apresentado a 35 alunos do ensino médio (tecnológico) e a 5 professores ambos da área de informática. Foi explicado a esses usuários qual a finalidade do sistema. Logo após foram separados 4 grupos. Cada grupo era composto por 10 usuários, sendo um tutor e 9 alunos. Após a realização do experimento todos responderam a um questionário de avaliação do sistema. A seguir, são apresentados alguns resultados relevantes dessa avaliação. 6.3.1 Quanto à finalidade do uso da ferramenta 6.2 Escalabilidade A escalabilidade é interpretada como sendo a capacidade do sistema em aceitar novos clientes, numa mesma máquina ou em máquinas diferentes [7]. Segundo [7] sistemas que envolvem operadores humanos devem entregar pacotes com a mínima latência e gerar gráficos texturizados 3D a uma freqüência de 30 a 60 Hz, para garantir a ilusão de realidade. Este desafio torna-se maior em sistemas que utilizam redes a longa distância, conforme mencionado anteriormente. A latência da rede pode ser reduzida, até certo ponto, por meio da utilização de enlaces (links) dedicados. Todavia, uma maior largura de banda não é necessariamente a melhor solução. A escalabilidade foi medida em função do resultado da análise de latência na seção 6.1, levando-se em conta a degradação do tempo de comunicação com o aumento do número de clientes. Os testes iniciais foram feitos com base Figura 6. Gráfico: Finalidade da Ferramenta. Como pode ser notado no gráfico da Figura 6 observa-se que a maioria das pessoas consideraram-se satisfeita com o sistema. Porem algumas pessoas ressaltaram que para operar o software, as pessoas necessitam de certo conhecimento de informática.
6.3.2 Quando à colaboração entre os usuários é perceptível o software RANET possui um grande apelo pedagógico sendo uma ferramenta de grande auxilio na área da ciência e educação. 7 Trabalhos Futuros Como trabalhos futuros pode-se integrar ao módulo do cliente comandos de voz para que as animações sejam executadas através de comandos sonoros. E adaptar o software para que o mesmo aceite múltiplos objetos virtuais na cena. Figura 7. Gráfico: Colaboração entre Usuários. No gráfico da Figura 7 observa-se que a maioria dos usuários avaliaram a colaboração entre os usuários perceptível, ficando muito satisfeito com o protótipo. Porém alguns usuários comentaram que o software poderia suportar mais objetos virtuais na cena. Tal procedimento será sugerido como trabalho futuro. Outra sugestão foi a possibilidade de implementar uma trava com o objetivo de forcar aos usuários que não estão com a trava, apenas assistirem a distribuição, o que possibilitaria o uso do protótipo como uma ferramenta interessante no caso de educação à distância. Alguns usuários mostraram-se insatisfeitos porém não justificaram suas respostas. 6.3.3 Quanto à aprendizagem (houve aquisição de conhecimento?) O gráfico da Figura 8 demostra que a maior parte dos usuários ficaram muito satisfeitos com a questão da aprendizagem, que o estudo de caso através do software RANET proporcionou. Porém alguns professores da área de informática, comentaram que o software poderia além do controle da animação, e a possibilita de alterar o objeto virtual visualizado na cena o software poderia possibilitar a inserção de vários objetos virtuais na cena. Figura 8. Gráfico: Aquisição de Conhecimento. Através dos gráficos apresentados, pode-se concluir que Referências [1] Adobe. Flash player penetration, 2009. Disponível em: <http://www.adobe.com/products/player_census/ flashplayer/>. Acesso em: 13 agosto. 2009. [2] R. T. Azuma. Recent advances in augmented reality. IEEE Computer Graphics and Applications, 21:34 47, 2001. [3] BlazeDS. Blazeds developer guide. Disponível em:http://livedocs.adobe.com/blazeds/1/blazeds_devguide/ Acesso em: 15 mar. 2010, 2010. [4] A. Cardoso and L. Jr. Realidade Virtual: Uma Abordagem Prática. SVR, 2004. [5] G. Coulouris. Distributed systems: concepts and design. Addison-Wesley Longman, 2005. [6] W. A. da Silva. Uma arquitetura para distribuição de ambientes virtuais de realidade aumentada. Master s thesis, Universidade Federal de Uberlândia, 2008. [7] M. W. de Souza Ribeiro. Arquitetura para Distribuição de Ambientes Virtuais Multidisciplinares. PhD thesis, Universidade Federal de Uberlândia, 2006. [8] M. W. de Souza Ribeiro. Arquitetura para distribuição de ambientes vituais multidisciplinares. PhD thesis, Universidade Federal de Uberlândia, 2006. [9] C. Filhoais and J. Trindade. Física no computador: O computador como uma ferramenta no ensino e na aprendizagem das ciências físicas. Revista Brasileira de Ensino de Física, 25, 2003. [10] K. Nogueira, K. Nogueira, E. Lamounier, and A. Cardoso. Uma arquitetura para a distribuição de realidade virtual e aumentada. 6 o Workshop de Realidade Virtual e Aumentada, 2009. [11] J. Prümper. Test it: ISONORM 9241/10. In Proceedings of HCI International (the 8th International Conference on Human-Computer Interaction) on Human-Computer Interaction: Ergonomics and User Interfaces-Volume I-Volume I, page 1032. L. Erlbaum Associates Inc., 1999. [12] L. F. Silva. Ambientes distribuídos em Realidade Virtual como suporte a Aprendizagem Cooperativa para a Resulução de Problemas. PhD thesis, Universidade Federal de Uberlândia, 2009. [13] A. TANENBAUM and M. Steen. Sistemas Distribuídos: Princípios e Paradigmas, 2008. [14] P. TÉCNICA. MOTORES DE COR- RENTE CONTÍNUA. Disponível em: www.siemens.com.br/medias/files/2910_2006050514190 8.pdf Acesso em: 14 mar. 2010.