Universidade de Trás-os-Montes e Alto Douro
Visualização de dados sensoriais em aplicações de Realidade
Aumentada
Dissertação de Mestrado em Comunicação e Multimédia
Por
Nuno Filipe Frutuoso Ribeiro
Orientador: Doutor Luís Gonzaga Mendes Magalhães
Co-orientador: Doutor Emanuel Soares Peres Correia
Vila Real, 2013
Universidade de Trás-os-Montes e Alto Douro
Visualização de dados sensoriais em aplicações de Realidade
Aumentada
Dissertação de Mestrado em Comunicação e Multimédia
Por
Nuno Filipe Frutuoso Ribeiro
Orientador: Doutor Luís Gonzaga Mendes Magalhães
Co-orientador: Doutor Emanuel Soares Peres Correia
Vila Real, 2013
Orientação Científica:
Doutor Luís Gonzaga Mendes Magalhães
Professor Auxiliar com Agregação do
Departamento de Engenharias da Escola de Ciências e Tecnologia
Universidade de Trás-os-Montes e Alto Douro
Doutor Emanuel Soares Peres Correia
Professor Auxiliar do
Departamento de Engenharias da Escola de Ciências e Tecnologia
Universidade de Trás-os-Montes e Alto Douro
i
ii
“Problemas não são obstáculos, mas oportunidades ímpares de superação e evolução”
Maurício Rodrigues de Morais
À minha família, amigos e colegas
iii
iv
RESUMO
O dia-a-dia é afetado pela constante evolução tecnológica. Uma tecnologia que
tem vindo a ganhar destaque explora a interatividade em tempo real, com a criação de
sistemas que possibilitam a substituição de grande parte ou até mesmo toda a
experiência do utilizador no espaço físico. Esta tecnologia, denominada Realidade
Virtual (RV), deu origem à Realidade Aumentada (RA) que, ao invés da RV, não
procura substituir a totalidade do mundo real mas sim completá-lo, sobrepondo-lhe
objetos virtuais.
A motivação desta dissertação surge da perceção da inexistência de um sistema
que interligue RA, dispositivos móveis e sistemas de aquisição de dados sensoriais e,
visto esta ser uma área pouco explorada, entende-se ser um trabalho que bem explorado
pode originar um sistema com bastante interesse e utilidade para o utilizador. Desta
forma, o objetivo deste trabalho é a criação de um sistema que interligue estas três
tecnologias: RA, dispositivos móveis e sistemas de aquisição de dados sensoriais.
Neste trabalho fez-se o planeamento de um sistema de visualização de dados
sensoriais em aplicações de RA para dispositivos móveis, composto por três
componentes: contextualização sensorial, gestão de dados sensoriais e visualização de
modelos
virtuais
contextualizados.
Estes
componentes
estão
responsáveis,
respetivamente, pela aquisição de dados sensoriais de contexto, gestão dos dados
adquiridos e pela visualização dos mesmos em modelos virtuais apresentados na
aplicação executada no dispositivo móvel, influenciando ou condicionando o rendering
desses modelos virtuais. Depois do planeamento do sistema, foi concebido e
desenvolvido um sistema com as características já referidas e este foi testado num caso
de uso, através da implementação de um protótipo de uma sala e da utilização de dois
parâmetros sensoriais: intensidade de iluminação e temperatura. Contudo, o componente
de contextualização sensorial foi simulado, tendo sido criado uma plataforma web que
simula as aquisições dos dados através de botões, ao invés da sua aquisição no espaço
físico. Após a sua conceção, os resultados obtidos foram os pretendidos: influenciar ou
condicionar a visualização de modelos virtuais baseados nos valores sensoriais de
contexto utilizados, sendo possível alterar a iluminação de um candeeiro presente no
modelo virtual com base no valor atual da iluminação simulada e da alteração das
v
texturas desse modelo virtual de acordo com a temperatura atual, sendo utilizados cinco
intervalos de temperatura: muito frio, frio, normal, quente e muito quente, aos quais
estão associadas as cores azul-escuro, azul, verde, laranja e vermelho, respetivamente.
Desta forma, após a conclusão deste caso de estudo, mostrou-se que é possível
condicionar a visualização de um determinado modelo virtual através da utilização de
parâmetros de entrada sensorial, relativos ao contexto real acerca do local onde de
desenvolve a visualização.
Palavras-chave – Realidade Aumentada, Realidade Virtual, Vuforia, Android, Single
Board Computer, Unity3D, aquisição de dados sensoriais
vi
ABSTRACT
The day-to-day life is affected by constant technological evolution. A technology
that has gained prominence explores interactivity in real time, with the creation of
systems that allow the replacement of most or even the whole user experience in
physical space. This technology, named Virtual Reality (VR), gave origin to
Augmented Reality (AR) that unlike the VR, doesn’t seek to replace the real world
entirely but to supplement it, overlapping it with virtual objects.
The motivation of this dissertation comes from the perception of the lack of a
system interlinking AR, mobile devices and sensory data acquisitions systems, and
since this is an area underexplored, is meant to be a work that might originate a system
with great interest and utility to the user. This way, the objective of this work is the
creation of a system that interconnects these three technologies: AR, mobile devices and
sensory data acquisition systems.
In this work was made the planning of a sensory data visualization system in AR
applications
to
mobile
devices,
composed
of
three
components:
sensory
contextualization, sensory data management and visualization of sensory virtual
contextualized models. These components are responsible, respectively, for the
acquisition of sensory data context, acquired data management and their visualization
acquired in virtual models presented in the application running on the mobile device,
influencing or conditioning the rendering these virtual models.
After the planning of the system, was designed and developed a system with the
characteristics mentioned above and it was tested in a case of use, through the
implementation of a prototype of a room and the use of two sensory parameters:
illumination intensity and temperature. However, the sensory contextualization
component was simulated, having been created a web platform that simulates the
acquisition of data via buttons instead of purchase in physical space.
After its design, the desired results were obtained: influence or condition the
visualization of virtual models based on the sensory context values used, being able to
change the lighting of a lamp present in the virtual model based on the current value of
vii
simulated lighting and change of textures of this virtual model according to the current
temperature, being used five temperature ranges: very cold, cold, normal and hot, which
are associated with the colors dark blue, blue, green, orange and red, respectively.
Therefore, after completing this case study, it was shown that it is possible to condition
the viewing of a particular virtual model through the use of sensory input parameters
relative to the real context about the location where is developed the visualization.
Keywords – Augmented Reality, Virtual Reality, Vuforia, Android, Single Board
Computer, Unity3D, acquisition of sensory data
viii
Agradecimentos
A realização desta dissertação apenas foi possível graças ao auxílio e apoio
prestado por diversas pessoas. Gostava de aqui deixar os meus sinceros agradecimentos
a todas elas porque direta ou indiretamente, contribuíram para a conclusão deste
trabalho. A todas as pessoas que me motivaram, que me ajudaram a ultrapassar todas as
dificuldades encontradas ao longo deste percurso, que me incentivaram a concluir mais
esta importante etapa da minha vida. Agradeço então:
À UTAD, a mui nobre academia que me acolheu ao longo de cinco anos e me
disponibilizou todas as condições para a minha formação académica, especialmente
durante o último ano.
Aos meus orientadores, Professores Luís Magalhães e Emanuel Peres, pela
excelente orientação desde o início, pelo empenho e disponibilidade que sempre
demonstraram, pela paciência, dedicação, simpatia e rigor. Sem eles não seria possível a
conclusão desta dissertação.
À minha família, pais e irmã, que sempre me apoiaram nos momentos mais
difíceis e demonstraram imensa compreensão. Às avós, padrinhos, tios, primos e
afilhada, pelo espírito de união que nos envolve.
À família Meo House, Nuno Severino, Victor Martins, José Rego, Daniel Coelho,
Nádia Pimenta, Miguel Pereira, Tiago Rodrigues, Susana Lavrador, Samuel Neto e
Margarida Sousa, por todos os momentos inesquecíveis ao longo de cinco anos e que
levo na bagagem para toda a vida.
À família académica, Liliana Couto, Vítor Santos, Sara Faria, Marisa Ferreira,
Filipa Simão, Rita Mota, Sandra Matos, Cláudia Vieira, Mariana Santos, Martinha
Sousa e Isabel Lima, que enriqueceram a minha vida académica.
Às pessoas de sempre, da “Terrinha”, com as quais preservo uma amizade
inabalável, Tânia Monteiro, André Sousa, Liliana Monteiro, Jorge Lima, Diana Saraiva,
Elísia Lopes, Nuno Pinto e Gabriela Moreira.
ix
Aos meus amigos e futuros Doutores Telmo Adão, Miguel Melo e Martinho
Gonçalves, pela disponibilidade que sempre demonstraram quando as dúvidas tomavam
conta de mim.
Aos amigos de Vila Real, que de uma ou outra forma interagiram comigo e
marcaram o meu percurso académico. De entre outros, um especial agradecimento à
Andreia Matos, Milene Esteves, Liliana Lei, Alexandra Rodrigues, Davide Borges,
Lopo Rego, Pedro Bessa, Ricardo Rodrigues, Flávia Castro, Célia Ribeiro e Susana
Sério.
Ao meu patrão, Tiago Costa, pela simpatia e compreensão e aos meus colegas da
AGE+, um muito obrigado por me acolherem e por todo o profissionalismo e espírito de
aprendizagem que me permitem disfrutar.
Aos meus colegas do PIEJ: Projeto de Inovação e Empreendedorismo da
Juventude, que comigo voluntariamente lutam para transformar o concelho de Marco de
Canaveses.
Por fim, a todos aqueles que direta ou indiretamente permitiram que esta
dissertação fosse um sucesso.
A todos, um muito obrigado do fundo do coração!
Nuno Ribeiro,
UTAD, Vila Real
18 Dezembro de 2013
x
Índice
RESUMO ..................................................................................................V
ABSTRACT ............................................................................................. VII
AGRADECIMENTOS .................................................................................... IX
ÍNDICE DE TABELAS ................................................................................. XIII
ÍNDICE DE FIGURAS .................................................................................. XV
GLOSSÁRIO, ACRÓNIMOS E ABREVIATURAS ................................................... XVII
1- INTRODUÇÃO ........................................................................................ 1
2- ESTADO DA ARTE ................................................................................... 9
2.1- REALIDADE AUMENTADA
2.1.1 - CONCEITO DE REALIDADE VIRTUAL
2.1.2- CONCEITO DE REALIDADE AUMENTADA
2.1.3 – APLICAÇÕES DA RA E DA RV
2.1.4- FERRAMENTAS DE RA
2.1.5- FERRAMENTAS DE RA PARA DISPOSITIVOS MÓVEIS
2.1.6 – APLICAÇÕES DE RA PARA DISPOSITIVOS MÓVEIS
2.1.7 – UNITY3D
2.2- HYPERTEXT MARKUP LANGUAGE
2.2.1- INTRODUÇÃO E HISTÓRIA DO HTML
2.2.2- A NOVA VERSÃO: HTML5
2.3- ANDROID
2.3.1- INTRODUÇÃO E ESTATÍSTICAS
2.3.2- ARQUITETURA
2.3.3- DESENVOLVIMENTO EM ANDROID
2.4- COMPUTAÇÃO FÍSICA
2.4.1- INTRODUÇÃO À COMPUTAÇÃO FÍSICA
2.4.2- DISPOSITIVOS DE AQUISIÇÃO DE DADOS SENSORIAIS
2.4.3- GRANDEZAS A MEDIR NA MODELAÇÃO DE AMBIENTES VIRTUAIS
2.4.4- TÉCNICAS DE LOCALIZAÇÃO INDOOR E DETEÇÃO DE PRESENÇA
2.5- APLICAÇÕES PARA O CASO DE ESTUDO: AS IMOBILIÁRIAS
2.5.1- APLICAÇÕES WEB PARA IMOBILIÁRIAS
2.5.2- APLICAÇÕES DE RA PARA DISPOSITIVOS MÓVEIS
9
9
11
14
18
20
25
27
29
29
32
40
40
44
46
47
47
48
53
55
61
61
61
xi
3- SISTEMA DE RA COM CONTEXTUALIZAÇÃO SENSORIAL .................................... 65
3.1 – ARQUITETURA DO SISTEMA
3.1.1- CONTEXTUALIZAÇÃO SENSORIAL
3.1.2- GESTÃO DE DADOS SENSORIAIS
3.1.3- VISUALIZAÇÃO DE MODELOS VIRTUAIS CONTEXTUALIZADOS
3.2 – PROPOSTA DE LAYOUT
3.3 – PROTÓTIPO
3.4.1 – CASOS DE USO
3.4.2 – BLOCO FUNCIONAL GESTÃO DE DADOS SENSORIAIS
3.4.3 – BLOCO FUNCIONAL CONTEXTUALIZAÇÃO SENSORIAL
3.4.4 - BLOCO FUNCIONAL VISUALIZAÇÃO DE MODELOS VIRTUAIS CONTEXTUALIZADOS
3.4.5 – BASE DE DADOS
3.4.6 – DISPOSITIVOS MÓVEIS UTILIZADOS NA CONSTRUÇÃO DO PROTÓTIPO
65
66
67
68
69
71
71
74
75
77
86
87
4 – CASO DE ESTUDO ................................................................................ 89
5 – RESULTADOS E CONCLUSÕES .................................................................. 97
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................. 99
xii
Índice de tabelas
Tabela 1: Condições ideais para o conforto do Homem. Adaptado de (Labour, 2007). ...
Tabela 2: Exemplo de aplicação de textura a um objeto do Modelo Virtual................
Tabela 3: Exemplificação do código para acionar o objeto "candeeiro" .....................
Tabela 4: Cores associadas às texturas dos níveis de temperatura...........................
Tabela 5: Implementação do Split dos diferentes níveis de temperatura no Unity3D. ...
Tabela 6: Implementação da propriedade GUI.Box, exibindo informação sensorial .......
Tabela 7: Criação de um botão nos scripts do Unity3D.........................................
54
79
81
81
82
83
84
xiii
xiv
Índice de figuras
Figura 1: Realidade Virtual não imersiva (à esquerda) e imersiva (à direita) (Tori, R., et
al 2006). ............................................................................................... 10
Figura 2: Realidade mista (Adaptado de Milgram and Kishino, 1994). ....................... 13
Figura 3: Captura em tempo real dos batimentos cardíacos (Bucioli et al., 2007). .......... 15
Figura 4: Animação do coração (Bucioli et al., 2007).............................................. 15
Figura 5: Visualização do modelo sobreposto no paciente (Lab & Hospital, 1999). ....... 16
Figura 6: Interação do utilizador com a Wii através do Wii Remote (GameGuru, 2006). . 17
Figura 7: A marca de RA e respetivo objeto do EyePet (Fahey, 2010). ...................... 17
Figura 8: Diagrama de funcionamento do ARToolKit (Adaptado de (Sinclair, 2001)). ..... 19
Figura 9: Diagrama de Fluxo de Dados do SDK Vuforia num Ambiente de Aplicação
(Qualcomm Technologies, 2013b).................................................................. 22
Figura 10: Visão geral do processo de desenvolvimento de aplicações na plataforma
Vuforia (Qualcomm Technologies, 2013a). ....................................................... 23
Figura 11: Geo Layer do Jardim Botânico da UTAD na aplicação Layar, que permite
interagir com 18 pontos de interesse. ............................................................ 24
Figura 12: Visão geral do Ingress (Bit, 2013). .................................................... 26
Figura 13: O protocolo HTTP, responsável pela comunicação entre o browser do utilizador
e o servidor web. ..................................................................................... 31
Figura 14: Menu principal (esquerda) e aplicação Google Play do sistema operativo
Android (direita). ..................................................................................... 42
Figura 15: Top 8 de sistemas operativos móveis utilizados entre Setembro de 2012 e
Setembro de 2013. Figura obtida de (Stats, 2013). ............................................. 44
Figura 16: Arquitetura do Google Android (Google, 2012b). .................................. 45
Figura 17: Modelo B do Raspberry Pi. ............................................................. 49
Figura 18: Visão geral dos componentes que compõem o Raspberry Pi. Figura adaptada de
(Pi, 2011). ............................................................................................. 50
Figura 19: Arduino Mega. Imagem adaptada de (Arduino, 2012a).............................. 52
Figura 20: Interruptores fotoelétricos (à esquerda), detetor de movimento (centro) e
interruptor magnético (à esquerda). Figura adaptada de (O'Sullivan & Igoe, 2004). ...... 57
Figura 21: Trilateração utilizando três pontos de ancoragem (Sanchez et al., 2012). .... 59
Figura 22: Aplicação Vodafone Praia permite escolher uma praia de Portugal e visualizar
dados sensoriais em tempo real ou baseado no histórico. ..................................... 63
Figura 23: Estimativas sensoriais para a Praia de Espinho, na aplicação BeachCam....... 64
Figura 24: Arquitetura da aplicação para visualização de dados sensoriais em aplicações
de realidade aumentada. ........................................................................... 66
Figura 25: Fluxo do componente de contextualização sensorial. ............................. 67
Figura 26: Bloco de operação do Webservice. ................................................... 67
Figura 27: Fluxo de dados do bloco de operação Dispositivo Móvel .......................... 69
Figura 28: Divisão da interface da aplicação. .................................................... 70
Figura 29: Casos de uso da aplicação concebida. ............................................... 72
Figura 30: Visão geral do simulador de dados sensoriais. ...................................... 76
Figura 31: Esquema do processo de desenvolvimento no Unity3D............................ 77
Figura 32: Exemplo da construção de um pedido ao Webservice. ............................ 80
Figura 33: Diagrama Entidade-Relacionamento da base de dados do protótipo............ 86
xv
Figura 34: Dispositivos móveis utilizados durante a construção do protótipo. ............. 88
Figura 35: Mensagem de erro, apresentada no dispositivo móvel quando não é possível
comunicar com o Webservice. ...................................................................... 89
Figura 36: Interface da aplicação concebida. .................................................... 90
Figura 37: Marca de Realidade Aumentada Stones, disponibilizada pela Vuforia. ......... 90
Figura 38: Rendering do Modelo Virtual........................................................... 91
Figura 39: Captura da marca através de diferentes ângulos permite visualizar o modelo
virtual de outras perspetivas. ...................................................................... 91
Figura 40: Rendering do modelo virtual, com o candeeiro ligado com intensidade 1 ..... 92
Figura 41: Rendering do modelo virtual, com o candeeiro ligado com intensidade 7 ..... 92
Figura 42: Visualização do modelo virtual nos cinco níveis de temperatura. ............... 93
Figura 43: Rendering do modelo virtual com os parâmetros de temperatura e iluminação
ligados em simultâneo. .............................................................................. 94
Figura 44: Apresentação da legenda dos níveis de temperatura. ............................. 95
Figura 45: Interface do dispositivo móvel com o parâmetro da temperatura desativado
pelo administrador. .................................................................................. 95
xvi
Glossário, acrónimos e abreviaturas
Lista de acrónimos
Sigla
.NET
2G
3D
3G
4G
ADT
AJAX
API
APK (.APK)
ARM
AS
AS3
AVI
BD
BMP
CSS
CSS3
DMS
DOF
FTP
g
Gb
GIF
GPS
GPU
GWG
HD
HDMI
HMD
HTC
HTML
HTTP
IDE
IP
JDK
JPEG
JS
m/s
m2
Mac
MAME
MB
MHz
MIDI
Expansão
.NET Framework
Rede de 2ª geração
Imagem a três dimensões
Rede de 3ª geração
Rede de 4ª geração
Android Development Tools
Asynchronous Javascript and XML
Application Programming Interface
Android Application Package file
Advanced RISC Machine
ActionScript
ActionScript, versão 3
Audio Video Interleave
Base de dados
Windows Bitmap
Cascading Style Sheets
Cascading Style Sheets, versão 3
Degree Minute Second
Degrees of Freedom
File Transfer Protocol
Grama
Gigabyte
Graphics Interchange Format
Global Positioning System
Graphics Processing Unit
Geolocation Working Group
High-definition video
High-Definition Multimedia Interface
Head-Mounted Display
High Tech Computer Corporation
HyperText Markup Language
Hypertext Transfer Protocol
Integrated Development Environment
Internet Protocol
Java Development Kit
Joint Photographic Experts Group
JavaScript
Metros por segundo
Metros quadrados
Macintosh
Multiple Arcade Machine Emulator
Megabyte
Mega-hertz
Musical Instrument Digital Interface
xvii
MP3
MP4
MySQL
NTFS
ºC
OHA
OOP
OpenGL
OS
PHP
PNG
QR-Code
RA
RAM
RCA
RF
RFID
RM
RV
SBC
SDK
SGBD
SGML
SO
SQL
SVG
UARTs
URI
USB
UTAD
UV
V
VNC
VRML
W3C
WHATWG
WWW
X3D
XHTML
XML
MPEG Layer 3
MPEG Layer 4
My Structured Query Language
New Technology File System
Graus Celsius
Open Handset Alliance
Object-oriented programming
Open Graphics Library
Operative System
“PHP:Hypertext Preprocessor”
Anteriormente “Personal Home Page”
Portable Network Graphics
Quick Response Code
Realidade Aumentada
Random Access Memory
Radio Corporation of America
Radio frequency, Radiofrequência
Radio-Frequency IDentification
Realidade Mista
Realidade Virtual
Single Board Computer
Software Development Kit
Sistema de Gestão de Base de Dados
Standard Generalized Markup Language
Sistema Operativo
Structured Query Language
Scalable Vector Graphics
Universal Asynchronous
Receiver/Transmitter
Uniform Resource Identifier
Universal Serial Bus
Universidade de Trás-os-Montes e Alto
Douro
Ultravioleta
Volts
Virtual Network Computing
Virtual Reality Modeling Language
World Wide Web Consortium
Web Hypertext Application Technology
Working Group
World Wide Web
Extensible 3D
eXtensible Hypertext Markup Language
eXtensible Markup Language
xviii
Lista de abreviaturas
Abreviatura
e.g.
et al.
etc.
i.e.
Significado(s)
por exemplo
e outros (autores)
etecetera, outros
Isto é, por conseguinte
xix
xx
1- Introdução
Neste capítulo serão abordados os principais conceitos tecnológicos em que se
baseou esta dissertação, assim como a motivação deste trabalho e os seus respetivos
objetivos. Por fim, será explicada a organização da dissertação.
Há uma tecnologia que tem vindo a evoluir ao longo dos últimos anos, que visa a
interatividade em tempo real, com a criação de sistemas que possibilitam a substituição
de grande parte ou até mesmo toda a experiência do utilizador no mundo físico com
materiais tridimensionais, como gráficos e som (Feiner, Macintyre, & Seligmann,
1993). Esta tecnologia, denominada RV, apesar de ser vista como algo inovador, na
verdade surgiu em 1960, quando Ivan Sutherland construiu o Sketchpad, o primeiro
sistema de computação gráfica, passando de seguida a trabalhar no Ultimate Display
(Packer & Jordan, 2002), o primeiro capacete de RV, apresentado no final dessa década
e que ainda hoje é a base das pesquisas dentro deste tema. A RV pode ser definida como
um ambiente tridimensional gerado por computador que possibilita ao utilizador
navegar e interagir, em tempo real, com este ambiente, recorrendo a dispositivos
multissensoriais, como luvas, óculos ou capacetes de RV, aumentando desta forma a
sensibilidade dos sentidos do utilizador, sendo que se pode classificar a RV em função
da presença do utilizador no mundo real, sendo considerada imersiva quando o
utilizador está completamente imerso no ambiente virtual e não imersiva quando o
utilizador tem noção do espaço que o rodeia (Tori, Kirner, & Siscoutto, 2006). Milgram
et al engloba RA como uma parte da RV (Milgram, Takemura, Utsumi, & Kishin,
1994). Apesar de parecerem a mesma coisa e estarem interligadas, são duas coisas
distintas. Enquanto a RV pretende substituir o mundo real, a RA procura apenas
aumentá-lo, ou seja, acrescentar-lhe elementos virtuais, criando uma mistura dos dois
em tempo real (R. T. Azuma, 1997). Quando comparados, a RA requer menos aparato
tecnológico que a RV, sendo apenas necessária uma câmara de vídeo que capture o
mundo real, integrando nessa captura os elementos virtuais em tempo real. Milgram
criou uma relação entre os ambientes virtuais e real, à qual chamou de Virtuality
Continuum, que coloca o ambiente completamente virtual e o completamente real como
1
extremos e, a tudo o que se encontra entre estes dois extremos, chama Realidade Mista
(Milgram et al., 1994).
O dia-a-dia é afetado pela constante evolução tecnológica. Hoje, logo pela manhã,
sente-se a necessidade de verificar a caixa de email, ver as principais notícias ou até
mesmo aceder às redes sociais. Com o aparecimento dos dispositivos móveis, estas
tarefas tornaram-se mais simples e deixaram de estar limitadas fisicamente, sendo o
acesso possível a partir de qualquer lugar. O mundo dos dispositivos móveis ficou
marcado quando, em 2007, a Apple lançou o iPhone: um smartphone completamente
táctil e que se tornou um símbolo de luxo para a população (Hall & Anderson, 2009).
Contudo, no decorrer desse mesmo ano, a Google anunciou um sistema operativo open
source que prometia revolucionar o mercado dos smartphones: o Android. Andy Rubin,
criador do Android e diretor das plataformas móveis da Google, afirmou que não deve
haver nada que os utilizadores possam fazer num computador que não seja possível no
seu dispositivo móvel (BBC, 2008). Segundo a Google, existem atualmente centenas de
milhões de dispositivos com este sistema operativo (SO) ativos, espalhados por mais de
190 países. Estes números não param de aumentar, sendo diariamente ativos milhões de
novos dispositivos (Google, 2012a). O Android dispõe de uma loja de aplicações
gratuitas e/ou pagas, denominada Google Play, que possibilita que os utilizadores
partilhem as suas próprias aplicações com o resto desta comunidade.
Atualmente já é possível conceber aplicações de RA para dispositivos móveis
com alguma facilidade, existindo uma panóplia de ferramentas que nos possibilitam
criá-las, com maior ou menor detalhe, conforme as nossas necessidades. A framework
Vuforia é uma ferramenta poderosa, desenvolvida pela Qualcomm Technologies, Inc,
que nos permite conceber aplicações para dispositivos móveis com o SO Android ou
iOS. Um grupo de investigadores afirma que esta framework utiliza o dispositivo móvel
como um portal para um mundo aumentado onde a realidade e a virtualidade parecem
coexistir (Balint, Kiss, Magyari, & Simon, 2012). Enquanto a maioria das ferramentas
de RA se limita a marcas com limites negros e uma figura geométrica simples, o
Vuforia possibilita a utilização de marcas naturais não aparentes (markerless), ou seja,
possibilita que qualquer imagem ou objeto possa ser a nossa marca, como por exemplo
uma fotografia, uma caixa, um rótulo, entre outros, desde que respeitem determinadas
regras impostas pelo algoritmo de deteção da plataforma (Forte, Silva, & Marengoni,
2012). Contudo, existem ferramentas que requerem menos conhecimentos de
2
programação disponibilizando, na maioria dos casos, interfaces gráficas que facilitam a
conceção de aplicações de realidade aumentada. A Layar é uma ferramenta que utiliza o
recetor de Global Positioning System (GPS) do dispositivo para detetar e posteriormente
sobrepor informações virtuais à imagem capturada pela câmara do dispositivo móvel em
tempo real, sendo que estas informações não são mais que pontos de interesse para o
utilizador, como restaurantes, espaços de diversão, culturais, transportes públicos, entre
outros. Para Scott, esta ferramenta é bastante útil para quem está numa cidade que não
conhece, fornecendo-lhe dicas de locais a visitar, podendo ainda o utilizador descarregar
novas Geo Layers, desenvolvidas por qualquer pessoa, sem necessidade de utilização de
código (Scott, 2010). Outra ferramenta semelhante à Layar é a Wikitude que, além das
funcionalidades já referidas, possibilita também a visualização de conteúdos publicados
perto do utilizador, como por exemplo tweets do Twitter, artigos da Wikipedia, vídeos
do Youtube e Flickr. Além disso, disponibiliza também um sistema de jogos em
realidade aumentada, entre a câmara do dispositivo e o mundo virtual.
É assim notório que a RA está cada vez mais presente nos dispositivos móveis.
Existem diversas aplicações que utilizam este conceito em prol de entreter ou até
mesmo orientar o utilizador, aumentando desta forma a popularidade deste tipo de
aplicações (Fröhlich, Oulasvirta, Baldauf, & Nurminen, 2011). A Google possui um
jogo multiplayer que explora as potencialidades da RA, chamado Ingress que, apesar de
ainda se encontrar em fase beta, possui já uma grande legião de fãs. Este jogo tem como
enredo a luta pelo controlo das mentes de todos os habitantes deste planeta e utiliza o
mundo real como cenário. Proporcionando uma nova visão do ambiente urbano, o
jogador percorre o mundo à procura de energia, que lhe possibilitará posteriormente
aceder a portais. Estes portais, virtualmente associados a objetos públicos, estátuas e
monumentos ou até mesmo peças de museus, são controlados por uma das duas equipas
que o utilizador pode escolher quando inicia o jogo: os iluminados (The Enlightened) e
a resistência (The Resistance), que, em equipa, procuram pela sua cidade vestígios da
equipa adversária, combatendo-a com o auxílio do seu smartphones e das armas virtuais
disponibilizadas pela aplicação. Um outro jogo que combina o mundo real com a
virtualidade chama-se X-Rift. Neste jogo, são capturadas frames de vídeo através da
câmara do dispositivo móvel e, com base em coordenadas GPS, são adicionados
elementos virtuais que o utilizador deverá destruir, como monstros e outros obstáculos.
Mas a RA nos dispositivos móveis não se limita aos jogos, mas também a aplicações
3
que facilitam ou enriquecem as atividades do utilizador. A aplicação Word Lens
Translator utiliza também a câmara do dispositivo móvel para, em tempo real, detetar
palavras e frases em inglês e automaticamente fazer a tradução para um dos cinco
idiomas disponíveis, entre os quais o português. Por outro lado, a Augment - 3D
Augmented Reality utiliza as potencialidades do smartphone para fazer o rendering de
objetos virtuais animados no mundo virtual, sendo possível posicioná-los em qualquer
parte do ecrã, sendo esta aplicação bastante útil para, por exemplo, simular como fica
um móvel numa sala de uma casa. Contudo, a RA também pode ser uma mais-valia
relativamente à segurança rodoviária. iOnRoad Augmented Driving é uma aplicação que
exibe informações relativamente à circulação automóvel do utilizador. O dispositivo
móvel é estrategicamente colocado na parte da frente do veículo e é calculada a
velocidade atual a que este circula e posteriormente determinado o tempo de distância
para o veículo que se encontra à sua frente, alertando o utilizador para aumentar a
distância, caso tal seja necessário, de forma a circular de forma mais segura.
Apesar de todas as inovações que a RA nos proporcionou, a evolução dos
sistemas informáticos não se ficaram por aqui, tendo surgido novos equipamentos para
aumentar a experiência disponibilizada ao utilizador. O’Sullivan e Igoe definem
computação física como a interação entre o mundo físico e o mundo do computador
(O'Sullivan & Igoe, 2004). Esta interação procura ser o mais invisível possível, criando
um ambiente pervasivo. A ideia de computação pervasiva é transformar um ambiente
num ambiente autónomo, capaz de obter informações do meio à sua volta e utilizá-las
para controlar, configurar e ajustar uma aplicação, de forma completamente invisível e
impercetível para o utilizador (Araujo, 2003). Atualmente existem já uma grande
quantidade de casas que utilizam esta tecnologia, denominadas “casas inteligentes”, que
utilizam a disseminação de sensores em larga escala para a perceção das atividades
diárias dos seus habitantes, como por exemplo sensores de posicionamento ou até
mesmo sensores nas cadeiras que detetam quando uma pessoa se senta. Desta forma, a
casa consegue reagir à presença do utilizador, de acordo com as suas rotinas, sabendo
quando tem de fazer o café, que temperaturas têm de ter as diferentes divisões da
habitação ou até mesmo encomendar automaticamente artigos em falta no frigorífico.
Um outro sistema pervasivo integra sensores no vestuário que, entre outras
funcionalidades, monitorizam os sinais vitais e são capazes de se adaptar à temperatura
do corpo da pessoa. Existem imensas ferramentas que possibilitam a criação de sistemas
4
pervasivo. Apesar de serem sistemas bastante caros, têm surgido alguns dispositivos,
denominados Single Board Computer (SBC), que possibilitam a aquisição de dados
sensoriais no espaço físico. Dois exemplos de SBC são o Raspberry Pi e o Arduino,
dois equipamentos do tamanho de um cartão de crédito com elevadas capacidades de
processamento, que permitem a acoplação de sensores. Além de muitas outras
funcionalidades, estes SBC são capazes de sentir o ambiente através de sensores e
comunicar as informações recolhidas utilizando ligações sem fios (Barroca et al., 2013).
Um exemplo de dados sensoriais que estes dispositivos podem captar são a temperatura,
humidade, iluminação e índices ultravioleta, sendo que podem posteriormente ser
utilizados para auxiliar na luta contra problemas sociais, tais como determinar os índices
de poluição, medir os níveis de radioatividade, analisar o tráfego em tempo real, ruído,
humidade e temperatura (Mendez, Labrador, & Ramachandran, 2013).
A motivação desta dissertação surge quando analisamos estas três tecnologias,
com um elevado potencial e se constata que ainda estão pouco exploradas, quando
interligadas. Entende-se que um sistema de RA para dispositivos móveis, que possibilite
a aquisição e incorporação de dados sensoriais, poderá tornar-se numa mais-valia
importante para os utilizadores. Desta forma, o objetivo deste trabalho é a criação de um
sistema que interligue estas três tecnologias: RA, dispositivos móveis e sistemas de
aquisição de dados sensoriais. Em primeiro lugar, pretende-se desenvolver um sistema
de aquisição de dados sensoriais e registar alguns parâmetros, que serão posteriormente
armazenados numa base de dados (BD), recorrendo a webservices. Depois disso, ir-se-á
conceber uma aplicação de RA para dispositivos móveis onde seja possível aceder aos
dados recolhidos e utilizá-los para alterar propriedades em modelos virtuais, fazendo a
simulação dos parâmetros sensoriais a que correspondem. Por fim, existirá uma área de
administração, onde será possível fazer a gestão dos parâmetros que podem ser
utilizados e também para visualização de históricos dos dados sensoriais adquiridos. Em
Portugal existem, pelo menos, dois sistemas deste género que utilizam o contexto das
praias e costa marítima portuguesa (Vodafone Praia em Direto e Moche BeachCam),
fazendo a aquisição de diversos parâmetros sensoriais, como a temperatura do ar,
temperatura da água, velocidade e direção do vento, entre outros, e as disponibilizarem
aos seus utilizadores, juntamente com dados estatísticos para determinados períodos de
tempo. Considera-se que estas três tecnologias podem ser exploradas noutras áreas, de
forma a conceber mais soluções que complementem a vida dos utilizadores.
5
Para que este trabalho seja desenvolvido com sucesso, foram estabelecidas
algumas metas:

Revisão do estado da arte relativo às tecnologias e ferramentas disponíveis
para a criação de sistemas de RA para dispositivos móveis, assim como
dos dispositivos de aquisição de dados sensoriais;

Estudo de aplicações de RA e de aquisição de dados sensoriais já
existentes para dispositivos móveis;

Conceber e desenvolver um sistema e implementar um protótipo que
permita ao utilizador visualizar um modelo virtual, associado a uma marca
de RA e, com base em valores sensoriais, altera-lo dinamicamente,
simulando características sensoriais;

Realização de testes para avaliar o funcionamento do protótipo
desenvolvido.
De forma a demonstrar o funcionamento deste sistema, será criado um caso de
estudos, implementando o protótipo no contexto imobiliário. Após a pesquisa de
aplicações de RA para imobiliárias, constatou-se que é uma área praticamente
inexplorada e que, apesar de haverem algumas aplicações de RA, as mesmas não estão
disponíveis em Portugal. É o caso da HomeSpotter (Apps, 2012), uma aplicação para
iOS que utiliza a câmara e o recetor GPS do dispositivo para, com base na sua
localização, sobrepor às imagens capturadas, informações sobre casas para venda ou
aluguer, assim como um radar que mostra a distância para outras casas que se
encontrem nesta situação. Esta mesma empresa, possui também uma aplicação que usa
QR-Code que, após serem analisados, redirecionam para a página do respetivo imóvel
na sua aplicação web. A ARHouse é outra aplicação de RA para iOS, que permite às
agências imobiliárias simularem um modelo virtual tridimensional de um imóvel
diretamente em cima da secretária, descartando os antigos e complicados projetos em
papel. Além disso, também permite uma configuração do que é visualizado, podendo-se
escolher entre a vista interior ou exterior do imóvel, assim como ter uma vista
panorâmica de qualquer um deles. Quando falamos de aplicações RA de imobiliárias
em Portugal, não encontramos nenhuma específica, sendo que as únicas que existem
utilizam os browsers de RA Layar e Wikitude, criando packs de informação que são
adicionados às restantes destas aplicações. Duas plataformas de imobiliárias bastante
conhecidas em Portugal são a Casa Sapo e o Imovirtual, que possuem versões para
6
dispositivos Android e iOS. Contudo, estas aplicações normalmente não passam de uma
otimização da página web, mais limpa e com menos detalhe, de forma a facilitar a sua
utilização.
Após este estudo, constatou-se que não existe um sistema que junte estas três
tecnologias e permita a alteração de um modelo virtual, em tempo real, através das
entradas recebidas de uma rede sensorial in situ.
Esta dissertação encontra-se organizada em quatro capítulos. Além deste capítulo
introdutório, no capítulo 2 é feito um levantamento do estado da arte relativo às
tecnologias e ferramentas existentes em relação à RA, Android, HTML5 e computação
pervasiva, onde são analisados e descritos os principais conceitos de cada um destes
temas, assim como as suas vantagens e desvantagens, de forma a perceber as melhores
opções para a conceção, especificação e desenvolvimento do sistema pretendido neste
trabalho.
No capítulo 3 é planeado o sistema, assim como a especificação dos blocos
funcionais que o definem. São também apresentados os detalhes da sua implementação
e por fim são explicadas todas as funcionalidades do protótipo, assim como o caso de
estudo em imobiliárias.
No capítulo 4 são apresentadas as conclusões deste trabalho, bem como a
justificação da utilização ou não utilização de algumas tecnologias estudadas e por fim
algumas considerações para um trabalho futuro.
Neste primeiro capítulo foi feito um breve enquadramento tecnológico do estado
da arte e das ferramentas disponíveis para a conceção de um sistema de RA para
dispositivos móveis interligada com dispositivos de aquisição sensorial, assim como
dados alguns exemplos de cada um. Por fim, foi explicada a motivação deste trabalho,
assim como estabelecidas algumas metas para o seu êxito.
7
8
2- Estado da Arte
Neste capítulo é feita uma revisão bibliográfica de algumas tecnologias, de forma
a perceber quais as que poderão serão utilizadas com a conceção do sistema de
visualização de dados sensoriais em aplicações de realidade aumentada, em dispositivos
móveis, assim como as limitações e vantagens de cada uma delas. Desta forma, neste
capítulo são abordados os conceitos de RV e RA, HTML, Android e computação física.
2.1- Realidade Aumentada
Desde primórdios que o ser humano convive com representações da realidade ou
da imaginação, expressando-se através de pinturas rupestres, artes plásticas, jogos
tradicionais, atividades culturais e outras expressões artísticas. Com o aparecimento do
computador, estas ações ganharam outro dinamismo e originaram a multimédia,
integrando sons, imagens e fotografias, textos, vídeos e animações e permitiram a
criação de aplicações mais interativas. Com o avanço da tecnologia, as aplicações
superaram a barreira do monitor permitindo hoje gerar ambientes tridimensionais ultra
interativos com o utilizador.
2.1.1 - Conceito de Realidade Virtual
Apesar de parecer antagónico, a origem da Realidade Virtual (RV) não é tão
recente como se imagina. Em 1960, Ivan Sutherland construiu o Sketchpad, o primeiro
sistema de computação gráfica, passando logo depois a trabalhar no primeiro capacete
de RV, apresentando-o no final dessa década, com o nome Ultimate Display (Packer &
Jordan, 2002), sendo ainda hoje a base das pesquisas dentro deste tema. Na década de
80, Jaron Lanier utilizou pela primeira vez o termo “Realidade Virtual”, de forma a
diferenciar os mundos virtuais por ele criados (Lanier, 1984), surgindo posteriormente
diversas definições para este termo. Segundo Burdea, a RV "é um mundo sintetizado
não estático, mas sim, que responde às ordens do utilizador sejam eles gestos, vozes,
etc" (Burdea & Coiffet, 2003). Dito isto, retira-se o seu conceito base: interatividade em
tempo real. Além disso, o termo RV é muitas vezes usado para descrever sistemas que
tentam substituir grande parte ou toda a experiência do utilizador do mundo físico com
materiais sintetizados em 3D, tais como gráficos e som (Feiner et al., 1993). Além
9
disso, esta tecnologia é um ambiente tridimensional gerado por computador que
possibilita ao utilizador navegar e interagir em tempo real com esse ambiente, através de
dispositivos multissensoriais, como luvas, óculos ou capacetes de RV, aumentando
desta forma a sensibilidade dos sentidos do utilizador, permitindo-lhe ver, ouvir, sentir e
viajar de forma mais intensa do que é possível no mundo real (Tori et al., 2006). Já
Vallino afirma que a RV é uma tecnologia que engloba um amplo espectro de ideias e
define-a como um ambiente tridimensional gerado por computador e interativo, onde o
utilizador é imerso (Vallino, 1998). Gobbetti e Scateni afirmam que o seu objetivo é
colocar o utilizador num ambiente de simulação em tempo real, imersos num mundo
autónomo e sensível às suas ações (Gobbetti & Scateni, 1998).
A RV pode ser classificada em função da presença do utilizador no mundo real:
imersiva ou não imersiva (Tori et al., 2006). Considera-se imersiva quando o utilizador
está completamente desligado do mundo real e interage com o ambiente virtual através
de dispositivos multisensoriais. Estes dispositivos captam os seus movimentos e
comportamentos e espoletam alterações no ambiente virtual. Já num ambiente não
emersivo o utilizador está dividido entre o mundo real e o virtual, sendo necessária a
utilização de, por exemplo, um monitor para ser transportado para o mundo virtual,
continuando assim ter percepção do que se passa no mundo real. Na Figura 1 vê-se um
exemplo de RV imersiva e não imersiva.
FIGURA 1: REALIDADE VIRTUAL NÃO IMERSIVA (À ESQUERDA) E IMERSIVA (À DIREITA) (TORI, R., ET AL
2006).
De acordo com as definições anteriormente dadas, o aspeto mais importante da
RV é a interação que esta tecnologia possibilita, estando relacionada com a capacidade
do computador detetar as ações ou movimentos do utilizador e reagir imediatamente,
provocando alterações ou impulsionar eventos no ambiente virtual. A interação mais
simples consiste na navegação, onde o utilizador se move no ambiente virtual
10
recorrendo a um dispositivo de realidade aumentada, obtendo assim visualização de
novos pontos de vista do ambiente (Tori et al., 2006). Segundo os autores citados
anteriormente, uma interação propriamente dita ocorre quando o utilizador explora,
manipula, aciona ou altera objetos virtuais dentro do ambiente virtual.
Os sistemas de RV são complexos e são capazes de suportar interações em tempo
real entre vários componentes de hardware e software. No que diz respeito a hardware,
a utilização de sistemas computacionais é imprescindível, já que um sistema de
realidade virtual envolve dispositivos de entrada, responsáveis por captar as interações
do utilizador e as transmitir ao sistema. Entre esses dispositivos, pode-se mencionar:
luvas, reconhecedores de voz, teclados 3D, entre outros. Como dispositivos de saída,
responsáveis por transmitir o ambiente virtual, podem-se encontrar os dispositivos
óticos, acústicos e hápticos. Em relação ao software, a realidade virtual utiliza
linguagens
de
programação,
sendo
as
mais
conhecidas
o
VRML
(Virtual Reality Modeling Language) e o seu sucessor X3D (Extensible 3D Graphics),
podendo recorrer a bibliotecas gráficas como o OpenGL, Java 3D, entre outros.
2.1.2- Conceito de Realidade Aumentada
A RA e a RV podem parecer a mesma coisa, mas apesar de interligadas são coisas
distintas.
Enquanto a RV leva o utilizador para um ambiente tridimensional gerado por
computador e interativo em tempo real, a RA pode definir-se como a integração do
mundo real com elementos virtuais tridimensionais gerados com a ajuda de um
computador. No entanto, este conceito é muito geral. Segundo Ronald Azuma, RA é um
ambiente que envolve tanto RV como elementos do mundo real, criando uma mistura
dos dois em tempo real, não se limitando à visão mas sim a todos os sentidos (R. T.
Azuma, 1997).
O termo “Realidade Aumentada” foi cunhado pelo Prof. Thomas Caudell durante
uma visita à empresa Boeing, referindo-se a um dispositivo de RV que apoiava os
funcionários na montagem de equipamentos eletrónicos de aviões (Ribeiro & Zorzal,
2011).
11
O objetivo da RA não é substituir o mundo real, mas sim aumentá-lo e acrescentar
ainda mais informação disponível para o utilizador, através da sobreposição de
elementos sensoriais no ambiente real e em tempo real (Obst & Tröller, 2009).
Azuma afirma também que para um sistema ser considerado RA deve combinar
objetos reais e virtuais num ambiente real, ser interativo e em tempo real e alinhar
objetos reais e virtuais entre si (R. T. Azuma, 1997). Outro aspeto importante na
definição de RA por Azuma é que ele considera que RA não se restringe às tecnologias
que utilizam displays HMD (Head Mounted Display).
Na RA certas aplicações têm a necessidade de ocultar objetos existentes quando
novos objetos são adicionados a esse ambiente virtual. Por exemplo, ao adicionar um
objeto virtual na frente de um real, esse objeto sobrepõe-se. Enquanto vários
investigadores utilizam o termo “Realidade Diminuída” para esta característica, um
grupo de investigadores prefere dizer que é um subconjunto da RA (R. Azuma et al.,
2001).
Uma proposta foi apresentada por Broll para classificar as técnicas de interação
que podem ser utilizadas em ambientes de RA (Broll et al., 2005):

Interação espacial (spatial interaction);

Interação baseada em comandos (command-based interaction);

Interação por controlo virtual (virtual control interaction);

Interação por controlo físico (physical control interaction).
A interação espacial baseia-se na manipulação das propriedades espaciais dos
objetos físicos, através de interfaces táteis, onde o utilizador interage com o objeto
físico através do real.
Já a interação baseada em comandos recebe e descodifica gestos espontâneos,
simbólicos ou comandos de voz do utilizador. Normalmente, estes sistemas impõem
algumas restrições na composição da cena, como o fundo, a cor dos objetos a serem
reconhecidos, condições de iluminação e de outras características físicas.
A interação por controlo virtual permite ao utilizador interagir com o sistema
através da manipulação de gráficos tridimensionais, como por exemplo um menu
tridimensional.
12
Por fim, a interação por controlo físico recorre às ferramentas e interfaces físicas
de forma a controlar não só os objetos físicos mas também os virtuais.
Milgram criou uma relação entre os ambientes virtuais e reais à qual chamou
“Virtuality Continuum ”ou ”Contínuo de Virtualidade”, que coloca como extremos o
ambiente completamente virtual e o completamente real, chamando a tudo o que se
encontra entre os dois extremos, Realidade Mista (RM) (Figura 2) (Milgram et al.,
1994). Milgram separa Virtualidade Aumentada e RA. Enquanto o primeiro é um
mundo virtual onde são adicionados objetos reais, o segundo é um mundo real onde são
adicionados objetos virtuais.
FIGURA 2: REALIDADE MISTA (ADAPTADO DE MILGRAM AND KISHINO, 1994).
Segundo Tori, Virtualidade Aumentada pode ser definida como um detalhe da
RM quando o ambiente predominante for o virtual, enriquecendo-o com elementos reais
pré-capturados ou em tempo real, como objetos estáticos ou dinâmicos (e.g. mãos e
pessoas), sendo estes últimos capturados através de dispositivos de captura de vídeo e
reconstruídos em tempo real (Tori et al., 2006).
Apesar da RV e RA partilharem algumas características, existem algumas
diferenças entre elas. A primeira refere-se ao nível de imersão no sistema. Enquanto na
RV o utilizador é transportado para um mundo virtual gerado por computador, onde se
abstrai por completo do mundo real, na RA apenas são adicionados elementos virtuais
ao mundo real, fazendo com que o utilizador não perca a noção daquilo que o rodeia
mas consiga interagir com esses elementos. Desta forma é possível apontar outra
diferença: o material necessário. Na RV é gerado um mundo completo que “arrasta” o
utilizador para o seu interior. Para isto são necessários equipamentos que permitam crialo o mais interativo e fiel possível à realidade, ou seja, equipamentos que podem ser
dispendiosos. Já na RA, o objetivo não é substituir o ambiente real mas sim adicionarlhe objetos virtuais, bastando um simples computador e uma webcam para essa tarefa, o
que a torna uma tecnologia bastante acessível.
13
Outra diferença refere-se ao alinhamento entre os objetos reais e os objetos
virtuais (Barreira, 2010). Para que a cena seja corretamente analisada pelo sistema de
RA, os objetos virtuais precisam de estar perfeitamente posicionados em relação ao
mundo real. Nos sistemas de RV este fator não tem importância, pois o cenário é todo
construído artificialmente.
Desde orientar um turista numa cidade desconhecida, auxiliar um piloto aéreo
informando-o da rota correta, apoiar uma equipa médica ou simplesmente adicionar
elementos a um vídeo capturado em tempo real, as possibilidades desta tecnologia são
cada vez mais e pode ser aplicada em diversas áreas como a medicina, entretenimento e
jogos, educação, comércio, forças armadas, entre outras.
2.1.3 – Aplicações da RA e da RV
Apesar de todos os avanços que a medicina tem diariamente, a RA tem-se
mostrado um precioso auxílio ao trabalho dos profissionais desta área. Existem já
alguns projetos envolvendo RA e medicina, como o ARBioMed.
O ARBioMed, desenvolvido na Universidade Federal de Uberlândia, destina-se à
visualização e simulação de sinais de eletrocardiogramas. Estes eletrocardiogramas
podem ser simulados a partir de um batimento cardíaco fixo definido pelo utilizador,
capturados em tempo real (Figura 3) a partir do sensor lógico ou baseado num
eletrocardiograma real, seja através de arquivos de texto que contêm um vetor gráfico
com os respetivos valores ou simplesmente a partir de uma imagem real (jpeg; bmp;
png; gif.) (Bucioli, Jr., Cardoso, & Kirner, 2007).
Depois de selecionado um dos métodos de entrada é simulado um coração (Figura
4) com base nos dados introduzidos, respeitando a velocidade e mostrando possíveis
anomalias o mais fiel possível, visto que as taxas de amostragem dos sinais
eletrocardiográficos são superiores ao número de frames por segundo que as placas
gráficas conseguem reproduzir (Bucioli et al., 2007).
Neste projeto destaca-se a captação e simulação dos batimentos cardíacos em
tempo real, através de um sensor lógico, que envia para o sistema um bit a cada
pulsação, calculando a velocidade média do coração a partir das últimas 5 amostras
recebidas do sensor.
14
FIGURA 3: CAPTURA EM TEMPO REAL DOS BATIMENTOS CARDÍACOS (BUCIOLI ET AL., 2007).
FIGURA 4: ANIMAÇÃO DO CORAÇÃO (BUCIOLI ET AL., 2007).
Um outro projeto, desenvolvido em conjunto pelo Massachusetts Institute of
Technology e Surgical Planning Laboratory of Brigham and Women’s Hospital,
pretende criar ferramentas de apoio a cirurgia guiada através de imagem. Estas
ferramentas permitem aos cirurgiões visualizar, em tempo real, estruturas internas do
corpo do paciente através da sobreposição automática de reconstruções 3D. Um
exemplo da aplicação deste projeto é na remoção de tumores cerebrais.
Para o perfeito funcionamento deste projeto, o paciente tem de passar por quatro
etapas (Bucioli et al., 2007): a construção de um modelo tridimensional do cérebro e
crânio
do
paciente
através
de
ressonância
magnética
e
tomografia
axial
computadorizada; a determinação da posição exata do paciente na mesa de cirurgia,
analisando a posição do couro cabeludo usando lasers de baixa potência e câmaras de
vídeo. Estes dados têm uma precisão elevada, com um erro inferior a um 1 milímetro
(Lab & Hospital, 1999). Utilizando os dados obtidos no processo anterior e algoritmos
de otimização, posiciona-se o modelo virtual do crânio sobre o paciente; Por fim, a
15
última etapa consiste na visualização do modelo sobreposto ao paciente real num ecrã
presente na sala de operações, permitindo ver a estrutura interna do crânio do utilizador
e desta forma uma maior precisão na deteção do tumor. A Figura 5 ilustra este processo.
FIGURA 5: VISUALIZAÇÃO DO MODELO SOBREPOSTO NO PACIENTE (LAB & HOSPITAL, 1999).
Na área do entretenimento existem bastantes aplicações de realidade aumentada,
nomeadamente nos jogos virtuais. Cada vez mais gigantes da indústria, como por
exemplo a Sony e a Nintendo, com a PlayStation e a Wii respetivamente, apostam nas
tecnologias de RA para oferecer um novo conceito e mais interatividade e diversão aos
seus consumidores finais.
A Nintendo construiu a Wii, uma plataforma com um conceito de jogo diferente,
onde pretende aliar a diversão ao exercício físico. Possui um comando sem fios, o Wii
Remote, que tem incorporado um motor de vibração e um acelerómetro que é capaz de
detetar movimentos em três dimensões e interage com a consola através de
infravermelhos, mas é possível ligá-lo a outros dispositivos, como um computador,
através da tecnologia Bluetooth (Lee, 2008). Quando o comando é detetado pela
consola, o utilizador é representado no vídeo através de um avatar, que consegue
controlar com os seus movimentos em tempo real (Wuang, Chiang, Su, & Wang, 2011).
A Figura 6 representa a interatividade entre o utilizador e a consola em tempo real,
através do wii remote.
16
FIGURA 6: INTERAÇÃO DO UTILIZADOR COM A WII ATRAVÉS DO WII REMOTE (GAMEGURU, 2006).
Outra consola com bastante destaque e que utiliza o conceito de RA é a
PlayStation 3, através do equipamento PlayStation Eye, semelhante a uma webcam
tradicional mas com uma objetiva incorporada que suporta zoom duplo. A primeira
definição permite a formação de imagens na parte superior do tronco. A segunda é uma
grande angular que possibilita a formação de imagens de corpo inteiro (Marks, 2007).
Este equipamento possuiu um microfone que suporta comunicações de voz de alta
qualidade e a captura de vídeo é possível mesmo com baixa luminosidade. Um jogo que
utiliza este conceito é o EyePet. Destinado a crianças, simula um animal de estimação
com a qual é possível interagir em tempo real. Esta interação é possível através de
gestos e de uma marca de RA impressa. Conforme a Figura 7, a PlayStation Eye
analisa-a e, em tempo real e com base na orientação da marca, adiciona o objeto que lhe
está associado.
FIGURA 7: A MARCA DE RA E RESPETIVO OBJETO DO EYEPET (FAHEY, 2010).
17
2.1.4- Ferramentas de RA
Um dos primeiros projetos de RA, o Rekimoto’s 2D Matrix Code (Rekimoto,
1998), era baseado no uso de uma câmara e marcas. Estas marcas, quadradas, são
limitadas por uma margem preta (Iwasaki, Nishimura, Hamada, & Kozono, 2010).
Dentro desse limite encontra-se uma figura que, de forma a ser facilmente reconhecida,
é desenhada através de formas geométricas, desenhos simples e/ou textos. Este conceito
originou várias ferramentas para o desenvolvimento de aplicações de RA, das quais se
destacam o ARToolKit (ARToolKit, 2009), o ARToolKitPlus (Wagner & Schmalstieg,
2007) e o ARTag (Fiala, 2005).
O ARToolkit é um dos softwares mais utilizados para criar aplicações de RA
(Romano, 2010) e foi originalmente desenvolvido em 1999 por Hirokazu Kato, do
Instituto de Ciência e Tecnologia de Nara. É uma biblioteca baseada nas linguagens C e
C++, suportando também objetos virtuais criados nas linguagens VRML e OpenGL
(Bucioli et al., 2007), que permite o desenvolvimento de aplicações de RA através da
identificação de características das marcas, que permite processar a imagem e recolher
algumas informações relacionadas com a deteção, além de estimar a sua posição e
orientação em relação ao ambiente, através do relacionamento das coordenadas da
marca e da câmara (Ribeiro & Zorzal, 2011). Após capturada, a imagem é convertida
em valores binários (preto e branco) e comparada com os símbolos existentes. Quando a
imagem for reconhecida, o sistema sobrepõe-lhe o objeto virtual que lhe está associado
e analisa possíveis movimentos, alterações de distância e rotações, permitindo também a
utilização de ações pré-definidas através de dispositivos de entrada (e.g. teclado)
(Ribeiro & Zorzal, 2011). Segundo Jong-Chih, , o ARToolkit está limitado pela
associação estática entre as marcas e os modelos virtuais tridimensionais definidos para
essa aplicação e propõe um sistema que, através utilização de códigos de barras
unidimensionais e da ligação a uma base de dados online, permite armazenar e
manipular remotamente uma maior variedade de marcas e modelos tridimensionais,
aumentando assim a quantidade e variedade das mesmas (Jong-Chih, Hoang-Yang, LinSen, Yi-Sheng, & Li-Chang, 2010). A Figura 8 representa as várias fases do processo
do ARToolKit.
18
FIGURA 8: DIAGRAMA DE FUNCIONAMENTO DO ARTOOLKIT (ADAPTADO DE (SINCLAIR, 2001)).
O ARToolKitPlus (Wagner & Schmalstieg, 2007) é uma biblioteca que possibilita
o desenvolvimento de aplicações de RA, baseada no ARToolKit mas otimizada para
dispositivos móveis. Possui algumas melhorias em relação ao ARToolKit, entre as quais
o facto de utilização de aplicações computacionais com ponto fixo em vez do ponto
flutuante (Barreira, 2010) que, principalmente em dispositivos móveis, requeria
demasiado tempo para a operação (Wagner & Schmalstieg, 2007). O processo de
captura de imagem do ARToolKitPlus é feito em 3 passos (Jia, Qi, & Zuo, 2010): os
dados são capturados numa escala de cinzas, sendo que o ARToolKitPlus permite a
alteração automática do limiar de iluminação conforme as condições de luz, de seguida,
as marcas são detetadas e posteriormente todas elas são corrigidas de acordo com a
distorção da lente. Por fim, são estimadas as posições das marcas válidas. O
ARToolKitPlus apenas fornece funções para tracking das marcas, não disponibilizando
funções nem para o rendering dos objetos virtuais nem para a obtenção do ambiente
real.
Uma outra forma de desenvolver aplicações de RA é através do ARTag. Em
contraste com o ARToolKit, a deteção das marcas é feita através da técnica edge based
approach, ou seja, através da deteção da proximidade às arestas (Jia et al., 2010). Este
método melhora a desempenho e dispensa a necessidade de lidar com as diferentes
condições de iluminação. As arestas detetadas servem de base para o processo de
deteção da marca e estão ligados em segmento que, por sua vez, são agrupados em
19
quadriláteros e utilizados para calcular uma homografia onde o interior das marcas é
representado (Hirzer, 2008).
Quando se fala de aplicações de RA para integrar em páginas web, surgem as
aplicações baseadas em ActionScript (AS), como o FLARToolKit, PaperVision3D,
SLARToolKit e o FLARManager. O FLARToolKit é uma adaptação do ARToolKit para
AS3 fornecido por Saqoosha e permite integração com outros motores de ActionScript,
como o PaperVision3D (Dankov, Rzepka, & Araki, 2011). Numa breve comparação
(Nee, Ong, Chryssolouris, & Mourtzis, 2012), o FLARToolKit é utilizado para
desenvolver aplicações de RA baseadas na web, o FLARManager aplicações para o
Adobe Flash e o SLARToolKit disponibiliza uma biblioteca para o desenvolvimento de
aplicações com o Silverlight. Além destas, também o ARToolKitPlus poderia ser aqui
incluído.
2.1.5- Ferramentas de RA para dispositivos móveis
A visualização e processamento de vídeo, em tempo real, capturado através da
câmara de dispositivos móveis, tornaram-se suficientemente eficientes para suportarem
uma variedade de aplicações de RA para estes dispositivos, possibilitando o conceito de
presença dupla de informações, ou seja, os aspetos do plano físico capturado pela
câmara sobrepostos, simultaneamente, com as informações adicionais no ecrã do
dispositivo, permitindo uma compreensão ampliada do ambiente do utilizador
(Morrison et al., 2011). Desta forma, a popularidade das aplicações de RA para
dispositivos móveis tem vindo a aumentar (Fröhlich et al., 2011).
Para os dois principais sistemas operativos de dispositivos móveis mais utilizados
no ano de 2012 (Stats, 2013), Google Android e Apple iOS, existem já bastantes
aplicações de RA que, utilizando todas as funcionalidades do dispositivo, conseguem
complementar a informação espacial com informação virtual através da RA. De entre
estas aplicações, destacam-se a Vuforia, o Layar, a Wikitude e a Aurasma.
A plataforma de desenvolvimento Vuforia, desenvolvida pela Qualcomm
Technologies, Inc, é uma plataforma que fornece as ferramentas necessárias, simples e
poderosas para desenvolver aplicações de RA para dispositivos móveis, Android ou
20
iOS. Este Software Development Kit (SDK), cujo diagrama de fluxo de dados é
representado na Figura 9, utiliza o dispositivo móvel como um portal para um mundo
aumentado onde a realidade e a virtualidade parecem coexistir (Balint et al., 2012). Com
base na imagem capturada, são aplicados vários algoritmos para a deteção de targets,
tendo assim uma melhor precisão para a deteção de alvos (Balint et al., 2012). Renato
Lopes afirma que, ao capturar a imagem, a câmara garante que cada frame seja
capturada e transmitida de forma eficiente para o tracker, sendo simultaneamente
convertida para a resolução e tamanho exigidos pelo dispositivo, através do Pixel
Format Converter, que efetua a conversão do formato da câmara (i.e. YUV12) para um
formato adequado ao rendering em ES OpenGL (i.e. RGB565) e para o tracking (i.e.
luminância) (Lopes & Cardoso, 2012). O tracker contém algorítmos de visão
computacional que detetam e analisam os objetos do mundo real, nas imagens
capturadas pela câmara, recorrendo a diferentes algoritmos, com o objetivo de detetar
alvos e/ou marcas e avaliar possíveis botões virtuais (Ibañez & Figueras, 2013; Lopes &
Cardoso, 2012). O tracker suporta vários datasets, mas apenas um pode estar ativo de
cada vez.
21
FIGURA 9: DIAGRAMA DE FLUXO DE DADOS DO SDK VUFORIA NUM AMBIENTE DE APLICAÇÃO
(QUALCOMM TECHNOLOGIES, 2013B).
As marcas do Vuforia, ao contrário das marcas RA a que estamos habituados, não
se limitam a uma borda negra com uma figura geométrica o mais simples possível. Ao
invés disso, utiliza marcas naturais não aparentes (markerless), sendo possível usar
qualquer imagem ou objeto como referência para o registo no sistema, como por
exemplo produtos, caixas, rótulos, fotografias, entre outros (Forte et al., 2012).
Qualquer um destes objetos pode ser uma marca de RA na plataforma Vuforia, desde
que obedeçam a um determinado conjunto de regras impostas pelo algoritmo de deteção
da plataforma. Estas marcas são geradas online, no sítio da Qualcomm Vuforia
(Qualcomm Technologies, 2013a). O utilizador envia a imagem que pretende utilizar
como marca, o sistema processa a imagem e cria um ficheiro XML e um ficheiro
binário que o utilizador irá utilizar na aplicação. O SDK Vuforia fornece uma biblioteca
(objeto partilhado libQCAR.so no Android e biblioteca estática libQCAR.a no iOS) que
deverá estar ligada à aplicação. A Figura 10 representa todo este processo.
22
FIGURA 10: VISÃO GERAL DO PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES NA PLATAFORMA
VUFORIA (QUALCOMM TECHNOLOGIES, 2013A).
O Vuforia possui ainda uma extensão para o Unity3D, um sistema de
desenvolvimento orientado para simulação que permite a construção multiplataformas,
de forma mais simples e rápida, devido ao poderoso Game Engine que disponibiliza
(Ibañez & Figueras, 2013; Qualcomm Technologies, 2013a).
Layar é um browser de RA que utiliza o recetor de GPS incorporado no
dispositivo para mostrar o que está geograficamente próximo, exibindo informações em
tempo real, sobre a imagem que está a ser capturada e permitindo interagir em tempo
real com essas informações. David Meerman Scott afirma que este browser é bastante
útil para quem está numa cidade que não conhece, sendo apenas necessário apontar a
câmara para a rua e em tempo real surgem diversas informações, desde restaurantes,
espaços de diversão, espaços culturais, estações de transportes públicos entre muitos
outros (Scott, 2010). Scott define ainda o Layar como um mashup entre a câmara do
dispositivo, a localização GPS e um enorme conjunto de dados. Além dos pontos de
interesse padrão, é possível descarregar e adicionar novas Geo Layers desenvolvidas por
qualquer pessoa, através da ferramenta disponibilizada pelos seus criadores. Um
exemplo de Geo Layer é o Jardim Botânico da UTAD, exibido na Figura 11. Esta
aplicação permite também interagir com materiais impressos, como revistas e jornais,
23
dando vida às páginas estáticas e transformando-as, por exemplo, em vídeos. Além
disso, o utilizador pode partilhar as suas experiências nas redes sociais.
FIGURA 11: GEO LAYER DO JARDIM BOTÂNICO DA UTAD NA APLICAÇÃO LAYAR, QUE PERMITE
INTERAGIR COM 18 PONTOS DE INTERESSE.
O Wikitude é um SDK que também permite o desenvolvimento de RA. Possui
praticamente todas as características do Layar, mas acrescenta-lhe ainda mais
funcionalidades interativas. Além da tradicional sobreposição de pontos de interesse ao
vídeo capturado em tempo real, possui um mapa que permite ver conteúdos publicados
perto do utilizador ou relacionados com a localização, como por exemplo tweets do
Twitter, artigos da Wikipedia, vídeos do Youtube e Flickr.
Entre as diversas funcionalidades, uma que se destaca é o Wikitude Drive, um
sistema de navegação através do GPS e RA que sobrepõe ao vídeo capturado o trajeto e
as instruções de orientação. Tracy Cozzens
considera que esta é funcionalidade
vantajosa para o utilizador pois permite, por exemplo, que um condutor que conduza de
noite seja auxiliado através de um mapa onde é possível alterar para uma vista
tridimensional apenas com um toque no ecrã (Cozzens, 2011). O Wikitude possui um
sistema de jogos de RA, entre a câmara e o mundo virtual. É também possível apontar a
câmara para uma quantia em dinheiro e efetuar taxas de câmbio automaticamente. Além
24
disto, o utilizador pode ainda criar o seu mundo no Wikitude e partilhá-lo nas redes
sociais.
Ao contrário das duas anteriores, a plataforma Aurasma não é baseada na
utilização do GPS do dispositivo, mas sim na análise de imagem impressa. Com ela é
possível dar vida a uma imagem completamente estática, presente num jornal ou revista,
um quadro do museu ou um simples logótipo de um café.
O seu funcionamento é muito simples. O utilizador captura uma imagem,
denominadas auras, a aplicação reconhece-a e surge um vídeo, uma hiperligação para
uma página web ou até mesmo uma animação tridimensional que está associada à
imagem.
Em Portugal, o jornal Correio da Manhã utiliza esta aplicação, difundindo o
conceito e tornando mais interativa a leitura dos seus conteúdos.
2.1.6 – Aplicações de RA para dispositivos móveis
A RA é uma tecnologia que ganha cada vez mais visibilidade nos dispositivos
móveis. Existem diversas aplicações que utilizam este conceito para entreter, orientar e
auxiliar o utilizador em tarefas do dia-a-dia, tornando-se cada vez mais populares. Um
novo género de aplicações móveis são os browsers de RA, como o Layar e o Aurasma,
abordados anteriormente, que incorporam elementos virtuais sobre os dados adquiridos
pela câmara do dispositivo (Bolter, Engberg, & MacIntyre, 2013). Além dos browsers
de RA existem aplicações mais complexas, que aproveitam as capacidades que estes
dispositivos fornecem, como GPS, câmaras, sensores de inclinação, ligações rápidas à
internet, bússolas digitais, entre outras, para desenvolverem sistemas mais completos e
avançados, como por exemplo jogos. Um exemplo destes jogos chama-se Ingress,
desenvolvido pela Google e encontra-se em fase beta, o que não o impede de já possuir
uma grande quantidade de jogadores. Este jogo tem como enredo a luta pelo controlo
das mentes de todos os habitantes deste planeta e utiliza o mundo real como cenário.
Proporcionando uma nova visão do ambiente urbano, o jogador percorre o mundo à
procura de energia, que lhe possibilitará posteriormente aceder a portais. Estes portais,
virtualmente associados a objetos públicos, estátuas e monumentos ou até mesmo peças
de museus, são controlados por uma das duas equipas que o utilizador pode escolher
quando inicia o jogo: os iluminados (The Enlightened) e a resistência (The Resistance),
25
que, em equipa, procuram pela sua cidade vestígios da equipa adversária, combatendo-a
com o auxílio do seu smartphones e das armas virtuais disponibilizadas pela aplicação.
FIGURA 12: VISÃO GERAL DO INGRESS (BIT, 2013).
Outro jogo que combina o mundo real com a RA chama-se X-Rift e utiliza a
câmara do dispositivo para capturar a cena real e sobrepor-lhe elementos virtuais com
base nas coordenadas recebidas do recetor GPS. Estes elementos virtuais são
obstáculos, como monstros, que o utilizador deve destruir, possuindo um radar que
localiza os restantes inimigos. Além disso, este jogo possui modo multiplayer, onde
vários jogadores podem cooperar de forma a ultrapassarem os diferentes níveis. Mas a
realidade aumentada nos dispositivos móveis não se limita aos jogos, mas também a
aplicações que facilitam ou enriquecem as atividades do utilizador. A aplicação Word
Lens Translator utiliza a câmara do dispositivo móvel para, em tempo real, detetar
textos em inglês e automaticamente substituí-los pela respetiva tradução em espanhol,
francês, italiano, alemão e português, na própria imagem. Por outro lado, a Augment 3D Augmented Reality, utiliza as potencialidades do smartphones para fazer o rendering
de objetos virtuais animados no mundo virtual, sendo possível movimentá-los pelo ecrã,
posicionando-os em pontos estratégicos. Esta aplicação é bastante útil para, por
exemplo, simular como fica um móvel numa sala ou um prédio em construção numa
determinada zona. A RA pode ser utilizada em diversas áreas e com diferentes objetivos,
sendo uma mais-valia relativamente à segurança rodoviária. Existem diversas aplicações para
26
dispositivos móveis que permitem auxiliar o condutor nas suas viagens. iOnRoad Augmented
Driving é uma aplicação que exibe informações relativamente à circulação do automóvel do
utilizador. O dispositivo móvel é estrategicamente colocado na frente do veículo e, com o
recurso a vários sensores faz a deteção de objetos que se encontrem à sua frente, calculando a
velocidade do veículo em tempo real e consecutivamente a distância para os mesmos, emitindo
sinais visuais e sonoros sempre que se encontram a distâncias reduzidas, alertando o utilizador
para a possibilidade de colisão enquanto está a tempo de travar.
2.1.7 – Unity3D
O Unity3D é uma ferramenta para o desenvolvimento de jogos criado por uma
companhia Dinamarquesa chamada Unity Technologies. De aprendizagem fácil e
flexível, proporcionando um ciclo de desenvolvimento rápido e um sistema de eixos do
Blender (Foundation, 2013) incorporado (Macedo & Rodrigues, 2011), rapidamente
conseguiu tornar-se num dos Game Engines mais populares no seio dos programadores
(Wenfeng & Xin, 2012).
Disponível para Windows e Mac OS, uma das suas características mais fortes é
permitir que o mesmo código, seja exportado para ser executado em diversas
plataformas: Windows, Mac OS, XBOX 360, PlayStation 3, Nintendo Wii, Apple iOS,
Google Android e também nos browsers mais modernos (Jie, Wang gen, & Xiaoqing,
2012; Macedo & Rodrigues, 2011). É importante referir que o Unity3D também permite
exportar para a funcionalidade Adobe Stage3D do Adobe Flash. Contudo, algumas das
suas funcionalidades não são suportadas pelo Flash (Jie et al., 2012). O Unity3D
também suporta a utilização de scripts nas linguagens JavaScript (JS), C# e também um
dialeto de Python chamado Boo (Sa et al., 2010), sendo que, o autor anteriormente
referenciado afirma que os scripts são normalmente vistos como lentos e limitados mas,
como no Unity3D são compilados para código nativo, são executados quase tão
rapidamente como C++. O mesmo autor considera ainda que estas três linguagens são
igualmente rápidas e interoperáveis, podendo aliar-se às bibliotecas .NET que têm
suporte a base de dados, expressões regulares, XML e também à rede. As suas
características específicas incluem um editor de código integrado, editor de terreno,
shaders, scripts, networking, simulador de física, controlo de versão, entre muitas outras
27
(Jie et al., 2012; Wenfeng & Xin, 2012). O Unity3D é totalmente otimizado para o
DirectX e OpenGL (Sa et al., 2010).
Feijó et al explicam o funcionamento da programação orientada a objetos dizendo
que é uma modelação do mundo como uma coleção de entidades, denominadas de
objetos, com comportamentos próprios e que cooperam entre si, tornando desta forma o
código mais fácil e organizado (Feijó, Clua, & da Silva, 2010). No que diz respeito ao
desenvolvimento em si, no Unity3D todos os objetos na cena do jogo são instâncias da
classe GameObject. O GameObject é uma classe que contém todos os componentes que
podem ser utilizados nos objetos e dessa forma implementar-lhe funcionalidade real
sendo, por exemplo, a luz um componente que está ligado a um GameObject. O
GameObject pode ser associado a vários componentes e especificar diversas
propriedades. Quando um script é desenvolvido, herda automaticamente as
características da classe MonoBehavior, que é uma subclasse especial do Componente.
Um grupo de investigadores indica algumas características poderosas do Unity3D
(Sa et al., 2010). Em primeiro lugar, contém mais de 40 sombras, desde as mais simples
(e.g. diffuse e glossy) às mais complexas (e.g. Self Iluminated bumped specular),
funcionando todas com qualquer tipo de iluminação. A segunda característica refere-se
à possibilidade de criar scripts dentro do próprio Unity3D, utilizando o editor integrado.
Contudo, para funções mais complexas, é possível utilizar-se o Visual Studio, sendo
possível depois compilar as cenas com o Visual Studio, adicionando o UnityEngine.dll.
Assim, uma das características mais conhecidas do GameEngine é o seu sistema de
análise de colisão entre objetos, utilizando todos os recursos do Ageia PhysX, presente
em jogos como o Unreal Tournament 2007 e o Ghost Recon 3, entre outros. Além
disso, tem um suporte total para Rigidbodies, que atuam com forças, colisões e análise
das articulações, sem requerer nenhum script ou código adicional. Por fim, é possível
adicionar-se sons, animações e vídeos aos GameObjects, aumentando desta forma a
imersão do utilizador no sistema de realidade virtual.
Em suma, Clarke et al afirmam que os programadores escolhem o Unity3D pela
sua versatilidade multiplataformas (Clarke, Arnab, Dunwell, & Brown, 2012) e Macedo
et al acreditam que o processo de transportar o jogo para outras plataformas é simples e
fácil (Macedo & Rodrigues, 2011). Além da criação de jogos, esta ferramenta permite
também a criação de outro conteúdo, como a visualização arquitetónica ou animações
28
3D em tempo real, sendo possível realizar aplicações de RA recorrendo, por exemplo, à
extensão do Vuforia, já abordada.
Apesar da RA já existir há algumas décadas, encontra-se ainda em grande
desenvolvimento, surgindo cada vez mais sistemas que proporcionam ao utilizador
diferentes experiências em tempo real. Desde simples adições de objetos virtuais ao
mundo real até ambientes completamente virtuais, onde o utilizador se abstrai
totalmente do seu mundo e interage com um sistema totalmente construído por
computador, a RA tem vindo a crescer e a possibilitar a criação de sistemas cada vez
mais complexos.
2.2- Hypertext Markup Language
Com a criação da Internet, surgiu a necessidade da criação de standards capazes
de estruturar a sua utilização e o desenvolvimento de conteúdos, de forma a evitar que a
Internet se transformasse num mundo de propriedade de formatos incompatíveis,
reduzindo-se dessa forma o seu potencial comercial para todos (W3C, 1999).
2.2.1- Introdução e história do HTML
Em 1989, Tim Berners-Lee desenvolveu o HTML, acrónimo de Hypertext
Markup Language, com o objetivo de facilitar a comunicação com os seus colegas
(Ferreira & Eis, 2011). Contudo, esta linguagem mudou o Mundo da Internet. BernersLee baseou-se no SGML (Standard Generalized Markup Language), um padrão
internacional para a marcação de texto para apresentação numa variedade de
dispositivos físicos, em que a ideia principal era tornar independentes estrutura e
apresentação, algo que no início o HTML não possibilitava.
Como o próprio nome indica, o HTML é baseado em hipertexto. Segundo
Pfaffenberger hipertexto é um tipo de texto que possibilita que o utilizador navegue de
uma página hipertexto para outra (Pfaffenberger, Schafer, White, & Karow, 2004).
Dentro destas páginas, podem ser usados um leque de elementos, como por exemplo
imagens, texto, vídeos e áudio. Ao contrário de um texto comum, o hipertexto permite
29
que o utilizador defina a sua navegação de acordo com as suas necessidades. Enquanto
um livro foi concebido para ser lido em sequência, onde a página dois sucede a um, o
hipertexto permite que o utilizador vá para o que verdadeiramente lhe interessa.
Além da utilização de hipertexto, o HTML pretende ser uma linguagem
interoperável. Woodley define interoperabilidade como a capacidade de diferentes tipos
de computadores, redes, sistemas operativos e aplicações trabalharem eficazmente em
conjunto, sem comunicação prévia, de forma a trocarem informação útil e com
significado, ou seja, funcionar em todas as plataformas, independente de sistemas
operativos, browser, resoluções e outros meios de acesso (Woodley, 2005).
Sensivelmente um ano após a sua criação, o HTML ganhou popularidade com o
Mosaic, um browser desenvolvido por Marc Andreessen, que impulsionou outros
criadores de browsers a adotarem o HTML (Ferreira & Eis, 2011).
Todas estas páginas de hipertexto juntas formam a World Wide Web, vulgarmente
conhecida por WWW.
O W3C é um consórcio internacional que pretende equilibrar os interesses dos
programadores, criadores de browsers e tecnologia. Reúne comités com representantes
de empresas de alta tecnologia e está responsável por criar os standards do HTML,
HTTP e de uma série de padrões adicionais, como o CSS (Cascading Style Sheets).
Segundo o W3C (W3C, 1999), a WWW é uma rede de recursos de informação,
construída sobre três pilares:
 Um sistema que determina como cada página de informação ou recurso
recebe um endereço único e utilizado para aceder a esse mesmo elemento:
URI (Uniform Resource Identifier);

Um protocolo que garante a comunicação entre o browser e o servidor: o
protocolo HTTP (Hypertext Transfer Protocol) (Figura 12);
 Uma linguagem de marcação para codificar a informação, para que esteja
acessível numa vasta quantidade de dispositivos: o HTML.
30
FIGURA 13: O PROTOCOLO HTTP, RESPONSÁVEL PELA COMUNICAÇÃO ENTRE O BROWSER DO
UTILIZADOR E O SERVIDOR WEB.
O W3C define HTML como uma linguagem de publicação de conteúdo, como
texto, imagem, vídeo e áudio, entre outros, na web.
Abreu entende HTML como uma linguagem que permite a construção de páginas,
através de conjuntos de elementos, vulgarmente conhecidos por tags, utilizados para
descrever apresentar uma página web (Abreu, 2012).
Ao longo dos anos o HTML foi evoluindo e foram lançadas várias versões.
Contudo, não existiam padrões e cada um criava á sua maneira. De forma a evitar que a
web fosse construída em base proprietária, com formatos incompatíveis e limitados,
surgiu em 1994 o World Wide Web Consortium (W3C).
Em 1997, o W3C lança a versão 3.2 do HTML, criando assim um standard,
fazendo com que cada browser reconheça as páginas HTML da mesma forma, deixando
de ser necessário criar uma página diferente para cada um e desta forma reduzir custos e
finalmente tornar o HTML interoperável. Ainda em 1997, o W3C anunciou o HTML
4.0 (W3C, 1997). Com o lançamento da versão 4.0 surgiram alguns erros, corrigidos
alguns meses depois, aquando o lançamento do HTML 4.01. Esta versão trouxe
algumas melhorias: otimização da acessibilidade, reconhecimento de scripts, melhor
controlo da estrutura de tabelas, melhor indexação aos motores de busca, suporte a
objetos, entre outras novidades. Por fim, surgiu em 2000 o XHTML (Extensible
HyperText Markup Language), juntando o padrão do HTML com a extensibilidade do
XML (eXtensible Markup Language).
31
Contudo, o grande marco do HTML ocorreu em 2008 com o início do HTML 5,
que promete revolucionar o mundo da Internet.
2.2.2- A nova versão: HTML5
Nos dias de hoje é fundamental estar sempre ligado à Internet, por questões
profissionais ou de entretenimento. Desde 2010 o número de acessos à web através de
dispositivos móveis duplicou, havendo cada vez mais utilizadores a ligarem-se através
de smartphones ou tablets, em qualquer lado (Vedor, 2012).
O HTML 4.01 apesar de garantir uma quase interoperabilidade, não era suficiente
e perfeito. Possuía várias fragilidades que neste tipo de dispositivos são cruciais: Os
programadores criavam as páginas sem grande cuidado, com estruturas complexas e
muitas das vezes recorriam a plug-ins que não tinham suporte em dispositivos móveis
para incorporar ficheiros multimédia, como por exemplo o Adobe Flash, Apple
QuickTime e o Microsoft Silverlight.
Segundo Pilgrim, o HTML 5 é a próxima geração de HTML, substituindo os
ultrapassados HTML 4.01 e XHTML 1.0 e 1.1 (Pilgrim, 2010). É também uma
tecnologia que introduz novos recursos que são necessários para criar aplicações web
modernas. Na opinião do mesmo autor, durante anos os programadores de páginas web
utilizaram recursos que nunca tinham sido aprovados ou documentados, tornando assim
essas páginas suscetíveis à incompatibilidade quando processadas por diferentes
browsers.
McDaniel afirma que o HTML 5 é baseado nas mesmas tecnologias, mas possui
ferramentas poderosas de forma a criar a próxima geração de sítios, com o auxílio das
CSS3 e do JavaScript, de forma a construir sites mais interativos e com movimento
(McDaniel, 2011).
Após o lançamento da versão 4.01 do HTML, o W3C começou a preparar uma
versão baseada em XML e HTML, que iria constituir o XHTML 2.0. Ao mesmo tempo,
o grupo WHATWG (Web Hypertext Application Technology Working Group), que não
concordava com o rumo que o W3C queria dar ao HTML, começou a preparar aquilo
que hoje conhecemos como HTML 5. Em meados de 2008 o W3C acabou por ceder e
32
unir forças com o projeto proposto pelo WHATWG e desde aí ambos os grupos têm
trabalhado em conjunto no standard que promete revolucionar a web.
O W3C definiu como quatro princípios chave de conceção do HTML 5 a
compatibilidade, a utilidade, a interoperabilidade e o acesso universal (W3C, 2007):

Compatibilidade: Existem alguns elementos que estavam presentes em
versões anteriores do HTML, que agora deixam de ser utilizados. Uma
aplicação deverá ser capaz de ser processada da melhor forma possível em
browsers mais antigos. Além disso, evolução não é revolução. Existem já
várias funcionalidades que não necessitam de ser recriadas, evitando-se
assim reinventar a roda.

Utilidade: Uma aplicação web deverá ser utilizada da melhor forma para
todos os fins pretendidos. O grupo de trabalho do HTML 5 pretende
enfrentar e eliminar definitivamente os erros de versões transatas e
assegurar que os recursos funcionem com o modelo de segurança da web.

Interoperabilidade: Outra vontade relacionada com o HTML 5 é permitir
que possa ser processado em todos os browsers mais utilizados. Deverá ser
uma linguagem reconhecida pela simplicidade de cada recurso e permitir
que os erros sejam tratados, reduzindo assim o risco de problemas da
aplicação.

Acesso universal: Este princípio está, em parte, relacionado com o
anterior. Uma aplicação web deverá ser capaz de trabalhar em diferentes
plataformas, dispositivos e meios de comunicação, independentemente de
sistemas operativos, resoluções de tela e diferentes arquiteturas. Deverá
também permitir a publicação em todos os idiomas e permitir que pessoas
com algum tipo de capacidade reduzidas, independentemente da
habilidade ou capacidades físicas, consigam também usá-lo.
O HTML 5 inclui também recursos que não são diretamente controlados pelo
WHATWG ou pelo W3C, como por exemplo a API de Geolocalização. Esta API está a
ser desenvolvida pelo GWG (Geolocation Working Group) e, por ser parte da evolução
33
da web moderna, é associado ao HTML 5, fornecendo-lhe recursos imprescindíveis para
uma maior experiência por parte do utilizador.
Por ser uma tecnologia ainda em desenvolvimento, a lista de recursos definidos no
HTML 5 está sempre a ser alterada, quer seja para adicionar ou melhorar recursos já
existentes, sempre com o objetivo de simplificar. Os principais recursos que o HTML 5
nos oferece:
Semântica: Oferece uma forma mais simples para a construção de um layout
semântico. É possível construir um layout de uma página sem recurso às antigas tags
<div>, anteriormente usado para delimitar secções de uma página, utilizando novos
elementos estruturais como o <header>, <nav> ou <footer>, que criam uma área
destinada, respetivamente, para o cabeçalho, área de hiperligações e rodapé;
Formulários mais ricos: uma das principais vulnerabilidades de um sítio são os
campos de introdução de dados por parte do utilizador. No HTML 4, é necessário
validar esses dados no lado do servidor e, para proporcionar uma melhor experiência ao
utilizador, também do lado do cliente, que poderia ser conseguido recorrendo ao JS.
Na versão 5 do HTML, estes formulários foram revistos e é possível restringir os
campos para formatos de valores específicos, como números de telefone, intervalos de
valor ou até mesmo um formato definido pelo próprio utilizador, dispensando desta
forma a verificação através do JS;
Os formulários HTML passaram a ter também alguns novos tipos de campos de
formulário, como os sliders e data, e também atributos como o placeholder e o
autofocus, responsáveis por pré-definir um valor padrão num determinado campo e
selecionar automaticamente um deles quando a página é carregada.
Novo suporte para elementos de vídeo e áudio: há algum tempo atrás, a
multimédia tinha a sua presença na Internet quase que restrita a formatos mais leves,
como o MIDI ou os GIFs animados. Com a evolução da largura de banda, começou a
ser possível suportar-se formatos mais pesados e consequentemente com maior
34
qualidade, como o MP3 ou AVI. Contudo, para os incorporar nas páginas web era
necessário recorrer à instalação de plugins de terceiros no cliente, como por exemplo o
Adobe Flash ou o Microsoft Silverlight.
Em 2007, Anne Van Kesteren comunicou ao WHATWG que a empresa Opera se
encontrava a desenvolver um novo mecanismo de vídeo, que primava pela simplicidade
e era idêntico ao antigo elemento (Kesteren, 2007).
Abreu comenta que o termo “vídeo” é, na maior parte das pessoas,
automaticamente associado, pela maior parte das pessoas, a ficheiros nos formatos AVI
ou MP4, quando na realidade estas designações apenas identificam o formato do
contentor (Abreu, 2012). Um contentor pode conter vários elementos no seu interior,
como clips de vídeo e áudio, título, informações sobre o episódio, entre outros, e limitase a gerir a organização desses elementos. O armazenamento destas faixas de vídeo e
áudio dentro dos contentores é possível devido àquilo a que chamamos “codificação”,
com recurso a codecs para a codificação e posterior descodificação dos mesmos. Abreu
afirma ainda que atualmente a especificação do HTML 5 não impõe restrições em
relação aos codecs que devem ser suportados nos browsers, sendo que o Mozilla
Firefox, Google Chrome e Opera suportam o codec de vídeo Theora e o codec de áudio
Vorbis, em contentores Ogg.
Segundo Peter Lubbers, os novos elementos de áudio e vídeo permitem adicionar
novas opções multimédia sem a necessidade de plug-ins externos, proporcionando
assim aos programadores uma API comum, integrada e programável, que pode ser
utilizada para criar aplicações mais atraentes (Lubbers, Salim, & Albers, 2011).
Nas versões anteriores do HTML, a solução para incorporar vídeos ou áudio em
páginas web passava pela utilização do elemento <object>. Contudo, devido às diversas
incompatibilidades entre os browsers, esse elemento requeria o elemento <embed>.
Durante anos essa foi a solução, contudo não era a melhor, pois implicava muitas das
vezes duplicar parâmetros e usar comandos demasiado complexos e confusos. O
HTML5 veio assim simplificar esses dois elementos, fornecendo os elementos <vídeo>
e <audio>, com valências mais simplistas.
35
API de Geolocalização: Apesar de não ser uma API diretamente controlada e
desenvolvida pelos grupos de trabalho do HTML 5, faz parte da evolução da web
moderna, disponibilizando recursos capazes de proporcionar uma experiência mais rica
ao utilizador.
Existem várias estratégias de marketing, que tentam cativar os utilizadores a
adquiri determinados serviços ou produtos. Uma estratégia que está a crescer a um ritmo
elevado, recorre à geolocalização, permitindo desta forma que os anúncios sejam
contextualizados e cheguem a pessoas que realmente poderão necessitar deles. “Muitos
sites oferecem anúncios específicos de acordo com o dia, a hora, a localização
geográfica do utilizador, etc.“ (Rita & Oliveira, 2006). Um bom exemplo é quando um
utilizador efetua uma pesquisa num motor de busca, utilizando a expressão
“restaurante” e nos resultados surgem em primeiro lugar, os restaurantes que são da sua
região. A posição geográfica do utilizador é determinada e representada através de um
par de coordenadas: a latitude e a longitude.
A API de geolocalização do HTML 5 requer autorização do utilizador para obter
as suas coordenadas de localização e permite não só determinar a posição atual do
utilizador como também verificar, em intervalos regulares, se essa posição se altera,
utilizando o método watchPosition.
Canvas: Até agora, para representar gráficos mais avançados era necessária a
utilização de plug-ins, como o Adobe Flash ou o Microsoft Silverlight. O HTML5, mais
uma vez inovou e procurou simplificar o processo, adicionando o elemento <canvas>.
Originalmente criado pela Apple, em 2004, para o MAC OS X e posteriormente
para o Safari, o canvas foi adotado pela especificação desta tecnologia. Chuck Hudson
diz que o coração do canvas é formado por dois componentes (Hudson & Leadbetter,
2011): o canvas do HTML e o JS, para executar operações. Tal como acontece com um
pintor, a tela fica em branco até que ele decida começar a utilizar os pincéis e as
ferramentas disponíveis para criar a sua obra de arte. Da mesma forma, o JS fornece-nos
as ferramentas necessárias para criar uma panóplia de projetos com o canvas.
Remy Sharp afirma que esta é uma das maiores partes da especificação do
HTML5, tendo até sido escrito num documento à parte dela, não deixando no entanto de
fazer parte da mesma (Lawson & Sharp, 2010). Já Steve Fulton acredita que o canvas
seja o elemento mais interessante do HTML5 e define-o como um bitmap de modo
36
imediato (immediate mode) que cria uma superfície retangular, por omissão com 300
pixéis de largura e 150 pixéis de altura, que pode ser manipulada com recurso a JS
(Fulton & Fulton, 2011). Abreu afirma que immediate mode se refere à forma como os
pixéis são renderizados nesta superfície, sendo neste caso necessário criar o código JS
dos elementos gráficos aos quais se pretende fazer o rendering (Abreu, 2012). Uma
característica deste elemento é não possuir “memória”, obrigando a fazer novamente o
rendering dos elementos sempre que seja necessário atualizá-lo. O facto deste elemento
recorrer a um bitmap immediate mode, torna-o muito diferente do Flash, Silverligh e
SVG, que operam em retained mode. Este modo, em vez de fazer o rendering
diretamente, atualiza o estado interno da biblioteca gráfica, ou seja, ao contrário do
immediate mode, é mantida uma lista dos objetos presentes na superfície e esses objetos
possuem propriedades capazes de influenciar o seu comportamento (ex: coordenadas X
e Y, tamanho, cor, etc.). Este modo de bitmap afasta o programador de operações de
baixo nível, mas proporciona-lhe menos controlo sobre o processamento final na
superfície (Gu & He, 2012).
Lubbers refere que o canvas suporta as mesmas operações bidimensionais que os
sistemas operacionais e estruturas mais modernas e que quem já tenha desenvolvido
para esses sistemas não irá sentir dificuldades a adaptar-se (Lubbers et al., 2011). Por
outro lado, quem nunca utilizou estes sistemas irá ficar agradavelmente surpreendido
com o quão mais poderosa é esta tecnologia quando comparada ao que foi feito nas
CSS, durante muitos anos, pelos programadores.
De acordo com Rob Hawkes não se desenha diretamente na API do Canvas, mas
sim num contexto bidimensional que ele nos proporciona (Hawkes, 2011). Este
contexto permite-nos executar incontáveis funcionalidades (Fulton & Fulton, 2011):
- Criar e modificar desenhos bidimensionais, textos e imagens bitmap;
- Aplicar cores, rotações, opacidade e manipular pixéis;
- Criar diferentes tipos de linhas, curvas e caixas e exibir gráficos;
- Criar e modificar animações avançadas;
- Deteção de colisões;
- Incorporar e manipular vídeo e áudio;
- Construir uma framework capaz de criar uma variedade de jogos;
37
- Desenvolver gráficos de jogos animados. Apesar de ainda não haver um
contexto tridimensional, existem já várias implementações, como o WebGL, mas
nenhuma adotada pelo standard do HTML5 (Ferreira & Eis, 2011). Contudo, isso
não impede os programadores de explorarem maneiras de utilizar técnicas 3D e
criar aplicações multiplayer.
Com o recurso ao JS é possível criar animações complexas, incluindo fundos
interativos para sítios, elementos de navegação, ferramentas gráficas, eventos de rato e
teclado, captura de frames de um vídeo e até mesmo jogos com elevada interatividade.
Devido ao poder do elemento canvas e da globalidade do HTML5, a Apple
descontinuou, em Abril de 2010, o Adobe Flash em dispositivos móveis e decidiu
apostar no HTML5 (Jobs, 2010). Esta decisão deve-se principalmente a questões
tecnológicas e facilidade de uso do HTML5. Em primeiro lugar, o HTML5 é um
standard aberto e não depende de plugins de terceiros, como era o caso do Flash. Em
segundo, o Flash não proporcionava uma “web completa” aos utilizadores de
dispositivos Apple, porque 75% dos vídeos da web são em Flash. O terceiro contra da
Apple prende-se com questões de segurança, confiabilidade e desempenho, enquanto o
quarto fator aponta a um gasto excessivo de bateria dos dispositivos móveis. O quinto
motivo refere-se ao facto de o Flash ter sido desenvolvido para computadores e para ser
utilizado com um rato, não para ecrãs táteis. Por último, o Flash é multiplataforma e a
Adobe não pode depender de terceiros para decidir quando distribuir as ferramentas aos
programadores. Estes seis motivos fizeram com que a Apple pretendesse abandonar o
passado e apostar no HTML5, uma tecnologia emergente e que vai dominar os
dispositivos móveis. Em consequência, em Novembro de 2011 a Adobe descontinuou o
desenvolvimento do Flash para browsers de dispositivos móveis, admitindo que o
HTML5 é a melhor solução para eles (Winokur, 2011).
O elemento canvas trás, finalmente, uma forma nativa de desenhar nos browsers
sem necessidade de recorrer a aplicações externas, é poderosa ao nível de
desenvolvimento e adivinha-se que os programadores o testarão até aos seus limites
(Lawson & Sharp, 2010).
Armazenamento de dados: Uma atividade fundamental para qualquer aplicação
web é a possibilidade de armazenamento de dados. Abreu afirma que, nas versões
anteriores do HTML, a única forma capaz de armazenar pequenas quantidades de dados
a partir de uma página HTML eram as cookies (Abreu, 2012). Os cookies podiam ser
38
utilizadas para guardar um valor, guardar nomes de utilizadores, preferências, datas de
autenticação, entre muitas outras possibilidades. Elcio Ferreira desacredita-as, por terem
uma interface complexa, envolvendo cálculos complexos com datas e controlo de nome
de domínio e também porque estavam limitadas a apenas 4KB de informação (Ferreira
& Eis, 2011). Remy Sharp também considera que os cookies não são a melhor opção,
achando-as uma ”porcaria ou lixo”, pois têm uma série de problemas que fazem com
que seja doloroso trabalhar com elas, preferindo procurar bibliotecas de JS capazes de
as substituir (Lawson & Sharp, 2010).
Chuck Hudson escreve que alguns conjuntos de dados podem melhorar a
experiência do utilizador se os cookies poderem ser armazenados e recuperados
localmente, em vez de serem recuperados do servidor de cada vez que são utilizados
(Hudson & Leadbetter, 2011). Com o HTML5 surgem duas novas formas de
armazenamento local: Web Storage e Web SQL Databases.
O Web Storage, baseado no conceito dos cookies, permite o armazenamento de
até 5Mb de informação por domínio e, ao contrário dos cookies, não são propagados
para o servidor através de pedidos HTTP, funcionando localmente. Esta funcionalidade
possui dois tipos de storage: localStorage e sessionStorage.
Elcio Ferreira e Abreu comparam estes dois tipos de Web Storage (Abreu, 2012;
Ferreira & Eis, 2011) : enquanto o localStorage armazena localmente os dados sem um
limite de tempo de vida e a sobreviver entre sessões, podendo ser recuperados numa
outra página carregada a partir de outra janela, o sessionStorage apenas mantém esses
dados durante a sessão na página atual, perdendo-se todos os dados armazenados
quando a página é encerrada, sem a possibilidade de serem recuperados numa utilização
futura. Ambos os tipos de armazenamento utilizam um objeto do tipo Storage, que se
comporta como um dicionário, onde os dados são mantidos no formato chave/valor,
sempre do tipo string. Caso se pretenda armazenar um valor que não seja do tipo string,
é necessário seriá-lo numa string antes de o armazenar.
O Web SQL Databases é uma outra forma de armazenar dados no cliente mas, ao
contrário do Web Storage, não se baseou nos cookies mas sim nas tradicionais bases de
dados SQL. Remy Sharp analisa este tipo de armazenamento e afirma que é necessário
saber utilizar a linguagem SQL, mais propriamente SQLite, pois é a ela que o Web
Storage recorre para o armazenamento (Lawson & Sharp, 2010). Quanto aos limites de
armazenamento, afirma que a documentação não é clara e que cada browser impõe os
39
seus limites sendo, por norma, 5Mb por domínio. Infelizmente esta forma de
armazenamento ainda não é suportada por muitos dos browsers, sendo que atualmente
apenas o Opera, o Chrome e o Safari a suportam (Deveria, 2013; Lawson & Sharp,
2010).
Estas duas novas formas de armazenamento prometem bastante e Hogan
considera que são fáceis de usar, incrivelmente poderosas, e razoavelmente seguras
(Hogan, 2011).
Existem muitas outras novidades no HTML5 que, por serem em tão elevado
número e por não serem objeto do trabalho, não é possível abordar nesta dissertação. O
HTML5 prometia e já provou que possui todas as funcionalidades para revolucionar o
desenvolvimento de aplicações web, quer através das funcionalidades explicadas
anteriormente, como o canvas ou o novo suporte para elementos áudio e vídeo, quer
também pelas funcionalidades não abordadas, mas com igual importância, como a
facilidade das interfaces drag and drop, aplicações offline ou da microdata.
As opiniões sobre esta tecnologia são, geralmente, positivas. Steve Jobs, fundador
da Apple, apoia o HTML5, por permitir que os programadores web criem gráficos
avançados, tipografia, animações e transições independentes de plug-ins externos, como
não acontece com o Flash, da Adobe (Jobs, 2010); Para Dion Almaer (Almaer, 2010),
co-fundador da Ajaxian.com, principal comunidade de Ajax, a revolução do Ajax foi um
hack e, com os browsers HTML5, temos finalmente um fantástico runtime. John
Harding, Engenheiro de Software do Google, afirma que na empresa estão
entusiasmados com o esforço do HTML 5, principalmente com a tag <video>, que
tornou possível a reprodução dos vídeos do Youtube através da interface em HTML5
(Harding, 2010).
2.3- Android
2.3.1- Introdução e estatísticas
Durante os últimos anos existiram várias tentativas para transformar o software de
dispositivos móveis em open source (e.g. Maemo, Debian Mobile, Symbian OS).
40
Existiam também alguns SO closed source (e.g. BlackBerry OS, Microsoft Windows
Mobile) mas nenhum se conseguiu assumir como perfeito. Apesar do Symbian OS
dominar o mercado de SO para dispositivos móveis (Hall & Anderson, 2009), nunca foi
visto como completo e o seu ambiente para desenvolvimento de aplicações era
complexo. Em 2007, a forma como os smartphones eram vistos mudou, após o
lançamento do iPhone. Desenvolvido pela Apple e com o sistema operativo iOS,
dispunha de uma interface tátil baseada na orientação do dispositivo, tornando-se no
primeiro SO móvel com uma grande comunidade de aficionados e transformou-se num
símbolo de luxo na população (Hall & Anderson, 2009).
O mundo dos dispositivos móveis ficou também marcado quando, em Novembro
de 2007, a Google anunciou o Android, um SO open source para dispositivos móveis.
Nesse mesmo dia anunciou também a criação do Open Handset Alliance (OHA), um
consórcio constituído por 84 empresas especialistas de tecnologia e tecnologia móvel
(e.g. T-Mobile, HTC Corporation, Samsung Electronics), com a ambição de acelerar a
inovação neste mercado e oferecer uma maior experiência no mercado móvel, mais
acessível e mais móvel. O primeiro telemóvel com este SO foi anunciado em Outubro
de 2008, pela T-Mobile, com o nome G1. Desde então, várias empresas de
telecomunicações, como a Samsung, adotaram o SO Android e o seu crescimento
tornou-se visível, tornando-o num rival credível do iOS, presente no iPhone da Apple,
que até então parecia destinado a liderar a internet móvel (Lyons, 2010).
A plataforma Google Android foi apontada como uma grande oportunidade para
os programadores de aplicações móveis (Rogers, Lombardo, Mednieks, & Meike,
2009). O Android é um dos atores principais no mercado de sistemas operativos para
dispositivos móveis, como telemóveis, tablets e televisões (Payet & Spoto, 2012). Andy
Rubin, criador do Android e diretor das plataformas móveis da Google, afirmou que não
deve haver nada que os utilizadores possam fazer num computador que não seja
possível no seu dispositivo móvel (BBC, 2008). Segundo a página oficial de
desenvolvimento do Android, existem atualmente centenas de milhões de dispositivos
ativados com este SO, espalhados por mais de 190 países e estes números não param de
aumentar, sendo diariamente ativos milhões de novos dispositivos (Google, 2012a).
Esta plataforma possui um mercado de aplicações pagas e gratuitas, denominado
Google Play, pré-instalado em mais de 400 milhões de dispositivos, que permite
personalizá-lo com quase todo o tipo de aplicações. Até Dezembro de 2012 foram feitos
41
mais de 25 biliões de downloads de aplicações e este número cresce à impressionante
velocidade de 1.5 biliões mensalmente, principalmente devido ao enorme número de
programadores desta plataforma e também da simplicidade com que cada um deles pode
adicionar as suas aplicações (Google, 2012d). Atualmente o SO vai na versão 4.2,
também conhecido por Jelly Bean, mas apenas 6.7% dos dispositivos a possuem, sendo
a versão mais usada a 2.3, Gingerbread, com cerca de 51% dos dispositivos (Google,
2012c). A Figura 13 mostra-nos o menu principal de um dispositivo Android com a
versão 2.3.7, assim como uma visão geral da Google Play.
FIGURA 14: MENU PRINCIPAL (ESQUERDA) E APLICAÇÃO GOOGLE PLAY DO SISTEMA OPERATIVO ANDROID
(DIREITA).
Sharon Hall e Eric Anderson dizem que o sucesso do Android se deve à resolução
dos problemas que os utilizadores apontavam aos anteriores dispositivos móveis (Hall
& Anderson, 2009): interfaces difíceis, digitação em dispositivos pequenos, velocidade
de rede, visualização de páginas web e falta de aplicações. De seguida analisam-se mais
detalhadamente algumas características.
42

Interfaces difíceis: A framework do Android permite que o hardware seja
construído de forma simples e amigável, integrada com um ecrã sensível
ao toque. O SO Android foi concebido para aproveitar todas as vantagens
dos ecrãs tácteis.

Digitação em dispositivos pequenos: Antes do Android, a maioria dos
dispositivos móveis dispunha de um teclado numérico de 12 teclas para
escrita. Escrever tornava-se complicado e chato (e.g. A tecla 2 tinha
associados os caracteres A, B e C, pelo que para escrever o “C” era
necessário pressionar esta tecla 3 vezes.). Este problema encontrou uma
solução com os teclados QWERTY. O Android permite que seja a empresa
responsável pelo hardware a decidir entre o tradicional teclado táctil do
Android ou um teclado físico, de 12 caracteres ou QWERTY.

Velocidade de rede: Nas primeiras redes móveis, a preocupação dos
utilizadores era que ela suportasse uma chamada sem que o sinal falhasse e
que a largura de banda fosse suficiente para reconhecer o timbre de voz da
outra pessoa (Brito & Aguiar, 2002). Hoje, os utilizadores querem estar
sempre ligados aos serviços de rede e Internet e, com os paradigmas
emergentes, como o Cloud Computing, o conceito de omnipresença é cada
vez mais necessário (Silva, Carvalho, Sousa, & Neves, 2011). Todos os
dispositivos Android são baseados na rede 3G, mais rápida que as
tradicionais redes 2G utilizadas anteriormente. Contudo, os utilizadores
ambicionam sempre mais, existindo já alguns dispositivos capazes de
suportar redes de quarta geração (4G).

Visualização de páginas web: Utilizadores de dispositivos móveis
pretendem visualizar as páginas web reais e não versões simplificadas para
dispositivos móveis. O Android fornece um browser completo capaz de
renderizar as páginas reais da mesma forma que um computador
tradicional.

Falta de aplicações: Ao ser uma plataforma open source, o Android
permite que os utilizadores possam desenvolver as suas próprias
aplicações, baseadas em Java, e posteriormente instala-las no seu
dispositivo ou disponibiliza-la no Google Play, contribuindo desta forma
para as milhares de aplicações ali disponíveis.
43
A Figura 14 apresenta os SO móveis mais utilizados entre Setembro de 2012 e
Setembro de 2013, onde o Android se mostra em crescimento, ao contrário do
SymbianOS, que tem uma queda bastante acentuada. Já o iOS da Apple mantém-se
estabilizado.
FIGURA 15: TOP 8 DE SISTEMAS OPERATIVOS MÓVEIS UTILIZADOS ENTRE SETEMBRO DE 2012 E
SETEMBRO DE 2013. FIGURA OBTIDA DE (STATS, 2013).
2.3.2- Arquitetura
O Android consiste na utilização de um SO baseado em Linux, bibliotecas da
linguagem Java, uma máquina virtual e algumas aplicações (Chien-Wei, Chun-Yu,
Chung-Ta, Yi-Fan, & Shau-Yin, 2010). A sua arquitetura é dividida em cinco camadas
(Google, 2012b): Applications, Application Framework, Native Libraries, Android
Runtime e Linux Kernel. Estas camadas encontram-se divididas de acordo com a Figura
15.
44
FIGURA 16: ARQUITETURA DO GOOGLE ANDROID (GOOGLE, 2012B).
A camada Linux Kernel permite a abstração entre o hardware e a plataforma
Android; Silva et al incluem aqui uma subcamada, denominada Hardware Abstraction
Layer, que administra e fornece uma interface abstrata entre os drivers de Hardware e a
plataforma Android, como as interfaces 3G, Wi-Fi e gestão de energia (Silva et al.,
2011).
Acima desta camada, encontra-se a camada Android Runtime, o coração da
plataforma. Os ciclos de vida dos processos em execução (e.g. aplicações e serviços) e
recursos (e.g. memória e capacidade de processamento) que lhes correspondem são aqui
geridos. Esta camada consiste em dois componentes: Core Libraries que são Java APIs
para gerir estruturas de dados e acesso à rede e a máquina virtual Dalvik. Esta máquina
virtual foi concebida para dispositivos com memória reduzida e para permitir que várias
instâncias de máquinas virtuais sejam executadas simultaneamente. Comparada com
uma máquina virtual Java padrão, apresenta duas diferenças chave (Chien-Wei et al.,
2010): enquanto a maioria destas máquinas virtuais possuem uma arquitetura stackbased, a do Dalvik é register-based e a máquina Dalvik executa os aplicativos Java que
foram transformados em executáveis Dalvik (no formato .dex). As ferramentas que não
45
foram desenvolvidas em máquinas virtuais Dalvik, não podem ser diretamente
transportadas para ela.
A camada Libraries possui um conjunto de bibliotecas de C e C++ que são
utilizadas por diversos componentes do sistema Android. Nestas bibliotecas incluem-se,
por exemplo, bibliotecas multimédia, que permitem a reprodução dos formatos de
áudio, vídeo e estáticos mais populares.
A camada seguinte, Application Framework, consiste em vários serviços que
permitem a gestão dos recursos do sistema, como o gestor de atividades ou uma simples
janela. Por ser uma plataforma de desenvolvimento aberta, o Android permite que os
desenvolvedores aproveitem todas as suas funcionalidades.
Finalmente, no topo da arquitetura, as aplicações que estão visíveis para os
utilizadores são exeutadas na máquina virtual Dalvik e recorrem à application
framework para gerir os seus recursos. É a camada com que um utilizador tem contacto
quando utiliza um dispositivo Android.
2.3.3- Desenvolvimento em Android
Atualmente smartphones, como o Google Android e o iPhone da Apple, têm
capacidade de armazenamento de dados (e.g. 8Gb ou 32Gb), suportam ligações
avançadas a redes Wi-Fi e 3G/4G e possuem ainda uma série de propriedades
interessantes, como teclado/teclado virtual, bússola digital, recetor de GPS e
acelerómetro (Weng, Sun, & Grigsby, 2012). Contudo, possuem ainda algumas
limitações, principalmente ao nível da bateria. Cada aplicação, cada atualização na
memória ou mesmo cada pixel do ecrã, utilizam recursos e consequentemente afetam a
autonomia do dispositivo.
Todas estas funcionalidades e o poder da própria plataforma Android, aliadas aos
milhões de dispositivos atualmente ativos, transformaram o Android numa das
principais tendências da atualidade, iniciando assim uma revolução móvel (Lyons,
2010).
Desenvolver para estes dispositivos requer alguns conhecimentos de OOP
(Object-oriented programming), mais propriamente na linguagem Java. O Google
disponibiliza o Android SDK, que contém as bibliotecas e ferramentas necessárias para
46
construir, testar e depurar aplicações para o Android. Este SDK pode ser incluído em
vários ambientes de desenvolvimento, sendo o Eclipse IDE o mais utilizado, possuindo
um plug-in especial que facilita na programação em Android: o Android Developer Tool
(ADT). Por fim e não menos importante, é também necessário o Java Development Kit
(JDK) para construir aplicações baseadas em Java.
Com estas ferramentas, as aplicações são desenvolvidas num computador, onde os
recursos são abundantes e podem testadas num emulador ou em dispositivos reais, até
chegarem á sua versão final, que posteriormente poderá chegar ao Google Play.
Desde que surgiu o primeiro dispositivo móvel foram vários os SO criados.
Contudo, até há bem pouco tempo, nenhum se conseguia assumir como perfeito. O iOS
da Apple e o Android da Google vieram assumir o comando deste sector, devido às suas
poderosas funcionalidades e capacidades. Dentro deste confronto, o Android tem vindo
a ganhar vantagem (Stats, 2013), beneficiando de ser um SO opensource.
2.4- Computação Física
2.4.1- Introdução à computação física
Com o aparecimento e evolução dos sistemas informáticos surgiram novos
instrumentos que visam aumentar a experiência do utilizador, da forma mais cómoda e
prática possível. Atualmente é possível integrar a rotina do ser humano com o recurso a
sistemas computadorizados. O’Sullivan e Igoe definem computação física como a
interação entre o mundo físico e o mundo do computador (O'Sullivan & Igoe, 2004).
Esta interação tenta ser o mais invisível possível, criando um ambiente pervasivo. A
ideia de computação pervasiva é transformar um ambiente num ambiente autónomo,
capaz de obter informações do meio à sua volta e utilizá-las para controlar, configurar e
ajustar a aplicação, de forma completamente invisível e impercetível para o utilizador
(Araujo, 2003). Um exemplo é o conceito da casa inteligente que, através de
dispositivos sensoriais, toma conta da casa sem necessitar da atenção do proprietário,
ligando as luzes automaticamente quando se apercebe da presença do utilizador numa
47
determinada divisão da casa, encomendar os produtos em falta no frigorífico ou
simplesmente gerir a temperatura da habitação. Tudo isto captando o mínimo de atenção
possível ao utilizador. Um outro sistema pervasivo integra sensores no vestuário que,
entre outras funcionalidades, monitorizam os sinais vitais e são capazes de se adaptarem
à temperatura do corpo da pessoa. É comum ver este tipo de equipamentos em desportos
de alta competição, onde é importante os jogadores terem uma monitorização constante.
2.4.2- Dispositivos de aquisição de dados sensoriais
Existem muitas ferramentas para a criação de protótipos com elementos
eletrónicos, com uma panóplia de hipóteses, desde a conceção de novos instrumentos
musicais para salas inteligentes, dispositivos de entrada personalizados e obras de arte
interativas. Contudo, a maioria dos produtos são comerciais, ou seja, caros e de código
fechado, ou então fazem parte de projetos de pesquisa inacessíveis para a maioria das
pessoas (Mellis, Banzi, Cuartielles, & Igoe, 2007). Atualmente existem já ferramentas e
protótipos que permitem, com custos reduzidos, enfrentar estas barreiras.
Uma das formas de interagir entre o mundo físico e o mundo do computador é a
utilização de dispositivos de aquisição de dados sensoriais, SBC, como o Arduíno ou o
Raspberry Pi. Além de muitas outras funcionalidades, estes SBC são capazes de sentir o
ambiente através de sensores e comunicar as informações recolhidas utilizando ligações
sem fios (Barroca et al., 2013). Um exemplo de dados sensoriais que estes dispositivos
podem captar são a temperatura, humidade, iluminação e índices ultravioleta.
O Raspberry Pi, apresentado na Figura 16, é um SBC, do tamanho de um cartão
de crédito, com um custo aproximado de 30 euros, capaz de efetuar grande parte das
tarefas de um computador de secretária, incluindo a reprodução de vídeos Full HD
(1080p).
48
FIGURA 17: MODELO B DO RASPBERRY PI.
Este computador foi construído para colmatar uma falha nos conhecimentos
informáticos dos candidatos aos cursos de informática do St. John’s College, na
Universidade de Cambrigde (Tróia, 2013). Desta forma, ao disponibilizarem um
equipamento barato que requeresse o mínimo de periféricos para funcionar e pudesse
ser ligado através de uma ligação HDMI a um televisor moderno ou através da saída
RCA, de vídeo composto, a uma televisão mais antiga, facilitaram o primeiro contacto
das crianças com a informática. Deste modo e à semelhança dos computadores dos anos
80, as crianças são obrigadas a descobrir a linha de comandos, e acreditam que melhores
candidatos surgirão e, desta forma, irão aumentar o número e qualidade de profissionais
que saem dos seus cursos (Gaylord, 2011; Tróia, 2013) .
Existem dois modelos deste dispositivo: A e B. Apesar do modelo A ser menos
potente, diferem em poucos aspetos: enquanto o modelo A tem 256MB de RAM e 1
porta USB, o modelo B tem 512MB, 2 portas USB e uma porta ethernet. No resto dos
componentes
os
dois
modelos
são
iguais:
processador
Broadcom
ARM
(Advanced RISC Machine) 11 700MHz e GPU (Graphics Processing Unit) Videocore
4. O GPU do Raspberry Pi proporciona uma tecnologia OpenGL ES 2.0, hardware
acelerado OpenVG e permite imagens de alta resolução 1080p30 H.264 (Limited, 2013).
O armazenamento é feito através de um cartão de memória SD e, apesar de ser possível
ligar discos rígidos, o arranque é obrigatoriamente feito a partir do cartão SD. O
49
dispositivo é alimentado por uma interface MicroUSB de 5V, a atual ligação de energia
padrão para telemóveis na União Europeia (Tróia, 2013). Por possuir um processador
ARM, o Raspberry Pi suporta grande parte das distribuições Linux. A Figura 17
representa a arquitetura, enquanto a Figura 17 apresenta uma visão geral dos
componentes que o compõem.
FIGURA 18: VISÃO GERAL DOS COMPONENTES QUE COMPÕEM O RASPBERRY PI. FIGURA ADAPTADA DE
(PI, 2011).
.
Jon Gold afirma que o Raspberry Pi parece destinado a ter um impacto muito
além do setor educacional, após uma das primeiras séries produzidas no Reino Unido
ter esgotado depois de apenas um dia no mercado, atingindo as 700 encomendas por
segundo (Gold, 2012).
O Raspberry Pi dispõe já de uma grande comunidade de fãs e programadores,
tendo sido muito recentemente criada a Pi Store, uma loja de aplicações para esse
dispositivo, surgindo cada vez mais projetos de carácter interessante.
O BeetBox (Garner, 2012) é um instrumento simples que permite aos utilizadores
ativar o som de um tambor quando toca em beterrabas reais. Apesar de parecer bizarro,
utiliza um sensor de toque capacitivo e um amplificador áudio, criando uma interação
complexa com a tecnologia completamente oculta.
David Hayward ensina a criar um servidor FTP (File Transfer Protocol)
suportado pelo Raspberry Pi e painéis solares (Hayward, 2012). Este projeto tem
alguma complexidade, sendo necessário configurar o dispositivo para que este tenha um
IP estático, instalar um servidor VNC (Virtual Network Computing) para que lhe possa
aceder remotamente e posteriormente colocá-lo num local onde a iluminação seja
50
abundante e ligá-lo à rede através da entrada ethernet. Desta forma, onde quer que
esteja, o utilizador pode aceder remotamente a um disco rígido formatado em NTFS
(New Technology File System) ligado ao Raspberry Pi.
Akerman utilizou o Raspberry Pi, monitorizado através de GPS, como
controlador de um sensor num balão atmosférico e enviou-o para a estratosfera,
capturando imagens do planeta até cerca de 40 mil metros de altitude através de uma
webcam ligada ao dispositivo (Akerman, 2013). Esta experiência teve um custo
aproximado de cerca de 350 euros.
Além destes, existem bastantes outros projetos interessantes, desde construir um
supercomputador ligando vários Raspberry Pi (Southampton, 2012), comunicar através
de telnet com a máquina de café e ordenar-lhe que comece a fazê-lo (Johnsen, 2012),
uma Multiple Arcade Machine Emulator (MAME) (Clive, 2011) ou até mesmo uns
óculos que, através de apresentação de legendas, permitem a tradução instantânea de
uma conversa entre indivíduos que comunicam em idiomas diferentes (Hide, 2012).
É importante frisar que, por ser uma tecnologia recente, o Raspberry Pi ainda tem
bastantes recursos para serem explorados. Além disso, muitos dos projetos que o
utilizam, ainda se encontram em fase inicial.
O Arduíno é uma plataforma para desenvolvimento de protótipos interativos com
componentes eletrónicos (Mellis et al., 2007), baseado na família de microcontroladores
Atmel ATMega (Al-Kuwari, Ortega-Sanchez, Sharif, & Potdar, 2011). O hardware é
uma placa de circuitos eletrónicos, com vários modelos disponíveis, sendo que o mais
barato ronda os 15€, fornecendo uma plataforma completa, flexível e fácil para ser
utilizada por artistas, designers e amadores (Sarik & Kymissis, 2010).
Foi criado na Interaction Design Institute em Ivrea, uma pequena escola no norte
de Itália, onde o ensino era focado em interfaces para ecrã, objetos físicos e serviços.
Esta escola incentivou os alunos a criarem protótipos rápidos das suas ideias e testá-las
repetidamente e aperfeiçoá-los, nascendo assim o Arduíno, resultado da combinação
entre vários protótipos.
O Arduíno é uma placa de circuitos que contém um microcontrolador de baixa
potência e os componentes necessários para lhe fornecer uma fonte de alimentação
estável que permite ligá-lo ao computador (Mellis et al., 2007) e a outros componentes,
51
podendo controlá-los (Kim & Lee, 2011). Tem a capacidade de suportar diversos tipos
de entradas, através de sensores e interagir com motores, luzes e outros tipos de objetos
(Al-Kuwari et al., 2011). A interação com objetos físicos, por meio de sensores ligados
a microcontroladores é denominada computação física (O'Sullivan & Igoe, 2004) sendo
o Arduíno uma plataforma fiável para o desenvolvimento nesta área (Kato, 2010).
Existem diversos modelos mas, segundo Al-Kuwari et al, os mais utilizados são
os Mega, Duemilanove, Nano e Mini (Al-Kuwari et al., 2011). O modelo Mega (Figura
18) é constituído por uma placa baseada na Atmega1280, de 8 bits, e possui 54 pins de
input/output
digitais,
16
inputs
analógicos,
4
Universal
Asynchronous
Receiver/Transmitter (UARTs), um oscilador de cristal de 16MHz, uma porta USB e
uma fonte de alimentação de 5V (Arduino, 2012a). Os restantes modelos utilizam a
placa ATMega168 ou ATMega328 e variam na quantidade de inputs/outputs digitais e
inputs analógicos (Arduino, 2012b). Todas as versões de placas do Arduíno são
desenhadas para trabalhar com os componentes eletrónicos padrão, proporcionando uma
plataforma base que não limita os utilizadores aos sensores pré-instalados (Mellis et al.,
2007).
FIGURA 19: ARDUINO MEGA. IMAGEM ADAPTADA DE (ARDUINO, 2012A).
O software do Arduíno é constituído por 2 partes, ambas open source: ambiente
de desenvolvimento multiplataforma (Windows, MAC OS X e Linux), escrito em Java,
onde o utilizador não é obrigado a trabalhar com a linha de comandos e as bibliotecas,
que consistem em funções de C/C++.
O Arduíno, à semelhança do Raspberry Pi, possui também incontáveis projetos de
grande interesse, beneficiando do facto de existir há mais tempo. Há exemplos, desde
abrir portões de garagens, comandar interruptores elétricos, sensores de chuva, um cubo
52
luminoso que acende quando a conta do gmail recebe um novo email (Matthews, 2008),
passando pela interação com o software de animação 3D Maya (Thompson, 2008) ou
até mesmo um carro de controlo remoto a funcionar através da Internet (Bennett, 2008).
Um projeto interessante consistiu no desenvolvimento de um braço robótico,
controlado através da Internet e que pretendia mostrar que um robot pode ser usado em
casa para as tarefas diárias (Kadir, Samin, & Ibrahim, 2012). Este robot possui um
Arduino Uno incorporado e a comunicação com a rede é feita através do Arduino
Ethernet Shield. Os criadores afirmam que a Internet está presente em todo o lado, na
ponta dos dedos, fazendo sentido a introdução de um robot nas lides domésticas. O
braço robótico é controlado pelo utilizador, através da página web construída em
HTML, que introduz o grau de movimento do braço robótico e, de seguida, o
movimento é executado, sendo possível efetuar movimentos pré-configurados.
Por fim, é importante frisar que ambos os SBC analisados permitem que lhes
sejam adicionados diversos tipos de sensores, possibilitando a recolha de dados de
contexto geográfico.
2.4.3- Grandezas a medir na modelação de ambientes virtuais
Os avanços tecnológicos das últimas décadas tornaram possível criar uma
plataforma de deteção móvel capaz de capturar grandes quantidades de dados para lidar
com problemas sociais, de forma discreta e rentável (Weinschrott, Du, x, rr, &
Rothermel, 2010). Estes sistemas de deteção têm o objetivo de medir e controlar fatores
de interesse de um país, cidade, comunidade ou até mesmo mundial, como por exemplo,
determinar os índices de poluição, medir os níveis de radioatividade, analisar o tráfego
em tempo real, ruído, humidade e temperatura (Mendez et al., 2013). A monitorização
de um sistema físico facilita identificar e eliminar obstáculos em ambientes de
computação virtual, além de permitir adaptar esses ambientes automaticamente para
uma utilização mais eficiente dos recursos a ele agregados (Feng, Vishwanath, Leigh, &
Leigh, 2008).
Rawi e Al-Anbuki defendem que existe uma forte ligação entre o conforto
ambiente e a produtividade humana (Rawi & Al-Anbuky, 2011). Se o ser humano não
se sentir confortável, irá ter uma quebra de produtividade. Segundo os autores, o
conforto humano é complicado de medir, pelo que é estabelecido através de fatores
53
como a temperatura, humidade, iluminação e qualidade do ar e está dividido em
conforto térmico, conforto visual, qualidade do ar interior e conforto acústico
(Frontczak, Andersen, & Wargocki, 2012; Rawi & Al-Anbuky, 2011). No trabalho
realizado por Frontczak et al, que recebeu 645 respostas, concluiu-se que, quando
questionados sobre os fatores de conforto doméstico, os questionados dão valor à
qualidade do ar, temperatura, acústica e iluminação (Frontczak et al., 2012).
No Departamento do Trabalho da Nova Zelândia outro estudo foi realizado para
determinar quando uma pessoa se sente confortável (Labour, 2007). Os autores
entendem a temperatura do ar como um fator muito importante para o conforto térmico.
A humidade também o é, contudo está diretamente relacionada com a temperatura,
sendo que ambientes muito quentes e com pouca humidade apenas trazem problemas,
pelo que um ambiente não muito seco e temperatura agradável é o ideal. O calor
radiante pode ser um fator ambiental ou ocupacional e refere-se ao calor emitido por um
objeto quente. O calor radiante é considerado ambiental quando a fonte radiante é o sol
e ocupacional quando é emitido por objetos, como aquecedores ou ar condicionado. As
condições ideias são resumidas na Tabela 1.
TABELA 1: CONDIÇÕES IDEAIS PARA O CONFORTO DO HOMEM. ADAPTADO DE (LABOUR, 2007).
Condição
Temperatura do ar
Verão
19 a 24º
Inverno
18-22
16 a 21 se em trabalho 16-19 se em trabalho ativo
ativo
Humidade relativa do ar
40 a 70%
Velocidade do ar
0,1 a 0,2 m/s, sem corrente de ar
Até 0,5 m/s se em trabalho ativo
Calor radiante
Nenhuma exposição direta a fonte de calor radiante
Como exemplo de aplicação, um grupo de investigadores (Alahmad, Nader, Cho,
Shi, & Neal, 2011) desenvolveu um protótipo que permite controlar o consumo de
energia numa habitação. Com a implementação deste projeto, os utilizadores passam a
saber onde reduzir esse consumo, já que segundo eles, 41% da energia gerada é
desperdiçada, sendo que cerca de 32% dessa parte é gasta no aquecimento de quartos
desocupados (Williams & Matthews, 2007). Por este e outros fatores, o conhecimento
54
acerca da posição geográfica dos utilizadores é muito importante aquando da atuação
sobre sistemas físicos e como elemento essencial às ferramentas de suporte à decisão.
2.4.4- Técnicas de localização indoor e deteção de presença
Sensores de posição e movimento facilitam a forma como se integra a posição do
corpo e movimento numa ampla gama de exercícios, desde fazer aparecer fantasmas em
casas assombradas, acender luzes quando o ambiente “sente” a pessoa e até mesmo
analisar o trajeto de alguém numa sala de exposição de um museu. Em ambientes
outdoor a localização de objetos ou pessoas pode ser efetuada utilizando diversas
técnicas e estratégias, como por exemplo os satélites GPS. Indoor, estas técnicas falham
ou não são tão precisas, pois não foram desenvolvidas para serem aplicadas a espaços
fechados (Ahmed & Hegazy, 2008; Gonzalez & Bleakley, 2007; O'Sullivan & Igoe,
2004; Sanchez, de Castro, Elvira, Glez-de-Rivera, & Garrido, 2012; Tesoriero, Tebar,
Gallud, Lozano, & Penichet, 2010; Varshavsky, de Lara, Hightower, LaMarca, &
Otsason, 2007). Nos últimos tempos, a necessidade de localização indoor aumentou
(Deak, Curran, & Condell, 2012), levando ao aumento do interesse no desenvolvimento
de técnicas para este efeito, principalmente por serem fáceis de implementar e de baixo
custo, principalmente se optarmos pelas infraestruturas de comunicação (e.g. Wi-Fi,
Bluetooth) (Mahtab Hossain, Nguyen Van, & Soh, 2010).
Para analisar o movimento de corpos em relação ao ambiente, deve-se ter em
atenção cinco parâmetros (O'Sullivan & Igoe, 2004): a posição do corpo no ambiente, a
orientação, a velocidade do movimento, a posição absoluta ou relativa, ou seja, saber se
a posição é a exata ou se apenas foi alterada em relação à posição anterior, Identidade
do objeto, para ser possível distinguir-se dos outros objetos; Quando se refere à posição
e orientação, tem de se considerar os Degrees of Freedom (DOF). Para a posição
existem três DOF: esquerda para direita (eixo X), cima e baixo (eixo Y) e frente para
trás (eixo Z). Existem outros três DOF para a orientação e rotação: rotação sobre o eixo
X, rotação sobre o eixo Y e rotação sobre o eixo Z.
Há diversas formas de sentir a presença de uma pessoa num determinado espaço,
sendo a gama de sensibilidade o critério mais importante para a escolha de um sensor. A
maioria dos sensores calcula a distância em relação ao alvo emitindo energia sobre a
55
forma de luz, magnetismo ou som (O'Sullivan & Igoe, 2004). Os métodos menos
eficazes de localização indoor pretendem apenas sentir quando a pessoa se aproxima,
sendo normalmente utilizados, por exemplo, para acender as luzes em casas de banho e
as manter acesas durante a presença da pessoa, apagando-as quando deixar de a sentir.
Já os mais sofisticados fazem por sentir a posição exata da pessoa em cada instante,
sendo normalmente utilizado em projetos que requerem elevada fiabilidade.
Existem algumas técnicas para detetar a presença de uma pessoa ou objeto em
espaços interiores. Estas técnicas pretendem despoletar uma ação aquando a
aproximação do alvo. O’Sullivan e Igoe analisam quatro destas técnicas (O'Sullivan &
Igoe, 2004): Foot Switches, interruptores fotoelétricos, detetores de movimento e
interruptores magnéticos.
Os Foot Switches são a técnica mais simples para detetar a presença de um
utilizador, especialmente numa área pequena. Estes equipamentos, feitos em longas tiras
de fita de metal separados por intervalos de tiras de espuma, sentem quando alguém
caminha sobre eles, comprimindo as tiras de espuma e fazendo com que as tiras de
metais toquem. Contudo, têm de ser suficientemente robustos para aguentar o peso de
quem caminha sobre eles.
Os interruptores fotoelétricos emitem feixes luminosos para atingir um sensor
alvo. Quando algo se intromete entre o sensor e a fonte de luz, quebrando essa ligação,
o interruptor é ativado. Um exemplo são as portas automáticas que, ao aproximar do
utilizador, abrem-se automaticamente.
O funcionamento dos detetores de movimento é bastante idêntico ao dos
interruptores fotoelétricos. Estes sensores apenas reagem a alterações na luz
infravermelha do espaço, não indicando posição nem orientação da pessoa. Quando
comparado aos interruptores fotoelétricos têm algumas vantagens: mais fácil instalação;
área mais ampla de cobertura, sensibilidade pode ser ajustada alterando a lente.
Normalmente são utilizados pelos alarmes de segurança.
Por fim, os interruptores magnéticos são pares de dispositivos formados por um
íman e um interruptor, que é constituído por pares de lâminas que podem ser acionadas
através de um campo magnético. Na ausência deste campo magnético, as lâminas
permanecem afastadas uma da outra. Ao entrarem em contacto com um campo
56
magnético, o circuito é fechado, dando origem a uma ação (Braga, 2007). A figura 19
mostra os três últimos sensores abordados.
FIGURA 20: INTERRUPTORES FOTOELÉTRICOS (À ESQUERDA), DETETOR DE MOVIMENTO (CENTRO) E
INTERRUPTOR MAGNÉTICO (À ESQUERDA). FIGURA ADAPTADA DE (O'SULLIVAN & IGOE, 2004).
Os sensores até agora analisados apenas permitem sentir a presença de uma
pessoa num determinado sítio, são úteis para fins mais simplistas. Contudo, há casos em
que necessitamos de saber, com elevada precisão, a posição que o utilizador possui
nesse exato momento, analisar a sua deslocação e até mesmo espoletar ações tendo em
conta esse movimento. Para isso precisamos de sensores com maior sensibilidade e
precisão, como a identificação por radiofrequência (RFID) e os ultrassons.
Um grupo de investigadores afirma que “o objetivo da Radio Frequency
identifycation (RFID) é guardar e disponibilizar informação através de transmissão
eletromagnética para um dispositivo de leitura” (Ni, Yunhao, Yiu Cho, & Patil, 2003).
Deak et al explicam-nos o uso de RFID para detetar a posição, sendo esta baseada na
comunicação entre os leitores e as tags RFID (Deak et al., 2012). Estas tags podem ser
classificadas em passivas, se não possuírem energia própria, ou ativas, se possuírem
(Esteves, 2005). As tags passivas têm um alcance de aproximadamente 1 a 2 metros,
mas em contrapartida os leitores compatíveis são caros. Já as ativas têm um alcance
muito maior, chegando às dezenas de metros, sendo indicadas para ambientes maiores.
Esta técnica pode ser transformada numa tecnologia de localização, recorrendo à força
do sinal entre o leitor e o recetor de RFID (Ni et al., 2003) e é considerada a tecnologia
de localização mais adequada para a localização indoor (Razavi & Moselhi, 2012).
Possui algumas vantagens, entre as quais a capacidade de trabalhar sobre duras
condições ambientais, o rápido tempo de resposta, eficácia, tempo de vida e a baixa
necessidade de manutenção (Tesoriero et al., 2010). Quanto em relação aos ultrassons,
57
não têm problemas com o barulho. Acredita-se que a próxima geração de RFID pode ser
considerada um sistema hibrido, ou seja, irá trabalhar em conjunto com dispositivos
móveis de forma a estimar a localização com maior precisão (Deak et al., 2012).
Utilizando ultrassons podemos estimar a distância entre o transmissor e o recetor,
medindo o tempo de voo dos ultrassons e tendo em conta a velocidade do som (Sanchez
et al., 2012), ou seja, o transmissor emite um ultrassom e o cálculo é feito com base do
tempo que demora a regressar (O'Sullivan & Igoe, 2004), sendo que quanto mais
demorar, mais longe está o recetor. Alberto Sanchez, anteriormente referido, diz que
existem duas estratégias principais para calcular a posição: triangulação e trilateração.
Enquanto a triangulação calcula os ângulos entre o transmissor e o recetor, a trilateração
calcula a distância entre ambos. Trilateração possui a vantagem de ser de execução mais
rápida que a triangulação e produzir os resultados com precisão aceitável (Melo, Souza,
& Silva, 2012).
A trilateração requer hardware mais complexo, como antenas unidirecionais e o
cálculo matemático é também mais difícil. Sanchez et al explicam o processo da
trilateração, que mede as distâncias entre alguns pontos fixos e o alvo (Sanchez et al.,
2012). Este método requer, regra geral, quatro pontos fixos cujas distâncias em relação
ao alvo são calculadas. Contudo, três pontos são suficientes para se obter a posição,
como mostra a Figura 20. Cada distância define uma esfera (s1), onde o centro é a
posição do ponto de ancoragem e a distância é o raio. O objeto está num ponto desta
esfera, não sendo possível obter a sua posição apenas com uma medição. Utilizando-se
uma nova medição (s2), as duas esferas (s1, s2) intersectam-se. Por fim, a terceira
medição (s3) intersecta-as em 2 pontos (P1, P2), sendo estes os possíveis resultados de
uma triangulação. P1 e P2 têm os mesmos valores nos eixos X e Y, mas variam no sinal
no eixo Z. Supondo que os pontos de ancoragem estão colocados no teto, um desses
pontos (p1) encontra-se acima dele, sendo descartado pois os ultrassons não ultrapassam
paredes. Desta forma, P2 é o resultado que pretendíamos, correspondendo assim ao
ponto do objeto recetor. Com uma quarta medição poder-se-ia resolver este problema do
eixo Z.
58
FIGURA 21: TRILATERAÇÃO UTILIZANDO TRÊS PONTOS DE ANCORAGEM (SANCHEZ ET AL., 2012).
A maioria dos sistemas de localização que recorrem ao tempo de voo para calcular
a distância são baratos e eficientes, sendo grande parte desta eficácia devido à lenta
propagação do ultrassom no ar, que é de aproximadamente 343 m/s em ambientes de
sensivelmente 20º celsius (Schweinzer & Kaniak, 2010).
Os primeiros projetos englobando ultrassons foram estudados nos sistemas Bats
(Harter, Hopper, Steggles, Ward, & Webster, 1999) e Cricket (Priyantha, Chakraborty,
& Balakrishnan, 2000).
O sistema Bats consiste num emissor e recetor, num controlador lógico e num
transdutor ultrassónico, com 5x3x2 cm de medida, peso de 35g, e cada Bat possui um
identificador único. O funcionamento é simples: a estação base emite periodicamente
uma mensagem rádio que contém um identificador único, provocando reação no Bat
correspondente que emite um ultrassom. Simultaneamente, os recetores de ultrassons
que se encontram alcançáveis reiniciam os valores e monitorizam o ultrassom emitido,
calculando o tempo de chegada de algum sinal do Bat. Utilizando a velocidade do som
no ar, possível de obter através da temperatura ambiente, o tempo de voo do ultrassom
para os recetores é calculado e convertido.
O sistema Cricket foi desenvolvido para custar menos de 10 US dólares
(aproximadamente 7,5€ à data de hoje) e combina o uso de radiofrequências (RF) e
ultrassons para fornecer um serviço de suporte à localização para utilizadores e
aplicações. Este sistema utiliza balizas de transmissão e um dispositivo recetor móvel.
59
À semelhança do Bats, as balizas emitem ultrassons sincronizados com RF, calculando
o tempo de voo.
Estes sistemas foram concebidos para terem uma precisão o mais apurada
possível, podendo ser de 10 cm e orientação de 3 graus num ambiente com baixo ruído
(Gonzalez & Bleakley, 2007). Contudo, segundo o autor por último referenciado, a
precisão é rapidamente afetada pelo ruído.
Atualmente as aplicações de dispositivos ultrassónicos são imensas. Por exemplo,
um projeto junta Arduíno e ultrassons para construir um sistema de auxílio ao
estacionamento do automóvel (Satorius, 2012). Este sistema utiliza dois emissores de
ultrassom que deteta a distância em relação ao automóvel e comunica com um semáforo
que, com o aproximar do automóvel, muda de verde para amarelo e posteriormente para
vermelho. Este sistema pode ser executado em dois lugares de estacionamento.
Os ultrassons têm três vantagens sobre os dispositivos de radiofrequência
(Gonzalez & Bleakley, 2007). Em primeiro lugar, a menor velocidade de propagação
dos sistemas de ultrassom facilita a recolha de dados mais precisos. Em segundo lugar,
os sinais ultrassonoros não atravessam paredes, não interferindo assim com outros
sistemas. Por fim, os sistemas RF são proibidos ou inúteis em determinadas situações,
como hospitais, navios e submarinos. Concluindo, os ultrassons funcionam com alta
precisão em curtas distâncias, calculando a posição relativa entre a fonte e o recetor. Já
RFID tem menor precisão mas mais alcance, permitindo que várias tags sejam detetadas
a partir do mesmo leitor (O'Sullivan & Igoe, 2004).
Nas últimas décadas tem-se presenciado uma grande evolução das chamadas
novas tecnologias. A informática passou a fazer parte integrante de praticamente todas
as tarefas do quotidiano. Contudo, é necessário olhar para o computador de outra forma.
O’Sullivan e Igoe acreditam que se deve utilizar o computador para interagir com as
rotinas (O'Sullivan & Igoe, 2004). Chris Crawford define interação como um processo
iterativo de ouvir, pensar e falar entre dois ou mais atores (Crawford, 2002). Usar os
SBC para interagir entre o mundo físico e o mundo virtual permite ganhar um maior
controlo sobre os objetos, desde abrir uma porta ou ligar um carro, até tarefas mais
complexas, como monitorizar ambientes e fazer repercutir alterações em físicas de um
60
contexto geográfico, num modelo virtual. A isto pode-se ainda juntar sensores de
deteção de localização indoor e de deteção de presença, que possibilitam saber a
posição exata de um utilizador dentro de um espaço físico.
2.5- Aplicações para o caso de estudo: as imobiliárias
Num tempo em que a Internet é cada vez mais um centro de oportunidades de
negócio, surgem diariamente aplicações capazes de facilitar o dia-a-dia da sociedade,
desde organizar o dia de trabalho, até informar acerca de horários dos transportes
públicos ou simplesmente aplicações para entreter e divertir o utilizador.
2.5.1- Aplicações web para imobiliárias
Existe um vasto leque de aplicações web para comércio de imóveis. Em Portugal
destacam-se o Imovirtual (FixeAds - Serviços de Internet, 2012) e o Casa Sapo (Janela
Digital, Telecom, & Sapo, 2012). Como a maioria das aplicações deste género, estas
permitem que o utilizador pesquise através de vários tipos de características, selecionem
regiões e visualizem diversas informações úteis em cada anúncio. O Imovirtual permite,
em casas que se encontrem em regiões suportadas, a integração do mapa StreetView, da
Google. O Casa Sapo permite que sejam adicionadas plantas do imóvel e fotografias
360º, sendo necessária a instalação do plug-in Adobe Shockwave Player para a sua
visualização. Também possui uma aplicação para dispositivos móveis, Android e iOS,
que é uma versão otimizada da aplicação web para dispositivos móveis, apresentando
também um mapa com marcação geográfica dos anúncios. Ambos possuem vários
dados estatísticos para a região selecionada, como preço por m2, evolução de preços e
informações demográficas.
2.5.2- Aplicações de RA para dispositivos móveis
Há também algumas aplicações de realidade aumenta para dispositivos móveis,
principalmente para os SO Android e iOS. Contudo, no contexto imobiliário são muito
61
poucas aquelas que se diferenciam das tradicionais aplicações web. As aplicações para
dispositivos móveis, como referido em relação à aplicação do Casa Sapo, são
normalmente uma otimização da aplicação web, com uma interface mais limpa e menos
detalhada. Uma aplicação que contraria esta tendência não está disponível para
Portugal: HomeSpotter, da Mobile Realty Apps (Apps, 2012). Esta aplicação aproveita
os tradicionais conceitos e junta-lhe o de RA: ambiente que envolve tanto realidade
virtual como elementos do mundo real, criando uma mistura dos dois em tempo real.
Esta aplicação, atualmente disponível para iOS, utiliza o recetor GPS e bússola do
dispositivo e, através da webcam, captura o ambiente onde o utilizador se encontra,
analisa-o e sobrepõe a informação sobre as casas que se encontram para venda ou
aluguer. Possui também um radar que mostra a direção e proximidade a essas mesmas
casas. Esta empresa tem também uma aplicação baseada em QR-Code para imobiliárias,
que após analisados redirecionam para a aplicação web.
Existem também algumas aplicações que utilizam dados sensoriais para transmitir
informações úteis aos utilizadores, como é o caso do “Praia em Directo” (Vodafone,
2012) e o “BeachCam” (Comunicações, 2013).
A aplicação “Praia em Directo” mostra mais de 170 zonas balneares de toda a
zona costeira de Portugal e permite obter, em tempo real, as seguintes informações
sensoriais de cada uma das praias: temperatura do ar, índice UV, velocidade do vento,
direção do vento, humidade do ar, pressão atmosférica, pluviómetro e qualidade e
temperatura da água. Como é possível visualizar na Figura 21, é também permitido
consultar o histórico do dia, semana e mês.
62
FIGURA 22: APLICAÇÃO VODAFONE PRAIA PERMITE ESCOLHER UMA PRAIA DE PORTUGAL E VISUALIZAR
DADOS SENSORIAIS EM TEMPO REAL OU BASEADO NO HISTÓRICO.
A aplicação “BeachCam” pretende transmitir informações sobre algumas praias,
não só a banhistas mas também a amantes do surf. Menos aprofundada que a “Vodafone
Praia”, a “BeachCam” faz a análise de pouco mais de uma dezena de praias de norte a
sul do país. Ao analisar uma delas, é possível perceber se há condições para a realização
de surf ou praia, assim verificar a temperatura atual, altura das ondas, velocidade e
direção do vento, a hora prevista para o nascer-do-sol e pôr-do-sol. Além disso, é
possível aceder a uma previsão diária da temperatura, altura das ondas e velocidade do
vento, descobrindo qual a melhor hora do dia para praticar surf ou praia. Por fim, indica
a que hora irá haver alterações da maré nessa praia. Como complemento, permite ainda
visualizar em direto a praia através de uma câmara lá instalada. A Figura 22 mostra esta
aplicação.
63
FIGURA 23: ESTIMATIVAS SENSORIAIS PARA A PRAIA DE ESPINHO, NA APLICAÇÃO BEACHCAM.
É importante referir que as aplicações Layar e Wikitude, abordadas anteriormente,
podem também aqui ser enquadradas, no contexto de aplicações de RA para
dispositivos móveis.
Neste capítulo foram estudadas as tecnologias mais relevantes e que poderão ser
utilizadas na conceção do sistema pretendido nesta dissertação. Os conceitos abordados
neste capítulo foram RA, HTML5, Android e Computação física.
64
3- Sistema
sensorial
de
RA
com
contextualização
3.1 – Arquitetura do sistema
O principal objetivo do sistema que se pretende desenvolver nesta dissertação é a
criação de um sistema de realidade aumentada para dispositivos móveis que interaja
com dispositivos sensoriais obtendo, em tempo real, dados através de uma rede
sensorial, possibilitando a sua utilização na aplicação de RA, influenciando e
condicionando a visualizado de um modelo virtual no dispositivo móvel. É constituída
por um componente de aquisição sensorial do contexto, denominado “contextualização
sensorial”, um componente de gestão de dados sensoriais e de um componente de
visualização de modelos virtuais contextualizados, como indicado na Figura 24.
O componente contextualização sensorial representa todo o processo de recolha
de dados sensoriais no espaço físico. Neste componente são utilizados vários SBC (e.g.
Raspberry Pi ou Arduino), sendo que a cada um deles estão acoplados sensores,
responsáveis pela aquisição de dados sensoriais do mundo real. Posteriormente, para os
armazenar, é utilizado o componente de gestão de dados sensoriais, acedido pela
interface web, que tratará do armazenamento. Podem existir vários SBC, em diferentes
locais, aumentando a quantidade de dados existentes no sistema.
O componente seguinte, gestão de dados sensoriais, permite aos restantes
componentes comunicarem com a BD, onde estão armazenados os valores sensoriais.
Após a aquisição dos dados por parte do módulo anterior, os mesmos são enviados para
os webservices deste componente, que fazem o seu tratamento e posterior
armazenamento na BD, utilizando um SGBD. Por outro lado, quando o componente de
visualização de modelos virtuais contextualizados necessitar de ter acesso a algum
desses dados, estes webservices farão uma leitura na BD, devolvendo o valor
pretendido.
Por fim, o componente de visualização de modelos virtuais contextualizados
representa o smartphone ou tablet do utilizador e a aplicação de RA que lá será
executada. Esta aplicação vai ser capaz de aceder aos dados sensoriais, através do
componente gestão de dados sensoriais, sendo possível ao utilizá-los para influenciar ou
65
condicionar a visualização do modelo virtual, cujo rendering é visualizado no
dispositivo móvel.
Em síntese, será feita a aquisição dos dados sensoriais através de vários SBC
(componente de contextualização sensorial), sendo posteriormente armazenados na BD
(componente de gestão de dados sensoriais), utilizando um SGBD. Por fim, a aplicação
de RA irá ser executada no dispositivo móvel e pode aceder a esses dados,
influenciando ou condicionando a forma como o modelo virtual é visualizado
(componente de visualização de modelos virtuais contextualizados).
FIGURA 24: ARQUITETURA DA APLICAÇÃO PARA VISUALIZAÇÃO DE DADOS SENSORIAIS EM APLICAÇÕES DE
REALIDADE AUMENTADA.
3.1.1- Contextualização sensorial
Este bloco funcional tem como função adquirir dados sensoriais no espaço físico.
Isso é possível utilizando, por exemplo, um ou vários SBC, como o Raspberry Pi ou o
Arduino, que permitem a acoplação de um ou vários sensores. Com estes dispositivos,
este sistema pretende ter um conjunto de sensores que façam recolhas sensoriais,
obtendo, por exemplo, dados relativos à temperatura, humidade, iluminação, no espaço
físico. Após estas recolhas, e utilizando os webservices do componente de gestão de
dados sensoriais, será feito o armazenamento na BD. A Figura 25 representa o fluxo
deste componente.
66
FIGURA 25: FLUXO DO COMPONENTE DE CONTEXTUALIZAÇÃO SENSORIAL.
3.1.2- Gestão de dados sensoriais
O componente de gestão de dados sensoriais, composto por um ou vários
webservices, um SGBD e uma BD, é o componente que irá permitir aos diversos
componentes comunicarem entre si. A Figura 26 representa a comunicação dos
componentes de contextualização sensorial e visualização de modelos virtuais
contextualizados com este. O primeiro, utiliza este componente apenas para armazenar
os dados, utilizando estes webservices que, através de um SGBD, efetuam as operações
na BD. Já o segundo componente, ao necessitar de alguma informação da BD, irá obtêla BD, utilizando o mesmo processo explicado anteriormente, e fá-la-á chegar à
aplicação de RA.
FIGURA 26: BLOCO DE OPERAÇÃO DO WEBSERVICE.
67
3.1.3- Visualização de modelos virtuais contextualizados
O componente “visualização de modelos virtuais contextualizados” irá conter
todo o fluxo de dados necessário durante o período em que a aplicação de RA estiver a
ser executada no dispositivo móvel. O fluxo de dados deste componente está
representado na Figura 27.
Quando a aplicação for iniciada, a câmara do dispositivo será automaticamente
ligada, passando ao módulo “Tracking e deteção da marca”. Neste módulo será feita a
análise das frames capturadas pela câmara até que seja detetada uma marca de R.A.
associada à aplicação. Após a deteção da marca e enquanto esta estiver visível, será
feito o tracking da mesma, ou seja, atualizar a sua posição e orientação relativamente às
frames de vídeo capturadas quando ocorrerem alterações.
Após a deteção da marca e recorrendo ao componente de gestão de dados
sensoriais, serão lidos da base de dados os valores sensoriais recolhidos que poderão ser
utilizados para definir algumas propriedades, influenciando ou condicionando a
visualização do modelo virtual associado a essa marca. De seguida, será feito o
Rendering desse modelo virtual com as respetivas propriedades que lhe foram impostas,
surgindo no ecrã do dispositivo móvel a integração do modelo virtual nas frames
capturadas, dando origem ao módulo “Visualização”, onde o utilizador poderá interagir
com os dados sensoriais existentes.
68
FIGURA 27: FLUXO DE DADOS DO BLOCO DE OPERAÇÃO DISPOSITIVO MÓVEL
3.2 – Proposta de layout
Para um melhor funcionamento da aplicação deverão ser adotadas algumas
normas para garantir o perfeito funcionamento do sistema. Desta forma, a interface da
aplicação deverá cumprir alguns requisitos durante a sua construção.
Pretendendo-se uma interação o mais fácil e intuitiva possível, a interface deverá
primar pela simplicidade e eficácia. A interação deverá ser através de botões (toque),
sendo que estes devem ter um tamanho aceitável relativamente às dimensões do ecrã, de
forma a evitar dificuldades para despoletar a ação a eles associados. Além disso, ao
tocar num botão, deve-se garantir que estão suficientemente afastados entre si, de forma
a não tocar em dois simultaneamente e intencionalmente. Por último, o layout deverá
ser responsivo, ou seja, não deverão ser utilizadas medidas absolutas mas sim relativas,
permitindo que o mesmo layout se adapte às diferentes resoluções do ecrã. É importante
referir também que, para maior comodidade, deverá ser utilizada a orientação
Landscape do dispositivo, disponibilizando maior espaço horizontal para apresentar
todas estas informações.
A interface foi pensada de forma a permitir diversas áreas de interação e
apresentação de informação, como mostra a Figura 28:
69
FIGURA 28: DIVISÃO DA INTERFACE DA APLICAÇÃO.
A interface proposta está dividida em quatro áreas distintas. A primeira área, na
parte central e com um maior tamanho, destina-se à apresentação do conteúdo de RA,
bem como todas as suas alterações. As restantes áreas são hipótese para a colocação dos
botões e de possíveis informações sensoriais que possam ser importantes para o
utilizador. Por isso, as áreas assinaladas com o número 2 e 4 seriam hipótese para a
colocação dos botões, enquanto a área 3 será uma boa zona para exibir as informações
sensoriais. Desta forma, mantém-se uma interface leve, simples e elegante, não
intrusivas entre si. Por fim, achou-se que a parte inferior não tem tanto destaque como a
parte superior, pelo que é preferível fazer parte da área de visualização do conteúdo
realidade aumentada. Contudo, a parte inferior poderá no futuro ser utilizada para
apresentação de publicidade.
70
3.3 – Protótipo
No âmbito desta dissertação e utilizando os blocos funcionais descritos
anteriormente, procedeu-se à construção de um protótipo da aplicação, aplicada ao
contexto
imobiliário.
O
componente
de
visualização
de
modelos
virtuais
contextualizados será construído utilizando como tecnologias a extensão da framework
Vuforia para o GameEngine Unity3D, resultando numa aplicação para dispositivos com
o sistema operativo Android. O bloco de contextualização sensorial, por motivos
explicados à frente, apenas irá simular medições sensoriais através de um SBC, o
Raspberry Pi, de dois parâmetros sensoriais: intensidade de iluminação e temperatura.
Por fim, o componente de gestão de dados sensoriais irá ser construído em HTML, PHP,
AJAX e JavaScript e o SGBD será MySQL, estando estes num servidor Apache.
As recolhas de valores sensoriais serão simuladas através de uma interface gráfica
no Raspberry Pi. Esta decisão foi tomada pelo simples facto de ser mais fácil simular
dados sensoriais do que esperar que as alterações ocorram naturalmente. Imagine-se o
caso do parâmetro temperatura: naturalmente as alterações não ocorrem sempre que
pretendemos, podendo demorar horas a acontecer. Já com simulações, podemos
provocar alterações neste parâmetro sempre que necessitarmos.
Desta forma, optou-se por utilizar uma interface gráfica que, através de botões
numa aplicação web, permite modificar os parâmetros sensoriais. Acedendo a esta
aplicação web através do Raspberry Pi, prova-se que é possível este SBC enviar valores
simulados através do webservice do componente de gestão de dados sensoriais e
posteriormente utilizá-los para modificar o modelo virtual, em tempo real.
3.4.1 – Casos de uso
Antes de mostrar o processo de construção do protótipo, é importante perceber as
funcionalidades que o sistema terá. A Figura 29 representa os casos de uso de um
utilizador normal e do administrador do sistema.
71
FIGURA 29: CASOS DE USO DA APLICAÇÃO CONCEBIDA.
O ator utilizador representa um qualquer utilizador que tenha a aplicação instalada
no seu dispositivo móvel Android e que a execute. Este terá acesso a algumas
funcionalidades e principalmente à utilização dos parâmetros sensoriais. No caso da
iluminação, será ligado ou desligado um candeeiro presente no modelo virtual, com a
intensidade de iluminação recebida dos webservices do componente de gestão de dados
sensoriais, que varia entre 0 e 8, sendo que o 0 corresponde a desligado e o 8 a ligado
com a intensidade máxima. Já o parâmetro de temperatura, após receber o valor atual,
irá proceder à substituição da textura atual pela textura associada ao intervalo de
temperatura que lhe corresponde, sendo que existem 5 intervalos de temperatura: muito
frio, frio, normal, quente e muito quente, sendo que as texturas que lhes estão
associadas são baseadas nas cores, respetivamente, azul muito escuro, azul claro, verde,
laranja e vermelho.
Os casos de uso deste ator são descritos de seguida.

Ativar iluminação: Quando a iluminação não estiver a ser utilizada, vai ativála, acendendo o candeeiro no modelo virtual, com o valor da intensidade de
iluminação atual.

Desativar iluminação: Quando a iluminação estiver a ser utilizada, vai
desligá-la, atribuindo a intensidade zero ao candeeiro presente no modelo
virtual.

Ativar temperatura: Altera a visualização da temperatura no modelo virtual,
substituindo-lhe a textura original pela textura do intervalo de temperatura em
que está inserida a temperatura atual.
72

Desligar temperatura: Desliga a visualização da temperatura e restaura a
textura original.

Atualizar valores: Substitui os valores de temperatura e iluminação
armazenados na aplicação pelos mais recentes.

Ativar legenda: Exibe uma legenda que indica os cinco intervalos de
temperatura.

Desativar legenda: Caso a legenda esteja a ser exibida, oculta-a.

Sair: Termina o processo e sai da aplicação.
O segundo ator do sistema é o administrador, que será um utilizador com
privilégios especiais, a quem é permitido controlar todo o sistema. Desta forma, poderá
utilizar o simulador para controlar os dois parâmetros sensoriais, definir os cinco níveis
de temperatura e decidir se o parâmetro da temperatura pode ser utilizado na aplicação
de RA.
Os casos de uso deste utilizador são descritos de seguida:

Aumentar valor da temperatura: Verifica o valor atual da temperatura e
acrescenta-lhe 1.

Diminuir valor da temperatura: Verifica o valor atual da temperatura e
retira-lhe 1.

Aumentar valor da iluminação: Verifica o valor atual da intensidade da
iluminação e acrescenta-lhe 1.

Diminuir valor da iluminação: Verifica o valor atual da intensidade da
iluminação e retira-lhe 1.

Visualizar valores: Apresenta no ecrã os valores atuais da temperatura e da
intensidade de iluminação.

Permitir temperatura: Permite que, na aplicação de RA, seja utilizado o
parâmetro da temperatura, assim como os casos de uso a ele associados.

Proibir temperatura: Desabilita a utilização do parâmetro da temperatura na
aplicação de RA, assim como os casos de uso a ele associados.

Definir níveis de temperatura: Define os cinco intervalos de temperatura
possíveis: muito frio, frio, normal, quente, muito quente.
73
3.4.2 – Bloco funcional gestão de dados sensoriais
Formado por um webservice, construído em PHP e por um SGBD MySQL, este
bloco funcional foi concebido de forma a identificar os diferentes pedidos provenientes
dos restantes blocos funcionais.
Quando algum componente necessita de interagir com a BD, efetuam um pedido
GET aos webservices, integrados no componente gestão de dados sensoriais, que tratará
de fazer a operação correspondente na BD.
Em primeiro lugar, o Webservice verifica o que lhe foi enviado através do pedido
GET, estando preparado para receber as variáveis sensor, parametro, valor e operacao.
Cada uma destas variáveis contém informações uteis para o sistema. A primeira contém
a identificação do sensor que efetuou uma medição, a segunda possui a identificação do
parâmetro medido, enquanto a terceira representa o valor medido. Por fim, a operacao é
uma String que indica o nome da operação a realizar. É também importante referir que a
variável parametro corresponde ao parâmetro iluminação quando o seu valor é 0 e à
temperatura quando é 1. Como nesta dissertação as medições foram simuladas, definiuse um único sensor que faz a medição dos dois parâmetros: iluminação e temperatura.
Para cada uma das operações possíveis existe um ciclo IF, sendo em cada um
deles verificado se o valor da variável operacao corresponde à operação desse IF. A
variável operacao pode ter os seguintes valores e respetiva funcionalidade:

insertData: Lê na BD o valor atual de um determinado parâmetro e somalhe 1, guardando-o novamente;

insertDataLess: Lê na BD o valor atual de um determinado parâmetro e
subtrai-lhe 1, guardando-o novamente;

getValorIluminacao: Lê na BD o valor atual da iluminação e devolve-o ao
componente que fez o pedido;

getValorTemperatura: Lê na BD o valor atual da temperatura e devolve-o
ao componente que fez o pedido;

changeAtiveTemperature: Verifica BD se o uso da temperatura é
permitido ou não e troca-o (i.e. Se for permitido, proíbe. Se não for
permitido, permite);
74

checkStatusTemperature: Lê na BD se o uso da temperatura é ou não
permitido;

getNiveisTemperatura: Lê na BD os cinco níveis de temperatura;

changeNiveisTemperatura: Atualiza os valores dos cinco níveis de
temperatura.
Após entrar num ciclo IF e de efetuar o tratamento necessário dos dados, é
chamado o método executarQuery de uma classe externa que está responsável pela
gestão das operações na BD, DataBase.php. Ao ser chamado, esse método recebe uma
query como argumento e executa-a e, no caso de ser pretendida alguma informação da
mesma, devolve os resultados para o Webservice que, por sua vez, trata de o fazer
chegar ao componente que efetuou o pedido. Para que esta resposta seja reconhecida na
aplicação desenvolvida no Unity3D, é feita através de um echo dos valores a serem
enviados. No caso de ser necessário enviar mais que um valor por pedido (e.g.
getNiveisTemperatura), é feita a concatenação de todos os valores, separados pelo
caracter @, efetuando-se posteriormente um explode da String no bloco em questão,
enviando-se a String final também através de um echo.
3.4.3 – Bloco funcional contextualização sensorial
Para a construção deste componente foram utilizadas as tecnologias HTML, PHP,
JS e AJAX. Construiu-se uma página web, apenas acessível ao administrador do
sistema, representada na Figura 30, que contém alguns botões para a simulação dos
dados sensoriais, aumentando ou diminuindo o valor atual de um determinado
parâmetro. Ao serem utilizados, é efetuado um pedido GET ao webservice, com a
variável operacao a ter o valor insertData ou insertDataLess, conforme a intensão do
botão. Além desta variável, é também enviada a identificação do parâmetro e do sensor.
Neste simulador é também possível ativar ou desativar o uso do parâmetro
temperatura na aplicação de RA, sendo que se o uso não for permitido, todas as
referências a este parâmetro são também escondidas. Esta ativação/desativação do
parâmetro é feita comunicando com o Webservice, do componente de gestão de dados
sensoriais,
onde
a
variável
operacao
do
pedido
GET
tem
o
valor
changeAtiveTemperature.
75
Além das simulações e através de dois pedidos GET (onde a variável operacao
tem, respetivamente no primeiro e segundo pedido, os valores getValorIluminacao e
getValorTemperatura), é possível visualizar os valores atuais da iluminação e
temperatura. No caso da iluminação, não é permitido que os valores sejam menores que
0 e maiores que 8, sendo estes os limites da intensidade de iluminação com que trabalha
o Unity3D. É também neste simulador que são definidos os cinco níveis de temperatura,
utilizando a variável operacao com o valor changeNiveisTemperatura no pedido ao
Webservice (i.e. componente de gestão de dados sensoriais): é considerado muito frio
quando a temperatura está abaixo de x graus, frio quando a temperatura se encontra em
x e y graus, assim como normal e quente. Considera-se muito quente quando a
temperatura está acima de x graus.
FIGURA 30: VISÃO GERAL DO SIMULADOR DE DADOS SENSORIAIS.
76
3.4.4 - Bloco funcional visualização de modelos virtuais contextualizados
O componente de visualização de modelos virtuais contetualizados contém todo o
processo de desenvolvimento da aplicação que irá correr em dispositivos Android.
Combinando o GameEngine Unity3D e a extensão da Framework Vuforia, o seu
processo de construção tornou-se mais fácil, graças às bibliotecas que esta framework
disponibiliza, simplificando-o. Para completar, é necessário a marca de RA, criado a
partir da aplicação web “Developer Vuforia” e de um modelo virtual no formato .FBX.
A Figura 31 ilustra o fluxo de dados deste componente.
FIGURA 31: ESQUEMA DO PROCESSO DE DESENVOLVIMENTO NO UNITY3D.
Como qualquer aplicação de RA, é necessário algo que ative esta tecnologia.
Neste caso, utiliza-se uma marca de RA desenvolvida pela Qualcomm, criadores da
framework Vuforia, chamado ImageTarget. A criação da marca exige a criação de um
package para o Unity3D, que contém todas as suas informações necessárias para o seu
reconhecimento. Este processo é feito no portal Vuforia Developers, secção Target
Manager, onde é necessário fazer upload da imagem ou de cada uma das faces de uma
caixa. Após o download do package, o mesmo deve ser importado no Unity3D.
77
Após a inclusão do modelo virtual, marca de RA e extensão Vuforia, inicia-se o
processo de construção do protótipo. No Unity3D é necessário substituir a câmara
tradicional pela do Vuforia, arrastando da diretoria “Qualcomm Augmented Reality ->
Prefab” a ARCamera para o painel Hierarchy, após apagar a câmara original do
Unity3D. Agora, selecionando esse elemento e acedendo ao Inspector, ativamos a marca
na secção “Data Set Load Behaviour (Script)”, selecionando as duas checkboxs
disponíveis. De seguida, da mesma diretoria é também necessário importar o
“ImageTarget” para esse painel. Após isso, ao selecioná-lo já é possível associar-lhe a
marca, escolhendo as opções correspondentes nos selects “Data Set” e Image Target,
da secção “Image Target Behaviour (Script)”. Por fim, arrastamos o modelo virtual,
presente no painel “Project”, sobrepondo-o ao ImageTarget. A partir deste momento,
ao executarmos a aplicação, já é possível visualizar o modelo virtual quando a marca é
capturada pela câmara do dispositivo. Durante este processo, o módulo ARCamera,
originário da extensão Vuforia, automatiza todo o processo de Tracking e deteção de
marca, rendering e da visualização da aplicação no dispositivo móvel apresentados na
descrição deste bloco funcional.
A etapa seguinte da construção do bloco funcional é feita através de Scripts que,
após criados, são associados ao ImageTarget, iniciando automaticamente com a
aplicação. Aqui, construímos os restantes módulos deste bloco funcional (Obtenção de
dados sensoriais, definição das propriedades e interação e atualização). Foi
desenvolvido um script que posteriormente foi associado ao ImageTarget, que contém
toda a lógica da aplicação, desde texturas, botões, interações com a BD e atualizações.
Este script contém diversos métodos capazes de responder às diferentes necessidades da
aplicação.
Quando a aplicação é executada, este script é automaticamente iniciado,
carregando por defeito a um método chamado Start. Este método permite configurar
como é que a aplicação se comporta quando é carregada, ou seja, o que é que ela faz no
início. Para entender da melhor forma este método, optou-se por deixá-lo para o fim e
explicar primeiro os restantes e que no fundo acabam por se integrar neste.
78
Atribuir Texturas
Um dos primeiros métodos que faz sentido explicar chama-se carregarTexturas.
Este método, quando é chamado, carrega a textura inicial dos objetos que compõem o
modelo virtual: o chão, a parede de tijolo, a lareira, o quadro e o candeeiro. Se o objeto
for composto por múltiplas faces, é necessário carregar a textura para cada uma delas. O
primeiro passo para aplicar uma textura é aceder ao objeto na cena, através da função
GameObject.Find. Após isso, para aplicar a textura a esse objeto/face é utilizada a
função renderer.material.mainTexture, indicando a localização da mesma através da
propriedade Resources.Load. A Tabela 2 mostra o processo de acesso ao objeto
“parede” e posterior aplicação da textura, que neste caso se encontra na diretoria
“Textura”, com o nome “tijolo”.
TABELA 2: EXEMPLO DE APLICAÇÃO DE TEXTURA A UM OBJETO DO MODELO VIRTUAL
var parede = GameObject.Find("cenario/Parede");
parede.renderer.material.mainTexture = Resources.Load("Texturas/tijolo");
As texturas devem estar no formato JPG ou PNG, sendo que nesta dissertação, por
ser construída para dispositivos móveis e por uma questão de otimização, foram
utilizadas imagens no formato JPG.
Comunicar com o Webservice do componente gestão de dados sensoriais
Outra funcionalidade que tem extrema importância neste script é a comunicação
com o Webservice, pertencente ao componente de gestão de dados sensoriais, para que a
aplicação possa ter acesso a informações na BD. Existem vários métodos na aplicação
que efetuam esta tarefa, cada um com a sua finalidade.
Comunicar com o Webservice é bastante fácil, sendo necessário indicar o seu
URL, assim como os parâmetros necessários para estruturar o pedido. Depois disso,
chamamos um objeto WWW que concretiza esse pedido. Feito isto, o sistema fica a
aguardar (yield) a resposta ao pedido, fazendo posteriormente o seu download. Ao
recebê-la e estando esta isenta de erros, é possível aceder ao seu conteúdo através da
propriedade www.text. A Figura 32 exemplifica a comunicação com o Webservice para
obter o valor da iluminação atual.
79
FIGURA 32: EXEMPLO DA CONSTRUÇÃO DE UM PEDIDO AO WEBSERVICE.
Vários métodos necessitam de comunicar com o Webservice, utilizando sempre
este
processo.
Os
métodos
que
o
utilizam
são:
callIluminacao,
verificarStatusTemperatura, mostrarTemperatura, txt_Niveis, catchTemperature e
catchIluminacao.
Por fim, caso a comunicação com o Webservice falhe por algum motivo (e.g. Sem
ligação à internet), é apresentada no ecrã uma mensagem de erro a pedir ao utilizador
para verificar a sua ligação à internet.
Controlar iluminação: Acender e apagar candeeiro
O parâmetro da iluminação nesta aplicação é simulado através do controlo de um
candeeiro. Em primeiro lugar é utilizado o método catchIluminacao para, através do
Webservicei (i.e. componente de gestão de dados sensoriais), saber qual o último valor
medido deste parâmetro. Este valor irá estar entre 0 e 8, visto serem os valores de
iluminação com que o Unity3D trabalha. Após isso, é possível acender o candeeiro,
tocando no botão correspondente. Quando isso acontece, o sistema verifica qual o valor
da intensidade de iluminação do objeto do candeeiro e, caso o seu valor seja 0, chama o
método callIluminacao. Caso contrário, é chamado o método apagarCandeeiro. Ao
aceder ao método callIluminacao, é verificado novamente o valor mais recente deste
parâmetro e, de seguida, enviado para o método changeIluminacao, que altera a
intensidade luminosa do candeeiro atribuindo-lhe o esse valor, através da propriedade
light.intensity e define o seu alcance em 200, utilizando a propriedade light.range. A
Tabela 3 contém o código utilizado para acender o candeeiro.
80
Caso o candeeiro já estiver ligado e este botão seja novamente pressionado, é
chamado o método apagarCandeeiro, que atribui o valor 0 à light.intensity do objeto do
“candeeiro”.
TABELA 3: EXEMPLIFICAÇÃO DO CÓDIGO PARA ACIONAR O OBJETO "CANDEEIRO"
var candeeiro = GameObject.Find("cenario/luz");
candeeiro.light.intensity = iluminacaoInt;
candeeiro.light.range = 200;
Controlar temperatura: Alterar e restaurar texturas
O parâmetro sensorial da temperatura é simulado através da alteração das texturas
dos elementos da cena consoante a temperatura atual, existindo intervalos de
temperatura, cada um com uma textura diferente associada. Estas texturas, adaptadas da
original, têm tons diferentes. A Tabela 4 indica os tons associados a cada um dos níveis.
TABELA 4: CORES ASSOCIADAS ÀS TEXTURAS DOS NÍVEIS DE TEMPERATURA
Nível de temperatura
Cor associada à textura
Muito frio
Azul-escuro
Frio
Azul claro
Normal
Verde
Quente
Laranja
Muito Quente
Vermelho
Contudo, apenas é possível efetuar esta tarefa se o administrador do sistema
permitir o seu uso. Por isso, a primeira ação para este parâmetro é verificar se o seu uso
é permitido, utilizando o método verificarStatusTemperatura, que irá indicar se pode ou
não permitir o seu uso. Se a resposta for positiva, então acede ao método
catchTemperature para saber a temperatura atual. Agora, imaginando que o
administrador proíbe o seu uso enquanto a aplicação está em execução e este parâmetro
se encontra em uso, a resposta será negativa e implicará que seja chamado o método
desligarMostrarTemperatura, que irá restaurar as texturas originais e ocultará todas as
referências a este parâmetro no ecrã.
Depois disto, quando o seu uso é permitido e é pressionado o botão
correspondente, é necessário saber se o valor anteriormente obtido ainda se encontra
81
atualizado, fazendo-o através do método catchTemperature. Depois disso é chamado o
método mostrarTemperatura, que irá proceder à alteração da textura de cada um dos
objetos presentes na cena.
De seguida é feito um pedido ao Webservice do componente de gestão de dados
sensoriais, de forma a saber os cinco níveis de temperatura. Como anteriormente
referido, o Webservice envia estes níveis como uma concatenação de Strings separadas
por um “@”, sendo desta forma necessário efetuar a sua separação. Isto é feito através
da propriedade Split. Os dados são recebidos do Webservice, armazenados na variável
niveistemperatura e é essa variável que é dividida, utilizando o caracter “@” para
identificar o “corte”, sendo que os valores serão armazenados num array. Depois disto,
os diferentes níveis de temperatura são divididos por diferentes variáveis. No caso do
nível muito frio e muito quente, como apenas têm um valor (i.e. muito frio abaixo de x
graus; muito quente acima de x graus.), são guardados em variáveis inteiras, enquanto as
restantes (i.e. frio, normal, quente) são armazenadas em arrays com 2 posições,
correspondendo a posição 0 ao valor mínimo e a posição 1 ao valor máximo. A Tabela 5
representa o processo do Split e posterior armazenamento dos cinco níveis de
temperatura.
TABELA 5: IMPLEMENTAÇÃO DO SPLIT DOS DIFERENTES NÍVEIS DE TEMPERATURA NO UNITY3D.
niveistemperatura = www.text;
var values : String[] = niveistemperatura.Split("@"[0]);
var mtfrio : int = int.Parse(values[0]);
var frio : String[] = values[1].Split(","[0]);
var normal : String[] = values[2].Split(","[0]);
var quente : String[] = values[3].Split(","[0]);
var mtquente : int = int.Parse(values[4]);
Agora que já se sabem os cinco níveis de temperatura, falta verificar em qual
deles se enquadra a temperatura atual, substituindo de seguidas as texturas originais
pelas que correspondem a este nível. Este processo é exatamente o mesmo que é
utilizado para aplicar as texturas originais, alterando apenas a diretoria das mesmas.
82
OnGUI: Botões e informação auxiliar
A interação que o utilizador pode ter com a aplicação, além da utilização da marca
de RA, é feita através do toque em botões. Além disso, de forma a auxiliar o utilizador,
são utilizadas caixas de texto onde são apresentadas diversas informações úteis.
No Unity3D existe uma função que está preparada para estas duas tarefas,
denominada OnGUI, sendo automaticamente chamada várias vezes por frame. Desta
forma, foram adicionados cinco botões e algumas caixas de texto.
As caixas de texto, exibidas através da propriedade GUI.Box, são utilizadas para
apresentar informações úteis para o utilizador, como os valores de iluminação e
temperatura atuais, assim como os cinco níveis de temperatura. Desta forma, as duas
primeiras apenas mostram os valores que são recebidos pelos métodos correspondentes,
catchIluminacao e catchTemperature. Já a caixa de texto dos níveis de temperatura,
contém as informações que são recolhidas quando o método txt_Niveis é utilizado. É
importante referir que estes dois últimos (indicar temperatura atual e níveis de
temperatura) apenas são adicionados ao ecrã se o administrador permitir o uso deste
parâmetro. A Tabela 6 mostra o código utilizado para criar uma GUI.Box, a sua
localização no ecrã e o respetivo texto.
TABELA 6: IMPLEMENTAÇÃO DA PROPRIEDADE GUI.BOX, EXIBINDO INFORMAÇÃO SENSORIAL
GUI.Box(Rect((Screen.width*0.15),Screen.height*0.13,170,30), "Temperatura atual: "+
temperaturaInt + " ºC");
O primeiro botão tem a função de ativar ou desativar o parâmetro da iluminação,
ou seja, acender ou desligar o candeeiro. Ao ser pressionado, este botão vai verificar a
intensidade de iluminação desse candeeiro, através da função light.intensity e, caso esta
seja 0, é chamado o método callIluminacao, que ativa o candeeiro com a intensidade
correspondente à iluminação atual e atribui o valor 1 à variável luzOn, que possibilita
determinar quando o candeeiro está ligado. Caso este já esteja ligado e quando o utilizar
tocar neste botão, é chamado o método apagarCandeeiro.
O botão seguinte, que apenas está visível caso este parâmetro seja permitido pelo
administrador, ativa a visualização das texturas de temperatura. Ao ser pressionado, é
utilizado o método mostrarTemperatura, sendo também atribuído o valor 1 à variável
ativo cujo objetivo, à semelhança da luzOn, é determinar quando as texturas de
83
temperatura estão a ser utilizadas. Por fim, caso o utilizador toque no botão e as texturas
de temperatura estejam ativadas, procede-se ao restauro das texturas originais, por
intermédio do método desligarMostrarTemperatura.
O terceiro botão é utilizado para atualizar os valores da temperatura e iluminação,
comunicando com o Webservice e substituindo os valores antigos pelos atuais. Desta
forma e ao ser pressionado, utiliza os métodos catchIluminacao e catchTemperature
para atualizar os valores e, posteriormente, verifica se os dois parâmetros estão a ser
utilizados, recorrendo às variáveis luzOn e ativo, respetivamente. Caso a iluminação
esteja ligada, é chamado novamente o método CallIluminacao, que irá aplicar a nova
intensidade. No caso da temperatura, é primeiro verificado se o parâmetro é permitido
(verificarStatusTemperatura) e, caso positivo, são verificados os níveis atuais da
temperatura (txt_Niveis). Por fim, caso seja permitido e esteja ativo, é novamente
carregada a textura correspondente, através do método mostrarTemperatura.
O próximo botão tem uma funcionalidade mais simples que os anteriores. Ao ser
pressionado pela primeira vez, acrescenta 6 caixas de texto ao ecrã, que contêm a
legenda dos níveis de temperatura atuais, de forma a facilitar a compreensão das
texturas coloridas. Ao ser pressionado, é chamado o método changeMostrarNiveis, cuja
finalidade é fazer alternar o valor da variável mostrarNiveis entre 0 e 1, sendo que é
atribuído o valor 1 quando a legenda está visível e 0 quando está oculta.
Por fim, o último botão fecha a aplicação, terminando o seu processo através do
comando Application.Quit disponibilizado pela Framework Vuforia.
A Tabela 7 mostra o processo para a criação de um botão, recorrendo à
propriedade GUI.Button, ao qual é indicado a sua posição e o bitmap associado à sua
aparência.
TABELA 7: CRIAÇÃO DE UM BOTÃO NOS SCRIPTS DO UNITY3D
GUI.Button(Rect((Screen.width*0.01),(Screen.height*0.4),(Screen.width*0.1),(Screen.width
*0.1)),btnTextureTemperature)
84
Start: A entrada na aplicação
Como anteriormente mencionado, quando se inicia a aplicação é automaticamente
executado o método Start. Este método contém todas instruções da aplicação de RA que
nós pretendemos que sejam corridas desde o início. Desta forma, faz sentido sabermos
imediatamente os valores da iluminação, saber se é permitido usar o parâmetro da
temperatura e se sim, qual o seu valor atual e os níveis, assim como aplicarmos as
texturas padrão de todos os objetos da cena.
Um dos requisitos que colocamos para a construção da interface da aplicação
pretendia que a orientação fosse Landscape. Definiu-se então esta orientação na
aplicação, deixando de ser possível alterá-la quando o utilizador rodar o seu dispositivo
móvel, garantindo que a mesma vai ter sempre o mesmo comportamento,
independentemente da orientação do mesmo. Este requisito foi implementado utilizando
a
propriedade
Screen.orientation,
à
qual
se
atribuiu
o
valor
ScreenOrientation.LandscapeLeft. A tarefa seguinte é aplicar as texturas originais aos
objetos da cena, utilizando o método carregarTexturas. De seguida e através do método
verificarStatusTemperatura, verifica-se se o parâmetro de temperatura está acessível e,
caso positivo verifica-se o seu valor atual e os respetivos níveis de temperatura
utilizando, respetivamente, os métodos catchTemperature e txt_Niveis. A etapa seguinte
é adquirir o valor atual da iluminação, servindo-se do método catchIluminacao para
esse fim.
É também aqui que se inicia o ciclo que, a cada 10 segundos, atualiza
automaticamente todos os dados da aplicação. Este processo é feito através da função
yeld WaitForSeconds que, quando corresponder à hora programada, executa as
instruções para obter os valores atuais da iluminação e temperatura (catchIluminacao e
catchTemperature) e, caso estes parâmetros estejam a ser utilizados (a verificação é
feita através das variáveis luzOn e ativo), atualiza a intensidade do candeeiro e/ou a cor
da textura, utilizando os métodos callIluminacao e mostrarTemperatura. Contudo, no
caso da temperatura, antes de ser chamado o método em questão, é verificado se ainda é
permitido o seu uso, chamando o método verificarStatusTemperatura. Caso positivo,
então é atualizada a cor da textura e de seguida, atualizados os níveis de temperatura,
empregando-se do método txt_niveis.
85
3.4.5 – Base de dados
A BD foi desenhada e implementada de forma a permitir o armazenamento de
toda a informação essencial para o funcionamento do sistema, tendo sido necessárias
quatro tabelas: Parametros, Medicoes, niveistemperatura e sensores. A Figura 33
representa o Diagrama Entidade-Relacionamento da BD criada.
FIGURA 33: DIAGRAMA ENTIDADE-RELACIONAMENTO DA BASE DE DADOS DO PROTÓTIPO.
A tabela Parametros é utilizada para armazenar todas as informações relativas aos
parâmetros sensoriais que podem ser utilizados no protótipo, contendo as propriedades
id_parametro (chave primária) e nome_parametro.
Associado a esta está a tabela, níveistemperatura. Aqui é possível armazenar
informações úteis relativamente a um parâmetro (representado pela chave estrangeira
id_parametro), sendo no caso da aplicação desenvolvida, modelada em torno do
parâmetro de temperatura, permitindo indicar os diferentes níveis e também o seu
estado, se está ativo ou desativo, correspondendo aos campos mtfrio, frio, normal,
quente, mtquente e ativo.
Outra tabela que faz parte desta BD chama-se sensores e contém todas as
informações sobre um determinado sensor do sistema, ou seja, o seu nome ou código e
o estado do mesmo. Esta propriedade estado indica se o sensor está neste momento
ativo e disponível para ser utilizado para a recolha de dados sensoriais ou se está
86
desativado. Como nesta dissertação apenas se simulou um sensor que efetua a medição
de dois parâmetros, não se achou necessário relacionar as tabelas Parametros e
sensores, que indicaria que parâmetros eram medidos por cada sensor. Existem ainda
mais duas propriedades: id_sensor (chave primária) e nome_sensor.
Por fim, a tabela Medicoes armazena todas as medições sensoriais efetuadas pelos
sensores. Cada medição apenas contém os dados de um parâmetro com o respetivo
valor, assim como a identificação do sensor que efetuou a medição e a respetiva data da
operação,
no
formato
AAAA-MM-DD
HH:mm:ss,
ou
seja,
ano-mês-dia
hora:minutos:segundos. Desta forma, esta tabela contém as propriedades id_medicao
(chave primária), id_sensor e id_parametro (chaves estrangeiras), valor e data.
3.4.6 – Dispositivos móveis utilizados na construção do protótipo
Durante o processo de construção do protótipo foram utilizados dois dispositivos
móveis com o sistema operativo Android, com os quais foram efetuados inúmeros
testes: Samsung Galaxy Ace Plus (GT-S7500) e Samsung Galaxy Tab 2 10.1 (GTP5110), representados na Figura 34 à direita e esquerda, respetivamente.
O primeiro dispositivo é um Smartphone com a versão 2.3.6 do Android,
processador de 1 GHz, ecrã de 3.65 polegadas e uma resolução de 320x480 pixéis. Com
uma câmara de 5 megapixéis e ligação à internet 3G e Wi-Fi 802.11b/g/n, permitiu
testar toda a aplicação e perceber como esta se comportava em dispositivos com
dimensões mais pequenas e versões Android mais antigas.
O segundo dispositivo é um Tablet, bastante popular no mercado atual. Possui a
versão Android 4.0.4, ecrã de 10.1 polegadas e uma resolução de 1280x800 pixéis.
Possui uma câmara de 3.2 megapixéis frontal e traseira que permite a gravação em 720p
e possibilita a ligação à internet através de 3G e 802.11 a/b/g/n.
87
FIGURA 34: DISPOSITIVOS MÓVEIS UTILIZADOS DURANTE A CONSTRUÇÃO DO PROTÓTIPO.
88
4 – Caso de estudo
Após a conclusão da conceção do sistema proposto nesta dissertação, procedeu-se
à realização dos testes da aplicação, assim como a exemplificação das suas
funcionalidades, através de um caso de estudo de uma imobiliária. Como toda a
aplicação foi construída para comunicar com o Webservice (componente de gestão de
dados sensoriais), é necessária uma constante ligação à internet. Por isso, ao iniciar a
aplicação, esta irá verificar se existe ligação à rede, através de Wi-Fi ou 3G/4G. Caso
isto não se verifique, surgirá uma mensagem de erro igual à da Figura 35, a informar o
utilizador desta necessidade.
FIGURA 35: MENSAGEM DE ERRO, APRESENTADA NO DISPOSITIVO MÓVEL QUANDO NÃO É POSSÍVEL
COMUNICAR COM O WEBSERVICE.
Após a ligação à internet com sucesso, a câmara do dispositivo móvel é ligada e
automaticamente começa a recolha de frames de vídeo. Nesta etapa é possível visualizar
a interface da aplicação que, de acordo com o planeamento, é dividida da seguinte
forma e como indicado na Figura 36:
89

Lado esquerdo: Botões para interação;

Canto superior esquerdo: Informações sobre os valores atuais dos
parâmetros sensoriais;

Lado Direito: Informações sobre os níveis de temperatura;

Ecrã inteiro: Imagem capturada pela câmara do dispositivo.
FIGURA 36: INTERFACE DA APLICAÇÃO CONCEBIDA.
Desde a primeira frame capturada é possível reconhecer a marca de RA, tendo
sido utilizada uma marca padrão da Framework Vuforia, apresentada na Figura 37.
FIGURA 37: MARCA DE REALIDADE AUMENTADA STONES, DISPONIBILIZADA PELA VUFORIA.
90
Ao detetar a marca, o sistema irá fazer o rendering do modelo virtual
correspondente, assim como executar todos os scripts que estão associados a esse
modelo. No caso desta aplicação, o modelo virtual é bastante simples, contendo 3
paredes de tijolo, um chão de madeira, uma lareira, um quadro e um candeeiro. O
resultado do rendering do modelo virtual está representado na Figura 38.
FIGURA 38: RENDERING DO MODELO VIRTUAL.
A partir de agora, se o utilizador alterar a orientação da marca, o modelo virtual
irá seguir essa orientação, permitindo que o utilizador visualize o modelo virtual de
diferentes perspetivas. A Figura 39 exemplifica como é feito o rendering do modelo
virtual se o utilizador visualizar a marca a partir do lado esquerdo, de outra perspectiva,
em vez de uma captura frontal.
FIGURA 39: CAPTURA DA MARCA ATRAVÉS DE DIFERENTES ÂNGULOS PERMITE VISUALIZAR O MODELO
VIRTUAL DE OUTRAS PERSPETIVAS.
91
A interação com a aplicação é feita através dos botões apresentados do lado
esquerdo, com dimensões relativas, adaptando-se às dimensões de ecrã de qualquer
dispositivo.
O primeiro botão ativa o parâmetro iluminação que, por consequência ativa o
candeeiro com a intensidade a corresponder ao valor atual desse parâmetro. Enquanto a
Figura 40 mostra o candeeiro com a intensidade 1, a Figura 41 mostra-o com
intensidade 7.
FIGURA 40: RENDERING DO MODELO VIRTUAL, COM O CANDEEIRO LIGADO COM INTENSIDADE 1
FIGURA 41: RENDERING DO MODELO VIRTUAL, COM O CANDEEIRO LIGADO COM INTENSIDADE 7
Ao ser novamente pressionado, o botão desliga o candeeiro, voltando ao seu
estado original, ou seja, intensidade 0. A tarefa do segundo botão é atualizar os valores
atuais dos parâmetros permitidos, substituindo os anteriores. Por fim, caso o parâmetro
de temperatura esteja disponível, o terceiro botão ativa ou desativa a sua visualização.
92
Como referido anteriormente, a utilização deste parâmetro é a alteração das texturas
para outras com cores significativas. A Figura 42 mostra as texturas para cada um dos
cinco níveis de temperatura.
FIGURA 42: VISUALIZAÇÃO DO MODELO VIRTUAL NOS CINCO NÍVEIS DE TEMPERATURA.
93
A figura encontra-se dividida em cinco partes, cada uma representando um dos
níveis e as respetivas cores. A imagem numerada com o número 1 corresponde ao nível
“muito frio”, com uma cor azul escura. A segunda, azul mais claro corresponde ao nível
“frio”, enquanto a terceira é apresentada quando o valor da temperatura é considerado
“normal”, estando associada à cor verde. A quarta imagem representa o nível “quente”
através do cor-de-laranja, enquanto o nível “muito quente” tem associada a cor
vermelha.
Caso o candeeiro esteja ligado (i.e. parâmetro iluminação em uso), é possível
utilizar os dois ao mesmo tempo. A Figura 43 comprova este acontecimento, utilizando
como exemplo o nível de temperatura “muito frio” e intensidade de iluminação com o
valor 8.
FIGURA 43: RENDERING DO MODELO VIRTUAL COM OS PARÂMETROS DE TEMPERATURA E ILUMINAÇÃO
LIGADOS EM SIMULTÂNEO.
O botão seguinte permite mostrar ou ocultar várias caixas com informações sobre
os níveis de temperatura, conforme apresenta a Figura 44.
94
FIGURA 44: APRESENTAÇÃO DA LEGENDA DOS NÍVEIS DE TEMPERATURA.
Contudo, o parâmetro da temperatura apenas se encontra visível se o
administrador permitir o seu uso. Caso isso não se verifique e conforme a Figura 45, os
botões correspondentes à temperatura e legenda dos níveis, assim como a informação da
temperatura atual, estarão ocultos.
FIGURA 45: INTERFACE DO DISPOSITIVO MÓVEL COM O PARÂMETRO DA TEMPERATURA DESATIVADO PELO
ADMINISTRADOR.
95
96
5 – Resultados e conclusões
Este trabalho foi desenvolvido com a motivação de desenvolver um projeto que
alia-se três tecnologias com elevado potencial (i.e.: RA, Android e SBC) e também por
considerarmos que estão pouco exploradas quando interligadas, não existindo nenhum
projeto que se destaque neste contexto. Achou-se interessante criar um sistema de
aquisição de dados sensoriais que conseguisse influenciar aplicações de RA em
dispositivos móveis, que permitisse ao utilizador perceber o comportamento de
determinado contexto mediante determinadas condições, baseadas nos dados
adquiridos.
Depois da conclusão do estado da arte, foi planeada uma arquitetura para um
sistema de aquisição de dados sensoriais em aplicações de RA para dispositivos móveis,
concluindo-se que o mesmo teria três blocos funcionais: dispositivo móvel, SBC e
webservice. No passo seguinte foram analisadas as tecnologias estudadas no estado da
arte, percebendo as que melhor se adaptavam ao sistema proposto. Chegou-se à
conclusão que deveria ser utilizado PHP e MySQL para conceber o Webservice e que a
melhor opção para a aplicação de RA era a framework Vuforia integrada no Unity3D,
para dispositivos móveis com o SO Android. Por fim, achou-se que não deveria ser
implementado um sistema de aquisição de dados sensoriais, tendo sido feita a simulação
destas medições com recurso a uma plataforma web, capaz de ser executada num
Raspberry Pi, provando-se desta forma que é possível interligá-lo com os restantes
blocos. É importante referir que a escolha para a construção da aplicação de RA não
recaiu no HTML5 pois este ainda não suportava diversas funcionalidades, sendo
necessário o recurso ao X3DOM para fazer o rendering dos modelos virtuais, o que
dificultava a sua visualização em dispositivos móveis.
Neste trabalho foi feito um caso de estudo, no contexto imobiliário. A aquisição
dos dados sensoriais é simulada em dois parâmetros sensoriais: intensidade de
iluminação e temperatura. Esta simulação é feita através de uma plataforma web que,
através de botões, aumenta ou diminui os seus valores atuais. Nesta plataforma, é
também possível definir cinco intervalos de temperatura: muito frio, frio, normal,
quente e muito quente, utilizados posteriormente para influenciar o modelo virtual. Para
finalizar esta plataforma web, é possível habilitar ou desabilitar o uso deste último
97
parâmetro. Além desta plataforma web, foi também desenvolvida a aplicação de RA
para dispositivos móveis que deteta uma marca padrão de RA da framework Vuforia, à
qual está associado um modelo virtual composto por três paredes de tijolo, o chão, uma
lareira com um quadro e um candeeiro. A interação com esta aplicação é possível
através de botões, sendo possível utilizar os dois parâmetros, alterando-os no ecrã do
dispositivo móvel. No caso do parâmetro de intensidade de iluminação, este é
representado alterando a intensidade luminosa de um candeeiro presente no modelo
virtual. Já o parâmetro de temperatura é representado com o recurso a texturas
coloridas, com base no intervalo de temperatura em que o seu valor atual se encontra,
correspondendo aos intervalos muito frio, frio, normal, quente e muito quente as cores
azul-escuro, azul, verde, laranja e vermelho, respetivamente. Note-se que é possível a
utilização destes dois parâmetros em simultâneo, alterando a textura dos objetos que
constituem o modelo virtual e atribuindo intensidade luminosa ao candeeiro, também
este pertencente ao modelo virtual. Caso algum dos dois parâmetros seja atualizado na
plataforma web enquanto estiver em uso na aplicação, o modelo virtual é
automaticamente atualizado de acordo com os novos valores. Por fim, é possível
visualizar as legendas dos diversos intervalos de temperatura, facilitando a compreensão
das cores aplicadas aos objetos da cena.
Pode-se concluir que os objetivos desta dissertação foram atingidos, sendo que
todas as metas propostas foram atingidas e a aplicação de RA se encontra funcional,
assim como os restantes componentes. Para trabalho futuro podemos destacar a
implementação do bloco funcional Single Board Computer com recolhas reais, ao invés
das simuladas nesta dissertação. Utilizando um Raspberry Pi e combinando-o com
vários sensores, podemos tornar o sistema bastante mais interessante e interativo. A
principal vantagem da aplicação proposta nesta dissertação é a possibilidade
implementação recorrendo a outras tecnologias além das utilizadas. A arquitetura da
aplicação proposta não impõe requisitos, sendo apenas necessário o desenvolvimento
dos três módulos e interligação entre eles, independentemente das tecnologias
utilizadas.
98
Referências bibliográficas
Abreu, L. (2012). HTML5 (2ª ed.). Lisboa, Portugal.
Ahmed, M., & Hegazy, T. (2008). Comparison among indoor location-based
technologies for construction and infrastructure applications. Paper presented at
the Annual Conference of the Canadian Society for Civil Engineering 2008,
Quebec.
Akerman, D. (2013). Pi in the Sky: Using The Raspberry Pi for High Altitude
Ballooning,
Consultado
em
22/01/2013,
Disponível
em
http://www.daveakerman.com/wp-content/uploads/2013/01/Raspberry-Jam-PiIn-The-Sky.pdf
Al-Kuwari, A. M. A. H., Ortega-Sanchez, C., Sharif, A., & Potdar, V. (2011, May 31
2011-June 3 2011). User friendly smart home infrastructure: BeeHouse. Paper
presented at the Digital Ecosystems and Technologies Conference (DEST), 2011
Proceedings of the 5th IEEE International Conference on.
Alahmad, M., Nader, W., Cho, Y., Shi, J., & Neal, J. (2011). Integrating physical and
virtual environments to conserve energy in buildings. Energy and Buildings,
43(12), 3710-3717. doi: http://dx.doi.org/10.1016/j.enbuild.2011.10.007
Almaer, D. (2010). Don’t “deploy HTML5″? Thanks again W3C, Consultado em
04/12/2012, Disponível em http://almaer.com/blog/dont-deploy-html5-thanksagain-w3c
Apps, M. R. (2012). HomeSpotter – Augmented Reality Apps for Real Estate Brokers,
Consultado
em
13/12/2012,
Disponível
em
http://www.mobilerealtyapps.com/features/homespotter-augmented-realityapps-for-real-estate-brokers-and-mls/
Araujo, R. B. d. (2003). Computação Ubíqua: Princípios, Tecnologias e Desafios.
Paper presented at the XXI Simpósio Brasileiro de Redes de Computadores, São
Carlos
SP
Brasil.
http://www.professordiovani.com.br/rw/monografia_araujo.pdf
Arduino. (2012a). Arduino Mega, Consultado em 23/01/2013, Disponível em
http://arduino.cc/en/Main/ArduinoBoardMega
Arduino. (2012b). Products, Consultado em 23/01/2013, Disponível em
http://arduino.cc/en/Main/Products
ARToolKit. (2009). ARToolKit, Consultado em 15/01/2013, Disponível em
http://www.hitl.washington.edu/artoolkit/
Azuma, R., Baillot, Y., Behringer, R., Feiner, S., Julier, S., & MacIntyre, B. (2001).
Recent Advances in Augmented Reality. IEEE Comput. Graph. Appl., 21(6), 3447. doi: 10.1109/38.963459
Azuma, R. T. (1997). A Survey of Augmented Reality. Presence: Teleoperators and
Virtual Environments, 6(4), 355-385.
Balint, Z., Kiss, B., Magyari, B., & Simon, K. (2012, 20-22 Sept. 2012). Augmented
reality and image recognition based framework for treasure hunt games. Paper
presented at the Intelligent Systems and Informatics (SISY), 2012 IEEE 10th
Jubilee International Symposium on.
Barreira, J. C. d. S. (2010). Proposta de uma Framework para Desenvolvimento de
Aplicações de Realidade Aumentada. mSc Thesis, Universidade de Trás-osMontes e Alto Douro.
99
Barroca, N., Borges, L. M., Velez, F. J., Monteiro, F., Górski, M., & Castro-Gomes, J.
(2013). Wireless sensor networks for temperature and humidity monitoring
within concrete structures. Construction and Building Materials, 40(0), 11561166. doi: http://dx.doi.org/10.1016/j.conbuildmat.2012.11.087
BBC. (2008). Google bets on Android future, Consultado em 30/12/2012, Disponível
em http://news.bbc.co.uk/2/hi/technology/7266201.stm
Bennett, J. (2008). Wifi Robot, Consultado em 23/01/2013, Disponível em
http://www.jbprojects.net/projects/wifirobot/
Bit,
S.
(2013),
Consultado
em
20/10/2013,
Disponível
em
http://www.squarebit.com.au/images/news/news_ingress01.jpg
Bolter, J. D., Engberg, M., & MacIntyre, B. (2013). Media studies, mobile augmented
reality, and interaction design. interactions, 20(1), 36-45. doi:
10.1145/2405716.2405726
Braga, N. C. (2007). Sensores magnéticos de alarmes, Consultado em 28/01/2013,
Disponível em http://www.sabereletronica.com.br/secoes/leitura/82
Brito, L. M. P. L. d., & Aguiar, R. L. (2002). Qualidade de Serviço em rede móveis:
presente e futuro. Paper presented at the Conferência Científica e Técnica em
Engenharia, ISEL, Lisboa.
Broll, W., Lindt, I., Ohlenburg, J., Herbst, I., Wittkamper, M., & Novotny, T. (2005).
An Infrastructure for Realizing Custom-Tailored Augmented Reality User
Interfaces. IEEE Transactions on Visualization and Computer Graphics, 11(6),
722-733. doi: 10.1109/tvcg.2005.90
Bucioli, A. A. B., Jr., E. A. L., Cardoso, A., & Kirner, C. (2007). ARBIOMED –
SISTEMA EM REALIDADE AUMENTADA PARA VISUALIZAÇÃO E
SIMULAÇÃO DE SINAIS ELETROCARDIOGRÁFICOS.
Burdea, G. C., & Coiffet, P. (2003). Virtual Reality Technology: Wiley.
Chien-Wei, C., Chun-Yu, L., Chung-Ta, K., Yi-Fan, C., & Shau-Yin, T. (2010, 26-29
April 2010). Implementation of JVM tool interface on Dalvik virtual machine.
Paper presented at the VLSI Design Automation and Test (VLSI-DAT), 2010
International Symposium on.
Clarke, S., Arnab, S., Dunwell, I., & Brown, K. (2012). PR:EPARe: A Game-Based
Approach to Relationship Guidance for Adolescents. Procedia Computer
Science, 15(0), 38-44. doi: http://dx.doi.org/10.1016/j.procs.2012.10.056
Clive. (2011). Guest blog # 6: MAME cabinet by Darren J, Consultado em 22/01/2013,
Disponível em http://www.raspberrypi.org/archives/2412
Comunicações, P. (2013). Beachcam, Consultado em 15/08/2013, Disponível em
https://play.google.com/store/apps/details?id=pt.sapo.android.beachcam
Cozzens, T. (2011). Driving Reality Home Wikitude Drive Blends Smartphone Video
with Driving Directions (Vol. 22, pp. 58-58): North Coast Media, LLC.
Crawford, C. (2002). The Art of Interactive Design: A Euphonious and Illuminating
Guide to Building Successful Software: No Starch Press.
Dankov, S., Rzepka, R., & Araki, K. (2011). UIAR Common Sense: an Augmented
Reality Framework for Creating Games to Collect Common Sense from Users.
Procedia - Social and Behavioral Sciences, 27(0), 274-280. doi:
http://dx.doi.org/10.1016/j.sbspro.2011.10.608
Deak, G., Curran, K., & Condell, J. (2012). A survey of active and passive indoor
localisation systems. Computer Communications, 35(16), 1939-1954. doi:
http://dx.doi.org/10.1016/j.comcom.2012.06.004
Deveria, A. (2013). Can I use Web SQL Database? , Consultado em 03/12/2012,
Disponível em http://caniuse.com/sql-storage
100
Esteves, J. M. C. d. S. (2005). Metodologia de Autolocalização Absoluta em Ambientes
Quase-Estruturados. Doutoramento, Universidade do Minho.
Fahey, M. (2010). Is That An EyePet In Your Pocket? , Consultado em 07/01/2013,
Disponível em http://kotaku.com/5616986/is-that-an-eyepet-in-your-pocket
Feijó, B., Clua, E., & da Silva, F. S. C. (2010). Capítulo 7 - Classes, Objetos e Herança
Introdução À Ciência Da Computação Com Jogos (pp. 103-126). Amsterdam:
Elsevier Editora Ltda.
Feiner, S., Macintyre, B., & Seligmann, D. (1993). Knowledge-based augmented
reality. Communication of the ACM, 36(7), 53-62. doi: 10.1145/159544.159587
Feng, W., Vishwanath, V., Leigh, J., & Leigh, J. (2008). High-Fidelity Monitoring in
Virtual Computing Environments.
Ferreira, E., & Eis, D. (2011). HTML5 - Curso W3C Escritório Brasil, Consultado em
11/12/2012,
Disponível
em
http://www.w3c.br/pub/Cursos/CursoHTML5/html5-web.pdf
Fiala, M. (2005, 20-25 June 2005). ARTag, a fiducial marker system using digital
techniques. Paper presented at the Computer Vision and Pattern Recognition,
2005. CVPR 2005. IEEE Computer Society Conference on.
FixeAds - Serviços de Internet, S. A. (2012). Imovirtual, Consultado em 11/12/2012,
Disponível em http://www.imovirtual.com/
Forte, C. E., Silva, S. L. d., & Marengoni, M. (2012). Uso de Realidade Aumentada em
Interface Acessível para Consumidores com Redução de Acuidade Visual.
Foundation, B. (2013). Blender, Consultado em 13/06/2013, Disponível em
http://www.blender.org/
Fröhlich, P., Oulasvirta, A., Baldauf, M., & Nurminen, A. (2011). On the move,
wirelessly connected to the world. Commun. ACM, 54(1), 132-138. doi:
10.1145/1866739.1866766
Frontczak, M., Andersen, R. V., & Wargocki, P. (2012). Questionnaire survey on
factors influencing comfort with indoor environmental quality in Danish
housing.
Building
and
Environment,
50(0),
56-64.
doi:
http://dx.doi.org/10.1016/j.buildenv.2011.10.012
Fulton, S., & Fulton, J. (2011). HTML5 Canvas: O'Reilly Media.
GameGuru. (2006). Wii Sport To be Launched in December 2006 by Nintendo,
Consultado
em
08/01/2013,
Disponível
em
http://www.gameguru.in/sports/2006/22/wii-sport-to-be-launched-in-december2006-by-nintendo/
Garner, S. (2012). BeetBox, Consultado em 22/01/2013, Disponível em
http://scott.j38.net/interactive/beetbox/
Gaylord, C. (2011). Raspberry Pi: Rise of the $25 computer.(Innovation). The Christian
Science Monitor.
Gobbetti, E., & Scateni, R. (1998). Virtual reality: past, present and future.
Gold, J. (2012). Tiny Linux computer punches above its weight; $25 Raspberry Pi
technology demonstrator is a fully functioning, self-contained computer.
Network World.
Gonzalez, J. R., & Bleakley, C. J. (2007, 1-4 July 2007). Accuracy of Spread Spectrum
Techniques for Ultrasonic Indoor Location. Paper presented at the Digital Signal
Processing, 2007 15th International Conference on.
Google. (2012a). Android, the world's most popular mobile platform, Consultado em
12/12/2012, Disponível em http://developer.android.com/about/index.html
Google. (2012b). App Framework, Consultado em 19/12/2012, Disponível em
http://developer.android.com/about/versions/index.html
101
Google. (2012c). Platform Versions, Consultado em 12/12/2012, Disponível em
http://developer.android.com/about/dashboards/index.html
Google. (2012d). Visibility for Your Apps, Consultado em 12/12/2012, Disponível em
http://developer.android.com/distribute/googleplay/about/visibility.html
Gu, Y., & He, Y. (2012). HTML5 Canvas 2D Performance Tuning. Paper presented at
the Tizen Developer conference.
Hall, S. P., & Anderson, E. (2009). Operating systems for mobile computing. J.
Comput. Small Coll., 25(2), 64-71.
Harding, J. (2010). Flash and the HTML5 <video> tag, Consultado em 04/12/2012,
Disponível em http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html
Harter, A., Hopper, A., Steggles, P., Ward, A., & Webster, P. (1999). The anatomy of a
context-aware application. Paper presented at the Proceedings of the 5th annual
ACM/IEEE international conference on Mobile computing and networking,
Seattle, Washington, USA.
Hawkes, R. (2011). Foundation HTML5 Canvas: For Games and Entertainment:
Apress.
Hayward, D. (2012). How to make a Raspberry Pi solar-powered FTP server,
Consultado
em
22/01/2013,
Disponível
em
http://reviews.cnet.co.uk/desktops/how-to-make-a-raspberry-pi-solar-poweredftp-server-50009923/
Hide, N. (2012). Raspberry Pi smart glasses subtitle foreigners in real time, Consultado
em 22/01/2013, Disponível em http://crave.cnet.co.uk/gadgets/raspberry-pismart-glasses-subtitle-foreigners-in-real-time-50008692/
Hirzer, M. (2008). Marker Detection for Augmented Reality Applications.
Hogan, B. P. (2011). HTML5 and CSS3: Develop with Tomorrow's Standards Today:
O'Reilly Vlg. GmbH & Company.
Hudson, C., & Leadbetter, T. (2011). HTML5 Developer's Cookbook: Pearson
Education.
Ibañez, A. S., & Figueras, J. P. (2013). Vuforia v1.5 SDK: Analysis and evaluation of
capabilities. MSc, Universitat Politécnica de Catalunya.
Iwasaki, Y., Nishimura, S., Hamada, Y., & Kozono, K. (2010, April 29 2010-May 1
2010). Development of the MR laboratory for electrical experiment using
ARToolKit. Paper presented at the Information Technology Based Higher
Education and Training (ITHET), 2010 9th International Conference on.
Janela Digital, I. e. T. S., Telecom, P., & Sapo. (2012). Casa Sapo, Consultado em
11/12/2012, Disponível em http://casa.sapo.pt/
Jia, J., Qi, Y., & Zuo, Q. (2010, 15-16 May 2010). An Extended Marker-Based Tracking
System for Augmented Reality. Paper presented at the Modeling, Simulation and
Visualization Methods (WMSVM), 2010 Second International Conference on.
Jie, H., Wang gen, W., & Xiaoqing, Y. (2012, 16-18 July 2012). A pathfinding
algorithm in real-time strategy game based on Unity3D. Paper presented at the
Audio, Language and Image Processing (ICALIP), 2012 International
Conference on.
Jobs, S. (2010). Thoughts on Flash, Consultado em 18/11/2012, Disponível em
http://www.apple.com/hotnews/thoughts-on-flash/)
Johnsen, M. (2012). MoccaPI: A coffee machine controlled by Raspberry Pi,
Consultado
em
22/01/2013,
Disponível
em
http://moccapi.blogspot.co.uk/2012/03/idea.html
Jong-Chih, C., Hoang-Yang, L., Lin-Sen, P., Yi-Sheng, W., & Li-Chang, L. (2010, 1617 Dec. 2010). Building an Augumented Reality-Based Product Promotion
102
System with ARToolkit Integrated with an Adaboosted Classifier-Assisted 1-D
Barcode Reader. Paper presented at the Intelligent Systems (GCIS), 2010
Second WRI Global Congress on.
Kadir, W. M. H. W., Samin, R. E., & Ibrahim, B. S. K. (2012). Internet Controlled
Robotic
Arm.
Procedia
Engineering,
41(0),
1065-1071.
doi:
http://dx.doi.org/10.1016/j.proeng.2012.07.284
Kato, Y. (2010, 25-28 Jan. 2010). Splish: A Visual Programming Environment for
Arduino to Accelerate Physical Computing Experiences. Paper presented at the
Creating Connecting and Collaborating through Computing (C5), 2010 Eighth
International Conference on.
Kesteren, A. v. (2007). [whatwg] <video> element proposal, Consultado em
15/11/2012,
Disponível
em
http://lists.whatwg.org/pipermail/whatwgwhatwg.org/2007-February/009702.html
Kim, G., & Lee, B. (2011, 6-8 Sept. 2011). A study on the interaction globe system
using physical computing. Paper presented at the Consumer Electronics - Berlin
(ICCE-Berlin), 2011 IEEE International Conference on.
Lab, C. V. G. o. t. M. A. I., & Hospital, S. P. L. o. B. a. W. s. (1999). Projeto sobre
cirurgia guiada por imagem: A colaboração entre o MIT AI Lab e Brigham and
Women Laboratório de Planejamento Cirúrgico, Consultado em 07/01/2013,
Disponível
em
http://www.ai.mit.edu/projects/medicalvision/surgery/surgical_navigation.html
Labour, D. o. (2007). Health Bulletin - Physical Hazards Fact sheet - Thermal Comfort
Project,
Consultado
em
31/01/2013,
Disponível
em
http://www.osh.dol.govt.nz/publications/series/hb-21-thermalcomfort.html
Lanier, J. (1984). Visual Programming Languages. Scientific American, cover and
accompanying description, 8.
Lawson, B., & Sharp, R. (2010). Introducing HTML5: New Riders.
Lee, J. C. (2008). Interaction Techniques Using The Wii Remote
Limited, R. (2013). Raspberry Pi, Consultado em 21/01/2013, Disponível em
http://pt.rsonline.com/web/generalDisplay.html?id=raspberrypi&cm_mmc=OfflineReferral-_-Electronics-_-RaspberryPi-201203-_-World-Selector-Page
Lopes, R. A., & Cardoso, A. (2012). Um Sistema de Realidade Aumentada Associado a
Dispositivos Móveis para Auxiliar o Preparo, Treinamento e Administração de
Medicamentos
Lubbers, P., Salim, F., & Albers, B. (2011). Pro HTML5 Programming: Apress.
Lyons, D. (2010). ANDROID INVASION. (Cover story). [Article]. Newsweek,
156(15), 42-49.
Macedo, D. V. d., & Rodrigues, M. A. F. (2011). Experiences with rapid mobile game
development using unity engine. Comput. Entertain., 9(3), 1-12. doi:
10.1145/2027456.2027460
Mahtab Hossain, A. K. M., Nguyen Van, H., & Soh, W.-S. (2010). Utilization of user
feedback in indoor positioning system. Pervasive and Mobile Computing, 6(4),
467-481. doi: http://dx.doi.org/10.1016/j.pmcj.2010.04.003
Marks, R. (2007). Apresentamos a PlayStation Eye, Consultado em 08/01/2013,
Disponível
em
http://pt.playstation.com/ps3/news/articles/detail/item85718/Apresentamos-aPlayStation-Eye/
103
Matthews, J. (2008). How to make a Physical Gmail Notifier, Consultado em
23/01/2013, Disponível em http://j4mie.org/blog/how-to-make-a-physicalgmail-notifier/
McDaniel, A. (2011). HTML5: Your visual blueprint for designing rich Web pages and
applications: Wiley.
Mellis, D. A., Banzi, M., Cuartielles, D., & Igoe, T. (2007). Arduino: An Open
Electronics Prototyping Platform. Paper presented at the ACM Conference on
Human Factors in Computing Systems, San Jose, USA.
Melo, W. D. A., Souza, A. d. N., & Silva, D. C. d. (2012). UTILIZAÇÃO DO
PROGRAMA ADJUST EM AJUSTAMENTO DE TRIANGULAÇÕES E
TRILATERAÇÕES. Paper presented at the IV Simpósio Brasileiro de Ciências
Geodésicas e Tecnologias da Geoinformação, Recife - PE, Brasil.
http://www.ufpe.br/cgtg/SIMGEOIV/CD/artigos/GEODESIA/175_3.pdf
Mendez, D., Labrador, M., & Ramachandran, K. (2013). Data interpolation for
participatory sensing systems. Pervasive and Mobile Computing, 9(1), 132-148.
doi: http://dx.doi.org/10.1016/j.pmcj.2012.11.001
Milgram, P., Takemura, H., Utsumi, A., & Kishin, F. (1994). Augmented Reality: A
class of displays on the reality-virtuality continuum. Telemanipulator and
Telepresence Technologies, 2351.
Morrison, A., Mulloni, A., Lemmelä, S., Oulasvirta, A., Jacucci, G., Peltonen, P., . . .
Regenbrecht, H. (2011). Collaborative use of mobile augmented reality with
paper
maps.
Computers
&
Graphics,
35(4),
789-799.
doi:
http://dx.doi.org/10.1016/j.cag.2011.04.009
Nee, A. Y. C., Ong, S. K., Chryssolouris, G., & Mourtzis, D. (2012). Augmented reality
applications in design and manufacturing. CIRP Annals - Manufacturing
Technology, 61(2), 657-679. doi: http://dx.doi.org/10.1016/j.cirp.2012.05.010
Ni, L. M., Yunhao, L., Yiu Cho, L., & Patil, A. P. (2003, 23-26 March 2003).
LANDMARC: indoor location sensing using active RFID. Paper presented at the
Pervasive Computing and Communications, 2003. (PerCom 2003). Proceedings
of the First IEEE International Conference on.
O'Sullivan, D., & Igoe, T. (2004). Physical Computing: Sensing and Controlling the
Physical World with Computers: Course Technology Ptr.
Obst, B., & Tröller, L. (2009). Augmented Reality. Paper presented at the Innovations
Forum,
Humboldt-Universität,
Berlin.
http://wiki.informatik.huberlin.de/nomads/images/9/96/Augmented_Reality.pdf
Packer, R., & Jordan, K. (2002). Multimedia: From Wagner to Virtual Reality: Norton.
Payet, É., & Spoto, F. (2012). Static analysis of Android programs. Information and
Software
Technology,
54(11),
1192-1201.
doi:
http://dx.doi.org/10.1016/j.infsof.2012.05.003
Pfaffenberger, B., Schafer, S. M., White, C., & Karow, B. (2004). HTML, XHTML, and
CSS Bible (3ª ed.). Indianapolis, Indiana, USA.
Pi, R. (2011). Rapsberry Pi Model B, Consultado em 20/02/2013, Disponível em
http://www.raspberrypi.org/wp-content/uploads/2011/07/RaspiModelB1024x902.png
Pilgrim, M. (2010). HTML5: Up and Running: O'Reilly Media.
Priyantha, N. B., Chakraborty, A., & Balakrishnan, H. (2000). The Cricket locationsupport system. Paper presented at the Proceedings of the 6th annual
international conference on Mobile computing and networking, Boston,
Massachusetts, USA.
104
Qualcomm Technologies, I. (2013a). Build your Vision with Vuforia, Consultado em
04/06/2013, Disponível em https://developer.vuforia.com
Qualcomm Technologies, I. (2013b). Vuforia SDK Architecture, Consultado em
04/06/2013, Disponível em https://developer.vuforia.com/resources/devguide/vuforia-ar-architecture
Rawi, M. I. M., & Al-Anbuky, A. (2011). Development of Intelligent Wireless Sensor
Networks for Human Comfort Index Measurement. Procedia Computer Science,
5(0), 232-239. doi: http://dx.doi.org/10.1016/j.procs.2011.07.031
Razavi, S. N., & Moselhi, O. (2012). GPS-less indoor construction location sensing.
Automation
in
Construction,
28(0),
128-136.
doi:
http://dx.doi.org/10.1016/j.autcon.2012.05.015
Rekimoto, J. (1998, 15-17 Jul 1998). Matrix: a realtime object identification and
registration method for augmented reality. Paper presented at the Computer
Human Interaction, 1998. Proceedings. 3rd Asia Pacific.
Ribeiro, M. W. S., & Zorzal, E. R. (2011). Realidade Virtual e Aumentada: Aplicações
e Tendências. Paper presented at the XIII Simpósio de Realidade Virtual e
Aumentada, Uberlândia-MG - Brasil.
Rita, P., & Oliveira, C. (2006). O Marketing no negócio electrónico. Porto, Portugal.
Rogers, R., Lombardo, J., Mednieks, Z., & Meike, B. (2009). Android Application
Development: Programming with the Google SDK: O'Reilly Media,
Incorporated.
Romano, S. M. V. (2010). Realidade Aumentada Aplicada a Medicina.
Sa, W., Zhengli, M., Changhai, Z., Huili, G., Shanshan, L., & Beibei, C. (2010, 18-20
June 2010). A new method of virtual reality based on Unity3D. Paper presented
at the Geoinformatics, 2010 18th International Conference on.
Sanchez, A., de Castro, A., Elvira, S., Glez-de-Rivera, G., & Garrido, J. (2012).
Autonomous indoor ultrasonic positioning system based on a low-cost
conditioning
circuit.
Measurement,
45(3),
276-283.
doi:
http://dx.doi.org/10.1016/j.measurement.2011.12.002
Sarik, J., & Kymissis, I. (2010, 27-30 Oct. 2010). Lab kits using the Arduino
prototyping platform. Paper presented at the Frontiers in Education Conference
(FIE), 2010 IEEE.
Satorius, M. (2012). Alto - Arduino Parking Assistant, Consultado em 30/01/2013,
Disponível em http://blog.mattsatorius.com/technology/alto-arduino-parkingassistant/
Schweinzer, H., & Kaniak, G. (2010). Ultrasonic device localization and its potential
for wireless sensor network security. Control Engineering Practice, 18(8), 852862. doi: http://dx.doi.org/10.1016/j.conengprac.2008.12.007
Scott, D. M. (2010). Layar on the Mashup. EContent, 33(5), 40.
Silva, R., Carvalho, P., Sousa, P., & Neves, P. (2011). Enabling Heterogeneous
Mobility in Android Devices. Mobile Networks and Applications, 16(4), 518528. doi: 10.1007/s11036-011-0322-6
Sinclair, P. (2001). ARToolKit, Consultado em 09/01/2013, Disponível em
http://www.metade.org/research/phd/artoolkit/
Southampton, U. d. (2012). Steps to make a Raspberry Pi Supercomputer, Consultado
em 22/01/2013, Disponível em http://www.southampton.ac.uk/~sjc/raspberrypi/
Stats, S. G. (2013). Top 8 Mobile Operating Systems from Sept 2012 to Sept 2013,
Consultado
em
21/10/2013,
Disponível
em
http://gs.statcounter.com/#mobile_os-ww-monthly-201209-201309
105
Tesoriero, R., Tebar, R., Gallud, J. A., Lozano, M. D., & Penichet, V. M. R. (2010).
Improving location awareness in indoor spaces using RFID technology. Expert
Systems
with
Applications,
37(1),
894-898.
doi:
http://dx.doi.org/10.1016/j.eswa.2009.05.062
Thompson, D. (2008). Maya + Python + Arduino + Servo (Part 1), Consultado em
23/01/2013, Disponível em http://danthompsonsblog.blogspot.pt/2008/08/mayapython-arduino-servo.html
Tori, R., Kirner, C., & Siscoutto, R. A. (2006). Fundamentos e tecnologia de realidade
virtual e aumentada: Editora SBC.
Tróia, P. (2013, Janeiro 2013). Raspberry Pi. PC Guia, 66-69.
Vallino, J. R. (1998). Interactive Augmented Reality. PhD Thesis, University of
Rochester, Rochester, New York, USA.
Varshavsky, A., de Lara, E., Hightower, J., LaMarca, A., & Otsason, V. (2007). GSM
indoor localization. Pervasive and Mobile Computing, 3(6), 698-720. doi:
http://dx.doi.org/10.1016/j.pmcj.2007.07.004
Vedor, L. (2012). Acesso à Internet com dispositivos móveis duplicou desde 2010,
Consultado
em
15/10/2012,
Disponível
em
http://pcguia.sapo.pt/2012/05/11/acesso-a-internet-com-dispositivos-moveisduplicou-desde-2010/
Vodafone. (2012). Praia em Directo, Consultado em 13/12/2012, Disponível em
http://www.vodafone.pt/main/A+Vodafone/PT/Fundacao/ProjectosIniciativas/pr
aia_directo
W3C. (1997). World Wide Web Consortium Publishes Public Draft of HTML 4.0,
Consultado em 02/11/2012, Disponível em (http://www.w3.org/Press/HTML4)
W3C. (1999). HTML 4.01 Specification, Consultado em 01/11/2012, Disponível em
http://www.w3.org/TR/REC-html40/
W3C. (2007). HTML Design Principles, Consultado, 08/11/2012, Disponível em
http://www.w3.org/TR/html-design-principles/
Wagner, D., & Schmalstieg, D. (2007, February 2007). ARToolKitPlus for Pose
Tracking on Mobile Devices. Paper presented at the 12th Computer Vision
Winter Workshop, Sankt Lambrecht, Austria.
Weinschrott, H., Du, x, rr, F., & Rothermel, K. (2010, 8-12 Nov. 2010). StreamShaper:
Coordination algorithms for participatory mobile urban sensing. Paper
presented at the Mobile Adhoc and Sensor Systems (MASS), 2010 IEEE 7th
International Conference on.
Wenfeng, H., & Xin, Z. (2012, 23-25 March 2012). A Semiautomatic Control
Technique for Machinima Virtual Camera. Paper presented at the Computer
Science and Electronics Engineering (ICCSEE), 2012 International Conference
on.
Weng, Y.-H., Sun, F.-S., & Grigsby, J. D. (2012). GeoTools: An android phone
application in geology. Computers & Geosciences, 44(0), 24-30. doi:
http://dx.doi.org/10.1016/j.cageo.2012.02.027
Williams, E. D., & Matthews, H. S. (2007, 7-10 May 2007). Scoping the potential of
monitoring and control technologies to reduce energy use in homes. Paper
presented at the Electronics & the Environment, Proceedings of the 2007 IEEE
International Symposium on.
Winokur, D. (2011). Flash to Focus on PC Browsing and Mobile Apps; Adobe to More
Aggressively Contribute to HTML5, Consultado em 05/12/2012, Disponível em
http://blogs.adobe.com/conversations/2011/11/flash-focus.html
106
Woodley, M. S. (2005). DCMI Glossary, Consultado em 02/11/2012, Disponível em
http://dublincore.org/documents/usageguide/glossary.shtml
Wuang, Y.-P., Chiang, C.-S., Su, C.-Y., & Wang, C.-C. (2011). Effectiveness of virtual
reality using Wii gaming technology in children with Down syndrome. Research
in
Developmental
Disabilities,
32(1),
312-321.
doi:
http://dx.doi.org/10.1016/j.ridd.2010.10.002
107