TFG Memoria SergioRodriguez

UNIVERSIDAD POLITÉCNICA DE MADRID
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y

DISEÑO INDUSTRIAL
Grado en Ingenierı́a Electrónica y Automática Industrial
TRABAJO FIN DE GRADO
Desarrollo de una aplicación

móvil para la teleoperación de
los telescopios robóticos de la
red GLORIA
Sergio Rodrı́guez Dorado
Cotutor: Jorge Artieda Trigueros Tutor: Raquel Cedazo León

Departamento: Departamento de Departamento: Departamento de
Ingenierı́a Eléctrica, Electrónica Ingenierı́a Eléctrica, Electrónica
Automática y Fı́sica Aplicada Automática y Fı́sica Aplicada
Madrid, Septiembre 2016

ii
UNIVERSIDAD POLITÉCNICA DE MADRID
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y

DISEÑO INDUSTRIAL
Grado en Ingenierı́a Electrónica y Automática Industrial
TRABAJO FIN DE GRADO
Desarrollo de una aplicación

móvil para la teleoperación de
los telescopios robóticos de la
red GLORIA
Firma Autor
Firma Cotutor Firma Tutor

ii
iii
Tı́tulo: Desarrollo de una aplicación móvil para la teleoperación de los telescopios

robóticos de la red GLORIA
Autor: Sergio Rodrı́guez Dorado
Tutor: Raquel Cedazo León
Cotutor: Jorge Artieda Trigueros
EL TRIBUNAL
Presidente:
Vocal:
Secretario:
Realizado el acto de defensa y lectura del Trabajo Fin de Grado el dı́a ....... de
.................... de ... en .........., en la Escuela Técnica Superior de Ingenierı́a y Diseño
Industrial de la Universidad Politécnica de Madrid, acuerda otorgarle la CALIFI-
CACIÓN de:
VOCAL
SECRETARIO PRESIDENTE
iv
Agradecimientos
Agradezco a todas las personas que me han acompañado durante este tiempo y
me han animado a seguir adelante ya que gracias a ellos he conseguido terminar con
éxito este proyecto.
En primer lugar quiero dar las gracias a mi familia, en especial a mi madre, que
ha estado apoyándome dı́a a dı́a y me ha facilitado mucho las tareas de convivencia
para poder dedicarle más tiempo al proyecto.
Por otra parte, le doy las gracias a Sandra por haberme apoyado en los buenos
y malos momentos, por haberme dado todos esos consejos que me han aportado
seguridad y me han ayudado a alcanzar la meta.
También agradezco a mis tutores Raquel y Jorge el haber formado parte de es-
te proyecto, por haberme propuesto realizar este interesante trabajo, habiéndome
guiado en los momentos más complicados y reconociendo el esfuerzo y la dedicación
que ha supuesto este TFG.
Muchas gracias a todos.
v
vi AGRADECIMIENTOS
Resumen
Este proyecto se resume en el desarrollo de una aplicación móvil multiplataforma

para realizar el control a distancia de los telescopios robóticos de la red GLORIA. La
teleoperación de los telescopios se divide en dos experimentos astronómicos: Solar
y Nocturno. Mediante dichos experimentos, el usuario puede apuntar el telescopio
hacia un objetivo, ası́ como ajustar parámetros de la cámara, como el tiempo de
exposición y el enfoque, para finalmente tomar una o varias fotos de dicho objetivo.
El desarrollo de la aplicación se estructura en dos bloques, que son la funcionali-

dad y el diseño de la interfaz de usuario.
La aplicación de teleoperación realizada en este Trabajo de Fin de Grado está con-
tenida en una aplicación denominada Cazadores de Asteroides que consiste en la
búsqueda de asteroides y obtención de premios para reservar intervalos de tiempo
de realización de la teleoperación.
Palabras clave: teleoperación, telescopio, aplicación móvil.
vii
viii RESUMEN
Abstract
This project developes a multi platform mobile application for remote control of
GLORIA’s robotic-telescopes array. Teleoperation of telescopes is divided into two
astronomical experiments: Solar and Night. Through these experiments, user is able
to point the telescope to a target, or adjust camera settings, such as exposition time
or focuser, to finally take one or more photos of that objective.
The development of the application is divided into two blocks, which are the
functionality and design of the user interface.
Teleoperation’s application made in this paper is contained in an application called
Cazadores de Asteroides consisting of finding asteroids and obtaining awards to
reserve time intervals for teleoperation.
Keywords: teleoperation, telescope, mobile application.
ix
x ABSTRACT
Índice general
Agradecimientos V
Resumen VII
Abstract IX
1. Introducción 1
1.1. Motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Materiales utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Estado del arte 5

2.1. Definición de conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Aplicaciones móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Desarrollo multiplataforma . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Aplicaciones Web vs Aplicaciones Nativas . . . . . . . . . . . 7
2.3.2. Aplicaciones Hı́bridas . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Evolución de las aplicaciones Web . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Framework AngularJS . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2. Comparativa entre AngularJS y otros frameworks . . . . . . . 14
3. Proyectos astronómicos de ciencia ciudadana 17

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Historia de los Observatorios Robóticos Autónomos . . . . . . . . . . 17
3.3. Grupos astronómicos de investigación . . . . . . . . . . . . . . . . . . 20
3.3.1. Grupo Cı́clope . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2. Grupo Zooniverse . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Desarrollo de la aplicación móvil 27

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2. Creación de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1. Instalación de los componentes . . . . . . . . . . . . . . . . . 28
4.2.2. Construcción de la aplicación . . . . . . . . . . . . . . . . . . 30
4.3. Estructura del contenido . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. Desarrollo del contenido . . . . . . . . . . . . . . . . . . . . . . . . . 34
xi
xii ÍNDICE GENERAL
5. Experimentos 41
5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2. Experimento Solar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.1. Telescopios del Experimento Solar . . . . . . . . . . . . . . . . 41
5.2.2. Teleoperación del Experimento Solar . . . . . . . . . . . . . . 42
5.3. Experimento Nocturno . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.1. Telescopios del Experimento Nocturno . . . . . . . . . . . . . 45
5.3.2. Teleoperación del Experimento Nocturno . . . . . . . . . . . . 51
6. Conclusiones 55
6.1. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2. Desarrollos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A. Manual de usuario 57
A.1. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.1.1. Compatibilidad de dispositivos . . . . . . . . . . . . . . . . . . 57
A.1.2. Requisitos del dispositivo . . . . . . . . . . . . . . . . . . . . . 57
A.2. Instrucciones de instalación . . . . . . . . . . . . . . . . . . . . . . . 57
A.3. Instrucciones de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.3.1. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Bibliografı́a 69
Índice de figuras
2.1. Arquitectura de una aplicación nativa [4]. . . . . . . . . . . . . . . . . 8

2.2. Arquitectura de una aplicación Web [4]. . . . . . . . . . . . . . . . . 9
2.3. Representación del contenedor de una aplicación móvil hı́brida [1]. . . 11
2.4. Arquitectura a alto nivel de una aplicación Cordova [26]. . . . . . . . 13
3.1. Primer telescopio controlado por ordenador (1968). . . . . . . . . . . 18

3.2. The Carlsberg Meridian Circle en La Palma (1984). Uno de los pri-
meros observatorios autónomos. . . . . . . . . . . . . . . . . . . . . . 19
3.3. Situación de los telescopios robóticos en el mundo. . . . . . . . . . . . 20
3.4. Arquitectura software de la red de telescopios robóticos GLORIA. . . 21
4.1. Esquema de la estructura de la aplicación GLORIA. . . . . . . . . . . 28

4.2. Esquema de la estructura de la aplicación Cazasteroides. . . . . . . . 28
4.3. Esquema de funcionamiento de AngularJS [25]. . . . . . . . . . . . . 32
4.4. Esquema de las dependencias externas de la aplicación. . . . . . . . . 34
4.5. Esquema de la jerarquı́a de rutas de la aplicación. . . . . . . . . . . . 36
4.6. Esquema de visualización y búsqueda de imágenes. . . . . . . . . . . 37
4.7. Esquema de solicitud de una reserva. . . . . . . . . . . . . . . . . . . 37
5.1. Telescopio TADs ubicado en el Observatorio del Teide (Tenerife). . . 42

5.2. Imagen de la fotosfera solar tomada mediante el experimento solar. . 43
5.3. Imagen de búsqueda del Sol utilizada en el experimento solar. . . . . 43
5.4. Imagen del telescopio TADs tomada por la cámara exterior del ob-
servatorio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5. Imagen del telescopio TADs tomada por la cámara interior del obser-
vatorio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6. Ejemplo de fotografı́a obtenida por el telescopio TADs durante el
experimento solar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7. Telescopio BART localizado en el Instituto Astronómico del CAS
(Ondrejov). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8. Telescopio BOOTES-1A localizado en Observatorio de El Arenosillo
(Huelva). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.9. Telescopio BOOTES-2 ubicado en el Observatorio de La Mayora
(Málaga). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.10. Telescopio TADn ubicado en el Observatorio del Teide (Tenerife). . . 49
5.11. Telescopio D50 localizado en el Instituto Astronómico de la Academia
de las Ciencias de República Checa (Ondrejov). . . . . . . . . . . . . 50
5.12. Telescopio WATCHER localizado en el Observatorio Boyden (Bloem-
fontein). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
xiii
xiv ÍNDICE DE FIGURAS
5.13. “Skymap”. Mapa del cielo con información de las constelaciones. . . . 52

5.14. Ejemplo de fotografı́a obtenida por el telescopio BART durante el
experimento nocturno. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1. Login de usuario en Cazasteroides. . . . . . . . . . . . . . . . . . . . 58
A.2. Login de usuario en GLORIA. . . . . . . . . . . . . . . . . . . . . . . 58
A.3. Registro de usuario en Cazasteroides. . . . . . . . . . . . . . . . . . . 59
A.4. Registro de usuario en GLORIA. . . . . . . . . . . . . . . . . . . . . 59
A.5. Pantalla de inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.6. Tutoriales de realización de los experimentos. . . . . . . . . . . . . . . 60
A.7. Sección de visualización de imágenes. . . . . . . . . . . . . . . . . . . 61
A.8. Selección de un experimento. . . . . . . . . . . . . . . . . . . . . . . . 61
A.9. Selección de una fecha. . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.10.Solicitud de una reserva. . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.11.Finalización del proceso de reserva. . . . . . . . . . . . . . . . . . . . 62
A.12.Lista de reservas pendientes. . . . . . . . . . . . . . . . . . . . . . . . 62
A.13.Detalles de una reserva. . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.14.Información del experimento. . . . . . . . . . . . . . . . . . . . . . . 63
A.15.Pantalla principal. Experimento Solar. . . . . . . . . . . . . . . . . . 64
A.16.Pantalla de visualización del observatorio. Experimento Solar. . . . . 65
A.17.Pantalla de apuntamiento del telescopio. Experimento Solar. . . . . . 65
A.18.Pantalla principal. Experimento Nocturno. . . . . . . . . . . . . . . . 66
A.19.Búsqueda y localización. . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.20.Posicionamiento por coordenadas. . . . . . . . . . . . . . . . . . . . . 67
A.21.Posicionamiento por objetivos. . . . . . . . . . . . . . . . . . . . . . . 67
A.22.Búsqueda mediante “SKYMAP”. . . . . . . . . . . . . . . . . . . . . 67
Índice de tablas
5.1. Caracterı́sticas y especificaciones del telescopio TAD. . . . . . . . . . 42

5.2. Caracterı́sticas y especificaciones del telescopio BART. . . . . . . . . 46
5.3. Caracterı́sticas y especificaciones del telescopio BOOTES-1A. . . . . . 47
5.4. Caracterı́sticas y especificaciones del telescopio BOOTES-2. . . . . . 49
5.5. Caracterı́sticas y especificaciones del telescopio D50. . . . . . . . . . . 50
5.6. Caracterı́sticas y especificaciones del telescopio WATCHER. . . . . . 51
xv
xvi ÍNDICE DE TABLAS
Capı́tulo 1
Introducción
1.1. Motivación del proyecto

El motivo principal de la elección de este Trabajo de Fin de Grado comienza con
el interés por poner en práctica los conocimientos adquiridos durante la realización
del Grado en Ingenierı́a Electrónica Industrial y Automática. Dentro de la amplia
variedad de materias estudiadas, y con la motivación de seguir aprendiendo y ad-
quirir unas habilidades más especı́ficas, se decide realizar un proyecto centrado en
la informática y aplicado al desarrollo de las nuevas tecnologı́as.
El auge de la tecnologı́a móvil en la actualidad ha resultado en una constante

evolución hacia la creación de dispositivos portátiles capaces de realizar cualquier
tipo de función para conseguir una mayor comodidad a cualquier usuario. El resul-
tado de estas nuevas tecnologı́as ha provocado una revolución en la realización de
ciertas actividades, pudiendo simplificar y agilizar el proceso a los usuarios.
En el sector de las aplicaciones y páginas web se ha popularizado la implemen-
tación de versiones para dispositivos móviles adaptadas a las limitaciones fı́sicas de
éstos. Esto conlleva una optimización de los recursos necesarios para su correcto
funcionamiento y visualización.
Entre las muchas organizaciones que están optando por la adaptación a la tecno-
logı́a portátil se encuentra el Grupo Ciclope, dedicado a la investigación cientı́fica
en Astronomı́a, con el objetivo de promover el interés a los usuarios para colaborar
en la ciencia ciudadana mediante una aplicación para móviles. El grupo Cı́clope
posee una experiencia en el sector astronómico que inspira diversos proyectos como
es el caso de GLORIA (GLObal Robotic-telescopes Intelligent Array), cuya red de
telescopios robóticos se utiliza para observar el cielo de forma remota.
La Astronomı́a en la actualidad es un campo muy abierto a la investigación, ya

que existe una inmensa cantidad de cuerpos celestes desconocidos por el momento
que podrı́an ser útiles e interesantes para nuestro futuro. La continua observación
e investigación del Universo nos acerca cada vez más al conocimiento de nuestro
posible futuro, ası́ como de nuestro origen.
Con la intención de observar el universo mediante los telescopios robóticos y la
posibilidad de ser utilizado por cualquier persona, sea o no profesional en el sector,
se fomenta el interés y la motivación por el aprendizaje sobre la Astronomı́a, ası́
1
2 CAPÍTULO 1. INTRODUCCIÓN
como la interacción en tiempo real con la red de telescopios mediante una aplicación
móvil.
1.2. Objetivos
Este proyecto pretende desarrollar una aplicación para móviles con el propósito
de controlar de forma remota la red de telescopios robóticos GLORIA y ofrecer sus
experimentos al Proyecto Cazadores de Asteroides. Esta aplicación debe ser compa-
tible con cualquier dispositivo móvil.
Para alcanzar este propósito se establecen los siguientes objetivos:

Diseño y desarrollo de la app multiplataforma de teleoperación.
Diseño de las interfaces de usuario de los experimentos.
Integración con la API de GLORIA.
Tests de usabilidad de la app.
1.3. Materiales utilizados

Durante la elaboración de este proyecto se ha utilizado un ordenador personal
con Sistema Operativo Windows 10, provisto de herramientas de programación y
simulación. El entorno de desarrollo utilizado ha sido Eclipse, acompañado del na-
vegador Google Chrome para la visualización de la interfaz de usuario y simulación
del funcionamiento de la aplicación.
Para realizar el testing de la aplicación en el navegador se utiliza Node.js, que
crea un servidor web local que se encarga de gestionar las peticiones HTTP enviadas
por cliente.
Adicionalmente, se ha hecho uso de SDK y AVD de Android y XCode de Apple

para la emulación y comprobación del funcionamiento de la aplicación en distintas
plataformas.
La programación se ha realizado en los lenguajes HTML, CSS y Javascript, útiles

para el desarrollo de páginas y aplicaciones Web.
La herramienta de desarrollo multiplataforma utilizada ha sido Apache Cordova,

compatible con las tecnologı́as de programación anteriormente mencionadas.
Para realizar el desarrollo de la interfaz de usuario y proporcionar funcionalidad

a la aplicación, se ha decidido utilizar el framework de AngularJS junto con jQuery,
jQuery Mobile y Bootstrap.
1.4. Estructura del documento

A continuación, para facilitar la lectura del documento, se detalla el contenido
de cada capı́tulo.
1.4. ESTRUCTURA DEL DOCUMENTO 3
En el Capı́tulo 1 se realiza una introducción y alcance del proyecto.

En el Capı́tulo 2 se analizan las tecnologı́as utilizadas en la actualidad para el
desarrollo de aplicaciones móviles.
En el Capı́tulo 3 se muestra el alcance de diversos proyectos astronómicos de-
dicados a la ciencia ciudadana.
En el Capı́tulo 4 se detalla la estructura y desarrollo de la aplicación.
En el Capı́tulo 5 se analizan los experimentos realizados.
En el Capı́tulo 6 se desarrolla una conclusión y se proponen futuras mejoras
para la aplicación móvil.
En el Apéndice A se detalla el manual de usuario de la aplicación.
4 CAPÍTULO 1. INTRODUCCIÓN
Capı́tulo 2
Estado del arte
En este capı́tulo se analizarán las tecnologı́as utilizadas para el desarrollo de

aplicaciones móviles y se argumentarán los motivos de la elección de las tecnologı́as
utilizadas en este proyecto en comparación con el resto de posibilidades también
utilizadas en la actualidad.
Para comenzar, se definirán algunos aspectos relevantes necesarios para la com-
prensión del documento.
2.1. Definición de conceptos

En el trascurso del documento se hará referencia a diversos conceptos definidos
en esta sección.
HTTP (Hypertext Transfer Protocol) Es el protocolo de comunicación que per-
mite la transferencia de información por la Web. Define la sintaxis que utilizan
los elementos de software de la arquitectura web para comunicarse. Es un proto-
colo sin estado, es decir, no almacena la información sobre conexiones anteriores
ya que de eso se encargan las cookies. La transferencia de datos de forma segura
se realiza mediante el protocolo HTTPS (HTTP Secure), que utiliza un cifra-
do apropiado para el tráfico de información privada. Para aceptar conexiones
HTTPS el servidor Web debe poseer un certificado autorizado.
AJAX (Asynchronous Javascript And XML) Es una técnica de desarrollo web
para aplicaciones interactivas. Las aplicaciones que utilizan AJAX se ejecutan
en el cliente mientras se mantiene la comunicación ası́ncrona con el servidor, de
esta forma es posible interactuar con los elementos de la página sin necesidad
de recargarla, mejorando su velocidad y usabilidad.
API (Application Programming Interface): Es un conjunto de subrutinas, fun-
ciones y procedimientos que ofrece una biblioteca para ser utilizada por otro
software proporcionando cierto nivel de abstracción. Representa la capacidad
de comunicación entre componentes software, y se utiliza para proporcionar un
conjunto de funciones de uso general para evitar su programación desde cero.
REST (Representational State Transfer): Es un estilo de arquitectura software
utilizado para describir cualquier interfaz entre sistemas que utilicen HTTP
para obtener datos o ejecutar operaciones sobre datos en cualquier formato co-
mo XML o JSON sin las abstracciones adicionales de los protocolos basados en
5
6 CAPÍTULO 2. ESTADO DEL ARTE
patrones de intercambio de mensajes. Está basado en un protocolo cliente/ser-

vidor sin estado en el cual cada mensaje contiene toda la información necesaria
para comprender la petición. Las operaciones más importantes de gestión de
los elementos de información son POST, GET, PUT y DELETE.
SOAP (Simple Object Access Protocol): Es un protocolo estándar que define los
métodos de comunicación entre objetos mediante intercambio de datos XML. Se
trata de un paradigma de mensajerı́a de una dirección sin estado utilizado para
crear otros protocolos más complejos según la aplicación. El documento XML
presenta una estructura que consta de Envelope (identifica el mensaje SOAP),
Header (envı́a información de procesamiento del mensaje), Body (contiene la
información de llamada y respuesta) y Fault (contiene información sobre errores
del procesado y envı́o del mensaje).
XML (eXtensible Markup Language): Es un lenguaje de marcas utilizado para
almacenar datos de forma legible. Permite definir la gramática de lenguajes
especı́ficos para estructurar documentos. XML da soporte a bases de datos y se
utiliza cuando varias aplicaciones deben comunicarse entre sı́ o integrar infor-
mación. La estructura de la información intercambiada se rige mediante unos
elementos estándar, formados por el prólogo (Declaración del tipo de documen-
to), el cuerpo (Contenido del mensaje) y otros elementos con sus respectivos
atributos.
JSON (JavaScript Object Notation): Es un formato de texto ligero para inter-
cambio de datos que posee una sintaxis literal de objetos Javascript. Es posible
analizar de forma muy simple estos datos mediante cualquier navegador Web
debido a la presencia de Javascript, lo cual ha permitido que JSON haya si-
do aceptado por la comunidad de desarrolladores AJAX. Los tipos de datos
disponibles en JSON son números, cadenas, booleanos, valores null, vectores y
objetos.
2.2. Aplicaciones móviles

La tecnologı́a ha evolucionado mucho en los últimos años, desarrollando disposi-
tivos cada vez más pequeños y con mayor capacidad. Internet en la tecnologı́a móvil
es uno de los avances más importantes en la actualidad, considerando un continuo
desarrollo de las páginas web para adaptarse a las pantallas táctiles y con tamaño
limitado.
Esta era comenzó con el lanzamiento del iPhone en 2007, el primer smartphone
que se consideraba un ordenador de bolsillo debido a sus potentes cualidades que le
permitı́an el uso de múltiples aplicaciones y la capacidad de conectarse a internet y
acceder a una tienda online, caracterı́sticas que se alejaban de un modelo de teléfono
móvil tradicional. Desde entonces se ha ido popularizando y expandiendo hasta la
época actual en la que un smartphone con internet es prácticamente indispensable
tanto personal como profesionalmente.
Es posible analizar esta evolución distinguiendo varias etapas [27] según el cambio
en el comportamiento de las personas al utilizar un dispositivo móvil con internet.
En la primera etapa se utilizaba internet en los móviles para sustituir diccionarios
2.3. DESARROLLO MULTIPLATAFORMA 7
mediante la búsqueda en navegadores de enciclopedias online o con aplicaciones de

traductores, servı́a mayormente como herramienta de búsqueda de información o de
entretenimiento. En la segunda etapa se avanza un paso adelante con la contribu-
ción de la comunidad aportando conocimientos y experiencias propios de cada uno,
además de la interactuación social entre usuarios. Es la etapa de las redes sociales,
la comunicación pública con otros usuarios de internet. En la tercera y última etapa
se define el término de creatividad. Las comunicaciones y la obtención de nuevos
conocimientos ya no se utilizan únicamente como entretenimiento, sino como un
estilo de vida que consigue la adaptación de la forma de ser y actuar de cada uno,
optimizando el trabajo propio y personalizando las tareas en una constante coor-
dinación con las herramientas y aplicaciones proporcionadas por el dispositivo móvil.
Este recorrido ha resultado en una integración absoluta de los smartphones en la

sociedad actual proporcionando aplicaciones pensadas para ayudarnos en distintos
aspectos de la vida cotidiana, como localizar nuestra situación o medir diariamente
nuestra actividad fı́sica, ası́ como fomentar la educación de la ciudadanı́a de una
forma más cómoda y accesible.
2.3. Desarrollo multiplataforma

El desarrollo de aplicaciones móviles es importante para contribuir a la evolu-
ción tecnológica en la sociedad actual. La multitud de servicios disponibles en los
dispositivos móviles es consecuencia de la existencia de diversas plataformas o sis-
temas operativos basados en una metodologı́a propia de desarrollo. Las aplicaciones
nativas proporcionan unas funcionalidades especı́ficas propias de cada plataforma a
cambio de estar limitadas a ofrecer sus servicios únicamente a los dispositivos que
posean dicho sistema operativo.
Para evitar los problemas de compatibilidad entre distintas plataformas se di-
señan las aplicaciones multiplataforma, que utilizan un framework que permite a la
Web ser una perfecta candidata para el desarrollo de aplicaciones compatibles con
múltiples plataformas.
La Web permite a los smartphones acceder a multitud de contenidos y servicios
REST. Existen dos opciones para acceder a dichos servicios [4], mediante aplica-
ciones nativas o mediante aplicaciones Web. A pesar de la independencia de la
plataforma, las aplicaciones Web parecen contener las mismas caracterı́sticas y ex-
periencias de usuario que las nativas. Sin embargo, cada vez los usuarios utilizan
más las aplicaciones nativas.
A continuación se comentarán las diferencias de acceso a los servicios Web REST-

ful entre aplicaciones Web y nativas.
2.3.1. Aplicaciones Web vs Aplicaciones Nativas

Las aplicaciones móviles se han adaptado en los últimos años a los distintos méto-
dos para consumir servicios Web, entre los que se encuentran los patrones SOAP
y REST. Debido a las mejoras en la informática móvil se ha comprobado que al
consumirse los servicios Web SOAP son muy pesados en cuanto a rendimiento, en
cambio los servicios Web RESTful son más ligeros y poseen una arquitectura más
flexible y adecuada para los dispositivos móviles.
En la actualidad existen numerosas aplicaciones móviles que acceden a servicios

Web RESTful para proporcionar información a los usuarios de los dispositivos móvi-
les, ya sea para buscar en la web, conocer la información del tiempo, acceder a las
redes sociales o realizar cualquier compra.
Muchos de los servicios están disponibles para ambos tipos de aplicación, ya sea
Web o nativa. Aparentemente las dos formas ofrecen las mismas funcionalidades al
usuario, pero son distintas para los desarrolladores del software. Las aplicaciones
nativas poseen una mayor optimización con el hardware, pero necesitan de un len-
guaje de programación propio como es el caso de iOS con Objective-C y Android
con Java. Por otro lado, las aplicaciones Web se desarrollan mediante HTML, CSS
y Javascript y se puede acceder a ellas mediante cualquier navegador web como
Chrome, Safari o Firefox desde cualquier plataforma.
Teniendo en cuenta estos aspectos, se comparará la forma de acceso a los servicios
Web en cada tipo de aplicación.
Para comenzar, cabe destacar que los proveedores de servicios Web poseen di-
ferentes semánticas de API para aplicaciones Web y nativas, ya que las URL de
destino de dichos servicios son distintos ofreciendo la misma funcionalidad.
En cuanto a la arquitectura de las aplicaciones, las nativas (ver Figura 2.1) con-
tienen muchos elementos precargados al realizar una petición y solamente necesitan
la información del usuario obtenida desde el servidor en lugar de cargar la apli-
cación completa. Sin embargo, los usuarios tienen que actualizar manualmente la
aplicación, descargando e instalando la última versión para obtener las nuevas fun-
cionalidades.
Figura 2.1: Arquitectura de una aplicación nativa [4].
Una vez instalada la aplicación en el dispositivo, el código nativo y algunos re-

cursos necesitan ser almacenados. Al iniciar la aplicación, la lógica de procesamiento
comienza y esto puede requerir de algún recurso Web que ha de descargarse y ana-
lizarse para decodificar el formato de datos (por ejemplo JSON) y finalmente crear
la nueva interfaz de usuario. Hay que destacar que algunos desarrolladores utilizan
los datos almacenados en la memoria caché para reutilizar algunos recursos (como
imágenes) y ası́ evitar descargarlos de nuevo.
Por el contrario, una aplicación Web es mostrada mediante un navegador Web, el

cual tiene que descargar todos los recursos como los archivos de páginas, imágenes,
códigos de Javascript y hojas de estilos CSS para mostrar la interfaz de usuario. La
arquitectura de estas aplicaciones (ver Figura 2.2) consiste en una primera petición
de datos de la interfaz al iniciar la aplicación en el navegador, seguida del resto
de peticiones para el resto de contenidos. Existen dos formas de interactuar con la
aplicación, la primera se basa en los saltos entre páginas al realizar el usuario alguna
intervención, y la segunda se basa en una petición AJAX que gestiona los métodos
de callback sin realizar ningún salto de página.
Figura 2.2: Arquitectura de una aplicación Web [4].
En lo referido al acceso a servicios RESTful, es posible realizar varios tipos de

comparaciones [4], como son el número de conexiones de red, el tiempo de respuesta
y el volumen de tráfico de datos. Comenzando por el número de conexiones, tanto
las aplicaciones nativas como las Web poseen resultados muy similares dependiendo
del tipo de gestión que se desee realizar. Esto ocurre al utilizar los métodos POST,
PUT y DELETE, pero el método GET otorga mayor número de conexiones en
aplicaciones nativas. En referencia al volumen de tráfico de datos, generalmente las
aplicaciones Web consumen más debido al envı́o de mayor cantidad de información
y la descarga de los recursos necesarios. Sin embargo, existen aplicaciones nativas
que consumen mayor cantidad de datos porque envı́an y reciben más información. El
tiempo de respuesta está muy ligado al volumen de tráfico de datos, aunque obtiene
una gran ventaja el uso de la memoria caché por su aumento de rendimiento, por
tanto, es aconsejable el uso de dicha memoria tanto para aplicaciones Web como
nativas.
Se ha comprobado que el desarrollo de una aplicación presenta un funcionamien-

to distinto y unas caracterı́sticas propias del método de desarrollo empleado. Las
aplicaciones Web y nativas presentan ciertas ventajas y desventajas con respecto a
sus competidoras.
Para combinar las ventajas de los dos métodos de desarrollo existe un tercer
método basado en la construcción de aplicaciones hı́bridas.
2.3.2. Aplicaciones Hı́bridas

El término de Aplicación Móvil Hı́brida (HMA) [1] describe una aplicación creada
para ejecutarse en un dispositivo móvil donde la lógica de la aplicación está prin-
cipalmente escrita en Javascript y los componentes de la interfaz de usuario están
definidos utilizando HTML5 y CSS3.
Todos los sistemas operativos actuales permiten la visualización e interacción de
una WebView, un navegador integrado documentado y contenido en cada una de las
plataformas SDK (Software Development Kit).
La asociación de Javascript y HTML consigue integrar una aplicación Web en
un dispositivo mediante la instalación de sus componentes, evitando el desarrollo
en el lenguaje nativo particular de cada dispositivo. El framework utilizado para
este propósito consiste en una aplicación nativa que proporciona todos los servicios
y APIs necesarios para que los desarrolladores se abstraigan de la programación
mediante el lenguaje nativo.
Las aplicaciones nativas poseen una serie de plugins desarrollados para cada pla-
taforma que utilizan las funciones a nivel de dispositivo, como acceso al calendario,
agenda o a elementos hardware como la cámara. Estos plugins tienen una API de
Javascript asociada, que permite acceder a todas las funciones nativas e interactuar
en distintas plataformas. Una aplicación hı́brida puede procesar mediante estas APIs
el URI (Uniform Resource Identifier) y llamar a los métodos nativos dentro de la
máscara de aplicaciones. Los servicios proporcionados por las APIs permiten gestio-
nar funcionalidades del propio dispositivo como la seguridad y el almacenamiento,
las notificaciones, las actualizaciones, y aplicaciones comunes a cualquier dispositivo
como el email, el calendario o la agenda de contactos.
El desarrollo de aplicaciones hı́bridas posee una cantidad de ventajas en cuanto

a la creación de aplicaciones móviles:
El uso de HTML5 y Javascript aumenta la portabilidad de la aplicación.
La interfaz de usuario y la lógica de la aplicación pueden ser utilizadas en
múltiples plataformas con una mı́nima cantidad de cambios en el formato de
presentación realizados con CSS.
La abundancia de recursos para el desarrollo de HTML y Javascript en com-
paración con el conocimiento de los lenguajes nativos Objective-C y Java.
Se requiere exclusivamente conocimiento sobre desarrollo Web en lugar de ne-
cesitar aprendizaje de múltiples lenguajes de alto nivel.
En términos de instalación, la mayor parte de las veces se actualiza únicamente
la interfaz de usuario, evitando tener que reinstalar todos los elementos de la
aplicación.
La solución para la creación de un contenedor de aplicaciones hı́bridas es mediante
un framework que cargue el código HTML y Javascript posteriormente al código
nativo, para permitir cargar de forma independiente la estructura de la interfaz de
usuario y la lógica de la aplicación.
Como puede observarse en la Figura 2.3, el contenedor de la aplicación hı́brida
está formado por una variedad de componentes en capas, mientras que la aplica-
ción en sı́ está programada en el lenguaje nativo del dispositivo. El contenedor está
formado por un código que ejecuta la interfaz de usuario en una WebView al po-
ner en marcha la aplicación. La aplicación ejecutada en WebView puede llamar al
código nativo mediante plugins, que contienen las APIs de Javascript y las clases
correspondientes implementadas en código nativo.
Al seleccionar el icono del escritorio se llama al Administrador de Aplicaciones
(Application Manager), que carga la aplicación seleccionada en los componentes de
la WebView.
Figura 2.3: Representación del contenedor de una aplicación móvil hı́brida [1].
El framework hı́brido más frecuentemente utilizado es Apache Cordova, que per-

mite a los desarrolladores crear aplicaciones hı́bridas, además de plugins personali-
zados compatibles con éstas. La extensa comunidad de desarrolladores de Cordova
ofrece múltiples plugins que proporcionan funcionalidades adicionales a las aplica-
ciones.
Apache Cordova
Apache Cordova [26] es un marco de desarrollo móvil de código abierto. Permite

utilizar las tecnologı́as estándar web como HTML5, CSS3 y JavaScript para desa-
rrollo multiplataforma, evitando el lenguaje de desarrollo nativo de cada plataforma
móvil.
Es una herramienta útil para desarrollar una aplicación y extenderla a más de
una plataforma sin tener que reimplementar el código con el lenguaje y herramientas
de cada plataforma.
Se utiliza también para implementar una aplicación web y distribuirla por los
distintos portales de aplicaciones. Además, es utilizado por desarrolladores interesa-
dos en combinar los componentes de una aplicación nativa con una WebView para
acceder a las APIs de nivel del dispositivo o desarrollar una interfaz plugin entre los
componentes nativos y la WebView.
La misma aplicación se implementa como una página web, mediante un archivo
local llamado index.html, que hace referencia a cualquier CSS, JavaScript, imágenes,
archivos multimedia u otros recursos necesarios para su ejecución. La aplicación se
ejecuta como una WebView dentro de la aplicación nativa.
Las aplicaciones Cordova contienen un archivo común, denominado config.xml,
que proporciona información acerca de la aplicación y especifica los parámetros que
afectan a su funcionamiento.
Los Plugins proporcionan una interfaz para establecer una comunicación entre
los componentes nativos y Cordova y proporcionar enlaces a APIs estándar de Ja-
vascript.
Debido a las diferencias entre los distintos dispositivos, como son sus IDE (In-
tegrated Development Environments) y estructuras en la creación de aplicaciones
nativas, Cordova utiliza un método para la creación y administración de aplicaciones
multiplataforma denominado CLI (Command-Line Interface). El CLI proporciona
soporte para distintas plataformas compatibles, además de la capacidad de añadir y
gestionar plugins en el proyecto, incluidos plugins de terceros y creados por cualquier
desarrollador. También se utiliza para preparar, compilar y construir proyectos, con
la posibilidad de ejecutarlos en un simulador.
Las plataformas que Cordova puede soportar son: Amazon-fireos, Android, black-
berry10, Firefox OS, IOS, Ubuntu, Windows Phone 8 y Windows (8, 8.1, 10).
Una aplicación creada mediante Apache Cordova presenta una arquitectura bási-
ca mostrada en la Figura 2.4.
2.4. Evolución de las aplicaciones Web
Antiguamente, una página web tradicional de cualquier empresa utilizaba, como

red de comunicaciones con los usuarios, una página estática, un folleto online con
textos e imágenes [15]. Para interactuar con la empresa y tener más conocimiento de
sus servicios, el usuario debı́a comunicarse mediante correo electrónico o buscando
un teléfono de contacto para contactar con el servicio técnico.
La necesidad de mejorar los servicios de comunicación online ha supuesto la crea-
ción de unos marcos de desarrollo, denominados frameworks, que se incorporan en
las aplicaciones Web para mejorar su flexibilidad y aportar una capacidad dinámica,
aspectos que se traducen en una mayor interacción entre los usuarios y el entorno
de la página Web.
Actualmente, mediante este tipo de desarrollo de aplicaciones Web, internet ha
evolucionado mejorando la experiencia del usuario mejorando la comunicación y evi-
tando pérdidas de tiempo innecesarias.
La aplicación implementada en este proyecto se desarrolla mediante el framework

AngularJS. A continuación se comentan los aspectos más importantes de Angular y
se realiza una comparación con otros frameworks utilizados en la actualidad.
2.4. EVOLUCIÓN DE LAS APLICACIONES WEB 13
Figura 2.4: Arquitectura a alto nivel de una aplicación Cordova [26].
2.4.1. Framework AngularJS

AngularJS [25] es un framework de Javascript de código abierto desarrollado
por Google e introducido a mediados del año 2012. Se ha popularizado entre los
desarrolladores web y los ingenieros UI.
Es un marco estructural para aplicaciones web dinámicas. Permite utilizar HTML
extendiendo su sintaxis y añadiendo al lenguaje estático una funcionalidad dinámica.
De esta manera es posible una mayor interacción entre el usuario y la aplicación.
Para resolver el problema de la concordancia entre aplicaciones estáticas y dinámi-
cas se utiliza una librerı́a que contiene una colección de funciones útiles para apli-
caciones web además de frameworks para completar los detalles del código.
Angular permite al navegador entender esta nueva sintaxis mediante unas direc-
tivas, que incluyen: un enlace de datos entre el código Javascript y HTML; unas
estructuras de control del DOM que permiten repetir, mostrar u ocultar fragmen-
tos del DOM; un soporte y validación de formularios; y agrupación de HTML en
componentes reutilizables.
La virtud en el desarrollo de aplicaciones que proporciona Angular es un nivel
de abstracción mayor para el desarrollador, aunque esto tiene sus consecuencias en
cuanto a flexibilidad. Por tanto, hay ocasiones en las que no es la mejor opción para
desarrollar una aplicación. Angular se basa en una aplicación CRUD (Create, Read,
Update, Delete), que es el método que utilizan la mayorı́a de las aplicaciones web. Los
casos en los que no es recomendable la utilización de Angular serı́an desarrollos de

videojuegos o editores GUI, que presentan una manipulación intensiva y complicada
del DOM. En estos casos suele ser mejor utilizar una librerı́a con menor nivel de
abstracción, como es JQuery.
Angular se utiliza para crear SPAs (Single-Page Applications), es decir, aplica-
ciones de una sola página, que proporcionan una mayor velocidad en la ejecución
cargando al inicio todos los elementos y evitando cargar continuamente las páginas
durante el transcurso de éstas.
A continuación se destacan una serie de ventajas de Angular:
Desacopla la manipulación del DOM de la lógica de la aplicación. Esto es útil

para facilitar las pruebas o testing de código.
Desacopla el lado del cliente de una aplicación del lado del servidor. Esto per-
mite el desarrollo en paralelo de ambas partes.
El framework guı́a a los desarrolladores durante la creación y desarrollo de la
aplicación, desde el diseño de una buena interfaz de usuario hasta la realización
de pruebas o testing.
Evita el registro de la devolución de llamadas, que suelen estorbar el código.
Extrae el código repetitivo común, que aumenta la cantidad de codificación de
Javascript y, por tanto, dificulta la lectura y comprensión del funcionamiento
de la aplicación.
Evita la manipulación de programación HTML del DOM, que es propenso a
errores en aplicaciones AJAX. Esto se soluciona describiendo de forma decla-
rativa la forma en que la interfaz de usuario cambia en función del estado de
la aplicación sin necesidad de manipular el DOM a bajo nivel.
Evita la escritura de una estructura de código compleja y abundante en la
inicialización de código mediante sus servicios de autoinyectado, que permite
empezar a desarrollar funciones de una forma rápida y controlada.
2.4.2. Comparativa entre AngularJS y otros frameworks

Además de AngularJS, se utilizan en la actualidad otros frameworks y librerı́as
para el desarrollo de aplicaciones Web, entre las que se encuentran jQuery, Backbo-
neJS, EmberJS y ReactJS.
jQuery vs AngularJS
jQuery es una librerı́a que sirve para acceder al estado de cualquiera de los ele-
mentos de una página. Mediante los selectores de CSS y los creados por el propio
jQuery se puede leer y modificar las propiedades de los elementos, ası́ como suscri-
birse a los eventos producidos en esos elementos de una forma mucho más cómoda
que utilizando únicamente Javascript.
En cuanto a la comparación entre jQuery y Angular, cabe destacar que el alcance
de estas dos librerı́as es distinto. En primer lugar [23], Angular pasa de denominarse
librerı́a a constituir un framework de aplicaciones Web por ofrecer una serie de
normas y hábitos en la programación gracias al patrón MVC implementado. Además
2.4. EVOLUCIÓN DE LAS APLICACIONES WEB 15
de permitir acceder y modificar los elementos de una página, Angular proporciona un

conjunto de mecanismos para extender el HTML y hacerlo más semántico, ahorrando
de esta manera cierta cantidad de código para realizar las mismas funciones.
Una desventaja considerable de Angular es la depuración de errores Javascript,
debiendo tener especial cuidado en todo momento de lo que se escribe intentando
evitar errores en la estructura.
Como se ha comentado anteriormente, el objetivo de cada una de ellas es distinto,
esto quiere decir que es posible realizar una aplicación compleja con el framework
Angular complementando su estructura con funciones de jQuery.
BackboneJS vs AngularJS
Backbone es una librerı́a basada en SPA (Single-Page Application), cuyo origen

es más antiguo que el framework Angular. De esta premisa se obtiene la ventaja
de Backbone [16], por llevar más tiempo desarrollando aplicaciones que, por su
complejidad, no compensa realizar una migración a Angular y, por tanto, seguir
desarrollándose con esta librerı́a.
Sin embargo, el coste de ser una librerı́a más antigua reside en la complejidad
para escribir código, pues en Angular se realiza de una forma más sencilla. Además,
Angular posee muchas más caracterı́sticas y funcionalidades debido a la frecuencia de
actualizaciones por considerarse más atractivo en cuanto al desarrollo. Esto conduce
a otra desventaja de Backbone, ya que el estar menos actualizado conlleva problemas
a la hora de encontrar bugs en escenarios determinados.
EmberJS vs AngularJS
Ember es un framework Javascript que posee una gran cantidad de funcionalida-

des y compite directamente con Angular. Se analizan las ventajas y desventajas de
Ember sobre Angular para decidir cuál es el óptimo para la aplicación.
Entre las ventajas de Ember (Referencia curso) [12] cabe destacar que posee un
mayor rendimiento, un mejor servicio de rutas, se basa en el Principio de Acceso
Uniforme (no diferencia entre trabajar con atributos, propiedades o métodos) y se
basa en el paradigma Convención sobre Configuración (simplifica las decisiones de
un desarrollador para lograr un comportamiento deseado sin perder flexibilidad).
Comentados los aspectos más relevantes de Ember, es momento de argumentar

la elección de Angular.
Angular sigue la filosofı́a POJSO (Plain Old JavaScript Objects), equivalente a
POJO de Java, que hace referencia a la clásica programación orientada a objetos en
la que un objeto es una instancia de una clase que no extiende ni implementa nada
en especial, que únicamente es una clase de Javascript independiente de Angular.
Esto no ocurre con Ember, que para trabajar con objetos se necesita hacer uso de
mucho código propio dentro de Javascript.
Otro de los aspectos que destacan de Angular es su flexibilidad a la hora de
organizarse y construir una arquitectura propia siguiendo solamente unas pocas
normas de uso obligado. En este sentido Ember posee una arquitectura mucho más
rı́gida.
ReactJS vs AngularJS
React es una biblioteca Javascript que está orientada a la interfaz de usuario y

el renderizado, que no es tan completa como Angular. Están pensadas para cubrir
distintos tipos de necesidades, por eso React podrı́a utilizarse como complemento
de Angular para ofrecer mayor velocidad de ejecución gráfica.
Entre las ventajas de React sobre Angular [16] se encuentran la mayor rapidez
en cuanto a visualización y una mayor cantidad de navegadores que soportan sus
funcionalidades.
Sin embargo, React se comporta únicamente como motor de renderización, esto
significa que no es capaz de realizar otros servicios como routing o comunicación con
el servidor, teniendo que integrar librerı́as de terceros para añadir estas funcionali-
dades. Esto no ocurre con Angular, que posee una solución más completa.
Capı́tulo 3
Proyectos astronómicos de ciencia

ciudadana
3.1. Introducción
En este capı́tulo se hablará de múltiples proyectos astronómicos orientados al
desarrollo de la ciencia ciudadana. La constante evolución de los sistemas robóticos
ha permitido a los observatorios astronómicos poseer un cierto grado de autonomı́a,
ampliando sus capacidades en cuanto al uso de telescopios robóticos de forma remota.
El interés por la investigación y la disponibilidad de recursos limitados ha conducido
a la implementación de nuevos métodos de desarrollo orientados a la llamada ciencia
ciudadana, en la cual todo tipo de personas, dedicadas profesionalmente al sector
o interesadas en la Astronomı́a, puedan realizar una contribución cientı́fica de una
forma educativa e interactiva.
Para descubrir el origen de los métodos de investigación actuales utilizados en
Astronomı́a, es necesario conocer la historia de los Observatorios Robóticos Autóno-
mos.
3.2. Historia de los Observatorios Robóticos Autónomos

La historia de la robótica [8] comienza en 1921 con los primeros autómatas lla-
mados “robots”. A lo largo de los años el concepto de robot ha ido evolucionando
debido al desarrollo cientı́fico y tecnológico. Es posible definir el concepto de Robot
como un sistema mecánico que ejecuta tareas remotas preprogramadas con asisten-
cia humana, pero la evolución ha permitido considerar otros conceptos como Robot
Teleoperado, cuyo comportamiento puede ser modificado dinámicamente por el ser
humano, o Robot Autónomo, que es capaz de adaptarse al cambio durante la eje-
cución de una tarea sin la intervención humana. Estos conceptos concluyen en la
definición de Robot Inteligente, el cual es capaz de realizar cualquier tarea compleja
con semejanza a la inteligencia humana.
La Astronomı́a ha adquirido un gran progreso en cuanto a la automatización de
los observatorios, considerando la aplicación de sistemas robóticos. Los telescopios
han sido materia de investigación durante los últimos años, adaptándose al progreso
tecnológico y desarrollando su concepto hacia el campo de la robótica.
Es posible realizar un paralelismo entre los conceptos de robótica y su aplicación
en la Astronomı́a, pudiendo definirse el concepto de Telescopio Programado Auto-
17
18 CAPÍTULO 3. PROYECTOS ASTRONÓMICOS DE CIENCIA CIUDADANA
matizado (Robot) como un telescopio que realiza observaciones preprogramadas sin

intervención directa del observador; Telescopio Teleoperado (Robot Teleoperado), el
cual es capaz de reaccionar ante la cualquier petición remota del observador; Obser-
vatorio Robótico Autónomo (Robot Autónomo), capaz de adaptarse a los cambios
sin la intervención humana; y Observatorio Robótico Inteligente (Robot Inteligente),
que toma las decisiones mediante un sistema inteligente.
Situando cronológicamente los conceptos definidos anteriormente, es posible se-

pararlos por épocas:
1968-1975. Telescopios Programados Automatizados. La historia de los

telescopios robóticos está relacionada con el desarrollo de los telescopios fo-
toeléctricos automatizados (APTs). El primer telescopio controlado por orde-
nador, representado en la Figura 3.1, fue construido por la Universidad de
Wisconsin en 1968. Tenı́a un tamaño de 0.2m y se utilizó para medir una se-
cuencia fija de estrellas brillantes durante la noche. Es considerado el primer
telescopio programado automatizado.
Figura 3.1: Primer telescopio controlado por ordenador (1968).
1975-1984. Telescopios Operados Remotamente. En 1975 fue completa-

mente automatizado un telescopio de 0.75m, que permitı́a la operación remota
mediante un enlace de microondas. Entre 1976 y 1977 se consiguió controlar
por ordenador un gran telescopio de 2.3m. El primer sistema que ejecutaba
tareas predefinidas de forma repetitiva se logró terminar en octubre de 1983 en
un observatorio de Phoenix (Arizona), con un telescopio de 0.25m de diámetro.
El telescopio se ejecutaba durante toda la noche tomando medidas fotométricas
UBV de las estrellas de forma automática para finalmente desconectarse.
1984-2000. La Era de los Observatorios Robóticos Autónomos. En

1984, el telescopio de 0.18m de diámetro, The Carlsberg Meridian Circle situado
en La Palma (Islas Canarias, España) que se muestra en la Figura 3.2 fue uno de
los primeros telescopios automatizados conjuntamente entre el Observatorio de
la Universidad de Copenhage y el Real Instituto y Observatorio de la Armada
en San Fernando. Se convirtió en uno de los primeros observatorios autónomos.
3.2. HISTORIA DE LOS OBSERVATORIOS ROBÓTICOS AUTÓNOMOS 19
Los primeros telescopios automatizados en observatorios autónomos realizaban

una secuencia preprogramada de medidas fotométricas.
Entre 1987 y 1988 se comenzó a controlar los telescopios enviando los coman-
dos vı́a internet. Se consiguió controlar un dispositivo Alt-Azimuthal y se com-
puterizó una montura ecuatorial. De esta forma, los primeros robots fueron
telescopios con un control de posicionamiento absoluto y sistemas de guı́a. Se
introdujeron estaciones meteorológicas en observatorios astronómicos.
Durante los años 90 se incrementó exponencialmente el número de telescopios
automatizados y muchos de ellos estaban dedicados a observaciones de GRB
(Gamma-Ray Burst). En 1997 se dispuso la disponibilidad pública del primer
telescopio robótico profesional en internet.
Figura 3.2: The Carlsberg Meridian Circle en La Palma (1984). Uno de los primeros observatorios
autónomos.
2001-Actualidad. La Era de las Redes de Observatorios Robóticos

Autónomos. Una gran cantidad de Observatorios Robóticos Autónomos han
surgido durante la primera década. Muchos de ellos se han unido por las pri-
meras redes mundiales, como ROTSE-III, BOOTES, TAROT, MASTER, RO-
BONET o MONET. En cuanto a su distribución por el planeta, existen más de
100 localizadas en un 80 % aproximadamente entre Europa y Estados Unidos,
como se observa en la Figura 3.3.
En la actualidad, los telescopios robóticos se utilizan para múltiples propósitos.

Uno de ellos es el desarrollo de la ciencia ciudadana, proporcionando un espacio de
tiempo para que cualquier persona pueda utilizarlos y contribuir a la mejora de sus
servicios, ası́ como analizar los datos extraı́dos de diversos experimentos para ayudar
a los equipos de investigación a obtener conclusiones fiables. Otro propósito desta-
cable es la utilización de los telescopios en el ámbito educativo, pudiendo realizar
actividades enfocadas al aprendizaje de los estudiantes.
La tecnologı́a continúa evolucionando hacia un futuro donde la asistencia humana
en la toma de decisiones será reemplazada por sistemas inteligentes artificiales. La
tecnologı́a astronómica seguirá avanzando hacia La Era de las Redes Astronómicas
Robóticas Inteligentes.
Figura 3.3: Situación de los telescopios robóticos en el mundo.
3.3. Grupos astronómicos de investigación

En esta sección se muestran algunas organizaciones cientı́ficas orientadas al desa-
rrollo de proyectos de investigación ciudadana en el campo de la Astronomı́a.
Se comentarán los aspectos más relevantes de dos importantes organizaciones
como son el Grupo Cı́clope y la plataforma Zooniverse, ası́ como sus proyectos
dedicados a la ciencia ciudadana.
3.3.1. Grupo Cı́clope

El grupo Cı́clope [9] se encuentra en el Observatorio Astronómico de Montegan-
cedo. Es el primer observatorio astronómico de libre acceso del mundo y que ofrece
software libre. Estas caracterı́sticas proporcionan una herramienta necesaria para la
investigación colectiva y fomentan el crecimiento de la sociedad interesada por la
astronomı́a.
Posee una serie de proyectos dedicados a la investigación cientı́fica que contribu-
yen a la realización de la ciencia ciudadana.
Proyecto GLORIA (2011 - 2014)
GLORIA (GLObal Robotic-telescopes Intelligent Array) [19] es la primera red de

telescopios robóticos del mundo de acceso libre. Es un entorno en el que los propios
usuarios pueden colaborar en la investigación de la Astronomı́a observando el espacio
mediante unos telescopios robóticos, además de analizar los datos adquiridos por
otros usuarios de GLORIA.
La red de telescopios de GLORIA está abierta a cualquier usuario que tenga
curiosidad por el alcance de la astronomı́a. El objetivo de este proyecto es ofrecer
la posibilidad de observar el cielo de cerca desde cualquier lugar para descubrir con
detalle el universo que nos rodea. Para ello se basa en varios propósitos, como son
la creación de una red social para la investigación en astronomı́a, el incremento de
telescopios robóticos de la red mediante una arquitectura estándar (ver Figura 3.4),
el incremento del número de experimentos para resolver los problemas astronómicos,
el crecimiento de la comunidad cientı́fica mediante la motivación a la ciudadanı́a, y
la sostenibilidad de los recursos mediante una comunidad activa.
3.3. GRUPOS ASTRONÓMICOS DE INVESTIGACIÓN 21
El proyecto GLORIA está destinado a la investigación cientı́fica en astronomı́a

por medio del método más clásico de experimentación, la observación del universo.
A través de los telescopios robóticos capaces de apuntar a cualquier parte del cielo,
es posible una completa visualización del entorno. Solamente hace falta mirar en el
lugar correcto en el momento oportuno para detectar objetos en el espacio. La canti-
dad de datos recogidos mediante los experimentos de observación realizados por los
usuarios de GLORIA es capaz de proporcionar un contenido realmente interesante
para la astronomı́a en la actualidad.
GLORIA utiliza una serie de métodos y estándares de utilización de sus servicios,
mediante los cuales se podrán realizar las siguientes actividades:
Controlar los telescopios robóticos, ası́ como su instrumentación, es decir, sus

cámaras, cúpulas, etc.
Dar acceso a la web a un número arbitrario de telescopios robóticos.
Realizar experimentos online con entornos especı́ficos para el control de los
telescopios para la investigación cientı́fica en diversos aspectos.
Realizar experimentos offline para el análisis astronómico de los metadatos
producidos por GLORIA y otras bases de datos.
Figura 3.4: Arquitectura software de la red de telescopios robóticos GLORIA.
Proyecto Cazadores de Asteroides (Actualidad)
Cazadores de Asteroides [13] es un proyecto de ciencia ciudadana que pretende

desarrollar un experimento astronómico que consiste en la búsqueda y localización
de asteroides cercanos a la tierra, denominados NEAs (Near Earth Asteroids) o

NEOs (Near Earth Objects).
Este experimento se desarrollará a través de una aplicación móvil, la cual mos-
trará imágenes recogidas por los telescopios de la red GLORIA y los usuarios tendrán
la posibilidad de observar y encontrar asteroides para conseguir premios otorguen
privilegios necesarios para la utilización de los telescopios de GLORIA.
Posteriormente, en los siguientes capı́tulos del documento, se tratará más en
detalle la implicación del Trabajo de Fin de Grado en el Proyecto Cazadores de
Asteroides.
Proyecto MEGARA (2010 - Actualidad)
MEGARA (Multi-Espectrógrafo en GTC de Alta Resolución para Astronomı́a)

[24] será el instrumento óptico del Gran Telescopio Canarias. Una vez instalado, ofre-
cerá dos diferentes modos de observación a la comunidad, el modo Large Compact
Bundle (LCB) que consta de una unidad de campo integral que cubre 12.5”x11.3” en
el cielo, y un modo Multi-Object Spectroscopy (MOS) que permitirá la observación
de 100 objetos en una región de 3.5’x3.5’ alrededor del LCB. Los intereses cientı́ficos
se centran en el estudio de galaxias cercanas y nebulosas planetarias y en el estudio
de las fuentes puntuales con densidades superficiales altas, teniendo interés en los
cúmulos de galaxias con alto desplazamiento al rojo.
Una de las futuras posibilidades, posteriores a la finalización de este proyecto,
serı́a incluir el Gran Telescopio Canarias en la red de telescopios robóticos GLORIA.
Proyecto ASTROCAM (2006 - 2009)
ASTROCAM (Red de Astrofı́sica de la Comunidad Autónoma de Madrid) [2],

red en la que participan cientı́ficos de diversas universidades y empresas tiene como
objetivo potenciar actividades para difundir los logros de la Astronomı́a a la socie-
dad, aumentando la visibilidad de la investigación que se lleva a cabo en la CAM. En
este campo se encuentra grupo Cı́clope y su amplia experiencia en la teleoperación y
control remoto de telescopios. Además, permitirá divulgar los avances en Astrofı́sica
en los centros de educación secundaria y al público en general. El interés de este
proyecto reside en la necesidad de informar a la sociedad de los avances cientı́ficos
sobre la evolución del Universo o el origen de la vida en la Tierra.
Este proyecto posee otros intereses en cuanto a la enseñanza de Astronomı́a,
como es la creación de un Máster Universitario en Astrofı́sica para estimular la
participación de investigadores, o la explotación cientı́fica de multitud de recursos e
instalaciones disponibles, siempre orientado a la preparación, formación y motivación
de la comunidad cientı́fica.
Proyecto COLDEX (2002 - 2005)
COLDEX [10] tiene como objetivo fomentar la experimentación cientı́fica, el mo-

delado y la simulación con herramientas computacionales de escenarios pedagógicos
para el estudio de percepción visual, incluyendo mediciones astronómicas y sı́smi-

cas, desde un punto de vista cientı́fico y una experiencia subjetiva. El proyecto está
destinado a estudiantes de educación secundaria.
Para explorar los fenómenos cientı́ficos el proyecto cuenta con acceso remoto a un
espacio que ofrece datos experimentales en diversos campos. Los fenómenos experi-
mentales a ser estudiados son: la astronomı́a, con acceso remoto a los observatorios;
los fenómenos sı́smicos, que proporcionan datos continuos de las actividades sı́smicas
en una región activa; la navegación por escenarios virtuales de percepción limitada
en situaciones cotidianas, por ejemplo, la simulación de una persona ciega en el me-
tro; las reacciones de las plantas, los animales y las personas a ciertas condiciones
ambientales, como cambios estacionales del clima; y fenómenos ópticos en ingenierı́a
mecánica y quı́mica, como la fotoelasticidad.
3.3.2. Grupo Zooniverse

Zooniverse [37] es la plataforma más grande y popular dedicada a la investigación
colectiva. Su objetivo es contribuir a la investigación por parte de voluntarios, ası́
como la realización de proyectos académicos.
Posee un amplio conjunto de proyectos cientı́ficos clasificados en diversos campos
de estudio, entre los que se encuentra la Astronomı́a. Sus proyectos están orientados
al desarrollo de la ciencia ciudadana.
Proyecto GALAXY ZOO
Galaxy Zoo [34] es un proyecto dedicado al estudio de las galaxias que se en-
cuentran a nuestro alrededor. Con la observación de las galaxias formadas se puede
conocer en cierta medida el pasado, presente y futuro del Universo.
Las observaciones de imágenes proporcionadas por la Cámara de Gran Angular
3 (WFC3) del Hubble permiten realizar una clasificación de las galaxias según su
forma. Se pueden clasificar en varios bloques: galaxia con forma lisa y redondeada,
galaxia con discos o formas caracterı́sticas, o galaxia no identificada por su forma
de estrella u otro artefacto.
Proyecto RADIO GALAXY ZOO
Radio Galaxy Zoo [35] es un proyecto dedicado a la búsqueda de agujeros negros

en erupción. Los agujeros negros se encuentran en el centro de todas o casi todas
las galaxias.
Las imágenes procedentes del Very Large Array (VLA) y del Australia Telescope
Compact Array (ATCA) proporcionan datos de ondas de radio. También se utilizan
imágenes en infrarrojo que provienen del Wide-Field Infrared Survey Explorer (WI-
SE), que muestran las galaxias que emiten su luz como una combinación de estrellas
frı́as, polvo calentado por la luz estelar y emisiones de un agujero negro supermasivo.
Con la combinación de los dos tipos de imágenes proporcionados, se examinan
visualmente las imágenes resultantes y se comparan los datos para obtener el lugar
exacto de los agujeros negros.
Proyecto RADIO METEOR ZOO
Radio Meteor Zoo [36] es un proyecto enfocado a la identificación de ecos de

meteoros durante las lluvias de meteoritos. Los datos producidos por la red de esta-
ciones de radio BRAMS (Belgian Radio Meteor Stations) se presentan generalmente
en forma de espectrogramas que, mediante una serie de algoritmos, es posible la de-
tección automática de formas especı́ficas asociadas a los ecos de meteoros.
Las observaciones de radio poseen ciertas ventajas sobre las ópticas, como la
posibilidad de extraer datos independientemente de las condiciones meteorológicas
y la sensibilidad de detección de algunos meteoritos menores que no producen ningún
tipo de luz visible.
En el experimento se muestran unas imágenes de un transmisor que contienen
información de ondas de radio reflejadas en un espacio temporal y frecuencial, en
el que aparecen señales en un intervalo corto de tiempo pertenecientes a ecos de
meteoros y señales de larga duración que son reflejos de la onda de radio de los
aviones. El objetivo del usuario consiste en detectar y señalar las zonas donde se
encuentran los ecos de meteoros.
Proyecto PLANET HUNTERS
Planet Hunters [21] es un proyecto dedicado a la detección de planetas extraso-

lares (exoplanetas) que orbitan alrededor de otras estrellas. Cuando un exoplaneta
transita por delante de su estrella, la luz de dicha estrella se atenúa momentánea-
mente disminuyendo el brillo detectable.
Las imágenes proporcionadas por la nave espacial Kepler de la NASA constituyen
una serie temporal de mediciones de brillo de una estrella. Las curvas de luz sirven
para analizar las señales repetitivas del tránsito de un planeta. Durante el experi-
mento, se muestran imágenes de curvas de luz de una estrella y el objetivo consiste
en encontrar planetas al ver cómo el brillo de la estrella cambia en un intervalo de
tiempo.
Para la realización del experimento no es necesario poseer grandes conocimientos
en la materia, únicamente ser un buen observador.
Proyecto SUPERNOVA HUNTERS
Supernova Hunters [22] es un proyecto centrado en el descubrimiento de nuevas

supernovas. Las supernovas son estrellas que estallan con una gran cantidad de
energı́a que necesitan ser estudiadas para comprender la evolución de las estrellas y
realizar predicciones sobre la frecuencia con la que se producen.
Las imágenes captadas por el Pan-STARRS (Telescopio de Investigación Pa-
norámica y Sistema de Respuesta Rápida) inicialmente se utilizaban para la búsque-
da de objetos cercanos a la tierra, pero también se utilizan para la identificación de
supernovas. Se complementa del PESSTO (Estudio Espectroscópico Público de Ob-
jetos Transitorios) para confirmar los descubrimientos de supernovas y realizar un
seguimiento a lo largo de su evolución.
El experimento muestra tres imágenes distintas. Una de ellas es la imagen de
referencia tomada hace unos años, otra es una imagen más actual y la tercera es una
imagen obtenida de la diferencia entre las dos imágenes anteriores. El objetivo es
detectar nuevas supernovas mediante la observación de la luz emitida en un punto

en el transcurso temporal, considerando opción afirmativa si en la imagen antigua
no aparecı́a la luz y en la reciente sı́.
Los usuarios que realicen el experimento contribuirán al aporte de clasificaciones
útiles para la mejora de los algoritmos y a la reducción del número de detecciones
falsas que se producen con el software actual.
Proyecto COMET HUNTERS
Comet Hunters [20] es un proyecto enfocado al aumento de la tasa de descu-

brimiento de cometas situados en el cinturón principal de asteroides del Sistema
Solar.
Las imágenes extraı́das del Telescopio Subaru ubicado en Maura Kea (Hawai) son
capaces de detectar la actividad más débil de los asteroides del cinturón principal.
Debido a la dificultad del diseño de rutinas automatizadas para la detección de
los cometas, es necesaria la intervención humana para la observación de diversos
tamaños y formas de las colas que indican la actividad del cometa.
El experimento tiene como objetivo la identificación de las colas de los asteroides
para la distinción de los cometas. Se muestran dos imágenes del mismo asteroide
tomadas en diferentes momentos de la noche, y si se puede identificar su cola, se
trata de un cometa.
Proyecto PLANET FOUR
Planet Four [17] es un proyecto diseñado para ayudar a los cientı́ficos que estudian
los planetas a identificar y medir las formaciones de la superficie de Marte, las cuales
no existen en la Tierra. Las formaciones que se desea buscar se clasifican en abanicos
y manchas, que son necesarias para entender mejor el clima de Marte.
Las imágenes provenientes de la cámara HiRISE (High Resolution Imaging Scien-
ce Experiment) que el Mars Reconnaissance Orbiter lleva a bordo se analizan me-
diante la participación ciudadana para posteriormente confeccionar un mapa fiel de
las formaciones de la superficie de Marte. El experimento muestra una imagen en
la que se pueden marcar elementos como abanicos, manchas u otras formaciones
interesantes.
Proyecto PLANET FOUR: TERRAINS
Este proyecto, al igual que el proyecto Planet Four, trata de identificar el terreno
de la superficie de Marte. Planet Four: Terrains [30] tiene como objetivo observar la
región del polo sur de Marte en busca de tipos de terreno informalmente llamados
?arañas?, ?arañas bebé?, ?redes de canales? y ?queso suizo? para ayudar a localizar
los cráteres.
El experimento muestra una imagen del terreno exótico y se ha de seleccionar la
opción más adecuada a sus caracterı́sticas.
Proyecto SUNSPOTTER
El proyecto Sunspotter [28] está enfocado al estudio de las manchas solares, cons-
truyendo una medición de la complejidad del grupo de manchas. El objetivo es lograr
un mejor entendimiento sobre la causa de las erupciones en las manchas solares, ası́
como mejorar la capacidad de predicción de dichas erupciones.
Este experimento utiliza los resultados obtenidos por la ciudadanı́a para mejorar
el algoritmo automático de clasificación de las manchas solares.
Proyecto DISK DETECTIVE
Disk Detective [14] es un proyecto dedicado a la búsqueda de estrellas con discos

de escombros similares al cinturón de asteroides localizados a su alrededor. Estos
discos proporcionan información del lugar donde se están formando planetas, y están
compuestos de enormes nubes de gas, polvo y pedazos de roca.
Este proyecto utiliza los datos de Wide-field Infrared Survey Explorer (WISE),
Two Micron All Sky Survey (2MASS), Digitized Sky Survey (DSS) y de Sloan Digital
Sky Survey (SDSS).
El experimento muestra una secuencia de imágenes que contienen un objeto con
unas ciertas caracterı́sticas. El objetivo es identificar las propiedades del objeto entre
distintas opciones, como son la detección de múltiples objetos, el movimiento del
objeto hacia el exterior de la imagen, la extensión del objeto fuera de los lı́mites en
imágenes WISE, la ausencia de objetos en imágenes WISE, o la forma del objeto no
es circular en imágenes DSS2 o 2MASS.
Proyecto POPPIN’ GALAXY
Poppin’ Galaxy [18] es un proyecto que tiene como objetivo completar el estudio
estadı́stico más masivo de la deformación galáctica con unas 10000 muestras. Para
ello, es necesario medir la amplitud de la estructura deformada y clasificar el tipo
de deformación mediante investigación visual. Las galaxias se pueden clasificar en
varios tipos según la forma de la deformación de los extremos del disco, existiendo
estructuras tipo S, L, U y no deformada.
Las imágenes mostradas en este experimento contienen objetos que han de ser ve-
rificados manualmente como galaxias por su tamaño y forma, y además si se verifica
la afirmación, se permite clasificar entre los diversos tipos morfológicos enumerados
anteriormente.
Capı́tulo 4
Desarrollo de la aplicación móvil
En este capı́tulo se detallará el proceso de desarrollo de la aplicación móvil, ası́

como la estructura del programa.
4.1. Introducción
El propósito de esta aplicación es proporcionar un espacio de tiempo a los usua-

rios para poder utilizar y controlar los telescopios robóticos de la red, con el objetivo
de capturar imágenes del cielo y observar la cantidad de información que se puede
obtener del Universo.
Esta aplicación dedicada a la teleoperación de los telescopios de la red GLORIA

puede ser utilizada de dos formas distintas.
La primera posibilidad consiste exclusivamente en proporcionar todos los servicios
de GLORIA mediante una aplicación independiente equivalente a la aplicación Web
para usuarios del Proyecto GLORIA [31] comentado anteriormente.
La otra posibilidad es la integración de los servicios de teleoperación en la aplica-
ción Cazasteroides, que pertenece al Proyecto Cazadores de Asteroides mencionado
en el capı́tulo anterior [13]. Mediante la aplicación Cazasteroides el usuario obtendrá
una serie de premios valorados en puntos que podrán ser canjeados por una canti-
dad de tiempo para acceder a los telescopios robóticos y realizar cualquiera de los
experimentos de teleoperación.
Además de las diferencias estructurales y funcionales entre las dos opciones de

implementación, una diferencia significativa reside en el tipo de usuario que recibe
los servicios, pues utilizan bases de datos distintas que, a efectos de usuario, le
permiten gestionar las reservas de los experimentos de forma distinta.
En la aplicación GLORIA (ver Figura 4.1) se puede reservar de forma limitada y
equitativa entre todos los usuarios únicamente en los horarios disponibles, mientras
que en la aplicación Cazasteroides (ver Figura 4.2) los tiempos de experimentación y
preferencias entre usuarios son más flexibles debido a la gestión mediante el sistema
de puntos.
27
28 CAPÍTULO 4. DESARROLLO DE LA APLICACIÓN MÓVIL
Figura 4.1: Esquema de la estructura de la aplicación GLORIA.
Figura 4.2: Esquema de la estructura de la aplicación Cazasteroides.
4.2. Creación de la aplicación

En esta sección se detallan los pasos a seguir para la creación de la aplicación en
distintas plataformas y la introducción del contenido a desarrollar. La realización de
este cometido se realiza mediante el framework Apache Cordova [32], que necesita
la previa instalación de una serie de requisitos para cada plataforma.
4.2.1. Instalación de los componentes

En primer lugar, se procede a instalar los SDK de las distintas plataformas.
4.2. CREACIÓN DE LA APLICACIÓN 29
Herramientas de desarrollo de Android
Uno de los requisitos para Android SDK es el Java Development Kit (JDK).
En Mac, Java deberı́a estar disponible sin necesidad de descarga, de no ser ası́ se
seguirı́a el proceso de descarga e instalación desde la página http://www.oracle.
com/technetwork/java/javase/downloads/index.html.
Windows requiere de la instalación obligatoria. Una vez descargado e instalado,
el siguiente paso para finalizar la instalación de Java es necesario definir la variable
de entorno JAVA HOME en la Configuración avanzada del sistema.
En este momento se procede a la descarga de Android SDK desde la página
para desarrolladores de Android (https://developer.android.com/index.html).
La descarga del SDK incluye las herramientas para construir y emular aplicaciones
Android, además de incluir una versión preconfigurada de Eclipse. Sin embargo, no
posee las librerı́as SDK ni los emuladores de dispositivos, por lo que se deberán de
descargar mediante el SDK Manager siguiendo las instrucciones del siguiente enla-
ce: https://developer.android.com/studio/intro/update.html. Al no requerir
instalación estos componentes, es necesario añadir al sistema los directorios (PATH)
donde se encuentran descargados los componentes, de esta forma el CLI es capaz de
encontrar las carpetas de dichas herramientas.
Tras realizar estos pasos, los últimos elementos que deben descargarse se encuen-
tran en el SDK Manager, que contiene todas las versiones del sistema operativo. En
este momento se seleccionan las necesarias dependiendo de los dispositivos a los que
se quiera destinar la aplicación.
Herramientas de desarrollo de iOS
Antes de comenzar con el desarrollo en iOS, se debe ingresar en el programa Apple

iOS Developer. Se puede encontrar más información en https://developer.apple.
com/programs/ios.
Después de esto, se instala el Xcode IDE desde el App Store de Mac. La apli-
cación proporciona también las herramientas del CLI y emuladores que necesitan
ser instalados. Para ello, se accede a la sección de Preferencias y en el apartado de
Descargas se seleccionan los componentes del Command-Line Tools, para el correcto
funcionamiento de Cordova, y las versiones de iOS necesarias para la aplicación.
Herramientas de Apache Cordova
Tras la instalación de los SDK, se procede a instalar el framework de Apache

Cordova.
Para gestionar el proyecto de forma sencilla mediante Cordova, se requiere de
la instalación del CLI (Command-Line Inferface). El CLI está construido usando
código Javascript con el motor de ejecución Node.js (obtenido de www.nodejs.org).
Se distribuye como un paquete npm, por lo que se instala mediante la siguiente lı́nea
de comandos dependiendo del sistema operativo:
Windows:
C:\ > npm i n s t a l l −g c o r d o v a
Mac:
$ sudo npm i n s t a l l −g c o r d o v a
Para la creación del proyecto se accede desde la terminal al directorio que se desee
y se escribe el siguiente comando:
c o r d o v a c r e a t e p r o j e c t f o l d e r a p p i d app name
donde se especifica el nombre de la carpeta que contiene el proyecto (project folder),

el ID de la aplicación (app id) y el nombre de la aplicación (app name). El CLI se
ejecuta y crea la estructura que organiza el proyecto de Cordova. Se encuentran
distintos directorios en el proyecto:
En la carpeta www se desarrolla la aplicación. Aquı́ se encuentran los directorios

que agrupan los elementos de creación de aplicaciones Web, como son HTML,
CSS y Javascript, además de contener un elemento denominado index.html que
será la página principal sobre la cual se desarrolla la aplicación.
En la carpeta platforms se administran las distintas plataformas contenidas en
el proyecto. Cordova se encarga de generar el contenido necesario para cada
plataforma, por lo que no es aconsejable modificarlo.
En la carpeta plugins se instalan los plugins necesarios en la aplicación.
El archivo config.xml contiene los parámetros de la aplicación, como nombre,
autor, etc.
En este proyecto únicamente se utiliza un plugin para estandarizar la vista de

la aplicación en cualquier dispositivo Android. Consiste en cambiar el WebView
predeterminado del sistema por un WebView propio denominado Crosswalk. Esto
ofrece la ventaja de la independencia del navegador y la versión de cada dispositivo
con la aplicación, además de conseguir una mejora en el rendimiento en comparación
con los navegadores nativos. En inconveniente de este plugin es el incremento del
tamaño de la aplicación, aun ası́ es recomendable su instalación. Para ello, se añade
en la consola el siguiente comando:
c o r d o v a p l u g i n add cordova−p l u g i n −c r o s s w a l k −webview
Las plataformas utilizadas para la aplicación (Android, iOS) se añaden de la

siguiente forma:
Android:
c o r d o v a p l a t f o r m add a n d r o i d
iOS:
c o r d o v a p l a t f o r m add i o s
4.2.2. Construcción de la aplicación

Una vez finalizada la instalación de todos los componentes de la aplicación, se
procede a desarrollar todo el contenido. Se detallarán la estructura y el desarrollo
en las siguientes secciones.
Tras haber desarrollado el contenido del proyecto, es el momento de realizar la

construcción de la aplicación multiplataforma. El procedimiento que efectúa Cor-
dova consiste en la preparación y compilación del proyecto. La preparación copia
4.3. ESTRUCTURA DEL CONTENIDO 31
el contenido de la aplicación Web procedente del directorio www y organiza las

carpetas en los distintos directorios de las plataformas. El proceso de compilación
utiliza unos scripts especı́ficos de cada plataforma para compilar la aplicación nativa
preparada anteriormente. Con esto se consigue integrar una aplicación Web en una
estructura nativa.
Para realizar este procedimiento se utilizan unos comandos dependiendo de la
plataforma:
Android:
cordova b u i l d android
iOS:
cordova b u i l d i o s
Este proceso genera los archivos necesarios para la directa instalación de la apli-
cación en el dispositivo móvil. En el caso de Android genera el archivo APK para
las arquitecturas X86 y ARM. En la plataforma iOS se genera el archivo APP.
Con este método concluye la creación de la aplicación multiplataforma.
Es necesario comprobar el correcto funcionamiento de la aplicación en las distintas

plataformas, por ello se hace uso de los respectivos simuladores de dispositivos.
Para ello, únicamente se precisa la utilidad de un comando utilizado para todas las
plataformas:
Android:
cordova emulate android
En este caso también se puede ejecutar la aplicación con otro comando del CLI:
c o r d o v a run a n d r o i d
iOS:
cordova emulate i o s
4.3. Estructura del contenido

En esta sección se detalla la estructura de funcionamiento de la aplicación, ası́
como los métodos de personalización de la interfaz de usuario.
En primer lugar, es necesario tener en cuenta el tipo de funcionalidades que

caracterizan a la aplicación, pues su propósito principal es el acceso a una serie de
servicios proporcionados por un servidor Web que son fundamentales para realizar
las operaciones mediante control remoto.
Para acceder a los distintos servicios que ofrecen los telescopios se utiliza la API
REST de GLORIA, que contiene los métodos de envı́o de datos, obtención de infor-
mación y permisos necesarios para realizar cualquier operación.
La API de GLORIA está implementada en AngularJS, por lo que se decide uti-
lizar este framework en el desarrollo de la aplicación para integrar los servicios de
la API de una forma sencilla y bien estructurada.
Para realizar la aplicación mediante las funciones de Angular, es necesario seguir

su estructura predefinida, que abarca tanto aspectos de funcionalidad interna como
la interfaz de usuario.
La arquitectura de Angular se basa en el patrón MVC (Model-View-Controller)
(ver Figura 4.3), que divide la interfaz de usuario de la parte funcional de la aplica-
ción. Se distinguen tres componentes esenciales:
1. Modelo: Es el encargado de gestionar los datos de la aplicación y responder a las

peticiones de la Vista y a las instrucciones del Controlador para actualizarse.
2. Vista: Es el responsable de representar visualmente los datos en un formato

particular mediante las decisiones tomadas por el Controlador.
3. Controlador : Responde a las peticiones del usuario y realiza interacciones en

los objetos del Modelo de datos.
Figura 4.3: Esquema de funcionamiento de AngularJS [25].
La estructura del programa está definida por una serie de elementos que pertene-
cen a la arquitectura de funcionamiento de Angular y se clasifican en los siguientes
conceptos:
Plantilla: En Angular se utilizan plantillas escritas en HTML que contienen

atributos y elementos especı́ficos de Angular. Se combina la información de la
plantilla con la información del modelo y del controlador para conseguir una
vista dinámica para el usuario.
4.3. ESTRUCTURA DEL CONTENIDO 33
Directivas: Son marcadores en un elemento del DOM que utilizan el compilador

HTML de Angular para obtener un comportamiento especı́fico del elemento. Se
utilizan para ejecutar una función de Javascript mediante un evento producido
sobre un elemento del HTML.
Servicios: Son objetos o funciones que realizan una prestación especı́fica uti-
lizados para organizar o compartir código en la aplicación. Angular sólo crea
una instancia de un servicio cuando un componente depende de ello. También
pueden tener sus propias dependencias.
Scope: Es un objeto referido al modelo de la aplicación. Se considera el enlace
entre el controlador y la vista, por ello todas variables de cualquier tipo utili-
zadas en el controlador que se vayan a necesitar en la interfaz de usuario deben
ser objetos scope.
Controladores: Son funciones constructoras de Javascript que contienen scopes
para comunicarse con el DOM. Se utilizan para configurar el estado inicial y
proporcionar comportamiento a los objetos scope con el fin de reaccionar a los
eventos. También realizan la inyección de dependencias y servicios necesarios.
Módulos: Son elementos que contienen los distintos componentes de la apli-
cación, como controladores, servicios, directivas, etc. Se organizan en bloques
de configuración y ejecución que se aplican al programa durante el proceso de
arranque.
Además de los servicios básicos de Angular, también se hace uso de una serie
de módulos y dependencias externas (ver Figura 4.4) con el objetivo de ampliar las
funcionalidades y ofrecer una interfaz de usuario adaptada a los dispositivos móviles.
Los módulos de Angular aportan las siguientes funcionalidades al programa:
Módulo ngRoute: Proporciona servicios de enrutamiento y directivas para la

aplicación. El método de trabajo consiste en Single-Page Application (SPA),
que proporciona rapidez de ejecución en el tránsito entre rutas. Cada ruta
debe tener una página HTML asociada, que se cargará al acceder a ella, y un
controlador necesario para gestionar las funcionalidades.
Módulo ngAnimate: Proporciona soporte para las animaciones basadas en CSS
y Javascript.
Módulo ngTouch: Proporciona eventos táctiles y otros servicios para dispositi-
vos táctiles. Su implementación está basada en el manejo de eventos de jQuery
Mobile.
Módulo ngCookies: Proporciona un servicio de lectura y escritura de cookies.
Módulo Locale: Proporciona servicios para internacionalizar la aplicación, es de-
cir, para utilizar la aplicación en múltiples idiomas con la capacidad de añadirlos
de forma sencilla.
Angular Material : Proporciona componentes de visualización para la interfaz
de usuario.
Figura 4.4: Esquema de las dependencias externas de la aplicación.
Bootstrap: Proporciona servicios de personalización de la interfaz orientado a

aplicaciones móviles que utilizan HTML, CSS y Javascript.
También se hace uso de la biblioteca jQuery en conjunto con Angular, una API
que amplı́a las funcionalidades del programa aportando múltiples manejos de even-
tos, funciones de manipulación y animación al documento HTML.
Combinado con los servicios que ofrecen Angular y Bootstrap, el framework
jQuery Mobile presenta un conjunto de utilidades optimizadas para la interfaz de
usuario de la aplicación, consiguiendo ası́ el aumento de las posibilidades de perso-
nalización y diseño de los elementos que componen la interfaz.
La librerı́a Font Awesome contribuye al diseño de la aplicación por estar consti-
tuida de una serie de iconos de múltiples estilos y temáticas aptos para aplicaciones
Web que incluyan CSS.
4.4. Desarrollo del contenido

En esta sección se explican los métodos de desarrollo utilizados en la aplicación
GLORIA, ası́ como los procedimientos de utilización de los mismos.
4.4. DESARROLLO DEL CONTENIDO 35
El software de la aplicación se desarrolla mediante un sistema de control de versio-

nes utilizando las herramientas Git en el entorno Bitbucket para gestionar el código
del repositorio.
Como se ha explicado anteriormente, la aplicación se realiza mediante la arquitec-

tura de AngularJS, por lo que se debe seguir un procedimiento de desarrollo basado
en su estructura.
Para el comienzo de la aplicación, es necesaria la creación de un módulo que agru-

pa las funcionalidades de Angular. En el módulo se definen los diversos elementos
que permiten configurar la aplicación, como directivas o controladores. El siguiente
paso consiste en añadir los módulos y dependencias externas necesarias para propor-
cionar a la aplicación los servicios y funcionalidades oportunos. En este momento se
incluye también la API REST de GLORIA.
Una vez incluidas las dependencias, es necesario cargarlas en el módulo principal
para que la aplicación dependa de dichos módulos.
Una vez inyectados los servicios en la aplicación, lo primero en lo que se debe
pensar es en el funcionamiento lógico de ejecución, ası́ como el orden de acceso a las
distintas funcionalidades. Para ello, se hace uso del sistema de rutas, que permite
asociar una ruta a una página HTML y a un controlador que realice las funciones
internas.
La estructura de rutas utilizada en esta aplicación está representada en el esquema
de la Figura 4.5. En el organigrama se muestra la jerarquı́a del proceso de ejecución,
desde el comienzo de la aplicación hasta la realización de los experimentos.
Al tener definidas las rutas de la aplicación, se procede a crear las páginas HTML
correspondientes y gestionar los respectivos controladores. Los controladores deben
inyectar las dependencias y servicios necesarios de la aplicación cargados en el módu-
lo principal.
El controlador base de la aplicación es el encargado de hacer el login del usuario y
se denomina “LoginController”. Contiene los servicios de autenticación para realizar
el inicio de sesión y almacenar los parámetros de usuario y contraseña durante la
ejecución del programa. Para mantener la sesión del usuario, este controlador abarca
todas las páginas del documento HTML. De esta manera no se pierde la información
en ningún momento en condiciones normales de conectividad de internet.
Una vez incluido este servicio, se crean el resto de controladores y se gestionan
en función de la ruta en que se encuentren:
LOGIN : En esta página se realiza el inicio de sesión para usuarios registrados.

Se deben introducir los campos de email del usuario y contraseña. Como se ha
comentado anteriormente, el controlador asociado a esta ruta es el “LoginCon-
troller”.
REGISTRO: En esta página se realiza el registro de nuevos usuarios en la base
de datos de la red GLORIA. Para registrarse es necesario introducir el email
del usuario, un alias y una contraseña. El controlador asociado a esta ruta es
el “RegisterController”.
INICIO: Es una página de tránsito donde se accede a las distintas funciona-
lidades y se realiza el cierre de sesión. Entre las funcionalidades accesibles se
Figura 4.5: Esquema de la jerarquı́a de rutas de la aplicación.
encuentran las reservas, la visualización de imágenes y la visualización de tu-

toriales sobre los experimentos en plataforma Web. Esta ruta tiene asociado el
controlador “LoginController”.
IMÁGENES : En esta página se realiza la visualización de las imágenes toma-

das en los distintos experimentos. Se pueden filtrar los resultados por fecha
o mostrar imágenes aleatorias de cualquier usuario o del usuario propio (ver
Figura 4.6). El controlador asociado a esta ruta es el “ImagesController”.
RESERVAS : Es una página de tránsito que puede acceder a las secciones de

nueva reserva y reservas pendientes. Estas rutas tienen asociado el controlador
“ReservationsController”.
NUEVA RESERVA: En esta página se realizan las reservas de los experimentos

mediante la elección de telescopios y fechas disponibles, como se muestra en la
Figura 4.7.
Figura 4.6: Esquema de visualización y búsqueda de imágenes.
Figura 4.7: Esquema de solicitud de una reserva.

RESERVAS PENDIENTES : En esta página se gestionan las reservas realizadas

anteriormente. A través de ella es posible acceder a los experimentos o eliminar
las reservas no deseadas.
EXPERIMENTO SOLAR: En esta página se realiza el experimento Solar. Los
detalles del experimento se explican en el siguiente capı́tulo. El controlador
asociado a esta ruta es el “SolarExperimentController”.
EXPERIMENTO NOCTURNO: En esta página se realiza el experimento Noc-
turno. Los detalles del experimento se explican en el siguiente capı́tulo. El
controlador asociado a esta ruta es el “NightExperimentController”.
Para explicar con detalle el proceso de inyección de servicios y utilización de los
mismos, se utiliza el siguiente ejemplo de solicitud de una reserva mediante el acceso
a la API de GLORIA. Para ello se utiliza la programación de una serie de elementos
en Javascript:
v a r t o o l b o x = a n g u l a r . module ( ’ t o o l b o x ’ , [ ’ ngCookies ’ , ’ ngRoute ’ , ’ ngTouch ’ , ’
n g S a n i t i z e ’ , ’ g l o r i a . ap i ’ , ’ u i . b o o t s t r a p ’ ] ) ;
toolbox . c o n t r o l l e r ( ’ R e s e r v a t i o n s C o n t r o l l e r ’ , f u n c t i o n ( $gloriaAPI , $scope , $ l o c a t i o n ,

$timeout ) {
$ s c o p e . m a k e R e s e r v a t i o n=f u n c t i o n ( ) {
$gloriaAPI . makeReservation ( $scope . experimentSelected , [ $scope . t e l e s c o p e S e l e c t e d
] , $ s c o p e . h o u r S e l e c t e d . b e g i n , $ s c o p e . h o u r S e l e c t e d . end , f u n c t i o n ( data ) {
$ s c o p e . r e s e r v a t i o n . makeSuccess=t r u e ;
$ s c o p e . r e s e r v a t i o n . d a t e=new Date ( $ s c o p e . r e s e r v a t i o n . d a t e ) ;
} , function () {
$ s c o p e . r e s e r v a t i o n . makeSuccess=f a l s e ;
$ s c o p e . r e s e r v a t i o n . d a t e=new Date ( $ s c o p e . r e s e r v a t i o n . d a t e ) ;
}) ;
}
}) ;
En la primera lı́nea se crea el módulo principal “toolbox”, donde se indica

que va a necesitar el uso de distintos servicios, entre los que se encuentra la
API de GLORIA (“gloria.api”), cuyo módulo contiene todos los servicios de
teleoperación necesarios.
El siguiente paso se basa en la creación de un controlador que va a englobar
las funcionalidades relacionadas con la gestión de reservas. En este momento se
añaden los servicios a utilizar en el controlador. Para este ejemplo se hace uso
de $scope y $gloriaAPI.
A continuación se crea una función de tipo $scope necesaria para interactuar
con los componentes de la interfaz de usuario. En este caso, se hace una llamada
a la función en el momento en que el usuario pulsa un botón de solicitud.
Finalmente se hace la llamada al método “makeReservation”proporcionado por
el servicio $gloriaAPI, que se encarga de realizar la solicitud de una reserva con
los parámetros de tipo de experimento, telescopio, fecha y hora de comienzo y
finalización del mismo, que han seleccionados por el usuario y almacenados en
variables $scope.
Según la respuesta del servidor, se gestionan los posibles resultados de petición
correcta o error en la petición. Estos resultados pueden tener efecto visual y/o
funcional, como ejecutar otras funciones o mostrar un mensaje de alerta en
pantalla.
Una vez desarrollada la estructura de funcionamiento de la aplicación, se procede

a realizar el diseño de los componentes visuales de la interfaz de usuario. Para ello se
hace uso de las herramientas proporcionadas por CSS, Bootstrap y jQuery Mobile.
Al poseer pantallas de tamaño limitado, es necesario crear una interfaz manejable y
optimizada para el control táctil de los dispositivos móviles.
Para explicar el desarrollo de la interfaz de usuario se muestra un ejemplo que
contiene componentes de la estructura y elementos de diseño utilizados para la
realización de una reserva explicada en el ejemplo anterior. Para ello se utilizan los
lenguajes HTML y CSS:
<d i v i d =” p r i n c i p a l ” data−r o l e =”page”>
<d i v data−r o l e =”c o n t e n t ” c l a s s =”ui −c o n t e n t ” s t y l e =”padding :0” >
<!−− S e l e c c i ó n de t i p o de e x p e r i m e n t o , t e l e s c o p i o y f e c h a −−>
<!−− . . . −−>
<d i v s t y l e =”f o n t −s i z e :125 %; padding : 10 px 0 5px;” > S e l e c c i o n a e l h o r a r i o : </ div>
<t a b l e ng−show=” r e s e r v a t i o n . a v a i l a b l e ” c l a s s =” t a b l e t a b l e −s t r i p e d ”>
<!−− Encabezado de l a t a b l a −−>
<!−− . . . −−>
<tbody>
<t r ng−r e p e a t =”t i m e L i m i t s i n r e s e r v a t i o n . a v a i l a b l e ” ng−c l i c k =”
reservationSummaryOn ( t i m e L i m i t s ) ” s t y l e =”background−c o l o r : w h i t e ; ” data−t o g g l e =”
modal ” data−t a r g e t=”#a l e r t ”>
<th >{{ t i m e L i m i t s . b e g i n | d a t e : ’HH:mm’}} </ th>
<th >{{ t i m e L i m i t s . end | d a t e : ’HH:mm’}} </ th>
</t r >
</tbody>
</ t a b l e >
</div>
</div>
<d i v c l a s s =”modal f a d e ” i d =” a l e r t ” t a b i n d e x =”−1” r o l e =” d i a l o g ” a r i a −l a b e l l e d b y =”

myModalLabel”>
<d i v c l a s s =”modal−d i a l o g ” r o l e =”document”>
<d i v ng− i f =” h o u r S e l e c t e d . b e g i n && h o u r S e l e c t e d . end && r e s e r v a t i o n . makeSuccess
==n u l l ” c l a s s =”modal−c o n t e n t ”>
<!−− Resumen de l a r e s e r v a −−>
<!−− . . . −−>
<d i v c l a s s =”modal−f o o t e r ”>
<a t y p e=”b ut to n ” c l a s s =”l u k e −bu tt on ” ng−c l i c k =”m a k e R e s e r v a t i o n ( ) ” s t y l e =”
f l o a t : l e f t ”>SOLICITAR</a>
<a t y p e=”b ut to n ” c l a s s =”l u k e −bu tt on ” data−d i s m i s s =”modal”>CANCELAR</a>
</div>
</div>
</div>
</div>
En primer lugar, se observa que la interfaz de usuario en este ejemplo se es-

tructura en dos bloques. El primero contiene los elementos mostrados en la
página y se basa en la estructura jQuery Mobile de organización de contenido.
El segundo corresponde a una ventana de diálogo que se superpone sobre la
página, y está basada en el diseño de Bootstrap. En este ejemplo se resume el
contenido mostrando únicamente la selección de los datos de horarios de una
reserva.
El primer bloque está formado por una tabla con la lista de los horarios de reser-
va disponibles obtenidos de los servicios de la API de GLORIA. Al seleccionar
un horario se abre una ventana de diálogo.
El segundo bloque se activa al seleccionar el horario y muestra un resumen de
los datos de la reserva a realizar. Mediante un botón se hace la llamada a la
función de solicitud de reserva gestionada en Javascript.
Tras finalizar el desarrollo de la aplicación Web, el siguiente paso consiste en la

creación de los archivos de ejecución de la aplicación en el formato nativo corres-
pondiente a las distintas plataformas.
Capı́tulo 5
Experimentos
5.1. Introducción
En este capı́tulo se exponen los distintos experimentos desarrollados en la apli-
cación móvil.
La Red de Telescopios GLORIA consta de 17 telescopios robóticos localizados

en distintos observatorios alrededor del planeta. Actualmente están disponibles seis
de ellos para que los usuarios puedan realizar experimentos desde la aplicación móvil.
Los experimentos pertenecientes al Proyecto GLORIA implementados en la apli-

cación móvil son de carácter online y están basados en la teleoperación de los te-
lescopios robóticos. Se trata de los denominados Experimento Solar y Experimento
Nocturno.
A continuación, se detallarán los objetivos y el alcance de dichos experimentos.
5.2. Experimento Solar

El experimento Solar está basado en la toma de imágenes del Sol para explorar
sus manchas y ayudar a la medición de la actividad solar. El experimento consiste
en generar el mayor número posible de imágenes de la fotosfera solar para conseguir
una mayor precisión en la medida diaria de la actividad solar.
5.2.1. Telescopios del Experimento Solar

El único sistema de telescopios actualmente disponible para realizar este experi-
mento es el TAD.
A continuación, se detallan los aspectos más relevantes de este telescopio.
TADs
El TAD (Telescopio Abierto de Divulgación) [29] es un sistema de telescopios

que se encuentra localizado en el Observatorio del Teide (Instituto de Astrofı́sica de
41
42 CAPÍTULO 5. EXPERIMENTOS
Canarias, Tenerife). Está compuesto por dos telescopios controlados remotamente,

uno de ellos es solar (TADs) y el otro es nocturno (TADn).
El TADs, representado en la Figura 5.1, permite observar la fotosfera solar en
detalle, además de estar provisto de un telescopio utilizado como buscador del Sol.
Figura 5.1: Telescopio TADs ubicado en el Observatorio del Teide (Tenerife).
Para obtener más detalles del telescopio, consultar la Tabla 5.1 de caracterı́sticas
y especificaciones.
Tabla 5.1: Caracterı́sticas y especificaciones del telescopio TAD.
ESPECIFICACIONES
SOCIO IAC
LOCALIZACIÓN Tenerife, España
Latitud: 28.298566 N
COORDENADAS Longitud: 16.509490 O
Altura: 2390m
FECHA DE INICIO Diciembre 2007
FILTROS CFW-9
APERTURA 260mm
DISTANCIA FOCAL 3020mm (f/11.6)
5.2.2. Teleoperación del Experimento Solar

La teleoperación del experimento solar consta de las siguientes funcionalidades:
Visualización de información sobre la reserva. Se incluyen los detalles del teles-
copio y de la reserva, el tiempo restante antes de la finalización del experimento
5.2. EXPERIMENTO SOLAR 43
y la información atmosférica de las condiciones climatológicas recibidas por el

sistema, como la temperatura y la velocidad del viento.
Visualización en tiempo real de la fotosfera solar en detalle mediante el tubo
óptico del telescopio (Referencia figura). El tubo está conectado a una cámara
DBK con un sensor CCD. Mediante estos componentes se obtiene una imagen,
como la representada en la Figura 5.2, proveniente de la radiación que emite
el Sol. La superficie muestra un fondo luminoso debido a la temperatura fo-
tosférica. También se encuentran manchas solares que se forman en oquedades
o depresiones profundas en las que se ve la parte menos caliente y, por tanto,
se muestran más oscuras.
Figura 5.2: Imagen de la fotosfera solar tomada mediante el experimento solar.
Visualización de la fotosfera solar en un entorno amplio del espacio mostrado

en la Figura 5.3 para la localización del Sol. Se utiliza como buscador previo a
la visualización de la fotosfera en detalle.
Figura 5.3: Imagen de búsqueda del Sol utilizada en el experimento solar.
Visualización del sistema de telescopios mediante las cámaras del observatorio.

La cámara exterior representada en la Figura 5.4 apunta al sistema conjunto,
proporcionando una imagen necesaria para la visualización del estado de aper-
tura de la cúpula. La cámara interior visualizada en la Figura 5.5 apunta al
telescopio y se utiliza para observar y comprobar el movimiento de la montura.
Figura 5.4: Imagen del telescopio TADs tomada por la cámara exterior del observatorio.
Figura 5.5: Imagen del telescopio TADs tomada por la cámara interior del observatorio.
Control del apuntamiento del telescopio. Se puede apuntar el telescopio au-

tomáticamente al Sol para que se consiga visualizar la imagen en el visua-
lizador del entorno. Adicionalmente, se puede controlar de forma manual el
direccionamiento del telescopio para centrar la imagen del Sol y visualizarlo
completamente.
Control de la apertura y cierre de la cúpula. Mediante la aplicación se permite

abrir y cerrar la cúpula durante el experimento. Se recomienda cerrar la cúpula
antes de finalizar.
Control de los parámetros de la cámara. Es posible modificar algunos paráme-

tros de la cámara para obtener una imagen óptima del objetivo. Entre dichos
parámetros es posible modificar el tiempo de exposición y el enfoque de la
cámara.
1. Control del tiempo de exposición del obturador de la cámara. Se utiliza

para modificar la cantidad de tiempo que el CCD está recibiendo luz. Para
un tiempo de exposición corto, el obturador permanece abierto poco tiempo
y deja pasar menos luz. Por contrario, para un tiempo de exposición largo,
el obturador permanece abierto más tiempo dejando pasar más luz.
5.3. EXPERIMENTO NOCTURNO 45
2. Control del enfoque de la cámara. Se utiliza para obtener la mayor nitidez

posible en la toma de una imagen. Esto se consigue cuando los rayos de luz
que inciden en la cámara coinciden en un punto de la cámara llamado foco,
que a su vez coincide con el sensor de la cámara. Para realizar el enfoque
sobre el Sol, se deben tener en cuenta las manchas solares, que indican si
se está visualizando de forma correcta o no en función de su nitidez.
Captura de imágenes. Tras configurar los parámetros de la cámara es hora

de tomar una o varias imágenes del Sol, pudiendo modificar cualquiera de los
parámetros tantas veces como sea posible para conseguir una imagen lo más
detallada posible.
Visualización de imágenes. Es posible acceder al visualizador de imágenes to-
madas en cualquier momento para observar los resultados del experimento.
La imagen mostrada en la Figura 5.6 contiene un ejemplo de fotografı́a tomada

durante el experimento.
Figura 5.6: Ejemplo de fotografı́a obtenida por el telescopio TADs durante el experimento solar.
5.3. Experimento Nocturno

El experimento Nocturno tiene como objetivo la observación del cielo nocturno
y la toma de imágenes de estrellas, galaxias y asteroides.
5.3.1. Telescopios del Experimento Nocturno

Entre los sistemas de telescopios disponibles para el experimento Nocturno se
encuentran los telescopios BART, BOOTES-1A, BOOTES-2, TADn, D50 y WAT-
CHER.
A continuación, se detallan los aspectos más relevantes de cada uno de ellos.
BART
BART [3] es un telescopio robótico localizado en el Instituto Astronómico del

CAS (Ondrejov). Es un pequeño telescopio de apertura representado en la Figura
5.7 que ha sido diseñado para seguimientos GRB (Gamma-Ray Burst) rápidos con
tiempo de respuesta lo más corto posible a los avisos GCN.
El objetivo cientı́fico principal del telescopio es obtener datos sobre transitorios
ópticos y resplandores de estallidos de rayos gamma, una emisión de luz simultánea
o casi simultánea de esas fuentes cósmicas de alta energı́a.
El telescopio es capaz de observar también otras fuentes interesantes como su-
pernovas, blazares, galaxias activas, estrellas variables cataclı́smicas, etc.
Figura 5.7: Telescopio BART localizado en el Instituto Astronómico del CAS (Ondrejov).
y especificaciones.
Tabla 5.2: Caracterı́sticas y especificaciones del telescopio BART.
ESPECIFICACIONES
SOCIO AUAV
LOCALIZACIÓN Ondrejov, República Checa
Latitud: 49o 54’32.577 N
COORDENADAS
Longitud: 14o 46’54.855 E
FECHA DE INICIO Febrero 2000
FILTROS Johnson B, V, R, z”, Clear
APERTURA 254m (NF) + 100mm (WF)
DISTANCIA FOCAL 1640mm (NF) + 495 (WF)
BOOTES-1A
La Red de Telescopios Robóticos BOOTES (Burst Observer and Optical Transient

Exploring System) [5] fue fundada con el objetivo de seguir alertas BATSE y realizar
análisis automatizados del cielo. BOOTES-1 es un observatorio robótico localizado

en Centro de Experimentación de El Arenosillo (Provincia de Huelva).
El observatorio alberga dos cúpulas con telescopios robóticos y un amplio con-
junto de dispositivos de apoyo. El mayor telescopio de este observatorio es el deno-
minado BOOTES-1B, seguido del BOOTES-1A mostrado en la Figura 5.8. El tercer
instrumento cientı́fico presente es una “all-sky camera” CCD de alta resolución si-
milar a la que se encuentra en el BOOTES-2.
Figura 5.8: Telescopio BOOTES-1A localizado en Observatorio de El Arenosillo (Huelva).
y especificaciones.
Tabla 5.3: Caracterı́sticas y especificaciones del telescopio BOOTES-1A.
ESPECIFICACIONES
SOCIO CSIC
LOCALIZACIÓN Andalucı́a, España
Latitud: 37.10402 N
COORDENADAS
Longitud: 6.73406 O
FECHA DE INICIO Octubre 1997
FILTROS Clear
APERTURA 0.3m
DISTANCIA FOCAL 1775mm
BOOTES-2
La estación astronómica BOOTES-2 [6] se encuentra en el Observatorio de La

Mayora (Provincia de Málaga). El observatorio está localizado a 240km de la estación
BOOTES-1 y, a diferencia de ésta, su cúpula está controlada por un sistema de
apertura hidráulico controlado automáticamente según las condiciones climáticas
existentes.
En este Observatorio Astronómico se encuentra el telescopio TELMA (TELesco-
pio MAlaga) representado en la Figura 5.9, perteneciente a la Red de Telescopios
Robóticos BOOTES, que cuenta con una “all-sky camera” (CASANDRA-2) capaz
de visualizar todo el cielo para llevar un registro continuado de la bóveda celeste.
El objetivo primario del observatorio [7] es realizar un seguimiento de las ob-
servaciones ópticas de los fenómenos cósmicos transitorios de alta energı́a, como
explosiones de rayos gamma y supernovas. También se utiliza para el estudio de las
estrellas variables, galaxias activas o planetas menores cercanos.
Figura 5.9: Telescopio BOOTES-2 ubicado en el Observatorio de La Mayora (Málaga).
y especificaciones.
TADn
Como se ha explicado anteriormente, el TAD [29] está constituido por dos teles-
copios, uno solar y nocturno.
El TADn mostrado en la Figura 5.10 es el primer telescopio nocturno español de

libre acceso a toda la ciudadanı́a.
El sistema de equipamiento que lo forma contiene un telescopio catadióptrico,
que combina las cualidades de las lentes y los espejos, cuyo tubo óptico se comple-
menta con un buscador. El buscador externo apocromático posee lentes ED de baja
dispersión para evitar problemas de dispersión de luz. Para la captación de imáge-
nes se dispone de una cámara CCD complementada con una rueda portafiltros de 5
Tabla 5.4: Caracterı́sticas y especificaciones del telescopio BOOTES-2.
ESPECIFICACIONES
SOCIO UMA-CSIC
LOCALIZACIÓN Andalucı́a, España
Latitud: 36.7592 N
COORDENADAS
Longitud: 4.0410 O
FECHA DE INICIO Octubre 2001
FILTROS Bessel R, SLOAN g’, r’, i’, UKIRT z’, Y’, Clear
APERTURA 0.6m
DISTANCIA FOCAL 4475mm
posiciones.
Figura 5.10: Telescopio TADn ubicado en el Observatorio del Teide (Tenerife).
y especificaciones.
D50
D50 [11] es un telescopio astronómico reflector ubicado en el Instituto Astronómi-

co de la Academia de las Ciencias de República Checa.
Este telescopio, representado en la Figura 5.11, utiliza dos espejos en lugar de un
sistema de lentes. El sistema de funcionamiento de los espejos consiste en que la luz
que pasa a través del telescopio es reflejada por el espejo primario al espejo secun-
dario, y a continuación el secundario la refleja hacia el sensor digital del telescopio.
y especificaciones.
Figura 5.11: Telescopio D50 localizado en el Instituto Astronómico de la Academia de las Ciencias
de República Checa (Ondrejov).
Tabla 5.5: Caracterı́sticas y especificaciones del telescopio D50.
ESPECIFICACIONES
SOCIO AUAV
LOCALIZACIÓN Ondrejov, República Checa
Latitud: 49o 54’33.739 N
COORDENADAS Longitud: 14o 46’52.907 E
Altura: 529m
FECHA DE INICIO Septiembre 2007
FILTROS Johnson B, V, R, I, Clear
APERTURA 500mm
DISTANCIA FOCAL 1975mm, alpha/16 EFLParaCor=2277mm
WATCHER
WATCHER [33] es un telescopio localizado en el Observatorio Astronómico Boy-

den (Bloemfontein).
El telescopio robótico, mostrado en la Figura 5.12, es capaz de responder a los
estallidos de rayos gamma (GRB) y detectar destellos ópticos y resplandores débi-
les. El sistema fue diseñado principalmente para obtener localizaciones GRB muy
precisas procedentes de satélites en órbita.
y especificaciones.
Figura 5.12: Telescopio WATCHER localizado en el Observatorio Boyden (Bloemfontein).
Tabla 5.6: Caracterı́sticas y especificaciones del telescopio WATCHER.
ESPECIFICACIONES
SOCIO UCDNUID
LOCALIZACIÓN Bloemfontein, República de Sudáfrica
Latitud: 29o S
COORDENADAS Longitud: 26o E
Altura: 1387m
FECHA DE INICIO Mayo 2006
FILTROS Clear
APERTURA 40cm
DISTANCIA FOCAL f/14.25
5.3.2. Teleoperación del Experimento Nocturno

La teleoperación del experimento nocturno consta de las siguientes funcionalida-
des:
Visualización de información sobre la reserva. Se incluyen los detalles del teles-
copio y de la reserva, el tiempo restante antes de la finalización del experimento
y la información atmosférica de las condiciones climatológicas recibidas por el
sistema, como la temperatura, la humedad y la velocidad del viento.
Visualización del sistema de telescopios mediante las cámaras del observatorio.
Cada observatorio dispone de una o dos cámaras de este tipo.
Como ejemplo de visualización se utiliza el TADn que está provisto de dos
cámaras. La cámara exterior (Referencia figura 1) apunta al sistema conjunto,
proporcionando una imagen necesaria para la visualización del estado de aper-
tura de la cúpula. La cámara interior (Referencia figura 2) apunta al telescopio
y se utiliza para observar y comprobar el movimiento de la montura.
Control del apuntamiento del telescopio. Se puede apuntar el telescopio au-

tomáticamente a al objetivo que se desee. Adicionalmente se puede controlar
de forma manual el direccionamiento del telescopio para centrar la imagen del
objetivo, pudiendo realizar los movimientos según las coordenadas geográficas.
Para realizar el direccionamiento automático previamente se debe seleccionar
el objetivo mediante cualquiera de las distintas opciones. La primera opción es
indicar manualmente las coordenadas geográficas (latitud y longitud) mediante
el sistema de coordenadas J2000, en el que se deben indicar los parámetros de
ascensión recta y declinación. La segunda opción permite indicar el nombre del
objetivo deseado. Entre los distintos objetivos, es posible seleccionar de una
forma sencilla los planetas pertenecientes al Sistema Solar, ası́ como la Luna.
Además, es posible mostrar el “Skymap” (mapa del cielo) representado en la
Figura 5.13 que indica con detalle información sobre la situación y coordenadas
celestiales de todas las estrellas, constelaciones, objetos del Sistema Solar y
objetos no estelares, ası́ como trayectorias de cometas y asteroides.
Figura 5.13: “Skymap”. Mapa del cielo con información de las constelaciones.
Control de los parámetros de la cámara. Es posible modificar algunos paráme-

tros de la cámara para obtener una imagen óptima del objetivo. Entre dichos
parámetros es posible modificar el tiempo de exposición, el enfoque y la ganan-
cia de la cámara.
1. Control del tiempo de exposición del obturador de la cámara. Se utiliza

para modificar la cantidad de tiempo que el CCD está recibiendo luz. Para
un tiempo de exposición corto, el obturador permanece abierto poco tiempo
y deja pasar menos luz. Por contrario, para un tiempo de exposición largo,
el obturador permanece abierto más tiempo dejando pasar más luz.
2. Control del enfoque de la cámara. Se utiliza para obtener la mayor nitidez
posible en la toma de una imagen. Esto se consigue cuando los rayos de
luz que inciden en la cámara coinciden en un punto de la cámara llamado
foco, que a su vez coincide con el sensor de la cámara.
3. Control de la ganancia de la cámara. Se utiliza si la iluminación de la escena
es tan baja que incluso la apertura del diafragma no ofrece una señal con
el valor deseado. Para estos casos se utiliza una amplificación electrónica

que aumenta artificialmente la señal recibida, pero a su vez se amplifica el
ruido de la imagen.
Selección del tipo de filtro de fotometrı́a. Se utilizan los filtros para controlar
la luz que nos llega de las estrellas. Los filtros no dejan pasar toda la luz, sino
únicamente una banda determinada más o menos estrecha, absorbiendo el resto
del espectro lumı́nico. Esto conlleva una pérdida de sensibilidad en la cámara,
pero se compensa por los resultados obtenidos al realizar una superposición de
imágenes tomadas con distintos filtros.
Selección del modo de video. El modo de video es utilizado para poder visualizar
el cielo en tiempo real, en lugar de visualizar únicamente las imágenes tomadas.
Actualmente, esta función sólo está disponible con el telescopio TADn.
Captura de imágenes. Tras configurar los parámetros de la cámara es hora de
tomar una o varias imágenes del objetivo, pudiendo modificar cualquiera de los
parámetros tantas veces como sea posible para conseguir una imagen lo más
detallada posible.
Visualización de imágenes. Es posible acceder al visualizador de imágenes to-
madas en cualquier momento para observar los resultados del experimento.
La imagen mostrada en la Figura 5.14 contiene un ejemplo de fotografı́a tomada
durante el experimento.
Figura 5.14: Ejemplo de fotografı́a obtenida por el telescopio BART durante el experimento noc-
turno.
Capı́tulo 6
Conclusiones
6.1. Conclusión
Una vez finalizado el proyecto se consigue realizar la teleoperación de los telesco-
pios mediante dispositivos móviles de distintas plataformas. La implementación de
los servicios proporcionados por la red GLORIA ha permitido la realización de los
experimentos Solar y Nocturno mediante los cuales se controla la red de telescopios,
con el objetivo de observar el cielo durante el dı́a y durante la noche, ası́ como la
toma de múltiples imágenes del Universo que nos rodea.
Se ha conseguido cumplir el verdadero propósito del proyecto, permitir el acceso

libre a cualquier usuario para que utilice en primera persona, mediante un smartp-
hone, la gran cantidad de recursos disponibles en los experimentos, y ası́ contribuir
a la globalización de la ciencia ciudadana.
6.2. Desarrollos futuros

Actualmente, la aplicación móvil se encuentra en un momento de arranque en
su crecimiento, ya que posee las funcionalidades básicas para su utilización. De esta
manera, es posible el desarrollo de múltiples funcionalidades y mejoras que puedan
aportar una mayor motivación a los usuarios de pertenecer a esta red cientı́fica.
A continuación, se propone una serie de posibles desarrollos futuros para la apli-

cación:
Debido a la importancia de las redes sociales en la época actual, se considerarı́a

oportuno el desarrollo de un sistema para compartir el resultado de los experi-
mentos realizados, mostrando las imágenes tomadas a cualquier persona y ası́
promover la participación de la mayor cantidad de gente.
Para mejorar la interacción de los usuarios situados en cualquier parte del

planeta, serı́a necesario adaptar la interfaz a múltiples idiomas.
En lo referido al tema de Astronomı́a, se podrı́a valorar la opción de incluir

una sección que recogiera datos de distintos medios de comunicación cientı́ficos
y proporcionara información a los usuarios sobre los temas de actualidad en el
55
56 CAPÍTULO 6. CONCLUSIONES
campo de la Astronomı́a, ası́ como ofrecer detalles sobre futuros acontecimientos

que pudieran ser objeto de la realización de experimentos en las fechas previstas.
Para facilitar el acceso a los usuarios y proporcionar comodidad con la aplica-
ción, se propone el uso de un sistema de notificaciones que evitarı́a a los usuarios
mantenerse a la espera para la entrada a cualquier experimento. También se
podrı́a aplicar a la publicación de noticias o a la actividad de otros usuarios
que quisieran compartir su estado.
Apéndice A
Manual de usuario
A.1. Requisitos previos

A.1.1. Compatibilidad de dispositivos
La aplicación se encuentra compatible inicialmente para dispositivos en desarro-
llados las plataformas Android e iOS, por ser los sistemas operativos más utilizados
en dispositivos móviles. Es posible extender la aplicación a otras plataformas, como
Windows Phone, Blackberry o Ubuntu si la situación lo requiere mediante Apache
Cordova.
A.1.2. Requisitos del dispositivo

El único requisito necesario para la utilización de la aplicación es la conexión
a internet, preferiblemente a través de WiFi por la cantidad de datos enviados y
recibidos del servidor.
A.2. Instrucciones de instalación

La aplicación no se encuentra actualmente en las tiendas oficiales Play Store y
App Store, por lo que se deberán seguir las siguientes instrucciones de instalación:
Dispositivos con sistema operativo Android: Para instalar la aplicación se nece-

sitará poseer el archivo “.apk”. Por el momento están disponibles para descargar
las distintas APK en los siguientes enlaces: GLORIA para ARM (https://www.
dropbox.com/s/wt4cly1ueezbszs/Gloria%20Mobile-armv7.apk?dl=0), GLO-
RIA para x86 (https://www.dropbox.com/s/8psbkn7kjxeujx6/Gloria%20Mobile-x86.
apk?dl=0), Cazasteroides (http://cazasteroides.org/ - Descargas - An-
droid).
A continuación se deberán realizar los siguientes pasos:
1. Acceder a los Ajustes del sistema.
2. Entrar en la sección Seguridad, o Seguridad y pantalla de bloqueo.
3. Activar la pestaña de Orı́genes desconocidos o Fuentes desconocidas, que
permite la instalación de aplicaciones de no obtenidas desde el Play Store.
Aceptar el mensaje de advertencia de seguridad.
57
58 APÉNDICE A. MANUAL DE USUARIO
4. Ejecutar el archivo “.apk” descargado anteriormente y aceptar las condi-

ciones de instalación.
Dispositivos con sistema operativo iOS: Actualmente no es posible instalar la
aplicación sin la ayuda de un PC, por tanto es necesario esperar a la publicación
de la misma en el App Store.
A.3. Instrucciones de uso

En esta sección se detalla la guı́a de utilización de la aplicación de teleoperación
de los telescopios.
La aplicación que contiene los experimentos de teleoperación puede utilizarse
como una aplicación independiente (denominada GLORIA en esta sección), pero se
utilizará también para constituir una parte de la aplicación Cazasteroides. Partiendo
de esta base, se explicarán los dos métodos de acceso a sus funcionalidades.
Una de las diferencias entre una aplicación y la otra es el inicio de sesión, pues
la aplicación GLORIA accede a la base de datos de la red GLORIA, y la aplicación
Cazasteroides accede a una base de datos independiente.
Al iniciar la aplicación se muestra una pantalla de inicio de sesión (ver Figuras
A.1 y A.2) que permite entrar en la aplicación o registrarse si es un nuevo usuario.
Figura A.1: Login de usuario en Cazasteroides. Figura A.2: Login de usuario en GLORIA.
La pantalla de registro pedirá unos datos u otros en función de la aplicación,

como se muestra en las Figuras A.3 y A.4.
A partir de este momento, cada aplicación accederá a los experimentos de una
forma distinta.
A.3. INSTRUCCIONES DE USO 59
Figura A.3: Registro de usuario en Cazasteroides. Figura A.4: Registro de usuario en GLORIA.
GLORIA
Una vez introducido el usuario y la contraseña, la aplicación GLORIA muestra

una pantalla con distintas opciones (ver Figura A.5), entre las que se encuentran los
accesos a reservas, imágenes, tutoriales y cierre de sesión.
Al acceder a los tutoriales (ver Figura A.6) se muestran unos vı́deos con las
distintas funcionalidades de los telescopios, ası́ como los pasos a seguir para realizar
un experimento mediante la aplicación Web.
La sección Imágenes (ver Figura A.7) muestra un visualizador de todas las imáge-
nes tomadas mediante los experimentos realizados por cualquier usuario. Es posible
filtrar el contenido por fecha y mostrar imágenes aleatorias o propias del usuario.
La sección Reservas permite realizar una nueva reserva o gestionar las reservas
pendientes.
Si se desea realizar una nueva reserva, la aplicación mostrará los experimentos. Al
seleccionar uno de ellos se mostrarán los telescopios disponibles para ese experimento
(ver Figura A.8). Una vez seleccionado el telescopio se buscará una fecha en el
calendario y finalmente se elegirá el horario deseado entre los disponibles (ver Figura
A.9).
Una vez hecho esto se debe solicitar la reserva (ver Figura A.10) y, si no hay
ningún problema, ésta se completará con éxito (ver Figura A.11).
Será posible cancelar la reserva en cualquier momento desde la sección Reservas
Pendientes (ver Figura A.12). Si se accede a esta sección dentro del horario de
reserva, la aplicación permitirá comenzar el experimento (ver Figura A.13) con el
telescopio elegido anteriormente.
Figura A.5: Pantalla de inicio.
Figura A.6: Tutoriales de realización de los experimentos.
Cazasteroides
Al introducir el usuario y contraseña, la aplicación Cazasteroides gestionará el

acceso a los experimentos y la duración de éstos en función de los premios obtenidos
Figura A.7: Sección de visualización de imágenes.
Figura A.8: Selección de un experimento. Figura A.9: Selección de una fecha.

Figura A.10: Solicitud de una reserva. Figura A.11: Finalización del proceso de reserva.
Figura A.12: Lista de reservas pendientes. Figura A.13: Detalles de una reserva.
de la caza de asteroides.
A.3.1. Experimentos
Una vez comenzado el experimento, se mostrarán en la pantalla los detalles de la
reserva (ver Figura A.14).
Figura A.14: Información del experimento.
Dependiendo del tipo de experimento, las opciones de teleoperación serán distin-

tas.
Solar
En la cabecera se encuentran los botones de información y visualización de imáge-

nes tomadas, además de una barra de progreso que muestra el tiempo restante para
la finalización del experimento.
El experimento solar consta de tres pantallas:
1. La pantalla principal (ver Figura A.15) muestra en la parte central una imagen
de la cámara principal del telescopio. En la parte superior se encuentra un
conjunto de miniaturas de las imágenes captadas por el resto de cámaras del
observatorio. En la parte inferior de la imagen principal se hallan los valores de
tiempo de exposición y pasos de enfoque. Finalmente, se encuentra el icono de
una cámara utilizado para tomar una imagen del sol.
La imagen principal posee unos controles en los laterales para modificar el
tiempo de exposición y el enfoque de la cámara.
Figura A.15: Pantalla principal. Experimento Solar.
2. Mediante las miniaturas encontradas en la parte superior izquierda de la panta-

lla principal se accede a la siguiente sección. En esta pantalla (ver Figura A.16
se muestran las imágenes del sistema de telescopios del observatorio. La prime-
ra imagen está tomada mediante la cámara exterior, y la siguiente mediante la
cámara interior. En la parte superior de la pantalla se encuentra un conjunto
de miniaturas para acceder al resto de las pantallas. En la parte inferior se
encuentran los botones de abrir y cerrar cúpula.
3. Mediante la miniatura encontrada en la parte superior derecha de la pantalla

principal se accede a la última sección. En esta pantalla (ver Figura A.17 se
muestra la imagen del sol en un entorno amplio. En la parte inferior de la
imagen se encuentra un botón para apuntar la cámara hacia el sol.
Las flechas que rodean a la imagen se utilizan para realizar movimientos del
telescopio y centrar el sol en la imagen.
Nocturno
En la cabecera se encuentran los botones de información, herramientas y visua-

lización de imágenes tomadas, además de una barra de progreso que muestra el
tiempo restante para la finalización del experimento.
En la parte central de la pantalla (ver Referencia figura) se muestra una imagen de
la cámara principal del telescopio (inicialmente se muestra una imagen predefinida
hasta que se toma una imagen con el telescopio). Es posible modificar el tiempo de
exposición y el enfoque mediante los controles situados a los laterales de la imagen.
En la parte superior se encuentran unas miniaturas de las imágenes del observatorio y
Figura A.16: Pantalla de visualización del observatorio. Experimento Solar.
Figura A.17: Pantalla de apuntamiento del telescopio. Experimento Solar.
unos controles de movimiento del telescopio. En la parte inferior de imagen principal

se halla la información del tiempo de exposición y el enfoque. Más abajo localiza
la barra de calibración de la ganancia de la cámara. Finalmente, se encuentra el

botón con el icono de una cámara para tomar fotos con el telescopio. Si el telescopio
posee un modo de visualización de vı́deo se mostrará otro botón con el icono de una
cámara de vı́deo.
Figura A.18: Pantalla principal. Experimento Nocturno.
El icono de herramientas mostrado en la parte superior permite acceder a los

parámetros de búsqueda y localización (ver Figura A.19). En esta sección se puede
encontrar un control de las coordenadas de localización del telescopio(ver Figura
A.20), capaz de posicionarlo mediante las coordenadas de ascensión recta y decli-
nación. También se muestra un buscador de objetos capaz de localizar múltiples
objetivos (ver Figura A.21), pudiendo apuntar a cualquiera de los planetas cerca-
nos a la Tierra, ası́ como a una cantidad de constelaciones, estrellas y objetos del
Sistema Solar. Para ello es posible visualizar un mapa del cielo mediante la opción
“Skymap”(ver Figura A.22). Por último, se mostrará la selección del tipo de filtro
a utilizar siempre que el telescopio disponga de ellos.
Figura A.19: Búsqueda y localización. Figura A.20: Posicionamiento por coordenadas.
Figura A.21: Posicionamiento por objetivos. Figura A.22: Búsqueda mediante “SKYMAP”.
Bibliografı́a
[1] David Jaramillo; Robert Smart; Borko Furht; Ankur Agarwal. A secure exten-
sible container for hybrid mobile applications. Southeastcon, 2013 Proceedings
of IEEE, (5):1–5, 2013.
[2] Proyecto ASTROCAM. [Online]. http://tornasol.datsi.fi.upm.es/
astrocam/.
[3] Telescopio BART. [Online]. http://hea.asu.cas.cz/bart/en/.
[4] Yi Liu; Xuanzhe Liu; Yun Ma; Yunxin Liu; Zibin Zheng; Gang Huang; M. Brian
Blake. Characterizing restful web services usage on smartphones: A tale of
native apps and web apps. Web Services (ICWS), 2015 IEEE International
Conference on, (8):337–344, 2015.
[5] BOOTES-1. [Online]. http://rts2.org/wiki/doku.php?id=obs:bootes_
1Telescope.
[6] BOOTES-2. [Online]. http://bootes.iaa.es/es/historia-proyecto/
74-bootes-2-historia.
[7] BOOTES-2. [Online]. http://rts2.org/wiki/doku.php?id=obs:bootes_2.
[8] Alberto Javier Castro-Tirado. Robotic autonomous observatories: A historical
perspective. Advances in Astronomy, (8), 2010.
[9] Grupo Cı́clope. [Online]. http://mercurio.datsi.fi.upm.es/index.php/
es/.
[10] Proyecto COLDEX. [Online]. http://www.coldex.info/.
[11] Telescopio D50. [Online]. http://www.vojtechvavrin.cz/bachelor_thesis/
index-en.html.
[12] Curso de AngularJS. [Online]. https://www.cursoangularjs.es.
[13] Proyecto Cazadores de Asteroides. [Online]. http://cazasteroides.org.
[14] Proyecto Disk Detective. [Online]. https://www.diskdetective.org/.
[15] Abdur Rahman.A; Chitra Devi.S. A framework for ultra-responsive light weight
web application using angularjs. 2015 Online International Conference on
Green Engineering and Technologies (IC-GET 2015), (4):1–4, 2015.
[16] Comparativa entre Frameworks. [Online]. https://devcode.la/tutoriales/
angularjs-vs-backbonejs-jquery-reactjs/.
69
70 BIBLIOGRAFÍA
[17] Proyecto Planet Four. [Online]. https://www.planetfour.org/.

[18] Proyecto Poppin’ Galaxy. [Online]. https://www.zooniverse.org/projects/
wim0705/poppin-galaxy.
[19] Proyecto GLORIA. [Online]. http://www.gloria-project.eu/es/.
[20] Proyecto Comet Hunters. [Online]. https://www.zooniverse.org/projects/
mschwamb/comet-hunters.
[21] Proyecto Planet Hunters. [Online]. https://www.planethunters.org/.
[22] Proyecto Supernova Hunters. [Online]. https://www.zooniverse.org/
projects/dwright04/supernova-hunters.
[23] Comparativa AngularJS Vs jQuery. [Online]. http://www.desarrolloweb.
com/articulos/angularjs-vs-jquery.html.
[24] Proyecto MEGARA. [Online]. https://guaix.fis.ucm.es/megara.
[25] Official Website of AngularJS. Angularjs by google. [Online]. https://www.
angularjs.org.
[26] Official Website of Apache Cordova. [Online]. https://www.cordova.apache.
org.
[27] Rita Francese; Michele Risi; Genoveffa Tortora; Giuseppe Scanniello. Suppor-
ting the development of multi-platform mobile applications. Web Systems Evo-
lution (WSE), 2013 15th IEEE International Symposium on, (4):87–90, 2013.
[28] Proyecto Sunspotter. [Online]. https://www.sunspotter.org/.
[29] Telescopio TAD. [Online]. http://gloria-project.eu/tag/tad-es/.
[30] Proyecto Planet Four: Terrains. [Online]. https://www.zooniverse.org/
projects/mschwamb/planet-four-terrains.
[31] GLORIA Users. [Online]. https://users.gloria-project.eu/#/welcome.
[32] John M. Wargo. Apache Cordova 3 Programming. Number 262 in Mobile
Programming Series. Addison-Wesley, first edition, 2013.
[33] Telescopio WATCHER. [Online]. http://watchertelescope.ie/.
[34] Proyecto Galaxy Zoo. [Online]. https://www.galaxyzoo.org/.
[35] Proyecto Radio Galaxy Zoo. [Online]. https://radio.galaxyzoo.org/.
[36] Proyecto Radio Meteor Zoo. [Online]. https://www.zooniverse.org/
projects/zooniverse/radio-meteor-zoo.
[37] Zooniverse. [Online]. https://www.zooniverse.org/.

TFG Memoria SergioRodriguez

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Memoria SergioRodriguez

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y

Grado en Ingenierı́a Electrónica y Automática Industrial

TRABAJO FIN DE GRADO

Desarrollo de una aplicación

Sergio Rodrı́guez Dorado

Cotutor: Jorge Artieda Trigueros Tutor: Raquel Cedazo León

Madrid, Septiembre 2016

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y

Grado en Ingenierı́a Electrónica y Automática Industrial

TRABAJO FIN DE GRADO

Desarrollo de una aplicación

Firma Cotutor Firma Tutor

Tı́tulo: Desarrollo de una aplicación móvil para la teleoperación de los telescopios

Muchas gracias a todos.

Este proyecto se resume en el desarrollo de una aplicación móvil multiplataforma

El desarrollo de la aplicación se estructura en dos bloques, que son la funcionali-

Palabras clave: teleoperación, telescopio, aplicación móvil.

Keywords: teleoperation, telescope, mobile application.

2. Estado del arte 5

3. Proyectos astronómicos de ciencia ciudadana 17

4. Desarrollo de la aplicación móvil 27

2.1. Arquitectura de una aplicación nativa [4]. . . . . . . . . . . . . . . . . 8

3.1. Primer telescopio controlado por ordenador (1968). . . . . . . . . . . 18

4.1. Esquema de la estructura de la aplicación GLORIA. . . . . . . . . . . 28

5.1. Telescopio TADs ubicado en el Observatorio del Teide (Tenerife). . . 42

5.13. “Skymap”. Mapa del cielo con información de las constelaciones. . . . 52

5.1. Caracterı́sticas y especificaciones del telescopio TAD. . . . . . . . . . 42

1.1. Motivación del proyecto

El auge de la tecnologı́a móvil en la actualidad ha resultado en una constante

La Astronomı́a en la actualidad es un campo muy abierto a la investigación, ya

Para alcanzar este propósito se establecen los siguientes objetivos:

1.3. Materiales utilizados

Adicionalmente, se ha hecho uso de SDK y AVD de Android y XCode de Apple

La programación se ha realizado en los lenguajes HTML, CSS y Javascript, útiles

La herramienta de desarrollo multiplataforma utilizada ha sido Apache Cordova,

Para realizar el desarrollo de la interfaz de usuario y proporcionar funcionalidad

1.4. Estructura del documento

En el Capı́tulo 1 se realiza una introducción y alcance del proyecto.

Estado del arte

En este capı́tulo se analizarán las tecnologı́as utilizadas para el desarrollo de

2.1. Definición de conceptos

patrones de intercambio de mensajes. Está basado en un protocolo cliente/ser-

2.2. Aplicaciones móviles

mediante la búsqueda en navegadores de enciclopedias online o con aplicaciones de

Este recorrido ha resultado en una integración absoluta de los smartphones en la

2.3. Desarrollo multiplataforma

A continuación se comentarán las diferencias de acceso a los servicios Web REST-

2.3.1. Aplicaciones Web vs Aplicaciones Nativas

flexible y adecuada para los dispositivos móviles.

En la actualidad existen numerosas aplicaciones móviles que acceden a servicios

Figura 2.1: Arquitectura de una aplicación nativa [4].

Una vez instalada la aplicación en el dispositivo, el código nativo y algunos re-

Por el contrario, una aplicación Web es mostrada mediante un navegador Web, el

Figura 2.2: Arquitectura de una aplicación Web [4].

En lo referido al acceso a servicios RESTful, es posible realizar varios tipos de

Se ha comprobado que el desarrollo de una aplicación presenta un funcionamien-

2.3.2. Aplicaciones Hı́bridas

El desarrollo de aplicaciones hı́bridas posee una cantidad de ventajas en cuanto

El framework hı́brido más frecuentemente utilizado es Apache Cordova, que per-

Apache Cordova [26] es un marco de desarrollo móvil de código abierto. Permite

2.4. Evolución de las aplicaciones Web