Software para misiones satelitales educativas. Glen D. Rodríguez R., Dr.Ing.

Transcripción

1 Software para misiones satelitales educativas Glen D. Rodríguez R., Dr.Ing.

2 Qué es una Misión satelital educativa? Es un proyecto para que alumnos universitarios o de secundaria fabriquen, lancen y monitoreen un satélite. Dicho proyecto les proporciona experiencia real y directa en desarrollo tecnológico, de gestión de proyectos a lo largo del ciclo de vida del mismo, integración de sistemas, testing, etc. Ejemplos: Cubesats, Cansats, SuitSats o RadioSkaf.

3 Cómo es una Misión satelital educativa? Debe: Ser barata Desarrollar un satélite pequeño Multidisciplinaria por necesidad Tener plazos cortos (alrededor de 2 ó 3 años para el desarrollo y pruebas) No busca solucionar una necesidad puntual, más bien es aprender + prueba de conceptos Capacitar para entrar en la industria aeronáutica y aeroespacial.

4 Rol del software en una Misión satelital educativa El software es un elemento más (no el único ni el más importante) de un proyecto satelital. Básicamente se usa software en: Estación terrena Computadora a bordo Otros elementos: componentes mecánicos estructurales, aislante térmico, calentadores y enfriadores, sensores y estabilizadores, hardware de comunicaciones, carga útil, etc.

5 Software en la Computadora a bordo La computadora a bordo es el Control central del satélite. NO siempre es un chip de PC: puede ser microcontrolador (PIC, FreeScale, ARM, etc.) o un FPGA. Es relativamente lenta y consume poca energía. Se le graba un programa que maneja al resto del hardware del satélite. A veces algunas tarjetas tiene su propio μc y se les delega una función que antes hacia el control central.

6 Software en la Computadora a bordo El software generalmente se desarrolla en C, se compila en una PC y el ejecutable se graba en el μc o la CPU. En el primer caso no hay S.O.; el programa debe manejar el scheduling, las excepciones, interrupciones. Sistema de tiempo real: hay tiempos máximos en que el software debe responder. Timers. Orientado a eventos y muy dependiente de estados.

7 Estación terrena Este subsistema no es parte del satélite en sí, pero su existencia y operación es necesaria para lograr los objetivos de un satélite. Es el conjunto de software, instalaciones y equipos de comunicación inalámbrica (radio) necesarios para comunicarse con el satélite, ya sea el propio o el de otra institución con que se tenga un convenio.

8 Funciones 1. Seguimiento: Se escucha el beacon o radiofaro del satélite para conocer su posición. 2. Telemetría: Pedir variables de estado (temperatura, voltaje, etc.) para monitorear al satélite y validar el cálculo de la órbita. 3. Comando: Ordenar al satélite por ejemplo que haga reset al sistema; ordenar la toma o el envío de las fotos.

9 Chasqui-I Es un proyecto de la UNI para hacer y lanzar un satelite pequeño (en la frontera entre pico <= 1kg, y nano >=1kg). Sigue los estandares de tamaño y peso cubesat (1kg, forma de cubo de arista=10 cm) Carga útil: dos cámaras, una en el rango visible y otra en el rango infrarrojo. Download a tierra. Objetivo: Mejoramiento de las capacidades de la UNI en tecnología satelital a través del diseño, análisis, ensamblaje, integración, prueba, lanzamiento, y operación de un nanosatélite con tecnología Cubesat.

10 Chasqui-I

11 Satélite Chasqui I Pre-Amplificador LNA Coaxial Transceiver (radio) ICOM Coaxial AX.25 Recepción Transmisión Antenas UHF Rotor Yaesu (motor) Amplificador TNC (terminal node controller) Cable adaptado a USB DIAGRAMA DE BLOQUES DE LA ESTACION TERRENA Cable AWG18 2x6 Serial RS232 Control Box ARS AZ-EL (SE) Mercury GS Cable de 8 líneas Computadora Cable de Puerto paralelo Tarjeta externa

12 Algunos conceptos clave TNC una especie de modem(en el ejemplo, diseñado y fabricado por el equipo del proyecto Chasqui I; su diseño es muy parecido al de la tarjeta de comunicaciones en el satélite, pero pueden comprarse TNCs comerciales). Mercury GS: software open source para manejo de estaciones terrenas, al que se le han hecho modificaciones y mejoras. AZ-EL: azimut-elevación AX.25 : protocolo de paquetes para radio aficionados

13

14

15 Software de la Estación terrena Se escogió usar, adaptar y modificar el software Mercury GS Se usaron las siguientes herramientas: Sistema operativo: Linux UBUNTU Sistema de gestión de base de datos: MySQL 5.5 Lenguaje de programación PHP: PHP 5.0 Lenguaje de programación Java: Java Version 1.6 Web Server: Apache AJAX : FrameWork jquery-1.4.2

16 Qué hace el Mercury GS? La versión original soporta: Control y configuración de algunos modelos de radios comerciales. Configuración de la estación terrena (ubicación, etc.) Seguridad (autenticación de usuarios) Catálogo de satélites a observar y tareas de observación. Manejo de sesiones. Todo con un front-end vía web (PHP) y un back-end en Java

17 TNC + RADIO It works as java server Functionset_radio() Server ComSerial.java Functionsend() DriverRadioCiv_V.java DriveRadio.java Socket ComTCP.java ComGsml.java ComDriverRadio.java Functionread_socket() Functionrecv() FunctionSetRadioState() FunctionrecvSetRadioState() These part works both as web server and java cliente FunctionSet_radio() fn.php Functionmerc_set_radio() merc.php msg=<gsml></gsml> Functionsend_msg(host, port) Socket TxFrecuency TxMode RxFrecuency... POST Table_control_radio.php Client

18

19 Nuevos módulos Módulo Commands: permite la creación, edición y eliminación de comandos y sus atributos en la Base de datos

20 Nuevos módulos Módulo Photos: Esta interface permite la exploración de los archivos de photos, previamente creadas que nos llegarán desde el satélite (galerias, previews, ver metadata de la foto) Módulo Communications: actúa como interfase que permite registrar los eventos de comunicación e intercambio de información entre la estación terrena y el satélite, teniendo en cuenta la sesión y fecha del evento. De no estar creada una comunicación, no permitirá el envío de comandos.

21

22 * * * MercuryConfiguration comp state i... : MercuryComponent : int : int Principales clases usadas o modificadas ComGsml BCAST_DST state buf... : String : int : byte[] sessioncom ProductionUnit packets sessionmessages txstream... : Vector : Vector : ComTcp DataServer modemcom rxstream txstream... : Sender : ComTcp : ComTcp * * * * comp MessageServer comp : int MercuryComponent : Vector Receiver {abstract} clientport clients... SessionController radiocontrolisenabled antennacontrolisenabled... * + + # comp sessioncom log id endtime : ComGsml : Logger : String : long recv (byte b[], int len, Object src) senderclosed (Object com) log (int level, String msg) : void : void : void * * * comp db stmt... DbConnection : MercuryComponent : Connection : Statement - - rt conf... GsManager : Runtime : MercuryConfiguration - antennacom - controlstream... DriverAntenna : Sender : ComTcp {abstract} # # radiocom controlstream... DriverRadio : Sender : ComTcp {abstract} DriverPower - syncwithdbinterval... {abstract} : int = 1000 DriverAntennaYaesuGs232 DriverRadioCiv_V DriverPowerFireCracker - isinitialized : boolean = false - - BIT_DELAY X10_HEADER : long : String = 2 = "

23 Clases modificadas Receiver (clase receptora de mensajes) DataServer (Proporciona conexiones TCP/SSL con el TNC y habilita un acceso remoto al hardware. Es el componente que recibe datos del satélite y envía datos al satélite usando la configuración del TNC. Esta clase fue modificada para controlar los paquetes de las fotos que envía el satélite. Agregamos una método revpacket(), que verifica los bytes recibidos y si en caso hubiera un error enviar una petición de paquetes)

24 Nuevas clases (creadas por nosotros) CLASES CREADAS DESCRIPCION FileController DbFile DbCommunication DbCommand Recibe y realiza un control sobre los paquetes (fotos y/o archivos de texto) que llegan del satélite. Funciones para leer y escribir en la tabla File de la base de datos. Funciones para leer y escribir en la tabla Communication de la base de datos. Funciones para leer y escribir en la tabla Command de la base de datos.

25 Formato de datos entre TNC y software La data se guarda en la base de datos como binary type, pero no es la data pura de la foto; es una data empaquetada en un paquete con el siguiente formato: Packet ID: número de paquete(2 bytes) Data Size: tamaño real de la carga útil (2 bytes) Available image data: data real de la foto (max. 506 bytes) Verification Code: suma byte-por-byte de la data real de la foto(2 bytes) MAX. SIZE OF PACKET = 512 BYTES; IT COMES IN MANY AX.25 FRAMES OF SIZE 32, 64 OR 128 BYTES

26 Funciones adicionales Métodos ExecuteQuery y getimageblob sirven para desempaquetar la data que viene del TNC+radio. Luego de desempaquetar, se guarda la data en una tabla de la base de datos. Método getdatosgsml obtiene la carga útil de los paquetes guardados en formato XML en la base de datos Método saveimage transforma la data binaria en un archivo jpeg en un directorio del software.

27 RECEPCIÓN Switching entre transmisión y recepción El switching se realiza con la finalidad de no dañar la Radio Icom910h porque la potencia que emite es alta. Se controla con una clase Java. TRANSMISIÓN TNC RADIO Comandos MERCURY (BACK END) Comandos RADIO ICOM 910H Equipos / modo Para transmitir Para recibir RADIO ICOM910H Preamplificador (desactivado), cambiar frecuencia (450MHz) Preamplificador (activado), cambiar frecuencia (437MHz) TNC -RADIO Transmision (activado) Transmision (desactivado)

28 Tracking del satélite (control del rotor) El software usado para captar información de satélites pequeños consiste en lo siguiente: Predictor de órbitas predict, en SO Línux Ubuntu. Interface de controlador de radio y rotor libhamlib, en SO Línux Ubuntu. Programa personalizado en lenguaje C, para consultar al predictor de órbitas y manejar la interface de rotor/radio, para conseguir un seguimiento automático de los satélites. Este programa se comunica con el Mercury GS (modulo nuevo) Grabador y editor de sonidos Audacity, en SO Línux.

29

30

31 Control Box Ángulos de Elevación y de azimut Frecuencia modificada por Doppler shift ARS AZ-EL (SE) Cable 8-wires Cable paralelo libhamlib Programa C-main Transceiver (radio) ICOM910H USB adapted cable Predict MERCURY GS Modificado

32 Pruebas con otros satélites Se va a describir el procedimiento para interpretar una señal de beacon en CW-Morse, a manera de ejemplo para el satélite ruso Yubileiny (RS-30). La interpretación se puede hacer directamente por el sonido de la radio, o indirectamente mediante el software Audacity. La salida de audio de la radio se conecta al terminal de entrada de audio de la PC por medio de un cable fabricado para tal propósito. Luego, usando el software Audacity se graba el audio en la PC, y en el mismo software se elimina el ruido del audio y se analiza la señal en el dominio de la frecuencia. El resultado es que se observan claramente los puntos y rayas que se pueden interpretar usando una tabla Morse.

33 R S 3 0 Call sign del satélite Yubieliny

34 Conclusiones La tecnología para crear software de comunicaciones y control de estación terrena está dentro del alcance de un estudiante peruano de ingeniería. Pero la orientación no es a casos de uso ; es más técnica: requerimientos no funcionales son tan importantes como los funcionales. Integración de software como parte de un sistema mayor: desafío.