Proposta de Modelo de Representação de Informações para Navegadores de Realidade Aumentada Jessica Oliveira de Souza, Leonardo Castro Botega Computing and Information Systems Research Lab Centro Universitário Eurípides de Marília - UNIVEM Avenida Hygino Muzy Filho, 529 - Marília – SP
[email protected],
[email protected]
ABSTRACT The evolution of mobile devices and their sensors has been allowing a bright scenario to the development of innovative applications for several domains such as geolocalization and navigation. The produced data by the sensors generally combined with information provided by webservices are used as reference for the information provisioning for such applications, which if poorly specified conduct to an interface cluttering and the degradation of the interactive process. Hence, this work aims to present a proposal of standardization of mobile navigation applications by the creation of a representation model for the displayed information, allowing a richer and customizable on-thefly experience in Augmented Reality Browsers (ARB). First of all, it is presented a general architecture for the information transferring between AR browsers and a provider structure. Later, it is discussed the structure and conception of the representation model, responsible for the identifying and filter the relevant information to users.
RESUMO A evolução dos dispositivos móveis e seus diversos sensores tem proporcionado um cenário favorável para o desenvolvimento de aplicações inovadoras de Realidade Aumentada (RA) em domínios como a geolocalização e navegação. Os dados produzidos por tais sensores, geralmente combinados com informações provenientes de serviços diversos, são utilizados como referência para a produção de informações para tais aplicações, que se mal especificadas conduzem à desordem visual da interface e prejudicam o processo interativo. Desta maneira, o presente trabalho visa apresentar a proposta de padronização de aplicações móveis de navegação, por intermédio da criação de um modelo de representação para as informações exibidas, proporcionando uma experiência customizável "on-the-fly" mais rica para a localização de pontos de interesse (PIs) em Navegadores de Realidade Aumentada (NRA). Em um primeiro momento é apresentada uma arquitetura geral para a transferência de informações entre navegadores de RA e uma infraestrutura provedora. Posteriormente, é discutida a estrutura e concepção do modelo de representação, responsável por identificar e filtrar as informações relevantes ao usuário.
Categories and Subject Descriptors H.5.1 [Multimedia Information Augmented, and Virtual Realities
Systems]:
Artificial,
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IHC'13, Brazilian Symposium on Human Factors in Computing Systems. October 8-11, 2013, Manaus, AM, Brazil. Copyright 2013 SBC. ISSN 2316-5138 (pendrive). ISBN 978-85-7669-278-2 (online).
Keywords Augmented Reality Browser, JSON, Representation Model.
1
INTRODUÇÃO
O modo de vida atual tem levado os usuários de interfaces computacionais sentirem a necessidade de respostas satisfatórias, rápidas e versáteis que possam adaptar-se às suas vontades. Neste contexto, a RA tem se tornado cada vez mais presente em aplicações interativas que demandem tais requisitos [2, 3, 11, 10]. Mediante este cenário, tecnologias combinadas aos diversos recursos da RA móvel em tempo real para a sobreposição de imagens deram origem aos NRAs, aplicações que demandam a sincronização de recursos como câmera, conexão com Internet e GPS (Sistema de Posicionamento Global), e que auxiliam na busca de territórios e PIs a serem explorados [1]. No entanto, tais aplicações de navegação têm se mostrado limitadas com relação à distribuição, disponibilização e customização dos dados exibidos. Deste modo, o presente trabalho tem como objetivo principal o desenvolvimento de um modelo de representação para formalizar o resultado de buscas e a representação de informações em NRAs. Mais especificamente, tal modelo deverá padronizar aplicações de NRA quanto à visualização, manipulação, seleção e customização em tempo real das informações de PIs por meio de uma interface de RA.
2
TRABALHOS RELACIONADOS
Bruno Gil et al [7] em “Impacts of data interchange formats on energy consumption and performance in Smartphones”, registraram dados de performance referente à serialização de dados. De acordo com o trabalho realizado, foi constatado que o padrão XML (Extensible Markup Language) mostra-se consideravelmente inferior ao padrão JSON (JavaScript Object Notation) com base em testes efetuados nos quesitos: prototipação, energia gasta pela CPU ao sincronizar os dados, transferência e tempo de sincronização em diferentes tipos de interfaces de rede. Após uma análise do trabalho, o autor conclui que o padrão JSON consegue lidar com as performances negativas do XML. Em contrapartida, os formatos binários são mais rápidos e consistentemente menores que os baseados em texto, porém pode haver uma limitação em sua utilização pois os dados enviados no formato binário só podem ser analisados se o receptor tiver um arquivo “.proto” ou “.thrift” e os includes necessários para incluir outros arquivos. Marko Ilievski et al [9] abordam o desenvolvimento de uma plataforma independente e padronizada de RA utilizando tecnologias Web. Trata-se de um conjunto de padrões Web como base para aplicações que utilizam rastreamento fundamentado em marcador e localização. Além disso, retrataram novos desafios de aplicações RA além de oferecerem uma abordagem diferente da implementação das mesmas por meio de tecnologias que permitem a padronização e independência de plataforma.
284
Referente à NRA com foco na construção de modelos para este tipo de aplicação, Gerhard Reitmayr et al [13] descrevem uma arquitetura dividida em três camadas que gerenciam um modelo de dados comum para um conjunto de aplicações, sendo elas: o banco de dado central que armazena o modelo geral; uma camada mediadora entre banco de dados e a aplicação responsável pela conversão do modelo geral em estruturas de dados em formato XML, e por fim a aplicação como a terceira camada. Engelke e Keil [6] abordam uma arquitetura fundamentada em RA móvel para pesquisa e desenvolvimento com base em padrões para um NRA utilizando HTML5 (Hypertext Markup Language, versão 5). Fatores condicionantes para o desenvolvimento do trabalho foram as diferentes arquiteturas existentes para dispositivos móveis e a pequena quantidade de desenvolvedores de aplicativos de RA, diante de plataformas de desenvolvimento e da necessidade de padronização.
3
ARQUITETURA PARA NAVEGADORES DE RA
Segundo Butchart em “Architectural styles for Augmented Reality in Smartphones”, há três padrões de arquiteturas para NRAs são eles: Gateway, Standalone e Web [4]. O padrão Gateway atua como entrada para modelos georeferenciados para determinados tipos de conteúdo como 2D, 3D, som e imagens, neste padrão os pontos georeferenciados e o contexto a ser exibido estão localizados fora do NRA. O padrão Standalone une todos os subsistemas do NRA, bem como os PIs e conteúdos publicados relacionados a eles. Assim, a aplicação não depende da conexão entre o desenvolvedor e a rede de dados que se tornam necessários apenas para atualização de conteúdo/versão. Já no padrão Web, não há camadas de abstrações, os dados são acessados por meio da Web tornando o NRA baseado nesta arquitetura em um navegador Web de acesso ilimitado utilizando a World Wide Web como uma base de dados [14]. Com base nestas informações, a arquitetura para o funcionamento de um NRA é dividida entre o aplicativo NRA e servidor de dados, dispostos de forma que a imagem capturada pela câmera em sincronia com o GPS alimenta o aplicativo, o qual envia a solicitação do PI ao servidor local ou remoto, onde é feita a identificação dos dados de localização, formatação e modelagem das informações referentes aos PIs correspondentes.
1.1
onde o usuário se encontra posicionado, até uma distância de 50 metros. Quanto ao gerenciamento de dados, o padrão REST (Representatio-nal State Transfer) foi adotado para estabelecer as regras de negócio e comandos de comunicação Cliente/Servidor, o qual consiste numa técnica para sistemas de hipermídia (mídias em um único suporte computacional). Utilizado no desenvolvimento de WebServices para otimizar a comunicação e a perfomance de aplicações, o padrão REST interliga cliente e servidor por meio das operações: GET, POST, DELETE e PUT empregadas para consultar, deletar e inserir dados utilizando o protocolo HTTP [8, 12]
Arquitetura proposta para NRA
A arquitetura para NRA no qual o modelo atuará é composta por três itens fundamentais: a Base de Dados, o Webservice e o Aplicativo. Sendo assim, o Aplicativo envia as solicitações referente aos PIs e, após receber as requisições, o WebService obtém dados do Google por meio da API (Application Programming Interface) Google Places. Em seguida, após modelar as informações conforme a Base de Dados local, o Webservice envia as mesmas para o Aplicativo utilizando um método de encapsulamento de dados (XML,JSON, YAML, etc). Por meio das coordenadas de latitude e longitude, o Aplicativo identifica onde o usuário se encontra, e por meio de um atributo denominado raio, é possível identificar locais ou lugares que estejam situados exatamente ou próximos desta localização. A interface de RA se encarrega de exibir as informações sobre os PIs a serem visualizados, onde em sincronia com a localização, disponibiliza os dados referentes aos locais próximos, causando a impressão de que os inputs do Aplicativo são realizados pela imagem capturada pela câmera. Como os dados são obtidos por meio da API do Google, o raio pode ser no máximo de 500 metros, assim, selecionado um raio de 50 metros, por exemplo, os marcadores aparecerão à partir de
IHC 2013 Proceedings ▪ Short Papers
Figura 1: Arquitetura geral para NRA alimentada pelo modelo de representação Referente ao WebService, foi definido o framework web Ruby on Rails, o qual desenvolve controladores e views baseados na arquitetura REST, bem como um modelo e um controlador para cada tabela da aplicação disponibilizando URL automáticas para as operações primárias. Outro fator contribuinte à definição deste framework para a aplicação Web é a simples integração com a API de serviços do Google Maps. Por meio desta, é possível calcular rotas entre locais utilizando uma solicitação HTTP, efetuar pesquisas de locais com o retorno de locais próximos com base na localização atual do usuário, obter informações mais detalhadas sobre um PI específico, bem como comentários de outros usuários [5]. A Figura 1 apresenta uma arquitetura proposta para o funcionamento do NRA com GPS, WebService e Base de Dados. Considerando a arquitetura da Figura 1, o modelo a ser descrito na próxima seção atuará como um filtro onde a solicitação dos dados referentes ao PI será tratada pelo WebService na saída do servidor REST, a fim de controlar a exibição de objetos a serem representados visualmente pela interface de RA, determinados relevantes pelo próprio usuário combinando informações pertinentes ao cenário selecionado.
4
Modelo de Representação
O modelo de representação em desenvolvimento conceitualmente disposto em três camadas:
x x
será
Base de dados: responsável pela distribuição dos dados obtidos por meio da API de serviços do Google; Reestruturação de dados: efetuará a conversão dos dados para um formato de encapsulamento intermediando a comunicação com a Aplicação;
285
x
Aplicação: se encarregará de dispor as informações recebidas ao usuário final.
Funcionalmente, na aplicação haverá um layout composto pelos campos de visualização a serem selecionados pelo usuário. Desta forma, as informações dispostas sobre os PIs estarão de acordo com sua própria necessidade e relevância diante do cenário. Ao selecionar as opções referentes ao PI como locais próximos, endereço e telefone, o WebService recebe a requisição feita pela Aplicação, e por meio de indicadores como Latitude e Longitude, obtém os dados da API Google Places e realiza a estruturação e o retorno de acordo com a base de dados pré-definida. Como resposta na Aplicação, o usuário obtém estabelecimentos/locais contidos no raio referente à localização atual.
usuário, bem como um radar composto pelos lugares próximos à localização atual e — se disponível — dicas de usuários sobre o PI. A seleção dos pontos propõe ao usuário uma interface menos carregada e agradável pelo fato de conter apenas o que foi selecionado.
É neste este escopo que atuará o modelo de representação para NRA, onde apenas certos atributos de um objeto serão exibidos em uma situação X e um conjunto de objetos serão exibidos em uma situação Y, possibilitando a formatação de saídas de forma dinâmica e sob demanda do usuário. A Figura 2 retrata a camada de definição de dados referentes ao PI levando em conta um cenário de estabelecimentos comerciais.
Figura 3: Arquitetura funcional do modelo de representação 5 Resultados Preliminares Como resultados preliminares, obteve-se informações pertinentes sobre navegadores conhecidos. Wikitude, (WorldWikitude) foi o primeiro NRA. Os dados de PI são convertidos para uma string JSON e a transferência dessa string é realizada por meio das funcionalidades do SDK (Software Development Kit) Wikitude que faz a chamada do JavaScript para o contexto da aplicação de RA. Junaio é um NRA com base na plataforma Metaio. Utiliza AREL (Augmented Reality Experience Language), uma ferramenta para definição de conteúdo. Sua arquitetura divide-se da seguinte forma: um XML define quais conteúdos serão carregados na AREL, como modelos 3D ou quadros de avisos. O mesmo também define as propriedades destes objetos como tamanho, coordenadas do sistema, transformações, etc. A camada HTML 5 provê a interface gráfica do usuário e interage por meio do JavaScript com o Metaio SDK.
Figura 2: Camada de seleção para estruturação da informaçãosobre os PIs a serem exibidos As requisições serão realizadas por meio da Internet e a consolidação do retorno das informações acontecerá por meio do WebService, onde as classes predefinidas em Ruby em conexão com o modelo definido pelo banco de dados, estrutura a informação de acordo com o que foi solicitado pelo usuário. O modelo atuará nesta fase de transição, modelagem e definição de resposta, onde, após receber a solicitação da Aplicação, o modelo recebe os dados referentes aos locais requeridos. Os autores acreditam que ao estruturar os dados provenientes dos serviços web, a representação dos mesmos pode ser modelada, pois considera-se neste trabalho que a visualização dos dados em interface de Realidade Aumentada é consequência da modelagem dos mesmos. A classe rails situada no Webservice recolhe as informações dos serviços de mapas do Google. Tais dados são renderizados no formato de dados JSON e a aplicação se encarrega de estruturação da interface de RA, como representado na Figura 3. A interface será composta pela imagem capturada pela câmera do dispositivo móvel, após a seleção dos PIs receberá os objetos flutuantes de RA contendo as informações selecionadas pelo
IHC 2013 Proceedings ▪ Short Papers
Também como resultado preliminar foi desenvolvido uma das camadas essenciais para o modelo de representação que é a modelagem da Base de Dados. Além de tabelas convencionais, a base de dados é composta por Bairros, Cidades e Países, e tabelas essenciais como: x Categoria, que encarrega-se de filtrar os dados de acordo com o tipo do PI, onde ocorrerá e exclusão de locais que não são do interesse do usuário, como por exemplo a categoria Saúde, a qual disponibilizará informações referentes a estabelecimentos na área da Saúde; x
Usuário, a qual refere-se a possíveis informações e referências sobre responsáveis por determinados estabelecimentos. Tal tabela pode ser considerada um fato excepcional devido à possibilidade de não haver dados referentes ao propósito da mesma;
x
Informações adicionais, a qual apresenta situações extraordinárias de acordo com o cenário dos locais, como por exemplo, promoções de consultas dentárias referente aos consultórios odontológicos.
Uma pesquisa dentre os formatos para o transporte dos dados baseados em texto foi realizada, gerando um comparativo entre os principais (XML e JSON). Assim, o padrão JSON foi definido como método de encapsulamento.
286
Em relação ao XML, o padrão JSON possui uma gramática pequena, mapas diretos à estruturas de dados utilizados nas linguagens de programação modernas, a ausência de tags ou atributos para representar os dados, a capacidade de suportar uma ampla variedade de aplicações e por possuir tempo de processamento menor, o que consequentemente provê um bom desempenho para a aplicação [15]. Os formatos binários podem ser mais rápidos, e ter tamanho e tempo menor na serialização. Porém, não se enquadram no âmbito deste projeto, pois dados encapsulados neste formato não podem ser utilizados sem que o receptor tenha includes necessários para realizar a leitura e utilização destes [7]. Com auxílio da API do Google para serviços do Google Maps foi possível desenvolver uma classe teste para efetuar a busca de locais por meio de uma solicitação HTTP. Em um primeiro momento a conexão com o serviço de mapas ocorreu com sucesso, porém necessitando de mudanças e adaptações para a comunicação da aplicação com a camada Reestruturação de dados.
6
Considerações Finais
O presente trabalho propõe-se a padronizar e promover a customização das informações exibidas por NRAs, por meio de um modelo de especificação composto por uma Base de dados, WebService local alimentado pela API de serviços do Google e a Aplicação, proporcionando uma experiência interativa do usuário onde será possível selecionar os PIs e manipular os dados em tempo real. Mais eficiente que o padrão XML, simplificando e diminuindo o tempo de espera do usuário, o padrão JSON pôde ser considerado a melhor ferramenta neste contexto por mérito de sua performance diante da prototipação das informações, além do fato de ser eficiente na sincronização de dados, visto que poderá haver infinitas requisições de PIs. Quanto ao modelo em desenvolvimento, estima-se efetuar ensaios relacionados à customização dos dados e à comunicação com o servidor de forma que a aplicação final destaque-se em sua performance. Em comparação com os NRAs analisados, a arquitetura de NRA juntamente com o modelo de representação tende a intensificar e abranger de forma mais completa a interação em tempo real do usuário, visto que ele pode selecionar quais informações sobre deseja visualizar como, por exemplo, ofertas de produtos esportivos e peças de veículos automobilísticos. Utilizando o Google como base de dados, a aplicação não se restringe a apenas uma determinada região, proporcionando ao usuário uma experiência interativa onde ele tem o poder da decisão e autonomia na aplicação independente de localização. Concluiu-se previamente que de acordo com as informações que compuseram e compõem o presente trabalho, que existem meios viáveis para concretizar o objetivo do mesmo. Assim os próximos passos constituirão a implementação das funções de filtragem de informação previstas pelo modelo de representação. Ao final desta, será realizada uma avaliação com grupos heterogêneos de usuários a fim de verificar a aplicabilidade da ferramenta para domínios diferentes
7
Agradecimentos
Os autores agradecem ao Conselho Nacional de Desenvolvimento Científico e Tecnológico pelo apoio financeiro. Processo número 117330/2012-4.
IHC 2013 Proceedings ▪ Short Papers
8 [1]
. Referências ALESSANDRO, M., DÜNSER, A., AND SCHMALSTIEG, D. Zooming Interfaces for Augmented Reality Browsers. Information Systems Journal 20, 5 (2010), 161–169.
[2] AZUMA , R., AND BAILLOT, Y. Recent Advances in Augmented Reality. IEEE Computer Graphics and Applications 21, 6 (2001), 34–47. [3] AZUMA, R., AND NEELY, H. Performance analysis of an out-door augmented reality tracking system that relies upon a few mo-bile beacons. International Symposium on Mixed and Augmented Reality (2006), 101– 104. [4] BUCHART, B. Architectural styles for augmented reality in smartphones. International AR Standards Meeting (2011). [5] DEVELOPERS, G. Google maps api web services, February 2013. [6] ENGELKE, T. A Modern WEB based mobile AR architecture for research and development based on Institute for Computer Graphics Research. International AR Standards Meeting (2011). [7] GIL, B., AND TREZENTOS, P. Impacts of data interchange formats on energy consumption and performance in smartphones. Proceedings of the 2011 Workshop on Open Source and Design of Communication (2011), 1–6. [8] HEIDEMANN, J., OBRACZKA, K., AND TOUCH, J. Modeling the performance of HTTP over several transport protocols. Workshop on Open Source and Design of Communication 5, 5 (1997), 616–630. [9] ILIEVSKI, M., AND TRAJKOVIK, V. An Approach to Both Standardized and Platform Independent Augmented Reality Using Web Technologies. ICT Innovations 2012, Advances in Intelligent Systems and Computing 207 (2013), 195–203. [10] KIRNER, T., REIS, F., AND KIRNER, C. Development of na interactive book with Augmented Reality for teaching and learning geometric shapes. Information Systems and Technologies (2012). [11] KORAH, THOMMEN, JASON WITHER, YUN-TA TSAI, R. A. Mobile Augmented Reality at the Hollywood Walk of Fame. In Proc. of IEEE Virtual Reality 2011 (2011), pp. 183–186. [12] MULLIGAN, G., AND GRACANIN, D. A Comparison of SOAP and REST Implementations of Service Based Interaction Independence Middleware Framework. Winter Simulation Confe-rence (2009), 1423– 1432. [13] REITMAYR, G., AND SCHMALSTIEG, D. Data management strategies for mobile augmented reality. Software Technology for Augmented Reality (2003). [14] SAMBIANELLI, F., AND PEIXOTO, C. Arquiteturas de Navegadores de Realidade Aumentada Movel. Tendencias e Tecnicas em Realidade Virtual e Aumentada 2 (2012), 182– 185. [15] SUMARAY, A. AND MAKKI, S. K. A Comparison of DataSerialization Formats For Optimal Efficiency on aMobile Platform. Proceedings of the 6th International Conference on Ubiquitous In-formation Management and Communication, 0851912 (2012).
287
