Automatizacion Observatorio Astronomico PDF

Automatización observatorio astronómico
Oscar Ferney Gallo Romero
Universidad Distrital Francisco José de Caldas

Facultad de Ingenierı́a
Proyecto Curricular de Ingenierı́a Electrónica
Bogotá D.C.
2018
Automatización observatorio astronómico
Oscar Ferney Gallo Romero Código: 20131005031
Trabajo de grado para optar al tı́tulo de:

Ingeniero Electrónico en la modalidad de pasantı́a
Directora:
Diana Marcela Ovalle Martı́nez. PhD.
Director externo:
Jimmy Raul Bustos Benitez. Ing.
Lı́nea de Trabajo:
Automatización industrial y telemática
Universidad Distrital Francisco José de Caldas

Facultad de Ingenierı́a
Proyecto Curricular de Ingenierı́a Electrónica
Bogotá D.C.
2018
Todos somos ignorantes, solo que no todos
ignoramos lo mismo.
Albert Einstein
Agradecimientos
Al llegar a este punto solo resta expresar mi agradecimiento a todas aquellas

personas que se cruzaron conmigo en el largo camino que comenzó hace 6 años, a
la mayor parte de los profesores que en algún momento dedicaron su tiempo para
resolver mis dudas sobre los temas referentes a sus materias, a mis compañeros y
compañeras de carrera con quienes compartı́ a lo largo de estos años, a la profesora
Diana Ovalle por el aval a mi proyecto de grado y al profesor Edilberto Suarez por
haberme recomendado al mismo, a mi familia por el apoyo constante en cuanto
necesitara y a Dios por permitir la culminación de mi carrera.
A todos gracias.
Resumen
Para el proyecto de automatización del observatorio astronómico de la Universi-

dad Distrital Francisco José de Caldas se implemento una solución haciendo uso
de una placa Raspberry Pi 3 como controlador central, la cual recibe mensajes
desde un aplicativo web empleando el protocolo MQTT, la pagina web y la base
de datos asociada a la misma se aloja empleando los servicios de almacenamiento
de Amazon Web Services(AWS), el software de gestión local que corre sobre la
Raspberry Pi fue escrito en Python y emplea caracterı́sticas tanto de la versión
2.7.x como de la mas reciente 3.x. La principal razón por la cual se escogió el
sistema embebido y el lenguaje de programación es la capacidad del primero para
ejecutar un sistema operativo de tiempo real de las múltiples distribuciones de
GNU/Linux de las muchas disponibles actualmente, y la integración de Python
con dichas distribuciones que le permite correr en forma transparente sobre ellas
sin necesidad de máquinas virtuales o Frameworks especiales para ello, sumado a
la caracterı́stica de software libre de Linux y Python en general.
El hardware del sistema de automatización fue construido siguiendo estándares

industriales tales como el montaje de los elementos dentro de armarios de control,
con bandeja de montaje interna y colocación sobre riel DIN tal como correspon-
de, adicionalmente, se incluyen elementos de protección tales como interruptores
termomagnéticos, fusibles, paradas de emergencia y totalizadores, puesto que se
poseen en total dos armarios de control se emplea un enlace Bluetooth para esta-
blecer un enlace entre los mismos.
Para el control de los motores que se emplean para el movimiento de la cúpula y

las compuertas se emplea extensivamente la lógica cableada e interruptores elec-
tromagnéticos, los cuales aún hoy en dı́a son una excelente alternativa en el campo
industrial gracias a su simplicidad de uso y la capacidad de aislamiento entre cir-
cuitos que ofrecen, también se emplean este tipo de interruptores para obtener
señales acerca del estado del observatorio, especı́ficamente en el caso de determi-
nar si existe suministro eléctrico a través de la red comercial hacia el tablero de
x RESUMEN
control principal y también para determinar si se ha activado el interruptor de

parada de emergencia; en el tablero de control principal o maestro se emplea una
fuente de alimentación proveniente de una UPS con el fin de garantizar que el sis-
tema de automatización y monitoreo funcione aun si no existe suministro eléctrico.
Como conclusión al trabajo se muestran algunas imágenes de objetos celestes

capturadas empleando el sistema en su totalidad, es decir, capturadas desde el
telescopio empleando los diferentes dispositivos que fueron integrados para este
propósito, con el fin de mostrar el potencial a futuro que ofrece el trabajo reali-
zado no como conclusión final sino como punto de partida para futuras mejoras
que contribuyan a la conformación de un laboratorio de astronomı́a robusto y
funcional, con el fin de convertirse en una herramienta que ayude al desarrollo de
esta ciencia en la Universidad Distrital Francisco José de Caldas.
Contenido
Resumen IX
Lista de Figuras XV
Lista de Tablas XIX
Introducción 1
1. Generalidades 5
1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . 5
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . 6
1.3. Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Diseño de hardware de gestión para la cúpula del observatorio 9

2.1. Tareas preliminares e identificación . . . . . . . . . . . . . . . . . 9
2.1.1. Descripción del sistema . . . . . . . . . . . . . . . . . . . . 9
2.1.2. Consideraciones sobre el movimiento de rotación horizontal 10
2.1.3. Consideraciones sobre compuerta vertical . . . . . . . . . . 12
2.1.4. Consideraciones sobre el telescopio Meade LX200 GPS . . 14
2.2. Diseño e implementación de sistema gestión de giro horizontal para
cúpula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1. Control de giro . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2. Orientación de cupula mediante brújula digital . . . . . . . 19
2.2.3. Orientación de cúpula mediante sistema de encoder incre-
mental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3. Diseño de sistema de gestión para compuertas horizontales . . . . 31
2.4. Iluminación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
xii CONTENIDO
3. Desarrollo de software de administración local 37

3.1. Consideraciones sobre el desarrollo . . . . . . . . . . . . . . . . . 37
3.1.1. Elección de lenguaje y placa de procesamiento . . . . . . . 37
3.1.2. Conectividad . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2. Arquitectura y documentación . . . . . . . . . . . . . . . . . . . . 42
3.2.1. Clases contempladas . . . . . . . . . . . . . . . . . . . . . 42
3.2.2. La clase iot . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.3. La clase Dome . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.4. La clase Telescope . . . . . . . . . . . . . . . . . . . . . . 59
3.2.5. Las clases ZWO, CameraLpi e indiCliet . . . . . . . . . . 65
3.2.6. La clase Cameraweb . . . . . . . . . . . . . . . . . . . . . 75
3.2.7. La clase Instrument . . . . . . . . . . . . . . . . . . . . . . 77
3.2.8. La clase Rpi . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2.9. La clase Buckets3 . . . . . . . . . . . . . . . . . . . . . . . 81
3.2.10. la clase Broker . . . . . . . . . . . . . . . . . . . . . . . . 82
3.2.11. La clase ST VL6180X . . . . . . . . . . . . . . . . . . . . 84
4. Integración global de componentes 85

4.1. Arquitectura general . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2. El servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3. El cliente Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3.1. Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.2. El panel de control . . . . . . . . . . . . . . . . . . . . . . 87
4.3.3. Perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4. El hardware local . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4.1. El tablero de control principal . . . . . . . . . . . . . . . . 91
4.4.2. El tablero de control secundario . . . . . . . . . . . . . . . 98
4.5. Resultados y análisis . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.5.1. Tablero de control principal . . . . . . . . . . . . . . . . . 104
4.5.2. Tablero de control secundario . . . . . . . . . . . . . . . . 108
4.5.3. Resultado final . . . . . . . . . . . . . . . . . . . . . . . . 110
5. Actividades adicionales 115

5.1. Complementos observatorio astronómico . . . . . . . . . . . . . . 115
5.1.1. Instalación de circuito cerrado de televisión . . . . . . . . . 115
5.1.2. Instalación de UPS . . . . . . . . . . . . . . . . . . . . . . 117
5.1.3. Instalación y configuración de estación meteorológica . . . 118
5.2. Tareas de apoyo en la empresa Robótica Colombia S.A.S. . . . . . 120
CONTENIDO xiii
5.2.1. Ensamble y depuración de tarjetas electrónicas de montaje

superficial . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.2.2. Fabricación de partes para robots didácticos . . . . . . . . 121
5.2.3. Tareas de soporte y atención . . . . . . . . . . . . . . . . . 122
6. Conclusiones y Trabajos Futuros 123

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.1.1. Sobre el tablero de control principal . . . . . . . . . . . . . 123
6.1.2. Sobre el tablero de control secundario . . . . . . . . . . . . 126
6.1.3. Sobre el software de gestión local . . . . . . . . . . . . . . 128
6.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2.1. Traslado del servidor . . . . . . . . . . . . . . . . . . . . . 131
6.2.2. “Vision” remota de la cúpula . . . . . . . . . . . . . . . . 132
6.2.3. Control de giro cúpula . . . . . . . . . . . . . . . . . . . . 134
A. Códigos Magnetómetros 141

A.1. Código de implementación magnetómetro MAG3110 . . . . . . . . 141
A.2. Código de desarrollo brújula compensada con acelerómetro LSM303C145
B. Código tablero secundario para control de compuerta de obser-

vación 151
B.1. Código final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Lista de Figuras
2-1. Domo astronómico . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2-3. Ruedas de giro horizontal . . . . . . . . . . . . . . . . . . . . . . 10
2-2. Motor AC para rotación horizontal . . . . . . . . . . . . . . . . . 10
2-4. Inversión de giro con interruptor reversible de barril[2] . . . . . . 11
2-5. Compuerta doble espacio de observación . . . . . . . . . . . . . . 12
2-6. Motores DC para apertura y cierre de compuerta . . . . . . . . . 13
2-7. Puente H con interruptor de 3 posiciones . . . . . . . . . . . . . . 13
2-8. Principio de funcionamiento telescopio Newtoniano[7] . . . . . . . 14
2-9. Telescopio en montura ecuatorial[9] . . . . . . . . . . . . . . . . . 15
2-10.Montaje final telescopio . . . . . . . . . . . . . . . . . . . . . . . 16
2-11.Arreglo de conmutadores para invertir giro de motor AC . . . . . 17
2-12.Implementación de elementos de seguridad . . . . . . . . . . . . . 18
2-13.Magnetómetro MAG3110[5] . . . . . . . . . . . . . . . . . . . . . 19
2-14.Lectura normalizada en el plano xy . . . . . . . . . . . . . . . . . 20
2-15.Magnetómetro MAG3110 implementado . . . . . . . . . . . . . . 21
2-16.Sistema coordenado brújula digital[15] . . . . . . . . . . . . . . . 22
2-17.Diagrama de rotación para cada uno de los ejes[15] . . . . . . . . 22
2-18.Montaje experimental brújula compensada en inclinación . . . . . 25
2-19.Calculo de valor de Azimut con LSM303C . . . . . . . . . . . . . 26
2-20.Tipos de encoder[10] . . . . . . . . . . . . . . . . . . . . . . . . . 27
2-21.Sistema de posicionamiento cúpula . . . . . . . . . . . . . . . . . 27
2-22.Encoder fı́sico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2-23.Encoder incremental domo detallado . . . . . . . . . . . . . . . . 29
2-24.Barrido de datos y discretización de los mismos . . . . . . . . . . 30
2-25.Arreglo de conmutadores para compuerta . . . . . . . . . . . . . . 32
2-26.Arreglo con finales de carrera para compuertas . . . . . . . . . . . 33
2-27.Esquema de accionamiento compuerta . . . . . . . . . . . . . . . 33
2-28.Circuito de gestión para compuerta . . . . . . . . . . . . . . . . . 35
xvi LISTA DE FIGURAS
2-29.Detalle iluminación cúpula . . . . . . . . . . . . . . . . . . . . . . 36
3-1. Detalles Raspberry Pi 3 Model B[4] . . . . . . . . . . . . . . . . . 40

3-2. Paradigma de operación protocolo MQTT . . . . . . . . . . . . . 41
3-3. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3-4. Diagrama de clase IoT . . . . . . . . . . . . . . . . . . . . . . . . 45
3-5. Diagrama de clase Dome . . . . . . . . . . . . . . . . . . . . . . . 49
3-6. Diagrama de clase Telescope . . . . . . . . . . . . . . . . . . . . . 60
3-7. Cámara planetaria ZWO ASI120MC[17]. . . . . . . . . . . . . . . 67
3-8. Diagrama de clases subsidiarias para operación de cámara planetaria. 69
3-9. Diagrama de clase ZWO . . . . . . . . . . . . . . . . . . . . . . . 70
3-10.Diagrama de clase Cameraweb. . . . . . . . . . . . . . . . . . . . 75
3-11.Diagrama de clase Instrument. . . . . . . . . . . . . . . . . . . . . 77
3-12.Diagrama de clase Rpi. . . . . . . . . . . . . . . . . . . . . . . . . 79
3-13.Diagrama de clase Buckets3. . . . . . . . . . . . . . . . . . . . . . 81
3-14.Diagrama de clase Broker. . . . . . . . . . . . . . . . . . . . . . . 83
4-1. Arquitectura general de sistema y métodos de comunicación. . . . 85

4-2. Formulario de autenticación para ingreso al aplicativo. . . . . . . 87
4-3. Vista tablero de control. . . . . . . . . . . . . . . . . . . . . . . . 88
4-4. Tarjeta para control de cámara planetaria. . . . . . . . . . . . . . 88
4-5. Tarjeta para control para el telescopio. . . . . . . . . . . . . . . . 89
4-6. Tarjeta para control para gestión de cúpula. . . . . . . . . . . . . 89
4-7. Tarjeta que muestra el estado de los componentes del observatorio. 90
4-8. Vista perfil de usuario. . . . . . . . . . . . . . . . . . . . . . . . . 90
4-9. Arreglo de conmutadores de baja potencia sobre riel DIN. . . . . 92
4-10.Conmutadores industriales. . . . . . . . . . . . . . . . . . . . . . . 93
4-11.Fuentes DC industriales. . . . . . . . . . . . . . . . . . . . . . . . 93
4-12.Protecciones termomagnéticas. . . . . . . . . . . . . . . . . . . . . 94
4-13.Pulsadores y hongo de emergencia. . . . . . . . . . . . . . . . . . 95
4-14.Borneras de conexión tablero principal. . . . . . . . . . . . . . . . 95
4-15.Montaje Raspberry Pi 3 sobre riel DIN. . . . . . . . . . . . . . . . 96
4-16.Distribución elementos dentro de tablero principal. . . . . . . . . 97
4-17.Esquema de alimentación tablero principal. . . . . . . . . . . . . . 97
4-18.Diagrama esquemático del tablero de control principal. . . . . . . 98
4-19.Montaje sobre riel DIN de microncontrolador con screw shield. . . 100
4-20.Borneras de conexión para riel DIN. . . . . . . . . . . . . . . . . . 100
4-21.Relevadores para motores de compuerta vertical. . . . . . . . . . . 101
LISTA DE FIGURAS xvii
4-22.Finales de carrera y motores DC. . . . . . . . . . . . . . . . . . . 101

4-23.Montaje de pulsadores. . . . . . . . . . . . . . . . . . . . . . . . . 102
4-24.Distribución tablero para motores DC. . . . . . . . . . . . . . . . 103
4-25.Plano tablero de control apertura de compuertas. . . . . . . . . . 103
4-26.Esquema de alimentación tablero secundario. . . . . . . . . . . . . 104
4-27.Vista tablero de control principal y pulsadores. . . . . . . . . . . . 105
4-28.Vista interna de tablero de control principal. . . . . . . . . . . . . 106
4-29.Diferentes colores de iluminación. . . . . . . . . . . . . . . . . . . 107
4-30.Vista tablero de control secundario y pulsadores. . . . . . . . . . . 108
4-31.Vista interna tablero de control secundario. . . . . . . . . . . . . . 109
4-32.Júpiter desde el observatorio astronómico de la Universidad Distrital.111
4-33.Saturno desde el observatorio astronómico de la Universidad Distrital.112
4-34.Marte desde el observatorio astronómico de la Universidad Distrital. 112
5-1. Trazado de canaleta autoadhesiva. . . . . . . . . . . . . . . . . . . 116

5-3. Vista de las cámaras instaladas y canaleta autoadhesiva. . . . . . 116
5-2. Montaje televisor y DVR. . . . . . . . . . . . . . . . . . . . . . . 116
5-4. UPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5-5. Toma de energı́a para UPS y toma corrientes de salida de la misma. 117
5-6. Vistas de la estación meteorológica. . . . . . . . . . . . . . . . . . 119
5-7. Consola de control y visualización de datos. . . . . . . . . . . . . 119
5-8. Tarjetas ensambladas en Robótica Colombia S.A.S. . . . . . . . . 120
5-9. Partes para robots didácticos. . . . . . . . . . . . . . . . . . . . . 121
6-1. Cámara en cúpula observatorio. . . . . . . . . . . . . . . . . . . . 132

6-2. Circuito cerrado de TV observatorio UD. . . . . . . . . . . . . . . 133
6-3. Recorte de fase en señal de alimentación. . . . . . . . . . . . . . . 135
6-4. Puente H AC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6-5. Diagrama de bloques circuito de control. . . . . . . . . . . . . . . 136
6-6. Esquemático fuente DC. . . . . . . . . . . . . . . . . . . . . . . . 137
6-7. Detección cruce por cero. . . . . . . . . . . . . . . . . . . . . . . . 137
6-8. Generador base de tiempo para control de fase y forma de onda . 138
6-9. Control de sentido de giro y ángulo de disparo. . . . . . . . . . . . 138
6-10.Conexión optotriac MOC30XX. . . . . . . . . . . . . . . . . . . . 139
6-11.Esquemático general control de fase. . . . . . . . . . . . . . . . . 140
Lista de Tablas
2-1. Tabla de verdad apertura de compuertas . . . . . . . . . . . . . . 34
3-1. Resumen especificaciones Raspberry Pi 3 model B[4] . . . . . . . 39

Introducción
Cuando llego el momento de evaluar el tipo de proyecto de grado que querı́a reali-
zar lo único que tenia realmente claro era el querer aplicar lo que habı́a aprendido
a lo largo de los años en un problema del mundo real, es decir, un proyecto que
permitiera ofrecer una solución a un problema fuera del ambiente académico en el
cual se desenvuelven los años de formación de pregrado, sumado a esto, la afinidad
desarrollada con el tiempo hacia el campo de la automatización industrial y los
sistemas embebidos me permitieron encontrar en el proyecto de automatización
del observatorio astronómico de la Universidad Distrital la opción perfecta para
cumplir con estas expectativas, puesto que si bien cumplı́an con lo expresado an-
teriormente no se alejaban demasiado del mundo académico además que hacı́an
posible el retribuir en cierta forma a la Universidad por la educación recibida.
El problema a abordar consistı́a entonces en llevar a cabo la implementación de

un esquema de automatización para el observatorio, el cual permitiera desde una
página web obtener imágenes de la luz captada por el telescopio, ası́ como el poder
mover este y rotar la cúpula, con lo que resulta necesario el establecer una meto-
dologı́a concreta para ofrecer una solución para dicho problema, esta consiste en
primera instancia en llevar a cabo una identificación del estado del observatorio
al momento de inicio de la ejecución del proyecto, para posteriormente definir los
elementos existentes que pueden emplearse y los desarrollos adicionales necesarios.
Una vez se definen los requerimientos del proyecto se parte el desarrollo en dos
lı́neas paralelas, por un lado se tiene el desarrollo de hardware y por otro el desa-
rrollo en software, no se puede hablar de uno sobre el otro pues la construcción
de uno esta justificada en el otro; para los dos casos se parte del concepto de
modularidad, es decir, entender al observatorio no como una estructura monolı́ti-
ca si no mas bien como la unión de varios componentes pequeños, esto ayuda a
la segmentación y agiliza el desarrollo de software además que permite enfocar
componentes de hardware a un problema especı́fico.
2 INTRODUCCIÓN
El lector del presente trabajo encontrara en el primer capı́tulo el planteamiento

del problema que se desea resolver, la justificación del mismo y los objetivos con-
cretos que se cumplieron durante el desarrollo del proyecto de grado, esto con el fin
de acotar los alcances del mismo y poder entender claramente lo que se buscaba
desde el comienzo.
En el segundo capı́tulo se lleva a cabo la identificación del estado del observatorio,

la instalación del telescopio y las consideraciones sobre el mismo, ası́ como la pri-
mera segmentación de componentes y los diseños para cada uno de ellos, también
se explica como se resuelven algunos de los primeros problemas para dar la fun-
cionalidad deseada, tales como la forma de rotar la cúpula en forma controlada, la
ubicación de la misma, la apertura de las compuertas y otros; también se muestra
la primera lista expandida de requerimientos a bajo nivel para los componentes
del observatorio y como a partir de ellos se empieza a construir la solución.
EL tercer capı́tulo se ocupa de definir los requerimientos que debe satisfacer el

software de gestión local, cuál deber ser la comunicación que debe sostener con
el resto del proyecto, sobre que sistema embebido debe ejecutarse y cuál es el
lenguaje de programación que se considera adecuado para escribirlo y porqué ha-
cerlo en el mismo; posteriormente expone la arquitectura del software y da una
detallada documentación sobre cada una de las clases que componen el mismo,
incluyendo sus listas de atributos, sus hilos de ejecución, los métodos que poseen
y los elementos de hardware que son gestionados por cada una.
El cuarto capı́tulo, expone la arquitectura general de todo el proyecto, la forma en

que se relaciona cada uno de los componentes y posteriormente retoma lo desa-
rrollado en los capı́tulos anteriores con el fin de desarrollar la forma en que se
interrelacionan, también explica la implementación fı́sica final del hardware y las
consideraciones finales sobre el software generado, finalmente ofrece un análisis
sobre los resultados.
EL último capitulo muestra algunas actividades complementarias desarrolladas

durante la duración del proyecto, referentes a la instalación de equipos adicionales
para el observatorio tales como una estación meteorológica, un sistema de vigi-
lancia empleando un circuito cerrado de televisión y un dispositivo de respaldo de
energı́a para los equipos del observatorio, también incluye una referencia a algu-
INTRODUCCIÓN 3
nas actividades desarrolladas como parte del convenio con la empresa Robótica
Colombia S.A.S., configurando ası́ el final de un proceso de cerca de un año, es-
perando claro, no faltar a los resultados esperados de un trabajo de grado de la
Universidad Distrital Francisco José de Caldas.
Capı́tulo 1
Generalidades
1.1. Planteamiento del problema

La astronomı́a en Colombia es un campo que si bien no representa un gran peso en
las tareas de investigación realizadas a nivel nacional, no deja de representar una
disciplina ampliamente extendida a nivel académico en diferentes instituciones,
como es el caso de la Universidad Nacional, la Universidad de Nariño, la Uni-
versidad del Bosque y la Universidad de los Andes, sobre esta última se pueden
mencionar algunos proyectos tales como la medición del espectro solar en alta
resolución[14] o la medición de propiedades fı́sicas de Menkalinan y Capella[13],
los cuales fueron desarrollados por estudiantes de la misma, los resultados de estos
experimentos suelen ser empleados para la publicación de artı́culos o la aplicación
de los mismos como material de enseñanza para los cursos que se dictan en algu-
nos pregrados.
También es importante mencionar a organizaciones como la Red de Astronomı́a

de Colombia(RAC), que organiza eventos en los cuales se permite el intercam-
bio de información entre universidades, planetarios u otras entidades adscritas a
ella, lo que permite ubicar a la astronomı́a como una fuente potencial de enlaces
académicos y de construcción cientı́fica que no deberı́a ser despreciada por ningún
centro educativo, para el caso de la Universidad Distrital, resulta sumamente per-
tinente en el programa de Ingenierı́a Catastral y Geodesia.
En el año 2013 se completó el proceso de remodelación del antiguo matadero de

la ciudad de Bogotá con el fin de convertirlo en la biblioteca central de la Univer-
sidad Distrital, proceso en el que se optó por construir una cúpula astronómica en
el lugar donde antes se emplazaba el tanque de agua[3], en la actualidad se cuenta
con la infraestructura fı́sica, los telescopios y también con el montaje mecánico
6 1 Generalidades
que permite realizar la apertura y la rotación de la cúpula el cual es accionado

por un interruptor manual, luego no existe ningún tipo de sistema de gestión que
permita administrar de forma conjunta los equipos de observación disponibles en
conjunto con la cúpula, resultando ası́ en una situación en la cual los equipos
suelen emplearse en los niveles inferiores y/o alrededores del observatorio y no en
el espacio donde se planeó originalmente.
Lo anterior expuesto limita el acceso y el uso potencial que se puede hacer del
espacio y los equipos disponibles, lo cual permite formular la siguiente pregunta:
¿será posible la implementación de un sistema de automatización para el obser-
vatorio astronómico de la Universidad Distrital?, resolver este interrogante es el
objetivo principal de este trabajo.
1.2. Objetivos
1.2.1. Objetivo General
Implementar un sistema que permita realizar observaciones astronómicas en el
observatorio astronómico de la Universidad Distrital Francisco José de Caldas,
mediante un proceso de automatización que posibilite la operación autónoma del
mismo.
1.2.2. Objetivos especı́ficos

1. Diseñar e integrar los componentes de hardware, eléctrico y electrónico, para
el control de giro de la cúpula del observatorio, y la apertura de puertas
horizontales de la misma.
2. Desarrollar el software para generar el enlace remoto entre el hardware y el

sistema embebido de gestión central.
3. Llevar a cabo la integración global de los diferentes elementos que constitu-

yen el proyecto en su conjunto, tales como el tablero electrónico de control,
los telescopios, las cámaras de captura de datos y el software de gestión, ası́
como en la realización de pruebas de funcionamiento.
4. Integrarse en las actividades propias de la empresa Robótica Colombia S.A.S,

tales como el ensamble de productos electrónicos, verificación de funciona-
lidad, entre otras actividades.
1.3 Aportes 7
5. Realizar la socialización de las actividades desempeñadas en el marco de la

pasantı́a ante la comunidad académica de la Universidad Distrital Francisco
José de Caldas.
1.3. Aportes
Los aportes hacia la Universidad Distrital Francisco José de Caldas producto del
presente trabajo son los siguientes:
Tableros de control: Los tableros de control construidos durante el tiempo

de este proyecto se instalan en las instalaciones del observatorio astronómico
de la universidad, los planos de los mismos ası́ como la descripción de su
funcionalidad se encuentran en el presente documento.
Software: El software de gestión local desarrollado en python se encuentra

almacenado en la placa Raspberry Pi 3 en el tablero de control principal,
dentro del presente documento se incluye documentación detallada acerca
de su funcionamiento ası́ como la API del mismo.
Instalación de equipos: como aporte final se puede mencionar la instalación

de equipamiento adicional en las instalaciones del observatorio, especı́fica-
mente un circuito de televisión cerrado para seguridad del sitio, una UPS
para respaldo en caso de cortes de energı́a y una estación meteorológica con
instrumentación suficiente para llevar a cabo estudios del comportamiento
climático en el centro de la ciudad.
8 1 Generalidades
Capı́tulo 2
Diseño de hardware de gestión para la
cúpula del observatorio
Este capı́tulo parte realizando una identificación del estado del observatorio mos-
trado en la Figura 2-1 al momento del inicio de ejecución del proyecto, con el fin
de definir claramente los requerimientos a satisfacer durante el tiempo de desa-
rrollo, también se ocupa de la instalación del telescopio en el observatorio, ası́
como de proponer lo básico en cuanto a diseño del esquema de automatización y
el hardware necesario para el mismo.
2.1. Tareas preliminares e identificación

2.1.1. Descripción del sistema
Una cúpula astronómica posee dos controles básicos, uno referente al giro en sen-
tido horizontal y otro relacionado con la apertura y cierre de la compuerta de
observación, a los cuales se relacionan actuadores y sensores con el fin de ejercer
control sobre los mismos.
Figura 2-1: Domo astronómico

10 2 Diseño de hardware de gestión para la cúpula del observatorio
Figura 2-3: Ruedas de giro horizontal
El diámetro de la cúpula es de 4 metros, lo cual implica un perı́metro de 12.566

metros, este valor se toma como equivalente a 360 grados correspondientes a toda
la rotación de la cúpula.
Figura 2-2: Motor AC para rotación horizontal
2.1.2. Consideraciones sobre el movimiento de rotación

horizontal
Para el movimiento horizontal se dispone de un sistema de rotación basado en un
tubo circular descansado sobre ruedas (ver Figura 2-3), de las cuales solamente
una de ellas realiza trabajo motriz activo, siendo las demás auxiliares, la velocidad
de rotación de la cúpula es de cerca de 5.1428 grados por segundo.
El actuador para el giro es un motor AC monofásico de medio caballo de potencia
conectado a través de una cadena a la rueda mencionada previamente, mostrado
2.1 Tareas preliminares e identificación 11
en la Figura 2-2.
Enunciando de manera resumida, para controlar el sentido de giro de un motor

AC monofásico de dos bobinados, solo basta con controlar la fase de la corriente
en uno de los dos bobinados, esto es, si se tiene que la corriente circula en el mismo
sentido en los dos bobinados se tendrá una rotación en un sentido, si se invierte
la polaridad de uno de los bobinados, se genera movimiento en el sentido inverso,
lo cual se consigue conmutando fı́sicamente los contactos de los dos bobinados tal
como se muestra en la Figura 2-4.
Figura 2-4: Inversión de giro con interruptor reversible de barril[2]
En el estado inicial del observatorio, se dispone de un interruptor reversible de

barril, el cual es un elemento conmutable de 3 posiciones y 6 pines de conexión,
haciendo uso de un juego de conexiones se puede conseguir fácilmente el efecto
de conmutación de las conmutaciones de los bobinados del motor ilustrado en la
Figura 2-4 y por ende la inversión del sentido de giro de la cúpula, dado a que se
trata de un sistema netamente mecánico, la rotación de se realiza en la medida
que se mantenga accionado el interruptor, luego no se dispone de ningún elemento
sensor para el control de giro horizontal.
El elemento que puede observarse en la Figura 2-4 conectado en serie a una de
las dos bobinas se denomina interruptor centrifugo, y tiene la particularidad de
desconectar la alimentación de la bobina una vez la velocidad de giro del rotor ha
alcanzado una velocidad determinada, esto obedece a una de las particularidades
del motor AC monofásico, el cual emplea una bobina auxiliar o de arranque en
la fase inicial del movimiento, y posteriormente se vale de una segunda bobina
conectada a través de un condensador al devanado principal, desde la cual obtiene
la alimentación necesaria para mantener la rotación del motor, con este sistema
en particular, se consigue disminuir el impulso inicial de corriente en el arranque

de la maquina.
Figura 2-5: Compuerta doble espacio de observación
2.1.3. Consideraciones sobre compuerta vertical
El espacio vertical de observación cuenta con un arreglo de compuerta doble, es

decir, un sistema de dos compuertas deslizantes que se mueven en contrasentido
tanto para apertura como para cierre, estas compuertas pueden observarse en la
Figura 2-5, la longitud del espacio de observación con las compuertas totalmente
desplegadas es de 1 metro, tomando en cuenta un perı́metro total de 12.566 metros
de la cúpula, la apertura equivale a un total de 28.6473 grados, a través de los
cuales debe ser apuntado el telescopio, este dato resulta de interés puesto que
permite establecer el grado de rigurosidad que debe manejarse en el diseño del
sistema de control de giro horizontal.
Cada una de estas cuenta con un motor de DC de 12 V 0.85 A como sistema
motriz, el cual se encuentra instalado en la base de las mismas, y conectado a las
compuertas a través de una cadena en la forma que se puede observar en la Figura
2-6.
Figura 2-6: Motores DC para apertura y cierre de compuerta
Como elemento de gestión para la apertura y cierre de las compuertas se dispone

de un interruptor de 6 posiciones, el cual permite conmutar la polaridad de la
corriente que se inyecta a los motores DC, cerrando o abriendo las compuertas
según la posición seleccionada, el principio de funcionamiento de este interruptor
se detalla en la Figura 2-7.
Figura 2-7: Puente H con interruptor de 3 posiciones
No se dispone de ningún elemento sensor que permita determinar una posición de

inicio o de final para ninguna de las dos compuertas,lo cual implica que cada una
de estas se detiene al obstaculizarse fı́sicamente con los elementos del montaje,
y dado que las compuertas no se desplazan a la misma velocidad, se tiene que
uno de los motores, al llegar al final del recorrido sigue alimentado hasta que la
otra compuerta termine su recorrido, lo que ocasiona un sobre esfuerzo que puede
ocasionar el daño del mismo.
2.1.4. Consideraciones sobre el telescopio Meade LX200

GPS
Se dispone de un telescopio Meade de la linea LX200, con un tamaño de 14
pulgadas para ser emplazado en la cúpula astronómica, este tipo de telescopios
son conocidos como telescopios Newtonianos, puesto que basan su funcionamiento
en un arreglo de espejos.
Figura 2-8: Principio de funcionamiento telescopio Newtoniano[7]
Observando la Figura 2-8 se puede apreciar que el principio de funcionamiento de

un telescopio Newtoniano contrasta en gran medida de los telescopios llamados
refractores, en los cuales se emplean distintos tipos de lentes para hacer que la
luz proveniente de objetos ubicados en el infinito converja hacia un punto focal
donde se observan mas grandes y brillantes, pero con la desventaja de aberracio-
nes producidas en la imagen captada originadas por el paso de la luz a través del
material de las lentes, lo cual los hace poco fiables en la observación de objetos
muy alejados o cuando se desean relaciones de aumento elevadas, los telescopios
Newtonianos o refractores emplean un espejo principal o colector que desvı́a los
rayos de luz hacia un punto focal especı́fico, donde se ubica otro espejo el cual
envı́a los rayos de luz hacia el ocular, esta ultima pieza posee una lente, esta ul-
tima pieza es la que determina la relación de aumento en función de la distancia
focal que se forme entre la misma y el espejo secundario.
Dado que el tamaño de la imagen percibida en un telescopio Newtoniano no

esta dada en función del tamaño de la lente ocular, se minimizan las posibles
aberraciones cromáticas que pueden originarse por el paso de la luz a través de la
misma, adicionalmente, los espejos son mas fáciles de fabricar y mas livianos que
una lente convencional, lo cual ha ocasionado que al dı́a de hoy se prefieran sobre
los telescopios refractores.
Figura 2-9: Telescopio en montura ecuatorial[9]
En la etapa de montaje del telescopio se opto por una montura ecuatorial como
la que se muestra en la Figura 2-9, la cual permite realizar el seguimiento de los
objetos celestes en los ejes de ascensión recta y declinación, con el fin de garantizar
un desplazamiento del telescopio en el sentido de rotación de la tierra, la Figura
2-10 permite contemplar el montaje final para el telescopio.
Con el fin de poder realizar el seguimiento de objetos celestes, es necesario realizar

un proceso de calibración del telescopio una vez ha sido emplazado, para lo cual
se sigue el siguiente procedimiento[8] que emplea dos estrellas:
Configurar fecha y hora.
Centrar la estrella polar en el ocular del telescopio e indicarle al mismo que

se ha hecho.
Seleccionar un estrella cualquiera, centrarla en el ocular e indicarle al teles-

copio que esa posición corresponde a la misma.
Se debe repetir el paso anterior con una tercera estrella.
Finalmente se debe iniciar el seguimiento de un objeto celeste e ir ajustando

fı́sicamente la montura para que el objeto de interés este siempre centrado.
Figura 2-10: Montaje final telescopio
Una vez finalizado el procedimiento de alineación, el telescopio se encuentra en

condiciones de iniciar el seguimiento de los objetos que se muestran en el catálogo
del aplicativo.
2.2. Diseño e implementación de sistema gestión

de giro horizontal para cúpula
Partiendo de lo expuesto en la sección anterior, se realiza una identificación previa
de los requerimientos que se desean satisfacer durante el tiempo de desarrollo:
Tener control sobre el sentido de la cúpula, tanto en forma remota, como en

forma local.
Controlar la iluminación al interior del espacio, tanto en forma local como

en forma remota.
Disponer de un mecanismo de sincronismo que permita orientar las com-

puertas con el telescopio alojado en el interior de la cúpula.
Evaluar las condiciones meteorológicas del sitio y determinar si se puede o

no realizar una sesión de información.
2.2 Diseño e implementación de sistema gestión de giro horizontal para cúpula 17
2.2.1. Control de giro

El sentido de rotación de la cúpula depende del giro del motor AC monofásico ins-
talado, luego debe poder administrarse la dirección del mismo, como ya se explico
anteriormente, esto puede conseguirse de forma relativamente sencilla conmutan-
do las conexiones a uno de los bobinados del mismo, ya sea el de trabajo o el
de magnetización, dado que la velocidad de rotación de la cúpula es de 5.1428
grados por segundo y la del telescopio Meade LX200 es de 3 grados por segundo
en su configuración más rápida, no se considera necesario variar la velocidad de
desplazamiento, el sistema para invertir el giro planteado consiste en un arreglo
de reveladores industriales conmutables.
(a) Giro en sentido horario
(b) Giro en sentido anti horario (c) Estado de reposo
Figura 2-11: Arreglo de conmutadores para invertir giro de motor AC
La Figura 2-11 nos muestra los diferentes casos que se presentan en el arreglo
planteado, en el estado de reposo se mantiene las dos terminales del bobinado de
trabajo conectados al neutro de la linea de alimentación, en tanto que el bobinado
de magnetización se encuentra fı́sicamente desconectado de la linea, para el caso
en el cual conmuta el rele K1, el bobinado de trabajo se conecta entre lı́nea y
neutro, el bobinado de magnetización también es energizado, luego se consigue la
rotación del motor; para conseguir el giro en sentido opuesto se conmuta el rele K2,
con lo cual se invierte el sentido de la corriente en el bobinado de trabajo, en tanto

que el bobinado de magnetización se energiza igualmente; si se presenta el caso
en el cual los dos conmutadores son accionados, el motor no realiza movimiento
alguno, lo que permite garantizar una operación transparente para el usuario.
(a) parado de emergencia (b) Protección termomagnética
Figura 2-12: Implementación de elementos de seguridad
Como medida de seguridad es necesario implementar un arreglo de parada de

emergencia, que garantice el poder evitar accidentes durante la rotación de la
cúpula, lo cual resulta en un diagrama de conexión como el mostrado en la Figura
2-12, de acuerdo a normatividad, los pasos de emergencia deben hacerse a través
de contactos normalmente abiertos, con el fin de descartar fallas por ausencia de
energı́a a través del pulsador de desconexión, adicionalmente, con el fin de garan-
tizar que el sistema implementado sea robusto, es necesario agregar protecciones
termomagnéticas que garanticen la integridad de los elementos adicionales que
estén conectados a la misma red de alimentación.
Con el fin de garantizar que el colector del telescopio este apuntando siempre
hacia el espacio de observación, es necesario desarrollar un sistema que permita
determinar cual es la orientación del colector del telescopio y en consecuencia,
desplazar el espacio de observación hasta que el colector del telescopio sea puntado
a través de dicho espacio; el telescopio Meade LX200 permite obtener a través de
comunicación serial su valor de de azimut, esto es, la orientación del colector en

grados con respecto al norte geográfico terrestre, esto conlleva a la construcción
de un sistema similar para la cúpula que permita determinar la coordenada de
azimut para las compuertas.
2.2.2. Orientación de cupula mediante brújula digital

Un magnetómetro digital es un dispositivo que permite determinar la intensidad
del campo magnético de la tierra medido en un determinado lugar, estos dispo-
sitivos permiten obtener la lectura en los 3 ejes espaciales, la arquitectura básica
de los mismos se muestra en la Figura 2-13, de donde se puede observar fácil-
mente un dispositivo de lectura en forma secuencial de los tres componentes de
campo magnético y una interfaz de comunicación I2C para la lectura de los datos
adquiridos.
(a) Arquitectura
(b) Encapsulado
Figura 2-13: Magnetómetro MAG3110[5]
Para el tipo de aplicación inicial se pensó en emplear solamente las lecturas en los
ejes x y y, puesto que se tiene de acuerdo con la hoja de datos[5] del dispositivo,
cuando este se encuentra orientado hacia el norte, la lectura en el eje x tiene su
mayor valor entero, en tanto que la lectura el eje y tiene un valor de cero o una
magnitud cercana al mismo, tal como se ilustra en la Figura 2-14; es necesario
aclarar que estas gráficas se encuentran elaboradas con valores normalizados con
el fin de ilustrar de manera mas adecuada el comportamiento, en primera instan-
cia. La Figura 2.14(a) muestra la distribución inicial de las lecturas al realizarse

el procedimiento inicial de barrido a lo largo de los 360o , encontrándose ası́ la
existencia de un offset en las lecturas que debe corregirse con el fin de obtener
un cálculo preciso de la orientación del dispositivo, para esto solo debe obtenerse
cual es el valor medio de desviación, esto es, realizar la resta en valor absoluto
entre el valor positivo y el valor negativo, luego tomar dicho resultado y cargarlo
en los registros de offset existentes en el dispositivo con el fin de realizar la com-
pensación de la lectura, el código asociado a este procedimiento fue implementado
en un microcontrolador ATMEGA328p y puede ser encontrado en los anexos del
presente documento.
(a) Lectura sin calibración (b) Lectura calibrada
Figura 2-14: Lectura normalizada en el plano xy
La Figura 2.14(b) muestra la distribución de las lecturas obtenidas del magnetóme-

tro una vez ha sido calibrado, lo cual se demuestra en la simetrı́a de las mismas
a lo largo de los ejes, como se ha dicho anteriormente, cuando el dispositivo se
encuentra orientado hacia el norte, la lectura obtenida corresponde con el máximo
valor de la misma en el eje x en tanto que sera 0 en el eje y, dado que la gráfica
correspondiente al barrido a lo largo de los 360o es un cı́rculo y que la variación
en grados debe darse a favor de las manecillas del reloj, la posición en grados
respecto al norte puede calcularse con la expresión:

o −1 −M agy
Θ( ) = tan (2-1)
M agx
Cuando se trate de una lectura en la cual se tenga un punto ubicado en el tercer
o en el cuarto cuadrante del plano, es necesario aplicar la corrección:
(a) Montaje experimental (b) Lecturas obtenidas
Figura 2-15: Magnetómetro MAG3110 implementado

o −M agy
Θ( ) = tan −1
+ 180o (2-2)
M agx
El código final empleado, puede ser encontrado en el primer apéndice del docu-
mento, el montaje experimental empleado se muestra en la Figura 2.15(a), en
tanto que la salida del dispositivo se muestra en la Figura 2.15(b), resultando ası́
en una implementación satisfactoria que en inicio resuelve el problema planteado.
Sin embargo, lo anteriormente expuesto funciona asumiendo la instalación del dis-

positivo en forma totalmente paralela al nivel de referencia terrestre, esto es, sin
que se presenten desplazamientos en el plano Z a medida que el magnetómetro
rota, que puedan generar variaciones en las lecturas de los componentes de cam-
po magnético, esto constituye una importante desventaja puesto que restringe la
forma en que el chip puede ser instalado en la cúpula del observatorio además
de no poderse garantizar de forma totalmente segura una posición en la cual no
se presenten alteraciones en la inclinación de la placa donde se coloca en última
instancia el magnetómetro.
Como solución a este problema, se propone el combinar un magnetómetro con

un acelerómetro digital, con el fin de determinar la inclinación para realizar el
ajuste de las lecturas obtenidas, el dispositivo seleccionado es el LSM303C de
STMicroelectronics, de acuerdo a la nota de aplicacion AN3192[15], previamente
haber llevado a cabo la calibración del acelerómetro y de magnetómetro, se parte
de los tres tipos de rotación que se pueden presentar:
Figura 2-16: Sistema coordenado brújula digital[15]
De la Figura 2-16 se puede definir:

Heading(Ψ): también conocido como Azimut, es el valor en grados con res-
pecto al polo norte magnético, si se desea obtener la posición con respecto al
polo norte geográfico, es necesario tomar en cuenta la declinación de acuerdo
a la posición geográfica donde se este realizando la lectura.
Pitch(ρ): es el ángulo definido entre el plano horizontal y el vector Xb , de-

pendiendo de la dirección hacia la que apunte el vector Yb puede variar entre
0o y 90o o entre −90o y 0o .
Roll(γ): es el ángulo definido entre el plano horizontal y el vector Yb , depen-

diendo de la dirección hacia la que apunte el vector Xb puede variar entre
0o y 90o o entre −90o y 0o .
Del sistema coordenado mostrado en la Figura 2-16 pueden obtenerse las matrices
de rotación para cada uno de los ejes:
Figura 2-17: Diagrama de rotación para cada uno de los ejes[15]

cos Ψ sin Ψ 0
 
R(Ψ) = − sin Ψ cos Ψ 0 (2-3)

0 0 1
cos ρ 0 − sin ρ
 
R(ρ) =  0 1 0  (2-4)
sin ρ 0 cos ρ
1 0 0
 
R(γ) = 0 cos γ sin γ  (2-5)

0 − sin γ cos γ
Haciendo uso de las ecuaciones 2-3, 2-4 y 2-5 es posible relacionar los valores
de posición de referencia con los valores primados de posición, en función de los
ángulos de rotación que posea el dispositivo en un momento dado haciendo uso
de la siguiente relación:
   
Xb′ Xb
 Yb  = R(Ψ)R(ρ)R(γ)  Yb 
′
(2-6)
Zb′ Zb
cos ρ cos Ψ cos ρ sin Ψ − sin ρ

    
Xb′ Xb
 Yb′  = cos Ψ sin ρ sin γ − cos γ sin Ψ sin Ψ sin ρ sin γ + cos γ cos Ψ cos ρ sin γ   Yb 
Zb′ cos Ψ sin ρ cos γ + sin γ sin Ψ cos γ sin ρ sin γ − sin γ cos Ψ cos ρ cos γ Zb
(2-7)
Al observar detenidamente la Figura 2-17, se tiene que cuando el dispositivo
se encuentra sobre el plano horizontal, Xb = Yb = 0 y Zb = +1g. cuando el
dispositivo rota y se encuentra en las coordenadas [Xb′ Yb′ Zb′ ] se tienen lecturas
del acelerómetro Ax Ay Az de valor entero con signo, ahora bien, al normalizar
estos valores, se obtienen nuevas magnitudes Ax1 Ay1 Az1 , las cuales tienen valores
positivos o negativos menores en magnitud a 1, si se obtiene la magnitud del vector
conformado por los 3 componentes, el valor debe ser igual a 1, luego la ecuación
2-7 puede ser reescrita como sigue:
cos ρ cos Ψ cos ρ sin Ψ − sin ρ 0

    
Ax1
Ay1  = cos Ψ sin ρ sin γ − cos γ sin Ψ sin Ψ sin ρ sin γ + cos γ cos Ψ cos ρ sin γ  0
Az1 cos Ψ sin ρ cos γ + sin γ sin Ψ cos Ψ sin ρ sin γ − sin γ cos Ψ cos ρ cos γ 1
(2-8)
Con lo cual pueden calcularse los ángulos Pitch(ρ) y Roll(γ) como se muestra:
P itch = ρ = sin−1 (−Ax1 ) (2-9)

−1 Ay1
Roll = γ = sin (2-10)
cos ρ
De acuerdo a la ecuación 2-10, se tiene que para el caso en el que ρ = ±90o se tiene
una división sobre 0, ante esto, se puede tomar γ = 0, también es necesario hacer
notar que la función arcsin(x) solo presenta una buena linealidad en el intervalo
de x = −45o a x = +45o , luego no es posible realizar una compensación exacta
para valores de rotación mayores a los ángulos limite del intervalo.
Ahora bien, suponiendo que el dispositivo rota de la posición [Xb Yb Zb ] a la

posición [Xb′′ Yb′′ Zb′′ ] a través de un movimiento en γ seguido por un movimiento
en ρ, se tiene que la matriz de transformación para las 3 coordenadas en función
de los ángulos de rotación esta dada por:
   ′′ 
Xb Xb
 Yb  = R(ρ)−1 R(γ)−1  Yb′′  (2-11)
′′
Zb Zb
cos ρ 0 sin ρ
     ′′ 
Xb Xb
 Yb  =  sin ρ sin γ cos γ − cos ρ sin γ   Yb′′  (2-12)
Zb − sin ρ cos γ sin γ cos ρ cos γ Zb′′
Al tomar las lecturas del magnetómetro se obtienen las tres componentes [Mx
My Mz ], al normalizar este vector se obtienen los valores [Mx1 My1 Mz1 ], en este
punto, se podrı́a calcular el valor de azimut con las ecuaciones 2-1 y 2-2, y el valor
obtenido seria correcto siempre y cuando el dispositivo se encuentre sobre el plano
horizontal xy, sin embargo, en este caso se conocen los valores de los ángulos de
rotación, luego, pueden obtenerse las cifras correspondientes al equivalente en el
plano horizontal para las componentes de lectura del magnetómetro:
Mx2 = Mx1 cos(ρ) + Mz1 sin(ρ) (2-13)
My2 = Mx1 sin(γ) sin(ρ) + My1 cos(γ) − Mz1 sin(γ) cos(ρ) (2-14)
Mz2 = −Mx1 cos(γ) sin(ρ) + My1 sin(γ) + Mz1 cos(γ) cos(ρ) (2-15)
Finalmente, el valor de azimut puede ser calculado:

−1 −My2
Heading = Ψ = tan (2-16)
Mx2
Si los puntos corresponden con valores del tercer o cuarto cuadrantes:

−My2
Heading = Ψ = tan −1
+ 180o (2-17)
Mx2
Una buena forma de determinar si la compensación se llevo a cabo de forma correc-

ta, consiste en obtener la magnitud del vector [Mx2 My2 Mz2 ], la cual deberı́a ser
igual o muy similar a 1, también es necesario tener en cuenta que el acelerómetro
no consigue distinguir entre gravedad de la tierra, aceleración lineal y aceleración
angular, por este motivo, y tomando en cuenta que el método de compensación se
basa en la gravedad de la tierra, se pueden presentar errores en el cálculo de los
ángulos de inclinación si el dispositivo se somete a variaciones de velocidad con
mucha frecuencia mientras se esta empleando.
El código asociado a esta implementación puede ser consultado en la sección de

anexos, la Figura 2-18 muestra el montaje experimental de la brújula compensa-
da, en tanto que la Figuras 2.19(a) y 2.19(b) muestran la variación del valor de
azimut comparando el valor obtenido por calculo directo y el valor calculado con
compensación.
Figura 2-18: Montaje experimental brújula compensada en inclinación

(a) Lecturas compensada y sin compen- (b) Lecturas compensada y sin compen-
sar en el plano sar con IMU inclinada
Figura 2-19: Calculo de valor de Azimut con LSM303C
Con el desarrollo sobre la IMU LSM303C se satisfacen los requerimientos plan-

teados por la aplicación que se busca desarrollar, sin embargo, al momento de
realizar pruebas de la brújula en el observatorio, se observo que debido al mate-
rial metálico del cual se encuentra elaborada la cúpula, se produce un fenómeno de
apantallamiento magnético que distorsiona el campo magnético en cercanı́as
a la misma, luego no es posible emplear esta propuesta de sincronización entre la
cúpula y el telescopio.
2.2.3. Orientación de cúpula mediante sistema de encoder

incremental
Un encoder es un dispositivo que se emplea para determinar la posición en sistemas
rotativos, existen varios tipos, sin embargo, los mas interesantes en la industria
son los encoder de tipo incremental y de tipo absoluto, los dos sistemas parten de
una misma base común, la cual consiste en un disco con un patrón grabado sobre
el mismo.
En la Figura 2-20 se detalla el funcionamiento de cada uno de los encoders men-

cionados, un encoder incremental posee un patrón regular de ranuras A y B a
lo largo de toda su superficie, apuntando a una de las caras del disco se colocan
elementos fotoemisores, en tanto que en la cara posterior se ubican sensores fo-
tosensibles con el fin registrar que se ha producido un desplazamiento, pero es
responsabilidad del controlador del cual se disponga el llevar a cabo el conteo de
ubicación, es importante notar que este dispositivo posee una ranura adicional C
cuya función es servir de referencia para el cero u origen, lo cual implica que en las
(a) Encoder incremental (b) Encoder absoluto
Figura 2-20: Tipos de encoder[10]
aplicaciones donde se emplee un encoder incremental se debe tener un mecanismo

de vuelta a cero antes de poder realizar la puesta en marcha del sistema; por su
parte, el encoder absoluto posee un patrón mucho mas complejo y requiere por
tanto de un mayor numero de elementos fotoemisores y fotorreceptores, lo cual
posibilita el generar un código único para cada posición, esto permite determinar
el estado del sistema aun durante la puesta en marcha inicial del mismo, este
tipo se suele preferir sobre la topologı́a incremental en tareas donde la precisión
o velocidad es critica para el funcionamiento del sistema.
(a) Domo UD (b) Arreglo de encoder construido
Figura 2-21: Sistema de posicionamiento cúpula
Para el caso de este observatorio en particular se opta por construir un sistema de

encoder incremental a la medida, para lo cual se agregan sobre la parte inferior
de la cara interna una serie de objetivos los cuales son apuntados por sensores de
distancia con el fin de medir el desplazamiento de la cúpula a medida que esta
Figura 2-22: Encoder fı́sico
rota, la Figura 2-21 ilustra lo expresado anteriormente.
Dado que la cúpula posee un diámetro de 4 metros, se puede hablar de:
Perimetro = 4mts ∗ Π = 12,566mts (2-18)

12,566m m
Rmetros/grado = o
= 0,0349 o (2-19)
360
Ahora bien, la longitud del espacio de observación es de 1 metro que corresponden
a un total de 28,647o , se dispone entonces de un total de 333,353o que deben ser
cubiertos con objetivos con el fin de llevar el control de rotación, ahora bien, el
colector del telescopio disponible tiene un tamaño de 14 pulgadas, luego, puede
asignarse a este un tamaño en grados de acuerdo a las convenciones que se han
venido empleando:
Ttelescopio = 14” = 0,3556m = 10,1871o (2-20)
Puesto que el espacio de observación de la cúpula dobla en tamaño al colector del

telescopio, se puede concluir que no se requiere una resolución muy alta para ga-
rantizar el apuntar correctamente el telescopio a través de este, luego se opta por
colocar un objetivo cada 5o , en metros corresponde a 17.45 cm, para un espacio
de 333,35o resulta en un total de 67 objetivos, la Figura 2-22 muestra el montaje
fı́sico de los mismos.
Al observar las dos ilustraciones mostradas en la Figura 2-23, se tiene que al

tratarse de un encoder incremental es necesario definir un mecanismo de posición
inicial, para lo cual, se coloca un objetivo ligeramente mayor en tamaño a los
otros, el sensor obtendrá una lectura en un rango especifico de distancia solo para
el caso en el cual este sea apuntado, para los demás objetivos el valor de lectura
estará alejado de dicho rango; el segundo sensor cumple las veces de auxiliar para
el caso en el cual el sensor principal se encuentre ante la compuerta de observación;
cuando el sistema se enciende el primer paso es rotar la cúpula hasta la posición de
Home, posteriormente, se obtiene el valor de azimut del telescopio se determina
cual es el valor múltiplo de 5 mas cercano a este y se realiza la rotación en el
sentido que resulte en un menor desplazamiento, al igual que para el caso del
magnetómetro, se entiende que el ángulo de azimut aumenta en el sentido de las
manecillas del reloj.
(a) Vista en perspectiva (b) Vista esquemática
Figura 2-23: Encoder incremental domo detallado
Durante la realización de pruebas para llevar a cabo la implementación del sistema

descrito en este apartado, se encontró que la cúpula no es en absoluta redonda, lo
cual genera un fenómeno de oscilación en el patrón de los datos generados por el
sensor a medida que la forma ovalada de la cúpula acerca o aleja su superficie a
medida que esta rota, esto se evidencia en la serie azul de la Figura 2-24, lo cual
imposibilita el definir un rango especifico para determinar la existencia o no de
un objetivo en dicha posición.
La solución consiste en no trabajar sobre un intervalo de distancias determinado,

sino en determinar el cambio de pendiente en los datos captados por el sensor,
para ello se toman 4 muestras consecutivas, a continuación se emplea la última
como valor de referencia desde la cual se evalúa la pendiente de esta con respecto
a las 3 anteriores, si resulta en un valor negativo superior a un determinado valor
de discriminación se toma dicho punto como un objetivo, el resultado de este
procedimiento puede verse en la serie roja de la Figura 2-24, el algoritmo que
Figura 2-24: Barrido de datos y discretización de los mismos
condensa lo planteado se muestra a continuación:

while TRUE do
x[k] ← sensor.getDistance()
if (x[k] − x[k − 3] + x[k] − x[k − 2] + x[k] − x[k − 1]) ≤ umbral then
objective ← T RU E
break
else
objective ← F ALSE
x[k − 3] ← x[k − 2]
x[k − 2] ← x[k − 1]
x[k − 1] ← x[k]
end if
end while
También es posible ver en la Figura 2-24 el valor correspondiente al Home, el cual
es con diferencia menor a todos los demás mostrados, como ventaja del método
expuesto puede mencionarse un comportamiento observado durante el montaje,
el cual consiste en que a medida que la temperatura varia en la superficie de la
cúpula, al tratarse esta de una superficie metálica, se produce un efecto de de-
formación térmica que ocasiona una variación considerable en los datos obtenidos
por el sensor de distancia, sin embargo, las pendientes siguen teniendo el mismo
valor ya que dependen exclusivamente de la transición entre fondo y objetivo, lo
2.3 Diseño de sistema de gestión para compuertas horizontales 31
que en cierta manera hace confiable al sistema.
El sensor empleado es la referencia VL6180X, el cual basa su funcionamiento en

un emisor infrarrojo y un fotodetector para medir el reflejo que ocasiona la luz
emitida sobre la superficie expuesta, dependiendo de la distancia este reflejo tarda
mas o menos tiempo en producirse con lo cual se puede cuantificar la distancia,
es importante decir que dependiendo del color o la regularidad de la superficie
que se ilumine se presentan variaciones en la medida, luego resulta indispensable
que todos los objetivos posean una superficie lisa y un color único, en este caso
planteado, con el fin de eliminar fuentes de error en el procedimiento de medida,
también se debe resaltar que si bien el sensor posee un detector de luz ambiental
que permite compensar la medida, cuando este es expuesto directamente a una
fuente de luz intensa, como bien puede ser la luz del sol, el sensor se satura y
genera su lectura de máximo rango, como solución puede agregarse un cobertizo
que restrinja la iluminación directa por parte del sol; lo anterior no es de obligatorio
cumplimiento, ya que se espera que el sensor opere en dichas condiciones en muy
pocas ocasiones, puesto que se entiende que el observatorio funcionara, por lo
general, durante las noches cuando la mayor fuente lumı́nica disponible en la
luna, no es lo suficientemente potente para saturar el sensor.
2.3. Diseño de sistema de gestión para compuer-

tas horizontales
Como se expuso en la sección 2.1, el espacio de observación de la cúpula del
observatorio astronómico de la Universidad Distrital dispone de un arreglo de
compuerta doble como el que se muestra en la Figura 2-5, cada una de estas
compuertas se desplaza horizontalmente gracias a un motor DC de 12 V como el
mostrado en la Figura 2-6, tomando en cuenta que la velocidad de desplazamiento
o el poder establecer valores de apertura medios son temas irrelevantes para el
funcionamiento deseado, se opta por implementar un mecanismo de inversión de
giro empleando un Puente H como el mostrado en la Figura 2-25.
La forma en la que se realiza la conexión de las borneras de los motores es reci-

proca, puesto que se sobreentiende que para cualquiera de los dos movimientos
el sentido de giro de los motores debe ser contrario respecto al otro, las Figuras
2.25(a) y 2.25(b) muestran los relevadores que deben ser accionados para lograr
(a) Abrir compuertas
(b) Cerrar compuertas (c) Estado de reposo
Figura 2-25: Arreglo de conmutadores para compuerta
cada uno de los dos desplazamientos, como ventaja del empleo de conmutadores
se puede destacar el hecho de no presentarse ningún estado de accionamiento en
el cual se ponga en corto circuito a la fuente de alimentación, para la selección de
componentes debe tomarse en cuenta que la corriente en régimen permanente que
circulara hacia los motores es de 1 A, luego, un contacto que soporte al menos el
triple de este valor es adecuado tomando en cuenta el sobrepico inicial de corriente
durante el encendido; cuando se trabaja con circuitos inversores de puente H es
recomendable agregar diodos en inverso puestos en paralelo a los interruptores,
con el fin de conducir la corriente acumulada en el bobinado de los motores cuando
se conmuta el sentido de giro, en este caso se omiten dichos diodos puesto que no
se contemplan variaciones bruscas en la dirección de giro en el funcionamiento del
sistema.
Dado a que en las pruebas de apertura y cierre que se le aplicaron a la compuerta

se evidencio que las mismas no se desplazan a la misma velocidad, luego, una
de las compuertas llega al final de su recorrido antes que la otra y por lo tanto
queda detenida fı́sicamente durante el tiempo que le toma a su par completar su
recorrido, tiempo durante el cual el motor sigue alimentado y realizando fuerza
aun cuando no es posible seguir girando en un estado que es poco favorable para
la vida útil del mismo, situación que se repite con el otro motor una vez complete
su recorrido hasta que se interrumpa el flujo de corriente hacia él.
(a) Totalmente abierta (b) Totalmente cerrada
(c) Estado de reposo
Figura 2-26: Arreglo con finales de carrera para compuertas
La solución a este problema consiste en agregar finales de carrera en cada una de

las posibles conexiones a la tierra de los motores como se muestra en la Figura
2-26, cada una de las conexiones emplea el terminal normalmente cerrado, una
vez la compuerta llega al final de su recorrido presiona el final de carrera lo cual
abre el circuito de alimentación de los motores, lo cual inhabilita el movimiento
en el sentido al que corresponda ese camino, esto se muestra en las ilustraciones
2.26(a) y 2.26(b); en los finales de carrera, el contacto normalmente abierto se
conecta a tierra cuando el interruptor es pulsado, esto resulta de utilidad para
notificar al controlador que se emplea para gestionar el movimiento que este la
compuerta a alcanzado la posición deseada.
Figura 2-27: Esquema de accionamiento compuerta

S1 S2 P1 P2 Abrir Cerrar
0 0 0 0 0 0
0 0 0 Z 0 1
0 0 Z 0 1 0
0 0 Z Z 0 0
0 Z 0 0 0 1
0 Z 0 Z 0 1
0 Z Z 0 0 0
0 Z Z Z 0 0
Z 0 0 0 1 0
Z 0 0 Z 0 0
Z 0 Z 0 1 0
Z 0 Z Z 0 0
Z Z 0 0 0 0
Z Z 0 Z 0 0
Z Z Z 0 0 0
Z Z Z Z 0 0
Tabla 2-1: Tabla de verdad apertura de compuertas
El diagrama de control propuesto es el que se muestra en la Figura 2-27, para

cada uno de los dos movimientos se prevé un accionamiento directo a través de
los pulsadores S1 y S2, y de una activación proveniente de un microcontrolador
empleando dos pines P1 y P2, esta implementación doble esta justificada por la
necesidad de poder activar las compuertas en caso de realizarse una observación
local, o en el caso de falla por parte del sistema digital no experimentar un bloqueo
del movimiento, también, dado que se pueden interpretar los pines y los pulsadores
como interruptores de conexión a tierra, no se puede hablar de un estado digital
alto para ninguno de los dos, puesto que se incurre en el riesgo de corto circuito,
los dos estados contemplados son 0 y alta impedancia analógica Z, el funciona-
miento de todos los elementos mencionados anteriormente se ve relacionado en la
tabla de verdad 2.3.
Para el accionamiento remoto de las compuertas se hace uso de un microcontrola-

dor ATMEGA328p, el cual además de accionar los reles debe revisar el estado de
los finales de carrera con el fin de determinar cual de los 4 posibles estados es el
que posee la compuerta en un determinado momento, siendo estos, abierta, cerra-
Figura 2-28: Circuito de gestión para compuerta
da, en estado intermedio o error de funcionamiento, adicionalmente, puesto que la

compuerta debe verse como un componente de un sistema de automatización más
grande integrado por el observatorio en su conjunto, es necesario dotar al control
de compuertas de un recurso de comunicación inalámbrico que le permita enla-
zarse con el sistema de control principal, para esto se opta por emplear un radio
Bluetooth HC-05, con el fin de generar un puente serial inalámbrico transparente
en el sentido de emplear únicamente dos lineas de datos, Rx y Tx, el esquemático
del circuito final implementado se muestra en la Figura 2-28, puesto que la linea
de alimentación disponible es de 12 V, se emplean reguladores monolı́ticos para
obtener los niveles de voltaje adecuados para el microcontrolador y para el radio
Bluetooth.
La energı́a requerida por los elementos que constituyen el control para los com-
puertas es suministrada por una baterı́a de 12 Voltios 7 Ah, debido a que la
rotación de la cúpula, y con ella la compuerta impiden el realizar la alimentación
del circuito empleando una conexión hacia la red domestica; es bien sabido que
el arranque de los sistemas electromecánicos genera un efecto de desestabilización
transitorio sobre la fuente de alimentación a la que estén conectados, dicha per-
turbación se manifiesta en variaciones abruptas del nivel de voltaje de la fuente
y es mayor en forma proporcional con respecto al par mecánico asociado a ellos,
esto ocasiono que durante el tiempo de desarrollo del sistema se presentaran reini-
cios del microcontrolador en cuanto este accionaba los relevadores para poner en
marcha los motores, no constituyendo un problema para el accionamiento manual,
pero si para el envı́o de instrucciones en forma inalámbrica, puesto que nunca se
completaba la orden recibida.
El método mas adecuado para solucionar este problema consiste en llevar a cabo
Figura 2-29: Detalle iluminación cúpula
un arranque suave de los motores, esto es, aumentar de manera progresiva la

corriente eficaz suministrada a estos hasta llegar al valor máximo en régimen
permanente, empleando para ello una modulación de ancho de pulsos en la cual
se parta de un ciclo útil bajo hasta llegar al 100 % de este, infortunadamente, los
tiempos contemplados no permiten la implementación de dicha propuesta, ası́ que
se opta en cambio por agregar condensadores de filtro entre las terminales de los
motores y en las terminales de alimentación del microcontrolador, lo cual basta
para amortiguar las variaciones mas drásticas y garantiza el buen funcionamiento
del sistema.
2.4. Iluminación
Como tarea de cierre para este capı́tulo, se muestra el mecanismo de iluminación
empleado para la cúpula en la Figura 2-29, el cual consiste en un arreglo de leds
rojos, verdes y azules, el cual permite obtener 7 colores diferentes, el accionamien-
to de cada uno se lleva a cabo empleando relevadores de baja potencia, si bien
el esquemático muestra un solo led, debe entenderse que cada una de las ramas
hace referencia a un conjunto de ellos, es también la razón del porque emplear
una fuente de 12 V para la alimentación.
Como sugerencia de mejora a futuro, se plantea el reemplazar los relevadores elec-

tromagnéticos por relevadores de estado solido o directamente por transistores,
los cuales admiten velocidades de conmutación elevadas como las que podrı́a ge-
nerar una señal de PWM, esto permitirı́a en teorı́a, el poder generar colores en
una combinación de 255x255x255.
Capı́tulo 3
Desarrollo de software de
administración local
En este capitulo se aborda el problema de la gestión local del observatorio em-

pleando un sistema informático, ası́ pues, en primera instancia se exponen los
requerimientos que deben ser satisfechos, para posteriormente realizar la elección
del sistema embebido y el lenguaje de programación sobre el cual se ha de llevar a
cabo el desarrollo propuesto, finamente, se genera la documentación del software
desarrollado.
3.1. Consideraciones sobre el desarrollo
3.1.1. Elección de lenguaje y placa de procesamiento

El esquema de automatización que se plantea en este trabajo obedece a una estruc-
tura modular, donde cada uno de los componentes haga referencia a un elemento
especifico del observatorio, a la vez que, deben estar relacionados entre si haciendo
uso de una interfaz conectora que permita la interacción entre los mismos, esto
obliga a pensar en el software de gestión como un reflejo de dicha caracterı́stica
modular, luego resulta obvia la necesidad de emplear un lenguaje de programación
orientado a objetos, en el cual se permita definir cada componente del observato-
rio como un nuevo tipo de dato, con atributos y métodos propios asociados a la
funcionalidad esperada para cada uno.
El lenguaje de programación escogido para el desarrollo es Python, un lengua-

je multiparadigma, de código identado y fácilmente legible, de gran versatilidad
ofrece en cuanto la programación de aplicaciones sin necesidad de depender de un
IDE especifico o un Framework determinado como pueden ser Microsoft Visual
38 3 Desarrollo de software de administración local
C++ de Microsoft corp para los lenguajes de la familia C, o la maquina virtual de

Java para el lenguaje homónimo, ya que en la mayorı́a de los sistemas operativos
basados en el núcleo GNU/linux, Python se encuentra integrado en forma prede-
terminada con el sistema, también es importante mencionar que se trata de un
lenguaje libre y abierto a desarrollos en comunidad, lo cual posibilita el desarrollo
sin depender de una licencia corporativa.
Ahora bien, para la selección del elemento principal de procesamiento sobre el cual
se desea correr el software desarrollado se deben tener en cuenta las siguientes
consideraciones:
Gestionar conexiones a través de internet, ya sea empleando conexión ca-

bleada fı́sica o mediante un enlace WLAN.
Ejecutar aplicaciones escritas en Python, tanto en las versiones 2.7.x como

en la mas recientes versiones 3.x.x.
Poder realizar la conexión de dispositivos periféricos, tales como cámaras o

elementos de memoria con el fin de realizar la captura y almacenamiento de
datos.
Conexión a dispositivos electrónicos actuadores con el fin de llevar a cabo

la activación motores.
Disponer de buses de comunicación serial I2C con el fin de realizar la lectura

de dispositivos de sensado.
Capacidad de comunicación a través de Bluetooth 2.0.
Con el fin de satisfacer los requerimientos planteados, se opta por hacer empleo de
la tarjeta Raspberry pi 3 model B, el cual en esencia es un microcomputador ca-
paz de ejecutar sistemas operativos de tiempo real cargados en una tarjeta SD, las
principales caracterı́sticas de este sistema se resumen en la tabla 3.1.1, dentro de
la oferta de sistemas operativos disponibles para esta placa se destacan Windows
10 IOT core, Risc OS y otras muchas distribuciones basadas en GNU/Linux, de
las cuales, la distribución basada en Debian, Raspbian Stretch Lite se considera
la adecuada para el presente trabajo, ya que al carecer de escritorio, evita el des-
perdicio de recursos en el procesamiento de interfaces gráficas de usuario.
3.1 Consideraciones sobre el desarrollo 39
Frecuencia de reloj 1,2 GHz

GPU Video Core 400 MHz
Memoria 1 GB LPDDR2 SDRAM
2.4GHz
Inalámbrica IEEE 802.11.b/g/n
Bluetooth 4.1
Red Fast Ethernet 10/100 Gbps
GPIO 40 pines
HDMI
4 x USB 2.0
CSI (cámara Raspberry Pi)
Puertos
DSI (pantalla tácil)
Toma auriculares / vı́deo compuesto
Micro SD
Micro USB (alimentación)
Tabla 3-1: Resumen especificaciones Raspberry Pi 3 model B[4]
Al respecto de las placas Raspberry Pi cabe destacar el hecho de haber sido pen-
sadas para el desarrollo de aplicaciones de IOT, por lo cual, si bien se trata de
computadores en todo el sentido de la palabra, cuentan con un GPIO con pines
disponibles para la gestión de dispositivos electrónicos convencionales, en forma
similar a como se podrı́an gestionar empleando un microcontrolador convencio-
nal, el esquemático del dispositivo, ası́ como el pinout correspondiente al GPIO
integrado en la placa se muestra en la Figura 3-1.
3.1.2. Conectividad
En las aplicaciones de IoT, resulta importante el contar con un gestor de conexión
de red, el cual debe encargarse de administrar los mensajes entre el servidor en
nube y el cliente local, para el presente desarrollo se ha decidido hacer uso del
protocolo MQTT[16], un protocolo de transporte diseñado para tolerar anchos de
banda limitados e intermitencia en las comunicaciones, esto lo hace ideal para
aplicaciones M2M(Machine to Machine) o IoT(Internet Of Things) en las cuales
se debe controlar el estado de sensores o actuadores sobre algunos procesos deter-
minados, ya que en en los mismos solo se requiere el traslado de datos u ordenes
en forma de texto plano o estructuras JSON.
(a) Hardware de la tarjeta (b) Pinout GPIO
Figura 3-1: Detalles Raspberry Pi 3 Model B[4]
Adicionalmente, se debe disponer de un servidor donde alojar un aplicativo web,

bases de datos y archivos, para esto existen múltiples alternativas, incluso es total-
mente factible implementar un servidor propio en cualquier tipo de computadora,
sobre todo si se tiene en cuenta que se desea implementar una aplicación capaz
de gestionar mensajes de texto y algunas imágenes, el problema radica entonces
en los diferentes procesos de acceso libre a la red en ambientes altamente restric-
tivos en temas de seguridad como puede ser el sistema de información de una
institución educativa, lo cual deja como una opción mas adecuada el contratar
un servicio externo, como bien puede ser el servicio de IoT Core de Amazon Web
Services(AWS), que en pocas palabras ofrece planes de almacenamiento y reserva
de capacidad de procesamiento para código del lado del servidor en precios rela-
tivamente accesibles, los detalles de la jerarquı́a de conexión serán discutidos mas
adelante.
Antes de exponer la arquitectura implementada es necesario entrar en detalle sobre

el paradigma de funcionamiento del protocolo MQTT, la siguiente información
suministrada se basa en un articulo especializado sobre el mismo[1], en términos
simples, el protocolo posee una regla de publicación y suscripción sobre TCP/IP,
en un esquema cliente a servidor, el servidor o la interfaz asociada al mismo suele
recibir el nombre de Broker, en tanto que los objetos de tipo cliente reciben el
3.1 Consideraciones sobre el desarrollo 41
nombre de Publishers o Suscribers según reciban o publiquen datos, es importante

mencionar que un cliente puede ser tanto Publisher como Suscriber, los canales
para compartir información reciben el nombre de Topics, cuando un cliente se
suscribe a un Topic recibe todos los mensajes que los Publishers ingresen en la
mismo, y según el contenido del mensaje determinan si se trata o no de un mensaje
relevante en forma individual, los mensajes publicados en un Topic no pueden
tener un tamaño superior a 250 MB, la imagen 3-2 ilustra el funcionamiento del
protocolo en forma gráfica.
(a) Los clientes establecen una co- (b) El cliente A publica en el To-
nexión TCP con el Broker. Los pic temperatura un valor de 22,5◦ ;
clientes B y C se suscriben al To- el Broker difunde el mensaje a todos
pic temperatura[1]. los clientes que previamente se hayan
suscrito al Topic ✭✭temperatura✮✮.[1]
Figura 3-2: Paradigma de operación protocolo MQTT
El último elemento importante a tener en cuenta es el conocido como Bucket, un

Bucket es un elemento propio de Amazon Web Services y hace referencia a una
locación especifica de almacenamiento en el cual es posible guardar cualquier tipo
de archivo, cada uno cuenta con un ID que debe ser único en el mundo, sin im-
portar que se encuentre almacenado en otra aplicación o subdivisión del servidor,
un Bucket puede gestionarse empleando MQTT para la apertura y cierre de la
comunicación, el envı́o de los archivos se realiza una vez se tiene una comunicación
estable.
3.2. Arquitectura y documentación
3.2.1. Clases contempladas

En orden de mantener una estructura modular, se determino que cada elemen-
to del observatorio constituye un cliente especı́fico de tipo Publisher y de tipo
Suscriber, el tópico general fue nombrado como /astrolab/ud/#, se pueden gene-
rar subdivisiones a dicho tópico según los requisitos para cada componente, los
elementos cliente que se tienen contemplados son los siguientes:
Telescopio: de la referencia Meade LX200 GPS, su mecanismo de comuni-

cación principal es un bus UART a través del cual se pueden obtener datos
de sus estado, posición o tiempo, ası́ como dar ordenes de movimiento.
Cámara Web: la función principal de este elemento consiste en brindar la

posibilidad de obtener una imagen del espacio de observación como tal, a
través de un puerto USB puede conectarse a la placa de procesamiento.
Cámara planetaria: puesto que se espera realizar una observación remota,

se emplea una cámara planetaria ASI120MC, la cual se monta directamente
sobre el telescopio, y obtiene las imágenes directamente de la luz capturada
por los espejos.
Domo astronómico: el domo se refiere a todo lo referente a la planta fı́sica del

espacio de observación, comprendiendo ası́: iluminación, rotación horizontal,
apertura y cierre de compuerta vertical, entre otras funciones.
Instrumentación: este ı́tem, contempla dos señales cuyo objetivo es determi-

nar la viabilidad de observación, esto es, realizar el seguimiento. Existen dos
condiciones que se consideran criticas en el funcionamiento del observatorio,
la condición de lluvia, y de ausencia de energı́a en la red eléctrica.
Adicionalmente a estos, es necesario disponer de dos elementos de control adicio-

nal, uno de ellos es el Broker para gestionar la conexión con AWS, en tanto que
el restante corresponde a un Bucket el cual se encargara de subir las imágenes
que se tomaran con las cámaras; durante el tiempo de desarrollo se evidencio que
era necesario generar algunas clases adicionales para la gestión completa de los
componentes del observatorio, estas clases cumplen el rol de subsidiarias y tienen
3.2 Arquitectura y documentación 43
como propósito encargarse de un elemento especı́fico, como bien puede ser un sen-
sor, la Figura 3-3 muestra la totalidad de las clases que constituyen el software,
ası́ como la relación jerárquica existente entre ellas.
Figura 3-3: Diagrama de clases
En la programación orientada a objetos, uno de los principales preceptos consis-

te en manejar el concepto de encapsulamiento, esto es, restringir el acceso de la
mayorı́a de atributos de un objeto a otros objetos o instancias de una aplicación,
con el fin de garantizar la seguridad y evitar la escritura de código fuertemente
acoplado, puesto que la edición o eliminación de clases constituye verdaderas pe-
sadillas cuando no se respetan estos preceptos, ahora bien, si se observa la Figura
3-3 se puede observar que se trata de un código débilmente acoplado, puesto que
puede deducirse fácilmente el orden jerárquico, en un flujo que parte de la clase
broker y termina con las clases subsidiarias, y si bien, las relaciones directas en-
tre clases principales deben evitarse, la relación entre las clases dome y telescope
obedece únicamente a una referencia de objeto para la obtención de un parámetro
de ubicación, lo que evita una fuerte cohesión entre las clases.
La implicación mas importante de lo dicho anteriormente, es que cada modulo

puede funcionar independientemente de los demás, y por tanto debe poseer un
mecanismo de verificación individual, este mecanismo se denomino ”live”, y con-
siste en un mensaje JSON generado por el servidor cada 30 segundos, el cual
contiene una solicitud de verificación para cada uno de los componentes del soft-
ware, esta solicitud se procesa y genera un respuesta ası́ncrona por parte de cada
uno de los módulos, si un modulo no genera una respuesta válida al servidor antes
que se genere el siguiente mensaje de verificación, este procede a deshabilitar la
funcionalidad asociada al modulo que genero el error, como puede ser la rotación
de la cúpula o la apertura de compuertas.
Por el lado del servidor, se dispone de un aplicativo web que se encarga de enlazar
con el software de gestión local, sin embargo, por motivos de derechos de autor no
se puede profundizar demasiado en su arquitectura, mas adelante se dará una breve
descripción sobre su funcionalidad, el paso a seguir, es la exposición detallada de
las clases del software local ası́ como su correspondiente documentación.
3.2.2. La clase iot

Paquetes requeridos
import json
import time
from rpi import Rpi
from dome import Dome
from broker import Broker
from buckets3 import Buckets3
from cameraweb import CameraWeb
from cameralpi import Cameralpi
from telescope import Telescope
from instrument import Instrument
Descripción
La clase iot tiene la función de servir de estructuradora para el programa, en la
medida que crea instancias de cada uno de los elementos del programa, con lo cual
se realiza la inicialización de cada uno de ellos, es necesario aclarar que las rutinas
de arranque de cada uno de los elementos de hardware que son administrados por
una clase en particular, son verificados y configurados en el constructor de cada
clase.
Una caracterı́stica que se busco durante el periodo de desarrollo, es el disponer

de instancias únicas para cada una de las clases, esto implica, que no se crea mas
de un objeto por clase, y el único es el creado por la clase iot, ası́, cuando una
clase en particular requiere un método o dato proveniente de otra clase, la clase
iot comparte con esta el objeto creado previamente.
La clase iot sirve como canal de broadcast entre el Broker y cada uno de los
clientes, lo cual implica que se encarga de enviar los mensajes provenientes de
red a todas las clases, también contiene como uno de sus atributos el tópico para
MQTT, al cual suscribe las clases una vez las instancia, su ultima caracterı́stica
es poseer un ciclo loop infinito para asegurar que el hilo principal del programa
continué su ejecución aun en la ausencia de ordenes provenientes, ya sea de una
clase en especı́fico o desde el Broker, la estructura de la clase puede verse en la
Figura 3-4.
Figura 3-4: Diagrama de clase IoT

Atributos
general topic Tópico para la publicación y suscripción de mensajes
MQTT.
port camera lpi Referencia para conexión de hardware de cámara planetaria.
buc- Nombre de Bucket para almacenamiento de imagen cámara
ket name lpi planetaria.
bucket url lpi Dirección del Bucket para almacenamiento de imagen cáma-
ra planetaria.
Puerto USB para conexión de hardware de cámara web.
port camera web
buc- Nombre de Bucket para almacenamiento de imagen cámara
ket name web web.
bucket url web Dirección del Bucket para almacenamiento de imagen cáma-
ra web.
port telescope Dispositivo USB asignado para el conversor usb-serial em-
pleado para comunicación con telescopio.
baudrate teles- Velocidad de transferencia UART para telescopio.
cope
pin rotate cw Número de pin fı́sico de GPIO para pulsador rotación hora-
ria de cúpula.
pin rotate ccw Número de pin fı́sico de GPIO para pulsador rotación anti-
horaria de cúpula.
pin led1 Número de pin fı́sico de GPIO para encender color rojo de
iluminación ambiental.
pin led2 Número de pin fı́sico de GPIO para encender color verde de
pin led3 Número de pin fı́sico de GPIO para encender color azul de
pin cw Número de pin fı́sico de GPIO para activar rotación horaria
de cúpula.
pin ccw Número de pin fı́sico de GPIO para activar rotación antiho-
raria de cúpula.
pin turn light Número de pin fı́sico de GPIO para modificar el color de
iluminación ambiental de cúpula.
pin home Número de pin fı́sico de GPIO para llevar la planta mecánica
a posición inicial.
pin emergency Número de pin fı́sico de GPIO asociado al sensor que moni-
torea la condición de parada de emergencia del sistema.
pin rain sensor Número de pin fı́sico de GPIO asociado al sensor de lluvia
para condición de observación.
Número de pin fı́sico de GPIO asociado al sensor de sumi-
pin energy sensor nistro de red eléctrica.
rpi Objeto de tipo Rpi para obtener datos de estado de la placa
Raspberry pi 3.
camera lpi Objeto de tipo Cameralpi para toma de imágenes con cáma-
ra planetaria.
camera web Objeto de tipo Cameraweb para toma de imágenes con
cámara web conectada por USB.
iot connection Objeto de tipo Broker para el manejo de mensajes MQTT.
bucket Objeto de tipo Buckets3 para el manejo de espacios de al-
macenamiento en nube.
telescope Objeto de tipo Telescope, para la gestión del telescopio Mea-
de LX200 GPS a través de comunicación serial.
dome Objeto de tipo Dome para la gestión de la infraestructura
fı́sica de la cúpula.
instrument Objeto de tipo Instrument para los sensores encargados de
determinar las condiciones de observación.
Métodos de clase
def broadcast channel(client,
userdata,
message)
Receptor de mensaje MQTT y reenvió de los mismos a todos los objetos de
clase instanciados en la clase iot suscritos al tópico ’astrolab/ud/#’, cada
objeto cuenta con un método de manejo de mensajes que lee el mensaje
recibido y según su contenido determina si debe ejecutar funciones propias
o no.
Tipo de retorno:
Ninguno.
def loop()
Ciclo infinito de ejecución principal
Tipo de retorno:
Ninguno.
3.2.3. La clase Dome
Paquetes requeridos
import RPI.GPIO as GPIO
import json
import time
import Bluetooth
import os
import subprocess
import threading
from ST VL6180X import VL6180X
import sys
Figura 3-5: Diagrama de clase Dome
Descripción
La clase Dome es con diferencia, la clase mas robusta en código comparada con
las demás estructuras que conforman el software desarrollado, de forma general
puede decirse que se encarga de la gestión de la mayor parte de los elementos de
hardware que constituyen la infraestructura fı́sica de la cúpula, esto se logra me-
diante la gestión del GPIO que posee la Raspberry Pi 3, luego no es de extrañar
que muchos de los métodos propios de la clase ejecuten acciones directas sobre
estos, la estructura de la clase puede verse en la Figura 3-5.
Es importante mencionar también, que dentro de la clase Dome se hace un uso

importante de Multithreading, es decir, la ejecución paralela de hilos de código
secundarios coincidentes en el tiempo, el objetivo de estas ramas de ejecución

secundarias es controlar procesos que son considerados crı́ticos para el sistema,
tales como la verificación del sistema de enlace para la compuerta principal, la
implementación del sistema de encoder incremental para el posicionamiento de
la cúpula, el mecanismo de señalización luminosa que informa sobre el estado
actual del observatorio y las interrupciones derivadas de eventos sobre el GPIO
del Raspberry, los cuales se asocian a la pulsación de interruptores que tienen
una acción mecánica asociada; el diagrama de ejecución para la clase Dome es el
siguiente:
Start instance x—————————————————–> Principal Thread

|
——————————> Tracing Thread
|
——————————> Bluetooth Live Thread
|
——————————> Alarm Color Thread
|
——————————> Change Dome Callback
Cada uno de los hilos secundarios pueden ser iniciados tanto desde el proceso de
ejecución principal, como desde otro hilo secundario, sin embargo, no es posible
realizar un llamada a hilo antes que haya concluido un inicio anterior; solo el hilo
de Change State Dome Callback es persistente a lo largo del ciclo de vida del
hilo principal, los demás por su parte se inician y terminan cuantas veces sean
llamados durante el flujo de ejecución, también es importante mencionar que se
trata de procesos que solo terminan cuando finalice su secuencia de ejecución, esto
implica que la terminación del hilo principal no implica el fin de ellos.
La palabra reservada self se usa en Python para indicar que un atributo o método
son propios de un objeto, esto es, por cada nueva instancia u objeto que se cree
de la clase se están generando atributos y métodos reservados para la misma con
valores únicos para cada instancia.
Atributos
client Instancia de la clase Broker para manejo de mensajes
MQTT.
telescope Instancia de la clase Telescope para la obtención de coorde-

nadas de apuntamiento del telescopio Meade LX200 GPS.
pin rotate cw Número de pin fı́sico de GPIO para pulsador rotación hora-
ria de cúpula.
pin rotate ccw Número de pin fı́sico de GPIO para pulsador rotación anti-
horaria de cúpula.
pin led1 Número de pin fı́sico de GPIO para encender color rojo de
pin led2 Número de pin fı́sico de GPIO para encender color verde de
pin led3 Número de pin fı́sico de GPIO para encender color azul de
pin cw Número de pin fı́sico de GPIO para activar rotación horaria
de cúpula.
pin ccw Número de pin fı́sico de GPIO para activar rotación antiho-
raria de cúpula.
pin turn light Número de pin fı́sico de GPIO para modificar el color de
iluminación ambiental de cúpula.
pin home Número de pin fı́sico de GPIO para llevar la planta mecánica
a posición inicial.
pin emergency Número de pin fı́sico de GPIO asociado al sensor que moni-
torea la condición de parada de emergencia del sistema.
pin rain Número de pin fı́sico de GPIO asociado al sensor de lluvia
para condición de observación.
pin energy Número de pin fı́sico de GPIO asociado al sensor de sumi-
nistro de red eléctrica.
address Dirección MAC de módulo Bluetooth HC05 encargado de
control de compuerta vertical.
port Número de bus UART para radio Bluetooth de Raspberry
Pi.
tof address Dirección hexadecimal de sensor tof de distancia conectado
por bus I2c.
tof sensor Instancia de clase para sensor tof VL6180X.
gate state Atributo para estado de compuerta vertical (open, close,
mid, error).
t Variable auxiliar para gestión de hilos.
led color Número de color actual.

con energy flag Bandera de estado de red eléctrica.
con rain flag Bandera de estado condición de lluvia.
sock Socket para establecer conexión Bluetooth entre Raspberry
y modulo HC05.
home flag Bandera de activación para rutina de inicialización encoder.
tracing flag Bandera habilitadora para seguimiento automático del te-
lescopio por parte de la cúpula.
n1 Signo de desplazamiento encoder muestreo previo.
n Signo de desplazamiento encoder muestreo actual.
xk Valor de distancia actual sensor tof x[k].
xk1 Valor de distancia sensor tof para x[k − 1].
Pos actual Posición angular de cúpula.
Métodos de clase
def init (self, client, pin rotate cw, pin rotate ccw,
pin home, pin turn light, pin emergency,
pin led1, pin led2, pin led3, pin motor cw,
pin motor ccw, pin energy, pin rain, telescope)
Constructor de clase, inicializa todos los atributos de objeto y realiza las
tareas de configuración para el GPIO cuando un objeto de la clase Dome es
creado.
Retorno:
Ninguno.
def tracing thread(self)

Secuencia de ejecución para el hilo Tracing Thread, obtiene la coordenada
de azimuth del telescopio y desplaza la cúpula hasta dicho valor angular
cada 30 segundos, finaliza su vida cuando la bandera tracing flag es puesta
en 0.
Retorno:
Ninguno.
def bluetooth live thread(self,msj,msj2)

Código de hilo para ejecutar ”live”sobre la compuerta vertical, inicia cuando
se recibe un mensaje proveniente del Broker y finaliza una vez se realiza una
solicitud de conexión sobre el estado de la compuerta.
Retorno:
Ninguno.
def alarm color thread(self, msj, color)

Hilo para señales lumı́nicas en función del proceso en ejecución, ası́ por
ejemplo, la rotación de la cúpula en cualquier sentido, la ejecución de la ru-
tina de Home, o la detección de alguna señal de estado critico desencadenan
un parpadeo con un color único para cada caso.
Retorno:
Ninguno
def message manager(self, message)

Método que recibe los mensajes provenientes del Broker y determina el
método de clase que debe ejecutarse de acuerdo al contenido del mensaje
recibido.
Retorno:
Ninguno
def open door(self)

Método para apertura de compuerta vertical desde aplicativo web.
Retorno:
Ninguno
def close door(self)

Método para cierre de compuerta vertical desde aplicativo web.
Retorno:
Ninguno
def rotate cw(self)

Girar la cúpula en sentido horario durante 1 segundo, este método solo se
llama como producto de orden desde aplicativo web.
Retorno:
Ninguno
def rotate ccw(self)

Girar la cúpula en sentido antihorario durante 1 segundo, este método solo
se llama como producto de orden desde aplicativo web.
Retorno:
Ninguno
def on light(self)
Encender iluminación de cúpula en color blanco, este método solo se llama
como producto de orden desde aplicativo web.
Retorno:
Ninguno
def off light(self)

Apagar iluminación de cúpula, este método solo se llama como producto de
orden desde aplicativo web.
Retorno:
Ninguno
def publish status dome(self, **kwargs)

Esta función sirve como publisher de la clase hacia el Broker, tiene como
objetivo el informar del estado del domo, para que se tenga una condición
verde en el estado, la compuerta vertical debe responder su estado y las
señales de alarma no deben estar accionadas.
Retorno:
Ninguno
def change dome callback(self, channel)

Hilo de ı̈nterrupciones”por GPIO de la Raspberry Pi 3, tiene como objetivo
atender al cambio en el estado de los pines que se definen como entradas
digitales para pulsadores o sensores, de acuerdo al pin en el que se ha pre-
sentado un cambio en el estado, se ejecuta el método o se inicia el hilo
correspondiente.
Debido a que se dispone de un único vector de interrupciones, cada uno
de los pines debe suscribirse al mismo hilo, luego en la lógica de este debe
realizarse una evaluación secuencial para determinar cual pin ha hecho la
activación del hilo; no se capturan eventos adicionales antes de que haya
concluido el último llamado de interrupción.
Retorno:
Ninguno
def alarm led color(self, color, state)

Método que contiene los estados correspondientes de GPIO para cada uno
de los colores de iluminación ambiental, el parámetro state funciona como
bandera de encendido o apagado para el color especificado en el llamado al
método.
Retorno:
Ninguno
def connect bluetooth(self)

Crea el socket de comunicación Bluetooth y reliza el enlace con el modulo
HC05 empleando la dirección MAC y el puerto especificados en los atributos
de clase address y port.
Retorno:
Boolean: True si conexión exitosa, False si conexión fallida.
def get status bluetooth(self)

Solicitud de estado a controlador de compuerta vertical a través de Blue-
tooth, los caracteres de respuesta esperados son ’C’: cerrada, ’O’: abierta,
’M’: en estado medio, ’E’: error.
Retorno:
Char: caracter de respuesta de estado si conexión exitosa, ’X’ si co-
nexión fallida.
def get status bluetooth(self)

Solicitud de estado a controlador de compuerta vertical a través de Blue-
tooth, los caracteres de respuesta esperados son ’C’: cerrada, ’O’: abierta,
’M’: en estado medio, ’E’: error, la solicitud se realiza mediante la transmi-
sión del carácter ’r’.
Retorno:
Char: caracter de respuesta de estado si conexión exitosa, ’X’ si co-
nexión fallida.
def open gate(self)

Método de apertura de compuerta vertical, se emplea para las condiciones de
emergencia, luego es recurrente en el sentido de enviar ordenes de apertura
permanentes si no se obtiene como estado de compuerta el carácter ’O’,
con el fin de evitar el detener el programa indefinidamente, el numero de
ordenes de apertura se encuentra limitado a 10.
Retorno:
int: i, contador de intentos, si menor a 10 apertura exitosa, si no,
condición de fallo de compuerta.
def open gate comm(self)

Apertura de conexión Bluetooth y envió de orden de cierre a modulo HC05
en la forma de un carácter ’o’, este método no presenta recurrencia.
Retorno:
Ninguno.
def close gate(self)

Método de cierre de compuerta vertical, se emplea para las condiciones de
emergencia, luego es recurrente en el sentido de enviar ordenes de cierre
permanentes si no se obtiene como estado de compuerta el carácter ’C’,
con el fin de evitar el detener el programa indefinidamente, el número de
ordenes de cierre se encuentra limitado a 10.
Retorno:
int: i, contador de intentos, si menor a 10 cierre exitoso, si no, con-
dición de fallo de compuerta.
def close gate comm(self)

Apertura de conexión Bluetooth y envió de orden de cierre a modulo HC05
en la forma de un caracter ’c’, este método no presenta recurrencia.
Retorno:
Ninguno.
def is alive bluetooth(self)

Verifica si el módulo Bluetooth de enlace entre la Raspberry y el controlador
de compuerta vertical se encuentra ”vivo”.
Retorno:
Boolean: True si conexión exitosa, False si conexión fallida.
def clear buffer(self)

Realizar la lectura del buffer de recepción del puerto RFCOMM de comuni-
cación Bluetooth, esto con el fin de descartar los mensajes recibidos durante
resets del controlador de compuerta vertical o reinicializar comunicación.
Retorno:
Ninguno.
def go home dome(self)

Este método lleva a cabo la inicialización de la funcionalidad de encoder
incremental para el posicionamiento angular de la cúpula, en la sección de
ubicación del capitulo 1 se expone como se posee un objetivo ubicado a
una distancia diferenciada de los demás objetivos para servir de posición de
inicio, una vez alcanzado este punto, se arranca el hilo de Tracing Thread
para el seguimiento automático del telescopio, y define la posición actual
del domo como 0 grados.
Retorno:
Ninguno.
def go position dome(self, pos desired)

La función de esta sección de código es critica en la medida que implementa
el algoritmo de lectura de objetivos y lleva el conteo de posición angular con
dicha lectura, a grandes trazos, recibe como argumento la posición deseada,
la compara con la posición actual, para determinar tanto la cantidad de
objetivos que ha de moverse y el sentido del giro, también toma en cuenta
el sentido de giro del último desplazamiento con el fin de realizar un ajuste
en el número de objetivos que debe desplazarse, al terminar el procedimiento
de ubicación, actualiza el signo de desplazamiento y el atributo de posición
actual.
Retorno:
Ninguno.
3.2.4. La clase Telescope
Paquetes requeridos
import json
import time
import serial
import subprocess
import numpy as np
from datetime import datetime
Descripción
La clase Telescope, cuyo diagrama se muestra en la Figura 3-6, es la encargada de
gestionar el movimiento del telescopio Meade LX200 GPS, asi como de obtener
datos como la hora y fecha internas, o las coordenadas espaciales de apuntamiento,
para ello se vale de una conexión UART a 9600 baudios, debido al empleo del bus
serial in-circuit de la placa Raspberry Pi 3 en otra tarea, se hizo necesario emplear
un dispositivo conversor usb-serial.
Figura 3-6: Diagrama de clase Telescope
Atributos
client Instancia de la clase Broker para manejo de mensajes
MQTT.
port Etiqueta que asigna el concentrador HUB de la placa Rasp-

berry pi 3 al conversor usb-serial.
budrate Velocidad en baudios de comunicación serial.
port timeout Tiempo de espera para respuestas por puerto serial.
Métodos de clase
def init (self, client, port d, baudrate d)

Constructor de clase, define los atributos para el telescopio y realiza la
inicialización del mismo cada que un nuevo objeto es creado.
Retorno:
Ninguno

Método que recibe los mensajes provenientes del Broker , para posterior-
mente realizar el llamado al método correspondiente según el contenido del
mensaje.
Retorno:
Ninguno
def move telescope ra plus(self, speed)

Ejecuta un movimiento positivo en la coordenada de ascensión recta sobre
el telescopio a la velocidad indicada durante un segundo.
Retorno:
Ninguno
def move telescope ra minus(self, speed)

Ejecuta un movimiento negativo en la coordenada de ascensión recta sobre
el telescopio a la velocidad indicada durante un segundo.
Retorno:
Ninguno
def move telescope dec plus(self, speed)

Ejecuta un movimiento negativo en la coordenada de declinación sobre el
telescopio a la velocidad indicada durante un segundo.
Retorno:
Ninguno
def move telescope dec minus(self, speed)

Ejecuta un movimiento negativo en la coordenada de declinación sobre el
telescopio a la velocidad indicada durante un segundo.
Retorno:
Ninguno
def stop telescope(self)

Detiene el movimiento del telescopio si este se encuentra en movimiento.
Retorno:
Ninguno
def auto telescope(self, ra, dec)

Apunta el colector del telescopio a las coordenada de ascensión recta y decli-
nación suministradas, y posteriormente, habilita el seguimiento automático
del objeto celeste ubicado en dicha posición.
Retorno:
Ninguno
def messier object telescope(self, messier object)

Este método recibe el código de un objeto Messier y lo envı́a al telescopio, si
la identificación suministrada coincide con una de las entradas almacenadas
en la base de datos interna del telescopio, este se desplaza para apuntar el
objeto celeste deseado, y comienza el seguimiento del mismo.
Retorno:
Ninguno
def get speed command(self, speed)

Recibe como parámetro la velocidad de desplazamiento deseada para el
movimiento del telescopio y la envı́a a este.
Retorno:
Ninguno
def execute command general(self, command)

Verifica el estado del puerto serial asociado al telescopio, y luego envı́a el
comando de propósito general que se especifico como parámetro de entrada,
el formato de los comandos corresponde a ”:(identificador 1)(identificador
2)#”
Retorno:
Ninguno
def execute command movement arrows(self,

command move,
command speed)
Este método se activa cuando se recibe una orden de movimiento del teles-
copio proveniente del aplicativo web, como parámetros recibe la coordenada
y el sentido en el que se desea el movimiento, ası́ como la velocidad del mis-
mo; al igual que en métodos anteriores, la duración total del desplazamiento
es de un segundo.
Retorno:
Ninguno
def execute command movement auto(self, command)

Tiene un propósito similar el método de ejecución de comandos generales,
con la diferencia de ejecutar un ajuste en el formato del comando requerido
para activar el seguimiento automático por parte del telescopio.
Retorno:
Ninguno
def get status telescope(self)

Valida si el telescopio se encuentra conectado y funcionando correctamente.
Retorno:
Ninguno
def publish status telescope(self, status)

Tiene como objetivo publicar el estado del telescopio hacia el Broker como
respuesta el mensaje de ”liverecibido desde este.
Retorno:
Ninguno
def initialize(self)
Rutina de inicialización, obtiene la hora y la fecha del telescopio y la compa-
ra con la hora estándar, si la diferencia entre las dos es mayor a 2 segundos
actualiza la hora del telescopio, esto se hace debido a que la posición rela-
tiva de un cuerpo celeste cambia según la hora y fecha del año; el método
también evalúa si el telescopio ha sido alineado o no, en caso afirmativo,
configura al telescopio con la última alineación exitosa.
Retorno:
Ninguno
def get azimuth scope(self)

Obtiene la coordenada de azimuth hacia la cual apunta el colector del te-
lescopio, este dato se emplea en la clase Dome para trasladar la compuerta
de observación a esta posición.
Retorno:
Ninguno
def serial response auto(self)

Muchos de los comandos enviados al telescopio generan una respuesta au-
tomática, este método se encarga de limpiar el buffer de recepción de dicha
información que resulta irrelevante para el programa.
Retorno:
Ninguno
3.2.5. Las clases ZWO, CameraLpi e indiCliet

Un aspecto importante en este trabajo tiene que ver con la posibilidad de reali-
za capturas de imagen directamente del telescopio, en este sentido, se evaluaron
algunas alternativas de sensores CCD especialmente desarrollados para este tipo
de aplicaciones, puesto que permitan realizar capturas con tiempos de exposición
que pueden variar entre varios cientos de microsegundos y mil segundos, también
permiten ajustar la ganancia sobre la luz capturada en un rango significativo; otro

dato significativo es que este tipo de sensores han sido pensados especialmente pa-
ra toma de imágenes de cuerpos planetarios.
Durante la fase de identificación de componentes se evaluaron distintas alterna-

tivas para la referencia del dispositivo que se emplearı́a en el montaje final, una
de estas fue la cámara planetaria MEADE LPI, infortunadamente, los drivers del
dispositivo solo han sido desarrollados para distribuciones de Microsoft Windows,
lo que hacia inviable su implementación con la distribución GNU/Linux Raspbian
Stretch, forzando ası́ a la búsqueda de otra opción, resultando ası́ en la elección
de la cámara planetaria ZWO ASI120MC-S de ZWO (ver Figura 3-7).
La elección de este dispositivo tampoco soluciona directamente los problemas de

compatibilidad relacionados con controladores para los sistemas GNU/Linux, sin
embargo, la compatibilidad de este dispositivo con el proyecto conocido como
Instrument Neutral Distributed Interface(INDI) ofrece una alternativa a los tra-
dicionales controladores Plug & Play para dispositivos periféricos USB, el cual
tiene como objetivo principal independizar a los clientes de software de los pro-
tocolos de comunicación con los dispositivos fı́sicos, por lo general dispositivos
astronómicos.
De acuerdo a la página de presentación de INDI[11], El concepto principal es que

los dispositivos tienen la habilidad de describirse a si mismos, luego es posible
establecer un comportamiento genérico para cada tipo de dispositivos, según el
cual, cada elemento de hardware posee una o mas propiedades que describen una
función especifica del dispositivo, existen 5 tipos de propiedades en INDI:
Propiedad de texto Text.
Propiedad numérica Number.
Propiedad de Switch para configurar parámetros de captura, tales como el

formato de imagen, la resolución, el tiempo de exposición o la ganancia para
el caso de los sensores CCD.
Propiedad de Luz, para establecer filtros si el dispositivo tiene el hardware

necesario.
Propiedad de Blob, referente a datos binarios.

Figura 3-7: Cámara planetaria ZWO ASI120MC[17].
A la vez que son necesarios tres elementos con el fin de realizar la comunicación
con los elementos de hardware:
INDI library: implementación del protocolo de comunicaciones entre el sis-

tema y el dispositivo.
INDI Driver: programa que se comunica directamente con el dispositivo em-

pleando la librerı́a de INDI, es el responsable de controlar las propiedades del
dispositivo y por ende traducirlos hacia los clientes, es usual que como pri-
mer paso se envié un listado de los parámetros soportados por el dispositivo
hacia el cliente.
INDI Clients: los clientes son los programas de software que desean conec-
tarse a los dispositivos, dentro de esta categorı́a se tienen aplicaciones como
Kstars que ofrecen un entorno gráfico para la gestión de los elementos; tam-
bién clasifican en este campo las librerı́as de desarrollo ofrecidas, para interés
del presente trabajo, se dispone de la librerı́a PyIndi Client, el cual permite
generar desarrollos con Python para el control de dispositivos astronómicos.
INDI Server: el servidor de INDI cumple la función de concentrador o HUB

entre los drivers y los clientes, sirve como router para los datos que se envı́an
en los dos sentidos, se debe recordar que INDI emplea el paradigma de una
red distribuida, esto es, todos los datos pasan por un único punto de enlace
sin importar cuantos enlaces se encuentren en funcionamiento; el servidor
soporta broadcasting, chaining y marshalling de datos, esto ultimo consiste

en la transformación de la representación en memoria de un objeto a datos
disponibles para su transmisión o almacenamiento.
EL siguiente esquema[11] sirve para ilustrar la topologı́a de red para el control de

dispositivos empleando INDI:
INDI Client 1 —–| |—– INDI Driver A — Dev x

INDI Client 2 —–| |—– INDI Driver B — Dev y
INDI Client 3 —–| |—– INDI Driver C — Dev z
| |
... |————– indiserver ————-| ...
| |
| |
INDI Client n —–| |—– INDI Driver N — Dev T
Client INET Server UNIX Driver Hardware

processes sockets process pipes processes devices
Para mas información sobre desarrollo de clientes de software empleando INDIlib

por favor consultar el manual del desarrollador [12].
Ahora bien, una vez se ha puesto en contexto el tipo de implementación que se

empleo para la cámara de captura de imágenes para el telescopio, cobra sentido el
porque se emplean 3 clases para la gestión de la cámara, por un lado, la clase indi-
Client se toma como estructura para los diferentes métodos que manipularan las
propiedades del dispositivo, la clase recibe como argumento un objeto BaseClient
de tipo PyIndi, con lo que es posible invocar los métodos de Cliente suministra-
dos por la librerı́a en forma directa; por otro lado, la clase Cameralpi tiene como
objetivo enviar al Bucket de almacenamiento en nube la ultima imagen tomada
con la cámara planetaria al recibir una solicitud desde el Broker, los diagramas
para las clases mencionadas se muestran en la Figura 3-8, dado que ya se explico
su funcionamiento, no se agrega documentación adicional sobre ellas.
(a) Clase indiCLient. (b) Clase Cameralpi
Figura 3-8: Diagrama de clases subsidiarias para operación de cámara planetaria.
La documentación sobre la clase ZWO:

Paquetes requeridos
from indiClient import indiClient
import time
import PyIndi
import sys
import threading
import pyfits
import cv2
import numpy
import cStringIO
import os
Figura 3-9: Diagrama de clase ZWO
Descripción
La clase ZWO contiene los métodos de gestión escritos especı́ficamente para la
cámara ASI120MC-S empleando la librerı́a de INDI, su correspondiente diagrama
de clase se muestra en la Figura 3-9, la función especifica de esta clase es tomar
una fotografı́a y almacenarla en un directorio del sistema de la Raspberry pi 3
para su posterior envió al Bucket de almacenamiento en nube, esta clase emplea
un hilo de ejecución secundario para correr el servidor de INDI, el cual tiene
como caracterı́stica detener el hilo de proceso que lo haya comenzado hasta que
forzosamente este muera, justificando ası́ el empleo de un hilo reservado solo para
el, el árbol de ejecución:
Start instance x—————————————————–> Principal Thread

|
———————–> Indiserver
El hilo Indiserver no finaliza por su cuenta, luego es necesario terminarlo ejecutan-

do directamente sobre terminal: ’killall -v indiserver’, intentar iniciar el servidor

cuando ya esta corriendo desemboca en un fallo catastrófico del programa que
solo puede ser solucionado reiniciando la Raspberry pi 3 convirtiendo en una ta-
rea critica el matar el proceso del servidor una vez ha finalizado una de las dos
tareas que pueden iniciarlo: una secuencia de captura de imagen o una solicitud
de “live”.
Atributos
ccd name Propiedad de texto con el identificador del dispositivo.
t Variable auxiliar para el hilo del servidor.
indiclient Instancia de la clase indiClient para uso de los métodos
de gestión de propiedades de la cámara.
device ccd Objeto de tipo ccd que gestiona la conexión a la cámara.
i Variable auxiliar.
ccd connect Switch de conexión - desconexión de dispositivo.
ccd ccd1 Blob para obtención de datos de imagen.
ccd video format Text para definir el formato de captura de vı́deo.
ccd compression Text para definir el tipo de compresión de datos.
Text para definir el tipo de encoder para transmisión en
ccd stream encoder vivo de datos de vı́deo desde cámara.
ccd active devices Text que almacena los dispositivos conectados al servidor
de INDI.
ccd exposure Number para controlar el tiempo de exposición de la
cámara.
ccd controls Number para controlar la ganancia que se aplica durante
la captura de imagen.
Métodos de clase
def init (self, ccd name)
Constructor de clase, crea un objeto de tipo ZWO para la gestión de la
cámara.
Retorno:
Ninguno
def server(self)
Código de hilo para el servidor de INDI, inicia cada que se requiere to-
mar una nueva imagen o durante una secuencia de ”live”, debe finalizarse
forzosamente.
Retorno:
Ninguno
def start connection(self)

Arranca el hilo del servidor de INDI , verifica si la cámara se encuentra
conectada por USB a la Raspberry pi 3, en caso afirmativo modifica el
Switch de conexión y habilita la toma de datos, en caso negativo, termina
el hilo del servidor.
Retorno:
Boolean: True si conexion exitosa, False si no.
def start blob(self)

Crea la referencia a la propiedad Blob de la cámara, con el fin de emplear
la caracterı́stica de marshaling del servidor para la obtención y almacena-
miento de los datos de imagen.
Retorno:
Ninguno
def set format RGB24(self)

Función que fija el Switch de escala de colores de la cámara a RGB de 24
bits, solo se emplea una vez durante la configuración inicial del dispositivo.
Retorno:
Ninguno
def set compression(self)

Este fragmento de código altera el Switch de compresión de la cámara para
que no emplee ningún algoritmo de compresión, esto con el fin de no lidiar
con patrones Bayer de imagen, y disponer únicamente de los datos en bruto,
este método solo se emplea una vez durante la configuración inicial del
dispositivo.
Retorno:
Ninguno
def set encoder(self)

Método de depuración para fijar un encoder de vı́deo, puesto que al final
solo se capturan imágenes individuales, resulta innecesario.
Retorno:
Ninguno
def verify active devices(self)

Obtiene una lista de los dispositivos conectados al servidor de INDI.
Retorno:
String: Lista de dispositivos.
def ToPNG(self, path):

Método que realiza la lectura de un archivo .FITS, extrae sus 3 matrices
de color en forma de RGB y con estas construye una imagen .PNG que
almacena en una ruta especificada por el usuario.
Retorno:
Ninguno
def take photo(self, exp time, gain, path)

Función que emplea los demás métodos de clase y toma una fotografı́a,
recibe como parámetros el tiempo de exposición y la ganancia deseadas para
la captura de la imagen, ası́ como el path donde se desea el almacenamiento
de la imagen, el procedimiento de captura inicia con la conexión hacia la
cámara, posteriormente referencia el Blob de la cámara y fija la ganancia,
al fijar el tiempo de exposición, comienza la captura de la fotografı́a.
Cuando los datos de la fotografı́a están listos se genera un evento del Blob,
entonces se comienza la lectura de todos los datos del Blob hacia un vector
unidimensional local puesto que en la configuración del dispositivo se le
ha indicado que no emplee ningún algoritmo de compresión, Este arreglo
RAW se emplea para generar un archivo .FITS, el cual se guarda en el path
especificado como parámetro del método.
El paso a seguir consiste en emplear la librerı́a PyFits para realizar la lectura
del archivo .FITS a una estructura de datos de la que es posible extraer las
componentes de color de la imagen en la forma de 3 matrices, una con
la componente del rojo, otra con la componente del verde y otra con la
componente del azul, al disponer de estas matrices se emplea openCV para
realizar la construcción de una imagen .PNG en el path indicado, con esto
finaliza el procedimiento de captura de imagen.
Retorno:
Ninguno
def is alive(self)
Realiza un llamado al metodo start connection() y emplea el retorno del
mismo para determinar si la cámara se encuentra conectada y disponible,
funciona como una verificación extra para garantizar que el servidor de INDI
sea detenido.
Retorno:
Boolean: True si cámara conectada y disponible, False si falla detec-
tada.
3.2.6. La clase Cameraweb
Paquetes requeridos
import json
import time
import boto3
import subprocess
Figura 3-10: Diagrama de clase Cameraweb.
Descripción
La clase Cameraweb se ocupa de gestionar la captura de imágenes empleando una
cámara web estándar conectada vı́a USB a la Raspberry Pi 3 y posteriormente
subir la última imagen tomada al Bucket de AWS reservado para esta categorı́a de
imágenes, el interés en disponer de una cámara web en el interior del domo surge
en el deseo de observar fı́sicamente al telescopio y la iluminación del espacio, en
la Figura 3-10 se muestra su estructura.
Atributos
client Instancia del Broker para la conexión con AWS.
bucket Instancia de la clase Bucket para el almacenamiento de datos
en nube.
port Path asignado por Raspbian Stretch cuando la cámara se
conecta por USB, por lo general es /dev/video0.
bucket name Nombre del bucket de almacenamiento asignado para las
imágenes de la cámara web.
bucket url Dirección del bucket.
Métodos de clase
def init (self, client, bucket, port, bucket name, bucket url)
Constructor de clase, recibe como parámetros la dirección web del Bucket de
almacenamiento, el nombre de este, una referencia al Broker para el manejo
de los mensajes del servidor y el path de puerto de hardware que le asigna
la Raspberry Pi 3 a la cámara, dado que se trata de un dispositivo de vı́deo
el puerto asignado siempre es el mismo, con lo que no resulta necesario una
rutina de Discovery para encontrar el identificador de puerto indicado; este
puerto tiene la dirección de sistema /dev/video0.
Retorno:
Ninguno

Método que se encarga de interpretar los mensajes recibidos desde el Broker,
si el mensaje esta dirigido a la clase, puede generar dos comportamientos:
toma y subida de imagen o verificación de funcionamiento de la cámara.
Retorno:
Ninguno
def take photo(self)

Verifica el estado del puerto asociado a la cámara web, y posteriormente eje-
cuta la secuencia de captura de imagen enviando a la cámara los parámetros
de captura: resolución, puerto de conexión, path de almacenamiento y esca-
la de color; posteriormente se conecta al Bucket de almacenamiento y sube
la imagen capturada.
Retorno:
Ninguno
def publish status cameraweb(self, status, url=None)

Método de ejecución para secuencia de ”live”, verifica si la cámara web se
encuentra conectada a la placa y si esta disponible, luego realiza el envió
del status de la misma hacia el Broker.
Retorno:
Ninguno
def get first image bucket(self)

Esta rutina sube la ultima imagen tomada por la cámara web al servidor,
se trata de un procedimiento que solo se ejecuta durante la creación de una
instancia de la clase Cameraweb.
Retorno:
Ninguno
3.2.7. La clase Instrument
Paquetes requeridos
import json
import time
import RPI.GPIO as GPIO
Figura 3-11: Diagrama de clase Instrument.
Descripción
La clase Instrument tiene como única función realizar la lectura de los sensores de
red eléctrica y de lluvia para publicar su estado hacia el Broker cuando ocurre una
secuencia de ”live”, es importante aclarar que esta clase no posee la capacidad de
ejecutar acciones sobre el hardware del observatorio, su correspondiente diagrama
se encuentra en la Figura 3-11.
Atributos
pin rain sensor Número de pin de GPIO usado para la lectura del sensor de
lluvia.
pin ups sensor Número de pin de GPIO usado para la lectura del sensor de
alimentación por red eléctrica.
Métodos de clase
def def init (self, client, pin rain sensor, pin ups sensor)
Metodo constructor de clase, recibe como parámetros la instancia hacia el
Broker y los números de pin asociados a los sensores.
Retorno:
Ninguno

Método que al recibir un mensaje dirigido a un objeto de tipo Instru-
ment publica el estado de los sensores al Broker empleando el método
publish status instruments().
Retorno:
Ninguno
def publish status instruments(self)

Obtiene el estado de los sensores y lo envı́a al Broker.
Retorno:
Ninguno
3.2.8. La clase Rpi
Paquetes requeridos
import json
import time
import psutil
Figura 3-12: Diagrama de clase Rpi.
Descripción
La clase Rpi obtiene la cantidad de memoria RAM ocupada en la Raspberry Pi
3, ası́ como la carga porcentual de CPU, con el fin de controlar si la placa se
encuentra dentro de un rango de funcionamiento normal, con hasta un 70 % de
memoria RAM y una carga de CPU del 60 % como máximo, si los datos obte-
nidos superan estos limites, el programa deshabilita automáticamente todos los
demás componentes de hardware, es posiblemente la clase mas sencilla de todas,
su diagrama de clase se muestra en la Figura 3-12.
Atributos
Métodos de clase
def init (self, client)
Constructor de clase, recibe la instancia del Broker para contar con la ca-
pacidad de recibir y enviar mensajes.
Retorno:
Ninguno

Método que recibe los mensajes provenientes del Broker, y luego realiza el
llamado a la función de publicación de estado.
Retorno:
Ninguno
def publish status rpi(self)

Función que envı́a los datos de CPU y de RAM empleados hacia el Broker.
Retorno:
Ninguno
def get ram(self)

A través de la librerı́a psutil obtiene el porcentaje de memoria empleada.
Retorno:
Int: porcentaje de memoria RAM en uso.
def get cpu(self)

A través de la librerı́a psutil obtiene el porcentaje de CPU empleado.
Retorno:
Int: porcentaje de carga en CPU en uso.
3.2.9. La clase Buckets3
Paquetes requeridos
import boton3
Figura 3-13: Diagrama de clase Buckets3.
Descripción
la clase Buckets3 tiene como razón de ser el administrar los Buckets de almace-
namiento de AWS para las imágenes de la cámara planetaria y la cámara web, en
este punto es necesario aclarar que la clase Broker y la clase Buckets3 emplean
caracterı́sticas diferentes sobre un mismo servidor, por esta razón, los buckets de
almacenamiento son accedidos con un id y una clave segura diferentes a los cer-
tificados del Broker, solo cuenta con un atributo referente a la conexión con el
servidor, su diagrama se muestra en la Figura 3-13.
Atributos
connection Objeto sobre el cual pueden modificarse los contenidos de
los buckets de almacenamiento.
Métodos de clase
def connect to s3(self))
Crea el objeto connection empleando para ello las credenciales de acceso al
servicio de almacenamiento de AWS.
Retorno:
Ninguno
def upload file to s3(self, bucket name, image path, ima-

ge name)
Método que carga una imagen hacia el bucket especificado en sus parámetros
de entrada.
Retorno:
String: llave de respuesta del bucket.
def delete bucket content(self, bucket name)

Elimina todos los archivos almacenados en el bucket especificado.
Retorno:
Ninguno
def get first item bucket(self, bucket name)

Retorna el último elemento en ser cargado al bucket especificado como
parámetro.
Retorno:
File: último archivo cargado en el bucket.
3.2.10. la clase Broker
Paquetes requeridos
from AWSIoTPythonSDK.MQTTLib import AWSIoTMQTTClient

import time
import logging
Figura 3-14: Diagrama de clase Broker.
Descripción
Clase que permite la creación de una instancia de AWSIoTMQTTClient para rea-
lizar la conexión entre el aplicativo y el servidor de Amazon Web Services, puede
interpretarse como la puerta de enlace para el envió y captura de mensajes a
través de el protocolo MQTT, la Figura 3-14 permite observar que solo cuenta
con un método.
def start iot connection(self)

Método que envı́a una petición HTTP al host ’a239kfcisbv9tk.iot.us-west-
2.amazonaws.com’, donde debe loggearse empleando un archivo de certifi-
cados único para la cuenta registrada a este host.
Una vez se ha establecido una conexión estable, se configuran los paráme-
tros de la misma con el fin de obtener un enlace MQTT de tipo Publisher-
Suscriber elemental, mediante la creación de una instancia denominada
’myAWSIoTMQTTClient’, esta instancia ejecuta un método de conexión
y entra en fase operativa para recibir y enviar mensajes hacia el servidor,
posteriormente, se retorna a la clase iot para ser reenviada a todas las demás
clases bajo el parámetro de ’client’ presente en todos los constructores de
clase vistos anteriormente, permitiendo ası́ a toda la aplicación suscribirse
y publicar mensajes con un único cliente de enlace.
Retorno:
AWSIoTMQTTClient: instancia para comunicación con el servidor
de AWS.
3.2.11. La clase ST VL6180X

Esta clase se emplea para realizar la lectura del sensor analógico de distancia
ST VL6180x desde Python, este sensor posee una interfaz I2C mediante la cual se
puede realizar la lectura de los datos de medida generados; debido a que esta clase
fue desarrollada por un tercero bajo licencia libre, no se agrega la documentación
sobre la misma, para efectos de consulta se recomienda visitar la pagina de GitHub
del desarrollador [6].
Capı́tulo 4
Integración global de componentes
En este capı́tulo se muestra la manera en la cual se lleva a cabo la unión, de todos

los elementos que constituyen el trabajo de automatización en el observatorio as-
tronómico de la Universidad Distrital, en primera instancia se parte por mostrar la
arquitectura general empleada para el sistema implementado, para posteriormente
ahondar progresivamente en cada uno de ellos.
4.1. Arquitectura general

La idea básica desde la cual se parte al momento de comenzar la ejecución del
proyecto, era la de poder controlar remotamente la cúpula del observatorio, el te-
lescopio instalado y disponer de la opción de llevar a cabo la captura de fotografı́as
de los objetos hacia los cuales se apunte el telescopio; en este orden de ideas, se
entiende que el sistema deberı́a estar conformado por una parte de enlace Web y
una parte de construcción de hardware.
Figura 4-1: Arquitectura general de sistema y métodos de comunicación.

86 4 Integración global de componentes
La Figura 4-1 muestra la arquitectura general del sistema implementado, de don-

de puede observarse en primera instancia que se poseen 3 componentes, por un
lado un servidor, por otro se tiene el hardware destinado a la gestión fı́sica del
observatorio, entre los dos se dispone de un cliente web que cumple la función
de puente entre las dos partes del sistema, es decir comunicar el hardware con el
servidor, cada uno de estos componentes fue bautizado con un .alias”para distin-
guirlo de los demás, ası́, el servidor recibe el nombre de moon server, el cliente
earth web y el hardware su iot.
4.2. El servidor
Como ya se ha dicho con anterioridad, es necesario disponer de un servidor para
almacenar la pagina Web, a base de datos de usuarios registrados y una pequeña
tabla con los datos de algunos objetos celestes para poder realizar la ubicación del
telescopio en forma directa, en el servidor también se cuenta con la posibilidad de
ejecutar pequeños scripts sobre python 2.7 para generar algunas respuestas sobre
mensajes especı́ficos; en el servidor tambien cabe mencionar a los espacios de al-
macenamiento o ”buckets”necesarios para las imágenes captadas por las cámaras.
El servicio de servidor contratado es el ofrecido por Amazon Web Services, puesto

que se trata de un esquema implementado por la empresa Robótica Colombia
S.A.S., no es posible entrar en detalles acerca de la organización interna del mismo,
los anchos de banda soportados, la base de datos de objetos y su acceso, ası́ como
de la secuencia de autenticación.
4.3. El cliente Web

Al tratarse de un proyecto de observación remota, resulta obvio el contar con un
aplicativo Web que permita la operación del observatorio, el mismo es desarrollado
sobre Angular 5, en la Figura 4-1 puede apreciarse que el aplicativo Web cumple
la función de puente entre la Raspberry Pi 3 y el servidor, entendiendo claro que
la pagina web es enviada del servidor hacia el navegador que realiza la petición,
pero mantiene dos hilos de comunicación, por un lado se tiene un enlace a través
del protocolo MQTT hacia la Raspberry Pi y uno sobre peticiones HTTP hacia
el servidor.
4.3 El cliente Web 87
Al igual que en el desarrollo del esquema del servidor, la colaboración por parte
del autor de este trabajo en el desarrollo del documento es limitada, por tal razón
no es posible exponer en forma detallada el código de implementación para el mis-
mo, pero esto no significa que no pueda mostrarse en forma general el desarrollo
del mismo.
Para ingresar al aplicativo se debe seguir el vinculo astrolab.tdrobotica.co, y

al hacerlo, se pueden observar las siguientes pantallas:
4.3.1. Login
Esta pantalla funciona como un formulario de autenticación cualquiera, es decir,
recibe un correo electrónico y una contraseña de usuario, una vez se pulsa el
botón de ingreso (ver Figura 4-2), se envı́an los datos de los cuadros de texto
hacia el servidor y se compara con la base de datos de usuarios registrados; si los
datos son correctos se carga la siguiente pagina, si no se retorna al formulario de
autenticación con un mensaje de error.
Figura 4-2: Formulario de autenticación para ingreso al aplicativo.
4.3.2. El panel de control

En esta pagina se encuentran todos los elementos asociados a la gestión del obser-
vatorio, Angular 5 ofrece la posibilidad de emplear subdivisiones en paginas Web
conocidos como “Card”, sobre los cuales pueden agregarse elementos clásicos de
HTML tales como botones o cuadros de texto (ver Figura 4-3), con el principio
de respetar el principio de modularidad establecido durante la fase de planeación
del proyecto se define un elemento “Card””para los componentes principales del
observatorio; en el capı́tulo 4 de este trabajo se explica la existencia de mensajes
especı́ficos cada 30 segundos conocidos como secuencias de ”live”, los cuales tie-
nen como propósito determinar si cada uno de los componentes esta conectado y
funcionando apropiadamente, en caso de una respuesta negativa por parte de un
componente a estas secuencias el elemento “Card” asociado a este deshabilita sus
opciones.
Figura 4-3: Vista tablero de control.
Los elementos “Card” disponibles son:
Camera LPI: esta tarjeta (ver Figura 4-4) contiene un espacio para observar
la imagen capturada desde el telescopio con la cámara ZWO, la opción para
descargar la última imagen capturada, los campos para definir el tiempo de
exposición y ganancia deseados para la imagen y el botón de capturar.
Figura 4-4: Tarjeta para control de cámara planetaria.
Telescopio: Las opciones disponibles son para el movimiento manual del te-
lescopio en los ejes de ascensión recta y azimuth, también se cuenta con un
espacio para observar la imagen capturada por la cámara web y un botón
para refrescar la misma, un control deslizante permite elegir la velocidad de
4.3 El cliente Web 89
movimiento del telescopio y finalmente, un menú desplegable permite selec-

cionar algunos cuerpos celestes del sistema solar para desplazar el telescopio
hasta estos y activar el seguimiento de los mismos (ver Figura 4-5).
Figura 4-5: Tarjeta para control para el telescopio.
Cúpula: esta subdivisión permite controlar los aspectos mas importantes de

la cúpula(ver Figura 4-6), permite rotar la misma de forma manual en des-
plazamientos de 10 grados por cada pulsación, también incluye la opción de
apertura y cierre de compuerta de observación, ası́ como el mostrar el estado
actual de la misma, por ultimo en la parte superior muestra la posición en
grados actual de la misma si la cúpula ha respondido a la secuencia de ”live.o
un linea horizontal en caso contrario.
Figura 4-6: Tarjeta para control para gestión de cúpula.
Señales: la ultima subdivisión con la que cuenta el aplicativo web tiene

como propósito mostrar el estado actual del observatorio (ver Figura 4-7),
recopilando las respuestas a las secuencias de ”live.enviadas desde el cliente
web, muestra el estado de conexión del telescopio, la cúpula, la cámara web
y la cámara planetaria, también muestra el estado de los dos sensores de
instrumentación instalados: el sensor de lluvia y el sensor de suministro
eléctrico.
Figura 4-7: Tarjeta que muestra el estado de los componentes del observatorio.
4.3.3. Perfil
La última pantalla de interés en el aplicativo es la referente al perfil de usuario(ver
Figura 4-8), en ella se muestra el tipo de cuenta que posee el usuario, la opción
para cambiar la contraseña, y el decidir si la compuerta de observación debe
cerrarse si el sensor de lluvia genera una lectura positiva.
Figura 4-8: Vista perfil de usuario.
Al admitirse solamente una sesión para un determinado instante de tiempo se hace

necesario contemplar un tiempo de actividad de 15 minutos, tras el cual se genera
un mensaje de advertencia hacia el usuario donde se solicita una confirmación
para continuar, si es negativa o no se genera confirmación antes de 60 segundos la
sesión es cerrada, también, si la sesión no se cierra a través del menú del aplicativo
y se cierra la ventana o pestaña del aplicativo es necesario esperar a que caduque
la sesión en proceso antes de poder ingresar nuevamente.
4.4. El hardware local

En la automatización industrial, si bien es fundamental solucionar los problemas
que se plantean, también es importante que la solución cumpla con diferentes
estándares que rara vez se tienen en cuenta en el campo académico, como son el
ensamble de los elementos eléctricos y electrónicos en tableros de control certifi-
cados, los cuales contienen en su interior rieles de montaje para los elementos y
4.4 El hardware local 91
canaletas a través de las cuales debe ir el cableado entre ellos, el material de estos
tableros es aluminio recubierto de una capa de pintura aislante, un tablero debe
poseer una puerta con llave con el fin de restringir el acceso a particulares sobre
los elementos que contiene adentro, en tanto que los pulsadores e interruptores
deben colocarse sobre la superficie externa del tablero, otra buena practica es el
agregar protecciones termomagnéticas en las entradas de alimentación del circui-
to, totalizadores y paradas de emergencia para los elementos móviles que están
relacionados directamente con el tablero de control.
En los dos capı́tulos anteriores ya se han expuesto los componentes y la funcio-

nalidad esperada para el componente local de la automatización, lo que resta es
explicar en detalle la conexión de los elementos que conforman esta parte del
trabajo cumpliendo con las buenas practicas de la automatización industrial; se
ha optado por construir dos tableros de control, uno principal encargado de la
comunicación con el cliente web y la gestión total de la infraestructura fı́sica del
observatorio, y otro secundario encargado de la apertura y cierre de las compuer-
tas horizontales del espacio de observación, la principal razón por la cual debe
hacerse en esta forma es la rotación de la compuerta a a medida que rota la cúpu-
la, lo cual implica que el mecanismo de control de las compuertas debe rotar con
ellas también, el enlace entre los dos tableros se lleva a cabo empleando un puerto
serial inalámbrico a través de Bluetooth.
4.4.1. El tablero de control principal

Funciones
Este tablero tiene como objetivo alojar a la placa Raspberry Pi 3, los conmu-
tadores para el motor AC monofásico de rotación de la cúpula, las fuentes de
alimentación, los pulsadores para accionamiento de rotación positiva, rotación ne-
gativa, búsqueda de posición de inicio y conmutación de iluminación, también este
tablero debe servir como punto de inicio para toda la operación, esto es, cuando
se encienda a través de un totalizador la Raspberry debe iniciar la ejecución del
software de gestión local descrito en el capitulo 3, con lo cual se inicializan las
salidas del GPIO, se inicializa el telescopio y se revisa si el tablero secundario
es accesible a través del enlace inalámbrico, también se empiezan a ejecutar las
secuencias de ”live.a solicitud del cliente web siempre que en este halla una sesión
activa.
Puede decirse que este tablero maneja dos circuitos de corriente alterna inde-
pendientes uno de otro, por un lado recibe la alimentación de sus componentes
electrónicos desde una lı́nea de 110 VAC generada por una UPS, en tanto que
el motor AC monofásico para la rotación horizontal debe ser alimentado directa-
mente de la red eléctrica, esto se debe a que no es recomendable conectar cargas
inductivas a elementos de respaldo de energı́a; este método de alimentación nos
indica que en caso de emergencia no es prioritario el desplazar la cúpula hasta su
posición de inicio, pero si es obligatorio el poder cerrar las compuertas del espacio
de observación, la UPS garantiza que una vez encendido el tablero, la Raspberry
Pi 3 siempre se encuentre encendida.
Componentes
Los elementos que conforman este tablero pueden agruparse según la función que
vayan a desempeñar, en este orden de ideas se tienen conmutadores, elementos
de control, fuentes de alimentación, protecciones y pulsadores de ingreso, estos
elementos han sido adquiridos en presentación para montaje sobre riel DIN. en
lista pueden enumerarse ası́:
1. Conmutadores o relevadores de baja potencia: en total se emplean 5 conmu-

tadores de baja potencia (ver Figura 4-9), 2 deben actuar como auxiliares
entre los pines de la Raspberry Pi y los conmutadores de potencia para el
accionamiento del motor AC monofásico, en tanto que se emplean 3 de ellos
para la activación de los colores de la iluminación led instalada, la alimen-
tación de estos conmutadores esta dada a un nivel de 5 V.
Figura 4-9: Arreglo de conmutadores de baja potencia sobre riel DIN.

2. Conmutadores o relevadores de potencia: son necesarios 7 en total (ver Fi-

gura 4-10), se emplean 6 para el inversor de giro destinado al motor AC
monofásico tal y como se ve en la Figura 2-12, en tanto que se emplean un
relevador adicional con bobina de 110 VAC que sirve como sensor de ali-
mentación por red eléctrica, de esta forma, el terminal normalmente abierto
esta conectado a la tierra DC común para todo el circuito, en tanto que el
terminal común del relevador esta conectado a un pin de la placa principal
de control, ası́ cuando no hay electricidad proveniente de la red eléctrica la
Raspberry detecta un nivel bajo en dicho pin.
Figura 4-10: Conmutadores industriales.
3. Fuentes de alimentación DC: Se cuenta con tres fuentes de alimentación DC

de grado industrial (ver Figura 4-11), la primera de ellas ofrece una salida
de 12V 7.5A y tiene como única función alimentar al telescopio MEADE
LX200 GPS, la segunda de las fuentes entrega 12V 4.5A y se empleara para
la conmutación de los relevadores de potencia, la alimentación de los arreglos
de iluminación led y la carga de la baterı́a del tablero de control secundario;
la ultima de las fuentes ofrece una salida de 5V 6.5A y tiene como propósito
el alimentar a la placa Raspberry Pi 3 y a los relevadores de baja potencia.
Figura 4-11: Fuentes DC industriales.

4. Interruptores termomagnéticos: constituyen la protección principal del cir-

cuito en caso de cortocircuito, este tipo de interruptores se caracteriza por
abrir el camino de la corriente eléctrica cuando esta aumenta lo suficiente
para accionar una bobina magnética o expandir una barra metálica que ha-
cen ”saltar.al interruptor (ver Figura 4-12); en total se emplean 6 de estos,
3 interruptores de 10 Amperios están destinados para proteger a cada una
de las fuentes DC y controlan el flujo de energı́a proveniente de la UPS,
los 3 interruptores restantes se emplean para la protección de las bobinas
del motor AC monofásico, se tiene un interruptor principal de 20 Amperios
y dos interruptores secundarios de 10 Amperios cada uno, el esquema de
conexión se muestra en la Figura 2-12.
Figura 4-12: Protecciones termomagnéticas.
5. Pulsadores: se agregan 4 pulsadores convencionales de tipo industrial, des-

tinados a ofrecer la posibilidad de interactuar directamente con la cúpula,
ası́ pues se tiene un pulsador para rotación a izquierda, un pulsador para
rotación a derecha, un pulsador para búsqueda de posición de inicio y uno
para la manipulación de la iluminación de la cúpula (ver Figura 4-13); adi-
cionalmente por cuestiones de seguridad se agrega un hongo de parada de
emergencia que conmuta un relevador de potencia y abre la alimentación
de las bobinas del motor AC monofásico, esto detiene de inmediato cual-
quier clase de movimiento, la Raspberry Pi es informada de la condición de
emergencia mediante un pin del GPIO conectado al terminal común de un
relevador cuyo pin normalmente cerrado esta conectado a la tierra fı́sica del
circuito DC del tablero, de esta manera el sistema de control central puede
determinar si se ha producido una condición de emergencia.
Figura 4-13: Pulsadores y hongo de emergencia.
6. Totalizador y piloto: un totalizador es un interruptor maestro que se en-

carga de abrir por completo los circuitos de alimentación de un tablero de
control, según el modelo, puede tener múltiples lineas para controlar varios
circuitos independientes uno de otro; la luz piloto se emplea para generar
una confirmación visual sobre el estado del tablero, ası́, cuando la luz este
encendida se asume la operación del tablero, para el tablero construido la
luz piloto es alimentada por la señal proveniente de la UPS.
7. Borneras: Con el fin de facilitar la interconexión de diferentes elementos en

el interior del tablero de control, ası́ como de organizar las entradas de cables
con señales y alimentación desde fuera de este, se suelen utilizar borneras de
conexión, que básicamente ofrecen dos puntos de conexión (ver Figura 4-14);
también es posible ensamblar rieles de alimentación o de tierra empleando
puentes entre varias borneras.
Figura 4-14: Borneras de conexión tablero principal.
8. Raspberry Pi 3: esta placa constituye el cerebro del tablero de control, una

descripción detallada sobre la misma se ofrece en la primera sección del

capitulo 3, la única novedad relacionada con respecto al tablero de control
es la instalación de la placa al interior de una caja para riel DIN (ver Figura
4-15), esta caja ofrece una PCB universal sobre la cual instalar bornas
laterales donde pueden hacerse las conexiones hacia otros elementos en forma
relativamente sencilla.
Figura 4-15: Montaje Raspberry Pi 3 sobre riel DIN.
Distribución y esquemáticos
La distribución de los elementos al interior del tablero de control se hace siguiendo

el estándar industrial, según el cual, en la parte superior del tablero deben ubi-
carse los elementos de protección y las fuentes, en la parte media los dispositivos
de control o circuitos electrónicos, y en la parte inferior las borneras de conexión,
dicha distribución se muestra en la Figura 4-16, nótese que por cuestiones de
espacio y mejor organización se decidió instalar el arreglo de conmutadores para
las luces de iluminación en la parte inferior derecha del tablero.
Todos los tableros industriales tienen como caracterı́sticas comunes el poseer una
bandeja sobre la cual se sujeta el riel sobre el cual se montan los dispositivos,
también cuentan con una puerta con cerradura con el fin de restringir el acceso al
interior del tablero solo a personal capacitado en las tareas de mantenimiento; por
conveniencia se busca que los pulsadores de un tablero de control sean montados
sobre el propio tablero, sin embargo, para casos en los cuales la ubicación de los
mismos no lo permite pueden ser ubicados en otros lugares siempre y cuando los
cables de los mismos salgan por la parte inferior del tablero y se lleven hasta los
elementos haciendo uso de canaleta, lo mismo aplica para los sensores.
Figura 4-16: Distribución elementos dentro de tablero principal.
Las fuentes DC disponibles son alimentadas con una UPS con el fin de garantizar
que el sistema continué en funcionamiento aun durante un corte de energı́a; la Fi-
gura 4-17 muestra el diagrama de conexión de las mismas, con su correspondiente
protección termomagnética y el uso que se hace de cada una de ellas.
Figura 4-17: Esquema de alimentación tablero principal.
Finalmente, la Figura 4-18 muestra el circuito esquemático del tablero principal,

en la sección 4.5 se discuten las particularidades del mismo.
Figura 4-18: Diagrama esquemático del tablero de control principal.
4.4.2. El tablero de control secundario

Funciones
El tablero de control secundario es el encargado de controlar la apertura y cierre de

las compuertas horizontales para el espacio de observación, en primera instancia
esto puede parecer una aplicación que no justifica por si misma la fabricación de
un tablero adicional, sin embargo hay que considerar que los motores se encuen-
tran instalados sobre la cúpula y por tanto rotan con ella, lo cual forzosamente
obliga a instalar el tablero de tal forma que rote junto con la cúpula, luego no
es posible construir una conexión cableada para la alimentación de los dos moto-
res DC de las compuertas y para las señales de activación, el enlace entonces, se
lleva a cabo empleando un modulo de comunicación Bluetooth HC-05, el tablero
también cuenta con dos pulsadores para la apertura y el cierre de la compuerta
en forma manual, ya sea para el caso en el cual el controlador electrónico no se
encuentre disponible, o simplemente se quiera hacer en forma fı́sica.
La fuente de energı́a que alimenta el tablero secundario es una baterı́a de plomo

de 12V 7Ah, la cual basta para poner en marcha los motores DC y energizar al
controlador electrónico; con respecto a los motores DC cabe decir que cada uno
de ellos cuenta con un arreglo de conmutadores ası́ como de finales de carrera que
sirven para fijar las posiciones de cierre y apertura de compuerta, en la sección
2.3 se detalla el funcionamiento del sistema.
Componentes
Como cabria esperar, este tablero es considerablemente mas sencillo que el tablero
de control principal, luego la lista de elementos que lo conforman es la siguiente:
1. Tarjeta Arduino Uno R3: cumple la función de servir como controlador cen-
tral para el tablero, el microcontrolador disponible en estas placas es el
ATMEGA 328p, un dispositivo basado en una arquitectura de 8 bits con un
set de instrucciones reducido que permite una programación relativamente
sencilla.
2. Screw Shield: una de las ventajas de emplear la plataforma de Arduino es

el empleo de ”Shields”, es decir, tarjetas de expansión que se conectan a la
placa central que contienen accesorios adicionales, en esta caso, la tarjeta
Screw contiene borneras para realizar conexiones en riel DIN, ası́ como posee
una PCB universal donde puede montarse fácilmente un modulo Bluetooth.
3. Modulo HC-05: modulo de comunicación Bluetooth, permite establecer una

conexión serial ası́ncrona sin depender de cables.
EL montaje de los 3 elementos anteriores se realiza directamente usando la
placa Arduino como base tal como lo muestra la Figura 4-19.
Figura 4-19: Montaje sobre riel DIN de microncontrolador con screw shield.
4. Borneras: Con el fin de facilitar la interconexión de diferentes elementos en

el interior del tablero de control, ası́ como de organizar las entradas de cables
con señales y alimentación desde fuera de este, se suelen utilizar borneras de
conexión, que básicamente ofrecen dos puntos de conexión (ver Figura 4-20);
también es posible ensamblar rieles de alimentación o de tierra empleando
puentes entre varias borneras.
Figura 4-20: Borneras de conexión para riel DIN.
5. Módulo de relevadores de baja potencia: en la sección 2.3 del capitulo 2 del

presente documento se detalla la construcción de un arreglo inversor de giro
empleando relevadores de baja potencia, de allı́ se deduce que son necesarios
un total de 4 para su construcción, luego se opta por emplear una tarjeta
como la vista en la Figura 4-21.
Figura 4-21: Relevadores para motores de compuerta vertical.
6. Baterı́a de plomo 12V 7A: baterı́a para llevar a cabo la alimentación de los
elementos del tablero, ası́ como de los motores DC de la compuerta.
7. Canaleta ranurada: se emplea para contener el cable empleado para hacer

las conexiones entre los elementos del tablero.
8. Riel DIN: el objetivo del riel es poder sujetar a los elementos que conforman
el armario de control.
9. Microswitches: son necesarios un total de 4 finales de carrera para controlar

las posiciones de totalmente abierto y totalmente cerrado (ver Figura 4-
22), el contacto comúnmente abierto de los mismos se realimenta hacia el
microcontrolador.
(a) Motor izquierdo. (b) Motor derecho.
Figura 4-22: Finales de carrera y motores DC.
10. Totalizador: Al igual que para el caso del tablero de control es necesario
un totalizador que administre el paso de energı́a hacia los componentes del

tablero.
11. Pulsadores: puesto que se cuenta con la posibilidad de llevar a cabo la aper-
tura y cierre de forma manual, se usan dos pulsadores de tipo industrial en
la forma que ilustra la Figura 4-23, uno para abrir y otro para cerrar.
Figura 4-23: Montaje de pulsadores.
12. Fusible: sirve como protección en caso de corto circuito.
13. Condensador 22000 uF: se emplea para reducir el efecto desestabilizador

producto de la “patada inductiva” generada por los motores cuando se en-
cienden.
14. Diodo: evita que la baterı́a devuelva energı́a hacia la fuente que lleva a cabo
su carga.
Distribución y esquemáticos
En el caso de este tablero, se tiene nuevamente un bandeja con riel DIN sobre el
cual se montan los componentes en la distribución que muestra la Figura 4-24;
debe tenerse en cuenta que un buen numero de componentes se encuentran en la
parte externa del tablero, como son los motores DC y los finales de carrera, la
borneras del tablero se ubican en la parte inferior del tablero con el fin de facilitar
su acceso por parte del cableado proveniente del exterior del tablero, la baterı́a
de plomo encargada de alimentar al tablero se sujeta únicamente por la puerta
del mismo, ya que no es recomendable sujetarla empleando ganchos metálicos o
realizar perforaciones en la misma.
Para el montaje del microcontrolador se usan bases plásticas generadas mediante

impresión 3D, lo mismo aplica para el caso del modulo de relevadores, el sello de
caucho que posee el tablero impide el acceso de humedad que pueda cristalizar el
material del cual están hechas.
Figura 4-24: Distribución tablero para motores DC.
La Figura 4-25 muestra el circuito esquemático de las conexiones entre los ele-
mentos del tablero de control para la apertura y cierre de compuertas.
Figura 4-25: Plano tablero de control apertura de compuertas.

En el circuito esquemático puede apreciarse que son necesarios dos niveles de vol-
taje para alimentar los diferentes componentes del tablero, con una única baterı́a
de 12V disponible para cumplir este objetivo y la necesidad de llevar a cabo la
carga de la misma se implementa el montaje mostrado en la Figura 4-26 para
solucionar el problema planteado.
Figura 4-26: Esquema de alimentación tablero secundario.
4.5. Resultados y análisis

Los resultados del presente trabajo pueden agruparse en dos grupos principales,
resultados de hardware y desarrollos de software, en el primer grupo clasifican los
tableros de control ası́ como los ajustes necesarios en cuanto a la infraestructura
fı́sica del observatorio, para el segundo caso aplica tanto el software de gestión
local como los aportes en cuanto al aplicativo web, a continuación se lleva a cabo
un sumario referente a estos dos grupos tomando en cuenta que ya han sido
previamente expuestos en detalle.
4.5.1. Tablero de control principal

La vista definitiva del tablero de control principal construido se muestra en las
Figuras 4-27 y 4-28, la primera observación importante que se debe hacer es con
respecto a los pulsadores de accionamiento y al hongo de emergencia, pues resul-
ta evidente que estos no se encuentran instalados directamente sobre el tablero
de control debido a la posición en que se encuentra este, esto resulta en que la
instalación de los mismos se lleva a cabo en la caja que contiene al motor AC
monofásico, de manera que puedan ser accionados cómodamente por cualquier
usuario.
4.5 Resultados y análisis 105
Figura 4-27: Vista tablero de control principal y pulsadores.
En la Figura 4-28 puede observarse el recorrido del cableado al interior de la

canaleta ranurada, ahora bien, si se observa el esquemático mostrado en la Figura
4-18 no pareciera que el volumen del cableado correspondiese con lo visto al inte-
rior de la canaleta, sin embargo, es necesario tomar en cuenta que las conexiones
hacia pulsadores, sensores externos y lı́neas de alimentación deben pasar primero
por la lı́nea de borneras con el objetivo de garantizar el poder llevara a cabo re-
paraciones de forma rápida.
También puede observarse el uso de marquillas para cada una de las conexiones
con el fin de llevar un registro de cual es el punto de inicio y final de un cable
determinado sin necesidad de seguir todo el recorrido del mismo, los agujeros que
pueden observarse en la parte inferior del tablero son los puntos de salida y entra-
da de conexiones, lo que asegura los cables se conoce como prensa estopa y tiene
como objetivo el evitar desconexiones al interior del tablero producto de cualquier
fuerza que pueda halar el cable desde el exterior.
Resulta evidente el uso intensivo de dispositivos electromecánicos por sobre otras

alternativas como conmutadores de electrónica de estado solido al observar el dia-

grama de la Figura 4-18, esto como consecuencia de la evaluación del problema
planteado, al determinar que un esquema de lógica cableada era mas conveniente
en la medida que disminuye los tiempos de desarrollo y no necesita de un para-
digma de control demasiado complejo para lograr un sistema robusto, también
puede observarse en el esquemático como pueden obtenerse algunas medidas del
estado de parámetros que emplean niveles de voltaje inapropiados para cualquier
sistema digital como es el caso del estado de la red eléctrica o la ocurrencia de
una situación de parada de emergencia, mediante la simple conmutación de un
contacto a la linea de tierra de las fuentes DC, para asegurar el estado lógico alto
en ausencia de la conexión a tierra se emplea la configuración de los pines del
GPIO de la Raspberry Pi para fijar resistencias de pull-up internas, el empleo
de contactos electromecánicos también garantiza el aislamiento galvánico entre
diferentes circuitos al interior del tablero, permitiendo ası́ proteger los circuitos
digitales de señales de energı́a considerable.
Figura 4-28: Vista interna de tablero de control principal.
Al respecto del funcionamiento del mecanismo de parada de emergencia se ob-

serva que la condición de normalidad se presenta cuando circula energı́a a través
de la bobina, y que la fuente empleada para el accionamiento es directamente la
red eléctrica, esta metodologı́a se justifica partiendo del hecho de poder descartar
malos funcionamientos en el estado del sistema cuando se presentan fallas en el
suministro eléctrico, ası́ el sistema se detiene automáticamente ante la ausencia
de electricidad en la red, por el contrario, si por ejemplo se empleara el esquema

inverso de alimentar para detener el sistema o emplear una de las fuentes DC
para accionar el relevador se puede presentar el caso de una rotura en la linea de
alimentación o un fallo en las fuentes que impidan la detención inmediata de los
elementos mecánicos.
(a) Luz blanca. (b) Luz azul.
(c) Luz roja (d) Luz verde
Figura 4-29: Diferentes colores de iluminación.
Como se ha dicho anteriormente, el tablero de control posee dos fuentes de ali-

mentación de corriente alterna , por un lado, En el esquemático mostrado en la
Figura 4-18 se muestra el cableado de la de la energı́a proveniente de la red eléctri-
ca tradicional a través de conmutadores hacia el motor AC monofásico y como se
emplean estos para retornar algunas señales hacia el controlador digital, en tanto
que la señal de alimentación proveniente de una UPS se emplea para alimentar
las fuentes DC destinadas al telescopio, la Raspberry Pi 3 y la iluminación de la
cúpula tal como se muestra en la Figura 4-17, la razón de esto es poder enviar
una señal de cierre de la compuerta de observación hacia el tablero principal en
caso de un corte de la red eléctrica comercial y poder informar de este suceso a un

determinado usuario con una sesión abierta en el aplicativo web, como ya se ha
dicho antes, el motor monofásico no debe ser conectado nunca a la UPS a riesgo
de dañar la misma.
Con respecto a la iluminación, cuando esta se activa desde el aplicativo el color

por defecto es el blanco, esto con el fin de disponer de la mayor cantidad de
iluminación al momento de tomar una captura con la cámara web, sin embargo,
en forma local el color puede ser seleccionado libremente por el operador (véase
Figura 4-29).
4.5.2. Tablero de control secundario

La vista final de tablero de control secundario construido para la apertura y cierre
de compuertas se muestra en las Figuras 4-30 y 4-31, en primera instancia se
observa que el tablero se encuentra fijado directamente sobre la cúpula con el fin
de que rote junto con esta, también se distinguen fácilmente dos pulsadores sobre
la cubierta del tablero, uno par abrir la compuerta y otro para cerrarla en forma
manual, el esquemático de la Figura 4-25 muestra que para el caso en el cual los
dos pulsadores son presionados al tiempo no se produce ningún movimiento por
parte de los motores DC.
Figura 4-30: Vista tablero de control secundario y pulsadores.

Figura 4-31: Vista interna tablero de control secundario.
El tablero secundario también hace uso de un esquema de lógica cableada para

llevar a cabo la apertura y cierre de la compuerta de observación, tal y como se
puede apreciar en la Figura 4-25, el puente H para la inversión de giro es cons-
truido con conmutadores, en tanto que se emplean finales de carrera para definir
los topes para cada una de las dos posiciones de la compuerta.
El enlace con el tablero de control principal se lleva a cabo empleando un mo-

dulo Bluetooth HC-05, y consiste en mensajes cortos de tipo orden o solicitud-
respuesta, las ordenes enviadas por parte del maestro son únicamente caracteres,
ası́, se emplea el carácter ’c’ para indicar que la compuerta debe ser cerrada, y
el carácter ’o’ para indicar que la compuerta debe ser abierta, la única solicitud
por parte del tablero de control principal consiste en obtener el estado actual de
la compuerta mediante el envió del caracter ’r’, las respuestas posibles por parte
del tablero de control secundario pueden ser:
’O’: indica que la compuerta se encuentra totalmente abierta si detecta co-

nexión a tierra fı́sica en los pines asociados a los finales de carrera F2 y
F3.
’C’: indica que la compuerta se encuentra totalmente cerrada si detecta

conexión a tierra fı́sica en los pines asociados a los finales de carrera F1 y
F4.
’M’: indica que la compuerta se encuentra en un estado medio puesto que

no se detecta conexión a tierra fı́sica en ninguno de los pines asociados a los

finales de carrera.
’E’: Para el caso en el que se tenga una combinación diferente en los pines de
los finales de carrera diferente a los descritos para las respuestas anteriores,
se entiende un estado de error en las conexiones y se retorna dicho aviso al
tablero principal.
El código del microcontrolador puede ser consultado en el anexo B.1, donde pue-
de apreciarse que el microcontrolador funciona en la forma de una máquina de
estados, siendo estos: reposo, abriendo y cerrando, de acuerdo al caracter que se
halla recibido desde el maestro se activa una sección especı́fica de los condicio-
nales mostrados en el loop de ejecución, también se ha optado por configurar un
whatchdog timer que ejecute un “reset” del microcontrolador en caso de que este
se detenga en un solo estado dejando de evaluar los demás, con el fin de evitar la
pérdida de conexión con el tablero.
En la Figura 4-26 puede observarse como se obtienen los dos niveles de voltaje
requeridos para el funcionamiento del tablero, también puede verse como se man-
tiene la carga de la baterı́a a través de borneras que la enlazan con una de las
fuentes DC del tablero principal, estas se ubican en la posición de “home” de la
cúpula, razón por la cual es necesario desplazar la misma hasta dicha posición
para llevar a cabo la carga de la baterı́a, como protección se emplea un diodo
para restringir el paso de la corriente solo desde la fuente hacia la baterı́a y no en
sentido inverso lo que puede dañar la fuente en el caso en que esta se encuentre
apagada y la baterı́a conectada a través de las borneras.
4.5.3. Resultado final

Con respecto al software de gestión local desarrollado todo el capı́tulo 3 del presen-
te trabajo puede considerarse como la exposición detallada del resultado obtenido
en cuanto a la parte de programación realizada, especialmente en lo referente a
la documentación de cada una de las clases escritas y la relación entre ellas; en
cuanto a la codificación del aplicativo web, los scripts del lado del servidor y la
base de datos de objetos celestes y usuarios, al tratarse de desarrollos mayoritario
por parte de la empresa Robótica Colombia S.A.S. no es posible expandir en ellos.
Luego lo que resta por mostrar es el tipo de imágenes que pueden obtenerse em-
pleado todo el sistema desde el aplicativo empleando la cámara planetaria ZWO
conectada a la placa Raspberry Pi 3 empleando una conexión de servidor local
para la conexión de la cámara a un sistema embebido, estas imágenes posterior-
mente son enviadas al aplicativo Web donde puede obtenerse una vista previa de
las mismas y ser descargadas.
La Figura 4-32 muestra dos vistas de júpiter, la imagen 4.32(a) muestra la ima-
gen tal y como es capturada por la cámara con un tiempo de exposición de 80
milisegundos y una ganancia de 30, en tanto que la imagen 4.32(b) muestra un
tratamiento de mejoramiento de imagen llevado a cabo en forma local sobre la
imagen ya capturada, en las dos imágenes es posible distinguir claramente las fran-
jas en la atmósfera del planeta ası́ como el color real del mismo, sin embargo, en la
imagen tratada es posible distinguir, aunque en forma tenue a los satélites Euro-
pa y Ganimedes, justificando ası́ que aunque no se obtengan vistas de objetos en
las imágenes originales, con un mejoramiento de imagen simple pueden observarse.
(a) Imagen original. (b) Imagen tratada.
Figura 4-32: Júpiter desde el observatorio astronómico de la Universidad Distri-

tal.
Para Saturno, se emplea un tiempo de exposición de 70 milisegundos y una ga-

nancia de 20, los resultados se muestran en la Figura 4-33, por un lado se tiene
la imagen original 4.33(a) que muestra la captura como se obtiene con la cámara
planetaria, la imagen 4.33(b) muestra un aumento en el brillo y un ligero ajuste en
el color sobre la imagen, permitiendo ası́ tener un indicio mas claro del color real
de la atmósfera del planeta; los anillos del planeta son perfectamente distinguibles
e incluso es posible encontrar la división de Cassini entre los dos grupo de anillos
A y B.
Figura 4-33: Saturno desde el observatorio astronómico de la Universidad Dis-

trital.
Figura 4-34: Marte desde el observatorio astronómico de la Universidad Distrital.
La última captura que se presenta corresponde a Marte mostrado en las dos imáge-
nes generadas en la Figura 4-34, como en los casos anteriores se tiene la imagen
original tomada por la cámara y una imagen con un tratamiento de mejora básico,
en los dos casos puede distinguirse fácilmente la capa de hielo del polo norte del
planeta, el color del planeta no se distingue con facilidad debido a la naturaleza
tenue de la luz reflejada por el planeta comparada con la luz de Júpiter y Saturno;
los ajustes para la cámara con 100 milisegundos de tiempo de exposición y 35 en

ganancia.
Para obtener imágenes mas nı́tidas de cualquier objeto se suele incrementar el

tiempo de exposición de la cámara, ası́ como habilitar el seguimiento del cuerpo
celeste por parte del telescopio con el fin de tomar mas de una imagen o enfocar
el objeto exactamente en la misma posición a medida que este varia su posición
relativa en la bóveda celeste como consecuencia de la rotación terrestre.
Capı́tulo 5
Actividades adicionales
Este capitulo recoge algunas actividades adicionales que fueron realizadas durante
el tiempo de la pasantı́a, algunas tienen que ver con la instalación de equipos adi-
cionales en el observatorio astronómico de la Universidad Distrital, otras tienen
que ver con trabajos realizados para la empresa Robótica Colombia S.A.S., que si
bien no fueron desempañadas durante un periodo de tiempo largo, también mere-
cen ser consideradas en el sentido de aportar experiencia en algunas habilidades
de ensamble y depuración de circuitos electrónicos.
5.1. Complementos observatorio astronómico
5.1.1. Instalación de circuito cerrado de televisión

Un ı́tem del contrato entre la Universidad Distrital y la empresa Robótica Colom-
bia S.A.S. especificaba la necesidad de llevar a cabo la instalación de un circuito
cerrado de televisión en las instalaciones del observatorio para efectos de vigilan-
cia al interior del observatorio, en esta tarea se invirtieron cerca de 20 horas en
las cuales se llevo a cabo la instalación de las cámaras en 6 puntos diferentes del
observatorio, en los 3 niveles superiores del mismo.
EL DVR adquirido para este propósito es un dispositivo de 8 canales de la marca

HKVISION (ver Figura 5-2), el cual además de ofrecer la capacidad de grabación
en forma local empleando un disco duro interno también cuenta con la capacidad
de conexión a internet median un puerto de Ethernet y las cámaras de vigilancia
empleadas cuentan con visión nocturna que se activa automáticamente en cuanto
detecta cambios en el nivel de luz ambiente.
116 5 Actividades adicionales
Figura 5-1: Trazado de canaleta autoadhesiva.
(a) Cámara del segundo nivel. (b) Cámara entra-

da.
Figura 5-3: Vista de las cámaras instaladas y canaleta autoadhesiva.
(a) Montaje de pared. (b) Imagen de cámaras en TV.
Figura 5-2: Montaje televisor y DVR.
El cableado entre las cámaras y el DVR se lleva a cabo empleando canaletas

autoadhesivas con el fin de proteger el cable y prolongar la vida útil del mismo
(ver Figura 5-3); otro dato interesante acerca del DVR instalado es el hecho de
5.1 Complementos observatorio astronómico 117
que solo realiza la grabación de vı́deo cuando detecta movimiento, lo cual es útil
pues hace mas eficiente el uso del espacio de almacenamiento disponible en el
disco.
5.1.2. Instalación de UPS

En el capitulo anterior se mencionaba como para el tablero de control principal
eran dos necearı́as dos fuentes de alimentación de corriente alterna, por una parte
la red eléctrica para el motor monofásico y por otro una fuente proveniente de
una UPS para la alimentación de la placa controladora, para cumplir con este
requisito se llevo a acabo la instalación de una unidad Smart-UPS de APC como
la mostrada en la Figura 5-4.
Figura 5-4: UPS.
(a) Clavija de conexión (b) Tomas de salida.

UPS.
Figura 5-5: Toma de energı́a para UPS y toma corrientes de salida de la misma.
La UPS puede entregar una potencia de salida hasta de 300 VA, lo cual permite
emplear su salida no solo para las fuentes DC del tablero principal, si no que
también se conectan el DVR y el televisor de vigilancia a la misma, de manera
que se garantice la seguridad del observatorio aun cuando no halla suministro de
la red eléctrica comercial, también se alimenta con la energı́a de la UPS a la es-
tación meteorológica del observatorio y el switch de red que proporciona acceso a
internet en el sitio, y se deja abierta la opción para alimentar computadores desde
los tomas adicionales.
Las tareas de adecuación para la instalación de la UPS incluyeron la puesta de

la misma al interior del RAC del switch de red, la instalación de la toma especial
para la UPS con su correspondiente protección termomagnética en el tablero de
tacos del observatorio y el trazado de las lı́neas de energı́a empleando canaleta
autoadhesiva como se muestra en la Figura 5-5; en un comienzo se pensó en hacer
uso de la interfaz serial disponible en la UPS para conectar esta a la Raspberry Pi
3 y llevar a cabo un monitoreo sobre su estado y poder informar sobre problemas
de funcionamiento, sin embargo esta opción fue descartada por motivos de tiempo.
5.1.3. Instalación y configuración de estación meteorológi-

ca
La ultima actividad complementaria en el observatorio astronómico de la Univer-
sidad Distrital Francisco José de Caldas es la referente a la instalación de una
estación meteorológica Davis Vantage Pro 2, este modelo cuenta con un montaje
con toda la instrumentación y una consola de control, la comunicación entre las
2 partes se hace a través de un enlace de radio, la consola de control muestra
las lecturas actuales de los instrumentos y posee la opción de presentar en forma
gráfica cualquiera de las lecturas durante las ultimas 24 horas tal y como puede
observarse en la Figura 5-7.
La consola cuenta con la opción de conectarse a internet y poner los datos leı́dos
por los instrumentos en la nube de Davis siempre y cuando se cuente con una
suscripción a la misma, también es posible embeber los datos en otros sitios web
mediante la API ofrecida por Davis.
La Figura 5.6(a) muestra el montaje de los instrumentos de la estación sobre un

tubo metálico ubicado en el techo del observatorio, este tubo puede ser acercado
5.1 Complementos observatorio astronómico 119
(a) Vista desde la compuerta de la (b) Vista desde la primera

cúpula. planta del observatorio.
Figura 5-6: Vistas de la estación meteorológica.
al espacio de observación de la cúpula empleando una linea de cable de acero con

el propósito de llevar a cabo limpieza o mantenimiento de los instrumentos, el
cable que puede observarse en la imagen pertenece a la placa del sensor de lluvia
del tablero principal, la cual se monto sobre el brazo de la veleta de la estación;
la fuente de energı́a de la instrumentación de la estación es una baterı́a de larga
duración especial para este tipo de dispositivos, el tiempo de actividad estimado
es de dos años.
Figura 5-7: Consola de control y visualización de datos.
Aparte del ensamble de la estación, el proceso de montaje involucro la calibración

de algunos instrumentos, tales como la veleta y el anemómetro.
5.2. Tareas de apoyo en la empresa Robótica Co-

lombia S.A.S.
Como parte del acuerdo realizado con la empresa se destinaron alrededor de 50
horas de trabajo por parte del pasante en tareas de colaboración en la empresa,
en forma general se tienen actividades.
5.2.1. Ensamble y depuración de tarjetas electrónicas de

montaje superficial
Se llevo a cabo el montaje de tarjetas electrónicas enfocadas en el control de
motores DC y la adquisición de datos de sensores, destinadas a la construcción de
robots didácticos, el procedimiento consiste en la colocación de los componentes
sobre PCB’s con soldadura liquida en los punto de conexión y la soldadura de las
mismas empleando un horno infrarrojo.
(a) Tarjeta controladora “skydragon”. (b) Seguidor de linea.
(c) Módulos didácticos. (d) Shield complementaria para Ar-

duino.
Figura 5-8: Tarjetas ensambladas en Robótica Colombia S.A.S.

5.2 Tareas de apoyo en la empresa Robótica Colombia S.A.S. 121
El paso a seguir era la carga de un cargador de arranque para el microcontrolador

de la tarjeta con el fin de hacer posible su programación directa a través de USB,
finalmente el procesos termina con la prueba de la tarjeta cargando algunos pro-
gramas para verificar el correcto estado de la tarjeta, algunos de estos productos
se muestran en las diferentes imágenes que componen la Figura 5-8.
5.2.2. Fabricación de partes para robots didácticos

Otro de los productos de la empresa son las partes para robots de competencias
didácticas, como seguidores de lı́nea y minisumos, algunas de estas partes son
ruedas de caucho y piezas de ensamble elaboradas mediante impresión 3D, algunos
de estos productos pueden observarse en la Figura 5-9, el trabajo llevado a cabo
consistió en ocupar algunas horas a cada una de estas actividades y el ensamble
final de los dispositivos.
(a) Chasis para minisumo. (b) Regleta de sensores para seguidor

de linea.
(c) Ruedas para robots de com-

petencia.
Figura 5-9: Partes para robots didácticos.

5.2.3. Tareas de soporte y atención

Puesto que la empresa Robótica Colombia S.A.S. lleva a cabo una buena parte
de sus actividades comerciales de la mano de colegios y fundaciones, entre ellas
Innova Latam, fueron destinadas algunas horas a tareas de soporte y asesorı́a de
dichas entidades en actividades como:
Asesorı́a en compra de equipos.
Enseñanza de programación básica para niños sobre Arduino y Scratch.
Revisión de garantı́as para productos defectuosos.
Talleres y generación de contenido didáctico para educación.

Capı́tulo 6
Conclusiones y Trabajos Futuros
6.1. Conclusiones
Se decidieron escribir un conjunto de conclusiones relacionada con los tres ejes
principales en cuanto a los que giró el desarrollo: el tablero de control principal,
el tablero de control secundario y el software de gestión local. Dichas conclusiones
se exponen en las subsecciones siguientes.
6.1.1. Sobre el tablero de control principal

El tablero de control principal fue construido empleando el estándar indus-
trial recomendado para este tipo de dispositivos, siguiendo la distribución
estándar mostrada en la Figura 4-16. Esto es, empleando riel DIN y equi-
pos especialmente diseñados para su puesta en forma horizontal a lo largo
de este, siguiendo la distribución recomendada con protecciones y fuentes
de alimentación en la parte superior, elementos de control en la parte media
y finalmente las borneras de conexión en la parte inferior. A esto hay que
agregar el empleo de canaleta ranurada para contener el cable empleado en
la interconexión de los componentes, ası́ como el uso de prensa estopa para
el paso de cableado desde el exterior hacia el tablero.
El esquemático mostrado en la Figura 4-18 muestra el uso intensivo de

lógica cableada para el control del movimiento del motor de rotación de
la cúpula, permitiendo la inversión de giro del mismo y el implementar un
mecanismo de parada de emergencia. También se evidencia que es necesa-
rio agregar elementos de protección con el fin de cortar el flujo de energı́a
automáticamente en caso de corto u otras fallas.
En el capitulo 2 se exponen dos alternativas para la sincronización de la

124 6 Conclusiones y Trabajos Futuros
posición del telescopio con la posición angular de la cúpula. Esto con el

fin de garantizar la correcta alineación entre la compuerta de observación
y el colector del telescopio, que permita implementar la funcionalidad de
seguimiento automático por parte del telescopio de objetos celestes sin verse
obstaculizado por la cubierta de la cúpula. En este orden de ideas, se pre-
sentan dos opciones para conseguir este propósito. La primera, empleando
un magnetómetro digital compensado en inclinación con un acelerómetro
y un giroscopio, en tanto que la segunda opción implica la construcción
de un sistema de encoder incremental mediante la instalación fı́sica de pie-
zas metálicas y un sensor óptico de distancia, las pruebas demostraron que
si bien la primera opción es mas precisa, no es posible su implementación
practica como consecuencia de un fenómeno de apantallamiento magnético
al interior de la cúpula, obligando ası́ a seleccionar el sistema de encoder
incremental como mecanismo de ubicación.
El encoder incremental construido descrito en la sección 2.2.3 emplea una

serie de “objetivos” consistentes en recuadros metálicos hacia los cuales se
apunta un sensor de distancia auto-reflex. El barrido de los datos captados
por el sensor se muestran en la Figura 2-24, de donde se concluye que, si bien
no es posible establecer un intervalo estándar en las medidas que indique la
presencia o no de un objetivo, si es posible detectar al mismo empleando un
mecanismo de sensado de gradiente mediante una ecuación en diferencias,
con lo cual se consigue una discretización de los datos captados por el sensor.
El encoder incremental, tal y como se muestra en el modelo de la Figura

2.2.3, ofrece una resolución de 5 grados de distancia entre cada objetivo, a
lo largo de un recorrido de aproximadamente 333 grados a ser cubiertos por
un total de 67 objetivos. El tamaño del espacio de observación no permite
generar una medida constante para todos los 360 grados, luego para valores
superiores a 335 grados se desplaza la cúpula durante un tiempo suficiente
para garantizar una posición de 350 grados al centro del espacio de obser-
vación, esto es suficiente para que el colector del telescopio apunte a través
de ella.
La instrumentación disponible para el tablero de control principal fue enfoca-

da para generar una condición de cierre y bloqueo del observatorio, enfocado
especialmente a dos condiciones: en primer lugar, por un corte de energı́a
eléctrica que irremediablemente deshabilita la rotación de la cúpula y, en
6.1 Conclusiones 125
segundo lugar, por una condición de lluvia que pueda resultar perjudicial
para los equipos internos. Con el fin de garantizar la operación ininterrum-
pida del sistema de control del observatorio, la placa de control ası́ como el
telescopio son alimentados con energı́a proveniente de una UPS.
De acuerdo al esquemático mostrado en la Figura 4-18 la placa controladora

adquiere las señales de la instrumentación requerida empleando únicamente
entradas digitales, aún cuando algunas de las variables que son medidas son
de naturaleza alterna o analógica. Para el caso de la distancia, se emplea una
interfaz serial para la lectura del sensor. Para determinar si se ha producido
una condición de emergencia o un corte de energı́a eléctrica, se recurre al
empleo de conmutadores electromecánicos que lleven el estado de los pines
asociados al mismo a nivel bajo.
De acuerdo a lo expresado con respecto a la comunicación entre la placa

controladora y el telescopio Meade LX200 GPS, se deduce que es necesario
el empleo de una interfaz serial. La razón por la cual se opta por hacer uso
de un conversor USB-Serial y no del modulo UART disponible en el GPIO
de la placa Raspberry Pi 3 es que este se emplea para el manejo, a través
de un puerto virtual RFCOMM, del radio Bluetooth con el cual se lleva a
cabo la comunicación con el tablero de control secundario.
Las opciones de interacción que ofrece el tablero principal a los usuarios en

forma local son: rotar a la derecha, rotar a la izquierda, modificar el estado
de la iluminación e ir a la posición de Home. Respecto a esta última cabe
decir que, además de desplazar la cúpula a una posición de inicio, realiza la
inicialización del sistema de encoder incremental y habilita el seguimiento
de la posición del telescopio, para lo cual obtiene la coordenada de azimut
del mismo y desplaza la compuerta hasta dicho valor en un intervalo de
30 segundos. Cuando se pulsa cualquiera de los dos pulsadores de rotación
manual se deshabilita esta funcionalidad hasta tanto se vuelva a iniciar la
secuencia de Home.
En la elección de la placa Raspberry Pi 3 como controlador central influyó

considerablemente el disponer de un GPIO que pudiese gestionarse en forma
similar a un microntrolador tradicional, sumado a la capacidad de correr
un sistema operativo de tiempo real, conectividad a red y el disponer de
abundante documentación en lı́nea sobre casos de aplicación con el mismo.
El mecanismo de alimentación en doble fuente para el tablero de control

principal ofrece una ventaja no esperada durante la fase de identificación, la
cual se refiere a evitar efectos de ruido sobre los sistemas de control producto
del accionamiento de elementos electromecánicos de potencia. Para el caso,
el accionamiento del motor monofásico se realiza desde una la red eléctrica,
en tanto la placa controladora ası́ como los conmutadores se energizan con
una UPS, teniéndose dos circuitos aislados entre si.
6.1.2. Sobre el tablero de control secundario

El tablero de control secundario es una consecuencia de la forma en la cual
se encuentran instalados los motores de apertura y cierre de las compuertas,
los cuales rotan junto con la cúpula, obligando ası́ a que el controlador de
los mismos rote también. Dentro de las alternativas para el suministro de
energı́a hacia el tablero se contemplaron varias opciones. La primera de ellas
implicaba el desplazamiento de la cúpula hasta la posición de Home y, una
vez allı́, conectar mediante borneras y realizar la apertura o cierre según la
necesidad, esto fue descartado pues en el caso de un corte eléctrico anulaba
la posibilidad de manipular la compuerta. La segunda opción promulgaba la
instalación de un anillo de corriente conectado mediante escobillas al table-
ro de control principal; sin embargo, no era plausible una implementación
realista del mismo luego fue descartado. La tercera opción, la seleccionada,
consistı́a una baterı́a DC interna y unas borneras para la carga de la misma.
Tal como lo muestra la Figura 2-27, los motores de las compuertas pueden
ser accionados tanto con un microcontrolador como en forma manual. El
propósito de esta última es no tener la necesidad de abrir el aplicativo para
abrir las compuertas, hacerlo en forma gradual o, simplemente, para el caso
en el cual la electrónica del tablero falle. Como dato adicional, emplean-
do cualquier aplicación que permita el envió de caracteres hacia el módulo
interno, es posible la apertura y cierre de la compuerta desde cualquier dis-
positivo.
La Tabla 2.3 muestra que los estados de los pines del microcontrolador
asociados a los relés de accionamiento de los motores manejan un nivel bajo
o un estado de alta impedancia digital, esto con el fin de evitar un corto
circuito en el caso que un pulsador se encuentre presionado y en el mismo
instante se accionen los motores desde el microcontrolador.
De acuerdo al plano general mostrado en la Figura 4-25, el tablero secun-

dario también emplea un esquema de lógica cableada, gestionada mediante
conmutadores electromecánicos accionados, ya sea en forma manual o desde
un microcontrolador. De la misma forma, dado que la velocidad de movi-
miento de las dos compuertas no es la misma y a la necesidad de establecer
una protección contra el sobre esfuerzo de los motores DC disponibles, se
hace uso de finales de carrera; los cuales establecen los topes para las po-
siciones de totalmente abierto y totalmente cerrado, abriendo el circuito e
interrumpiendo la alimentación de los motores cuando las compuertas han
llegado a la posición deseada.
La comunicación entre el tablero de control principal y el tablero de control

secundario se lleva a cabo empleando un enlace Bluetooth, entre el radio de
la placa Raspberry Pi 3 y un modulo HC-05, el cual solo emula un puente
en una comunicación a través de UART totalmente transparente. El micro-
controlador del tablero secundario es un ATMEGA328p programado en C,
empleando el IDE de Arduino. La metodologı́a seguida para llevar a cabo
la comunicación consiste en el envı́o de simples caracteres, que son inter-
pretados ya sea como una orden de movimiento o una solicitud de consulta
del estado actual de la compuerta, este último se determina evaluando la
realimentación obtenida desde los finales de carrera de los motores.
Contrario al caso del tablero principal, en el tablero secundario se tiene

que la alimentación de los motores se hace con la misma fuente de energı́a
destinada al controlador, lo cual ocasiona un efecto de distorsión en el nivel
de la fuente DC cuando se produce el encendido de los motores. Con el
fin de amortiguar este fenómeno, se agrega un condensador de 22000 uF
faradios en paralelo a la fuente, el cual se encarga de suministrar el pico de
corriente ocasionado por el transitorio de los motores; antes de su instalación
se producı́a un fenómeno de “reset” del microcontrolador, al momento del
encendido de los motores, perdiéndose ası́ la orden dada hacia el dispositivo
y evitando el cierre o la apertura de la compuerta.
De acuerdo a la Figura 4-11, se agrega un fusible como protección para el

tablero de control a la vez que, en lugar de emplear un controlador de carga
para la baterı́a, se hace uso de un diodo rectificador normal. Lo anterior
se justifica en el hecho de que el flujo de corriente de una fuente a otra es
proporcional a la diferencia de potencial entre las mismas, dividido entre
la suma de las resistencias internas de las fuentes. Para el caso, la fuente

DC que alimenta puede entregar un voltaje máximo de 13.3 V, al que ha
de restarse una caı́da de 0.7 V en el diodo, lo cual coincide con el voltaje
nominal de carga para la baterı́a de 12.6 V. Es decir, a medida que la baterı́a
se acerque a su valor de carga, la corriente de entrada hacia esta tenderá a
cero. Ahora bien, para el caso en el cual la fuente se encuentre apagada, es
decir a un nivel de 0V, el diodo no permite que la baterı́a inyecte corriente
hacia la fuente como forma de protección de la misma.
La programación del microcontrolador fue llevada a cabo siguiendo un es-

quema de máquina de estado. Esto es, definir su comportamiento iterativo
como la evaluación de condiciones de activación para ordenes o eventos es-
pecı́ficos. De esta manera, es posible obtener el estado de la compuerta aún
cuando esta se encuentre en movimiento. De forma similar, como mecanismo
de seguridad para garantizar la robustez del programa, se hace uso de un
Watchdog Timer; el cual, si no es actualizado en intervalos menores a un
segundo, realiza un “reset” del microcontrolador, evitando ası́ la congelación
de este en un estado en particular, en el anexo B.1 puede ser consultado en
detalle el algoritmo descrito.
6.1.3. Sobre el software de gestión local

La elección del lenguaje de programación Python para la escritura del soft-
ware de gestión local, que debe correr sobre la placa de control principal,
fue motivada por la simplicidad de la ejecución del mismo sobre los siste-
mas GNU/Linux, puesto que no requiere la instalación de un Framework o
máquina virtual dedicada para la compilación y depuración de scripts, a es-
to hay que agregar la capacidad multiparadigma del lenguaje, pues permite
la escritura de programas en forma estructurada como bajo el paradigma
orientado a objetos.
La metodologı́a del sistema de automatización contempla la división del

observatorio en componentes de hardware más pequeños, cada uno de los
cuales se encuentra enfocado a una tarea especı́fica. Ahora bien, el protocolo
de mensajes MQTT, explicado en la Figura 3-2, ilustra cómo es posible
relacionar diferentes componentes, partiendo de un puente central a través
de un paradigma de publicación y escucha de mensajes cortos. Las relaciones
se manejan a través de la suscripción de cada componente a tópicos o canales
de información con un único identificador. Los mensajes pueden ser texto

plano y no requieren de un switch central para su direccionamiento puesto
que cada nodo de la red esta en la capacidad de interpretar si un mensaje
esta o no dirigido a él. Es ası́ como, partiendo de esta idea de la operación del
protocolo MQTT y de la segmentación del proyecto, se define la jerarquı́a de
clases mostrada en la Figura 3-3; en la cual, se puede identificar claramente
a puente de unión entre clases representado en la clase broker y en las demás
clases se tienen elementos de publicación y escucha de mensajes.
Si bien los mensajes enviados desde y hacia las clases consisten de texto
plano, los mismos deben contar con una estructura que permita identificar su
contenido en forma coherente y fácilmente identificable. Por esto, se recurre
al formato JSON, el cual es una técnica de encapsulamiento de datos fácil
de escribir y leer por humanos, y fácil de generar por parte de máquinas.
Con el objetivo de generar una directiva de evaluación del sistema, cada una
de las clases desarrolladas cuenta con la capacidad de responder a un tipo
de mensaje universal para cada una conocido como “live”, el cual en esencia
es una solicitud para que cada clase publique un estado relacionado con el
hardware que esta a cargo de gestionar. Con el fin de informar al aplicativo
web si este se encuentra conectado y en funcionando en forma apropiada,
los mensajes de “live” solo son generados cuando existe una sesión activa en
el aplicativo web, esto también es valido para todos los demás mensajes de
ejecución sobre el observatorio.
De acuerdo al diagrama jerárquico mostrado en la Figura 3-3, se desarro-

llan clases denominadas subsidiarias, como el caso de la clase ZWO, las
cuales tienen como única función el manejo de un elemento especifico perte-
neciente a un elemento de hardware más general. Ası́, por ejemplo, la clase
ST VL6180X está enfocada exclusivamente en la obtención de datos desde
el sensor de distancia para el sistema de encoder incremental de la cúpula,
como un componente del tipo “Dome” el cual abarca en forma general todos
los componentes referentes a la cúpula del observatorio.
De acuerdo a la documentación mostrada para las clases Dome y ZWO, se

hace uso de hilos de ejecución de programa paralelos, con el fin de atender
a diferentes funcionalidades en la medida que son solicitadas. Es necesario
aclarar que el inicio, o muerte, de un hilo en particular no está condicionado
en ninguna manera por otro que no sea el hilo de ejecución principal. El
objetivo de estos hilos es atender a tareas que son consideradas crı́ticas

para el correcto funcionamiento del esquema de automatización. Ası́, por
ejemplo, se observa que se tiene un hilo dedicado a la reposición la cúpula
de acuerdo con la coordenada de azimut del telescopio, o un hilo para atender
a “interrupciones” derivadas de cambios en el estado del GPIO con el fin de
ejecutar la funcionalidad esperada de pulsadores o alarmas. Cada hilo nuevo
que se crea, con diferencia del hilo callback del GPIO se establece en forma
no persistente. Esto es, puede ser iniciado y terminado cuantas veces sea
necesario durante la vida del hilo principal. También es importante aclarar
que el fin de este conlleva a la terminación de cualquier hilo secundario que
halla sido lanzado.
Si bien es totalmente factible realizar la implementación de un servidor y

alojar una pagina web en la placa Raspberry Pi 3, por cuestiones de permisos
de acceso desde el exterior hacia la red institucional y tiempos de desarrollo,
se opta por emplear Amazon Web Services para alojar la página del aplica-
tivo web, ası́ como la base de datos de usuario y de objetos celestes. En este
mismo servicio se cuenta con la posibilidad de definir subdivisiones para el
almacenamiento de archivos conocidos como “Buckets”, opción que se toma
con el fin de definir dos espacios de este tipo empleando la clase Buckets3.
El propósito de estos espacios es almacenar las imágenes provenientes de la
cámara web y la cámara planetaria.
6.2. Trabajos Futuros

El trabajo plasmado en este documento tiene como objetivo ilustrar una imple-
mentación funcional de un sistema de automatización para el Observatorio As-
tronómico de la Universidad Distrital “Francisco José de Caldas”, teniendo como
limitantes los tiempos de contratación manejados entre la Universidad y la em-
presa Robótica Colombia S.A.S., ası́ como algunos desacuerdos en cuanto a temas
creativos entre el autor del presente trabajo y los responsables del proyecto.
Lo anterior implica que el trabajo final implementado puede mejorarse en algunos

aspectos, con el tiempo y la disposición necesarios. A continuación se mencionan
algunas propuestas para optimizar el funcionamiento del observatorio y garantizar
una experiencia de observación remota lo más amigable tanto para el usuario como
para la infraestructura fı́sica del observatorio.
6.2 Trabajos Futuros 131
6.2.1. Traslado del servidor
Anteriormente se ha mencionado como el servicio de alojamiento de la pagina web,

ası́ como de la base de datos de usuarios para el aplicativo se tiene pagando un
servidor de Amazon Web Services. Sin embargo, si se considera el ancho de banda
requerido por el sistema tal cual como se ha planteado, se tienen dos paquetes de
datos principales. En primer lugar, se tienen los mensajes de control desde y hacia
el servidor en forma de mensajes JSON, los cuales no son otra cosa diferente a
cadenas de texto plano con una estructura bien definida que sirve para representar
una propiedad o campo especifico seguido de un valor para el mismo; puesto que
se trata de texto plano, el peso de estos mensajes no pasa de algunos kilobytes por
envı́o, una tarea persistente de envió de texto correspondiente a las secuencias “li-
ve” enviadas desde el servidor y sus correspondientes respuestas cada 30 segundos
generan un tráfico constante, que en términos de información enviada no supera
el MB por hora. En segunda instancia, se tiene el transporte de dos imágenes en
formato PNG, la primera de estas correspondiente a las capturas de la cámara
web del espacio del telescopio; por otro lado se tiene el envió de de las imágenes
tomadas por la cámara ZWO, el tamaño tı́pico para una imagen capturada por
la cámara web es de entre 700 y 900 KB, en tanto que para la cámara ZWO es
de alrededor de 3 MB. Tomando en cuenta lo anteriormente expuesto se puede
afirmar que el tráfico neto generado por el observatorio no sobrepasa los 50 MB
para una sesión de observación de 1 hora.
Otro aspecto a tener en cuenta es que solamente se produce tráfico entre la Rasp-
berry Pi y el servidor cuando se encuentra una sesión activa en el aplicativo web
y, puesto que solo es posible tener una sesión activa en un determinado instante
de tiempo, ası́ como el hecho de que estas sesiones no son recurrentes a lo largo
del dı́a, resulta que el tráfico neto mensual por el cual se paga la suscripción a
Amazon se desaprovecha en forma bastante evidente.
Se sugiere entonces, reemplazar el servidor externo, montándolo directamente en

la placa Raspberry Pi 3, que se tiene disponible en el tablero de control principal.
Dados los requerimientos de ancho de banda, ası́ como el solo tener que atender
a un usuario en una sesión única, resulta totalmente plausible esta mejora. El
principal obstáculo podrı́a estar en conseguir un puerto de libre acceso a través
del punto de acceso principal de la red institucional de la Universidad, ası́ como la
posible volatilidad en el mantenimiento de las mismas condiciones a lo largo del
tiempo. También seria necesario disponer de un equipo intermedio, o firewall, que

garantice la seguridad el servidor. Las ventajas de llevar a cabo esto se encuentran
al disponer de la base de datos directamente en el observatorio, ası́ como evitar
pagar una mensualidad para el funcionamiento del observatorio astronómico.
6.2.2. “Vision” remota de la cúpula

Uno de los componentes controlados por la Raspberry Pi 3 es una cámara web
emplazada al interior de la cúpula astronómica (véase Figura 6-1), cuyo propósito
es obtener una imagen sobre el estado actual de la misma, con lo cual se deseaba
suplir la necesidad de disponer de un “ojo” sobre el telescopio y la posición del
espacio de observación de la cúpula. El inconveniente principal de esta solución ra-
dica en la demora entre la solicitud de la imagen y la obtención de la misma, como
consecuencia del tiempo de propagación e interpretación del mensaje por parte de
la Raspberry Pi, el tiempo de captura de imagen propia de la cámara y el retraso
generado por la carga de la imagen al Bucket de almacenamiento y la posterior
actualización de la tarjeta en el aplicativo web. También resulta evidente que se
trata de algo poco agradable de utilizar, pues lo deseable serı́a poder ver en tiem-
po real el estado de la cúpula sin necesidad de solicitar imágenes de forma manual.
Figura 6-1: Cámara en cúpula observatorio.
La razón para no realizar la transmisión de vı́deo con vista al interior de la cúpula

radica en el ancho de banda necesario. El streaming de vı́deo requiere cerca de
5 MB por minuto para una calidad cercana a los 480p, lo cual no va de acuerdo
al plan adquirido en AWS. Una de las actividades complementarias del proyecto
consiste en la instalación de un circuito de televisión cerrado para la seguridad
del observatorio, dentro de los equipos adquiridos para tal fin se cuenta un DVR
de HIKVISION, y un total de 6 cámaras con visión infrarroja, el DVR además de
permitir la grabación del vı́deo proveniente de cada una de las cámaras, realiza
la transmisión vı́a internet hacia los servidores del fabricante, desde donde puede
ser consultada con un usuario creado por el comprador del dispositivo.
EL servicio de streaming de HIK es totalmente gratuito y sin limites de uso. Es

posible acceder a las cámaras desde una aplicación para dispositivos móviles, tal
cual como se observa en la Figura 6-2, y también es posible agregar la señal de
las mismas a través de iframes en paginas web. Luego, una mejora a futuro que
se propone es llevar a cabo la integración de la cámara puesta en la cúpula sobre
una nueva división del aplicativo web del observatorio, lo cual puede mejorar
enormemente el uso del mismo, puesto que hace posible el ver directamente el
estado del observatorio ası́ como el estado de los equipos al interior de este. El
tráfico de vı́deo necesario no es motivo de preocupación, en la medida que al
embeber una referencia a una web externa en la pagina que hace el llamado, se
sigue empleando el servidor de origen para la transmisión de los datos.
Figura 6-2: Circuito cerrado de TV observatorio UD.

6.2.3. Control de giro cúpula

EL control de giro y posición implementado para la cúpula esta basado en un
esquema de lógica cableada a través de relevadores electromecánicos, el cual, si
bien funciona, tiene los siguientes inconvenientes:
Al tratarse de un contacto que se cierra para energizar el motor no se obtiene

un efecto de arranque suave para el mismo. Esto resulta irrelevante cuando
se quiere que el dispositivo funcione en forma constante durante intervalos
de tiempo considerables. Sin embargo, para el caso del observatorio este
movimiento solo ocurre durante un par de segundos la mayorı́a de las veces
y algo más de 90 segundos para el desplazamiento más largo.
Solo es posible ejercer un control de tipo on/off sobre el motor y su sentido

de giro, a la vez que, el arranque del motor genera una enorme vibración
sobre la ya de por si poco sólida infraestructura del observatorio, lo cual es
perjudicial para el seguimiento de objetos celestes por parte del telescopio,
ası́ como en la captura de imágenes.
Una vez el motor se encuentra en movimiento, se tiene una corriente im-

portante circulando a través de los contactos de los relevadores. Cuando el
movimiento se detiene, estos contactos conmutan interrumpiendo el paso de
la corriente, no sin antes presentarse una chispa entre el contacto y la termi-
nal a medida que se separan. El ciclo de conexión-desconexión, a medida que
se altera la posición de la cúpula, genera una gran cantidad de estos arcos,
que literalmente funden el metal de los contactos haciendo que se peguen
entre si, inutilizando el relevador. Esto puede provocar un daño irrepara-
ble en el motor, en la medida que uno de los dos bobinados puede quedar
energizado en forma permanente o en el mejor de los casos, el inutilizar el
movimiento de la cúpula al dañarse el relevador.
Para el control de la velocidad de rotación de un motor AC se puede optar por

variar la frecuencia de la señal de alimentación con un variador de frecuencia, pero
estos además de su elevado costo no solucionan el problema referente al control
del sentido de giro, con lo cual no resultan la mejor alternativa. En lugar de ello,
se propone una solución basada en el control de fase con el fin de administrar
la cantidad de energı́a rms que se le suministra al motor, partiendo del simple
concepto de que si el torque se mantiene constante el variar la energı́a suministrada
se altera la velocidad de rotación de la cúpula.
El interruptor electrónico
Resulta evidente el tener que emplear interruptores electrónicos que cumplan la
función de los relevadores. Para el caso se sugiere el empleo del TRIAC, el cual es
un dispositivo que funciona como un interruptor para corriente alterna en forma
similar a un SCR para continua. Esto es, se mantiene apagado hasta que se le
inyecte corriente en un pin denominado gate o compuerta y circule entre sus dos
terminales principales una corriente denominada corriente de sostenimiento; la
única forma de apagar el dispositivo es hacer que la corriente que lo atraviesa sea
inferior a la corriente de sostenimiento requerida por este. Como se trabajara con
una señal sinusoidal que posee un cruce natural por cero, el dispositivo se apagará
cuando finalice cada semiciclo, será necesario enviar una señal de control para
volver a encenderlo cuando comience el siguiente semiciclo de la señal.
Control de velocidad
La velocidad de rotación de un motor depende en esencia de la cantidad de po-
tencia que se le suministre. Si se puede controlar el flujo de potencia de la red
hacia el motor, se puede controlar la velocidad de rotación del mismo; es aquı́
donde los interruptores demuestran su forma de utilización más interesante. Esto
es, controlando la cantidad de tiempo que están cerrados o abiertos a lo largo de
todo el periodo de la señal. Se puede controlar la cantidad de corriente rms que
se le suministra a los bobinados y por ende la velocidad de rotación del motor. El
objetivo es recortar la señal de entrada como se ilustra en la Figura 6-3.
Figura 6-3: Recorte de fase en señal de alimentación.
Esperando una determinada cantidad de tiempo en grados contados a partir del

cruce por cero de la señal, se disparan los interruptores, aumentando o dismi-
nuyendo la cantidad de energı́a que se le entrega a la carga. En este caso, los

bobinados del motor, con lo cual, se puede llevar a cabo el control de la velocidad
de rotación; como se puede observar se tienen regiones donde la corriente que se
le inyecta al bobinado de magnetización es igual a cero. Durante este tiempo, no
tiene sentido inyectar corriente al bobinado de trabajo, por esta razón se puede
agregar un interruptor adicional, que se cerrará en el mismo instante de tiempo
que se cierren los interruptores del bobinado de magnetización. El esquema general
del circuito de potencia inversor de giro se muestra en la Figura 6-4.
Figura 6-4: Puente H AC.
Implementación del circuito control
Figura 6-5: Diagrama de bloques circuito de control.

Fuente DC: con el fin de alimentar todos los dispositivos que se emplearan,
es necesario construir una fuente de voltaje DC, para esto solo es necesario
un transformador, diodos y un filtro para eliminar rizado, en caso de ser
necesario se puede agregar un regulador monolı́tico.
Figura 6-6: Esquemático fuente DC.
Detector de cruce por cero: puede implementarse ya sea con un comparador

de voltaje o un transistor BJT en corte y saturación, detecta los cambios de
semiciclo de la señal y genera señales de sincronismo para el disparo de los
interruptores.
Figura 6-7: Detección cruce por cero.
Generador de base de tiempo: los pulsos correspondientes a los cruces por

cero pueden ser usados para controlar la carga y descarga de un condensa-
dor mediante un transistor, haciendo la constante de tiempo de carga mayor
a la duración de cada semiciclo podemos generar una señal rampa pseu-
dolineal (véase Figura 6.8(b)), donde el valor instantáneo de voltaje en el
condensador se corresponda con un valor de tiempo transcurrido.
(a) Generador diente de sierra. (b) Señal base de tiem-

po.
Figura 6-8: Generador base de tiempo para control de fase y forma de onda
Control de fase y de sentido de giro: el ángulo al que se dispararan los

interruptores se fija comparando la señal de base de tiempo con un nivel
DC, como ya se ha dicho, la señal diente de sierra se emplea para establecer
una relación entre tiempo y valor de voltaje, de esta forma, fijando un nivel
de voltaje como si fuese un valor de tiempo y comparándolo con la señal
diente de sierra se cierran los interruptores en el instante deseado. Para
controlar el sentido de giro del motor solo basta agregar un arreglo lógico
(véase Figura 6-9), el cual haga uso de una señal digital para habilitar la
señal de control para los interruptores M11-M12 o para M21-M22.
(a) Selector sentido de giro. (b) Disparo por ángulo.
Figura 6-9: Control de sentido de giro y ángulo de disparo.

Driver de disparo interruptores: el disparo de los TRIACs constituye la parte

más problemática de la implementación, puesto que la señal de disparo que
se aplique a cada uno de los interruptores debe estar aislada galvánicamente,
esto es, cada señal de control debe contar con su propia referencia de tierra
independiente de todas las demás, para conseguir esto se pueden utilizar opto
acopladores, más especı́ficamente los circuitos de la familia MOC30XX, los
cuales son TRIACs que se cierran ante un pulso luminoso generado por un
led.
Figura 6-10: Conexión optotriac MOC30XX.
Es de notar que el disparar los TRIACs de potencia con el MOC tiene la

ventaja de usar la misma señal de red que se conectara a la carga para
cerrarlos, esto aı́sla totalmente la señal de entrada con el circuito de poten-
cia, la referencia de MOC utilizada dependerá de la cantidad de corriente
necesaria para disparar el TRIAC seleccionado.
Las anteriores simulaciones y esquemáticos fueron realizados con el software PSIM
9.0, el esquemático general para el circuito de control planteado en el diagrama
de bloques 6-5 se muestra en la Figura 6-11, resulta evidente que hace falta un
sensor para determinar la velocidad de rotación de la cúpula y realimentar la
misma hacia un microcontrolador equipado con un conversor digital-analógico,
puesto que tal como se puede observar en el esquemático, el ángulo de disparo es
controlador por el nivel de voltaje conectado a la terminal negativa del compara-
dor, puesto que la Raspberry Pi no dispone de dicho modulo, se recomienda hacer
uso de un microcontrolador externo dedicado únicamente a ejecutar la función de
transferencia del controlador que se diseñe, de tal forma que solo reciba la posición
deseada a través de serial desde la Raspberry Pi y se encargue del desplazamiento
de la cúpula hasta dicha posición, liberando de esta forma a la placa central de
esta tarea, que como se explico anteriormente ocupa una parte importante del hilo
principal de ejecución del programa.
Figura 6-11: Esquemático general control de fase.

Apéndice A
Códigos Magnetómetros
A.1. Código de implementación magnetómetro

MAG3110
# include " i2c . h " // Use I2C library found here :

http : // users . soe . ucsc . edu /~ karplus / Arduino / libraries / i2c /
# define degrees_per_radian (180./3.14159265358979)
// minimum and maximum values seen during calibration time

int mag_low_x = -1300;
int mag_high_x = -730;
int mag_low_y = 810;
int mag_high_y = 1386;
int mag_low_z = -1124;
int mag_high_z = -585;
int mag_x , mag_y , mag_z ;
int xmax = -10000;
int ymax = -10000;
int zmax = -10000;
int xmin =10000;
int ymin =10000;
int zmin =10000;
// I2C 7 - bit address of the magnetometer

# define MAG_3110_I2C 0 x0E
142 A Códigos Magnetómetros
// registers on the magnetometer

# define MAG_3110_DR_STATUS 0 x00
// add 1 for LSB

# define MAG_3110_OUT_X_MSB 0 x01
# define MAG_3110_OUT_Y_MSB 0 x03
# define MAG_3110_OUT_Z_MSB 0 x05
// add 1 for LSB // user offset

# define MAG_3110_OFF_X_MSB 0 x09
# define MAG_3110_OFF_Y_MSB 0 x0B
# define MAG_3110_OFF_Z_MSB 0 x0D
# define MAG_3110_CTRL_REG1 0 x10

# define MAG_3110_CTRL_REG2 0 x11
// Fields in registers
// CTRL_REG1 : dr2 , dr1 , dr0 os1 , os0 fr tm ac
// Sampling rate 80 Hz
# define MAG_3110_SAMPLE80 0
// How many samples to average ( lowers data rate )

# define MAG_3110_OVERSAMPLE1 0
# define MAG_3110_OVERSAMPLE2 0 x08
// put in active mode

# define MAG_3110_ACTIVE 0 x01
// CTRL_REG2 : AUTO_MRST_EN _ RAW MAG_RST _ _ _ _ _

// reset sensor after each reading
# define MAG_3110_AUTO_MRST_EN 0 x80
// DR_STATUS Register ZYXOW ZOW YOW XOW ZYXDR ZDR YDR XDR
A.1 Código de implementación magnetómetro MAG3110 143
# define MAG_3110_ZYXDR 0 x08
# define mag_write_reg (r , v ) ( i2cWriteRegister ( MAG_3110_I2C ,r , v ))

# define mag_read_reg ( r ) ( i2cReadRegister ( MAG_3110_I2C , r ))
inline uint8_t mag_data_ready ( void )

{ return mag_read_reg ( MAG_3110_DR_STATUS ) & MAG_3110_ZYXDR ;
}
void mag_read_xyz ( int16_t &x , int16_t &y , int16_t & z ){
while (! mag_data_ready ()) {} // wait for new set of data
static uint8_t data [6];

i2cReadRegisters ( MAG_3110_I2C , MAG_3110_OUT_X_MSB , 6 , data );
x = ( data [0] < <8) + data [1];
y = ( data [2] < <8) + data [3];
z = ( data [4] < <8) + data [5];
}
void mag_set_offsets ( void ){

int mag_x_offset = ( mag_low_x + mag_high_x )/2;
int mag_y_offset = ( mag_low_y + mag_high_y )/2;
int mag_z_offset = ( mag_low_z + mag_high_z )/2;
static uint data [6];
data [0]= mag_x_offset > >7; data [1]=( mag_x_offset < <1)& 0 xFF ;
data [2]= mag_y_offset > >7; data [3]=( mag_y_offset < <1)& 0 xFF ;
data [4]= mag_z_offset > >7; data [5]=( mag_z_offset < <1)& 0 xFF ;
i2cWriteRegisters ( MAG_3110_I2C , MAG_3110_OFF_X_MSB , 6 , data );

}
void print_heading ( int16_t x , int16_t y , int16_t z ){
float mag_x_scale = 1.0/( mag_high_x - mag_low_x );

float mag_y_scale = 1.0/( mag_high_y - mag_low_y );
float heading = atan2 ( - y * mag_y_scale , x * mag_x_scale );

if ( heading < 0)
{
heading += 2* PI ; // correct for when the heading is negative
}
float headingDegrees = heading * degrees_per_radian ; // convert to de
// convert to clock hands
headingDegrees =360 - headingDegrees ;
Serial . print ( " headingDegrees = " );
Serial . print ( headingDegrees );
Serial . println ();
}
void mag_setup ( void ){

mag_write_reg ( MAG_3110_CTRL_REG2 , MAG_3110_AUTO_MRST_EN );
mag_write_reg ( MAG_3110_CTRL_REG1 ,
MAG_3110_SAMPLE80 + MAG_3110_OVERSAMPLE1 + MAG_3110_ACTIVE );
mag_set_offsets ();
}
void setup ( void )

{
Serial . begin (115200);
i2cInit ();
i2cSetBitrate (100); // try 100 kHz
delay (20);
mag_setup ();
delay (50);
}
void searchMax (){

mag_read_xyz ( mag_x , mag_y , mag_z ); // read from sensor
if ( mag_x > xmax ){ xmax = mag_x ;}
if ( mag_y > ymax ){ ymax = mag_y ;}
A.2 Código de desarrollo brújula compensada con acelerómetro LSM303C 145
if ( mag_z > zmax ){ zmax = mag_z ;}

}
void searchMin (){

if ( mag_x < xmin ){ xmin = mag_x ;}
if ( mag_y < ymin ){ ymin = mag_y ;}
if ( mag_z < zmin ){ zmin = mag_z ;}
}
void loop ( void ){

// searchMax ();
// searchMin ();
// print from sensor
// Serial . print (" mag x = ");
// Serial . println ( mag_x );
// Serial . print (" mag y = ");
// Serial . println ( mag_y );
// Serial . print (" mag z = ");
// Serial . println ( mag_z );
print_heading ( mag_x , mag_y , mag_z ); // print the heading
}
A.2. Código de desarrollo brújula compensada

con acelerómetro LSM303C
// I2C interface by default

//
# include " Wire . h "
# include " SparkFunIMU . h "
# include " SparkFunLSM303C . h "
# include " LSM303CTypes . h "
# define MAG_OUTX_L 0 x28

# define MAG_OUTX_H 0 x29
# define MAG_OUTY_L 0 x2A
# define MAG_OUTY_H 0 x2B

# define MAG_OUTZ_L 0 x2C
# define MAG_OUTZ_H 0 x2D
# define degrees_per_radian (180./3.14159265358979)
/*
* define DEBUG 1 in SparkFunLSM303C . cpp turns on debugging statements .
* Redefine to 0 to turn them off .
*/
/*
* SPI pins defined in SparkFunLSM303C . h for Pro Mini
* D10 -> SDI / SDO
* D11 -> SCLK
* D12 -> CS_XL
* D13 -> CS_MAG
*/
LSM303C myIMU ;
void setup () {
if ( myIMU . begin (
// /// Interface mode options
MODE_I2C ,
// /// Magnetometer output data rate options
MAG_DO_40_Hz ,
// /// Magnetic field full scale options
MAG_FS_16_Ga ,
// /// Magnetometer block data updating options
MAG_BDU_ENABLE ,
// /// Magnetometer X / Y axes ouput data rate
MAG_OMXY_HIGH_PERFORMANCE ,
// /// Magnetometer Z axis ouput data rate
MAG_OMZ_HIGH_PERFORMANCE ,
// /// Magnetometer run mode

MAG_MD_CONTINUOUS ,
// /// Acceleration full scale
ACC_FS_2g ,
// /// Accelerometer block data updating
ACC_BDU_ENABLE ,
// /// Enable X , Y , and / or Z axis
ACC_X_ENABLE | ACC_Y_ENABLE | ACC_Z_ENABLE ,
// /// Accelerometer output data rate
ACC_ODR_100_Hz
) != IMU_SUCCESS )
{
Serial . println ( " Failed setup . " );
while (1);
}
}
void ShowValues ()
{
float value ;
value = myIMU . readAccelX ();
// Assume that if X is not activated then none are ( poor assumptio

if ( ! isnan ( value ) )
{
Serial . print ( " \ nAccelerometer :\ n X = " );
Serial . println ( value , 4);
Serial . print ( " Y = " );
Serial . println ( myIMU . readAccelY () , 4);
Serial . print ( " Z = " );
Serial . println ( myIMU . readAccelZ () , 4);
}
value = myIMU . readGyroX ();

// Not supported by hardware , so will return NAN
{
Serial . print ( " \ nGyroscope :\ n X = " );
Serial . println ( myIMU . readGyroY () , 4);
Serial . println ( myIMU . readGyroZ () , 4);
}
value = myIMU . readMagX ();

{
Serial . print ( " \ nMagnetometer :\ n X = " );
Serial . println ( myIMU . readMagY () , 4);
Serial . println ( myIMU . readMagZ () , 4);
}
value = myIMU . readTempC ();

{
Serial . print ( " \ nThermometer :\ n " );
Serial . print ( " Degrees C = " );
Serial . print ( " Degrees F = " );
Serial . println ( myIMU . readTempF () , 4);
}
}
void loop (){

float x ,y , z ;
float xc , yc , zc ;
// Get Magnetometer values

x = myIMU . readMagX ();
xc = x /4.8828125; // Correct for obtain entire magnitudes

xc = xc *10000;
y = myIMU . readMagY ();
yc = y /4.8828125;
yc = yc *10000;
z = myIMU . readMagZ ();
zc = z /4.8828125;
zc = zc *10000;
float heading = atan2 ( yc , xc );
// heading = heading + PI /4;
if ( heading < 0)
{
heading += 2* PI ; // correct for when the heading is negative
}
float headingDegrees = heading * degrees_per_radian ; // convert t
// convert to clock hands
headingDegrees =360 - headingDegrees ;
Serial . print ( " Head = " );
Serial . print ( headingDegrees );
// Get and correct accelerometer values

float ax , ay , az ;
float axc , ayc , azc ;
ax = myIMU . readAccelX ();
axc = ax /6.103515625;
axc = axc *100;
ay = myIMU . readAccelY ();
ayc = ay /6.103515625;
ayc = ayc *100;
az = myIMU . readAccelZ ();
azc = az /6.103515625;
azc = azc *100;
axc = axc / pow (2 , 15) * 2;

ayc = ayc / pow (2 , 15) * 2;
azc = azc / pow (2 , 15) * 2;
// Estimated titl heading

float pitch = asin ( - axc );
float roll = asin ( ayc / cos ( pitch ));
float xh = xc * cos ( pitch ) + zc * sin ( pitch );

float yh = xc * sin ( roll ) * sin ( pitch ) + yc * cos ( roll )
- zc * sin ( roll ) * cos ( pitch );
float zh = - xc * cos ( roll ) * sin ( pitch ) + yc * sin ( roll )
+ zc * cos ( roll ) * cos ( pitch );
float headingt = atan2 ( yh , xh )* degrees_per_radian ;

if ( yh >= 0)
headingt = headingt ;
else
headingt = (360 + headingt );
headingt = 360 - headingt ;

// Serial . println ( xh );
Serial . print ( " Headtilt = " );
Serial . print ( headingt );
delay (500);
}
Apéndice B
Código tablero secundario para control
de compuerta de observación
B.1. Código final
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -//
// libreria
# include < avr / wdt .h >
// otras
int i =0;
int led =13;
int sel =0;
// Caracter recibido
char Key = ’. ’;
// pines para reles
int K13 = 2;
int K24 = 3;
// int K3 = 5;
// int K4 = 6;
// pines para final de carrera
int F1 = 8;
int F2 = 9;
int F3 = 10;
int F4 = 11;
// Variable de status
char sta = ’. ’;
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -//
152 B Código tablero secundario para control de compuerta de observación
void setup (){

wdt_disable ();
// Configurar led de aviso
digitalWrite ( led , HIGH );
pinMode ( led , OUTPUT );
// Configurar serial
while (! Serial ){} // wait for config end
// Config Rele
digitalWrite ( K13 , LOW );
pinMode ( K13 , INPUT );
// digitalWrite ( K3 , HIGH );
// pinMode ( K3 , OUTPUT );
// digitalWrite ( K4 , HIGH );
// pinMode ( K4 , OUTPUT );
// Config inputs for final
pinMode ( F1 , INPUT_PULLUP );
// config Interrupt
// attachInterrupt (0 , serialInterrupt , CHANGE );
wdt_enable ( WDTO_1S );
}
void Status (){

int k =0;
if ( digitalRead ( F1 )==0){
k +=1;
}
k +=5;
}
k +=9;
B.1 Código final 153
}
k +=15;
}
// evaluate
// error
if ( k ==6|| k ==24|| k ==29|| k ==15|| k ==25){
sta = ’E ’;
}
// All open
else if ( k ==14){ sta = ’O ’ ;}
// All close
else if ( k ==16){ sta = ’C ’ ;}
// Mid
else {
sta = ’M ’;
}
}
// void serialInterrupt (){
// while ( Serial . available ()==0){}
// Key = Serial . read ();
// if ( i ){ digitalWrite ( led , HIGH ); i =0;}
// else { digitalWrite ( led , LOW ); i =1;}
// }
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -//
void ClearBuffer (){
char w ;
for ( int i = 0; i < 50; i ++){
while ( Serial . available () > 0){
char k = Serial . read ();
w ++;
delay (1);
}
delay (1);
}
154 B Código tablero secundario para control de compuerta de observación
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -//
boolean EndO (){
if ( digitalRead ( F2 )==0 || digitalRead ( F3 )==0){
wdt_reset ();
delay (200); // tiempo de antirebote
if ( digitalRead ( F2 )==0 && digitalRead ( F3 )==0){
return true ;
}
}
return false ;
}
boolean EndC (){
if ( digitalRead ( F1 )==0 || digitalRead ( F4 )==0){
wdt_reset ();
delay (200); // tiempo de antirebote
if ( digitalRead ( F1 )==0 && digitalRead ( F4 )==0){
return true ;
}
}
return false ;
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -//
void loop (){
// Verificar si existe un caracter disponible
if ( Serial . available () >0){
Key = Serial . read ();
digitalWrite ( led , HIGH );
delay (150);
digitalWrite ( led , LOW );
}
// Evaluar orden recibida
// Open Gate
if ( Key == ’o ’ && sel ==0){
pinMode ( K13 , OUTPUT );
sel =1;
B.1 Código final 155
}
// Close Gate
else if ( Key == ’c ’ && sel ==0){
pinMode ( K24 , OUTPUT );
sel =2;
}
else if ( Key == ’r ’ ){
Status ();
Serial . write ( sta );
ClearBuffer ();
}
// Evaluar casos de cierre
// Esta toalmente abierta ?
if ( sel ==1){
if ( EndO ()){
Serial . write ( ’O ’ );
// ClearBuffer ();
sel =0;
}
}
// Esta totalmente cerrada ?
else if ( sel ==2){
if ( EndC ()){
Serial . write ( ’C ’ );
// ClearBuffer ();
sel =0;
}
}
// restart char variable
Key = ’. ’;
// Restart Timer
wdt_reset ();
}
Bibliografı́a
[1] S. Bonnet, MQTT: un protocolo especı́fico para el in-

ternet de las cosas. http://www.digitaldimension.
solutions/es/blog-es/opinion-de-expertos/2015/02/
mqtt-un-protocolo-especifico-para-el-internet-de-las-cosas/,
2015. [En linea; consultado 30-Agosto-2018].
[2] Comunidad, Conexion interruptor reversible de barril. http://coparoman.

blogspot.com.co/2014/05/como-se-conecta-un-interruptor.html,
2015. [En linea; consultado 10-Septiembre-2017].
[3] N. de prensa, De matadero municipal a centro cultu-

ral universitario. http://www.bogota.gov.co/content/
de-matadero-municipal-centro-cultural-universitario, 2013. [En
linea; consultado 4-Septiembre-2017].
[4] R. P. Foundation, Hardware details for Raspberry Pi 3 model B. https://

www.raspberrypi.org/documentation/hardware/raspberrypi, 2018. [En
linea; consultado 29-Agosto-2018].
[5] FreescaleSemiconductors, MAG3110, 3-axis digital magnetometer.

http://www.farnell.com/datasheets/1624886.pdf, 2012. [En linea; con-
sultado 01-Junio-2018].
[6] T. Holecek, VL6180-Python-3.X. https://github.com/tholecek/

VL6180-Python-3.X/blob/master/ST_VL6180X.py, 2017. [En linea; con-
sultado 18-Julio-2018].
[7] G. Inc., telescopio Newtoniano. https://sites.google.com/site/

timesolar/astronomia/telescopionewtoniano, 2010. [En linea; consul-
tado 31-Julio-2018].
[8] M. I. Inc., Lx200gps telescope reference manual, Meade, (2018), pp. 5–30.
BIBLIOGRAFÍA 157
[9] Liada, Montura ecuatorial. https://sedaliada.wordpress.com/2015/06/

26/mi-primer-telescopio/montura-ecuatorial/, 2015. [En linea; consul-
tado 31-Julio-2018].
[10] LogicBus, Tipos de encoder. http://www.logicbus.com.mx/info_

encoders.php, 2018. [En linea; consultado 20-Julio-2018].
[11] J. Mutlaq, Discover INDI. http://indilib.org/about/discover-indi.

html, 2015. [En linea; consultado 15-Septiembre-2018].
[12] J. Mutlaq, Developer Manual. http://indilib.org/develop/

developer-manual.html, 2018. [En linea; consultado 15-Septiembre-
2018].
[13] I. T. Peña and J. G. Aguilar, Medición de pro-

piedades fı́sicas de Menkalinan y Capella. https://
observatorio.uniandes.edu.co/index.php/proyectos/culminados/
35-medicion-de-propiedades-fisica-de-menkalinan-y-capella, 2016.
[En linea; consultado 3-Septiembre-2017].
[14] D. Ramı́rez, B. Oostra, and A. Arias, Espectro solar en alta reso-

lución. https://observatorio.uniandes.edu.co/index.php/proyectos/
culminados/38-espectro-solar-con-alta-resolucion, 2016. [En linea;
consultado 3-Septiembre-2017].
[15] STMicroelectronic, Using lsm303dlh for a tilt compensated electronic

compass, AN3192, (2010), pp. 10–20.
[16] M. support, What’s MQTT. http://mqtt.org/faq, 2010. [En linea; con-

sultado 30-Agosto-2018].
[17] ZWO, ASI120MC-S (color). https://astronomy-imaging-camera.com/

product/asi120mc-s, 2016. [En linea; consultado 15-Septiembre-2018].

Automatizacion Observatorio Astronomico PDF

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

Automatizacion Observatorio Astronomico PDF

Cargado por

Copyright:

Formatos disponibles

Automatización observatorio astronómico

Oscar Ferney Gallo Romero

Universidad Distrital Francisco José de Caldas

Oscar Ferney Gallo Romero Código: 20131005031

Trabajo de grado para optar al tı́tulo de:

Universidad Distrital Francisco José de Caldas

Al llegar a este punto solo resta expresar mi agradecimiento a todas aquellas

Para el proyecto de automatización del observatorio astronómico de la Universi-

El hardware del sistema de automatización fue construido siguiendo estándares

Para el control de los motores que se emplean para el movimiento de la cúpula y

control principal y también para determinar si se ha activado el interruptor de

Como conclusión al trabajo se muestran algunas imágenes de objetos celestes

Lista de Tablas XIX

2. Diseño de hardware de gestión para la cúpula del observatorio 9

3. Desarrollo de software de administración local 37

4. Integración global de componentes 85

5. Actividades adicionales 115

5.2.1. Ensamble y depuración de tarjetas electrónicas de montaje

6. Conclusiones y Trabajos Futuros 123

A. Códigos Magnetómetros 141

B. Código tablero secundario para control de compuerta de obser-

2-1. Domo astronómico . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2-29.Detalle iluminación cúpula . . . . . . . . . . . . . . . . . . . . . . 36

3-1. Detalles Raspberry Pi 3 Model B[4] . . . . . . . . . . . . . . . . . 40

4-1. Arquitectura general de sistema y métodos de comunicación. . . . 85

4-22.Finales de carrera y motores DC. . . . . . . . . . . . . . . . . . . 101

5-1. Trazado de canaleta autoadhesiva. . . . . . . . . . . . . . . . . . . 116

6-1. Cámara en cúpula observatorio. . . . . . . . . . . . . . . . . . . . 132

2-1. Tabla de verdad apertura de compuertas . . . . . . . . . . . . . . 34

3-1. Resumen especificaciones Raspberry Pi 3 model B[4] . . . . . . . 39

El problema a abordar consistı́a entonces en llevar a cabo la implementación de

El lector del presente trabajo encontrara en el primer capı́tulo el planteamiento

En el segundo capı́tulo se lleva a cabo la identificación del estado del observatorio,

EL tercer capı́tulo se ocupa de definir los requerimientos que debe satisfacer el

El cuarto capı́tulo, expone la arquitectura general de todo el proyecto, la forma en

EL último capitulo muestra algunas actividades complementarias desarrolladas

1.1. Planteamiento del problema

También es importante mencionar a organizaciones como la Red de Astronomı́a

En el año 2013 se completó el proceso de remodelación del antiguo matadero de

que permite realizar la apertura y la rotación de la cúpula el cual es accionado

1.2.2. Objetivos especı́ficos

2. Desarrollar el software para generar el enlace remoto entre el hardware y el

3. Llevar a cabo la integración global de los diferentes elementos que constitu-

4. Integrarse en las actividades propias de la empresa Robótica Colombia S.A.S,

5. Realizar la socialización de las actividades desempeñadas en el marco de la

Tableros de control: Los tableros de control construidos durante el tiempo

Software: El software de gestión local desarrollado en python se encuentra

Instalación de equipos: como aporte final se puede mencionar la instalación

2.1. Tareas preliminares e identificación

Figura 2-1: Domo astronómico

Figura 2-3: Ruedas de giro horizontal

El diámetro de la cúpula es de 4 metros, lo cual implica un perı́metro de 12.566

Figura 2-2: Motor AC para rotación horizontal

2.1.2. Consideraciones sobre el movimiento de rotación

Enunciando de manera resumida, para controlar el sentido de giro de un motor

Figura 2-4: Inversión de giro con interruptor reversible de barril[2]

En el estado inicial del observatorio, se dispone de un interruptor reversible de

en particular, se consigue disminuir el impulso inicial de corriente en el arranque

Figura 2-5: Compuerta doble espacio de observación

2.1.3. Consideraciones sobre compuerta vertical

El espacio vertical de observación cuenta con un arreglo de compuerta doble, es

Figura 2-6: Motores DC para apertura y cierre de compuerta