visualizaÇÃo de dados em realidade aumentada©_pedrosa.pdfvindo a atingir grandes desenvolvimentos...
TRANSCRIPT
UNIVERSIDADE DE LISBOA
Faculdade de Ciências
Departamento de Informática
VISUALIZAÇÃO DE DADOS EM REALIDADE AUMENTADA
José Manuel da Graça Nunes Pedrosa
PROJETO
MESTRADO EM INFORMÁTICA
2013
UNIVERSIDADE DE LISBOA
Faculdade de Ciências
Departamento de Informática
VISUALIZAÇÃO DE DADOS EM REALIDADE AUMENTADA
José Manuel da Graça Nunes Pedrosa
PROJETO
Trabalho orientado pela Profª. Doutora Maria Beatriz Duarte Pereira do Carmo
e coorientado pela Profª. Doutora Ana Paula Boler Cláudio
MESTRADO EM INFORMÁTICA
2013
Agradecimentos
Com a conclusão deste trabalho termina uma fase árdua da minha carreira
académica. Nunca teria sido possível chegar onde cheguei sem o apoio incondicional da
minha família, de toda a dedicação e sacrifício a que os meus pais se submeteram ao longo
de mais de duas décadas para assegurar que a minha jornada educativa pudesse ser
cumprida com o maior êxito possível.
Agradeço ainda a todos os meus amigos, aos mais próximos e mais afastados, que
me proporcionaram momentos de grande alegria e empatia e me deram forças para que
continuasse a seguir em frente mesmo mas fases mais difíceis da minha vida.
Obrigado a todos os meus colegas de trabalho, com quem me cruzei ao longo dos
anos, e com quem partilhei experiências magníficas que nos fizeram crescer e definir
enquanto pessoas, e nos ensinaram a encarar as adversidades com força e otimismo.
Juntos, partilhámos sucessos e fracassos e quebrámos barreiras que individualmente não
teríamos conseguido.
Obrigado também a todos os professores que me acompanharam e que me deram
apoio e incentivo extra quando mais precisei, pois com eles aprendi as minhas verdadeiras
forças e fraquezas, aprendi a nunca desistir e a conseguir sempre mais e melhor do que
antes.
Quero igualmente agradecer à Faculdade de Ciências da Universidade de Lisboa,
ao seu Departamento de Informática e ao LabMAg por terem proporcionado a
oportunidade e os meios para que pudesse completar a minha formação académica,
abrindo portas para uma futura carreira de sucesso, bem como à Fundação para a Ciência
e Tecnologia pelo apoio financeiro prestado. Por fim, um grande obrigado a todos os que
colaboraram na realização deste projeto, e a todos os envolvidos na realização de testes,
pois sem a vossa contribuição o mesmo não teria sido possível.
Aos meus pais e avós.
i
Resumo
A Realidade Aumentada (RA) consiste na combinação, em tempo real, de gráficos
gerados em computador com imagens do mundo real, sendo uma tecnologia que tem
vindo a atingir grandes desenvolvimentos na última década, em grande parte graças à
expansão da indústria de aparelhos móveis, tais como telemóveis, smartphones, mini-PCs
e mais recentemente tablets. Estes revelam grande potencial e utilidade para o
desenvolvimento de aplicações de RA devido ao bom compromisso que apresentam entre
a portabilidade e o bom desempenho e riqueza de recursos. Em particular, componentes
como a câmara de alta resolução, sensores como acelerómetros, bússola e giroscópios,
sistema de geolocalização e conectividade em rede, contribuem para proporcionar aos
programadores uma plataforma de hardware ideal ao desenvolvimento de aplicações RA.
É apresentado neste documento um projeto de expansão de uma biblioteca para o sistema
operativo Android, designado RUBI Glare, que permite visualizar dados científicos em
RA, e com base na qual foi desenvolvida uma aplicação para tablets que apresenta níveis
de radiação solar sobre os edifícios que compõem a FCUL. Os dados são projetados em
tempo real com diferentes modos de visualização, como superfícies ou glifos, e com a
possibilidade de serem exibidas até duas variáveis em simultâneo, bem como transições
animadas que facilitam comparações entre dados relacionados. São expostos com detalhe
os desafios e opções tomadas no desenvolvimento do projeto e as funcionalidades
implementadas, bem como os algoritmos de geração de gráficos desenvolvidos. São ainda
apresentados os resultados dos testes realizados com utilizadores para avaliação da
usabilidade da aplicação e utilidade da biblioteca, e para recolha de sugestões de
melhoramento.
Palavras-chave: realidade aumentada, visualização, dados científicos, computação
móvel
ii
iii
Abstract
Augmented Reality (AR) refers to the real-time combination of computer-generated
graphics and real world images, and is a technology which has reached a high level of
development within the last decade, mostly thanks to the expanding industry of mobile
devices, such as cell phones, smart phones, mini-PCs and, more recently, tablets. The
latter reveal a great potential for the development of augmented reality applications due
to their good compromise between portability and good performance and resource
plentifulness. Particularly, components such as a high resolution camera, sensors such as
accelerometer, compass and gyroscope, geo-location systems and network connectivity,
all together contribute to deliver programmers an ideal hardware platform for the
development of AR applications.
This document describes a project that comprised the extension of an Android library,
called RUBI Glare, which allows visualization of scientific data in AR and served as the
basis for the development of a tablet application that presents solar radiation levels over
the buildings encompassing FCUL. This data is projected in real time with different
visualization modes, such as surfaces or glyphs, and with the possibility of displaying up
to two variables simultaneously. It also includes animated transitions that facilitate the
comparison of related datasets. The document exposes in detail the challenges faced,
decisions made in the project’s development and functionalities implemented, as well as
the algorithms for generating of graphics. The results from user testing for measuring
usability, evaluating the library’s usefulness and gathering improvement suggestions are
also shown.
Keywords: augmented reality, visualization, scientific data, mobile computation
iv
v
Conteúdo
Lista de Figuras vii
Lista de Tabelas xi
Lista de Acrónimos e Siglas ........................................................................................ xiii
Capítulo 1 Introdução ....................................................................................... 1
1.1 Objetivos ..................................................................................................... 2
1.2 Planeamento e Contribuições ..................................................................... 3
1.3 Estrutura do Documento ............................................................................. 5
Capítulo 2 Trabalho Relacionado .................................................................... 7
2.1 Projetos de RA Relevantes ......................................................................... 7
2.1.1 Soluções de Alinhamento ..................................................................... 7
2.1.2 Visualização em Espaços Urbanos ....................................................... 8
2.1.3 Carregamento e Processamento dos Dados ........................................ 10
2.1.4 Realidade Aumentada em Android..................................................... 11
2.2 A Biblioteca RUBI ................................................................................... 12
Capítulo 3 A Biblioteca RUBI Glare ............................................................. 15
3.1 Análise e Desenho .................................................................................... 15
3.2 Material Utilizado ..................................................................................... 18
3.3 Implementação.......................................................................................... 20
3.3.1 Motor de Gráficos ............................................................................... 20
3.3.2 Escalas de Cor .................................................................................... 28
3.3.3 Carregamento de Dados...................................................................... 29
3.3.4 Georreferenciação e Orientação ......................................................... 30
Capítulo 4 Aplicação de Visualização de Radiação Solar ............................ 31
4.1 Modos de Visualização ............................................................................. 32
4.2 Opções Adicionais .................................................................................... 34
4.3 Interface com o Utilizador ........................................................................ 36
4.4 Transição Animada de Dados ................................................................... 38
vi
4.5 Desempenho e Fiabilidade........................................................................ 39
Capítulo 5 Testes com Utilizadores ................................................................ 41
5.1 Metodologia .............................................................................................. 41
5.2 Perfil dos Utilizadores .............................................................................. 43
5.3 Análise dos Resultados ............................................................................. 44
5.3.1 Carregamento e alinhamento dos gráficos.......................................... 44
5.3.2 Visualização de uma variável ............................................................. 45
5.3.3 Visualização de duas variáveis ........................................................... 48
5.3.4 Utilização de transições animadas ...................................................... 49
5.3.5 Questões adicionais ............................................................................ 50
Capítulo 6 Conclusões e Trabalho Futuro .................................................... 53
Bibliografia 55
Anexo A: Diagramas UML .......................................................................................... 59
Anexo B: Mapa dos Pontos de Observação ................................................................ 61
Anexo C: Guião de Testes com Utilizadores .............................................................. 63
Anexo D: Capturas de Ecrã ......................................................................................... 75
Anexo E: Menus de Opções ......................................................................................... 76
vii
Lista de Figuras
Figura 2.1 Demonstração do posicionamento de objetos KML, e imagem do
dispositivo mini-PC utilizado [Honkamaa07] .................................................................. 8
Figura 2.2 Exemplo da interface do SiteLens, suportando diferentes formatos de
glifos 3D, incluindo “nuvens” (c) de diferente densidade [White09]. ............................. 9
Figura 2.3 Captura de ecrã da visualização em RA de correntes de ar em torno do(s)
edifício(s) [Heuveline11]. ............................................................................................... 10
Figura 2.4 Imagens das aplicações de RA para Android: Mixare (à esquerda) e
AndAR (à direita). .......................................................................................................... 12
Figura 2.5 Esquema da arquitetura da biblioteca RUBI [SilvaP11b]. .................... 13
Figura 2.6 Captura de ecrã do RUBI versão 1.0. .................................................... 13
Figura 3.1 Arquitetura modular da biblioteca RUBI Glare (vista de alto nível). ... 17
Figura 3.2 Demonstração de Gráficos OpenGL translúcidos sobre a imagem da
câmara. ............................................................................................................................ 20
Figura 3.3 Sistema de coordenadas utilizado pelo OpenGL no seu espaço de desenho
3D [Chua]. ...................................................................................................................... 21
Figura 3.4 Representação da comunicação cliente-servidor estabelecida entre o
processador principal e o processador gráfico, realizada a cada chamada ao OpenGL,
incluindo na função de draw() [GLProg]. ...................................................................... 22
Figura 3.5 Esquema da lógica de desenho de uma superfície quadrangular........... 22
Figura 3.6 Exemplos de grelhas estruturadas geradas pelo algoritmo da classe
GLPlane, estas podem ser de geometria irregular (esquerda) ou regular (direita). ........ 24
Figura 3.7 Demonstração da geração de superfícies coloridas e deformadas com
diferentes níveis de densidade. ....................................................................................... 25
Figura 3.8 Cálculo do vetor normal unitário a um plano. ....................................... 26
Figura 3.9 Especificação do espaço de desenho dos gráficos através da função
gluPerspective(). ............................................................................................................. 27
Figura 3.10 Exemplo da descrição em código de uma escala de cores de arco-íris.
........................................................................................................................................ 28
Figura 4.1 Exemplo dos quatro modos de visualização, aplicados sobre a mesma
superfície do conjunto de dados. .................................................................................... 32
viii
Figura 4.2 Comparação da visualização de glifos em diferentes dimensões. ......... 33
Figura 4.3 Escalas de cor utilizadas na aplicação. De cima para baixo: rainbow, blue-
white-red e temperature.................................................................................................. 34
Figura 4.4 Dados sobrepostos à imagem da câmara, com transparência a 50% e
oclusão ativada. .............................................................................................................. 34
Figura 4.5 Interface com o utilizador, com a vista de RA em execução. ............... 36
Figura 4.6 Imagem do navegador de ficheiros integrado (acima), e do menu de
definições (abaixo). ........................................................................................................ 37
Figura 4.7 Menu de controlo de animação. ............................................................. 38
Figura 5.1 Exemplo dos diferentes tipos de perguntas realizadas nos testes com
utilizadores. .................................................................................................................... 42
Figura 5.2 Secção do edifício C6 utilizada nos testes com utilizadores. ................ 42
Figura 5.3 Gráficos da distribuição dos utilizadores de teste por sexo, profissão e
níveis de experiência em visualização de dados, software de vis. de dados e utilização de
tablets, numa escala de 1 (pouca) a 5 (muita). ............................................................... 43
Figura 5.4 Distribuição das respostas relativamente à facilidade do alinhamento
manual, e à existência ou não de imperfeições na sobreposição dos gráficos sobre a
imagem de fundo. ........................................................................................................... 44
Figura 5.5 Distribuição das respostas quanto à clareza e compreensibilidade das
opções do menu relativas ao alinhamento. ..................................................................... 45
Figura 5.6 Distribuição das respostas quanto à clareza das opções do menu relativas
a glyphs, e quanto à facilidade em ajustar essas mesmas opções. .................................. 46
Figura 5.7 Distribuição das respostas quanto à satisfação com o seletor de escalas de
cor, e quanto à escala de cores preferida segundo a profissão. ...................................... 46
Figura 5.8 Distribuição das respostas relativamente à facilidade em alternar entre
modos de visualização e em ajustar as opções de oclusão e opacidade. ........................ 47
Figura 5.9 Escolha dos utilizadores quanto ao modo de visualização preferido, e
separação das respostas obtidas segundo a idade e o sexo dos utilizadores. .................. 48
Figura 5.10 Classificação atribuída pelos utilizadores à facilidade de utilização do
modo de Glyphs + Surfaces e à clareza das opções de configuração desse modo. ........ 48
Figura 5.11 Classificação atribuída pelos utilizadores à clareza das opções de
configuração do modo de superfícies deformadas, e quanto à utilidade de um modo destes
na visualização dos dados. .............................................................................................. 49
ix
Figura 5.12 Classificação atribuída pelos utilizadores à facilidade de utilização da
animação, e à facilidade de ajuste das opções de animação. .......................................... 50
Figura 5.13 Classificação atribuída pelos utilizadores à visibilidade quer dos gráficos
de RA quer da interface de utilizador, e classificação global da aplicação. ................... 51
x
xi
Lista de Tabelas
Tabela 3.1: Características de hardware do dispositivo móvel utilizado. .............. 19
Tabela 4.1 Intervalos de tempo aproximados para carregamento dos dados e geração
e modificação dos elementos gráficos no ecrã, para cada modo de visualização. ......... 39
Tabela 4.2 Taxa de refrescamento da imagem para cada um dos modos de
visualização. ................................................................................................................... 39
xii
xiii
Lista de Acrónimos e Siglas API Application Programming Interface
CPU Central Processing Unit
CSV Comma-Separated Values
DDR3 Double Data Rate Type 3
GPS Global Positioning System
GPU Graphics Processing Unit
GUI Graphical User Interface
IDE Integrated Development Environment
POI Point Of Interest
RA Realidade Aumentada
SDRAM Synchronous Dynamic Random Access Memory
SoC System on a Chip
SSD Solid-State Drive
URL Uniform Resource Locator
xiv
1
Capítulo 1
Introdução
Realidade Aumentada é uma tecnologia que consiste na sobreposição de gráficos,
vídeo ou som gerados por computador à captação de imagens do mundo real, recorrendo
a técnicas de registo que permitem integrar ambos de uma forma fluida e natural [Kim12].
A origem do termo “realidade aumentada” remonta a 1990, mas desde meados dos anos
60 do século XX que têm vindo a ser desenhadas aplicações que recorrem a algumas das
suas características. No entanto, a quantidade de aplicações com utilidade prática foi
durante muito tempo de número reduzido, em parte devido às anteriores limitações
tecnológicas e por outro lado devido aos elevados requisitos de software e hardware que
estas requerem [Luo11]. Os dispositivos móveis em particular possuíam características
que condicionavam fortemente o desenvolvimento de aplicações de realidade aumentada
para os mesmos. Nomeadamente, a limitada capacidade das suas baterias, a tipicamente
fraca conectividade e rapidez das ligações de rede, e principalmente o fraco poder de
processamento que resulta da utilização de chips que são desenhados de modo a serem
pequenos e de baixo consumo energético.
Mais recentemente, com o aparecimento de smartphones e, mais tarde, de tablets,
abriram-se novas possibilidades ao desenvolvimento de aplicações de realidade
aumentada. Estes aparelhos móveis possuem um ecrã de dimensões mais generosas, que
permitem uma melhor experiência de visualização sem penalizar muito a portabilidade.
Adicionalmente, possuem todo o tipo de sensores que os outros dispositivos móveis já
possuíam, como acelerómetros, giroscópios, bússola, localização por GPS e
conectividade 3G, Wi-Fi ou Bluetooth e uma câmara fotográfica (ou mais) de alta
resolução. O poder destes dispositivos tem vindo a aumentar muito rapidamente, sendo
já algo comum encontrar chipsets com dois ou quatro núcleos e altas frequências de
processamento, que apesar de tudo são otimizados por forma a reduzir o consumo de
energia. Assim, o potencial para aplicações de RA em dispositivos móveis é cada vez
maior, existindo atualmente muitas plataformas para o seu desenvolvimento e
constatando-se o aumento progressivo de diversas aplicações de grande utilidade nas
áreas da ciência, saúde, engenharia ou entretenimento.
2
Assim, é do interesse da comunidade científica desenvolver novas plataformas
capazes de proporcionar experiências de RA com recurso a estes dispositivos que tornem
possível a visualização de dados, permitindo que a análise de informação passe a poder
ser realizada diretamente no local a que dizem respeito. O trabalho apresentado nesta tese
parte deste interesse em convergir a visualização de dados científicos com os presentes
avanços da RA em dispositivos móveis, procurando desenvolver uma plataforma de
desenvolvimento de aplicações que concilie todas estas vertentes. Este trabalho foi
realizado no âmbito da disciplina de Projeto de Engenharia Informática do Mestrado em
Informática do Departamento de Informática da Faculdade de Ciências da Universidade
de Lisboa (FCUL). O trabalho foi desenvolvido no âmbito de um projeto de investigação
do LabMAg (Laboratório Modelação de Agentes), uma unidade de investigação
associada ao Departamento de Informática da FCUL, e em colaboração com o
Departamento de Engenharia Geográfica, Geofísica e Energia (DEGGE).
1.1 Objetivos
O objetivo deste trabalho foi o desenvolvimento de um sistema de visualização de
RA para dispositivos móveis que permita a visualização de dados científicos. No contexto
do presente trabalho, estes foram definidos como valores numéricos com uma referência
espacial ou temporal e sem geometria pré-definida para a sua representação, podendo ter
sido obtidos por simulação ou medição. Para a implementação desse sistema foi preciso
construir a biblioteca necessária à visualização de dados e, posteriormente, desenvolver
uma aplicação exemplificativa das capacidades dessa mesma biblioteca. Por fim, através
de uma implementação cuidada, procurou-se que a aplicação executasse sem grandes
falhas de desempenho e sem consumo excessivo de recursos da máquina (nomeadamente
a bateria).
Os dados para a aplicação foram fornecidos pelo DEGGE e consistem em
informação sobre os níveis anuais de radiação solar sobre o edifício C6 da FCUL. A
aplicação desenhada utiliza informação geográfica e imagens captadas pela câmara para
visualizar esses mesmos dados sobre as imagens do edifício.
3
1.2 Planeamento e Contribuições
No decorrer do projeto foi elaborada uma nova biblioteca de visualização de dados
científicos em RA, designada RUBI Glare. Em particular, foi desenvolvido um motor
gráfico capaz de gerar diferentes modos de visualização, representando uma ou duas
variáveis escalares em simultâneo, e com execução em tempo real. A biblioteca foi
construída de forma modular podendo ser estendida com novas funcionalidades. A
capacidade de realizar transições animadas sobre os dados está também implementada,
podendo a interface de animação ser estendida no futuro por forma a suportar a análise
da evolução temporal desses dados. Como caso de estudo, foi desenvolvida uma aplicação
para visualização de dados sobre a radiação solar relativa ao edifício C6 da FCUL, que
permitiu também realizar uma validação experimental da biblioteca desenvolvida.
Existem algumas limitações como a falta de precisão dos mecanismos de
geolocalização e orientação para conseguir o alinhamento rigoroso dos gráficos com a
imagem real de fundo, o que levou à necessidade de implementar opções de ajuste
manual. Foram ainda realizados testes com utilizadores no sentido de recolher feedback
sobre a usabilidade da aplicação e a utilidade da biblioteca, do qual resultaram algumas
melhorias e aperfeiçoamentos ao atual sistema, bem como propostas de trabalho futuro.
Funcionalidades adicionais implementadas:
Carregamento de dados da memória do tablet.
Localização baseada em GPS.
Possibilidade de alinhar a visualização manualmente (para além do
alinhamento automático).
Possibilidade de configurar e gerar transições de dados animadas.
Possibilidade de “trancar” a captura de imagem, para visualizar os dados
sem ter de apontar constantemente para o edifício.
Relativo ao presente trabalho, foi ainda elaborado o artigo Realidade Aumentada
com Dados Científicos em Dispositivos Móveis, da autoria de José Nunes Pedrosa, Maria
Beatriz Carmo, Ana Paula Cláudio, Ana Paula Afonso, António Ferreira, Paula Redweik
e Cristina Catita. Este artigo foi aceite para publicação na conferência Interação 2013, a
decorrer de 7 a 8 de Novembro de 2013 na Universidade de Trás-os-Montes e Alto Douro
(UTAD), em Vila Real.
4
De seguida apresenta-se o plano de trabalhos estipulado no início do projeto,
contrastando as dadas inicialmente previstas com as datas efetivas da realização de cada
tarefa.
Data prevista: 15 de Setembro - 15 de Novembro
Data efetiva: 17 de Setembro – 30 de Novembro
1. Análise do problema e levantamento de requisitos.
2. Familiarização com a plataforma de realidade aumentada já desenvolvida.
3. Pesquisa de trabalhos realizados quer no domínio da Visualização, quer no
domínio da Realidade Aumentada.
4. Pesquisa de software de domínio público para visualização de dados e testes de
integração ou de exportação de resultados em formatos compatíveis com software
de Realidade Aumentada.
5. Escrita do relatório preliminar.
Data prevista: 15 de Novembro - 15 de Abril
Data efetiva: 1 de Dezembro – 30 de Julho
6. Concretização de uma componente destinada à visualização de dados, na
plataforma de Realidade Aumentada RUBI Glare, que estende a biblioteca RUBI,
contemplando:
- A representação de uma ou mais variáveis em simultâneo.
- A evolução temporal do valor de uma ou mais variáveis.
- Uma interface adequada para a seleção de parâmetros de visualização.
Para este efeito é necessário ter em conta:
a) Implementação do renderer 3D.
b) Integração do renderer com o output dos sensores do RUBI.
c) Criação de interface de seleção de dados.
d) Criação de interface para ajuste da visualização (seleção de variável,
transições animadas, modos de visualização).
e) Implementação de alinhamento baseado em sensores.
5
Data prevista: 15 de Abril - 15 de Maio
Data efetiva: 17 de Junho – 31 de Julho
7. Avaliação e refinamento da componente.
a) Testes individuais.
b) Testes com utilizadores.
c) Análise de resultados e feedback.
Data prevista: 15 de Maio - 15 de Junho
Data efetiva: 1 de Agosto – 27 de Setembro
8. Escrita do relatório final.
A principal discrepância em relação ao planeamento inicial encontra-se na duração
da fase de implementação da biblioteca RUBI Glare, que se revelou muito mais complexa
do que inicialmente previsto devido à necessidade de se realizar uma implementação na
sua maioria de raiz, e na fase de avaliação e refinamento da componente, em que surgiram
problemas pessoais e familiares que atrasaram a procura de utilizadores e a realização de
testes com os mesmos. Por fim, foi necessário proceder-se à escrita e submissão de um
artigo científico referente ao projeto para a conferência Interação 2013, e posteriormente
à submissão de uma versão revista, tarefas que não estava previstas no planeamento
inicial. Por todos estes fatores a escrita do relatório final necessitou de mais tempo e foi
deslocada para o mês de Setembro.
1.3 Estrutura do Documento
Este documento está organizado da seguinte forma:
Capítulo 2 – Trabalho Relacionado
Neste capítulo são exploradas as principais abordagens relacionadas com a aplicação
de RA. São também apresentados diversos trabalhos de investigação relacionados
com a integração de RA em dispositivos móveis, bem como sobre a visualização de
6
dados científicos nesse contexto, que inspiraram o desenvolvimento do presente
trabalho. São também listadas diversas plataformas de RA para Android, resumindo
as funcionalidades de cada uma. No final é feita uma breve introdução à biblioteca
RUBI, que serviu de base ao desenvolvimento deste trabalho.
Capítulo 3 – Biblioteca RUBI Glare
Neste capítulo é apresentada a biblioteca RUBI Glare. É abordada a sua conceção,
os requisitos considerados no desenho da mesma e dificuldades encontradas, o
software e hardware utilizados para o seu desenvolvimento e toda a implementação
realizada, listando módulos construídos, as relações entre estes e detalhando a lógica
de funcionamento.
Capítulo 4 – Aplicação de Visualização de Radiação Solar
Neste capítulo é apresentada uma aplicação Android que recorre à biblioteca
desenvolvida para gerar a visualização em RA dos níveis de radiação solar sobre o
edifício C6 da FCUL. Descreve-se a interface com o utilizador, as funcionalidades
que a aplicação disponibiliza, as opções de configuração à disposição do utilizador
e faz-se uma análise ao desempenho da aplicação, com destaque para a rapidez de
execução e precisão das técnicas de alinhamento.
Capítulo 5 – Testes com Utilizadores
Neste capítulo são apresentados os testes realizados com utilizadores no sentido de
recolher feedback sobre a usabilidade da aplicação e capacidades da biblioteca
desenvolvidas. É explicada a metodologia aplicada, o perfil dos utilizadores e a
análise dos resultados obtidos
Capítulo 6 – Conclusões e Trabalho Futuro
Neste capítulo são apresentadas as conclusões finais relativas ao trabalho
desenvolvido sendo também discutidas algumas possibilidades de trabalho futuro.
7
Capítulo 2
Trabalho Relacionado
Existem diversas questões a considerar quando se procura aplicar RA num
dispositivo móvel, as quais têm vindo a ser abordadas por diversos autores. Apresenta-se
neste capítulo um conjunto de trabalhos de investigação na área da RA que se focam na
correta aplicação desta tecnologia tendo em conta a integração com espaços urbanos, a
utilização de dispositivos móveis e as soluções para o carregamento, armazenamento,
processamento e visualização de dados. Posteriormente, são apresentadas diversas
plataformas de RA desenhadas para dispositivos móveis e compatíveis com o sistema
operativo Android [Android], explicando resumidamente as capacidades de cada uma.
Finalmente é feita uma breve introdução da biblioteca de RA designada RUBI, que serviu
de base ao presente trabalho.
2.1 Projetos de RA Relevantes
2.1.1 Soluções de Alinhamento
Um dos principais problemas da RA é como alinhar as representações virtuais com
a imagem real sem recorrer a marcas fiduciais e independentemente do objeto de estudo.
Em [Honkamaa07] procurou-se implementar um sistema capaz de ser executado em
tempo real em dispositivos móveis de tipo mini-PC. Recorrendo à leitura de valores do
acelerómetro, consegue-se gerar uma estimativa do movimento da câmara do utilizador à
medida que este se desloca em torno da cena.
Para o posicionamento e alinhamento do objeto tridimensional com a cena, foram
consideradas duas abordagens: a semiautomática e a automática. A abordagem
semiautomática estabelece que é o utilizador a indicar manualmente a posição do objeto
(em particular a distância do observador e a orientação), o que pode ser realizado, por
exemplo, através de interação táctil. Posteriormente a aplicação mantém a visualização
alinhada através de estimativas de deslocação da câmara. Na abordagem automática,
utiliza-se o GPS do aparelho móvel em conjunção com a informação geográfica recolhida
do Google Earth para realizar o cálculo da posição do objeto a visualizar. O carregamento
do mesmo é feito diretamente a partir de um ficheiro KML, permitindo obter de uma só
vez a informação geográfica e geométrica do modelo do edifício a apresentar (Figura 2.1).
8
Estas duas abordagens de alinhamento foram adotadas no nosso trabalho, sendo o
alinhamento automático feito com recurso ao GPS e bússola, e o manual realizado através
do arrasto dos gráficos com recurso ao ecrã tátil.
2.1.2 Visualização em Espaços Urbanos
São também de particular relevância estudos em espaços urbanos, uma vez que os
dados do nosso trabalho são aplicados a edifícios. Em [Hakkarainen09], o trabalho acima
referido é expandido no sentido de tornar a aplicação mais modular e reutilizável,
abordando ainda a questão do carregamento e armazenamento de dados e da
implementação de transições animadas. Neste, o objetivo foi desenvolver uma aplicação
para auxiliar em trabalhos de construção civil e edificação no âmbito de um projeto
designado Augmented Reality for Building and Construction (AR4BC).
Procurou-se uma implementação que permitisse a visualização do local de
construção, bem como a sua evolução ao longo do tempo. Devido ao elevado nível de
rigor exigido, recorreu-se a técnicas de localização mais precisas como bússola eletrónica
e sensores de inércia. Foi desenhado um novo sistema de visualização, baseado numa
arquitetura cliente-servidor, em que ambos os componentes podem ser executados na
mesma máquina (se esta possuir capacidades de hardware para tal), ou separadamente
em duas máquinas. Neste caso a informação de localização e orientação é enviada do
cliente para o servidor, que por sua vez calcula a imagem resultante e a devolve ao cliente
para ser apresentada.
Figura 2.1 Demonstração do posicionamento de objetos KML,
e imagem do dispositivo mini-PC utilizado [Honkamaa07]
9
Os algoritmos usados para o alinhamento são importados de uma biblioteca de RA
designada ALVAR (A Library for Virtual and Augmented Reality). Esta biblioteca foi
estendida na tentativa de otimizar o seu funcionamento em dispositivos móveis e
encontra-se documentada com maior detalhe em [Woodward11]. Um projeto semelhante
é apresentado em [Gimeno10], que procura adicionar uma componente de RA aos
tradicionais sistemas de CAD, sendo nesse caso utilizada uma câmara acoplada a uma
grua durante a fase de construção.
Um outro projeto, o SiteLens [White09], centra-se no desenvolvimento de uma
plataforma e conjunto de técnicas que permitem a chamada situated visualisation, isto é,
a visualização de dados relevantes contextualizados num espaço físico. O objetivo é
auxiliar nas tarefas de planeamento urbano, em que tipicamente são necessárias visitas ao
local para averiguar os níveis de tráfego automóvel, vegetação, ou densidade
populacional. O SiteLens dá ao utilizador a capacidade de analisar dados no local, tais
como a saúde dos moradores ou as condições do ar. O mecanismo suporta visualização
em dispositivos fixos, móveis ou mesmo head-mounted-displays. Recorre-se à conversão
de dados no formato KML, permitindo a interoperabilidade com o Google Earth e o
Google Maps. A informação que não tiver uma associação espacial é afixada a um canto
do ecrã, enquanto a restante informação é sobreposta dinamicamente à vista principal,
sendo o alinhamento baseado em marcas fiduciais. No SiteLens foram também
desenvolvidas experiências com ícones naturais (exemplo: nuvens de fumo negras para
representar a densidade de CO) (Figura 2.2). Existe ainda a opção de “congelar” (ou
“trancar”) a imagem, interrompendo a visualização de tempo real para uma melhor
consulta da informação, e fazer uma ampliação semântica sobre cada ponto de dados.
Estas duas soluções revelaram-se bastante úteis e intuitivas em testes com utilizadores. A
opção de “trancar” a imagem foi também adotada no presente trabalho.
Figura 2.2 Exemplo da interface do SiteLens, suportando diferentes formatos de glifos 3D,
incluindo “nuvens” (c) de diferente densidade [White09].
10
2.1.3 Carregamento e Processamento dos Dados
Em [Heuveline11] é apresentado um projeto que procura resolver a questão de como
selecionar os dados pretendidos de um grande volume de dados, bem como gerar uma
visualização que realize uma filtragem inteligente da informação para a tornar mais
compreensível para o utilizador. Neste caso, é utilizado um modelo virtual tridimensional
de várias ruas e edifícios a analisar, cuja informação geométrica é tida em conta ao fazer
a modelação dos dados (nesse caso, correntes de ar). O processamento dos dados e
geração de imagens são realizados em servidores remotos de alto desempenho, recorrendo
em parte à biblioteca VTK e ao software ParaView. As imagens resultantes são enviadas
para o cliente, prontas a ver no local, incluindo já a oclusão causada pelos edifícios, como
mostra a Figura 2.3.
Para minimizar os custos de processamento, bem como a latência e consumo da rede
na transmissão de dados, a visualização no dispositivo móvel aplica uma técnica
detalhada em [Helfrich-Schkarbanenko12], que recorre à criação de imagens com
diferentes perspetivas baseadas na posição e orientação da câmara. Assim, para cada
posição do utilizador, é recebido um pacote de imagens pré-calculadas que são
apresentadas conforme o deslocamento da câmara e o ângulo de visão. Dados os objetivos
específicos do presente trabalho, incluindo o facto de no estado atual de ser apenas
considerada a visualização dos dados sobre um edifício, optou-se por uma abordagem
mais simples, em que todo o processamento é feito no cliente.
Figura 2.3 Captura de ecrã da visualização em RA de correntes de ar em
torno do(s) edifício(s) [Heuveline11].
11
2.1.4 Realidade Aumentada em Android
Foi realizada uma pesquisa de plataformas de RA para Android cujas funcionalidades
fossem ao encontro das necessidades do presente trabalho, nomeadamente o alinhamento
baseado em localização e orientação (sem marcas fiduciais) com suporte para gráficos
tridimensionais e o fácil acesso e modificação do código-fonte.
Wikitude
O Wikitude [Wikitude] é uma das aplicações de RA mais conhecidas, disponível para
diferentes sistemas operativos móveis, incluindo o Android. Disponibiliza
adicionalmente uma API [WDK] que permite o desenvolvimento de aplicações de RA
por parte de terceiros. As aplicações resultantes apresentam ao utilizador os pontos de
interesse (POI) que estão identificados dentro de um determinado raio de alcance. A
aplicação permite o acesso a vários serviços para determinar os seus POI, e a informação
destes é transmitida por meio de ligação à Internet. É também possível adicionar POI
facultados pelo utilizador, bem como associá-los a um endereço URL que é acedido no
decorrer da aplicação.
Metaio
O Metaio [Metaio] é um conjunto de software, plataformas e serviços que permitem
o desenvolvimento de aplicações ou sistemas de RA. Em particular, possui um kit de
desenvolvimento designado Metaio Creator [MC], que permite a criação de aplicações de
RA através de uma interface de utilizador drag-and-drop para a construção de cenários,
a possibilidade de importar imagens ou modelos como conteúdo 3D para uma aplicação,
o alojamento desta em servidores dedicados Metaio e a exportação para diversos sistemas
operativos de desktop ou dispositivos móveis. No entanto, é necessário um registo no
Website como programador e a licença de utilização gratuita é limitada com uma marca
de água sobre a aplicação.
Layar
Outra aplicação bastante conhecida é o Layar [Layar], lançada em 2009 e também
compatível com o sistema Android. À semelhança do Wikitude esta apresenta ao
utilizador POI previamente georreferenciados sobre imagens captadas pelo dispositivo.
A informação que permite a determinação dos POI é também facultada através de uma
ligação à Internet com recurso às mais diversas fontes. A aplicação apresenta a
possibilidade de os utilizadores visualizarem os POI através de uma vista de “olho de
pássaro” e de um mapa 2D, facilitando desta forma o reconhecimento dos POI no espaço
envolvente. O Layar também disponibiliza uma API [LDK] que permite integrar POI na
aplicação, sendo que o conjunto de POI fornecido é intitulado de layer (camada). Esta é
facilmente integrada na aplicação de modo a que outros utilizadores também possam
usufruir dela. Esta possibilidade permite à aplicação apresentar uma quantidade elevada
de POI facultados por terceiros.
12
As três plataformas acima expostas suportam georreferenciação e reconhecimento
de imagem (ou marcas fiduciais), mas são de código fechado e focadas em pontos de
interesse, em que o suporte de gráficos 3D resume-se à importação de modelos estáticos
a representar sobre esses pontos [WDK, MC, LDK]. Dados os objetivos do trabalho, o
recurso a estas plataformas não foi considerada viável.
Outras alternativas de código aberto analisadas foram o Mixare, que se baseia
exclusivamente na georreferenciação de pontos de interesse [Mixare], e o AndAR, que
recorre ao OpenGL ES [OGLES] para carregamento de modelos 3D (Figura 2.4), mas
que possui apenas alinhamento baseado em marcas fiduciais [AndAR]. Assim, optou-se
por recorrer à biblioteca RUBI [[SilvaP11b], [Montez12]], que tem vindo a ser
desenvolvida por anteriores alunos do Departamento de Informática da FCUL, realizando
as extensões necessárias para a visualização de dados científicos cumprindo as
funcionalidades acima referidas.
2.2 A Biblioteca RUBI
A RUBI é uma biblioteca de visualização de pontos de interesse em RA para o
sistema operativo Android [SilvaP11a]. Esta permite a recolha e pré-visualização de
imagens por meio da câmara de vídeo e suporta geolocalização, cálculo da orientação e
inclinação para conseguir o alinhamento do conteúdo (Figura 2.5). Realiza também o
carregamento de dados remotos em formato JSON.
Figura 2.4 Imagens das aplicações de RA para Android: Mixare (à esquerda) e AndAR (à direita).
13
O RUBI foi desenvolvido para o Android 2.2 Froyo. O seu objetivo é ser usado para
o desenvolvimento de aplicações móveis de RA para visualização de pontos de interesse.
A biblioteca segue o padrão modular de aplicações de realidade aumentada exposto em
[Luo11] (Figura 2.6). Esta contém um módulo de recolha de dados que carrega a
informação que se pretende apresentar ao utilizador. A informação pode ser local ao
dispositivo ou ser carregada de um servidor remoto. Existe ainda um módulo de aquisição
de contexto que determina o posicionamento geográfico através do sensor de GPS, a
orientação através do sensor de bússola digital e inclinação por meio do acelerómetro.
Por fim, inclui um componente de visualização que é responsável por gerar a
representação dos POI e o seu alinhamento baseado na componente de aquisição de
dados. Este incorpora ainda a interface gráfica apresentada ao utilizador.
Figura 2.6 Captura de ecrã do RUBI versão 1.0.
Figura 2.5 Esquema da arquitetura da biblioteca RUBI
[SilvaP11b].
14
Esta biblioteca foi posteriormente estendida [Montez12], passando a permitir o
ajuste da visibilidade de símbolos em função da imagem de fundo. Esta versão estendida
da biblioteca RUBI serviu de base à biblioteca RUBI Glare (GL Augmented REality), que
se apresenta no capítulo seguinte.
15
Capítulo 3
A Biblioteca RUBI Glare
Neste capítulo é apresentada a biblioteca RUBI Glare, resultante da extensão da
biblioteca RUBI no sentido de suportar a visualização científica e a representação de
gráficos tridimensionais. É abordada a sua conceção, os requisitos considerados no
desenho da mesma e dificuldades encontradas, e o software e hardware utilizados para o
seu desenvolvimento. É ainda feita a listagem dos módulos desenvolvidos, as relações
entre estes e expostos os detalhes da sua implementação, bem como a lógica de
funcionamento.
3.1 Análise e Desenho
A integração de capacidades de RA em dispositivos móveis costuma seguir
determinados padrões [Luo11]. A informação obtida através dos sensores de orientação
(bússola, acelerómetro, giroscópio) e de localização (GPS) do aparelho permite que à
captação de imagem seja associada uma posição com 6 graus de liberdade (translação e
rotação segundo um sistema de coordenadas em 3 eixos). Opcionalmente estes sensores
podem servir de suporte para uma interação gestual com a aplicação. Existe também um
módulo de input/output que lê dados da memória do aparelho ou de um servidor remoto
e que os passa para um módulo de rendering, que os representará no ecrã. Os gráficos são
assim combinados com o vídeo em tempo real.
Os requisitos essenciais que estes sistemas procuram atingir são interatividade,
fidelidade, escalabilidade e robustez [Luo11]. A representação deve correr em tempo
real, e idealmente sem grandes restrições quanto à quantidade e qualidade dos dados
representados, bem como ter uma forte tolerância a distúrbios na leitura de dados que
possam ser causados por ambientes externos. Também é necessário ter em conta, para
aparelhos móveis, certas dificuldades como a diversidade de arquiteturas-alvo,
capacidades do hardware limitadas em comparação com desktops e laptops, e requisitos
de conservação de energia.
A biblioteca RUBI que serviu de base a este trabalho já possuía capacidades de
combinação de imagens da câmara com símbolos virtuais, leitura de dados GPS e de
acelerómetro [SilvaP11a, Montez12]. No entanto, ainda não possuía mecanismos para
16
desenhar gráficos 3D e os apresentar sobre a imagem, nem módulos para visualização de
dados científicos. Um dos desafios deste trabalho consistiu em desenhar e concretizar
esses módulos, tendo já em mente o desenvolvimento de uma aplicação para visualizar
dados de radiação solar sobre edifícios. A primeira fase do projeto consistiu na
identificação das funcionalidades e componentes necessários para a visualização de dados
num formato tridimensional.
Para o desenvolvimento do motor de gráficos considerou-se inicialmente recorrer ao
VTK (Visualization Toolkit), por este estar otimizado para a leitura e processamento de
dados científicos e por já termos experiência anterior de utilização. O VTK é baseado em
OpenGL e implementado na linguagem C++, mas não é compatível com o Android, pois
este suporta apenas um subconjunto das funcionalidades correspondentes à especificação
OpenGL ES.
Esta incompatibilidade do VTK, e de outras bibliotecas semelhantes do nosso
conhecimento, com o Android levou à necessidade de desenvolvermos de raiz um módulo
capaz de gerar visualizações tridimensionais de dados. O resultado deste trabalho foi uma
extensão da biblioteca RUBI que recorre à implementação OpenGL ES existente no
sistema Android, designada RUBI Glare (GL Augmented REality). A Figura 3.1 mostra
uma representação de alto nível da estrutura de módulos da biblioteca, identificando os
principais componentes e as relações entre estes. Diagramas de classes mais detalhados
podem ser consultados no Anexo A.
17
Figura 3.1 Arquitetura modular da biblioteca RUBI Glare (vista de alto nível).
A biblioteca RUBI Glare é uma extensão da biblioteca original RUBI, que aproveita
as funcionalidades de leitura de posição e orientação que esta já disponibilizava, bem com
a captura de imagens da câmara do dispositivo. Foi implementado um novo conjunto de
módulos responsáveis pela leitura, processamento e visualização de gráficos 3D que são
acrescentados à vista de RA previamente desenvolvida. Os principais componentes do
sistema são:
Gestor de Câmara – Responsável pela abertura e leitura do stream de dados da
câmara fotográfica do dispositivo, ativando e desativando o modo de pré-visualização da
câmara que será utilizado como fundo da vista de RA, e ajustando a proporção da imagem
de acordo com as dimensões e resolução do ecrã e os formatos de imagem suportados
pelo hardware.
Gestor de Posição / Orientação – Responsável por calcular a posição do dispositivo
através de da informação obtida pelo sensor de GPS: latitude, longitude e altitude. Calcula
também a orientação (horizontal) e a inclinação (vertical) deste através da leitura da
bússola digital e do acelerómetro, respetivamente.
Agregador de Entradas – O módulo que combina o input das imagens da câmara
com a informação de posição e orientação dos sensores do dispositivo e desenha uma
18
interface gráfica que consiste na preview da câmara combinada com widgets
representativos da informação da bússola e do GPS.
Gestor de Dados – Módulo responsável pelo processamento dos dados a serem
visualizados. Encarrega-se de realizar a abertura do ficheiro de dados, a leitura dos
mesmos e o seu carregamento e arrumação em memória, para que possam ser acedidos
para filtragem e visualização pela restante biblioteca.
Motor de Gráficos 3D – Módulo que gere a criação de geometria tridimensional,
baseado em OpenGL ES. Responsável pela construção da geometria e coloração (com
base nos dados processados pelo Gestor de dados), posicionamento e ajuste do viewport
e perspetiva do ambiente virtual.
Módulo de Configuração – Módulo que gere todas as configurações e parâmetros
que possam ser ajustados pelo utilizador, tais como a informação a visualizar, o modo de
visualização selecionado, etc. Na aplicação final está diretamente associado a uma GUI
de seleção de parâmetros.
Vista de RA – O front end da aplicação, a interface de utilizador final que resulta da
combinação da GUI gerada pelo agregador de entradas da biblioteca RUBI com o output
do motor de gráficos 3D do RUBI Glare.
Interface de configuração – A interface de utilizador na qual este pode aceder às
opções de configuração que pretender ajustar, sendo as alterações refletidas na vista de
RA. Esta interface encontra-se associada a um módulo de configuração que armazena as
preferências do utilizador, sendo estas lidas pelo motor de gráficos.
3.2 Material Utilizado
Atendendo ao tipo de aplicação a desenvolver, recorreu-se a um tablet, que possui
um ecrã com maiores dimensões que um smartphone e permite uma melhor experiência
de visualização, imagens maiores e mais detalhadas, e a capacidade de apresentar mais
informação em simultâneo, tornando-se uma escolha lógica para a implementação do
projeto. Foi realizada uma análise de vários modelos existentes no mercado e O tablet
utilizado no decorrer deste projeto foi um Asus TF300T, sobre o qual a aplicação foi
desenvolvida e testada. O código final foi elaborado de forma a suportar qualquer outro
dispositivo com características semelhantes, mas o TF300T foi o único modelo no qual
se testou a aplicação final. As características detalhadas do tablet são apresentadas na
tabela 3.1:
19
Fabricante Asus
Modelo Transformer Pad TF300T
Chipset NVIDIA Tegra 3 (1.3 GHz quad-core, arquitetura ARM)
Memória 1 GB DDR3 SDRAM
Armazenamento
interno
32 GB SSD
Sistema operativo Android 4.2.1 Jelly Bean
Ecrã LCD muti-toque, 10.1 polegadas, 1280*800 px de
resolução, 16 milhões de cores.
Câmaras Posterior (8 MP) e frontal.
Sensores Acelerómetro, giroscópio, bússola digital, GPS.
Conectividade USB 2.0, Wi-Fi 802.11 b/g/n, Bluetooth
Tabela 3.1: Características de hardware do dispositivo móvel utilizado.
O chipset Tegra 3 permite que o tablet possua um elevado desempenho quer em
processamento de gráficos 3D de alta qualidade, quer na paralelização das tarefas em
execução [Tegra]. SoC (system on a chip) baseado na arquitetura ARM possui 4 núcleos
Cortex A9 para tarefas de alto desempenho, e um 5º núcleo otimizado para poupança
energética, que permite conservar energia e aumentar a autonomia do aparelho quando
este não requer processamento intensivo. Algumas das vantagens desta arquitetura são o
menor consumo de energia e maior desempenho por Watt, carregamento mais rápido de
páginas Web, melhor execução de aplicações mais exigentes, maior desempenho no
multitasking, e uma melhor experiência e qualidade em videojogos. Estes benefícios
encontram-se mais detalhados em [Tegra].
O software utilizado foi o habitual para o desenvolvimento de aplicações para
Android.:
Android SDK.
Eclipse IDE com o plugin Android Developer Tools (ADT).
Java Development Kit (JDK 7).
20
3.3 Implementação
Nesta secção detalha-se o trabalho desenvolvido na construção dos diferentes
módulos da biblioteca RUBI Glare, é explicado o seu funcionamento interno e as
funcionalidades que estes módulos proporcionam.
3.3.1 Motor de Gráficos
Após concluir que não era possível incorporar o VTK na aplicação, testou-se a
implementação de uma demo de OpenGL ES sem recorrer a essa plataforma. Foi possível
executar a renderização de gráficos sobre a pré-visualização da câmara, mantendo a
visibilidade das duas camadas (Figura 3.2). A simples aplicação de demonstração
desenvolvida não só comprovou a capacidade de implementar realidade aumentada com
o dispositivo, como mostra a capacidade de ajustar diversos níveis de transparência e de
executar sem abrandamentos ou falhas.
Foi necessário desenvolver de raiz o código necessário para gerar gráficos
característicos da visualização científica. A construção do motor de gráficos implicou
assim a especificação das primitivas geométricas que serão utilizadas para a construção
de visualizações mais complexas. Cada primitiva geométrica utilizada pela biblioteca está
contida no seu ficheiro Java, o qual inclui toda a informação de que o OpenGL necessita
para gerar o respetivo objeto tridimensional e o apresentar no ecrã do dispositivo.
De seguida são apresentadas as principais classes que constituem o do motor de
gráficos desenvolvido, explicando a estrutura, propósito e os princípios de funcionamento
de cada uma.
Figura 3.2 Demonstração de Gráficos OpenGL translúcidos sobre a imagem da
câmara.
21
GLMesh
A classe GLMesh especifica os atributos que constituem uma figura geométrica.
Estes incluem uma lista de vértices especificada por um FloatBuffer, uma lista de índices
especificada por um ShortBuffer, e quantidade total de índices. O buffer de vértices é
preenchido com as coordenadas X, Y e Z de cada vértice que constitui a forma
geométrica. O buffer de índices serve para identificar, para cada posição especificada no
buffer anterior, a ordem em que esta é desenhada. Existe ainda uma terceira lista que
corresponde a cores no formato RGBA, também esta na forma de um FloatBuffer. Esta
especifica, para cada vértice listado no buffer de vértices, qual a cor do objeto nesse
vértice. Este buffer de cores só é utilizado quando o objeto que queremos mostrar no ecrã
tem mais que uma cor, caso contrário é substituído por um único vetor de floats
correspondente a uma única cor RGB. Finalmente, são especificadas variáveis que
correspondem a valores de rotação e translação nos 3 eixos do espaço de desenho. Este é
baseado num sistema de coordenadas cartesiano de “mão direita” (Figura 3.3), em que a
rotação em torno dos eixos é medida no sentido direto (sentido contrário ao dos ponteiros
do relógio).
A função mais importante da classe GLMesh é a função draw(). Nela está contido o
código responsável por realizar as diferentes chamadas ao OpenGL para carregar a
informação geométrica e de cor para a memória do GPU, para estre proceder à
renderização (geração da imagem final) no ecrã do dispositivo. É estabelecida uma
ligação entre o Cliente OpenGL ES presente na CPU e o servidor OpenGL ES presente
no GPU (Figura 3.4). Estabelecida a conexão, são estabelecidos apontadores para a
transmissão dos buffers do objeto a desenhar. Uma vez terminado o envio, a conexão
entre cliente e servidor é terminada.
Figura 3.3 Sistema de coordenadas
utilizado pelo OpenGL no seu espaço
de desenho 3D [Chua].
22
GLCube
A classe GLCube estende a GLMesh, especificando o vetor de vértices e de índices
para gerar um objeto tridimensional em forma de cubo. Ao criar um objeto GLCube o
programador tem apenas que especificar a largura da aresta segundo o eixo do X (width),
do Y (height) ou do Z (depth). Isto permite ao programador ajustar não só a dimensão
como também a forma do objeto como bem entender, podendo gerar por exemplo efeitos
de distorção. É possível também aplicar qualquer cor (ou transparência) que se deseje ao
objeto, invocando os métodos setColor() ou setColors() herdados da classe GLMesh.
Uma vez que o OpenGL ES, por predefinição, apenas conhece triângulos como
primitiva geométrica (uma das grandes limitações face ao OpenGL tradicional), a
especificação de um cubo implica a especificação de 6 quadrados, e cada uma desses
Figura 3.4 Representação da comunicação cliente-servidor estabelecida entre o
processador principal e o processador gráfico, realizada a cada chamada ao OpenGL,
incluindo na função de draw() [GLProg].
Figura 3.5 Esquema da lógica de desenho de uma superfície
quadrangular
23
quadrados resulta de agrupar 2 triângulos. Logo, o motor gráfico interpreta o cubo como
uma sequência de triângulos a ser desenhada a partir de uma lista de vértices numa
determinada ordem, como mostra a Figura 3.5. Note-se que, uma vez que apenas uma das
faces de cada triângulo é visível, e a outra fica virada para o interior do cubo, é realizado
o chamado culling de faces, em que se especifica que as faces viradas para dento, por não
serem visíveis, não devem ser desenhadas. Caso contrário, estaríamos simplesmente a
desperdiçar recursos gráficos.
GLCubeGlyphMap
A classe GLCubeGlyphMap serve para gerar a representação de um conjunto de
objetos GLCube dispostos ao longo do espaço de desenho, conforme um conjunto de
dados especificado pela classe RubiDataset (ver secção 3.3.3). Para gerar um
GLCubeGlyphMap o programador deve passar como argumento um objeto RubiDataset
(correspondente aos dados carregados para visualização), o índice correspondente ao
subgrupo de pontos que serão representados, o índice correspondente à variável a associar
aos cubos, o índice correspondente à escala de cores a utilizar (ver secção 3.3.2) e o nível
de opacidade e a dimensão pretendida para o conjunto de Cubos.
Para a construção de uma GLCubeGlyphMap, a biblioteca começa por extrair a
lista de pontos pretendida do volume de dados contido no objeto RubiDataset, filtrados
de acordo com os parâmetros acima explicados. Para cada ponto desta lista, é extraído o
valor da variável e as coordenadas do ponto. Com esta informação é então construído um
objeto GLCube em que a posição corresponde às coordenadas, a dimensão corresponde
à que é passada como argumento, e a cor é calculada com base no valor da variável e na
escala de cores especificada, conforme explicado na secção 3.3.2. Por fim, o GLCube
resultante é armazenado numa lista de cubos para posteriormente ser desenhado. Note-se
que este processo de geração da lista de cubos a desenhar só é realizado uma vez,
correspondente à fase inicial de carregamento dos gráficos.
Quando o programador realiza uma chamada ao método draw(), é estabelecida a
conexão entre CPU e GPU previamente explicada, sendo que neste caso os objetos
GLCube que constituem o conjunto de cubos são carregados para a memória gráfica e
desenhados um a um. Para cada cubo são realizadas 3 chamadas ao GPU: A primeira
estabelece a cor, a segunda a posição cartesiana e a terceira a geometria do cubo. Uma
vez enviada a totalidade dos cubos, a ligação é terminada.
24
GLPlane
A classe GLPlane estende a GLMesh e especifica a criação de uma malha
poligonal. Os parâmetros base para construir um objeto GLPlane são a largura e altura
(em unidades OpenGL), bem como o número de segmentos em cada eixo. Assim, quer a
dimensão quer o nível de subdivisões poligonais podem ser ajustados individualmente.
Estas malhas poligonais devem ser de topologia regular, ou seja, devem ser grelhas
estruturadas (o número de pontos na horizontal e na vertical não varia ao longo da grelha).
A forma mais rápida de verificar esta regularidade é comparando a quantidade de pontos
na primeira linha e primeira coluna com o total da grelha. A topologia é regular se a
seguinte regra for verdadeira:
TPontos = NPontosX x NPontosY
Em que TPontos é a quantidade total de pontos na grelha, NPontosX é a
quantidade de pontos na primeira coluna e NPontosY é a quantidade de pontos na
primeira linha. Esta verificação é bastante rápida computacionalmente e é realizada antes
de ser executado o algoritmo de construção da geometria. Apesar disso, note-se que a
geometria da grelha não precisa de ser também regular (Figura 3.6), o que permite
desenhar superfícies com deformação.
Um exemplo do que é possível realizar com objetos GLPlane é apresentado na
Figura 3.7. Aqui, foram gerados planos transparentes (opacidade a 50%), e com cores
arbitrárias em cada vértice da grelha. A superfície (a) é plana e tem dimensão 10x10. A
(b) é arbitrariamente irregular ao longo do eixo Z, e tem dimensão 10x10. As superfícies
(c) e (d) possuem dimensão 100x100. É possível comprovar não só a possibilidade de
gerar malhas com uma grande quantidade de vértices (e visualizar dados com elevada
resolução) como se pode observar a interpolação de cores que o OpenGL realiza entre
cada vértice com base na técnica de shading de Gouraud, ou vertex shading.
Figura 3.6 Exemplos de grelhas estruturadas geradas pelo algoritmo da classe
GLPlane, estas podem ser de geometria irregular (esquerda) ou regular (direita).
25
Se pretendermos construir uma superfície colorida (ou deformada) a partir de um
conjunto de dados, necessitamos de passar como argumento um objeto RubiDataset, o
índice da variável que queremos usar para a coloração e, facultativamente, o índice da
variável que queremos utilizar para a deformação. Finalmente, devemos especificar a
escala de cores a utilizar, o nível de deformação e o nível de opacidade da superfície.
O algoritmo filtra a partir do objeto RubiDataset os pontos a utilizar para gerar a
superfície e verifica a quantidade de pontos e as coordenadas destes para determinar se a
topologia resultante é regular. Caso contrário, a geração da superfície é cancelada. Se a
topologia for regular, são então gerados o buffer de vértices (a partir das coordenadas dos
pontos, o buffer de índices (a partir da informação da topologia da grelha anteriormente
calculada) e o buffer de cores (a partir do valor da variável em cada ponto).
Figura 3.7 Demonstração da geração de superfícies coloridas e deformadas com diferentes níveis
de densidade.
(a) (b)
(c) (d)
26
No caso das superfícies com deformação são necessários cálculos adicionais. É
preciso saber, para cada plano, qual a orientação da sua reta normal, pois esta será a
orientação da deformação. É também necessário saber a posição relativa ao observador,
pois esta permite saber qual o sentido da deformação. A deformação deve ser direcionada,
portanto, na perpendicular à orientação do plano, e para o lado que está voltado ao
observador. Para determinar uma reta normal ao plano, será necessário determinar
primeiro a posição deste. Isto é realizado selecionando 3 pontos aleatórios do plano que
não sejam colineares. Desses 3 pontos não colineares ficam definidos 2 vetores que
descrevem a posição e orientação do plano. Com estes 2 vetores AB e AC, é possível
calcular um vetor normal AN através do seu produto vetorial AN = AB x AC (Figura
3.8). Do vetor normal AN obtém-se o vetor normal unitário ou normalizado (isto é, de
norma 1).
Finalmente, para assegurar que a deformação é realizada no sentido do
observador, é necessário saber a posição deste no espaço de coordenadas OpenGL. A sua
posição é passada como argumento a cada ciclo de refrescamento da imagem, permitindo
recorrer ao cálculo do produto interno entre o vetor normal ao plano AN calculado acima
e o vetor AO, em que O é a posição do observador. Se o produto for negativo, a normal
NA é multiplicada por -1 para que o seu sentido seja invertido, e o objeto GLPlane é
redesenhado no sentido correto. O resultado é uma superfície com deformação no sentido
do utilizador, que é automaticamente reorientada conforme este mude de posição.
Uma consequência de utilizar a normal ao plano como o sentido da deformação é
que, se o plano não for perfeitamente perpendicular ao chão, a deformação também não
será. Além disso, se uma parede for muito irregular, a normal obtida pode ter uma
orientação estranha, dificultando a análise dos dados. Para evitar estes problemas, existe
a opção de forçar as normais a serem paralelas ao chão, ou não. Se a opção for ativada, a
normal utilizada manterá a orientação X e Z calculadas pelo algoritmo, mas fixará a
orientação Y (eixo vertical) a zero.
Figura 3.8 Cálculo do vetor normal
unitário a um plano.
27
RubiGLSurfaceView
Esta classe é efetivamente o coração do motor gráfico do RUBI Glare. Uma
extensão da classe GLSurfaceView da API do Android, é responsável por criar e mandar
desenhar todos os gráficos OpenGL através da sua subclasse RubiGLRenderer. É ainda
responsável por definir o viewport e configurar todos os detalhes da visualização 3D com
base nas preferências do utilizador. Por fim, é este módulo que faz o refrescamento da
visualização gráfica de acordo com o input recebido dos sensores do dispositivo,
atualizando a posição do observador, a orientação e inclinação em tempo real.
Para definir o viewport e o espaço de desenho dos gráficos, recorre-se à função
utilitária gluPerspective() (Figura 3.9). Esta função define o ângulo de visão da “câmara”
virtual. Este é o ângulo em graus entre dois planos: o plano que passa pela posição da
câmara e o topo do ecrã, e o plano que passa pela posição da câmara e fundo do ecrã. É
apenas passado como argumento o ângulo vertical da imagem, sendo que o ângulo
horizontal é calculado internamente a partir do vertical e da razão de aspeto (aspect ratio).
No caso particular das aplicações de RA, o principal objetivo ao chamar esta função é
ajustar a largura e altura do viewport de OpenGL para coincidir com o aspect ratio nativo
da câmara do dispositivo. Infelizmente, não foi possível descobrir um algoritmo que
conseguisse realizar este ajuste automaticamente, pelo que foram experimentados à mão
vários valores até conseguir a melhor aproximação possível.
Para ajustar a orientação e inclinação da câmara virtual, recorreu-se a um truque
de programação no qual a câmara é fixa na posição (0,0,0) do espaço de visualização e o
resto dos objetos sofrem uma rotação e translação inversas às que são recolhidas pela
Figura 3.9 Especificação do espaço de desenho dos gráficos através da função
gluPerspective().
28
bússola e acelerómetro do dispositivo. Este truque permite orientar corretamente os
gráficos sem a necessidade de calcular o eixo de projeção da câmara.
3.3.2 Escalas de Cor
A biblioteca RUBI Glare suporta a utilização de diferentes escalas de cor. Estas
consistem num vetor de cores RGB cuja dimensão e conteúdo são definidas pelo
programador. Deve-se apenas ter em atenção que, embora vetor mais extenso permita a
criação de escalas de cor mais detalhadas (e com mais cores), pode levar a uma pequena
quebra no desempenho pois torna a associação de uma cor a um valor de variável mais
demorado. A classe ColorScales armazena toda a informação das escalas de cor, podendo
ser alargada com mais conteúdo ao gosto do programador.
Cada escala de cor é identificada na biblioteca por um número inteiro. A escala
propriamente dita consiste num vetor bidimensional, em que cada entrada corresponde a
um vetor de 3 floats (Figura 3.10), correspondente aos níveis de RGB para cada cor da
escala. Estes níveis de RGB podem variar entre 0.0f (preto) e 1.0f (branco), de acordo
com os padrões da API do OpenGL.
O procedimento para aplicar uma escala de cor consiste na chamada da função
estática RubiDataset.colorize() para cada ponto de dados que se pretende colorir. Esta
recebe como argumento o identificador da variável, o valor da variável e o identificador
Figura 3.10 Exemplo da descrição em código de uma escala de
cores de arco-íris.
29
da escala de cores desejada. Com essa informação, consulta quais os valores mínimo e
máximo existentes para essa variável e dispõe a escala de cores entre os dois, calculando
os intervalos de valores a corresponder para cada cor. Finalmente, é escolhida e aplicada
a cor correspondente ao valor de variável recebido.
3.3.3 Carregamento de Dados
Os dados científicos a utilizar pela biblioteca são carregados de um ficheiro externo,
armazenado em disco no próprio dispositivo. O ficheiro de dados segue o formato CSV,
em que cada linha corresponde a um ponto de dados e a informação sobre esse ponto é
separada por “;”. Para exemplificar, o ficheiro de dados utilizado para a aplicação de
visualização de radiação solar (ver Capítulo 4) segue a seguinte estrutura:
Linha 1 (cabeçalho):
"FID_";"ID";"X";"Y";"Zdem";"svf";"cota_ponto";"a_Rdir";"a_Rdif";"a_Rglobal";"
a_nhsombra";"a_nhtotal";"Edifico";"cod_fach";"lat";"long_";"Altitude"
Linha 2:
;178.000000;-89132.989000;-
100755.304000;97.830000;0.306200;82.830000;1358.334800;185932.825000;187291.1
59800;4027.000000;4030.000000;"C6";155.000000;38.756198;-9.158519;136.229995
Linha 3:
;178.000000;-89132.989000;-
100755.304000;97.830000;0.306200;83.830000;3958.407900;186193.789300;190152.1
97000;4022.000000;4030.000000;"C6";155.000000;38.756198;-9.158519;137.229995
A primeira linha do ficheiro de dados corresponde ao cabeçalho, e identifica os
atributos listados nas seguintes linhas. Na estrutura acima, são definidos identificadores
do edifício, da parede e do ponto; coordenadas do ponto (cartesianas e em graus), e os
valores de diferentes variáveis nesse ponto.
A classe CSVDataLoader é responsável por abrir um ficheiro de dados e carregar o
seu conteúdo para memória ao iniciar uma aplicação. É passado como argumento o path
para o ficheiro de dados. Ao invocar a função getData() é aberto um input stream que lê
o ficheiro linha a linha, separando cada valor e armazenando o conteúdo numa ArrayList
de valores float (uma vez que é o formato numérico suportado pelo OpenGL). Por fim,
os dados são armazenados numa classe RubiDataset, que inclui a informação das
variáveis existentes e um HashMap que armazena a informação de todos os pontos de
30
dados agrupados de acordo com um determinado índice (Ex: número da parede). Desta
forma, a biblioteca necessita apenas de extrair os dados pretendidos do objeto
RubiDataset cada vez que pretender gerar uma visualização de dados, como um objeto
GLCubeGlyphMap ou GLPlane.
3.3.4 Georreferenciação e Orientação
Todos os módulos de leitura da georreferenciação e orientação são importados da
biblioteca RUBI original. A classe RubiGLSurfaceView contém uma referência à classe
CamadaRealidadeAumentada da biblioteca RUBI, que utiliza para obter a latitude,
longitude e orientação recolhidas pelos sensores do dispositivo. Neste momento, uma das
limitações do RUBI Glare é a necessidade de trabalhar em coordenadas cartesianas para
poder posicionar corretamente os gráficos 3D em relação à perspetiva do utilizador.
Embora os dados existentes incluam as coordenadas cartesianas dos pontos, no sistema
geodésico ETRS89, o sensor de GPS (e API do Android) permitem apenas a leitura de
coordenadas em graus, que a biblioteca não consegue converter no formato desejado. Para
colmatar esta limitação, desenvolveu-se uma solução temporária em que são
estabelecidos um conjunto de ponto de interesse, para os quais o DEGGE forneceu as
coordenadas ETRS89 (ver o Anexo B). A biblioteca, neste momento, opera apenas nestes
pontos predefinidos. Pretende-se que, no futuro, seja adicionado um algoritmo de
conversão de coordenadas na própria biblioteca capaz de correr em tempo real,
permitindo o seu funcionamento sem quaisquer limitações a nível da posição do
observador.
Surgiu também a necessidade de fazer pequenos ajustes à classe PosOri da biblioteca
RUBI, no sentido de ajustar os dados recolhidos pelo acelerómetro. Descobriu-se que
nem todos os dispositivos possuem os seus sensores calibrados ou posicionados da mesma
forma, o que obriga a que, em muitos casos, seja necessário ajustar os valores devolvidos
conforme a marca e o modelo do dispositivo. No caso concreto do Asus TF300T, o
acelerómetro não devolvia valores de inclinação corretos, existindo um desfasamento de
cerca de 20º entre a inclinação real do dispositivo e a inclinação medida pelo sensor, o
que levou a pequenos ajustes ao código original.
31
Capítulo 4
Aplicação de Visualização de Radiação Solar
Para a validação experimental das potencialidades da biblioteca RUBI Glare foi
desenhada e implementada uma aplicação que a utiliza para a visualização de níveis de
radiação solar sobre edifícios. A aplicação segue os padrões de desenho do sistema
operativo Android [ADP] na implementação da sua interface com o utilizador, tendo sido
otimizada para melhor usabilidade num tablet, com orientação de ecrã horizontal.
A aplicação possui determinados requisitos a nível de hardware e de sistema
operativo para poder ser instalada e executada. Estes são:
Sistema Operativo: Android 3.0 Honeycomb (ou superior)
Permissões de Execução:
android.permission.ACCESS_FINE_LOCATION para poder utilizar
os recursos de GPS.
android.permission.CAMERA para aceder à câmara fotográfica do
dispositivo.
android.permission.WRITE_EXTERNAL_STORAGE para permitir a
leitura (e escrita) de conteúdo da memória do dispositivo ou de um cartão
SD (a permissão de escrita é necessária para a execução do navegador de
ficheiros).
Recursos de hardware:
OpenGL ES 1.1: A aplicação recorre à especificação 1.1 do OpenGL ES.
Câmara fotográfica: A aplicação requer obrigatoriamente pelo menos
uma câmara fotográfica para funcionar.
Focagem automática (opcional): Se a câmara fotográfica o suportar, a
aplicação recorre à focagem automática da imagem, na tentativa de obter
imagens mais nítidas.
GPS: A aplicação requer que o dispositivo possua um sensor de GPS.
Acelerómetro: A aplicação requer que o dispositivo possua um
acelerómetro.
Bússola digital: A aplicação requer que o dispositivo possua uma bússola
digital.
32
Orientação horizontal: A aplicação só é executada em orientação de ecrã
horizontal (deitado), logo o dispositivo deve suportar essa orientação.
Todos os requisitos acima listados constam do ficheiro AndroidManifest.xml,
fazendo com que o ficheiro APK executável só possa ser instalado quando o dispositivo
alvo os cumpra na totalidade.
De seguida serão introduzidos os modos de visualização disponíveis ao utilizador,
quais os parâmetros que podem ser ajustados e quais as opções e funcionalidades
adicionais a que o utilizador tem acesso. É também descrita a organização e o conteúdo
da interface com o utilizador e explicado o funcionamento do modo de animação. Por fim
é apresentada uma análise ao desempenho da aplicação, nomeadamente na rapidez de
execução e precisão das técnicas de alinhamento.
4.1 Modos de Visualização
A aplicação possui quatro modos de visualização para variáveis escalares, como
ilustra a Figura 4.1. Os dois modos principais, superfícies coloridas e glifos coloridos,
permitem a visualização de dados de uma só variável, enquanto os outros dois modos,
superfícies com glifos e superfícies coloridas com deformação, permitem visualizar em
simultâneo duas variáveis ou a mesma variável com duas representações distintas.
Superfícies coloridas – Os dados são projetados segundo malhas poligonais criadas
a partir de grelhas com topologia regular. Uma cor é atribuída a cada valor e existe
interpolação de cor entre pontos, resultando numa superfície compacta com um efeito
contínuo de gradação de cores. É possível escolher a variável e a escala de cores
associada à visualização (Figura 4.1a).
(a) (b) (c) (d)
Figura 4.1 Exemplo dos quatro modos de visualização, aplicados sobre a mesma superfície do
conjunto de dados.
33
Glifos coloridos – Sobre cada posição do espaço de dados é desenhado um glifo, em
forma de cubo, posicionado e colorido individualmente (Figura 4.1b). O volume
destes cubos pode ser aumentado até se tornarem adjacentes, gerando uma superfície
de mosaicos coloridos, ou diminuído de forma a distinguir cubos e posições
individuais, com espaçamento entre si. Na sua dimensão mínima permite visualizar
os dados como nuvens de pontos (Figura 4.2). Tal como no caso anterior, é possível
escolher a variável e a escala de cores associada à visualização
Superfícies com glifos – As visualizações de superfícies e glifos podem ser
combinadas de forma a mostrar duas variáveis em simultâneo (Figura 4.1c). A
variável e escala de cores para cada tipo de visualização podem ser selecionadas
independentemente, sendo os glifos sobrepostos às superfícies coloridas.
Superfícies coloridas com deformação – A visualização de superfícies coloridas
pode ser complementada com a aplicação de uma deformação, de acordo com uma
variável de dados que é especificada pelo utilizador (Figura 4.1d). A deformação
consiste em deslocar os pontos da malha poligonal segundo um vetor normal à
superfície e que aponta para o semi-espaço onde se encontra o utilizador. É possível
também ajustar a intensidade da deformação, sendo que esta já sofre um ajuste
automático conforme a variável selecionada. Devido à dificuldade na perceção do
relevo das superfícies, este modo requer ainda melhoramentos para ser eficaz no
contexto da realidade aumentada.
Figura 4.2 Comparação da visualização de glifos em diferentes dimensões.
34
4.2 Opções Adicionais
Para cada modo de visualização é possível selecionar a escala de cor a associar à
variável em estudo. Para cada escala de cor, existe também uma escala inversa,
considerando que alguns dos valores relativos aos dados são referentes à quantidade de
sombra em vez da radiação solar. As escalas de cores existentes são baseadas em
[SilvaS11], e escolhidas pela sua utilidade na análise de radiação solar. Estas são
apresentadas na Figura 4.3.
Adicionalmente, é possível ajustar os níveis de opacidade dos gráficos. No
contexto da RA, esta opção é muito importante, uma vez que deve existir um balanço
entre a visibilidade dos dados e a visibilidade do edifício sobre o qual estes são projetados.
Dependendo das condições do ambiente exterior, e das características da visualização, o
nível de opacidade adequado pode variar, e assim, acrescentou-se a opção para o ajustar.
Figura 4.3 Escalas de cor utilizadas na aplicação. De cima para baixo: rainbow,
blue-white-red e temperature.
Figura 4.4 Dados sobrepostos à imagem da câmara, com transparência a 50% e oclusão ativada.
35
Outra funcionalidade oferecida é a opção de desligar ou ligar a oclusão que
controla se um gráfico mais à frente oculta ou não outro mais atrás. O ajuste da opacidade
e da oclusão são essenciais para a usabilidade da aplicação de RA, permitindo ao
utilizador enquadrar mais facilmente a visualização de dados sobre o contexto do espaço
físico em que este se encontra (Figura 4.4).
Relativamente ao alinhamento dos gráficos com a imagem da câmara, existem
também opções disponíveis para o utilizador, cuja principal utilidade é colmatar as
limitações do hardware. Assim, foi adicionado um modo de ajuste manual dos gráficos,
semelhante ao mecanismo utilizado em [Honkamaa07], que permite retificar a posição
destes arrastando-os com o dedo sobre o ecrã táctil. Esta funcionalidade é essencial em
situações em que a bússola digital não funciona corretamente devido a interferência
eletromagnética ou pelo facto de não estar calibrada. A sensibilidade e o sentido do
arrastamento podem também ser ajustados.
Uma vez que a medição de altitude através do GPS é demasiado imprecisa, a
aplicação utiliza uma altitude fixa que pode ser ajustada pelo utilizador.
Também foi desenvolvida uma função de “trancar” a vista de RA, inspirada na
solução apresentada em [White09]. Através de um botão é possível “congelar” totalmente
a imagem apresentada pelo aparelho (quer a vista da câmara, quer os gráficos 3D) para
mais confortavelmente consultar a informação sem a necessidade de apontar o aparelho
constantemente na direção pretendida.
36
4.3 Interface com o Utilizador
Respeitando as normas Android, na parte superior do ecrã encontra-se a barra de
ações (Figura 4.5a) que dá acesso aos diferentes menus e funções da aplicação que estão
disponíveis: abrir ficheiro de dados, trancar/destrancar vista, abrir controlos da transição
animada de dados e aceder às opções de configuração. À esquerda desta encontra-se a
barra de estado do GPS (Figura 4.5b) com informação se o GPS está ou não em
funcionamento, a latitude, longitude, altitude, e margem de erro obtidas pelo mesmo. O
indicador da bússola (Figura 4.5c) encontra-se centrado na parte inferior da interface. A
legenda (Figura 4.5d), ou legendas, são desenhadas à direita da bússola e o menu de
controlo da transição animada de dados (quando esta é invocada) situa-se à esquerda da
bússola (Figura 4.5e). O posicionamento destes itens foi pensado para minimizar a
sobreposição dos mesmos com a visualização do edifício. Para melhorar a visibilidade
em situações de grande claridade, optou-se pelo tema Holo Light do Android, com texto
(b) (a)
(e) (c) (d)
Figura 4.5 Interface com o utilizador, com a vista de RA em execução.
37
escuro sobre fundo claro. Mais capturas de ecrã da aplicação podem ser vistas no Anexo
D.
Adicionalmente à interface de RA existe um navegador de ficheiros para selecionar
o ficheiro a abrir, baseado numa biblioteca de código aberto android-filechooser
[BisonH], e um menu de opções de rápido acesso desenhado para tablets, onde todos os
parâmetros de configuração da visualização podem ser ajustados, assim como as
configurações adicionais da aplicação (Figura 4.6). Mais imagens do menu de opções
encontram-se no Anexo E.
Figura 4.6 Imagem do navegador de ficheiros integrado (acima), e do menu
de definições (abaixo).
38
4.4 Transição Animada de Dados
Um dos objetivos a cumprir foi a possibilidade de gerar transições animadas que
facilitam comparações entre dados relacionados. Para tal implementou-se um modo de
animação que pode ser iniciado e parado pelo utilizador, e que altera em tempo real os
parâmetros de visualização a serem apresentados (funcionando mesmo que a vista esteja
“trancada”). O utilizador pode ainda selecionar a sequência de variáveis a apresentar, e a
velocidade da transição. Esta funcionalidade poderá ser estendida para animações da
mesma variável ao longo do tempo, mas uma vez que os dados fornecidos não possuem
informação temporal associada, foi feita a demonstração de conceito com a transição entre
diferentes variáveis.
Ao invocar o menu de controlo da animação (através da barra de ações) este passa a
ocupar o canto inferior esquerdo do ecrã. O botão do lado esquerdo permite iniciar e parar
a animação (Figura 4.7a). A barra de progresso situa-se na parte inferior e funciona de
forma semelhante à de um leitor de vídeo, podendo ser arrastada com o dedo para saltar
para qualquer momento da animação (Figura 4.7b). Do lado direito encontra-se a legenda
que indica a instância da animação em curso (por exemplo, a variável ou instante de
tempo atuais) (Figura 4.7c). A disposição destes itens impede que qualquer informação
fique obstruída pelas mãos ou dedos do utilizador enquanto este interage com a aplicação.
(a)
(b)
(c)
Figura 4.7 Menu de controlo de animação.
39
4.5 Desempenho e Fiabilidade
Para medir o desempenho da aplicação ao nível da velocidade de processamento,
foram realizadas medições em partes específicas do código, de forma a determinar o
intervalo de tempo entre o início e o fim de determinadas tarefas. Isto não só permite
comparar a eficiência de diferentes implementações, como serve para medir de uma forma
objetiva o desempenho da aplicação e identificar pontos que provocam abrandamentos.
As tabelas 4.1 e 4.2 mostram uma lista de tarefas executadas pela aplicação e a duração
em milissegundos, bem como a taxa de refrescamento do ecrã para cada modo de
visualização. Todos os valores apresentados correspondem ao mínimo e máximo obtido
após 10 medições. O desempenho nunca é exatamente constante e depende de outros
processos do sistema que possam estar a correr em background.
Carregamento do ficheiro de dados (9485 linhas) 13674 e 20738 ms.
Construção da geometria (glyphs) Entre 996 e 1329 ms.
Transição de dados em animação (glyphs) Entre 50 e 189 ms.
Construção da geometria (surfaces) Entre 166 e 199 ms.
Transição de dados em animação (surfaces) Entre 47 e 176 ms.
Construção da geometria (glyphs + surfaces) Entre 1442 e 1582 ms.
Construção da geometria (warped surfaces) Entre 187 e 216 ms.
Tabela 4.1 Intervalos de tempo aproximados para carregamento dos dados e geração e modificação
dos elementos gráficos no ecrã, para cada modo de visualização.
Modo de visualização Taxa de refrescamento
Glyphs 2 fps.
Surfaces Entre 16 e 30 fps.
Glyphs + Surfaces 2 fps.
Warped Surfaces Entre 16 e 30 fps.
Tabela 4.2 Taxa de refrescamento da imagem para cada um dos modos de visualização.
40
É possível constatar que a visualização de superfícies (surfaces) executa com muito
mais rapidez que a visualização de glifos (glyphs), provando que os algoritmos para o
rendering desses glifos necessitam ainda de várias revisões para os tornar mais eficientes
e correrem sem abrandamentos. De igual modo, o carregamento inicial do ficheiro de
dados poderá eventualmente ser otimizado no sentido de tornar a sua leitura mais rápida.
Outro problema é o da precisão dos sensores. Como já foi referido, a altitude de
observação é fixa e pode ser ajustada à mão pelo utilizador, já que o GPS não proporciona
uma medição da altitude suficientemente precisa para as necessidades da aplicação (a
margem de erro pode ser de dezenas de metros). De igual modo, se o utilizador se
aproximar demasiado das paredes do edifício a cobertura de satélites torna-se menor e
por isso a triangulação torna-se menos precisa. O utilizador pode consultar a margem de
erro (em metros) do sensor na barra de estado do GPS na parte superior do ecrã. Durante
o desenvolvimento e teste da aplicação, recorreu-se à aplicação Fake GPS [FakeGPS]
para marcar manualmente a posição do utilizador em casos de maior imprecisão.
Por fim, a bússola digital revelou-se extremamente imprecisa, tornando em muitas
situações totalmente inutilizável. Não foi possível averiguar com clareza se esta
deficiência se deveu a um defeito em particular do Asus TF300T, ou se é generalizado,
embora se saiba que a bússola digital é muito sensível a interferências de campos
eletromagnéticos gerados por outros dispositivos móveis, computadores, ou mesmo cabos
elétricos no chão ou paredes. A imprecisão da bússola levou à necessidade de acrescentar
mecanismos de alinhamento manual, tendo sido implementada a funcionalidade de
arrasto dos gráficos com o dedo para compensar esta imprecisão.
41
Capítulo 5
Testes com Utilizadores
5.1 Metodologia
Na fase final do projeto procedeu-se à realização de testes com utilizadores, seguindo
um modelo de entrevista baseado em inquirição contextual. Os dois grandes objetivos
desta fase de testes foram a avaliação da qualidade da aplicação (e em particular da sua
usabilidade e utilidade) e ainda a recolha de sugestões para melhorias futuras e adição de
novas funcionalidades. Foi elaborado um guião de entrevista (Anexo C) que estabelece
uma sequência de tarefas para o utilizador executar enquanto vão sendo registadas as suas
opiniões e a avaliação de cada tarefa. As tarefas realizadas podem ser agrupadas nos
seguintes blocos:
a) Alinhamento dos gráficos.
b) Visualização de glifos.
c) Visualização de superfícies.
d) Visualização de 2 variáveis com glifos + superfícies.
e) Visualização de superfícies com deformação.
f) Realização de transições animadas.
g) Opiniões globais.
Quanto ao formato das perguntas, estas podem ser categorizadas em 3 tipos (Figura
5.1):
Perguntas de escolha múltipla: utilizadas para quantificar a preferência dos
utilizadores em relação a certas funcionalidades ou alternativas que existem na
aplicação.
Pergunta de classificação: pede-se que utilizador avalie um determinado aspeto
da aplicação numa escala de 1 (mínimo) a 5 (máximo), tal como a facilidade de
realização de uma tarefa ou a clareza da interface.
Perguntas de resposta aberta: utilizadas para recolher opiniões adicionais do
utilizador, sem restringir a sua liberdade de resposta, ou para pedir ao utilizador
que justifique ou clarifique uma resposta dada anteriormente.
42
A duração média de cada teste oscilou entre os 30 minutos e 1 hora. Os testes foram
todos realizados durante o dia e sempre no mesmo local, o Ponto A (localização GPS:
38º45'19.458"N, 9º09'28.188"O) do conjunto de pontos de observação pré-calculados, de
onde se podem observar as paredes do pátio interior do edifício (ver o Anexo B). A
posição escolhida encontra-se livre de qualquer exposição solar direta ao longo do dia,
sendo mais confortável ao utilizador (Figura 5.2). Por esse motivo foi também possível
realizar testes a qualquer hora do dia sem qualquer impacto significativo nas condições
de visibilidade.
Figura 5.1 Exemplo dos diferentes tipos de perguntas realizadas nos testes
com utilizadores.
Figura 5.2 Secção do edifício C6 utilizada nos testes com utilizadores.
43
5.2 Perfil dos Utilizadores
Os testes foram realizados sobre um universo de 22 utilizadores, todos docentes,
funcionários ou alunos da FCUL, com idades compreendidas entre os 20 e os 54 anos.
Embora os testes tenham sido anónimos, uma parte significativa dos utilizadores de
corresponde a stakeholders do projeto, incluindo professores associados ao mesmo (mas
não envolvidos diretamente na implementação) e professores de outros departamentos
que são representativos de potencial público-alvo da aplicação. Esta seleção foi
complementada com a inclusão de diversos alunos de informática da FCUL, permitindo
assim maior quantidade de feedback útil para o melhoramento do projeto.
13; 59%
9; 41%
Género dos Utilizadores
Masculino Feminino
14; 64%
7; 32%
1; 4%
Profissão dos Utilizadores
Estudante Professor Outro
1
3
7
9
21
5 5
8
34 4
6
8
00
2
4
6
8
10
1 2 3 4 5
Experiência dos Utilizadores
Con. Vis. Dados Con. Soft. Dados Exp. Tablets
Figura 5.3 Gráficos da distribuição dos utilizadores de teste por sexo, profissão e níveis de experiência
em visualização de dados, software de vis. de dados e utilização de tablets, numa escala de 1 (pouca) a 5
(muita).
44
No início de cada teste, foi pedido aos utilizadores que se autoavaliassem (numa
escala de 1 a 5) em três categorias distintas: conhecimentos teóricos sobre visualização
de dados, conhecimentos práticos com software de visualização de dados e experiência
na utilização de tablets. A Figura 5.3 mostra a distribuição no sexo e profissão dos
utilizadores, bem como das perguntas de autoavaliação.
5.3 Análise dos Resultados
São de seguida apresentados os resultados da inquirição contextual realizada, com
uma exposição das respostas obtidas e das principais críticas e sugestões. Todos os
resultados que se seguem são apresentados no formato (Nº da pergunta; Média; Desvio
padrão). No Anexo E encontram-se imagens dos menus de opções acedidos no decorrer
dos testes.
5.3.1 Carregamento e alinhamento dos gráficos
A maioria dos utilizadores mostrou satisfação relativamente à facilidade do
alinhamento manual, usando o modo de arrasto (2a; 3,65; 0,79). Ainda assim, uma
quantidade significativa de utilizadores apontou a necessidade de melhorar a fluidez do
arrasto, queixando-se de uma certa lentidão na resposta da aplicação que torna o processo
mais difícil e frustrante do que deveria ser. A maioria dos utilizadores também identificou
imperfeições na sobreposição dos gráficos com a imagem de fundo, em particular nas
paredes mais afastadas do observador (Figura 5.4).
45%
55%
2b) Nota imperfeições na sobreposição dos gráficos com a
imagem de fundo?
Não Sim
10
6
14
1
0
2
4
6
8
10
12
14
16
2a) Facilidade do alinhamento manual
1 (difícil) 2 3 4 5 (fácil)
Figura 5.4 Distribuição das respostas relativamente à facilidade do alinhamento manual, e à existência
ou não de imperfeições na sobreposição dos gráficos sobre a imagem de fundo.
45
A totalidade dos utilizadores (100%) compreendeu a diferença entre o modo de
alinhamento manual e o alinhamento automático (baseado em bússola e acelerómetro).
Quanto às opções de alinhamento (tracking) existentes no menu de opções, A maioria dos
utilizadores considerou a linguagem suficientemente clara para compreender o seu
funcionamento (3a; 4,14; 0,69) (Figura 5.5) mas lançou algumas críticas, tais como o
ícone representativo menu de opções não ser muito compreensível. Outra sugestão foi
que deveriam existir mais ícones no próprio menu de opções e que as opções de
alinhamento deveriam ser melhor agrupadas (ou por opções de alinhamento manual /
automático ou por opções de posicionamento / orientação).
Quanto à funcionalidade de trancar a vista de RA, a totalidade dos utilizadores
compreendeu o seu funcionamento e objetivo, tendo considerado a função extremamente
útil e bem-vinda. Com exceção de dois utilizadores que não compreenderam o ícone
utilizado, os restantes consideraram a o símbolo de um cadeado bastante claro e intuitivo.
5.3.2 Visualização de uma variável
No modo de visualização de glifos, a maioria dos utilizadores considerou o ajuste
dos parâmetros (dimensão dos cubos, escala de cores e variável) fácil ou muito fácil (5a;
4,59; 0,49) (6a; 4,64; 0,58). Apesar de satisfeitos com as opções disponíveis para a
dimensão dos glifos, alguns utilizadores sugeriram que a dimensão deveria ser ajustável
através de um slider, e esse ajuste deveria ser observável em tempo real na vista de RA.
A linguagem das opções de glifos foi considerada clara e compreensível para a maioria
0 0
4
11
7
0
2
4
6
8
10
12
3a) Clareza das opções de alinhamento
1 (confusas) 2 3 4 5 (claras)
Figura 5.5 Distribuição das respostas quanto à clareza e compreensibilidade das opções do
menu relativas ao alinhamento.
46
dos utilizadores (5b; 4,32, 0,63), com um utilizador a classificar a mesma de “demasiado
técnica” (Figura 5.6).
Em relação à seleção e utilização de escalas de cores, a maioria dos utilizadores
indicou satisfação com atual interface de para a sua seleção (6c; 4,05; 0,77), mas uma
quantidade significativa queixou-se que deveria existir uma pré-visualização da escala de
cores ao invés de um nome identificativo das mesmas. Quando à escala de cores preferida
pelos utilizadores, constatou-se que a maioria dos professores escolheram a escala de
arco-íris (rainbow), em parte por estarem mais habituados a ela e em parte por esta ser
mais segmentada e permitir uma análise mais minuciosa (Figura 5.7). Por outro lado, os
estudantes escolheram maioritariamente a escala de temperatura, por acharem mais
intuitiva face à consulta de radiação solar.
0 01
6
15
0
5
10
15
20
6a) Facilidade do ajuste das opções de Glyphs
1 (fácil) 2 3 4 5 (difícil)
0 0
2
11
9
0
5
10
15
5b) Clareza das opções deGlyphs
1 (confusas) 2 3 4 5 (claras)
01
3
12
6
0
5
10
15
6c) Satisfação com o selector de escalas de cor
1 (pouca) 2 3 4 5 (muita)
9
11
2
4
10
0
5
0
2
0
2
4
6
8
10
12
Rainbow Temperature Sem preferência
6d) Escala de cores preferida
Total Estudantes Professores
Figura 5.6 Distribuição das respostas quanto à clareza das opções do menu relativas a glyphs, e
quanto à facilidade em ajustar essas mesmas opções.
Figura 5.7 Distribuição das respostas quanto à satisfação com o seletor de escalas de cor, e quanto à
escala de cores preferida segundo a profissão.
47
Alguns utilizadores sugeriram a adição de uma escala em tons de cinzento para a
visualização da quantidade de horas de sombra, mas a maioria achou que as escalas de
cor atualmente presentes na aplicação são suficientes.
Foi de seguida solicitado aos utilizadores que alternassem para o modo de
visualização de superfícies coloridas (surfaces), e avaliassem a facilidade em alternar de
modo. A totalidade dos utilizadores considerou fácil ou muito fácil (7a; 4,59; 0,49)
(Figura 5.8). Alguns utilizadores sugeriram que deveria existir uma explicação textual de
cada modo de visualização mo menu de opções, que as opções para cada modo deveria
aparecer e desaparecer dinamicamente conforme o modo selecionado, ou que o seletor de
modo deveria estar presente na própria vista de RA. Foi de seguida solicitado aos
utilizadores que experimentassem o ajuste da oclusão e da opacidade dos gráficos. Os
utilizadores acharam útil e importante a existência destas duas opções, e a maioria
classificou o seu ajuste como muito fácil (8a; 4,77; 0,41).
Finalmente, os utilizadores foram inquiridos quanto ao modo de visualização de uma
variável que preferiam. No total, a maioria dos utilizadores preferiu o modo de superfícies
coloridas (surfaces). No entanto, ao separar os utilizadores por profissão, notou-se que os
professores preferiram maioritariamente a visualização de glifos (glyphs), enquanto os
estudantes favoreceram mais o modo de surfaces (Figura 5.9) Analisando as respostas
segundo o sexo, nota-se que as mulheres tiveram uma preferência mais acentuada pelo
modo de surfaces que os homens, que foram mais divididos na sua escolha. Quem
preferiu o modo surfaces alegou esta se integra melhor com as imagens do edifício, parece
mais natural e realista, e a variação de valores ao longo da superfície é mais percetível
devido à gradação de cor. Quem preferiu a visualização de glyphs defendeu que faz mais
0 0 0
9
13
0
5
10
15
7a) Facilidade em alterar o modo de visualização.
1 (difícil) 2 3 4 5 (fácil)
0 0 0
5
17
0
5
10
15
20
8a) Facilidade em ajustar oclusão e opacidade
1 (difícil) 2 3 4 5 (fácil)
Figura 5.8 Distribuição das respostas relativamente à facilidade em alternar entre modos de
visualização e em ajustar as opções de oclusão e opacidade.
48
sentido com dados correspondentes a nuvens de pontos, que a informação é mais
minuciosa e que representa os valores de forma discreta, fugindo a erros e aproximações.
5.3.3 Visualização de duas variáveis
No modo de visualização de Glifos + Superfícies foi realizada uma avaliação da
facilidade de utilização do mesmo, incluindo o acesso e ajuste das opções de configuração
(seleção de variáveis e escalas de cores individuais e dimensão dos glifos). Todos os
utilizadores consideraram a utilização fácil ou muito fácil (9a; 4,64; 0,48). De igual modo,
as opções de configuração foram classificadas de claras ou bastante claras (9b; 4,73;
0,45), como mostra a Figura 5.10.
10
2
7
5 56
4
2
4
2
6
1
54
2
0
2
4
6
8
10
12
Total Professores Estudantes Masculino Feminino
8d) Modo de visualização preferido
Surfaces Glyphs Sem preferência
0 0 0
8
14
0
5
10
15
9a) Facilidade de utilização do modo Glifos + Superfícies
1 (difícil) 2 3 4 5 (fácil)
0 0 0
6
16
0
5
10
15
20
9b) Clareza das opções de Glifos + Superfícies
1 (confusas) 2 3 4 5 (claras)
Figura 5.9 Escolha dos utilizadores quanto ao modo de visualização preferido, e separação das
respostas obtidas segundo a idade e o sexo dos utilizadores.
Figura 5.10 Classificação atribuída pelos utilizadores à facilidade de utilização do modo de Glyphs
+ Surfaces e à clareza das opções de configuração desse modo.
49
A totalidade dos utilizadores mostrou-se satisfeita com a informação apresentada
pela legenda e com a disposição das duas legendas. Foi sugerido o posicionamento
automático da legenda onde esta for menos intrusiva, e a possibilidade de utilizar um
gradiente de cor diferente para cada variável representada, de modo a evitar repetição de
cores nas duas variáveis.
Dada a natureza experimental do modo de superfícies deformadas, e o facto de a
sua implementação ser ainda pouco satisfatória, foi feita uma demonstração aos
utilizadores do seu propósito e de seguida solicitou-se aos mesmos que experimentassem
ajustar as configurações de deformação e contemplassem os resultados. Os inquiridos
consideraram as opções de deformação bastante claras e compreensíveis (10a; 4,57; 0,49)
(Figura 5.11). Quando questionados sobre a utilidade de poder representar uma variável
por deformação, as opiniões foram algo dispersas (10b; 3,43; 0,9), com a maioria dos
utilizadores a classificar a funcionalidade de útil, mas a insistir que são necessários vários
melhoramentos para tornar a deformação mais percetível e menos confusa. Alguns
utilizadores apontaram a utilidade da deformação na representação de outros tipos de
dados, como a tensão elétrica ou em representações do solo. Todos os inquiridos
preferiram o modo de Glifos + Superfícies face ao modo de superfícies deformadas.
5.3.4 Utilização de transições animadas
A última funcionalidade testada foi a realização de transições animadas. Foi
solicitado aos utilizadores que escolhessem um modo de visualização de uma só variável
e de seguida experimentassem a função de animação. Foi também explicado o objetivo
desta função e a sua utilidade para análise temporal dos dados. Quanto à utilização da
animação e à facilidade em manusear os comandos de reprodução, a maioria dos
utilizadores revelou-se muito satisfeita (11a; 4,55; 0,58) (Figura 5.12). Em relação às
0 0 0
9
12
0
5
10
15
10a) Clareza das opções de superfícies deformadas
1 (confusas) 2 3 4 5 (claras)
12
6
11
1
0
5
10
15
10b) Utilidade de representações com deformação
1 (pouca) 2 3 4 5 (muita)
Figura 5.11 Classificação atribuída pelos utilizadores à clareza das opções de configuração do modo
de superfícies deformadas, e quanto à utilidade de um modo destes na visualização dos dados.
50
opções de configuração da animação, mais uma vez a maioria dos utilizadores achou o
seu ajuste muito fácil (12a; 4,73; 0,45) e que as mesmas opções eram suficientemente
claras (12b; 4,36; 0,64), tendo sido sugerido que a escolha de intervalos de tempo fosse
baseada num slider em vez de uma caixa de diálogo, e que sejam no futuro adicionadas
opções para agrupar temporalmente os dados (em anos, meses, dias, horas, etc.).
5.3.5 Questões adicionais
Após a conclusão do teste, e de os utilizadores terem experimentado todas as
funcionalidades da aplicação, estes foram inquiridos a cerca das condições de visibilidade
da mesma. A maioria dos utilizadores classificou a visibilidade dos gráficos de RA, bem
como a visibilidade da interface de utilizador como boas ou muito boas (QAa; 4,41; 0,58)
(QAb; 4,5; 0,58). No entanto, o facto de os testes terem sido realizados num espaço à
sombra pode ter contribuído para as classificações elevadas (Figura 5.13). Vários
utilizadores acharam que a visibilidade se torna muito pior quando a aplicação é utilizada
diretamente debaixo do sol, mas admitiram que essa é uma limitação do próprio ecrã do
aparelho e não da aplicação, bem como que o modo de trancar a imagem ajuda em parte
a colmatar esta limitação.
Numa avaliação geral da aplicação, a maioria dos utilizadores classificou esta de
“boa” (QAd; 4,32; 0,55), chamando apenas a atenção para potenciais melhorias, como
por exemplo, corrigir a imprecisão do sistema de alinhamento através de sensores. Outra
sugestão foi a possibilidade de guardar snapshots e animações para visualização posterior
(ou no próprio tablet, ou num PC).
0 01
8
13
0
5
10
15
11a) Facilidade de utilização da animação
1 (difícil) 2 3 4 5 (fácil)
0 0 0
6
16
0
5
10
15
20
12a) Facilidade de ajuste das opções de animação
1 (difícil) 2 3 4 5 (fácil)
Figura 5.12 Classificação atribuída pelos utilizadores à facilidade de utilização da animação, e à
facilidade de ajuste das opções de animação.
51
0
2
4
6
8
10
12
14
1 (má) 2 3 4 5 (boa)
Visibilidade da aplicação
Gráficos de RA Interface de Utlizador
0 01
13
8
0
2
4
6
8
10
12
14
Classificação global da aplicação
1 (má) 2 3 4 5 (boa)
Figura 5.13 Classificação atribuída pelos utilizadores à visibilidade quer dos gráficos de RA quer da
interface de utilizador, e classificação global da aplicação.
52
53
Capítulo 6
Conclusões e Trabalho Futuro
Neste documento foi apresentada uma biblioteca para o sistema operativo Android,
designada RUBI Glare, que implementa a visualização de grandezas escalares em
realidade aumentada. Esta biblioteca resultou da extensão da biblioteca RUBI, que
originalmente suportava a visualização de pontos de interesse com geolocalização,
passando a permitir a visualização de dados com recurso a gráficos 3D, através de glifos
tridimensionais ou de superfícies coloridas, com ou sem deformação. Foram ainda
apresentados detalhes acerca do carregamento e processamento dos dados, e dos
mecanismos que permitem a sua visualização e o alinhamento com base nos sensores do
dispositivo móvel.
Com base nesta biblioteca, foi construída uma aplicação que demonstra as
funcionalidades da mesma, permitindo a visualização dos níveis de radiação solar sobre
as paredes do edifício C6 da FCUL. Apresentou-se a interface com o utilizador
desenvolvida, as opções de configuração existentes e foi feita uma análise sucinta do
desempenho e fiabilidade da aplicação.
Pode-se desde já concluir que os objetivos pretendidos para este projeto foram
cumpridos, tendo sido desenvolvido de raiz com sucesso um motor de gráficos 3D capaz
de suportar a visualização de dados científicos. O facto da biblioteca RUBI Glare seguir
uma estrutura modular e ser de código aberto, à semelhança da sua predecessora RUBI,
permite que um programador que pretenda construir aplicações móveis de RA possa
acrescentar as funcionalidades que entenda que estão em falta, ou modificar e otimizar as
existentes sem constrangimentos. Ainda assim, existem certas limitações. A maior de
todas é a falta de precisão dos sensores, que obrigou a aplicar soluções de alinhamento
manual. Além disso, partes do código ainda não se encontram suficientemente otimizadas
de forma a garantir um desempenho rápido e utilização fluida (com é o caso da
visualização de glifos).
Algumas propostas de melhoramentos, bem como ideias para trabalho futuro são
listadas de seguida:
Opções adicionais para a consulta dos dados: aplicação de filtros para
destacar apenas intervalos de valores.
Realizar uma ampliação semântica, em que o utilizador pode selecionar um
ponto da visualização para ver informação adicional, com mais pormenor.
54
Implementar um algoritmo de oclusão mais sofisticado, que carregue para a
memória gráfica apenas os objetos mais perto do observador e exclua
totalmente objetos mais afastados.
Melhorar o algoritmo de geração de conjuntos de glifos, de forma a tornar a
taxa de refrescamento do ecrã mais rápida e minimizar o lag na interface de
utilizador.
Experimentar a integração de uma pré-visualização fotográfica do edifício na
técnica de alinhamento manual por arrasto, de forma a dar mais contexto ao
utilizador.
Experimentar soluções de carregamento dos dados a partir de um servidor
remoto.
Adaptar a interface de transição animada para seleção específica de evolução
temporal, e ajustar o código em conformidade.
Melhorar a GUI da aplicação desenvolvida, tornando as principais opções de
configuração mais acessíveis e rápidas de ajustar.
Adicionar opções para calibrar manualmente o acelerómetro e bússola
conforme o dispositivo utilizado.
Adicionar suporte para mais línguas na aplicação, aproveitando as
capacidades da API do Android para esse efeito.
Possibilidade de guardar snapshots da visualização ou de animações para
analisar posteriormente.
55
Bibliografia
[ADP] Android Design Patterns (acedido em 6-9-2013).
<http://developer.android.com/design/patterns/index.h
tml>
[AndAR] AndAR – Android Augmented Reality (acedido em 12-9-2013).
<https://code.google.com/p/andar/>
[Android] Android – Página Oficial (acedido em 15-9-2013).
<http://www.android.com>
[BisonH] android-filechooser by Hai Bison (acedido em 18/9/2013)
<http://www.haibison.com/libs/android-filechooser>
[Chua] Chua’s OpenGL Programming Notes (acedido em 16-9-2013)
<http://www.ntu.edu.sg/home/ehchua/programming/opengl
/CG_BasicsTheory.html>
[FakeGPS] Fake GPS location – Google Play Store (acedido em 18-9-2013)
<https://play.google.com/store/apps/details?id=com.le
xa.fakegps>
[Gimeno10] J. Gimeno, P. Morillo, S.Casas, M. Fernández. An Augmented
Reality (AR) CAD System at Construction Sites. In Augmented
Reality: Some Emerging Application Areas, pp. 15-32. InTech.
(2010).
<http://www.intechopen.com/books/augmented-reality-
some-emerging-application-areas>
[GLProg] OpenGL ES Programming Guide for iOS (acedido em 16-9-2013)
<https://developer.apple.com/library/ios/documentatio
n/3ddrawing/conceptual/opengles_programmingguide/Open
GLESApplicationDesign/OpenGLESApplicationDesign.html>
[Hakkarainen09] M. Hakkarainen, C. Woodward, K. Rainio. Software Architecture
for Mobile Mixed Reality and 4D BIM Interaction. In Proc. 25th
CIB W78 Conference, Istanbul, Turkey, pp. 517-524. (2009).
[Helfrich-
Schkarbanenko12]
A. Helfrich-Schkarbanenko, V. Heuveline, R. Reiner, S.
Rittersbusch. Bandwidth-Efficient Parallel Visualization for
Mobile Devices. In INFOCOMP 2012, The Second International
Conference on Advanced Communications and Computation,
Venice, Italy, pp. 106-112. (2012).
<http://emcl.uni-hd.de/fileadmin/images/Publications/
Preprints/emcl-preprint-2012-07.pdf>
56
[Heuveline11] V. Heuveline, S. Ritterbusch, S. Ronnås. Augmented Reality for
Urban Simulation Visualization. In EMCL Preprint Series, 7-2012.
Engineering Mathematics and Computing Lab (EMCL), Karlsruhe
Institute of Technology (KIT), Karlsruhe, Germany (2011).
[Honkamaa07] P. Honkamaa, S. Siltanen, J. Jäppinen, C. Woodward, O. Korkalo.
Interactive Outdoor Mobile Augmentation Using Markerless
tracking and GPS. In Proc. Virtual Reality International
Conference (VRIC), Laval, France, pp. 285-288. (2007).
[Kim12] I. Kim. An Introduction to Augmented Reality. (Seminar Report)
In COMPSCI 705 S1 C. Department of Electrical and Computer
Engineering, University of Auckland, Auckland, New Zealand
(2012).
[Layar] Layar - Augmented Reality (acedido em 12-9-2013).
<http://www.layar.com>
[LDK] Layar SDK (acedido em 12-9-2013).
<https://www.layar.com/products/custom-
solutions/sdk/>
[Luo11] X. Luo. The Cloud-Mobile Convergence Paradigm for Augmented
Reality. In Augmented Reality: Some Emerging Application Areas,
pp. 33-58. InTech. (2011).
<http://www.intechopen.com/books/augmented-reality-
some-emerging-application-areas>
[MC] Metaio Creator (acedido em 15-9-2013).
<https://www.metaio.com/creator>
[Metaio] Metaio – Augmented Reality Products and Services (acedido em
15-9-2013).
<https://www.metaio.com/products>
[Mixare] Mixare (acedido em 12-9-2013)
<https://code.google.com/p/mixare/>
[Montez12] E. Montez. Visualização de Pontos de Interesse em Dispositivos
Móveis Utilizando Realidade Aumentada. Faculdade de Ciências
da Universidade de Lisboa, Lisboa, Portugal. (Relatório final de
Projeto em Engenharia Informática, 2012).
[OGLES] OpenGL ES – The Standard for Embedded Accelerated 3D
Graphics (acedido em 16-9-2013).
<https://www.khronos.org/opengles/>
57
[SilvaP11a] P. Silva. Transição Entre Ambientes Externos e Internos e
Visualização Adaptativa. Faculdade de Ciências da Universidade
de Lisboa, Lisboa, Portugal. (Relatório final de Projeto em
Engenharia Informática, 2011).
[SilvaP11b] P. Silva, P. Pombinho, A. Afonso, T. Gonçalves, Rubi: An Open
Source Android Platform for Mobile Augmented Reality
Applications. In Workshop on Mobile Augmented Reality: Design
Issues and Opportunities (MobileHCI’2011), Stockholm, Sweden
(August 30 to September 2, 2011).
[SilvaS11] S. Silva, B. Santos, J. Madeira. Using Color in Visualization: A
Survey. In Computers & Graphics, 35(2), pp. 320-333. (2011).
<http://www.sciencedirect.com/science/article/pii/S00
97849310001846>
[Tegra] Tegra Whitepaper: The Benefits of Quad-Core CPUs in Mobile
Devices; NVIDIA Corporation (2011)
<http://www.nvidia.com/content/PDF/tegra_white_papers/tegra-
whitepaper-0911a.pdf>
[WDK] Wikitude SDK for Android – Documentation (acedido em 12-9-
2013).
<http://developer.wikitude.com/documentation/android>
[White09] S. White, S. Feiner. SiteLens: Situated Visualization Techniques
for Urban Sites Visits. In Proc. ACM HCI 2009, Boston, MA, pp.
1117-1120. (2009).
[Wikitude] Wikitude – Página Oficial (acedido em 12-9-2013).
<http://www.wikitude.com>
[Woodward11] C.Woodward, M. Hakkarainen. Mobile Mixed Reality System for
Architectural and Construction Site Visualization. In Augmented
Reality: Some Emerging Application Areas, pp. 115-130. InTech.
(2011).
<http://www.intechopen.com/books/augmented-reality-
some-emerging-application-areas>
58
59
Anexo A: Diagramas UML
Diagrama de Pacotes
60
Diagrama de Classes (Métodos e atributos públicos)
61
Anexo B: Mapa dos Pontos de Observação
62
Coordenadas dos pontos de observação e conversão ETRS89 correspondente:
Ponto Latitude Longitude X (ETRS89) Y (ETRS89)
A +38.7554 -9.1578 -89073.8112905126 -100845.943866505
B +38.7556 -9.1580 -89075.0785822945 -100802.642947115
C +38.7559 -9.1580 -89087.7632784584 -100774.43397369
D +38.7557 -9.1577 -89041.3296108869 -100805.160295271
E +38.7549 -9.1575 -89045.0193321766 -100900.40707597
F +38.7550 -9.1580 -89092.0548298605 -100870.47341901
G +38.7551 -9.1585 -89113.9534209706 -100877.064174491
H +38.7553 -9.1571 -89013.2486284419 -100862.697587014
I +38.7559 -9.1573 -89034.2264643469 -100771.540393421
J +38.7563 -9.1573 -89027.6801817311 -100744.521566095
L +38.7566 -9.1577 -89052.7972881496 -100708.19831183
M +38.7562 -9.1581 -89065.2326000907 -100800.346089177
N +38.7562 -9.1579 -89080.1587405765 -100766.98250974
O +38.7561 -9.1580 -89099.5967426833 -100751.415107231
P +38.7562 -9.1587 -89101.5472235379 -100733.234525005
63
Anexo C: Guião de Testes com Utilizadores
Inquirição contextual para utilizadores do RUBI Glare
Junho de 2013
INTRODUÇÃO:
Realidade aumentada é uma tecnologia que sobrepõe gráficos gerados por
computador a imagens captadas do mundo real. O RUBI Glare (“GL Augmented
REality”) é uma aplicação para tablets cuja função é a visualização de dados científicos
em realidade aumentada. A aplicação utiliza imagens captadas pela câmara do tablet,
em conjunto com um motor de gráficos 3D para apresentar sobre as imagens do mundo
real uma representação dos dados relativos à exposição solar sobre os edifícios do
campus da FCUL. Para assegurar que estes gráficos são corretamente posicionados e
alinhados com as imagens da câmara, são utilizados diversos sensores do aparelho que
permitem calcular a sua posição e orientação, como o GPS, acelerómetro e bússola.
DADOS PESSOAIS: Idade:
Sexo:
Profissão:
Área de Estudos / Especialização:
Conhecimentos de visualização de dados:
1 (poucos) 2 3 4 5 (muitos)
Experiência com software de visualização de dados:
1 (pouca) 2 3 4 5 (muita)
64
Experiência de utilização de tablets:
1 (pouca) 2 3 4 5 (muita)
Observações adicionais:
GUIÃO DE UTILIZAÇÃO:
1º - Iniciar a aplicação RUBI Glare.
2º - Posicionar o tablet com as duas mãos, na vertical, e perpendicular ao chão.
Ter o cuidado de não colocar as mãos ou os dedos em cima do ecrã. Segurar o
tablet na direção pretendida, de forma a enquadrar a câmara com as paredes do
edifício. Para ajustar a posição dos gráficos, arrastar o dedo sobre o ecrã
(sugestão: pode ser ao canto do ecrã).
a) Facilidade do alinhamento:
1 (difícil) 2 3 4 5 (fácil)
b) As sobreposição dos gráficos parece-lhe deformada / irrealista?
Sim: Não:
65
c) Sente necessidade de maior feedback enquanto espera a geração dos
gráficos?
Observações:
3º - Nas definições, aceder à categoria Tracking (Alinhamento). Desativar o modo
de arrasto (drag mode) e regressar ao ecrã principal. Observar a orientação
automática dos gráficos através da bússola e acelerómetro. De volta às
definições de alinhamento, reativar o modo de arrasto. Se quiser, ajuste a
sensibilidade do arrasto para um valor mais satisfatório. Observar os resultados.
a) Clareza / compreensão das opções no menu:
1 (confusa) 2 3 4 5 (clara)
b) Compreendeu a diferença entre os dois modos de alinhamento?
Sim: Não:
c) Explique:
66
Observações:
4º - Utilizar o botão “trancar vista”, situado na barra de ações no canto superior
direito, para trancar a imagem. Usar novamente para destrancar.
a) Compreendeu o objetivo desta função?
Sim: Não:
b) Explique:
Observações:
(encontrou bem o botão?)
67
5º - Abrir o menu de definições. Nas opções gráficas, opções de glyphs, alterar o
tamanho dos cubos. Regressar à vista de RA (Realidade Aumentada) carregando
no botão de retrocesso.
a) Facilidade de alterar a dimensão dos glyphs:
1 (difícil) 2 3 4 5 (fácil)
b) Clareza / compreensão das opções no menu:
1 (confusa) 2 3 4 5 (clara)
c) Sugere outra forma geométrica para os glyphs, além de cubos?
d) A forma de escolher o tamanho é satisfatória?
Sim: Não:
e) Os tamanhos disponíveis para escolha são satisfatórios?
Sim: Não:
Observações:
(a nomenclatura: cubos ou ícones?)
68
6º - Abrir o menu de definições. Experimentar alterar a variável e a escala de
cores relativas aos glyphs. Regressar à vista de RA carregando no botão de
retrocesso.
a) Facilidade de alteração dos parâmetros:
1 (difícil) 2 3 4 5 (fácil)
b) Clareza / compreensão das opções no menu:
1 (confusa) 2 3 4 5 (clara)
c) A forma de escolher a escalas de cor é satisfatória?
1 (pouco) 2 3 4 5 (muito)
d) Qual das escalas de cor acha mais intuitiva?
e) Sugere outras escalas de cor?
Observações:
(adições / melhorias aos mapas de cor?)
69
7º - Abrir o menu de definições. Alterar o modo de visualização para superfícies
coloridas (Surfaces). Regressar à vista de RA carregando no botão de
retrocesso.
a) Facilidade da seleção do modo de visualização:
1 (difícil) 2 3 4 5 (fácil)
Observações:
8º - Novamente nas definições, e mantendo o modo de visualização em
superfícies, alterar as opções de oclusão e o nível de opacidade. Na vista de RA,
arrastar a imagem com o dedo para observar o resultado de alterar essas
definições.
a) Facilidade de alteração das opções:
1 (difícil) 2 3 4 5 (fácil)
b) Considera o ajuste da oclusão útil / vantajoso?
Sim: Não:
c) Considera o ajuste da opacidade útil / vantajoso?
Sim: Não:
70
d) Qual dos modos de visualização prefere?
Superfícies coloridas (Surfaces): Cubos (Glyphs):
e) Porquê?
Observações:
9º - Nas preferências, escolher o modo de visualização de Superfícies + Cubos
(com 2 variáveis), e escolher o mapa de cores e a variável para cada um.
Observar na vista de RA a sobreposição dos dois modos, com uma legenda
separada para cada variável. Regressar à preferência e mudar somente para
glyphs ou superfícies coloridas.
a) Facilidade de realização da tarefa:
1 (difícil) 2 3 4 5 (fácil)
b) Clareza / compreensão das opções no menu:
1 (confusa) 2 3 4 5 (clara)
c) A informação apresentada pela legenda é compreensível?
Sim: Não:
71
d) A disposição das duas legendas é clara e intuitiva?
Sim: Não:
Observações:
10º - Nas definições, Selecionar o modo de superfícies deformadas (Warped
Surfaces). Nas opções para superfícies deformadas, selecionar uma variável
para deformação. Regressar ao ecrã principal e ver o resultado.
a) Clareza / compreensão das opções no menu:
1 (confusa) 2 3 4 5 (clara)
b) Considera vantajosa a possibilidade de representar uma variável por
deformação?
1 (pouco) 2 3 4 5 (muito)
c) Que modo para representar duas variáveis lhe parece mais útil?
Superfícies coloridas + Cubos: Superfícies com deformação:
72
Observações:
11º - Abra novamente as definições e escolha um modo de visualização diferente
(de uma só variável). De regresso à vista de RA, selecionar o botão de animação.
Utilizar os controlos da interface que foi invocada para iniciar/parar a animação.
Arrastar a barra de progresso com o dedo para alternar manualmente entre
etapas da animação. Tocar com o dedo fora do menu para fechar a animação.
a) Facilidade de realização da tarefa:
1 (difícil) 2 3 4 5 (fácil)
b) O tempo de resposta e a fluidez da interface são aceitáveis?
Sim: Não:
Observações:
(a animação é pensada para variáveis com valores temporais associados, permitindo
assistir à evolução temporal)
73
12º - Regressar ao menu de definições e aceder à categoria Animação. Ajustar
as opções de escolha de variáveis e intervalo de transição. Regressar à vista de
RA e repetir a animação.
a) Facilidade de seleção dos parâmetros:
1 (difícil) 2 3 4 5 (fácil)
b) Clareza / compreensão das opções no menu:
1 (confusa) 2 3 4 5 (clara)
c) A forma de escolher os intervalos de tempo é satisfatória?
Sim: Não:
d) Os intervalos de tempo disponíveis são satisfatórios?
Sim: Não:
e) Tem preferência por algum dos modos de visualização quando realiza
animação?
Observações:
74
QUESTÔES ADICIONAIS:
a) A visibilidade dos gráficos sobre a imagem é satisfatória?
1 (pouco) 2 3 4 5 (muito)
b) A visibilidade geral da interface é satisfatória?
1 (pouco) 2 3 4 5 (muito)
c) Existe alguma funcionalidade importante que falte à aplicação?
d) Que avaliação geral faz da aplicação?
1 (má) 2 3 4 5 (boa)
75
Anexo D: Capturas de Ecrã
Visualização de Glifos
Visualização de Superfícies Coloridas
76
Visualização de Glifos + Superfícies
77
Anexo E: Menus de Opções
Menu de opções gráficas
Opções de visualização de Glifos
78
Opções de visualização de Superfícies
Opções de visualização de Glifos + Superfícies
79
Opções de visualização de Superfícies Deformadas
Menu de opções de animação.
80
Menu de opções de alinhamento.
81