NOTIFICACIONES Y PRECISIÓN PARA
APLICACIONES DE REALIDAD AUMENTADA BASADAS EN
GPS PARA UNITY 3D
TÍTULO DEL TFG: Notificaciones y precisión para aplicaciones de Realidad Aumentada basadas en GPS para Unity 3D
TITULACIÓN: Grado en Ingeniería de Sistemas de Telecomunicaciones AUTOR: Camilo Torrón Sosa
DIRECTOR: María Dolores Royo Vallés FECHA: 4 de Julio de 2019
basadas en GPS para Unity 3D Autor: Camilo Torrón Sosa
Director: María Dolores Royo Vallés Fecha: 4 de Julio de 2019
Resumen
El objetivo de este trabajo es dar solución a las limitaciones que existen en Unity para realidad aplicaciones de realidad aumentada basadas en geolocalización.
En primer lugar, se estudian los fundamentos de la realidad aumentada.
En esta primera parte se explica en que consiste este tipo de aplicaciones, que evolución histórica ha tenido, que perspectiva económica tiene y las opciones que existen para desarrollarlas.
En segundo lugar, se presentan las limitaciones de Unity para aplicaciones de realidad aumentada basadas en geolocalización.
Respecto a la obtención de datos de localización, se estudian 4 alternativas a la que Unity ofrece en 3 situaciones diferentes con tal de determinar cuál es la mejor opción en cada escenario.
Después, se ha observado el interés para este tipo de aplicaciones de que el usuario no tenga que estar interactuando con la aplicación en primer plano, pudiendo la misma notificarle cuando haya llegado un punto de interés. Esto no lo ofrece Unity por lo que se busca propone una solución.
Por último, se pretende proporcionar estas soluciones propuestas a una aplicación Unity mediante plug-in.
Unity 3D
Author: Camilo Torrón Sosa
Director: María Dolores Royo Vallés Date: July, 4th 2019
Overview
The objective of this assessment is to solve the existing limitations in Unity development for location based augmented reality applications.
Firstly, fundamentals of augmented reality will be studied. The first chapter talks about what augmented reality applications are, its historical evolution, how the experts expect this technology will evolve and which alternatives are on the market to develop this kind of applications.
Secondly, Unity limitations for location based augmented reality applications will be explained. Regarding to obtaining location data, 4 alternatives to the Unity option will be studied in 3 different situations.
The objective of this study is to determine which is the most accurate option available in every scenario.
After that, the interest of allowing the user don’t have to interact with the application in foreground and have notifications when arriving to a specific point of interest have been observed. This is not provided by Unity, so a solution will be proposed.
Finally, is it intended to provide these proposed solutions to a Unity application using a plug-in.
INTRODUCCIÓN... 8
REALIDAD AUMENTADA ... 9
1.1. ¿Qué es? ... 9
1.2. Evolución de la realidad aumentada ... 11
1.3. Oportunidades y perspectivas RA ... 13
1.4. Opciones de desarrollo ... 16
UNITY VS ANDROID PARA RA... 18
2.1. Localización ... 18
2.1.1. Opciones de Localización ... 18
2.1.2. Localización en Unity ... 20
2.1.3. Localización con Network provider o GPS provider ... 21
2.1.4. Localización con Fused provider (GoogleAPI) ... 23
2.1.5. ¿Cuál es el mejor proveedor? ... 26
2.2. Listeners ... 32
2.2.1. ¿Qué es un Listener? ... 32
2.2.2. Notificación en un listener ... 32
2.3. Plug-in ... 35
2.3.1. ¿Qué es un plug-in/librería? ... 35
2.3.2. ¿Cómo se programa un plug-in? ... 35
2.4. Conclusiones ... 38
2.5. Referencias ... 39
Fig. 1.1. Sistema de realidad aumentada general de Takehiro Tawara...8
Fig. 1.2. Gráfico generado a partir de los informes Hype Cycle de Gartner……….….11
Fig. 1.3. Mercado de realidad aumentada y realidad virtual por ShanhongLiu………....13
Fig. 2.1. Prueba 1: Entorno con baja cobertura……….………...….25
Fig. 2.2. Prueba 2: Entorno con cobertura media……….27
Fig. 2.3. Prueba 3: Entorno con cobertura alta……….…28
Fig. 2.4. Notificación cerca de la Sagrada Familia……….………..……....32
ÍNDICE DE TABLAS
Tabla 2.1. Resultados Prueba 1……...………..28 Tabla 2.2. Resultados Prueba 2……….…30 Tabla 2.3. Resultados Prueba 3………...………..31
La Realidad Aumentada es una de las tecnologías que mejores perspectivas tiene en los últimos años. Sin embargo, aún no ha conseguido implantarse en el mercado de una manera sólida.
Hasta ahora, el sector se centraba en desarrollar dispositivos, como gafas, únicamente dedicados a esta tecnología, pero la aceptación por parte de los usuarios no fue la deseada. Este concepto ya pasado a un segundo plano ya en la actualidad se ha cambiado el foco al desarrollo de aplicaciones de RA para teléfonos inteligentes.
En este momento, los expertos coinciden en que se da el contexto idóneo para que esta tecnología despegue finalmente. La popularización de smartphones que poseen una capacidad de procesado alta, incorporan sensores GPS, acelerómetro, giroscopio, etc., unido a la implantación del 5G, han hecho que las empresas dediquen grandes recursos en aplicaciones de Realidad Aumentada.
Se prevé que el mercado de RA aumente su volumen de manera exponencial en los próximos años.
La plataforma más popular y que mejores posibilidades nos ofrece para RA es Unity, sin embargo, existen algunas limitaciones. Las aplicaciones de realidad aumentada basadas en GPS no tienen la experiencia idónea por culpa, principalmente de la falta de precisión de los datos de GPS de Unity.
En este trabajo se pretende dar solución a estas limitaciones estudiando las posibilidades que Android ofrece si mejoran las que proporciona Unity estudiando su comportamiento en diversos casos.
REALIDAD AUMENTADA
1.1. ¿Qué es?
La realidad aumentada consiste en incluir en tiempo real elementos virtuales dentro de un espacio físico real. Estos elementos pueden ser de diferentes tipos y estimular cualquiera de nuestros sentidos. Añadir objetos visuales y sonidos son las prácticas más habituales en este tipo de tecnología. Mediante un dispositivo (móvil, tableta, gafas, etc.), el usuario puede observar elementos virtuales como imágenes 3D, textos, indicaciones sobre el mundo real o sonidos añadidos o reemplazados a los existentes en el mundo real.
Un sistema de realidad aumentada se compone de diferentes sensores (receptores GPS, acelerómetros, giroscopios, cámaras) y una o diversas pantallas. El hecho de que los smartphones y tabletas actuales dispongan de estos componentes y de la capacidad de procesado y almacenamiento para gestionar todos estos elementos y datos, hace que la realidad aumentada se pueda extender y popularizar más fácilmente que si los usuarios tuvieran que adquirir un dispositivo específico para este cometido.
Además, los usuarios pueden interactuar con estos objetos virtuales abriéndose así un gran abanico de posibilidades para los desarrolladores.
Un sistema de realidad aumentada se compone de cinco módulos claramente diferenciados:
1. El mundo real: el espacio físico donde se sitúan diferentes objetos y sobre al que se le desea proyectar cierto contenido digital.
2. Un elemento o conjunto de elementos que capture información del entorno en el cuál se encuentra el usuario. Estos pueden ser una cámara, un micrófono, un acelerómetro, etc.
3. Una unidad de procesado. Actualmente el hecho de que la tecnología nos permita tener grandes capacidades de procesado en relativamente poco espacio nos permite implementar este tipo de aplicaciones de manera más sencilla. Esta unidad puede ser un teléfono móvil, un ordenador o una tablet.
4. Un elemento sobre el cual proyectar la fusión de elementos reales y virtuales. Esto puede ser un display, un altavoz, un elemento con vibración…
5. Un elemento activador de la realidad aumentada. Este elemento dependerá del tipo de aplicación de RA. Más adelante trataré los diferentes tipos de aplicaciones de RA que existen. Estos elementos pueden ser desde una imagen QR, unas coordenadas, una superficie, un sonido, o una acción del usuario.
En la figura 1.1. se pueden ver los elementos que componen un sistema de realidad aumentada:
Fig. 1.1. Sistema de realidad aumentada general de Takehiro Tawara
En primer lugar, exiten objetos reales que son detectados por algún tipo de sensor. En este caso, dado que es una aplicación RA basada en imagen, se trata de una cámara que envía estas imágenes a un procesador. Este procesador añade el objeto virtual a los objetos reales y los representa en una pantalla.
Como se ha comentado antes, la tecnología actual permite integrar el conjunto sensores-procesador-display en el mismo dispositivo.
Existen dos tipos de aplicaciones de realidad aumentada para móviles:
a) Basadas en procesado de imagen: Se utiliza cualquier elemento del entorno para colocar el contenido virtual. Mediante procesado de imagen se puede detectar la cara de una persona, un edificio, un código QR, o cualquier objeto y situar sobre él el contenido que se desee. Un ejemplo de estas aplicaciones son los filtros de Snapchat que detectan la cara de la persona que los utiliza y agrega sobre ella diferentes efectos.
b) Basadas en geolocalización: A través de los sensores GPS y brújula digital, se puede determinar la localización y orientación de un usuario. De esta manera se puede superponer elementos en determinados puntos de interés como puedan ser restaurantes italianos, puntos turísticos de una ciudad o tiendas de nuestro interés.
Además, existe otro tipo de aplicaciones de RA pero generalmente no se integran en teléfonos móviles sino que se utilizan en dispositivos específicamente dedicados a este tipo de apps como las gafas HoloLens de Microsoft o Google Glass de Google. Estas aplicaciones son las basadas en generación de mapas:
El sistema es capaz de detectar distancias y espacios físicos que ocupan los objetos reales con lo que genera un mapa. A partir de este mapa se añade el contenido virtual. Se suele utilizar en aplicaciones como guiar a través de un edificio.
1.2. Evolución de la realidad aumentada
El primer proyecto que se puede catalogar como realidad aumentada, se remonta a 1950 donde el cineasta y considerado padre de la RA y de la realidad virtual Morton Heilig, escribió sobre un cine en el cuál se pudieran complementar las imágenes de una acompañar película a la estimulación de sentidos como las vista, el olfato, el taco y el oído. Años más tarde, en 1962 presentó el Sensorama.
Este dispositivo combinaba imágenes, añadía sonido envolvente, hacia vibrar el asiento y creaba viento lanzando aire al espectador para crear entre otras, la sensación de ir montado en una bicicleta por las calles de Brooklyn.
En 1968, Ivan Sutherland creó el Head Mounted Display para realidad virtual y realidad aumentada. Este dispositivo era muy grande y pesada, de hecho, debía colgase del techo para que poder utilizarlo. Si bien era muy primitivo en cuanto a interfaz de usuario y realismo, se considera el primer dispositivo de realidad aumentada propiamente dicho.
A finales de los 80 se popularizo el término Realidad Virtual por Jaron Lanier, cuya compañía fundada por él creo los primeros guantes y anteojos de Realidad Virtual. El termino Realidad Aumentada fue introducido por el investigador Tom Caudell en Boeing, en 1992. Caudell fue contratado para encontrar una alternativa a los tediosos tableros de configuración de cables que utilizan los trabajadores. Salio con la idea de anteojos especiales y tableros virtuales sobre tableros reales genéricos, es así que se le 2 ocurrió que estaba “aumentando” la realidad del usuario. El término Realidad Aumentada fue dado al público en un paper en 1992.
En 1990, Thomas Caudell creó el término Realidad Aumentada. Caudell era un científico que trabajaba para Boeing. Buscando la manera de ayudar a sus trabajadores a ensamblar largos grupos de cables en el avión 777, se le ocurrió la idea de dotar a los trabajadores de pantallas transparentes que pudieran
guiarlos mediante la superposición de líneas evitando así que tuvieran que consultar constantemente la hoja de instrucciones. Este proyecto finalmente no tuvo éxito ya que la tecnología del momento no les permitió que cumpliera con los objetivos que se propusieron.
En 1992, Louis Rosenberg desarrolló “Virtual Fixtures”, el primer sistema funcional de RA. Este sistema fue creado para las Fuerzas Aéreas de EEUU y consistía en un exoesqueleto que se implantaba de cintura hacia arriba. Permitía controlar, siendo guiado y aconsejado virtualmente, maquinaria funcionando remotamente.
A medida que avanzaba la década de los 90, fueron apareciendo diversas aplicaciones para RA. En 1994 se produjo la primera obra de teatro con RA, donde los acróbatas bailaban alrededor de objetos virtuales situados en un escenario real. También se utilizó RA por primera vez en televisión en una retrasmisión de futbol americano en 1998. Al año siguiente NASA implantó en su aeronave X-38 un sistema que sobre impresionaba datos de ruta para mejorar su navegación.
En el año 2000 se creó la primera herramienta para poder desarrollar realidad aumentada. El ARToolKit usa procesado de imagen para incluir objetos virtuales en un video capturado por la cámara.
Uno de los últimos hitos se produjo en 2014 con el lanzamiento y puesta a la venta por parte de Google de las gafas “Google Glass”. Estas gafas permiten mostrar la información de un teléfono inteligente sin que el usuario tenga que interactuar con el dispositivo móvil.
En 2016 se lanzó Pokemon Go, una aplicación basada en geolocalización y que actualmente ha llegado prácticamente a los doce millones de descargas y ha sido la aplicación de RA con más éxito hasta la actualidad.
Desde entonces la realidad aumentada ha ido integrándose principalmente en dispositivos móviles inteligentes. El hecho de que actualmente estén muy extendidos los teléfonos que incluyen todos los elementos necesarios para implementar aplicaciones de RA además de la aparición de nuevas herramientas para desarrolladores que facilitan y popularizan la programación de dichas aplicaciones, hacen prever el crecimiento de mercado RA.
1.3. Oportunidades y perspectivas RA
Para analizar las perspectivas de la realidad aumentada conviene consultar dos de las fuentes más importantes y consultadas de datos a nivel tecnológico y de negocio. En concreto, estas son Gartner(1) y Statista. Gartner sitúa anualmente a las 30 tecnologías con mejores perspectivas en su gráfico Hype Cycle. Por otro lado, Statista proporciona la evolución del volumen del mercado.
La realidad aumentada apareció por primera vez en el Hype Cycle de Gartner sobre tecnologías emergentes en 2005. Por aquel entonces se preveía de 5 a 10 años su plateau de productividad. A día de hoy ese plateau de productividad aún no se ha alcanzado.
La evolución a lo largo de estos años no ha sido tan positiva como se esperaba.
Si bien inicialmente era una tecnología que despertó muchas expectativas, con los años se ha ido estancando. Esta ha sido la evolución de la tecnología RA para Gartner:
Fig. 1.2. Gráfico generado a partir de los informes Hype Cycle de Gartner
(1)Gartner, Inc. (NYSE: IT), es la companía líder en investigación y consultoría a nivel mundial y miembro de S&P 500. Se dedica a aconsejar y proveer de herramientas a los líderes de negocio para tomar mejores decisiones estratégicas sobre sus proyectos. Más de 15000 organizaciones en más de 100 países trabajan con Gartner en diversos ámbitos de la empresa e industria.
El gráfico 1.2. se ha generado extrayendo los datos de realidad aumentada desde su aparición en el Hype Cycle(2) en 2005 hasta el último informe publicado.
Se pueden observar las distintas fases por las que ha pasado la tecnología AR.
Apareció en 2005 con unas expectativas moderadas que crecieron para 2006.
Sin embargo, en 2006 se creía que se alcanzaría la mejor productividad en un plazo mayor que en 2005. En 2007 AR no apareció como una de las 30 tecnologías con más posibilidades para Gartner. En los años 2008, 2009, 2010 y 2011, las expectativas crecieron hasta su máximo, pero todavía se preveía que en plazo de 5 a 10 años no alcanzaría su mejor productividad. A partir de ahí, las expectativas fueron cayendo llegando en 2018 a su mínimo.
En este punto se espera que la convergencia de las posibilidades tecnológicas, la aceptación de los usuarios y la inversión de las empresas, hagan que la realidad aumentada esté lista para crecer.
Existen varios factores que invitan al optimismo en el sector como la implantación del 5G, la inversión de grandes empresas y la aceptación de los usuarios. Según el artículo publicado el 1 de abril de 2019 de Gartner, “100 millones de consumidores comprarán en tiendas online o físicas con Realidad Aumentada en 2020”. Esta es una aplicación que se prevé que tenga muy buena aceptación y que cambiará totalmente la experiencia del usuario en las compras. Empresas como Alibaba, Tesco, Adidas o eBay Australia y están implementando tanto realidad aumentada como virtual en sus aplicaciones.
La aparición del 5G será un revulsivo para acelerar la incorporación de AR y VR.
Esta tecnología permite disminuir el tiempo de descargas de los objetos y mejorar la experiencia en tiempo real entre otros casos.
Además, Jeremy Dalton, Jefe de VR/AR en PwC, explicó para el medio de comunicación especializado en tecnología Verdict, dos factores que están ayudando al que AR dé el salto que se espera de esta tecnología. El primero es que tanto Google como Apple, que poseen la gran mayoría del mercado de los smartphones, están invirtiendo muchos recursos en AR y están integrando AR en sus dispositivos.
En segundo lugar, explica que el hecho de que aparezcan aplicaciones AR, hace que los usuarios se sientan más habituados a utilizarlas por lo que se adoptan más fácilmente cosa que las empresas ven como una mejor oportunidad para invertir en ella.
(2)Hype Cycle es una representación gráfica de estado del ciclo de vida de una tecnología que va desde su concepción hasta la adopción por parte del gran público.
Según Statista(3), el mercado del binomio RA y RV aumentará exponencialmente durante los próximos años. Sectores como la sanidad, la ingeniería, las ventas además de la industria del entretenimiento (juegos, redes sociales, etc.) aumentarán la popularidad de estas tecnologías. El gráfico 1.3. muestra la previsión del mercado según esta fuente. El mercado de RA y RV pasaría de 8.9 billones de dólares a los 160 billones que se prevén para 2023.
Fig. 1.3. Mercado de realidad aumentada y realidad virtual por Shanhong Liu.
(3)Statista es un portal de estadísticas online que analiza datos procedentes de estudios de mercado, estudios de opinión e indicadores económicos. Es la base de datos más popular y exitosa a nivel mundial. Cuenta con más de 1 millón de estadísticas sobre alrededor de 80000 temas procedentes de 22500 fuentes.
1.4. Opciones de desarrollo
Para desarrollar una aplicación RA para Android se presentas dos plataformas que son compatibles con este sistema operativo: Unity y Android nativo. Una vez se ha elegido la plataforma de desarrollo, existen distintas bibliotecas AR para facilitar el desarrollo. A continuación, se presentan las distintas alternativas posibles.
a) Unity: Es la plataforma más popular en la industria del desarrollo de videojuegos. Es totalmente libre y gratuita. Proporciona todos los elementos necesarios para desarrollar aplicaciones de realidad aumentada basadas en geolocalización para móviles como el acceso a los sensores GPS, giroscopio, acelerómetro, etc.
b) Vuforia: Proporciona reconocimiento de texto e imágenes tanto en 2D como en 3D, detección rápida y simultánea de distintos targets (objetivos que disparan algún objeto virtual) y un rastreo robusto. Es compatible tanto en Unity como Android nativo.
c) ARCore: Es la herramienta creada por Google para desarrollar aplicaciones RA. Tienes funcionalidades muy avanzadas a nivel visual como la percepción de las luces o la detección de texturas y superficies.
Contiene colecciones de objetos virtuales listos para ser añadidos a la aplicación. Es compatible con Android, pero su principal inconveniente es que actualmente solo lo soportan un número muy limitado de dispositivos lo cual hace que nivel industrial aún no sea interesante.
d) ARToolKit: Es un kit de herramientas totalmente libre y gratuito.
Únicamente tiene detección 2D por lo que limita bastante la experiencia proporcionada al usuario. Es compatible con todas las plataformas. Se suele utilizar para aplicaciones sencillas basadas en detección de imágenes en 2D como códigos QR.
e) WikiTude: es una de las opciones más completas incluyendo reconocimiento 2D y 3D, escaneo de objetos reales, representación y animación de objetos 3D y localización. Es compatible con todas las plataformas incluso con Google Glass y Smart glasses. Su desventaja es que no es gratuita y su precio es considerable.
f) KudanAR: Además del rastreo y reconocimiento de objetos reales, incorpora el mapeo de elementos en base a la localización del usuario.
Además, es capaz de generar puntos de referencia como bordes, esquinas o texturas para colorar los objetos virtuales. Permite también escanear objetos reales e importarlos a modelos en 3D. Es compatible tanto para Unity como para Android nativo.
Cada una de estas bibliotecas presenta ventajas e inconvenientes según la aplicación que se desea programar. Unas están orientadas más al aspecto visual de la aplicación, mientras que otras permiten desarrollar aplicaciones cuya experiencia se presenta más realista para usuario. Claro está que no todas las opciones son gratuitas y las opciones que más posibilidades proporcionan también son las que tienen mayor precio.
En la realización de este trabajo se ha escogido Unity por los siguientes motivos:
- Es una herramienta totalmente libre y libre de costes.
- No se depende del proveedor del servicio para desarrollar la aplicación con lo que las posibilidades de desarrollo aumentan.
- Los datos propios de la aplicación se pueden almacenar en local y no se tienen que compartir con el proveedor del servicio.
- Es una plataforma muy extendida con lo que existe una comunidad en la que apoyarse para el desarrollo.
UNITY VS ANDROID PARA RA
Llegados a este punto se propone determinar cuál de las dos plataformas es más adecuada para desarrollar aplicaciones de realidad aumentada basadas en geolocalización. El elemento más crítico para este tipo de aplicaciones es obtener el posicionamiento más fiable y preciso posible. Tanto Unity como Android nativo proporcionan diversas opciones. Durante este capítulo se estudiarán estas opciones y se realizaran pruebas reales con tal de determinar cuál es la mejor opción.
Otro elemento que es interesante para este tipo de aplicaciones es el hecho de que el usuario no tenga que estar interactuando con la aplicación en primer plano, sino que se le avise cuando llegue a un punto de interés.
En este punto parece que un desarrollador debe decantarse por una opción u otra, pero sería interesante aprovechar las bondades que proporcionen cada una de ellas y conectarlas. Durante este capítulo también se explorará esta opción.
2.1. Localización
Siguiendo el sistema de referencia de permite la ubicación de un punto en la Tierra, una localización viene dada por su latitud y longitud correspondiente. Una vez definido esto, se debe obtener mediante algún método estos valores.
2.1.1. Opciones de Localización
En Unity la información sobre localización viene dada por el struct LocationInfo.
Este struct proporciona tanto la latitud como la longitud además de otros datos como la altitud o la precisión. Ambos parámetros son de tipo float, esto quiere decir, según la guía de C# de Microsoft que se obtiene una precisión de 6 a 9 dígitos y están almacenados en 32bit.
Por otro lado, la información de localización en Android se almacena en la clase Location y con los métodos getLatitude() y getLongitude() se pueden obtener los valores de latitud y longitud. Estos valores están almacenados en un double y están expresados en grados. Un double tiene una precisión de 15-16 dígitos y está almacenado en 64 bits.
Sabiendo esto, se espera que Android proporcione una mayor precisión, en concreto el doble, que tiene el doble de espacio asignado en memoria para guardar el dato.
Generalmente una variable de tipo float se utiliza principalmente en librerías gráficas donde la demanda de potencia de procesado es alta. Sin embargo, el tipo de dato double se suele utilizar para almacenar valores reales con un mayor número de decimales.
En el caso de Android existen 3 proveedores principales que informan de la localización:
1. Network provider: este proveedor sitúa el dispositivo a través de la red de telefonía a la cual se está conectado o bien mediante la red Wi-Fi. Este tipo de servicio tiene un coste energético relativamente bajo, aunque su precisión no suele ser la mejor por lo que es adecuado para aplicaciones donde tener algo de error no sea crítico. Además, funciona tanto en interiores como en exteriores y se obtienen los datos rápidamente.
2. GPS provider: este proveedor recibe la señal de los satélites GPS. Su precisión es más alta que network provider, pero en contrapartida, consume más batería, necesita un tiempo para recibir la señal de los satélites y funciona correctamente en exteriores, ya que en interiores la señal GPS es débil.
3. Fused provider: este tipo de proveedor es el que usa la API de Google.
Combina los proveedores de Network y GPS siguiendo unos criterios de consumo de batería y precisión de cada proveedor. Según la documentación de Android, en la mayoría de casos es el que proporciona un mejor comportamiento de la batería además de la precisión más adecuada. Esto significa que se adapta al entorno y situación dada.
2.1.2. Localización en Unity
Siguiendo la documentación que proporciona Unity, para recibir actualizaciones de localización se debe utilizar el método Start() de la clase LocationService. Al llamar el método Start() se pueden definir dos parámetros. Estos parámetros hacen referencia a la precisión requerida en metros (a menor valor, mayor precisión) y a la distancia de actualización (valor mínimo que debe desplazarse el usuario con tal de cambiar la localización) también en metros. Para la realización de este test se ha escogido la mejor precisión posible. Se debe tener en cuenta que para obtener esta precisión se debe tener el permiso ACCESS_FINE_LOCATION de Android en el archivo Manifest.
Una vez se ha iniciado el método Start(), se empieza a almacenar la última ubicación recibida en la variable lastData del tipo LocationInfo. Como se ha explicado anteriormente, aquí ya se puede acceder a la latitud y longitud. Como se ha explicado anteriormente estas dos variables son de tipo float.
Teniendo esto en cuenta el manual proporciona el siguiente código de ejemplo para este cometido:
using UnityEngine;
using System.Collections;
public class TestLocationService : MonoBehaviour{
IEnumerator Start(){
// Comprobar si el usuario ha habilitado el servicio de localización
if (!Input.location.isEnabledByUser) yield break;
// Empezar las peticiónes de localización Input.location.Start();
// Esperar hasta recibir los primeros datos int maxWait = 20;
while (Input.location.status ==
LocationServiceStatus.Initializing && maxWait > 0){
yield return new WaitForSeconds(1);
maxWait--;}
// Service didn't initialize in 20 seconds if (maxWait < 1){
print("Timed out");
yield break;}
// Connection has failed
if (Input.location.status == LocationServiceStatus.Failed){
print("Unable to determine device location");
yield break;}
else{
// Si el acceso está concedido, la localización se puede mostrar
print("Location: " + Input.location.lastData.latitude +
" " + Input.location.lastData.longitude + " " + Input.location.lastData.altitude + " " +
Input.location.lastData.horizontalAccuracy + " " + Input.location.lastData.timestamp);}
// Stop service if there is no need to query location updates continuously
Input.location.Stop();}}
Se debe notar que hay 3 instrucciones que se utilizan en el ejemplo que pueden ser interesante.
En primer lugar, la propiedad de LocationService isEnabledByUser que es una variable de tipo booleano que indica si el usuario ha habilitado los servicios de localización en el dispositivo.
Después la propiedad de LocationService status que es un objeto de tipo LocationServiceStatus que indica el estado del servicio. Estos pueden ser:
Stopped, Initializing, Running y Failed.
Y por último el método Stop() que simplemente detiene el servicio.
2.1.3. Localización con Network provider o GPS provider
Para programar una aplicación en Android que muestre la información de localización desde Network o desde GPS, el procedimiento es muy similar, solo se deben cambiar 2 parámetros que indican cuál será el proveedor.
Primero se debe dar los permisos en el archivo Manifest para que la aplicación pueda acceder a la localización del teléfono. En este punto existen 2 posibilidades: ACCESS_COARSE_LOCATION o ACCESS_FINE_LOCATION.
En la primera se da permisos para Network provider con lo que no podremos obtener datos de GPS ya que la aplicación se caerá.
En la segunda opción se conceden permisos tanto para un caso como para otro.
Estos permisos se deben incluir en el archivo Manifest de la siguiente manera:
<uses-permission
android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission
android:name="android.permission.ACCESS_FINE_LOCATION" />
Una vez se han registrado los permisos y siguiendo la recomendación de la guía de Android, se deberá preguntar al usuario si concede permiso para consultar la ubicación del dispositivo. Estos permisos se piden de la siguiente manera:
public void solicitaPermiso(){
int permissionCheck = ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION);
if(permissionCheck == PackageManager.PERMISSION_DENIED){
//Solicita el permiso
if(ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.ACCESS_FINE_LOCATION)){
} else {
ActivityCompat.requestPermissions(this,new String[]{
Manifest.permission.ACCESS_COARSE_LOCATION},1);
} } }
Ahora se puede empezar a pedir actualizaciones de localización. Para ello se necesita la clase LocationManager. Esta clase provee acceso a los servicios de localización del sistema.
Después se inicializa el listener de localización a través de la clase LocationListener. Esta clase se una para recibir notificaciones del LocationManager que se ha creado anteriormente cuando la localización ha cambiado. Dentro de este LocationListener existen varios métodos que podemos sobrescribir. El método que interesa para recibir los datos es el onLocationChanger(Location location). A través del objeto location y de sus métodos getLatitude() y getLongitude() se tendrán almacenadas las nuevas coordinadas geográficas del dispositivo.
public void trackingNetwork(){
LocationManager LM = (LocationManager)
this.getSystemService(Context.LOCATION_SERVICE);
if(!LM.isProviderEnabled(LM.NETWORK_PROVIDER)){
Toast.makeText(getApplicationContext(), "Proveedor deshabilitado", Toast.LENGTH_SHORT).show();
}
LocationListener LL = new LocationListener() { @Override
public void onLocationChanged(Location location) {
//En el objeto Location se almacena la ultima localización recibida.
} }
@Override
public void onStatusChanged(String s, int i, Bundle bundle) { }
@Override
public void onProviderEnabled(String s) { Toast.makeText(getApplicationContext(), "Proveedor habilitado",
Toast.LENGTH_SHORT).show();
}
@Override
public void onProviderDisabled(String s) { Toast.makeText(getApplicationContext(), "Proveedor deshabilitado", Toast.LENGTH_SHORT).show();
} };
}
Por último, se precisa registrar el LocationListener en el LocationManager con tal de recibir los datos a través de esta clase. Esto se hace mediante el método de la clase LocationManager requestLocationUpdates(). Este método requiere cómo parámetros el proveedor (NETWORK_PROVIDER o GPS_PROVIDER), el tiempo mínimo entre actualizaciones, la distancia mínima entre localizaciones y el LocationListener por el que recibir las actualizaciones.
//Registrar el listener con el Location Manager para recibir actualizaciones de localizacion
int permissionCheck = ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION);
LM.requestLocationUpdates(LocationManager.NETWORK_PROVIDER ,0,0,LL);
Una vez se tiene este código ya se puede integrar dentro de la aplicación quese utilizará posteriormente para comprobar cuál es el mejor proveedor.
2.1.4. Localización con Fused provider (GoogleAPI)
Como ya se ha explicado previamente, el proveedor Fused es el que utiliza la GoogleAPI y combina diferentes proveedores para determinar la localización.
Esta manera de obtener la posición viene incluida en los servicios de Google Play. Por lo que primeramente se deberá preparar la aplicación para que pueda utilizar estos servicios.
Siguiendo la documentación de Google se debe agregar la siguiente línea en el archivo de build.gradle de la aplicación:
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar']) //noinspection GradleCompatible
implementation 'com.android.support:appcompat-v7:28.0.0-alpha1' implementation 'com.android.support.constraint:constraint-
layout:1.1.3'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.2' androidTestImplementation
'com.android.support.test.espresso:espresso-core:3.0.2' implementation 'com.google.android.gms:play-services- location:16.0.0'
implementation 'com.mapbox.mapboxsdk:mapbox-android-sdk:8.0.0' }
repositories { mavenCentral() }
Android Studio recomendara actualizar a la última versión si es necesario.
Acto seguido, y de la misma manera que en GPS, se debe conceder permisos de localización a la aplicación en el archivo Manifest. (Ver figura anterior).
Después se debe comprobar si el usuario permite a la aplicación acceder a la ubicación del dispositivo. En caso negativo, pedirlo. Este fragmente de código es el que ejecuta esta acción:
if(ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_FINE_LOCATION) !=PackageManager.PERMISSION_GRANTED){
ActivityCompat.requestPermissions(this, new String[]
{Manifest.permission.ACCESS_FINE_LOCATION}, REQUEST_LOCATION_PERMISSION);
} else {
mTrackingLocation = true;
mFusedLocationClient.requestLocationUpdates (getLocationRequest(),
mLocationCallback, null /* Looper */);
}
A partir de aquí, la aplicación ya está preparada para recibir actualizaciones de localización. Para ello se deben utilizar las clases FusedLocationProviderClient, LocationCallback y LocationRequest.
El FusedLocationProviderClient es el que nos permite interactuar con el FusedLocationProvider.
// Initialize the FusedLocationClient.
mFusedLocationClient =
LocationServices.getFusedLocationProviderClient(this);
El LocationCallback se dispara cuando el FusedLocationClient recibe una nueva actualización de posición. A través de su método onLocationResult y del objeto que recibe por parámetro LocatiónResult se puede acceder a dicha información actualizada.
mLocationCallback = new LocationCallback() { @Override
public void onLocationResult(LocationResult locationResult) { if (mTrackingLocation) {
//Acciones que se quieren realizer al recibir una acualización
} }
};
Después se debe definir como son las peticiones que se hacen al proveedor. El objeto que almacena la información de la petición es el LocationRequest. Esta información consiste en el intervalo al que se quiere recibir actualizaciones y la prioridad del proceso en cuestión. Esto se hace mediante la siguiente función:
private LocationRequest getLocationRequest() {
LocationRequest locationRequest = new LocationRequest();
locationRequest.setInterval(1000);
locationRequest.setFastestInterval(1000);
locationRequest.setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY);
return locationRequest;
}
Ahora que ya están definidos los elementos necesarios para hacer peticiones, se puede realizar mediente la siguiente instrucción:
mFusedLocationClient.requestLocationUpdates (getLocationRequest(),
mLocationCallback, null /* Looper */);
En esta instrucción se pide al FusedLocationProviderClient peticiones que se reciben a través del LocationCallback y con las características definidas en el LocationRequest.
Después de este estudio, se puede proceder al siguiente paso del objeto de este trabajo que es determinar cuál es el mejor de los proveedores para obtener la información más precisa y utilizarlas en aplicaciones de realidad aumentada basadas en geolocalización.
2.1.5. ¿Cuál es el mejor proveedor?
Para aplicaciones de realidad aumentada basadas en geolocalización, la precisión es uno de los puntos críticos a la hora de desarrollar la aplicación. Por lo tanto, se debe obtener la información más precisa posible. Según el estudio explicado anteriormente, parece ser que el fused provider de la Google API es el que proporcionara los datos más adecuados.
Con tal de determinar cuál es el mejor proveedor posible empíricamente he seguido el siguiente procedimiento:
1. Programar 3 aplicaciones que obtengan datos de localización para cada uno de los proveedores.
2. Realizar el mismo recorrido en con estas aplicaciones en 3 situaciones.
2.1. Entorno urbano donde la señal satélite sea baja.
2.2. Entorno abierto donde se tenga buena cobertura satelital 2.3. Entorno medio con edificios cercanos.
3. Representar estos datos en un mapa para poder compararlos.
Lo primero que se ha observado es que los dígitos que se obtienen no son los máximos posibles que proporciona tanto la documentación de Unity como la de Android.
En el caso de Unity se han obtenido de 4 a 6 decimales, mientras que en Android nativo de 5 a 7 decimales. Por lo tanto, a priori, los datos proporcionados por Android nativo son del orden de 10 veces más precisos. El hecho de que tenga más decimales puede dar datos más precisos, pero quizás incorrectos. Después de realizar las pruebas se determinará cuál es la mejor opción.
El procedimiento para determinar cuál es la mejor alternativa será realizar el mismo recorrido con las 5 opciones disponibles en 3 entorno diferentes. Después graficar los resultados en un mapa para poder compararlos entre sí. Como este tipo de aplicaciones están pensadas para que las utilice un usuario que se desplace caminando, el experimento se ha realizado de esta manera.
En primer lugar, se ha realizado el recorrido capturando los datos proporcionados por Unity (representados por los puntos negros). Después se ha realizado el mismo recorrido recogiendo los datos proporcionados por Network provider de Android nativo (puntos representados en color azul), seguido del GPS de Android nativo (puntos verdes), Google API con el GPS desactivado (puntos rojos) y por último Google API con el GPS activado (puntos lilas).
Después para cada caso, se ha calculado la distancia del recorrido. Se ha cogido como referencia para el recorrido real la localización de los puntos obtenidos manualmente en GoogleMaps. Una vez obtenido estos puntos se ha calculado
la distancia entre ellos para saber la distancia del recorrido real realizado y poder compararlo con las distancias de los recorridos obtenidos por los sensores GPS.
Por último, se ha calculado el error en porcentaje de la distancia obtenida por cada sensor respecto a la distancia real generada manualmente siguiendo la siguiente fórmula (2.1):
𝐸𝑟𝑟𝑜𝑟 [%] = 100 ∗
𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎 𝑅𝑒𝑎𝑙−𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎 𝑆𝑒𝑛𝑠𝑜𝑟𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎 𝑅𝑒𝑎𝑙
(2.1)
Una vez se ha definido la metodología para realizar los test, se han obtenido los siguientes resultados:
a) Entorno urbano donde la señal satélite sea baja
En esta prueba se ha recorrido una manzana típica de la ciudad de Barcelona que está completamente rodeada por edificios y donde la cobertura GPS es limitada.
Fig. 2.1. Prueba 1: Entorno con baja cobertura.
Se puede observar (figura 2.1.) como Unity da valores que no se acercan a la realidad. Estos errores no han sido puntuales, ya que, al repetir este test en
varias ocasiones, en todos aparecían errores del mismo tipo. Se ha elegido esta iteración como muestra representativa de lo que ocurría. Las dos opciones con GPS activado (puntos verdes y puntos lilas dan lecturas ligeramente incorrectas con errores de incluso más de 10 metros en ciertos puntos. A simple vista, parece ser que Network (puntos azules) y GoogleAPI sin GPS (puntos rojos) son los que mejor se comportan.
Tabla 2.1. Resultados Prueba 1
Distancia real [m]
Distancia Network
[m]
Distancia GPS [m]
Distancia GoogleAPI sin GPS [m]
Distancia GoogleAPI con GPS [m]
442,09335 441,12878 572,63873 449,64664 529,8113
Error 0% 0,21% 29,53% 1,70% 19,84%
En la tabla 2.1 se puede observar que los proveedores que más se ajustan al recorrido en estas condiciones se comportan mejor. Tanto el proveedor de Network, con un error de 0,32%, como GoogleAPI sin GPS, con un error de 1,70%, se comportan de manera similar dando datos fiables al usuario.
Por lo tanto, en estas condiciones, utilizar el sensor GPS no aporta una mejora de precisión en los datos. Sin embargo, utilizar datos de Network de Android nativo o de GoogleAPI elimina los errores entregados por Unity.
b) Entorno medio con edificios cercanos
En esta prueba se ha recorrido un tramo rectangular dentro del parque de la Ciudadela de Barcelona. Tiene edificios, por un lado, aunque a una distancia mayor a 20 metros. Al estar dentro de un parque, hay árboles que podrían limitar la señal GPS, pero en un grado menor que los edificios cercanos de la primera prueba.
Fig. 2.2 Prueba 2: Entorno con cobertura media.
En esta prueba (Fig. 2.2), los datos que en el caso anterior funcionaban mejor (Network provider y GoogleAPI sin GPS), datos totalmente erróneos (datos azules y rojos respectivamente) y que no reflejan en absoluto el recorrido realizado.
Por otro lado, Unity se acerca más a la realidad, pero, al igual que en la prueba 1, hay momentos donde los valores se distancian significativamente de los reales.
Sin embargo, en este caso, al haber una mejor cobertura GPS, tanto GPS provider de Android nativo (puntos verdes) como GoogleAPI con GPS conectado (puntos lilas) proporcionan datos mucho más precisos.
Tabla 2.2. Resultados Prueba 2 Distancia
Real [m]
Distancia Network
[m]
Distancia GPS [m]
Distancia GoogleAPI sin
GPS [m]
Distancia Google API con GPS [m]
179,35443 77,07223 191,18513 132,17804 224,82115
Error 0% 57.02% 6,59% 26,30% 25,35%
De la tabla 2.2, se puede sacar la conclusión de que, en cuanto a distancia, el GPS de Android nativo es el más ajustado. Sin embargo, en la figura 2.2, se puede observar que hay puntos que no son del todo exactos, por lo que también se podría dar por buenos los datos de GoogleAPI con GPS a pesar de que en cuanto a distancia no sean los mejores, visualmente se ajustan al recorrido realizado.
c) Entorno abierto donde se tenga buena cobertura satelital
En esta última prueba, se ha realizado un recorrido totalmente rectilíneo en una zona donde no hay ningún obstáculo que limite la cobertura GPS. Se espera que en este caso el GPS proporcione datos muy fiables en contrapartida con los proveedores que no lo utilizan.
Fig. 2.3 Prueba 3: Entorno con cobertura alta.
Se puede observar en la imagen 2.3. como los puntos azules (Network provider) y rojos (GoogleAPI sin GPS) entregan datos con errores de más de 15 metros para algunos puntos.
Unity se acerca más al recorrido realizado, pero con momentos donde erra hasta 10 metros. Este error puede ser crítico en aplicaciones de realidad aumentada basadas en geolocalización ya que puede suponer la diferencia entre estar en un lado de la calle o en el contrario, por ejemplo.
En el caso de los proveedores que utilizan GPS, muestran unos datos prácticamente totalmente fieles a la realidad. El proveedor GPS de Android nativo (puntos verdes) arroja algunos puntos ligeramente erróneos (menor a 5 metros) en la parte final, por lo que GoogleAPI con GPS es el que mejor se ha comportado a nivel visual en esta prueba.
Tabla 2.3. Resultados Prueba 3 Distancia
real [m]
Distancia Network
[m]
Distancia GPS [m]
Distancia GoogleAPI sin
GPS [m]
Distancia GoogleAPI con GPS [m]
310,76495 215,36789 329,42496 353,4028 397,1506
Error 0% 30,69% 6,00% 13,72% 27,79%
Sin embargo, en la tabla 2.3, en cuanto a distancia, el GPS nativo de Android ha dado un valor más ajustado al real.
Según se ha comprobado, no existe un proveedor idóneo que se comporte mejor en todas las situaciones. La combinación más precisa sería utilizar GoogleAPI de manera que en función de donde se encuentre el usuario se pudiera activar el GPS o desactivarlo para forzar que recoja los datos de otros proveedores.
Según la documentación de Google, esto no es posible, por lo que se debería adecuar el proveedor de datos a la localización más frecuente para la que esté prevista la aplicación.
En el caso de que sea una aplicación destinada a una ciudad, sería conveniente decantarse por Network provider o GoogleAPI sin GPS. Entre estas dos opciones no se han observado diferencias significativas en cuanto a precisión, pero si en otro aspecto que puede ser relevante. En el caso de GoogleAPI el desarrollador puede controlar la frecuencia de actualización de los datos, mientras que en Network provider de Android nativo no existe esa posibilidad. Esto hace que se puedan percibir cambios en la posición más pequeños.
Por otro lado, si se pretende desarrollar una aplicación destinada a un parque natural sin edificios cercanos, sería más interesante utilizar las opciones que utilizan GPS ya que se han comportado mucho mejor que las que no lo utilizan.
2.2. Listeners
2.2.1. ¿Qué es un Listener?
Para aplicaciones de realidad aumentada basadas en geolocalización, es interesante permitir al usuario solo interactuar con la aplicación cuando estemos en alguno de los puntos de interés y avisarle cuando esto haya ocurrido. Un listener se puede interpretar que actúa como un vigilante. El vigilante está atento a algún evento en concreto, cuando este evento se produce, lanza un aviso de cierta forma.
En el caso de la aplicación que se ha desarrollado este listener detecta cuando el usuario se encuentra a cierta distancia del punto de interés y lanza una notificación.
Como se ha explicado anteriormente, Unity es una plataforma que estuvo pensada inicialmente para videojuegos por lo tanto para aplicaciones que funcionen en primer plano y con las que el usuario esté en contacto directo constantemente. Por eso no existe la capacidad de implementar listeners.
Cuando se sale de la aplicación, esta se cierra junto con los procesos que estaban llevándose a cabo.
Sin embargo, en Android sí que existe la posibilidad de notificar al usuario cuando se llegue al punto de interés incluso cuando la aplicación no se está ejecutando en primer plano.
2.2.2. Notificación en un listener
Lo primero que debe hacerse es detectar cuando el usuario ha llegado a una localización concreta. En este ejemplo se mostrará una notificación cuando el usuario se encuentre cerca de la Sagrada Familia.
Primero de todo, se debe obtener las coordenadas de la Sagrada Familia (41.404098, 2.174974). Después se debe definir cuanto de cerca se quiere referir, por ejemplo, 10 metros. Ahora ya se está preparado para programar esta funcionalidad.
En primer lugar, se crea el objeto SF de tipo Location con las coordenadas se la Sagrada Familia.
Location SF=new Location("gps");
SF.setLongitude( 2.174974);
SF.setLatitude(41.404098);
Después de debe crear el canal de comunicación por el que la aplicación va a enviar la notificación al sistema operativo del dispositivo. Esto se hace de la siguiente manera:
private void createNotificationChannel() {
// Crea el NotificationChannel solo para API26+
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { CharSequence name = "Mi Canal";
String description = "Este es el canal";
int importance = NotificationManager.IMPORTANCE_DEFAULT;
NotificationChannel channel = new NotificationChannel(
"1233", name, importance);
channel.setDescription(description);
// Registrar el canal en el sistema
NotificationManager notificationManager = getSystemService(
NotificationManager.class);
notificationManager.createNotificationChannel(channel);
} }
Una vez está el canal creado, en la función onLocationChanged() del LocationListener se hace la comparativa de distancia entre la posición actual y la de interés para ver si se encuentra a menos de 10 metros. En caso afirmativo se llama a la función notifica.
if(location.distanceTo(SF)<10){
notifica();
}
En la función notifica(), es donde se crea la notificación propiamente dicha y donde se envía a través del NotificationChannel que se ha creado previamente.
Esto se hace mediante el código siguiente:
public void notifica(){
NotificationCompat.Builder mBuilder = new NotificationCompat.Builder(
this, "1233")
.setSmallIcon(R.drawable.ic_launcher_background) .setContentTitle("Notificación")
.setContentText("Estás cerca de la Sagrada Familia") .setPriority(NotificationCompat.PRIORITY_HIGH);
//Actividad que se lanzara al hacer click en la notificacion Intent resultIntent = new Intent(this,MainActivity.class);
PendingIntent resultPendingIntent = PendingIntent.getActivity(
this,0,resultIntent,PendingIntent.FLAG_UPDATE_CURRENT);
mBuilder.setContentIntent(resultPendingIntent);
NotificationManagerCompat notificationManager = NotificationManagerCompat.from(this);
// notificationId is a unique int for each notification that you must define
notificationManager.notify(Integer.parseInt("1233"), mBuilder.build());
}
Cuando el usuario se encuentre a menos de 10 metros de la localización que se ha definido, le aparecerá una notificación como la siguiente (Fig. 2.2).
Fig. 2.4. Notificación cerca de la Sagrada Familia
2.3. Plug-in
Como se ha demostrado anteriormente, Android nativo proporciona herramientas útiles al desarrollador para aplicaciones de realidad aumentada.
Por lo tanto, sería interesante poder integrar estas funcionalidades al entorno Unity. Esta plataforma permite hacerlo mediante lo que se denominan plug-ins.
2.3.1. ¿Qué es un plug-in/librería?
Un plug-in es un módulo de programación que permite añadir a un sistema una funcionalidad específica. En el caso que ocupa a este proyecto, un plug-in permite a Unity añadir funcionalidades programadas en Java para Android nativo. En este caso, la documentación de Unity las llama, AAR plug-ins. Este tipo de plug-in consiste en un archivo comprimido que encapsula tanto el archivo Manifest, las clases utilizadas y la carpeta de recursos. Una vez generado este archivo, se pueden importar y utilizar los métodos y recursos que proporciona.
2.3.2. ¿Cómo se programa un plug-in?
Lo primero que se debe entender a la hora de programar un plug-in es que es una aplicación que no tiene actividad, por lo tanto, consiste en un módulo en el cual existe una clase que contiene variables y métodos. Teniendo esto en cuenta, los primeros pasos para crear un plug-in serán:
a) Crear un proyecto y seleccionar “Add no activity”
b) Crear un nuevo módulo del tipo “Android Library”
c) Crear la clase pública que contenga la funcionalidad que se requiere d) Modificar el archivo Manifest añadiendo los permisos y elementos
necesarios
e) Hacer click en “Build Variants” y seleccionar “release” en vez de “debug”
para cambiar el tipo de compilación del código.
f) Hacer click en “Build” y “Make Project”
g) Dirigirse a la carpeta build/outputs/aar donde se encuenta el archivo generado
Siguiendo este procedimiento se ha generado el siguiente código para testear que es posible realizar la comunicación entre Unity y Android mediante un plugin generado de la manera explicada. Este plugin recibe los datos de un puntos de interés y devuelve a Unity un aviso se encuentra cerca del mismo.
package com.example.camilo.cercade;
import android.content.Context;
import android.location.Location;
import android.widget.Toast;
public class cercade { Context currentContext;
Location puntodeinteres;
Location posicionactual;
boolean cerca = false;
public cercade(Context UnityContext) { currentContext = UnityContext;
}
public void puntoInteres(float latitude, float longitude) { puntodeinteres = new Location("gps");
puntodeinteres.setLatitude(latitude);
puntodeinteres.setLongitude(longitude);
Toast.makeText(currentContext,"Punto de interes establecido.",Toast.LENGTH_SHORT).show();
}
public boolean estoyCerca(float latitud_actual, float longitud_actual, int distancia) {
// si dentro de la distancia que se especifica, retorna true posicionactual = new Location("gps");
posicionactual.setLatitude(latitud_actual);
posicionactual.setLongitude(longitud_actual);
if (posicionactual.distanceTo(puntodeinteres) < distancia) { Toast.makeText(currentContext,"Estas cerca del punto de interes.",Toast.LENGTH_SHORT).show();
cerca = true;
}
return cerca;
} }
Existe una pequeña diferencia respecto a la aplicación que se desarrolló para probar cual era el mejor proveedor entre las opciones de las que se disponía. En el caso del plug-in el contexto dependerá de la aplicación que lo llame y no será el suyo mismo, por lo que en este caso se ha añadido un parámetro y una variable donde se almacena el contexto desde donde se llama al plug-in.
Para acceder a este plug-in desde Unity se ha utilizado el siguiente código script en C#:
De este código cabe resaltar el objeto androidLocaliza del tipo AndroidJavaObject. En este objeto es donde se crea la instancia a la clase creada por el plug-in de Android. Como parámetro se debe pasar la ruta del paquete que encapsula el plugin ("com.example.camilo.cercade.cercade", en este caso) y la actividad de Unity que llamará a las funciones del plug-in.
A partir de ahí con el método del objeto AndroidJavaObject Call() se puede llamar a cualquier función definida por la clase del plug-in.
public class LocalizameScript : MonoBehaviour { [SerializeField]
Text retornPlugin;
AndroidJavaObject androidLocaliza;
// Use this for initialization void Start () {
AndroidJavaClass unityPlayerClass = new AndroidJavaClass("com.unity3d.player.UnityPlayer");
AndroidJavaObject unityActivity =
unityPlayerClass.GetStatic<AndroidJavaObject>("currentActivity");
androidLocaliza = new
AndroidJavaObject("com.example.camilo.cercade.cercade", unityActivity);
// inicializacion de puntos de interest
androidLocaliza.Call("puntoInteres", 41.4046941f, 2.1786045f);
}
public void getDistance() {
// Mira distancia entre la posición usuario y punto interés. retorna true o false dependiendo si la distancia entre puntos es menor igual a 10
bool res = androidLocaliza.Call<bool>("estoyCerca",
Input.location.LastData.latitude, Input.location.LastData.longitude,10);
retornPlugin.GetComponent<Text>().text = res.ToString();
} }
2.4. Conclusiones
A lo largo de este proyecto se ha comprobado que Android nativo proporciona datos más precisos de localización a Unity. El estudio en diversas situaciones ha demostrado que no existe un proveedor que se comporte de la mejor manera en todas las situaciones. Los datos proporcionados por Unity han introducido errores significativos las 3 pruebas realizadas por lo que se debería descartar si se requiere fiabilidad en los datos para una aplicación de realidad aumentada basada en geolocalización. El desarrollador debería prever cómo va a ser el ámbito por el que el usuario se desplazará. Dado que los puntos de interés son conocidos por el desarrollador, esto es controlable.
Además, la posibilidad de poder conectar Android nativo con Unity mediante plug-in proporciona al desarrollador la capacidad de elegir la mejor opción posible para el cometido deseado de ambas tecnologías. Esto hace que la calidad de la aplicación aumente y que el usuario tenga una mejor experiencia.
Además, durante la realización de este trabajo se ha notado la importancia que los expertos prevén que va a tener la realidad aumentada en los próximos años.
Si bien es una tecnología cuya implantación y desarrollo aún no es del todo satisfactoria, se encuentra en un momento propicio para el su auge definitivo. La convergencia de la inversión de las empresas, las posibilidades tecnológicas como el 5G, la implantación de los teléfonos inteligentes y el interés de los usuarios por este tipo de aplicaciones crear el entorno ideal para el hecho comentado anteriormente.
2.5. Referencias
Autores: Tawara, Takehiro y Ono, Kenji. Publicado: 2009. An Application of Photo Realistic Water Surface Interaction Using Mixed Reality
(https://www.researchgate.net/figure/A-general-augmented-reality- system_fig2_221622730)
Autor: Fundación Telefónica. Publicado: 2011. Realidad Aumentada: una nueva lente para ver el mundo
(https://books.google.es/books?hl=es&lr=&id=OXHmCgAAQBAJ&oi=fnd&pg=P A10&dq=historia+realidad+aumentada&ots=3rs-
R_ahs4&sig=UYBWVI7G22OecZT8mtlMCnzfqes#v=onepage&q&f=false)
Autora: Rachel Metz. Publicado: 2014. La realidad aumentada se pone a trabajar (https://www.technologyreview.es/s/4082/la-realidad-aumentada-se-pone-
trabajar)
Autor: Michael Isberto. Publicado: 2018. History of augmented reality (https://www.colocationamerica.com/blog/history-of-augmented-reality)
Autor: Interaction Design Foundation. Publicado: 2019. Augmented reality the past, the present and the future
(https://www.interaction-design.org/literature/article/augmented-reality-the-past- the-present-and-the-future)
Autor: Yeeply. Publicado: 2019. Tendencias en el desarrollo de apps para móviles en 2019
(https://www.yeeply.com/blog/tendencias-desarrollo-apps-moviles-2019/)
Autor: Shanhong Liu. Publicado: 2019. Global augmented virtual reality market size
(https://www.statista.com/statistics/591181/global-augmented-virtual-reality- market-size/)
Autor: Gloria Omale. Publicado: 2019. Gartner Says 100 Million Consumers Will Shop in Augmented Reality Online and In-Store by 2020
(https://www.gartner.com/en/newsroom/press-releases/2019-04-01-gartner- says-100-million-consumers-will-shop-in-augme)
Autores: Katies Costello y Robert van der Meulen. Publicado: 2018.
(https://www.gartner.com/en/newsroom/press-releases/2018-08-20-gartner- identifies-five-emerging-technology-trends-that-will-blur-the-lines-between- human-and-machine)
Autora: Ellen Daniel. Publicado: 2018. Gartner Identifies Five Emerging Technology Trends That Will Blur the Lines Between Human and Machine (https://www.verdict.co.uk/gartner-hype-cycle-2018-mixed-
reality/amp/?__twitter_impression=true)
Autores: David Cearley y Brian Burke. Publicado: 2018. Top 10 strategic technology trends for 2019
(https://emtemp.gcom.cloud/ngw/globalassets/en/doc/documents/3891569-top- 10-strategic-technology-trends-for-2019.pdf)
Autora: Elina Bessarabova. Publicado: 2018. 5 best augmented reality SDKs and frameworks
(https://themindstudios.com/blog/5-best-augmented-reality-sdks-and- frameworks/)
Autor: Estudio Alfa. Publicado: 2017. Top Herramientar para crear apps de Realidad Aumentada
(https://estudioalfa.com/top-herramientas-crear-apps-realidad-aumentada) Autor: Microsoft. Publicado: 2015. Float (referencia de C#) (https://docs.microsoft.com/es-es/dotnet/csharp/language-
reference/keywords/float)
Autor: Unity Technologies. Publicado: 2019. Unity user manual (https://docs.unity3d.com/Manual/index.html)
Autor: Android Enterprise. Documentación para desarroladores de apps (https://developer.android.com/docs)
Autor: Scrapywar. Publicado: 2019. Crear un plugin Android Java para Unity 3D (https://scrapywar.com/crear-un-plugin-android-java-para-unity-3d-paso-a- paso/)
